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?
Looking through the code is really interesting! I've always wondered how the code for these sorts of embedded devices worked (namely microwaves).
I recently went down that rabbit hole, just look up how often embedded devices use fixed-point arithmetic to compensate for the lack of FPU units on the chips.
  • vr46
  • ·
  • 2 hours ago
  • ·
  • [ - ]
I'm on the MD Discord and been following all of this, a bunch of us updated before the official launch and found a few bugs in the process, but the firmware itself is fabulous.
always wanted one of these models then prices skyrocketed. now there’s not much of a point as the primary novel feature, uploading, was reverse engineered for all other NetMD models (ones that take standard batteries and have screens that don’t burn-in), just need a WebUSB browser and go here: https://web.minidisc.wiki/
  • vr46
  • ·
  • 2 hours ago
  • ·
  • [ - ]
There's still bargains to be found, I (honestly) picked up a mint RH1 from Ebay for £180 last year.
I’m so glad Minidisc is having a resurgence. I don’t know if I’ll end up getting a MZ-RH1, but for the lucky folks who do, nice to see they’ll get some nice QoL upgrades!
> 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.

HSALF backwards reads FLASH but Sir68k is just a very diligent guy.
I have an MZ-RH10 lying around somewhere that would be neat to try working on.

Some folks have recently done screen replacements on those and that might be worth doing first.

  • vr46
  • ·
  • 2 hours ago
  • ·
  • [ - ]
Asivery screen replacement is great. Need some soldering skills but it's wonderful.