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.

 

[telmnstr]

The mediaboard dump available online is a filesystem structured like this.

segaboot.xbe      : 0
Textures.xpr      : A0000
FontProp.xpr      : B1000
FontFixed.xpr     : C2000
firmware.asic     : E4000
firmware.bin      : FC000
firmware2.bin     : FE000
unk.              : FFE00
segaboot.xbe      : 100000
dsstdfx.bin       : 1BC000
xbox_ac.wav       : 1C3000
tone.wav          : 1E3800
unk_firmware.asic : 1E4000
unk_firmware2.bin : 1FE000

Hello! I was flashing my Chihiros for CF upgrades the other day and one of them went south during the update. The system rebooted itself during some flashing, and at this point the media board no longer communicates with main board (Error 22.)

Any idea if I were to copy the TSOP flash IC from a working unit, copy it and replace it on the failed unit if it would work?

I was able to swap media/ethernet boards and successfully flashed the mainboard of the unit that failed.

I see there is multiple asic firmware files in the list, hopefully that is loaded in every boot and not flashed into ASIC?

 

[MetalliC]

@telmnstr media board firmware is inside of large Sega ASIC, there is no known to me way somehow manually reprogram it.

TSOP flash ROM iirc is segaboot. that's the code which shows you test mode screens, and it's fine if you see them.

 

[whatnot]

TSOP on the mediaboard is a "filesystem" as described above. "firmware.asic" & "unk_firmware.asic" is what gets run on the asic.

 

[telmnstr]

@telmnstr media board firmware is inside of large Sega ASIC, there is no known to me way somehow manually reprogram it.

TSOP flash ROM iirc is segaboot. that's the code which shows you test mode screens, and it's fine if you see them.

Yea, that is strange. I was thinking the files in that directory sound like boot splash screen and I get the splash screen and then it fails with a media board comms error. I can go into menu, but under System Info it shows comms error again.

Any idea if the .asic files are used every boot? Like it programs FPGA inside ASIC with that data every startup and if it's corrupted board no communicate?

 

[MetalliC]

Any idea if the .asic files are used every boot? Like it programs FPGA inside ASIC with that data every startup and if it's corrupted board no communicate?

you've been already told - firmware programmed inside of ASIC (NEC V850 CPU with flash), and there is no known ways to manually reprogram it.

for sure there should be the way to (re)program it, for case when new PCB was manufactured at factory and ASIC have no any firmware yet. but, it's unknown. good luck trying to contact Sega and ask how to do that

 

[telmnstr]

you've been already told - firmware programmed inside of ASIC (NEC V850 CPU with flash), and there is no known ways to manually reprogram it.

for sure there should be the way to (re)program it, for case when new PCB was manufactured at factory and ASIC have no any firmware yet. but, it's unknown. good luck trying to contact Sega and ask how to do that

Derp, sorry lots of fires in the oven switching between lots of hardware repairs/game repairs and missed that above..

Looks like I will try to replace the bad 168 DIMM socket on the other media board If that goes bad then I'll just buy a replacement media board but hoping to avoid that. Wrote out CF cards and they work great, so that will save some dreamcasts.

Thanks for all the info, will donate some bucks to the forum.