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

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.