Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 1 of 2 12 LastLast
Results 1 to 10 of 13
  1. #1
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default Dakota 20 firmware study

    I'have used the sd method for reading the region in GPS. I've the following RGN number in GPS: 5, 14, 15, 16, 34, 41, 43, 45, 86.
    I've used rrgn with rgn number from 0 to 149. In the following i report only the commands that results with an error.
    Dakota 20 Software Version 5.80, UID: , HWID:
    ------------------------------------------------------------------------------
    Parsing "rrgn,3,1:/Garmin/Updater/3.bin"
    Error
    Parsing "rrgn,10,1:/Garmin/Updater/10.bin"
    Error
    Parsing "rrgn,17,1:/Garmin/Updater/17.bin"
    Error
    Parsing "rrgn,19,1:/Garmin/Updater/19.bin"
    Error
    Parsing "rrgn,21,1:/Garmin/Updater/21.bin"
    Error
    Parsing "rrgn,44,1:/Garmin/Updater/44.bin"
    Error
    Parsing "rrgn,46,1:/Garmin/Updater/46.bin"
    Error
    Parsing "rrgn,48,1:/Garmin/Updater/48.bin"
    Error
    Parsing "rrgn,49,1:/Garmin/Updater/49.bin"
    Error
    Parsing "rrgn,50,1:/Garmin/Updater/50.bin"
    Error
    Parsing "rrgn,51,1:/Garmin/Updater/51.bin"
    Error
    Parsing "rrgn,74,1:/Garmin/Updater/74.bin"
    Error
    Parsing "rrgn,75,1:/Garmin/Updater/75.bin"
    Error
    Parsing "rrgn,76,1:/Garmin/Updater/76.bin"
    Error
    Parsing "rrgn,77,1:/Garmin/Updater/77.bin"
    Error
    Parsing "rrgn,93,1:/Garmin/Updater/93.bin"
    Error
    Parsing "rrgn,131,1:/Garmin/Updater/131.bin"
    Error
    Parsing "rrgn,15,1:/Garmin/Updater/15.bin"
    Error
    Parsing "reboot"
    Error
    Error: Failed to write last ID out to device
    When gps ends the commands, don't reboot and don't write the file 'last_id.bin' that disable another update execution, and the gps enter in a loop with the loader/updater.
    Solved without extracting the sd by forcing the gps to enter usb mode by very long pressing (>30 s) the power button, as works with Datota 20.
    Have to observe that the rgn 15 was extracted, but with a rrgn error, and i don't know if are a good extracted file.
    Now some questions.
    Code:
    Please Login or Register to see the links
    Last edited by ataro1; 4th May 2015 at 12:17 AM.

  2.    Advertissements


  3. #2
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    I've just read that rgn 41 are the Non Volatile Memory with personal data.
    But i've read also that rgn 5 and 43 are linked to the boot.bin of the GCD. I think that this are not true, because rgn 5 are only a little bit smaller than boot.bin, and the code of the two binary files are so different ....
    Last edited by ataro1; 4th May 2015 at 12:10 AM.

  4. #3
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    I've disassembled the routine that load the JNX files on GPS (starting from AlexWhiter work) and here i propose another version, that use a little numer of bytes and solve some not optimal thing in the jnx firmware patch.
    This is the patch (Dakota 20, firmware version 580). Installed on GPS obviously works perfectly.
    Code:
    Please Login or Register to see the links
    As in AlexWhiter patch, the first byte at address CC7AC bypass the Demo JNX handling. Differently from AlexWhiter patch, the second one at CC9F1 bypass the Garmin Hash CRC32 test result. The following 2 bytes at CC9FB bypass completely all the code written for JNX Signature test, and that solution are a little bit better respect original patch, because otherwise the remaining executed code in original patch call the memory heap routines to allocate and lock a zero lenght block of memory and than read from the JNX a zero lenght block of bytes. Sure that original patch is working, but i think that a more clean approch is better.
    The last byte at CCAAE, like original patch, bypass the JNX Device Id test matching.
    We also can save 3 bytes of patch and the result are more simple to patch because no procedure call is involved (as into the original patch that implies to patch 4 bytes that change from a firmware version to another).

  5. #4
    AlexWhiter
    Guest

    Default

    Quote Originally Posted by ataro1 View Post
    I've disassembled the routine that load the JNX files on GPS (starting from AlexWhiter work) and here i propose another version, that use a little numer of bytes and solve some not optimal thing in the jnx firmware patch.
    This is the patch (Dakota 20, firmware version 580). Installed on GPS obviously works perfectly.
    000CC7AC: D1 E0
    000CC9F1: 00 01
    000CC9FB: 7C 3F
    000CC9FC: 4E E0
    000CCAAE: D0 E0
    00876F86: EF 7A
    As in AlexWhiter patch, the first byte at address CC7AC bypass the Demo JNX handling. Differently from AlexWhiter patch, the second one at CC9F1 bypass the Garmin Hash CRC32 test result. The following 2 bytes at CC9FB bypass completely all the code written for JNX Signature test, and that solution are a little bit better respect original patch, because otherwise the remaining executed code in original patch call the memory heap routines to allocate and lock a zero lenght block of memory and than read from the JNX a zero lenght block of bytes. Sure that original patch is working, but i think that a more clean approch is better.
    The last byte at CCAAE, like original patch, bypass the JNX Device Id test matching.
    Thanks for sharing this!

    You are correct, the current implementation of the patcher does not remove the unnecessary calls (in fact it does but only in firmwares for a couple of latest device models).

    At first, I simply didn't care about optimizing the patched code - all I wanted was to make it work correctly
    And now it's too late. See, if I change the replacement patterns in the patcher, it would be necessary to re-test the firmwares in all devices. That means a lot of error-prone work and possibly bricked GPSes.
    So I prefer to make slightly better patterns for newly released devices, and for new firmwares where the old patterns refuse to work (from time to time Garmin makes more or less radical changes in the JNX loading routine).

    I'll change the pattern used for Dakota in the next release of the patcher, so it will make the minimalistic code changes.


    Quote Originally Posted by ataro1 View Post
    We also can save 3 bytes of patch and the result are more simple to patch because no procedure call is involved (as into the original patch that implies to patch 4 bytes that change from a firmware version to another).
    The patch won't be simpler, because no offsets are hardcoded in the patcher, the regular expressions search is made instead, and the call offsets are simply skipped in the patterns.

  6. #5
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    ataro1, regions 5 (bootloader) and 43 (x-loader) are usually flashed by boot.bin (ramloader) when it's executed over USB or GCD or ldr.bin.
    See nuvi firmwares for example.
    But for some devices some boot.bin versions don't flash regions 5 and 43.
    Be careful when playing with x-loader and bootloader. When booting, x-loader is loaded by processor's ROM code and then loads the bootloader, which implements pre-boot mode and loads fw_all.bin (region 14).
    Last edited by kunix; 4th May 2015 at 07:08 AM.

  7. #6
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    Quote Originally Posted by AlexWhiter View Post
    Thanks for sharing this!

    You are correct, the current implementation of the patcher does not remove the unnecessary calls (in fact it does but only in firmwares for a couple of latest device models).

    At first, I simply didn't care about optimizing the patched code - all I wanted was to make it work correctly
    And now it's too late. See, if I change the replacement patterns in the patcher, it would be necessary to re-test the firmwares in all devices. That means a lot of error-prone work and possibly bricked GPSes.
    So I prefer to make slightly better patterns for newly released devices, and for new firmwares where the old patterns refuse to work (from time to time Garmin makes more or less radical changes in the JNX loading routine).

    I'll change the pattern used for Dakota in the next release of the patcher, so it will make the minimalistic code changes.



    The patch won't be simpler, because no offsets are hardcoded in the patcher, the regular expressions search is made instead, and the call offsets are simply skipped in the patterns.
    I'm happy that You decide to implement my code in Dakota 10/20 JNX patch. You are a big, as big are your huge work.

  8. #7
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    Quote Originally Posted by kunix View Post
    ataro1, regions 5 (bootloader) and 43 (x-loader) are usually flashed by boot.bin (ramloader) when it's executed over USB or GCD or ldr.bin.
    See nuvi firmwares for example.
    But for some devices some boot.bin versions don't flash regions 5 and 43.
    Be careful when playing with x-loader and bootloader. When booting, x-loader is loaded by processor's ROM code and then loads the bootloader, which implements pre-boot mode and loads fw_all.bin (region 14).
    I've read some your posts where you say that this 5 and 43 rgns are very important, and i don't do anything on it, only backup copy on the pc. But exploring the binary of 5 i don't see anything of specific for Dakota. I see only generic names for old Garmin GPS and also a 'Honeywell' string that have few, i think, in common with garmin. Same for 43 i see, no specific code for Dakota i think. From where came the code flashed in 5 and 43? Boot.bin (or the same code Ldr.bin) don't seems have all the code for the two rgn 5 and 43. The code came from the internal of Updater.exe PC sw? Also talking of GCD, it contain only Boot.bin and the GPS firmware rgn 14 code. Where are the 5 and 43 bin code? Part in Boot and part in Firm? In't understand ..... And also a split of code from one and from other binary seems very not pratical flashing procedure ....
    Are the Dakota one of the gps that don't flash 5 and 43?

  9. #8
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    Commands supported by Dakota 20 in SD Updater mode:
    Code:
    Please Login or Register to see the links
    The following other two, supported by Nuvi's, are not valid commands for Dakota 20:
    Code:
    Please Login or Register to see the links
    Last edited by ataro1; 4th May 2015 at 09:53 PM.

  10. #9
    Navigation software Moderator kunix's Avatar
    Join Date
    Sep 2011
    Location
    Belarus
    Posts
    908
    Rep Power
    438

    Default

    ataro1, yes, you've got a boot.bin which simply doesn't flash regions 5 and 43. Obviously, they were flashed in factory and have never changed since then. It's still possible that Garmin will some day release boot.bin which would update regions 5 and 43.
    Take a boot.bin from say nuvi 55 and you will find bootloader and x-loader copies inside it. Also you will find some function which references those copies and also contains proper region number constants.
    Code:
    Please Login or Register to see the links
    I think putting x-loader and bootloader inside boot.bin is a good idea, as it makes the x-loader and bootloader flashing procedure atomic.
    I.e., either boot.bin executes correctly and flashes x-loader and bootloader, or boot.bin fails and flashes nothing.
    Also I think it's a pretty standard practice in embedded systems world.
    As an example of a non-atomic procedure, imagine you're flashing bootloader over USB and USB connection fails. So bootloader is corrupt and it will never boot again most probably.

  11. #10
    Member
    Join Date
    May 2010
    Location
    None
    Posts
    16
    Rep Power
    0

    Default

    Another discovery.
    The region 15 are in effect the internal flash disk image.
    For Dakota 20 it start at address 0x520000 of the dumped rgn15 file and using the file with ImDisk using this starting offset, install a new hard disk on the PC where is possible to work fully and freely .....

 

 

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •