Backup Wii U Nand

[Leola]

GodMode9is a full access file browser for the Nintendo 3DS console, giving you access to your SD card, the FAT partitions inside your SysNAND and EmuNAND, and basically anything else. Among other functionality, you can copy, delete, rename files, and create folders.

GodMode9 is powerful software that has the capability to modify essentially anything on your console. Though many of these modifications are locked behind a permissions system, and it is impossible to accidentally perform dangerous actions without deliberately unlocking permissions, you should still follow instructions carefully and keep backups just in case.

The SHA1 hash of the nand.bin will not match the hash stored in nand.bin.sha1. This is because dumpTool adds additional data known as a no$gba footer to the nand.bin file after the SHA1 hash is calculated. You can use the hiyaCFW Helperopen in new window to create a copy without the footer.

This will reset all of your saves, games, system version and other system settings back to the point of when you made the NAND backup. Keep this in mind, as you probably don't have to restore a NAND backup unless you have bricked your Switch or want to go back online safely after using CFW.

To restore from a NAND backup on your SD card, you can follow the instructions for RestoreMii.Family edition Wiis (Wiis without GameCube ports) CANNOT restore NAND backups without hardware modification.

NAND Flash Memory is the built in memory of the Wii console. It houses save data, downloaded channels, and the Wii Menu. Some games may require files only found in a full NAND dump to work correctly. The easiest way to do that is with BootMii. For alternate methods, see the forum thread.

Access BootMii through the Homebrew Channel. Use a GameCube Controller or the Power and Reset buttons to navigate through the BootMii menus, as detailed here. Select Options (gears icon) on the far right. Select Backup NAND (Green arrow from chip to the SD card), and wait until it completes. Once completed, remove the SD card and put it into your system. You should see a file named nand.bin on the SD Card. If you do, your NAND has been backed up.

Place the files nand.bin and keys.bin that you've acquired from the last section into the working directory, open cmd.lnk (A shortcut file that will open a command prompt in the current directory), and then type the following commands into the prompt:

i would leave the recovery-system on nand/nor and a full (image) backup e.g. on USB (as long as nvme is not accessable from uboot). you can write an image from any storage to emmc from uboot, but backup (writing the image) may need booting a linux-system (buildroot initrd inside kernel file which can be on usb too)

The j-runner I released has all of the files for all of the dashboards. Might not include all of the SU........ files from the official updates, but that is an easy fix. Also, it depends on your CB version. So if it was hacked before 15574, you cant just build the latest dash, but would need to build a retail 14719 image, then create your hacked image with that. The retail image wont work on the console, assuming you dont have the KV for that console, but you can use it to create an 17511 image that will work on the console.

It isnt about xell, it is about the CB version included with the hacked nand. If your stock dash was pre 15571, then the CB is different, which means you need to build your hacked image against the correct CB. I was helping someone else on the forum, who had a similar problem, and J-runner was building against the wrong CB.

And if you know, then still is pointless to flash a nand, then flash ecc again, just to get ldv and such.. all pointless if you ask me.. when doing rgh nand that is.. but, to simply change a nands kv to match CPU key and what not.. pointless if xell already works.. lol

Who said anything about flashing the nand. lol. I said create a stock image for the dash version that was on the console when it was modded, so when you create your new image it is built against the proper CB version.

The guide also says that 14717 is the latest dash, which is before 15574, so at that point in time the points I make here had no merit, as the cb hadnt been updated to stop the xor attack that used to be used to create xell images.

I know.. the cb's were split on phats, ect.. but guide tells you to flash a dud nand then flash ecc back, ect.. which is pointless if you can already get xell working.. but op is having trouble probably due to no 14xxx dash files..

I didnt really read the guide that was posted, more skimmed it. lol. The jist of it was that the guy needs a donor nand, that will boot via RGH2. Considering when the guide was written, the information is dated at best. lol. That being said, there is still a bunch of good information, and what I said, is exactly what I would do to create a donor nand for a console. It is about covering the bases, as each CB is different, and that can effect the booting of the console, in my experience.

I was examining the initialization procedure of the AM335x as listed in the TRM and I saw that the ROM Code will look at 4 consecutive blocks trying to find the first stage bootloader (MLO) if we're set to boot off of NAND or MMC.

This allows for 4 copies of the MLO, but what about the second stage bootloader (u-boot)? Is there any capability to have the 1st stage bootloader look for more than one copy of the second stage bootloader?

The second set of questions I have is with respect to the multiple copies of the MLO. The ROM code will look for more than one copy, is this to prevent a corrupt image from preventing the board from booting? For example if during an upgrade the first copy of MLO got corrupted, the next time the board boots it will try to boot the first copy and when that fails it will check to see if there are any other copies?

It's regarding OMAP, but I'm pretty sure it's applicable here as well. The MLO is just a stripped down version of u-boot, and it appears the last step it does it load a fixed address (0x80008000 was the example given) for the full u-boot and does not return.

So I guess the answer to my first set of questions is that it currently does not have the ability to look for more than one second stage bootloader, I would probably be able to set a different address for it to jump to if I wanted, but I'm guessing that doing a "check for corruption then use a different copy if required" would not be easy.

Mike Worster said:This allows for 4 copies of the MLO, but what about the second stage bootloader (u-boot)? Is there any capability to have the 1st stage bootloader look for more than one copy of the second stage bootloader?

The first-level bootloader is called u-boot SPL (secondary program loader). It's just a chopped down version of the full u-boot source in order to fit completely in internal memory. I'm not aware of this capability being built into u-boot SPL. You could certainly add something. Although it sounds "easy" I imagine it would probably be a lot of work to really harden the code. For example, in order to really make it robust I would envision putting some kind of CRC header on the file being loaded so that u-boot SPL can validate that it has been loaded correctly. But then you're looking at modifying the tooling for image creation, etc. Some of that already exists as the uImage files that u-boot loads for the kernel have CRCs built into them. Of course once you start adding all the CRC code back into u-boot SPL you might not have enough internal RAM to do it all. So I wouldn't expect it to be trivial.

Mike Worster said:For example if during an upgrade the first copy of MLO got corrupted, the next time the board boots it will try to boot the first copy and when that fails it will check to see if there are any other copies?

Not necessarily. If the pages are programmed with valid data (e.g. half from the original bootloader and half from the new bootloader, due to a power interruption for example) then this would look ok to the ROM. It's only looking for bad pages, i.e. it is not checking the integrity of the complete image (i.e. no CRC, etc.) to make sure it's "good".

Now, what I had read before is that the SPL (I guess) jumps to the u-boot at a specific address and hands over control. Is that much correct? Is this a hardcoded address that the SPL expects to find the second stage bootloader, u-boot, at? If so, where is the code where this address is set?

What I'm thinking right now is that you may be correct that adding a CRC header to the uboot images and a CRC check algorithm to the SPL might be a bit much... but maybe I can make this simpler. I can tell the SPL to boot from address B if some flag is set and otherwise boot from address A, the flag can be set/cleared during the boot and upgrade procedures.

2) I need set some sort of flag in a file, or something... for the SPL (MLO?) to be able to read/write and use that to pick the address noted in #1. Are you aware of a way to set any sort of flags that the SPL can look for?

You could probably modify the .h file and add a u-boot backup after u-boot and shift the u-boot environment/kernel/rootfs higher in NAND. You would also have to modify the SPL code to do some type of CRC and use the backup copy if something is wrong. The MTD table in your kernel would have to be modified, too.

3a8082e126