aera 795 stuck on 'Loader' after fw update (could getting Unit ID from GMA or UNL files help?)

**BenBreit** · 5th November 2023, 12:12 PM

Good Morning (by the time you read it, it should be morning again

)

As I was reading your post #50, I remembered that the aera never took commands from SD directly. So I tried your instructions and didn't take it of course.

So I tried to remember how I did it actually to take commands from SD. And it was together with the thread from kunix. So here is what I did now:

-loaded original FW in RGN_TOOL
-saved the boot.bin and changed the bytes to "3E"
-loaded back in RGN_TOOL and saved as 136401000560.rgn
-put in the same folder as GarminCure3 and let the updater run as cure file

Now it is taking the commands and here are the results from the update.log-file:

Spoiler: Click

So it was parsing the 14.bin, but you guessed it: no joy

**Butters** · 5th November 2023, 01:12 PM

That was to be my next and final suggestion, to use modded boot.bin as an RGN to execute update.txt via Updater.exe in preboot. That method to flash it using GarminCure3.exe to invoke Updater.exe is fine and has same result as loading the RGN directly into Updater.exe itself.

Unfortunately i can't access your Google Drive link, it denies access. Please just advise what it says in the log file after " Parsing "xrgn,14,1:/14.bin" ". If it says 'Error' it's non-recoverable. Even if it says 'Success' but still bootloops it's still a goner because there's no further software fixes to try. Only if it was 'Success' message and then stuck on logo with no bootloop and MSM accessible could we carry on.

**BenBreit** · 5th November 2023, 06:04 PM

Umh, well... then definitely its a write off. No other chances with some commands from the SD Card?

Spoiler: Logfile

By the way. If I flash the device with the updater (to run commands from SD) I will get the error message again after the 100%. So no success message. Not sure if it has something to do with it.

**Butters** · 5th November 2023, 11:27 PM

EDIT: Read the PS for a last-ditch attempt at recovery.
Apologies in advance for the lengthy explanation below but i think it's worth a read:

Seeing update.log shows success, the contrasting absence of success message from updater.exe may or may not be of interest, but only academically. The reality is that the device has cure firmware in region 14 but still bootloops and it doesn't have access to MSM. You'd be aware now that the sole design purpose of loading cure fw is to stall the boot process so no corrupt file/s are loaded and consequently MSM is re-enabled. Then those files (if known) can be removed or the entire internal file system reformatted as a last resort. Of course loading cure fw, deletion of individual files or entire folders, even formatting (if possible) may also be done via SD text commands, but to what end now? ... There are no files loaded when cure fw is present in rgn14 so it likely has no corrupt files onboard causing the problem, if it did have a bad file causing the boot problem it should freeze on logo now.

The inevitable conclusion is that the device has serious flash damage or region corruption of some type, as in two distinctly different possibilities i think.

First, it has actual physical flash damage of some sort which makes booting impossible although it tries over and over endlessly to do so. That damage might be either spread everywhere across essential parts of the flash memory (like extensive bad blocks can be present in any common flash drive) or it might even just be quite minor but confined to one single important region. It might even be rgn14's allocated space itself although i don't believe so because initially the copyright and associated messages appeared but after your attempts loading cure fw they ceased. That indicates to me that cure fw in 14 is preventing loading of files exactly as intended, therefore it appears 14 can in fact be overwritten properly. You can dump it with "rrgn,14,1:/14.bin" and hex compare it to cured fw_all.bin if you want, all data should be identical other than the dumped BIN will be much bigger and have empty FFs at the end reflecting unused space in the region (the entire allocated space is dumped). You could also write original fw_all data back to see if the start messages re-appear, but again it's academic.

However seeing you don't know the history of the device there is also a very likely second possibility. Someone has inappropriately flashed it with firmware meant for a different device, in particular using fw containing a foreign ramloader but preserving the aera's HWID. The ramloader is what Garmin calls the "boot.bin" component of the firmware, although it's a misnomer. The ramloader (aka boot.bin) is flashed to rgn12 (0x0C), a virtual region. During the next start up, rgn12 flashes two physical regions. Those regions are 43, the x-loader and critically region 5, the bootloader. Think of rgn5 like the BIOS/UEFI of a PC. Without BIOS working properly it cannot boot the PC, so similarly if an incompatible bootloader is in rgn5 there's no boot possible. Now you might think "We'll just flash rgn5 with correct data then" .... except you can't because it's protected from direct flashing and can ONLY be written by rgn12 during a successful boot cycle. So even if rgn12 now has appropriate data in it, it's not being invoked because the device isn't booting far enough due to an inappropriate bootloader in 5 and that bootloader can't start the device.

So, regardless of whether it's got physical damage or an incompatible bootloader it's become like a dog chasing it's tail, just bootloops endlessly getting nowhere. Sorry to say it is likely only good for parts now. I've heard it's possible to use JTAG methods to repair the flash by reprograming the chip if it's got a bad rgn5 but of course that needs not just special skills but also expensive specialized equipment. It's also possible to replace the flash chip then program it suitably. If you can find someone to do it you'd find the cost is very high. Garmin could do it for you but won't, they only exchange with "refurbished" like-for-like device. Perhaps you should enquire with them, it might be worth the exchange cost in this case.

Safe flying Ben.

PS: A late second thought. You could erase its non volatile memory from region 41 after backing it up. It's an outside chance there's some bad data there but worth a shot. Use 'rrgn,41,1:/41.bin' to back it up and 'ergn,41' to erase it. Even if it does work to stop the bootloop there may be other problems with the device, some feature may not work properly as some data can't be rewritten to 41 when it boots again.

**BenBreit** · 9th December 2023, 10:41 AM

Sorry for coming back only now. I was able to erase the 41.bin with the effect that the bootloop is now taking longer, but still no chance to recognize it as an MSM. I was hoping to be recognizable via RMPrepUSB, but also there it is not recognized. I still believe it can be saved, but have no clue how

Definitely we can work with SD Commands. Maybe 41.bin is not the issue, but another file?

Spoiler: update.log

**Butters** · 11th December 2023, 01:19 PM

The increased time between re-boots is likely because the device is trying to "reconstruct" region 41 with basic information however logically if there was previously bad data in region 41 which was causing the bootloop it would now be frozen on the logo screen. That's because it's had cure fw written to region 14 previously so clearing potentially poisoned data from 41 should allow 14 do its job. Therefore something else other than 41 is causing the bootloop and that's now narrowed down to one of these possible problems:

(a) A corrupt essential file in the file system (i.e. those files normally seen in Mass Storage Mode). That could even be a general data corruption as sometimes happens where 'nonsense' folder/file names appear in flash drives... but more likely caused by a single individual bad file such as, for example, a map IMG file, a poi GPI file, or a voice VPM file, etc. Unfortunately, that's by far the least possibility because the cure fw in region 14 should have prevented any attempt to load such files at all.

(b) A hardware fault such as a partially failed flash chip .... which is definitely not fixable by any software means.

(c) A foreign bootloader is present in region 5 which now cannot be overwritten from region 12 apparently because many flash attempts have been made by you using the correct ramloader (the so-called boot.bin). You'll recall that the ramloader is written to the virtual region 12 and it then writes to the physical region 5 (but that's done on the next successful complete boot cycle). So even though we're able to run commands from SD using boot.bin as an RGN the incapable bootloader is still in region 5. Region 5 is protected from direct flashing in every Garmin device i've tried (i.e., writing 5.bin via SD command "xrgn,5,1:/5.bin" will fail).

In the slight hope that it might be (a), if you want to examine the file system you can dump it using "copydir,0:/,1:/BackUp/" command and then try writing back completely empty folders corresponding to those in the dump, i.e. .System, Garmin, etc, etc., to overwrite all the existing folders ("copydir,1:/.System/,0:/.System/" and "copydir,1:/Garmin/,0:/Garmin/" etc.). Or if you can see any obvious corruption in a particular file from the dump it can be selectively deleted using del command, e.g. "del,0:/.System/gupdate.gcd" to remove a bad GCD file.

Personally, i'm now much less hopeful than optimistic that the device is saveable, but good luck.

Thread: aera 795 stuck on 'Loader' after fw update (could getting Unit ID from GMA or UNL files help?)

Thread Tools

Display

Advertissements

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions