Thread: IMPORTANT! If you want HELP in case of a bricked Garmin device, please follow this

Yes, Garmin's ARM processor is indeed customised. It's of course "ARM-like" however operates and boots the device in a "Garminized" kind of way. kunix supplied us with an insight as follows:

Spoiler: click for quote

Try reading the following [Only registered and activated users can see links. ], 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.

I can add that the Garmin OS of your 1390, although Linux-based, is very far from basic Linux and is a proprietary "closed-shop". We can garden around the edges by modifying firmware but AFAIK nobody has actually been able to get into the OS proper or if they have done, they haven't made it pubic.