Missing commands

[GXTX]

0x00 0x80555bd0 (DP): NOP command.
0x01 0x80555bd0 (DP): START-UP command.
0x02 0x80555bd0 (DP): HEALTH-CHECK command.
0x03 0x80555bd0 (DP): LOST-PACKET command.
0x04 <something is here but system reboots too quickly to print over serial>
0x05 0x80555bd0 (DP): REQUEST FOR DIMM command.
0x06 0x80555bd0 (DP): TRANSFER-CANCEL command.
0x07 0x80555bd0 (DP): HOST-MODE command.
0x08 0x80555bd0 (DP): DIMM-MODE command
0x09 0x80555bd0 (DP): TERMINATE command.
0x0A 0x80555bd0 (DP): HOST-RESTART command.
0x0B 0x80555bd0 (DP): WRITE TO FLASH command.
0x0C 0x80555bd0 (DP): WRITE EEPROM command.
0x0D 0x80555bd0 (DP): READ EEPROM command.
0x10 0x80555bd0 (DP): PEEK-HOST command.
0x11 0x80555bd0 (DP): POKE-HOST command.
0x14 0x80555bd0 (DP): ENABLE OFF-LINE command.
0x15 0x80555bd0 (DP): DISABLE OFF-LINE command.
0x16 0x80555bd0 (DP): GET COIN-INFORMATION command.
0x17 0x80555bd0 (DP): SET LIMIT-TIME command.
0x18 0x80555bd0 (DP): GET DIMM-INFORMATION command.
0x19 0x80555bd0 (DP): SET DIMM-INFORMATION command.
0x1E 0x80555bd0 (DP): GET Netfirm-Info command.
0x1F 0x80555bd0 (DP): RESET FIRM command.
0x20 0x80555bd0 (DP): 2NDBOOT UPDATE command. <killed my mediaboard>
0x21 0x8054fac0 (DP): MEDIA FORMAT command.
0x25 0x8054fac0 (DP): Set Media-Information command.
0x7F 0x8054fac0 (DP): SET SECURITY-KEYCODE command.
0xF0 0x8054fac0 (DP): PeekHost16 command.
0xF1 0x8054fac0 (DP): PokeHost16 command.
0xF2 0x8054fac0 (DP): ControlRead command.

For science I killed one of my Type-3 Chihiro media boards. These were issued with Ver13.05.bin firmware.

[DragonMinded]

From digging at the 3.17 firmware a lot of those don't exist in the handler, and some of them do but only have functionality gated to Triforce/Chihiro. Did you reverse a different firmware to get them? Maybe 4.01? Essentially, can you describe your fact-finding for posterity, it helps me to understand the net dimm more and give insight into other vectors of understanding.

[DragonMinded]

Ah, I see you claim 13.05, Not familiar with that revision, it must be a Chihiro firmware that includes a netdimm version? What version does the netdimm in it report when you ask it for info using netdimm_info?

[GXTX]

My method was quite crude, I simply edited your script to issue the commands 0x00~0xFF and watched the serial output of the net board.

The media board firmware is the hacked firmware (4.00?), and the net board firmware is 13.05 (although it has a set of jumpers to use a backup 11.0X version).

Ftr, I was just able to recover my mediaboard. Chihiro's flash has 2 segaboots, one being a backup 0.85, in this state it will only boot the firmware update tool.

[GXTX]

Oh by the way. I have a thread on AP with some random info about Chihiro Type-3, perhaps you'd be interested. Has serial logs from the netboard in the first post.

https://www.arcade-projects.com/threads/random-chihiro-type-3-info-thread.13466/

[DragonMinded]

Ah yeah, I was using the debug serial to try to RE the internet IOCTLs to try to add network support to Naomi homebrew games.

[GXTX]

Perhaps you'd be interested in my 2nd post, I'm fairly certain there's a dev net firmware for Type-1's in the firmware update util for Chihiro. See: main.0317xd, has some interesting strings compared to it's counterpart main.0317 and never gets flashed.

[DragonMinded]

Possibly it would help. I'm like 200% sure that my mis-handling of the control response is the root of all of my IOCTL troubles. I'm pretty sure the structure pointed at by that is where the netdimm reads params for IOCTLs and writes responses. The style of code they used for the Naomi BIOS as well as the netdimm, however, uses a lot of code pointers and as a result Ghidra struggles. Also, MAME does HLE of the netdimm board so watching traffic between the two isn't really possible. Maybe I'll figure it out someday.

[GXTX]

So coming back to this... I personally find it easier to work with C++ so I rewrote this and extended to my needs. https://gist.github.com/GXTX/1ece7ba9449cfa7094682c1035f52da6

There's actually a hidden command at 0x22, and from my testing I think I finally understand it...

It seems like it's a 0x04 but causes the Mediaboard to erase the entire contents of the RAM before writing it's contents.

I confirmed this by:

• Download address 0x0~0x80
• Issue 0x22 with an offset of 0x0 and data (0xAA55AA55)
• Download address 0x0~0x80

The original download request will have what ever contents were stored in RAM (aka random garbage on a bootup), the second will only contain 0xAA55AA55 and then 00's for the remaining 0x7C bytes.

[GXTX]

Bit more poking around with the commands. A fair few are just NOP, at least on Chihiro. Updated list.

https://gist.github.com/GXTX/1ece7ba9449cfa7094682c1035f52da6#file-a-cpp-L43

Also documented the DIMM_MODE stuff for Chihiro. It appears that it only spawns some type of "Coin" thread.

[GXTX]

Documented and tested out both WRITE_TO_FLASH & 2NDBOOT_UPDATE.

https://gist.github.com/GXTX/1ece7ba9449cfa7094682c1035f52da6/revisions

Still unsure of 0x22, appears to have a max offset of 0x100000? Did you play around with this at all @DragonMinded ?

[DragonMinded]

No I didn't. My focus was mostly on reverse engineering the state management and control stuff so that I could have kiosk mode working flawlessly, port a gdb stub to my libnaomi library for on-target debugging and also allow PC->homebrew and homebrew->PC communication for the on screen menu.