Oregon 650 flashed with Oregon 750 firmware is BRICKED

**Butters** · 11th June 2022, 07:50 AM

That is the O7xx logo in your 650's region 16 which is not unexpected being as it's part of the original O750 firmware, so that in itself is unremarkable. What is worth noting is that it has the O750 HWID of 2512 in it and when compared to the standard O6x0 logo it's otherwise very similar. The O6x0's logo also has HWID 1651 written in it:

Spoiler:

So i think we should use the modded O6x0 boot.bin RGN again seeing as this device is still confused as to it's identity. We should flash the correct O6x0 logo to its region 16 and try to dump region 14 to see if O6x0 fw_all was flashed, along with region 41 as the likely nonvol region. If you're ok with that then proceed as below.

Use the kit with the HWID folder changed back to 1651. Change the content of update.txt to:

rrgn,41,1:/41.bin
rrgn,14,1:/14.bin
xrgn,16,1:/Garmin/16.bin
reboot

Add Update.log if needed. Delete last_id.bin if present and also remove 14.bin from the Garmin folder, replacing it with the 16.bin in this [Only registered and activated users can see links. ] which is the proper logo for O6xx devices.

If nothing flashes then try with 2512 folder name. You know the disclaimer blurb by now, if it dies too bad... a tortured device like yours might pack it in at any time just by accessing poisoned/incompatible data in nonvol memory.

**andna** · 11th June 2022, 11:17 AM

Dear Butters, did as you wrote.
Text from updater log:
Oregon 600 Software Version 5.60, UID: 4294967295, HWID: 4294967295
-------------------------------------------------- ----------------------------
Parsing "rrgn,41,1:/41.bin"
success
Parsing "rrgn,14,1:/14.bin"
success
Parsing "xrgn,16,1:/Garmin/16.bin"
success
Parsing "reboot"
success

When turned on, the no Garmin logo appears, then system software missing and a pink screen.
After reboot it is still defined as O750.
Files 14.bin and 41.bin appeared on the SD card.

Spoiler: Link

**Butters** · 11th June 2022, 12:11 PM

This is a stubborn device, it clings to O750 identity no matter what we throw at it. There's no obvious reason why the O7x0 logo data would display the splash screen yet the correct O6xx data doesn't. It's confirmed as fw_all data for O6x0 in region 14 and it is clearly reacting to the O6x0 ramloader albeit the modified one. Maybe it's time to attempt erasing the nonvol memory, that's a last resort tactic which might work. However, first some questions need answers:
1. Did HWID folder 1651 or 2512 work for the last flash?
2. "After reboot it is still defined as O750" ... On device screen or in Updater.exe or both?
3. Did it display as 6x0 at all this time?

**andna** · 11th June 2022, 12:48 PM

Dear Butters,
1. 1651.
2. When flashing with modded_boot, it is displayed in UPDATER.EXE as O600, after flashing and rebooting and reconnecting it is displayed as O750 in UPDATER.EXE.
The model name does not appear on the screen.
P.S. During flashing with modded_boot, when it is defined as O600, the GARMIN splash screen appears.
3. Sorry, I didn't understand what you meant.

Spoiler: SCREEN

**Butters** · 11th June 2022, 10:06 PM

I meant in 3 for 6x0, like asked in 2 about 750, whether it displayed as 6x0 (O6xx/O600/O650) in Updater and/or on device screen during boot. Because you didn't mention otherwise, I guess it didn't display any model series on the device screen.

Let's next try flashing this O6xx [Only registered and activated users can see links. ] now that we know the device is reacting to it's correct 1651 HWID and it definitely has original V5.60 O6xx fw_all data in region 14. Just attempt a normal preboot Updater.exe flash. After it flashes don't disconnect from the PC. Hopefully it will immediately enter MSM and be visible in Disk Management as an unformated or RAR partition and can be formatted properly with RMPrepUSB. If it doesn't happen, read on.

Only if the above doesn't work, use the the Modded Flash Kit with 1651 folder and have only this this cured fw_all [Only registered and activated users can see links. ] in the root (alongside the Garmin folder, not in it). Flash modded_boot.RGN in preboot to execute this command in Updater.txt:

xrgn,14,1:/Garmin/14.bin
reboot

Have the PC ready with Disk Management open and a USB cable connected to it before you start. When Updater reports success, hopefully the device won't try to boot at all so quickly disconnect and reconnect it to PC then refresh or rescan Disk Management. Reformat it if it shows.

**andna** · 12th June 2022, 08:24 AM

Butters, nothing happens in either the first or second case.
UPDATER.EXE writes no updates, and nothing happens with the xrgn,14,1:/Garmin/14.bin command. The device reboots immediately. If you change it to xrgn, 14,1: / 14.bin, it is successfully flashed, but nothing happens after the reboot. In Disk Management, the device does not appear in any way.
P.S. The device is constantly in a preboot state. No manipulation of the power button is required to connect to UPDATER.EXE.

**Butters** · 12th June 2022, 10:37 AM

Is there any resultant entry in update.log from either attempt? If so please post it. Maybe it's not responding to HWID folder 1651 again.

It has defaulted into preboot because the data in region 14 cannot be read. The firmware (main system software) in there is responsible for initiating the bootloader in region 5 and that isn't happening therefore the situation is the same as 'System Software Missing' on splash screen. The data in 14 appears not corrupt or missing as evidenced by the earlier dump of it which compares the same as a heathy fw_all.bin from O6x0 fw:

Spoiler:

The first difference is the numerous FFs behind the checksum 2B in your dumped 14.bin and those empty FFs merely represent the unused space in the device's region (a dump "rrgn" copies the entire region, i.e. data and unused space).

So what we can tell from that is even though the proper fw data is there in 14, something is preventing it from being used by the device to boot itself properly. Not only that, even though we were previously able to write new data to 14 it's not allowing that now using the same method we used before.

**andna** · 12th June 2022, 04:52 PM

Text updater log after flashing with command xrgn,14,1:/14.bin:

Spoiler: Updater log

**Butters** · 12th June 2022, 11:09 PM

So you weren't correct when you stated "nothing happens in either the first or second case" because it did flash cured fw_all in 14.bin using the modded boot RGN.

In an otherwise healthy device defaulted to preboot, loading cure firmware would immediately change the default mode from preboot to Mass Storage and even a badly corrupted or unformatted or RAW file system would become visible to the PC, if not in Windows File Explorer then certainly in Disk Management for re-formatting correctly.

Here's what i think has happened to your device, one of two things and maybe even both:
(1) the flash drive has been irrevocably damaged by the failed attempt to convert the device to O750 with the region layout compromised, maybe other things too but particularly in regards the physical space allocated to the file system (48/83), also most likely that failure wrecked the Virtual region 12 to which the ramloader is written each time a flash is initiated with a (standard) boot.bin/Ldr.bin. The reason a flash with Updater.exe, used in the normal way, fails is because region 12 on the device is not being rewritten and maybe is never going to be capable of that because it's either been destroyed or rendered permanently unwritable, so it can't be re-flashed with correct (O6x0) ramloader data. Therefore region 12 cannot in turn write (either at all or correctly) to the physical regions 5 (the bootloader) and region 43 (the x-loader). However when the modded ramloader is flashed as RGN to execute txt commands on the card, that process is completely bypassed, importantly so is also the process involving the fw in region 14 which [normally] invokes the bootloader in region 5 to initiate starting the device;
and/or,
(2) the nonvol region (in the current O6x0 layout) 41 is poisoned with confusing and incompatible data. That causes the device to malfunction badly when it reads messed up data in 41 and explains why it will re-identify as O750 after a failed flash using Update.exe normally. That poisoning may be either:
(i) a permanent corruption; or,
(ii) erasable by using ergn command. Erasure using ergn doesn't stop the device replacing some essential and limited data in the region provided that it can then fully boot up, and hopefully that re-written data will be clean if it does fully boot.

So in effect, (1) and 2(i) are fatal and not correctable by any software cure.

Using 2(ii) is risky because the device may be left totally dead and never again even turn on.... but in my opinion it's the only remaining option left now. If you wish to do do, use the flash kit with the modded_boot.rgn to execute the erase command. Remove last_id.bin of course and replace the contents of Update.txt in 2512 folder with this:

ergn,41
reboot

If it does revive and become stable enough to enter Mass Storage Mode with cure O6x0 fw loaded (which it is already) then maybe it can be recovered... but possibly with limited functionality due to a crippling or deletion of some nonvol data which cannot be ever replaced.

**andna** · 13th June 2022, 04:01 PM

Dear Butters, did as you wrote.
It does not happen with the folder name 2512. With the name 1651 it is being flashed, but it does not go into mass storage mode. After reboot it is defined as O750.
Text from updater log:

Spoiler: LOG

Thread: Oregon 650 flashed with Oregon 750 firmware is BRICKED

Thread Tools

Display

Advertissements

Bookmarks

Bookmarks

Posting Permissions