[JasonACT]

Had a look at a few things today...

I've been trying to work out how the first partition is set up on these things, there's a QNX utility (etfsctl) which is meant to be able to dump raw and etfs filesystems. I've used it to back-up the 2nd file system on all 3 of my working devices (the filesystem I can write to, with all the Ford packages) but it just won't read the 1st partition - says "Error status on option 'R': Invalid argument".

I disassembled the utility, checked out what it was doing (in case SWSA had bodged it up) but it all seems like it should work. Not much on the Internet either.

I went back to the broken board, researching how I can get files into it somehow, maybe with the bluetooth serial port (now that the chip is gone). I didn't get far, I'll need to work out how to kill the master-control that keeps restarting things when they die. Then work out how to receive a certain number of bytes and close the file - seems like a tall order.

I did start to look at some of the symbols that were corrupt on the unit - turns out the corruption was in the qnx libraries (file: libph.so.3) which is one of the larger ones being 1MB in size. Only the ACM and media-player load it - so my issue with the USB not mounting isn't that (I don't think).

There's quite a lot of USB utilities on this device, and I think I've run them all on both the working unit and the broken one. There doesn't seem to be much difference. The control registers of the chip I replaced are being read back as exactly the same (vendor/model/setup) so I assume it's good. One thing though, it says device disabled (one of the registers I can read) but it all comes good when I pull out the usb stick and plug it back again - everything says the same then - but no mounted filesystem and no hd0 device available to do so.

Ok, getting nowhere, I looked at the stupid nav screen on startup.. Press "Accept" to continue. I found the zip file with a file with the text - I removed it... Still got the dialog but with the message "Error loading file: i18n/drive_carefully.xhtml"! Damn, wouldn't it be nice for it to just say, it's not there, I don't need to show this dialog? I may keep looking into this - but I don't want to break pop-ups before I get the new maps.

On to the FPV dials. There's a small FPV exe that runs, seems to take care of the car-status messages and moving graphics. But, there's a really large package (hmi ~ 80MB) that has all the pointers to the graphics files that need to be accessed. This thing seems to take care of all the themes too, and USB updating, and others. The non-sat-nav units have about 2.5MB free on the flash memory - so I don't think there's any chance to get FPV dials working now. I'm also hesitant to try and move this huge package onto the sat-nav unit with the old firmware. Hmm.

Back to the 1st partition again, really drilling down into things now.. There's a "core-pkg" that has everything to rebuild this, including another app called "nandWrite". I can see the scripts that do it (and comments from the author - "replace the running NAND driver while in the middle of an update -- scary!!!" - thanks for that SWSA).

I ran that program in reverse (there's a couple of commands when programming the flash to unlock partition 1 and relock it at the end - so I wasn't so scared I would do any harm). It only reads in blocks (so it will pad files which are less than a block with a given character if needed - but I was reading from the flash block device - so I didn't need that). I didn't specify the verify option either, I just want to throw away the extra ECC bytes on the flash. And, wow, I got 4 files out of the flash at partition 1 using the 4 commands in reverse from the update script.

So, it puts the boot program in at position 0 (and the flash chips are meant to be guaranteed to be good on that sector). It then puts 3 copies of the boot file system in 3 locations further along (I assume the boot loader will do a checksum and move on to the next if it fails to load). So that's good news, with the boot partition, there's lots of redundancy.

And what I got (other than being slightly longer than the 2 files in the package on partition 2) was an exact match on the boot sector file and boot filesystem.

I'd give these units a really good chance of being able to be rebuilt (if you've got the files to do so - and the USB hardware hasn't died on you).