Welcome guest, is this your first visit? Click the "Create Account" button now to join.
Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 50
  1. #31
    Important User smokefree's Avatar
    Join Date
    Sep 2010
    Location
    @ home
    Age
    44
    Posts
    966
    Rep Power
    731

    Default

    Quote Originally Posted by Neil View Post
    It seems logical to me only by comparing 14 to the original [or unpacked] fw_all can there be a valid comparison. So in essence, whether the flash was done with original or packed fw_all, the compare of the dumped 14 has to be to the full [not packed] fw_all, is that right?
    ...which is what I mentioned in the first line of post #29.

  2.    Advertissements


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

    Default

    smokefree, you've compared the original fw_all.bin and a GarminCure3-ed fw_all.bin. GarminCure3's patch is a bit different from that boot.bin patch.
    Looks like the experiment was not 100% clean. Maybe it's a bad flash block which was "frozen" with GarminCure3-ed fw_all.bin piece. Or maybe it's your mistake.

    Can you make fw_all.bin full of 0x3E bytes with the size of the dumped 14.bin. Then flash it, then dump it, and compare the flashed one and the dumped one?
    It's not dangerous to flash garbage instead of fw_all.bin, you can always flash something else in pre-boot mode after.

    Quote Originally Posted by Neil View Post
    That's what i meant is pointless because the packed file will always differ when compared to the dumped 14. It seems logical to me only by comparing 14 to the original [or unpacked] fw_all can there be a valid comparison. So in essence, whether the flash was done with original or packed fw_all, the compare of the dumped 14 has to be to the full [not packed] fw_all, is that right?.
    Right.

    Quote Originally Posted by Neil View Post
    @both
    I'd have thought there should be no difference other that the empty padding at the end of the 14 dump. In a 265W i've removed the extraneous FFs and the fw_all and 14 bins are then identical in hex and hash check. Why should a zumo 220 be different? A fault?
    Yes, when the experiment is 100% clean, this would indicate a fault. We can overcome such faults if they are not too abundant.
    Last edited by kunix; 3rd November 2014 at 11:24 AM.

  4. #33
    Important User smokefree's Avatar
    Join Date
    Sep 2010
    Location
    @ home
    Age
    44
    Posts
    966
    Rep Power
    731

    Default

    Quote Originally Posted by kunix View Post
    Can you make fw_all.bin full of 0x3E bytes with the size of the dumped 14.bin. Then flash it, then dump it <...>
    New territory for me here. Could your request be translated as: "Replace the contents of the dumped 14.bin by 0x3E bytes, then flash it, then dump it <...>"?


    Edit:
    Have opened a copy of 14.bin in a hex editor. I did find the option to replace a string by another string, but have no clue as to how to replace the entire contents of the file with 0x3E bytes.
    Last edited by smokefree; 3rd November 2014 at 11:35 AM.

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

    Default

    I think all hex editors have a fill operation.

    UPD:
    I'm very kind today that's why I generated 128MB of 0x3E for you! You can cut it as you want and hope it's enough. Keep the change.
    [Only registered and activated users can see links. ]
    Last edited by kunix; 3rd November 2014 at 03:31 PM.

  6. #35
    Important User smokefree's Avatar
    Join Date
    Sep 2010
    Location
    @ home
    Age
    44
    Posts
    966
    Rep Power
    731

    Default

    Quote Originally Posted by kunix View Post
    I think all hex editors have a fill operation.
    Hardly ever used a hex editor, so was not aware of the "fill" function. I made a copy of the fw_all.bin file and replaced the contents with 0x3E, hence resulting in the exact same size as the original file.

    A new challenge came up however: immediately when the unit is brought into pre-boot mode, the screen shows LOADER LOADING and freezes there. Therefore I'm currently unable to flash anything. Even an hour later the screen still shows the same. FYI: the unit still has CURE FW inside.

    IJV3e1T


    Edit:
    The correct sequence of events is as follows:
    1. Updater.exe is standing-by to flash the tweaked fw_all.bin.
    2. The zumo is brought into pre-boot mode successfully. See screenshot below:

    5TeX6zs

    3. OK is clicked in the Updater.exe window.
    4. The "Updating Software In..." window is shown very briefly only. See screenshot below:

    gxH5WZ4

    5. Immediately after the above window is shown, it gets covered by another window, showing an error message from Updater.exe. See screenshot below.

    na5HkqK

    6. At the very same moment, the zumo shows LOADER LOADING and freezes. The display remains frozen after removing the USB cable. The unit has to be switched off manually.

    Note: I am able to flash CURE or ORIGINAL FW into the unit using GarminCure3 and Updater.exe. Just not this 0x3E version of fw_all.bin.
    Last edited by smokefree; 3rd November 2014 at 06:52 PM.

  7. #36
    Important User smokefree's Avatar
    Join Date
    Sep 2010
    Location
    @ home
    Age
    44
    Posts
    966
    Rep Power
    731

    Default

    If fw_all.bin IS 14.bin, would it not be an idea to correct the two bytes of the dumped 14.bin file in a hex editor so it is identical to the original fw_all.bin (except for having the FF's at the end) and flash it back into the zumo via microSD?

    I know how to modify the file in a hex editor. Just need the exact syntax how to flash rgn14 back via microSD.

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

    Default

    Have you just used a patched boot.bin for update.txt execution?
    Use the original one.

    The whole idea behind 0x3E is to locate the broken flash block. If you just change two bytes, you will only test 1 or 2 blocks, depending on the location of bytes.

  9. #38
    Important User smokefree's Avatar
    Join Date
    Sep 2010
    Location
    @ home
    Age
    44
    Posts
    966
    Rep Power
    731

    Default

    Quote Originally Posted by kunix View Post
    Have you just used a patched boot.bin for update.txt execution?
    Use the original one.
    The way I tried to flash the 0x3E version of fw_all.bin is by dragging and dropping it on Updater.exe and bringing the zumo into pre-boot mode. From post #8 I understood that is the way to do it. There was no boot.bin involved in my method. Do I understand correctly from your reply I should use the microSD method?

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

    Default

    Oh my..
    updater.exe expects you to feed him RGN file, which has some special structure and headers. I have no idea what happened when you fed him with this garbage
    You should have built an RGN file from the original boot.bin and this fw_all.bin.
    And actually I've just realized that RGN_Tool wouldn't allow this (it won't detect fw_all.bin's region. It's a stupid idea to detect regions by file contents, as it turns out).
    You would need makergn.exe or gfw.exe to build such RGN.

    So, yes, it's better to flash this file with update.txt with the following command: xrgn,14,1:/14.bin.
    Last edited by kunix; 3rd November 2014 at 08:21 PM.

  11. #40
    Important User smokefree's Avatar
    Join Date
    Sep 2010
    Location
    @ home
    Age
    44
    Posts
    966
    Rep Power
    731

    Default

    Quote Originally Posted by kunix View Post
    <...> it's better to flash this file with update.txt with the following command: xrgn,14,1:/14.bin.
    OK, but from post #1 (Edit 2) we know that the zumo does not read from the microSD voluntarily. I needed to perform the trick Neil described in post #4. Would that be the same procedure for this 0x3E version of 14.bin file?

 

 

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
  •