Thread: Oregon 650 flashed with Oregon 750 firmware is BRICKED

Ok, so now we know some certainties about the device. Importantly it's UID has not been permanently lost and it's now got HWID of 2512 also with ramloader of O750t flashed to region 12. We also know (i) either nonvol region is not 41 but 154; or (ii) that the path to card isn't 1. So maybe the card is 2 and nonvol is in region 154, or .... some other combination. So let's test it with other combinations and also try to get a dump of GarminDevice.xml and gupdate.gcd.

Remove last_id.bin from the 2512 folder and replace the contents of update.txt with these commands then try again:

Spoiler:

rrgn,154,1:/154.bin
copy,0:/Garmin/GarminDevice.xml/,1:/
copy,0:/.System/gupdate.gcd,1:/
rrgn,41,2:/41.bin
rrgn,154,2:/154.bin
copy,0:/GarminGarminDevice.xml/,2:/
copy,0:/.System/gupdate.gcd,2:/
reboot

After you copy/paste the text ensure that you haven't accidently created any additional spaces behind lines or a 'carriage return' anywhere before using. Post all results including the new entries in update.log

Mixed results there.

The good: Not only is the ability to dump regions confirmed, we now know that its nonvol memory is in region 154 and the path to card is 1. The earlier error from trying to dump region 41 via 1 is likely because that region doesn't even exist in the region layout for O750t.
The not so good: "Volume Not Mounted" error means that we cannot directly access the file system from the card and even with Mass Storage Mode enabled it likely wouldn't be accessible that way either without firstly some manipulation and a reformat.

The file system in most devices is actually contained in a dedicated region, either 48 mostly in older-style devices or 83 in newer devices and in some cases it's duplicated with copies in both regions. So we should try to dump both. You might need a minimum 8GB card for this attempt to work. Remove last_id.bin from 2512 folder and replace the contents of update.txt with the following:

Spoiler:

rrgn,48,1:/48.bin
rrgn,83,1:/83.bin
reboot

The BINs will be identical. Try to open one of them in 7-Zip, hopefully it's readable and you will be able to see and extract all folders and files like this:

Spoiler: Image

[Only registered and activated users can see links. ]

It was worth trying to read the dumped BINs but that result is not very surprising. The file system regions are now certainly confirmed corrupted/unreadable. That was previously indicated by failure to dump copies of GCD and XML files with 'volume not mounted' error.

Maybe it's appropriate to try deleting the file system by erasing the regions using "ergn,48" and/or "ergn,83". If it succeeds, that would however result in a region state similar to an unformatted/unallocated partition in Windows or reported as a RAW volume in Disk Management if it can be detected, so we'd then need to have Mass Storage Mode available to re-format the file system with RMPrepUSB or it may even be required to recover it by doing a LLF with a different tool. We could also erase the main firmware (system software) in region 14 to force it to default to preboot showing 'System Software Missing'. You may want to think about whether to do either or both, and if so which to do first. I suspect that erasing the file system regions won't make things any worse, maybe... but erasing the firmware in 14 is very risky as it's quite impossible to know how much the wrong firmware data there is contributing to the present partial operation of the device, or, if it's in fact hindering further functionality. However if it loses preboot or media card function again it might be quite problematic. I'm certain losing both would be fatal. At least with the cure fw presently loaded to region 14 it might be possible to re-gain Mass Storage if the file system is empty of any data preventing the device booting and/or trying to load software during the boot attempt.

Another thought is to attempt to overwrite the file system using 'fftl' text command. I'm unsure what exactly is additionally executed with that command other than just writing a BIN file's data to the file system. It seems it must do something more that just write data from a BIN to a region because that's what 'xrgn' does. So fftl command may also properly format the file system before writing to it i think. Maybe it doesn't work like that, i just am not sure. If you want to try it, it's best to compile a BIN file named filesystem.bin, comprised of just .System and Garmin folders because many devices won't boot completely empty and we want it to boot, eventually. This zipped bin has been made with PowerISO or you can make your own: [Only registered and activated users can see links. ]. Usage: Extract the ZIP file and place filesystem.bin in card root alongside (not in) the Garmin folder. Remove last_id.bin if present in 2512 folder and replace Update.txt content with "fftl,0,1:/filesystem.bin".

If you try any of the above suggestions i can't say what the results might be so you have to take all responsibility for any outcome. I doubt you have much to lose at this stage anyway.

That means of course that 'fftl' command no longer works for the O750t ramloader (boot.bin/Ldr.bin) and has been replaced by the command 'ffs'. Maybe it still works for O6x0's ramloader but that's moot at present because the device seems unwilling to load the unmodified O6x0 ramloader.

Successful erasure of the file system resulting in no change is consistent with the 'Volume Not Mounted' error and i doubt there was any usable/recoverable data present previously and there certainly isn't now. Try to open in a Hex Editor the 48 or 83 BIN you previously dumped. I think there will only be gibberish or empty FFs bytes in there.

You've established previously that O6x0's ramloader doesn't seem to work now. It may be simply because the actual process of booting involves the firmware in region 14 and that may or may not be O750t's fw_all.bin as complete data. Even if it is complete it's clearly not working on that hardware. We can modify O6x0's ramloader so that it doesn't need the fw in 14 but then it can't work as Ldr.bin in a card. However it might work as an RGN in preboot to flash regions 12 and 14 with O6x0 firmware via text commands. Read [Only registered and activated users can see links. ] in "Running programs from SD on nuvi" thread. If you want to try but need help compiling the files let me know.