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