Random Chihiro Type-3 Info Thread

[whatnot]

There's actually 2 other RS232 RTX exposed on the DB9 connector, as well as, 2 *additional* RS232 RX, it's very odd.. I was not able to get any IO at all from the 2 full sets, and RX3/4 appeared to go into the 3rd ADM3222 device, however, the transmit pins that would send the data to the media CPU seem NC or perhaps a berried via.

IC10:R2i, RX, TX, IC9:T2o, GND
IC9:R2i, IC9:T1o, IC9:R1i, IC10:R1i

 

[whatnot]

Just documenting some undocumented jumpers on the base board.

The 6 jumpers on the board are actually for controlling the D-Terminal settings, this would only be useful if you have a monitor/TV which abides by the reported settings on a D-Terminal input.

JP3S & JP4S control line count
JP5S & JP6S control refresh
JP7S & JP8S control wide screen vs. letterbox.

The unpopulated JP1S I'm still a little confused about.

Pin 1 is connected to PA5/FRD# on QC
Pin 2 is connected to DIP5 on the filterboard (manual calls this "Serial selected")
Pin 3 is connected to PC7/RD# on SC

By default it's connected jumpered with a 0ohm resistor 2 & 3.

 

[whatnot]

Figured out the checksum method they used with the net firmware and can produce flashable packages with it.

My motivation for this was Gundam Battle Operating Simulator actually requires a specific firmware version and wont run without it, however, they actually check if the version is NULL before making that check, and if it is null it skips the check. What this means is we don't have to edit the game which would require a hacked kernel that doesn't check game signatures. I haven't checked yet, but I imagine it's similar with other games which check the version (being that if NULL it skips checks), alternatively I could just set it to be what Gundam requires.

I'll give it to anyone interested.

 

[MetalliC]

Figured out the checksum method they used with the net firmware

let me guess: it's standard CRC32 and result should be 0xFFFFFFFF ? Sega used this method in many devices, like DIMM and others.

 

[whatnot]

let me guess: it's standard CRC32 and result should be 0xFFFFFFFF ? Sega used this method in many devices, like DIMM and others.

They only really check it when writing from the factory tool -- if you remove the flash and write it there it's not checked by the MIPS proc. But it's just CRC32 then inverted lol.

 

[MetalliC]

They only really check it when writing from the factory tool

are you sure?
usually Sega used flash ROM x2 size of actual firmware, 1st half of it contains original/stock firmware, 2nd half contain updated version of it.
at boot it does calculate CRC32 of 2nd half, and if it valid (i.e. there is valid newer firmware) - will run it
otherwise will be run original firmware from 1st half, stock one

and yes, if you manually write to 1st half of flash chip some firmware and leave 2nd half empty - it will boot no matter if it have valid CRC or not.

 

[whatnot]

are you sure?
usually Sega used flash ROM x2 size of actual firmware, 1st half of it contains original/stock firmware, 2nd half contain updated version of it.
at boot it does calculate CRC32 of 2nd half, and if it valid (i.e. there is valid newer firmware) - will run it
otherwise will be run original firmware from 1st half, stock one

and yes, if you manually write to 1st half of flash chip some firmware and leave 2nd half empty - it will boot no matter if it have valid CRC or not.

I'm talking about the type-3 net board, not media board. Yes, it has 2 revisions on the flash, but it's only accessible via the jumper I documented earlier in the thread.

 

[MetalliC]

I'm talking about the type-3 net board, not media board.

me too. awhile ago I've RE'd SystemSP net board, MIPS-based device, basically same thing as Chihiro Type-3 net.bd, and its code works exactly like I've explained above.

Yes, it has 2 revisions on the flash, but it's only accessible via the jumper I documented earlier in the thread.

I'd bet mentioned jumper simply connect flash ROM's most significant address line to GND, effectively forcing it to boot firmware from 1st half of ROM.

will grab some Chihiro netbd firmware and will check it in a few...

add: yes, it's same, in boot/crc part at least.

 

[whatnot]

add: yes, it's same, in boot/crc part at least.

I'm not great with actual RE, but I'd love for some tips with getting IDA or Ghidra to xref to text section... On either the V850 ASIC or the MIPS on the net board. I even went as far as getting up the virtual sections on the V850 and *nothing* was getting referenced in terms of strings in the ROMs.

 

[MetalliC]

it's embedded device ROM, not PE or ELF file, there is no any sections, you have to manually add regions to memory map for ROM, RAM, some MMIO etc
in case of net.board - select MIPS LE CPU type, then load ROM at 0xbfc00000 and start checking its code. soon you'll see it's copying itself to RAM at 0x80010000, so you'll add 8MB RAM at 0x80000000, then load copy of ROM at 0x80010000 and continue RE it there.
as of V850 firmware - it's DES encrypted, probably that's why you see there no text strings or anything meaningful

 

[whatnot]

as of V850 firmware - it's DES encrypted, probably that's why you see there no text strings or anything meaningful

I'm aware, and I'm aware of it's weird read 8 bytes, dec, flip thing. The hack for Chihiro is interesting, just a single byte change, the second byte was in the interrupt section(?) didn't look much further.

in case of net.board - select MIPS LE CPU type, then load ROM at 0xbfc00000 and start checking its code. soon you'll see it's copying itself to RAM at 0x80010000, so you'll add 8MB RAM at 0x80000000, then load copy of ROM at 0x80010000 and continue RE it there.

Good to know, thanks! Yea, I loaded it at the reset for Alchemy, made the virtual sections and identified, you know.. like initializing registers for the interfaces and what not, but past that I couldn't follow much. Helpful to know it ends up copying itself and that's probably why.

EDIT: Thanks, yea, in FUN_bfc0085 is where it sets that all up then jumps to it. Nice

 

[ForestOfDreams]

So if you were to flash this firmware you can run all games including gundam?

 

[whatnot]

So if you were to flash this firmware you can run all games including gundam?

I haven't went and looked at what other games actually do, but as far as I can tell Gundam is the only one that actually requires a specific version, rather than checking if the version is over X.

https://installgentoo.net/~wutno/sum/FACTORYCHECKXB.512_hacked.BIN

When you boot into the updater, hold down test & service on the filterboard -- must be on the filter board. You should see (FORCE) in the top right, if you don't it wont update.

 

[MetalliC]

EDIT: Thanks, yea, in FUN_bfc0085 is where it sets that all up then jumps to it. Nice

you mean FUN_bfc00850 ? yes, that's it

void FUN_bfc00850(undefined4 param_1)

{
int crc_result;

crc_result = crc_check();
if (crc_result == 0) {
memcpy(&DAT_bfd00000,(void *)0xa0010000,0x40000);
}
else {
memcpy(&DAT_bfc00000,(void *)0xa0010000,0x40000);
}
/* jump to RAM */
FUN_80011b9c(param_1);
return;
}

and jumper seems does kind of "emergency boot" mode, which cut ROM high address line and force to run stock firmware from 1st half of ROM.
I'd guess that jumper was made for the cases if board was updated with some crappy binary which had valid CRC, and bricked it.