(SOLVED!) How to read and write mainboard Flash (Spansion S29GL)

[oscarboiro]

Hello!!

After some time with a lot of work, now i have time to return to my proyects.
im thinking from my problem to read flash in my NX with problem after stopped update.
is possible, when use a cd to update, erease a 95640WP EEPROM, and if casuality, when fail my update are erased and causes problems to write unit?
or i have a stupid idea? i dont possible write with a genuine segger.

[Go4IT]

The EEPROM does not seem to contain any reliable data. I've suspected it also, some time ago, but found that in a working unit it can be swapped by a new one without any data in it, and the unit boots and fills it up again. No clue what the radio needs this for...

[DGAlexandru]

I also bricked a NX DVD with a 5.3 update process.
It was using a very old firmware and I think it didn't like to jump directly to the last version and it hanged at the beginning of the update process - flashing "Main 1" written on the screen.

I had some previous JTAG experience with a MCA NX (SD card version and camera) so I wasn't worried of not being able to revive this DVD NX version.
The problem I was facing was that I couldn't connect to the OMAP CPU with J-Link and "standard" config for it. (It is a clone version - needed very fast when I bought it and after that stayed with it - so I thought this was the reason - also, others on web said they think this was the problem - but it was working with other NXs I was having around.
"Failed to disable MMU" "Failed to download the RAMCode" - same errors like oscarboiro

I looked "all over" the Internet for hints and I was able to find a guy who found a script made for other JTAG tool and who tried to port it to J-Link but didn't finis the job (on Segger's forum). With this script I was able to init the RAM and other registers for OMAP and was able to connect to the external FLASH (S29GL).
Before this script I was able to connect to OMAP only if I was disabling the external FLASH by removing it's power supply (small SMD inductor - L code) - OMAP has it's own BootLoader written to it and if it doesn't find the external FLASH to boot from, then you can read it's code by "normal" JTAG.
After connecting to it like this I reapplied power to the S29GL and tried to read it, but with no luck - OMAP's BL didn't have it initialized.

After using the script with J-Link and successfully connect to OMAP with external FLASH I've dumped the contents of the Flash and started to compare with other dumps to see what was wrong. The first thing I've noticed was that the BootLoader was bigger - after the "normal" bits, where all the others had FFs, this one had more data. This data was instructing the OMAP what to do during the update process and it was also responsible for the problem with "normal" JTAG J-Link script (it was moving the FLASH to another region and other type of access or even disabling JTAG access to it during FW update process).
I've put a dump from other working NX DVD, less the BL sector which was protected, and hoped for best . But it didn't worked as the BL had other things to do - it was still in the FW update mode. I then started to read the securing mechanism of the S29GL chip in order to understand how I can de-secure it. There were 2 modes: by secret key - sent by the CPU which was connected to it (OMAP in our case) or by a hardware pin. Only one mode can be active at a time. The secret key solution uses a 64bit "string" so it is very unlikely to brute-force it. I hoped that they used the hardware pin (WP) to have the Boot Sector locked and I was right!
The WP pin of S29GL is controlled by the OMAP CPU - it puts this S29GL input pin to GND as soon as it powers up. Having a FX board with OMAP, Flash and RAMs removed I was able to find the link between OMAP and Flash and used an Amphermeter to see how much current it drains if I put WP pin to a 3.3V supply. It was pretty big - 30 to 70mA (don't quite remember now ) which I didn't like so I looked to see if there is any kind of a SMD component that was part of this link and I found it - a 0 Ohm Resistor. I removed it, powered on the unit and I was able to erase and program also this sector of the S29GL flash chip. It wasn't necessary to apply 3.3V to the WP pin any more because this was done already by the design of the S29GL.

PS DO NOT FORGET TO FIRST DUMP AND SAVE AT LEAST SECTOR 507 AND THEN PUT IT BACK.
If you need a NX / FX full-dump or sector-dump any HW version, I can help (for free).

[DGAlexandru]

Another things I forgot to mention:

1. Put back the resistor after you flash Sector 0 = Boot sector of S29GL / BootLoader for OMAP CPU - in order to secure it from accidental rewirtes.
2. After you have your Flash written like this, be patient with first boot as it will update the V850 CPU - give it like 2 minutes (5 to make sure).
3. Your screen might give you wrong text messages as it still has older FW.
4. Do another FW update using a DVD/CD in DVD unit for NX DVD, CD for FX / NX SD... or SD for FX / NX SD - just to make sure that everything gets updated to the same FW level.

The EEPROM that is read by V850 CPU has nothing to do with the update. It only holds security information (number of PIN tries or if the PIN is active or not) and stored radio stations and I think it also holds Nav. history / saved locations.

[Go4IT]

Great job, Alex, i will try this! Writing the first sector is another think that puzzled me all the time. Shure the updater has the secrect key somewhere inside, but if we had a hardware way to do it, why not!?
And yes, you are right. The /WP signal of the Flash goes through a 0 Ohm resistor (R5827) directly to /EMIFS_WP (pin AF3) of the OMAP. The measure point you show is MP_5841.

[Go4IT]

Ok, i can confirm that it's working Once you removed the "/WP-Resistor" from the board, you can also erase and overwrite des first sector of the Flash

navi-nx_mainboard_explained_top.jpg

The unit will also drive normally if the resistor keeps removed, but as soon as you're done you should replace it, of course.
Now, we have a way to manipulate the bootloader, which will become handy some time.
I wonder if this could not also be done by pure software. The /EMIFS_WP pin may be controllable by manipulating IO-Registers of the OMAP and we could add it to the J-Flash init procedure like i did it for the Watchdog disable?!

Oh, i also got many dumps. Maybe we can build a database of it? Unfortunately this forum does not have a filebase, any ideas?

[Go4IT]

The EEPROM that is read by V850 CPU has nothing to do with the update. It only holds security information (number of PIN tries or if the PIN is active or not) and stored radio stations and I think it also holds Nav. history / saved locations.

You may be true about the protection, havn't testet this. So if i change from PIN to unsecure boot it may only change one Bit of the EEPROM? Let's see if i can find this out. For the others you are right, as you can look into the contents.

[Go4IT]

OMAP has it's own BootLoader written to it and if it doesn't find the external FLASH to boot from, then you can read it's code by "normal" JTAG.

That sounds interesting! Yes, there is ROM inside the OMAP with the "first stage bootloder" (PBL), which i would disassemble if i can get my hands on it. Have you a copy of the code? Which addresses do you read back to get it?

[DGAlexandru]

If you remove 3.3V VCC from Flash (remove the 0 OHM Resistor) then you can read it yourself from 0x000000000 address - as you would normally read the Flash.
I didn't saved OMAPS's own BootLoader, but if you want it, I can dump it from different versions of BP FX and NX (DVD or SD version).

On my previous post I said it is a SMD inductor here.. but on this PCB I see it is a Resistor. Anyway, just remove it to disable powering the Flash - S29GL and also the Nav Flash - SAMSUNG K9F1208U0C which is on the other side of the PCB.

[Go4IT]

Thanks for pointing this out. I managed to download it, like you said and here it is (see attachment).
I also added a disassembly.
In the mode without Flash i started the OMAP and halt the CPU, then single stepped. It loops endlessly in function "loc_104".
But the analysis of the bootloader should give us more insight what's going on prior to boot, which memory layout the OMAP uses and so on.