Thread: GARMIN drivesmart61 flash APAC version firmware problem

Garmin has continued with making it harder to flash other firmware to (apparently) compatible hardware. I expect that eventually it'll be quite impossible for new devices.

Originally Posted by superman

.............
Before venturing further, I reckon that I am better of making a backup of device-specific data/info since I do enjoy the entitlement to lifetime map update for North America region. I just wonder if it is sufficient to just back up the Region 154 in case I screw thing up. Many thanks!
......

Concerning the LM entitlement, that's tied to the device UID which doesn't ever change. So any conversion you do won't alter the factory map programming whether it's Lifetime or One-off entitlement.

You should make a full region dump of all possible regions (1-255) which will include the visible file system (probably rgn83 in your DS61) and the nonvol memory rgn154. Of course nothing will help if the device is unable to be flashed in preboot or via media card because it's been hard-bricked due to an incompatible bootloader present in rgn5 - think of it as the BIOS/UEFI of a PC, but not directly re-flashable (because rgn5 is protected and it's only flashable by rgn12). So if you do a full conversion with a 'foreign' ramloader (boot.bin/Ldr.bin) flashed to rgn12 and the device then boots enough for rgn12 to to load the new bootloader to rgn5 and/or the new x-loader to rgn43, one of several things will happen. Either it'll fully boot up and work fine, or it'll soft-brick but be recoverable because preboot's still available, or it'll brick without any touchscreen function and perhaps be recoverable (or perhaps will work converted with a compatible screen change), or it'll permanently hard-brick and never power on again. I'm hazy on the actual exact and technical boot process but Garmin is similar to other ARM devices. One of our experts, kunix gave this explanation many years ago and i'm sure at the time nobody else outside Garmin knew more about it than him:

Spoiler: Click

Originally Posted by kunix

.......... it's a typical boot sequence of an embedded ARM-based device, including Garmin devices.
So, I can tell the same story of the boot sequence the Garmin-ish way:

1. When you power on your device, the ARM processor starts executing it's ROM code.
   The external RAM modules are not initialized yet, so ROM code would have to use the internal SRAM for stack and data.
   ROM code searches for x-loader somewhere, the copies it to SRAM and executes it.
   On debug motherboards ROM code can load x-loader from SD/MMC or over UART.
   But on release Garmin motherboards ROM code loads x-loader only from starting blocks of the external flash chip. So if you erase those blocks, you will never boot your device again.
   Also those blocks are known as region 43.
2. x-loader is made by Garmin, so it "knows" a lot about the hardware setup.
   x-loader initializes the external RAM. Then, if the external flash chip is NAND, it loads bootloader from region 5 to RAM and executes it.
   Alternatively, if the external flash chip is NOR, the bootloader's addresses are mapped to the address space of the CPU (I don't know, whether x-loader sets up the mapping or it's done by the hardware setup), and so in this case bootloader can be executed from flash directly.
3. Bootloader (the "u-boot") enters the pre-boot mode if a particular key combination is pressed, or if region 14 doesn't pass the "5A A5" test.
   
   In the pre-boot mode the bootloader and the program on the PC (updater.exe, for example) communicate using the Garmin USB protocol.
   If not entered the pre-boot mode, bootloader proceeds to execute fw_all.bin.
   If the external flash chip is NAND, bootloader loads fw_all.bin from region 14 and executes it.
   If the flash chip is NOR, bootoader executes fw_all.bin from flash directly.
   If you erase bootloader in region 5, you will never boot your device again (most probably, because maybe x-loader can load bootloader from SD, but it's highly doubtful).
4. fw_all.bin (the "kernel") is responsible for
   
   • drawing the usual GUI
   • for providing the mass storage mode and the MTP mode.
   • initiating the procedure of executing update.txt scipts.
   • initiating the procedure of flashing GUPDATE.GCD files and verifying GUPDATE.GCD digital signature.
   • also, if not in the mass storage/MTP mode, it can communicate with the PC using the Garmin USB protocol and it provides a very rich set of USB commands
5. boot.bin (the "ramloader") is responsible for:
   
   • flashing regions over USB in pre-boot mode. It also communicates with with the PC using the Garmin USB protocol.
   • very frequently boot.bin contains copies of bootloader and x-loader and flashes them, when executed.
   • flashing regions from GUPDATE.GCD files.
   • executing update.txt scripts.

Every piece of Garmin firmware (i.e., x-loader, bootloader, fw_all.bin, boot.bin) contains a table of regions, which specifies which regions are contained on which flash chip and where exactly.
Also people frequently confuse bootloader and boot.bin. They are different.
Also region 41 (NV) is parsed only by fw_all.bin, other pieces of firmware (x-loader, bootloader, boot.bin) treat it as an opaque massive of bytes.
So if NV is corrupt, fw_all.bin may crash even when entering the mass storage/MTP mode.
But other pieces of firmware (x-loader, bootloader, boot.bin) continue working correctly.

So in short, if any of regions 5, 43 or 41/154 (the NV) are corrupt and preboot or SD is not working the device is done. Let's know if you make more progress.