curtis (dot) parrott (at) gmail (dot) com

Anyway…I am also playing around with the NAND interface above with my Xilinx CPLD devkit. I’m havnt done much VHDL/Veralog since my intro to logic class in college but its an interesting project.

At any rate…if anyone wants the breakout let me know. It seems to take the PCB fab house quite a bit of time to get my orders back to me but its cheaper; I use http://www.batchpcb.com.

Anyone know where to find the cheapest FT2232 board?

Yes, now that I “know better”, I do that D0 trick. I wonder if turning WC24 off would be enough to prevent that from being necessary – not that that is possible on a bricked Wii.
From another hand, it might be that on bricked Wii WC24 didn’t even started. Can’t be sure about anything anyway.

As for the 2048 vs 2048+64:.. but unfortunately it is “signed” with an HMAC as well, which is what currently has me stuck.
Does filesystem metadata also has ECC and every 8 pages are HMAC signed?
I.e. it’s same as filesystem data except it’s not encrypted.

Back to integrity check algorithm, you would prefer to count on ECC, not on HMAC signature, right?

@Newbie: Yes, now that I “know better”, I do that D0 trick. I wonder if turning WC24 off would be enough to prevent that from being necessary — not that that is possible on a bricked Wii.

As for the 2048 vs 2048+64: You have to read it in 2048 + 64 mode. We know how to calculate the ECC bytes for sectors, but every 8 pages, they add in a 20-byte HMAC into some of the empty space after the ECC inside of the 64-byte spare area.

The filesystem metadata must not only be there, but it must be almost intact. It tells the Wii where all of the files are in the encrypted section — so without it, the rest of the chip is worthless! This data is unencrypted, but unfortunately it is “signed” with an HMAC as well, which is what currently has me stuck.

We can do away with the entire CPLD design
and use a single FTDI chip with dual UART in
bit-bang mode.

http://www.ftdichip.com/Documents/DataSheets/DS_FT2232D.pdf

We can use Channel A as control signals for
CLE, ALE, CE, RE, WE, WP, and R/B(input)

Then we can use Channel B as our IO0-IO7.

All the 16 IOs from Channel A and Channel B can
be individually configured and 3.3v logic levels
of the FTDI requires no further voltage translation
for the 3.3v Wii NAND.

I guess this would be the easiest and fastest way
to do it.

What do you think?

I am using the same cpld as the X-board and in
china it costs about 7 U$D + 2 U$D for the
FTDI.

I have started coding for a small 8-bit core that
will handle the following commands:

Read 0000 0000 [00h]
Read ID 1001 0000 [90h]
Reset 1111 1111 [FFh]
Page Program 1000 0000 [80h]
Block Erase 0110 0000 [60h]
Read Status 0111 0000 [70h]

I do not plan to put the ECC inside the core as
I think this could be done on the PC side instead.
What I plan to do is make the CPLD read each
page (2048 + 64)bytes and send it over the
emulated RS232 port of the FTDI in 64byte
chunks. So it will be 64bytes x 33 RS232 frames.
I can put an additional 8-bit cheksum on each
64 byte frame to check on weather errors
have occured during the rs232 transfers.

But of course, this will not be the final design as
something like this will take almost 6 days to
read the entire device @ 9600 bps heheheh…
Even at 115200 bps it will take 12 hours for the
entire device, so I guess I really need to push
the FTDI’s maximum 1M Baud to get it clocking
between 1-2 hours. (the computations are just
off my head.. please correct me if something is
wrong…)

The bottleneck here is really the transfer of data
between the CPLD and the FTDI. I can clock the
CPLD @ 300Mhz (even faster than the NAND!)
but still we are limited on the FTDI to PC side ;-(((

Please click on the link that I put as my homepage
to see the dev board that I will be using. I am
sorry about the camera resolution as it is just
from my phone.

B.R.
skiddd