Live data from Hacker News

Custom Firmware for the MZ-RH1 – Ready for Testing

sir68k.re

11–20 of 23 posts

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#11

> discovered a boot ROM mode that can be enabled by bridging two GPIO lines on the mainboard (HSALF / TP8232 / R853 and WDT / SL901) to ground How do you even find something like this?

HSALF backwards reads FLASH but Sir68k is just a very diligent guy.

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#12

> discovered a boot ROM mode that can be enabled by bridging two GPIO lines on the mainboard (HSALF / TP8232 / R853 and WDT / SL901) to ground How do you even find something like this?

A lot of reverse engineering and guesswork actually!

One of the parts when writing a extensions for a device from which you've only extract a firmware blob from memory space is to understand as much as possible from the memory layout, and possible memory mappings. With HiMD MiniDisc recorders, they don't just have to bring up the MCU on boot, but also the VME (Virtual Mobile Engine / DSP).

As such, during my investigation I found a bit of code mapped to an unknown memory area 0x0081_0000. It contained what seemed to be a vector table, code for bootstrapping the system, and then some USB code with a small protocol to do some debug operations. The code was written as it was supposed to live at address 0x00 (which is where the Flash is mapped to in normal conditions).

As such, to me this seemed to clearly be a bootrom that could be activated in some condition. The question was, how?

Sony has always been protective of their hardware, and as such they have been careful in the service manual documentation of their NetMD/HiMD devices and renamed any pin/pad that could be potentially dangerous (as in, giving more control to users than they should have). Of course, if you look for nonsensical names, that brings you directly to the interesting pins :) That's how I isolated JTAG (though figuring out how to get it working and the right pinout was another story). The HSALF pin stood out as well, somehow I sort-of recognised the name, but I did not know how until I realised it stood for FLASH in reverse. Basically, it was pulled up, activating the flash. Pulling it down activated the bootrom.

The other pin that has to be bridged is related to the power IC. If not asserted by the MCU it will shut off. In bootrom mode or JTAG the MCU will not do this, so you need to force the power IC to stay alive.

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#13
Really nice project – respect :) Finding that boot ROM mode by bridging GPIO lines is a great catch. Having a hardwired 'safety net' makes custom firmware projects much more viable. When you were testing the flasher, did you find the CXD2687's flash interface to be deterministic in its failure modes, or did you run into any race conditions/timing issues during the erase/write cycles?

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#14
post #12

> discovered a boot ROM mode that can be enabled by bridging two GPIO lines on the mainboard (HSALF / TP8232 / R853 and WDT / SL901) to ground How do you even find something like this?

A lot of reverse engineering and guesswork actually! One of the parts when writing a extensions for a device from which you've only extract a firmware blob from memory space is to understand as much as possible from the memory layout, and possible memory mappings. With HiMD MiniDisc recorders, they don't just have to bring up the MCU on boot, but also the VME (Virtual Mobile Engine / DSP). As such, during my investig…

Very interesting!

> As such, during my investigation I found a bit of code mapped to an unknown memory area 0x0081_0000. It contained what seemed to be a vector table, code for bootstrapping the system, and then some USB code with a small protocol to do some debug operations. The code was written as it was supposed to live at address 0x00 (which is where the Flash is mapped to in normal conditions).

Is this something you can pattern-match directly from the assembly, or was this dis-assembled to C or so?

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#15
post #12

Earlier quoted context omitted.

A lot of reverse engineering and guesswork actually! One of the parts when writing a extensions for a device from which you've only extract a firmware blob from memory space is to understand as much as possible from the memory layout, and possible memory mappings. With HiMD MiniDisc recorders, they don't just have to bring up the MCU on boot, but also the VME (Virtual Mobile Engine / DSP). As such, during my investig…

Very interesting! > As such, during my investigation I found a bit of code mapped to an unknown memory area 0x0081_0000. It contained what seemed to be a vector table, code for bootstrapping the system, and then some USB code with a small protocol to do some debug operations. The code was written as it was supposed to live at address 0x00 (which is where the Flash is mapped to in normal conditions). Is this something…

Finding the memory area involves running code on the device that scans the entire memory range (catching data aborts where needed).

As for figuring out what the code does, it's a combination of staring at the hex, disassembly and semi de-compiled code.

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#16
post #13

Really nice project – respect :) Finding that boot ROM mode by bridging GPIO lines is a great catch. Having a hardwired 'safety net' makes custom firmware projects much more viable. When you were testing the flasher, did you find the CXD2687's flash interface to be deterministic in its failure modes, or did you run into any race conditions/timing issues during the erase/write cycles?

Thanks! The main problem I had was conflicts with the 'patch' peripheral during the erase/write. This peripheral allows for a small virtual overlay in memory space. It was used in previous devices to fix small bugs by overwriting a couple of words in the ROM. As all the flashing code needs to live in SRAM during flashing, the vector table needs to be patched to point to the code in SRAM. During the erase/write cycle you need to poll the values on certain addresses to figure out success - and if you haven't correctly disabled the patch overlay that can go wrong. That was how I got my first brick :)

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#17
post #16
post #13

Really nice project – respect :) Finding that boot ROM mode by bridging GPIO lines is a great catch. Having a hardwired 'safety net' makes custom firmware projects much more viable. When you were testing the flasher, did you find the CXD2687's flash interface to be deterministic in its failure modes, or did you run into any race conditions/timing issues during the erase/write cycles?

Thanks! The main problem I had was conflicts with the 'patch' peripheral during the erase/write. This peripheral allows for a small virtual overlay in memory space. It was used in previous devices to fix small bugs by overwriting a couple of words in the ROM. As all the flashing code needs to live in SRAM during flashing, the vector table needs to be patched to point to the code in SRAM. During the erase/write cycle…

Thanks! Does it mean I can now upload tracks to the mz-rh1 without using their ugly piece of software? Or is this still impossible due to the use of cryptographic keys?

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#19
post #17
post #16

Earlier quoted context omitted.

Thanks! The main problem I had was conflicts with the 'patch' peripheral during the erase/write. This peripheral allows for a small virtual overlay in memory space. It was used in previous devices to fix small bugs by overwriting a couple of words in the ROM. As all the flashing code needs to live in SRAM during flashing, the vector table needs to be patched to point to the code in SRAM. During the erase/write cycle…

Thanks! Does it mean I can now upload tracks to the mz-rh1 without using their ugly piece of software? Or is this still impossible due to the use of cryptographic keys?

The firmware in a sense does not change anything regarding connectivity (for now). If you want to record normal MD, just use Web MiniDisc Pro. For HiMD, I recommend the Electron version of Web MiniDisc Pro, but it's not yet as stable as SonicStage (due to the complixity of Sony's system).

Re: Custom Firmware for the MZ-RH1 – Ready for Testing

#20

Why is MiniDisc having a come back nowadys?

It's a great combination of physical and digital. Similar to vinyl records, having a resurgence, MiniDisc really stands out as a very good portable physical solution:

- MiniDiscs are easier to write/re-write than CDs if you have a NetMD capable device, just load up https://web.minidisc.wiki/ in your browser and MP3s will get converted for the disc. - Smaller and more robust than CDs - Feels very "RetroFuturistic" compared to cassettes and records, if MP3 players hadn't taken off, it could have easily been the next big format

Post reply on HN