Thread: GARMIN drivesmart61 flash APAC version firmware problem

@hotsport
Please say what conversion methods have you already tried without success. That will save us suggesting the common methods unnecessarily.

If you've already tried everything, it may mean that such a conversion is either unsafe or impossible. For instance, attempting conversion with non-matching PCB P/Ns always will result in failure and often in an irrecoverable hard-bricked device. Look for 1.0.5.-. in a hex reader (where "." is wildcard character) located in the respective firmwares which will tell you if there are common PCB P/Ns between the US/EU and APEC devices and importantly then check your actual device physically has one of those listed in the donor APEC firmware: [Only registered and activated users can see links. ] (Post #7 and later explanatory posts in that thread).

I test it.
APAC fireware change the file of boot, hwid change to 2588, sw change to 360. I flash the fireware. DriveSmart 61 shows system missing.

Did you do what Butters said

Look for 1.0.5.-. in a hex reader (where "." is wildcard character) located in the respective firmware which will tell you if there are common PCB P/Ns between the US/EU and APAC devices

[Only registered and activated users can see links. ]
[Only registered and activated users can see links. ]

@willingzhu
The bin file for region 154 contains device-specific information which should not be written to a device other than the unit from which it was dumped. Regardless, the device re-writes it's own specific information to rgn154 on each and every boot cycle. It was the flashing of the APAC HWID 2996 firmware that has changed the device and not the writing of the 'foreign' BUP_154.bin. In fact by first writing another device's non-vol memory info to it you ran the risk of introducing incompatible data into its NV memory which could have prevented it from ever booting again while not contributing anything of actual value for the conversion. As the device is now an APAC device with HWID 2996, GarminExpress should offer to supply compatible voice files etc. I'm unsure about the traffic receiver updates though.

Even when there's a commonality of PCB P/Ns is still always best practice to attempt a hybrid-conversion first using the original (2588 in this case) ramloader aka boot.bin from the native firmware combined with the remainder of the doner firmware (2996 in this case) but with the HWID changed to original (2588). Using original boot.bin and retaining HWID makes for easy and safe recovery if the flash fails. If a hybrid-conversion is successful then a full flash will be safe. If a hybrid is unsuccessful it could simply be that the original ramloader is not capable of starting the boot process with the 'new' fw in rgn14 and it'll boot-loop, freeze on logo or show 'system software missing' but will be fully recoverable. If it's unsuccessful because a 'new' complete fw is totally incompatible however you may end up with a dead brick that'll never boot again and won't even turn on.

Good day, All:

Thinking of converting Drivesmart 61 LMT-S (HWID 2588) to its APAC variant (HWID 2996) with a view to having the Mandarin input method. After extracting both of .GCD files with RGN tool and searching for the P/N of PCB in the extracted fw_all.bin files, it appears that both PCB have the same parts number shown as 105-%05u-%02u when viewing with a Hex editor. When checking the Hardware Version in Device > About, the LMT-S version and APAC version show "V5 M4v3 P10 16GB DW128 Ma6 WBT" and "V4 M4v3 P10 8GB DW256 Ma6 WBT", respectively. Despite the difference in Hardware Version, I still would like to try my luck.

After going through a few threads in this forum, I reckon that it's safer to flash a hybrid firmware to see if the conversion is viable. To make a hybrid firmware, I am supposed not only to combine the RAM loader of 2588 with the remainder of 2996 but also to keep the HWID as 2588.

I just wonder if I should use the GUPDATE.GCD originally from the 2588 and 2996 machines or the firmware files downloading from Garmin when generating the hybrid firmware. In addition, as seen in RGN tool, the .GCD file contains 4 .bin files, namely boot.bin, resources_7F05.bin, resources_9E05.bin and fw_all.bin. Does the remainder of 2996 refer to the files of resources_7F05.bin, resources_9E05.bin and fw_all.bin from 2996? When setting the HWID by use of RGN tool, am I supposed to set the HWID not only in the firmware section but also in the Inventory and GarminDevices.xml by ticking the option of "Replace HWID text strings"? Moreover, should the SW version be set as that of 2996?

Would be grateful if a kind soul could shine a light on these matters.


Regards,

CL

Originally Posted by superman

..........., I am supposed not only to combine the RAM loader of 2588 with the remainder of 2996 but also to keep the HWID as 2588.

Exactly.

Read Post #6 again carefully as it's explained there. Some re-stating and finer details follow below.

I just wonder if I should use the GUPDATE.GCD originally from the 2588 and 2996 machines or the firmware files downloading from Garmin when generating the hybrid firmware.

The respective GCD files should be identical regardless of how you obtained them, provided they are of the same Version because ultimately all of them would have been sourced from a Garmin server anyway. That's whether they're downloaded directly from a Garmin website or loaded to the device via GarminExpress or WebUpdater. You can use the latest versions of the files from here:

Code:

Please Login or Register to see the links

In addition, as seen in RGN tool, the .GCD file contains 4 .bin files, namely boot.bin, resources_7F05.bin, resources_9E05.bin and fw_all.bin. Does the remainder of 2996 refer to the files of resources_7F05.bin, resources_9E05.bin and fw_all.bin from 2996?

Yes, remainder is what you've inferred, the other sections of a firmware file i.e. other than the 'boot.bin' ramloader.

When setting the HWID by use of RGN tool, am I supposed to set the HWID not only in the firmware section but also in the Inventory and GarminDevices.xml by ticking the option of "Replace HWID text strings"?

Whatever you set using RGN_Tool will determine what's shown by the device subsequently in it's Inventory page and in GarminDevice.xml file if it successfully boots with hybrid firmware. Any manual changes you might make in the onboard XML won't be retained because the device re-writes it on every completed boot cycle. Remember in a hybrid conversion that you're retaining the HWID of the original device (2588 in this case).

Moreover, should the SW version be set as that of 2996?

Be sure to use the ORIGINAL device's HWID and also it's ramloader/boot.bin for a hybrid conversion, which in this case would be that of the US/EU device, i.e. 2588. For convenience and consistency i'd probably use the SW version (firmware version) of the APEC firmware advanced by ".01" (i.e. 3.51) although that's not so important, rather it's more to aid in personal recall and its identification as a hybrid fw, you could name it 7.00 if you want to avoid it being overwritten by GarminExpress later detecting it as a US/EU device due to its 2588 HWID being retained. Be aware that RGN_Tool being an older application doesn't deal too well with some later device firmwares so you need to be careful that it doesn't change region numbers etc. after saving, particularly in the 7F and 9E components. If you have problems then try with kunix's [Only registered and activated users can see links. ] instead.

This is how i'd try if i were attempting the hybrid conversion using RGN_Tool:

Spoiler: Click for Image

[Only registered and activated users can see links. ]

Then flash the RGN file in preboot. Note the specific file naming for the above would be 258801000351.rgn, reflecting the preservation of original US/EU HWID of 2588 and "01000" which tells Updater.exe to query and match the device's reported HWID to the file's HWID naming, for safety.

If you can successfully flash hybrid fw then a complete conversion using the full APAC fw will be possible. A failed hybrid flash doesn't necessarily mean it can't be fully converted however trying a full conversion first-off or if the hybrid attempt has failed might brick it. It could even hard-brick it irrecoverably. If it soft-bricks due to a failed hybrid conversion then it can be easily recovered because the original bootloader is still in region 5.

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.