Hi,
This is slightly off-topic, but given that the gmapsupp.img is a FAT
file system, someone on this list might know the answer.
Around March 10, the internal file system in my Garmin Edge 705 could no
longer be mounted by Linux. I was also unable to convert saved tracks
into training runs, which I guess means that the Garmin firmware failed
to read the file system as well. Also the base map (gmapbmap.img) failed
to load. So, currently the Edge 705 is crippled in that I can see the
gmapsupp.img that is on the SD card, but cannot save any tracks.
I saved the entire 1GB image from the device to my computer. There is
about 23 MB of nonzero data followed by zero bytes. The actual payload
may be smaller. It looks like the "boot" sector and all of FAT1 and most
of FAT2 are zeroed out.
From two Edge 705 users, I got file system dumps. One is from a 512MB
model and another is from a 1GB model. Both appear to be further from
pristine condition than my file system. I have only created and deleted
*.tcx files (saved GPS tracks) and a gupdate.gcd (firmware update). On a
copy of my backup image, I already tried replacing the FATs from one of
the other dumps, but every combination would cause some important files
to be truncated by dosfsck.
Because I do not know if there are any unit-specific data stored in the
file system, I would like to fix with as small changes as possible. This
would mean rewriting only the "boot" sector and the two FATs. Everything
starting with the root directory (apparently it is a FAT16 created by
mkdosfs) looks intact.
Any hints? How could I use dff or some other tool to reconstruct the
file allocation tables? Is there a good presentation of the FAT16 file
allocation table format somewhere, so that I could try to interpret the
tables in a hex editor? Or is there a Linux tool for visualizing or
pretty-printing the file allocation tables?
Marko
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
