Looking for a way to program a NAND Flash

Are they all Fujitsu MB91302A MCUs? The DVRP on mine is a Fujitsu MB91302A.

l_Oliveira has done experiments with the firmware of the SCPH-20401 and got some success with creating his own clone of the SCPH-20401... but, that is out of the reach of most people because HDD firmware modding is very difficult and isn't possible for every disk (partly because the firmware and flashing tool are not released for a lot of them).

We've thought of two possible solutions: the DVRP firmware could be attacked and compromised, or a special adaptor that emulates the SCPH-20401 could be created.

There's no FHDB installation for the PSX because that would overwrite the XMB, trashing the PSX's value forever.

The DVRP isn't locking anything out. It's just probably causing things to break down because the running software waits for the DEV9 (Or maybe just the ATA part of the SPEED) interface to become ready... which never does. Which is why FMCB will boot, but then it gets stuck (since it does load ATAD eventually)

 

Could you modify it to not do so ? Or maybe to timeout/give-up on error ?

Faulty PSX units would be still pretty usable if you could do that.

 

With the hdd, I ment install FMCB on a ps2 HDD and copy the files off the ps2 hdd onto the PSX NAND.

i wonder what happens if the DVRP just isn't there?

Are instructions for the MB91302A all on chip? if so, would it be easer to replace the MB91302A with a new one that simply passes through all the data (effectively doing nothing but acting as a bridge)?

Going by the datasheet there is a version with no User ROM, I'm assuming all instructions are pertained there?

DataSheet: http://www.datasheetlib.com/datasheet/188426/mb91302a_fuji-electric.html

 

The two TSOP chips with weird markings are a 256KB and a 4MB NOR flash chips respectively. The one near the Memory Stick slot is the 256KB one.

The markings are just to fool people into thinking they're custom chips. They're bog standard Fujitsu flash chips.

The 4MB one has the RTOS OS used by the DVRP processor (the Fujitsu).

Oh by the way your unit is a using the XPD-005 board, right ? The type which hasthe Altera FPGA sub board, right ?

 

Yeah it is, whys that?

 

Because that system is harder to get working in case of a brick or replacing the HDD...

We still don't know how to rebuild the HDD properly if the HDD gets wiped out, for example.

I know if you find a 40GB SONY HDD and install it on your PSX you will at least be able to use it with OPL for games.

No XMB functionality though.

 

But wasn't that because you adjusted the PS2 data region's size? We don't actually know that it will not work during a simple HDD replacement, do we?

***
@OP:
You cannot use the FHDB KELF for a retail PS2 on a PSX because they will be rejected by the PSX MECHACON.

There is a function for updating the DVRP firmware, although we still need somebody to reverse-engineer the DVRP firmware in order to figure out how the update function is to be used and to come up with a replacement firmware.

While I could strip XFMCB of its HDD support, adding a timeout would be impossible because we do not know what it is getting stalled at. It might be just because a bad sector is hit while the HDD module (APA driver) was scanning the HDD. The boot ROM and MBR/flash bootstrap might not be having this issue because it might not be mounting the disk in the same way?

 

True that I was playing with making the game region 120GB large and even though that worked, the lack of mount point for the DVR device was causing the XMB to panic and exit. On my DESR-7500 it would cause the XMB to exit to ROM OSD then after a couple of boot loops it would just freeze (stack overflow perhaps ?).

I was able to almost get the DESR-7100 to boot to XMB with a 40GB SCE HDD but it didn't had a DVR mount point so it could not finish booting. The XPC-001 XMB behaves differently in that it tries to boot regardless of DRV mountpoints be working or not.

I should investigate if I can make the mountpoints be generated on the 40GB HDD ...


Anyway, if it's not possible to put some sort of timeout on FMCB for PSX, then this situation proves that a alternative boot loader for the junk units could be a good idea.

 

I think that we're getting confused because he didn't describe his problem entirely.
If FMCB freezes up during boot, then the OP would not have been able to start any software at all. No disc-based games, no other software from anywhere.

From my memory, he just wrote that software like uLaunchELF gets stuck after boot. This was why I did nothing, since it would be a problem with software like uLaunchELF then (probably poor error handling).
Unless he meant that it got stuck at a blank, black screen every time. Then it might be stuck in-between FMCB and the software to be loaded.

 

PSX has a dead hdd.. Once I find a sony disk I'll be ok I think haha

anyhow lookiee here


http://thepsx.blogspot.com/2014/10/nand-reader-complete.html

 

Sorry but that's kind of a kludge ... lol

Clever is the software method kHn (the pops guy) deviced using PS2LINK software through the ethernet port.

 

There are a few reasons as to why FMCB will not ever support the flash storage:
1. There is no known way to rebuild it's original contents.
2. Installing FMCB there will cause the PSX to lose its XMB.
3. I used to think that it would be cool to support the flash storage, until you factor in its importance (to the PSX), how common MCs are and the fact that you need one to save data.

Also, it is possible to access the flash storage via software, through the xfrom device. It's just that software like uLaunchELF do not support it.

 

Oh I know that still something cool to do, also I learnt about NAND storage whilst doing it

its kinda funny how companies like e3flahser have a lot of smoke and mirrors when it comes to NAND flashing ect. Like how their device is the only method in the world..


This his psx is pretty much for display/parts now. I'm going to buy a replacement "s" unit soon hopefully