Trying to unbrick a zumo 220

**smokefree** · 2nd November 2014, 12:59 PM

Originally Posted by kunix

no need to erase fw_all.bin. However, if the flash chip is broken, then erasing/writing any region (including region 14, containing fw_all.bin) can help reveal the chip failure.

Please clarify if fw_all.bin is included in rgn41 or rgn14.
Post 11 tells me to erase rgn41, not rgn14.

**kunix** · 2nd November 2014, 01:10 PM

NV is inside region 41. fw_all.bin is inside region 14. There is no mistake.
I asked you to erase region 41.
And I didn't ask you to erase region 14.

**smokefree** · 2nd November 2014, 01:24 PM

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.

**smokefree** · 2nd November 2014, 04:27 PM

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:

Code:

Please Login or Register to see the links

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 (?).

Anything else I can try? How about the suggestion by Neil in post #8?

**kunix** · 2nd November 2014, 04:44 PM

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.

**smokefree** · 2nd November 2014, 09:23 PM

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?

**Neil** · 3rd November 2014, 11:04 AM

@kunix
Yes, much as i thought. Just one point though, SF posted this:

Originally Posted by smokefree

........
2. I then dump rgn14 as described and compare it in a hex editor to the packed fw_all.bin file. Correct?

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?.

@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?

**kunix** · 3rd November 2014, 11:18 AM

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.

Originally Posted by Neil

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.

Originally Posted by Neil

@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.

**smokefree** · 3rd November 2014, 11:30 AM

Originally Posted by kunix

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.

**Neil** · 3rd November 2014, 10:06 AM

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.

Thread: Trying to unbrick a zumo 220

Thread Tools

Display

Hybrid View

Advertissements

Bookmarks

Bookmarks

Posting Permissions