What's new
By:

Naomi dimm firm 4.02 direct flasheable binary file to chip

I can tell you that one of my Naomi boards doesn't detect dimms with 3.17+ firmware. Black screens confirmed.
 
2.13 net-only dimm to 4.02 via this method = bricked dimm.

I suspect putting original bios back wont fix it?
 
I supose if you flash back the original chip, you would be able to make it work again. Other thing is if in the process you have borken the dimm, all can be. I made a warning message for the possible errors that people could have.

I can assure that 4 dimms works with my method by my own hand.

Even I have a video where I made the extraction project and even the test with a new dimm directly flashed: https://www.youtube.com/watch?v=RLe9kyntqBw
 
Last edited:
penrhos said:
2.13 net-only dimm to 4.02 via this method = bricked dimm.

I suspect putting original bios back wont fix it?
Click to expand...
While my non-net dimm FW 1.02 flashed to 4.02 with this method didn’t “brick”, it also didn’t work correctly, would not load anything. I removed the flash chip and then flashed FW 3.17, which worked and proceeded to update to 4.02 with @Tylerdurden’s method.
 
if I go into dimm test mode I get a "timed out" error message.

I'll put 2.13 back and see it it works then.
 
Seeing the problems it may have with many people, I recomend first to do 3.17 flashing and after that 4.02 update via net dimm. I'm sorry to hear all about this
 
I don't think the cause related to firmware version(s), but more like to DIMM itself. in the end it is more than 15 years old piece of hardware, which may be broken in many ways.
 
MetalliC said:
I don't think the cause related to firmware version(s), but more like to DIMM itself. in the end it is >15 years old piece of hardware, which may be broken in many ways.
Click to expand...
I don't know either. It's a mistery. I haven't found yet a dimm which my binary causes brick.
 
tailsnic said:
Seeing the problems it may have with many people, I recomend first to do 3.17 flashing and after that 4.02 update via net dimm. I'm sorry to hear all about this
Click to expand...
I don’t know what the issue is with Non-Net Dimms, but they just aren’t as consistent as a Net Dimm when it comes to being stable/reliable with 4.02 firmware.
 
From 2.xx, you have to update to 3.17 or 4.01 before going to 4.02. Going right to 4.02 bricks the DIMM.
 
penrhos said:
if I go into dimm test mode I get a "timed out" error message.

I'll put 2.13 back and see it it works then.
Click to expand...
IIRC, my 2.13 DIMM didn't accept 3.17 when using transfergame.exe. I went to 4.01 instead with transfergame.exe. Then went to 4.02 with transfergame.exe.
 
let me do a bit of QA to make things clearer:

what is DIMM flash ROM binary ?
- it is 2Mbyte of data, where 1st Mbyte is original/stock firmware, and 2nd is updated firmware (might be same as 1st). each of halves have "magic" CRC32 - FFFFFFFFh

how firmware booting ?
- upon reset control go to very start of flash ROM, i.e. 1st/stock firmware, which is compute CRC32 of 2nd half of ROM, check if it equal to FFFFFFFF ? YES -> copy it to RAM and jump there, NO -> copy 1st half/stock firmware to RAM and run it

how firmware update works ?
- updater software code does: erase 2nd half of flash ROM (ONLY 2nd half!), write there 1Mbyte update binary.

sooo....
here is the question - how DIMM might become bricked after firmware update ? - obviously, if all hardware components is good, this can not happen. even if some junk data was written with update - CRC32 check will fail and original/stock half will be run. it might be bricked only in result of major hardware malfunction, more probable bad flash ROM chip.
 
I can't speak for naomi, but on chihiro, the upper 1MB is not fully updated. It only updates segaboot.xbe which is the bootup program showing the chihiro logo and containing the main test menu. Further, it updates firmware.bin and firmware2.bin which are the programs run on the baseboard 2 microcontrollers. Last, it updates firmware.asic which is the code run on an fpga implemented microcontroller that handles the dimm communication.

The first MB of the flash chip contains some resource files (like .wav files and font files) that don't exist in the second MB of it. So, it can run when only the first MB of the flash chip is intact, but not when only the second one is intact.

This doesn't mean your statement is incorrect, but there could be a difference in the way the settings are stored causing the newer firmwares to generate an exception. The older ones might get away with it and fix it for the later firmwares.

I am not saying this is what happens, but it could somewhat explain it. On chihiro, the settings are saved in an eeprom on the baseboard. Naomi might have such chip somewhere as well. This should however mean that the unit should work when it's connected to another naomi motherboard. (Maybe the chip that stores the settings for naomi is part of the dimm itself?)
 
@obcd we here talking about "Sega DIMM board" device, basically Hitachi SH-4 based microcomputer, which is used in NAOMI 1 and 2, as well as in Type-1 Chihiro and Triforce.
all said by me in previous post is same truth for all Naomi or (Type-1) Chihiro or Triforce.

obcd said:
Last, it updates firmware.asic which is the code run on an fpga implemented microcontroller that handles the dimm communication.
Click to expand...
in Type-2/3 Triforce and Chihiro whole "DIMM board" thing was replaced by simpler PCB with NEC V850 MCU (with DES encryption). firmware.asic is MCU internal firmware update, V850 code, DES encrypted, iirc using funny encryption key like 0x0022446688aaccee
I don't think this MCU implemented in FPGA, it also not handles DIMM comms, it IS whole DIMM-thing in term of game media storage and GD-ROM drive access (and there is also separate Network Board, AMD AU1500-based device).
 
Last edited:
I have tested today 3 more dimms.

In 2 cases, they have accepted the binary file.
In 1 case, black screen, even trying to solder a new chip with 3.17 firm. I have soldered back the original chip with 1.02 firmware.

So, we can say that there are mysterius dimms that doesn't accept a firmware update.
 
thanks for information.
do you noticed any difference between these PCBs or components ? RAM ICs maybe ?
 
They are the exact revision. I think that the problem is the aux chips. I think that they did a lot of main pcbs for base the netdimms. They probably come with an aux code that support de netdimm firmwares. What about if they did many new dimms with this new mobos with new code?
By this theory, the dimms not compatible are previus to the netdimm concept, so they were built with other proccessing codes. Think about it, if you put a conection PCB from a netdimm to a dimm mobo with 4.02, you obtain a netdimm, but there are this incompatibility cases. So let's think about this possibility.
 
Last edited:
You must log in or register to reply here.
Back
Top