Clear! Still a novice when it comes to modding FW which may have caused confusion on my part. A typo (41 versus 14) could not be excluded. Thanks for clarification. As mentioned, I'll be home after 1500 UTC, so will report back later.
Printable View
Clear! Still a novice when it comes to modding FW which may have caused confusion on my part. A typo (41 versus 14) could not be excluded. Thanks for clarification. As mentioned, I'll be home after 1500 UTC, so will report back later.
I performed the steps from post #4 combined with the instructions in post #11. The process went well, but had no effect on the problem. Content of the update.log file is as follows:
The unit rebooted twice. I suspect this is normal, as it reboots once as instructed by the command in the update.txt file and reboots again on detection of a missing rgn41 (?).Code:ž¥°â 2xx Series Software Version 3.00, UID: <10-digit>, HWID: <10-digit>
------------------------------------------------------------------------------
Parsing "ergn,41"
Success
Parsing "reboot"
Success
Anything else I can try? How about the suggestion by Neil in post #8?
Well, this kinda sucks. It should have recovered after taking this step.
Yes, try flashing gfwpack-ed fw_all.bin.
If it doesn't help, I would suggest dumping fw_all.bin with rrgn,14,1:/14.bin and comparing it to the flashed one.
From post #8:
The flash was successful, but it made no difference to the symptoms of the zumo.Quote:
Originally Posted by Neil [Only registered and activated users can see links. Click Here To Register...]
Well... not completely true. There is a difference in that the unit does not switch off anymore after 3 seconds when on battery power. It stays on now (still frozen on the Garmin splash screen) until switched off manually by pressing and holding the power button for more than 5 seconds.
I don't fully understand. There is a rgn14 in the unit which I can dump as described. What exactly do I compare it with?Quote:
Originally Posted by kunix [Only registered and activated users can see links. Click Here To Register...]
Edit 1:
I notice that since the above action, the zumo is not recognised anymore by the PC, WebUpdater or Garmin Express.
Edit 2:
Had to flash CURE FW into the unit via GarminCure3 and Updater.exe to get it recognised again by PC etc.
As one firmware mug to another, i'll try to help you understand to my limited extent, while kunix wrestles with some more advanced possibilities for your very sick unit. The dump of region 14 is the unit's firmware, i.e. fw_all.bin. Even though 14.bin may be quite a bit larger by a lot of FFs tacked on at the end, they otherwise should be the same before there. I think comparing them in hex to see if there are any other differences before the padded bytes will show whether fw_all.bin is being properly flashed.Quote:
Originally Posted by smokefree [Only registered and activated users can see links. Click Here To Register...]
Dump it and kunix will tell you what to do if the hex compares don't match. This might help you, HexCmp2:
Code:http://www.fairdell.com/
Please bear with me, but just to get things clear for myself, this is what I understand I am expected to do:
1. Since I flashed CURE FW after post #24, I assume this may have affected the fw_all.bin which I flashed in post #24. Am I correct in my assumption I need to flash the packed fw_all.bin again?
2. I then dump rgn14 as described and compare it in a hex editor to the packed fw_all.bin file. Correct?
SF, i'm waiting for kunix to answer you learnedly, but my horse-sense is that it's pointless comparing the packed fw_all.bin to the dump of 14.bin [whether dumped after either original, cure or packed fw_all flash] as the differences will be profound because of the packing regardless if the flash does complete or not.
It's only worth comparing the original fw_all.bin with the 14 dump obtained after the original fw_all has been flashed in my [uneducated] opinion. Best wait until kunix is back on-line, but if you want to do something now flash rgn made with original boot and original fw_all, then dump 14 again using patched boot.bin>rgn method.
Compare original fw_all.bin with new 14.bin, except for the trailing FFs in 14.bin they should be the same, if not then the flash didn't complete for sure i would think.
Neil, it does make sense to compare the fw_all.bin being flashed and the fw_all.bin dump, regardless if fw_all.bin is packed or not.
Unpacking is always made in RAM, after fw_all.bin is copied there from flash.
And by comparing fw_all.bin being flashed and dumped one we test the flash chip.
I've seen some flash chips not saving data to some blocks.
Actually It's better to compare the original fw_all.bin, as it's bigger and we can test more flash blocks.
OK, here's the result. I used the original (non-packed) fw_all.bin:
- As of offset 0081BF00, fw_all.bin is empty, where 14.bin contains only FF's up to and including offset 0087FFF0.
- The only real difference found, is in offset 00000010. fw_all.bin reads 0C 80 A0 E1, where 14.bin reads 0B 80 A0 E3. See screenshot below:
[Only registered and activated users can see links. Click Here To Register...]
This difference looks a bit like step 2 in post #4, but there 0C 80 A0 E1 in the original file is changed into 0C 80 A0 E3 (the 0C at the beginning is left unchanged there).
What does this indicate? How did the 0B end up inside 14.bin?
@kunix
Yes, much as i thought. Just one point though, SF posted this:
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?.Quote:
Originally Posted by smokefree [Only registered and activated users can see links. Click Here To Register...]
@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?