Talk:RealWnD

From WiiBrew
Jump to navigation Jump to search

Perhaps instead of creating a milion projects doing the same thing it would be better to post the improvements to the original project and help to make it version 1.0 instead of having 2 projects at version 0.0001 alpha? —Preceding unsigned comment added by Spec (talk • contribs) 14:20, 8 May 2009 (UTC)

Error 11

Error 11 is "bad block" (factory bad block marker detected; see datasheet). You're correct in noting that error 12 is uncorrectable ECC failure, which is often (but not always) uninitialized flash.

I've seen ES_ImportBoot fail to bother writing ECC (?!?!?!?!?) on at least one occasion, so you're right in ignoring error 12. --Bushing 18:52, 8 May 2009 (UTC)

Error -12/-11/-4

I have no datasheets to refer, but I have a DIY hardware/software to read and program my Flash. Just provide some results of experiments, assumption, and guess.

  • Cool, responses inline. -- Bushing 00:50, 12 May 2009 (UTC)

Results of my experiments:

  • The Hynix Flash from my Wii contains 2 factory marked bad blocks (64x2=128 pages). The characteristics for these bad blocks is that they can be read as 0x00 with Flash Page Read command, but failed with Block Erase command.
The bad block management information in Hynix datasheets seems quiet old. I heard from other Flash Card/USB manufactures (but not fully confirmed) that, already for a long time, Flash fabs undergo new approach by implementing circuits in their chips to disable erase/program operations for all bad blocks in fab's final test so as to prevent improper operation from losing factory bad block info. All erasable bad blocks in Wii NAND might be developed by Nintendo's factory test or Wii's defect menagement.
BTW, according to my test, factory bad blocks in Hynix chips are read as 0x00 and failure for erase command. Factory bad blocks in Samsung chips are read as 0x00. Erase command OK but still read as 0x00. Pcfree 10:08, 12 May 2009 (UTC)
  • The 2 factory marked bad blocks pass IOS_Read() for /dev/flash without error.
    • Yeah, I was just guessing. I give IOS too much credit. :)
  • I got ~7000 pages with code -12 for dump. The code -12 pages are dynamically changed.
    • Do you get code -12 on the same pages for each run? Is the data in one specific page consistent between dumps?
Investigate two dump contents and logs that were produced just between several Wii reboot. Most code -12 pages are unchanged. But several normal pages become code -12 pages (contents as 0xFF). And several code -12 pages (0xFF contents) become normal pages. Pcfree 10:08, 12 May 2009 (UTC)
  • while skipping -12 zeroing (my dump has no -11), I can get the same dump as my DIY hardware dump.

Assumptions:

  • Don't know how many layers the Wii File System implements. But there must be some kind of page map table in a layer to record bad page, used page, free page.
    • Yes; there are two. There is a map inside the boot2 area (blocks 1-7) that tells boot1 whether to skip any of blocks 1-7 when reading boot2. There is also the FAT / cluster map in the "SFFS metadata".
  • According to the NAND Flash characteristics, the page map table may distinguish the free pages as ready-to-use free page (erased as 0xFF to be ready to program) and candidate free page (contents are deleted in File System high level view but not erased by low level Flash Block Erase command).
    • Blocks are never erased until they are reused.

Conclusion & Some Guess:

  • Usual factory marked bad blocks (all 0x00) can pass Wii ECC circuits.
    • Yes, because of the way the parity code works. (zero '1' bits means zero parity)
  • IOS_Read() for /dev/flash is nothing to do with bad block map and cannot detect usual factory marked bad blocks.
    • This is probably correct. The IOS code is really hard to read :(
  • Yes, the code -12 should be uncorrectable ECC failure. Most code -12 pages are 0xFF and should be ready-to-use free pages. The Wii still works if clearing them as 0x00. But it could potentially cause them to be Page-Progammed fail and marked as bad pages so as to lose many free space.
  • Code -12 should be uncorrectable ECC failure and IOS_Read() cannot detect factory bad block mark. Then I guess code -11 might be correctable ECC failure. They are generated in the life time and usually have been marked as bad page in File System page map. Bypass the data code -11 for WnD is also a good idea if it happens to be the very first time failure for this page.
    • This seems reasonable.
  • Someone reported code -4 error in the log file. I guess it should be some kind of hardware error.
    • No. In recent IOS updates, they have removed /dev/flash from IOS; this is why we had to switch to using MINI for BootMii installation on some systems.
  • NAND Flash fabs have implemented circuits in their chip so they can preprogram as 0x00 and disable Erase and Page Program command to specific blocks that want to mark as bad. I guess in some unusal case, such as Page Read timeout or status error, abnormal behavior is not blocked by said circiuts so as to cause some unusual error code in Page Read command by IOS_Read().
    • I think this is impossible. See page 24 of the above PDF. There's no way you can have a timeout, because there is no "ack" from the flash chip. The only status you can read is the status register, and that only tells you if some bits failed to program or erase.

--pcfree 9:31, 9 May 2009 (UTC)

-- Bushing 00:50, 12 May 2009 (UTC)
-- Pcfree 10:08, 12 May 2009 (UTC)

Question to Bushing

May I ask a question regarding to the definition of FAT entry in Wii SFFS FileSystem? With the help of Zestig.c, I've found the factory marked bad block recorded as 0xFFFD in FAT entry, and 0xFFFB seems to be <EOF>. I am curious about 0xFFFC, 0xFFFE, and 0xFFFF. The erased 0xFF clusters do not map to unique FAT value. At least some are 0xFFFE and some are 0xFFFC. Maybe my assumptions are wrong. --pcfree 2:53, 11 May 2009 (UTC)

0xFFFC is "reserved / unusable" -- the clusters that are occupied by boot1/boot2 are marked this way. 0xFFFE is "unused / available". I'm not sure what 0xFFFF represents. --Bushing 12:48, 11 May 2009 (UTC)

One more question to Bushing

If I want to modify SFFS file entry or FAT table, should I also need to calculate HMAC? And where is the storage for HMAC of SFFS metadata and normal file data? Thanks in advance. Pcfree 10:49, 12 May 2009 (UTC)

I think I might know the asnwer now. --Pcfree 05:22, 13 May 2009 (UTC)


RestoreMii compatibility

I would like to know if I can restore with BootMii a dump made with RealWnd. Thanks in advance. Lolololailo 15:31, 4 June 2009 (UTC)

Retrieved from "https://wiibrew.org/w/index.php?title=Talk:RealWnD&oldid=66291"