Greetings, here's some instructions to move your emunand from <=2.3 to >=2.4 SX OS. You will need to fill in your own info.

dd if=/dev/rdisk* of=first1024.bin bs=1024 count=1

cat first1024.bin boot0.bin boot1.bin full.00.bin full.01.bin full.02.bin full.03.bin full.04.bin full.05.bin full.06.bin full.07.bin > /Volumes/WhereYouWantToStoreIt/emunand.bin

Write the backup with pv:

sudo dd if=/Volumes/WhereYouStoredIt/emunand.bin | pv -s 29G | sudo dd of=/dev/rdisk* bs=2m conv=noerror,notrunc

Without pv:

sudo dd if=/Volumes/WhereYouStoredIt/emunand.bin of=/dev/rdisk* bs=2m conv=noerror,notrunc

Let me know if you have any questions. This is for mac but should work on linux, with minor adjustments.

 

[thaikhoa]

This is well tested
Backup emunand from hidden emunand

dd bs=512 if=/dev/disk* of=./boot0.bin skip=2 count=8192
dd bs=512 if=/dev/disk* of=./boot1.bin skip=8194 count=8192
dd bs=512 if=/dev/disk* of=./rawnand.bin skip=16386 count=61071360

 

[GraFfiX420]

This is well tested
Backup emunand from hidden emunand

I'm just curious is this slow to backup rawnand? If so, it would be related to blocksize, 512 is 1 block at a time, also /dev/rdisk* would be used on mac to speed backup. If it is indeed slow because of blocksize, I would recommend you back up the entire hidden area, then keep that to restore later. If you do it that way, you can increase the blocksize to 2m, which will increase the speed substantially.

 

[thaikhoa]

I'm just curious is this slow to backup rawnand? If so, it would be related to blocksize, 512 is 1 block at a time, also /dev/rdisk* would be used on mac to speed backup. If it is indeed slow because of blocksize, I would recommend you back up the entire hidden area, then keep that to restore later. If you do it that way, you can increase the blocksize to 2m, which will increase the speed substantially.

Around 6MB/s . rdisk / bs 1024 even slower than. Idk why.
I'd like to backup rawnand for hacdiskmount to read. Backup a whole one is good too

 

[comput3rus3r]

All I did was backup my sd card. Created a new hidden emunand with sxos and then copied over the emutendo folder (not overwriting anything) it seems to be working with all my games/saves etc.

 

[GraFfiX420]

All I did was backup my sd card. Created a new hidden emunand with sxos and then copied over the emutendo folder (not overwriting anything) it seems to be working with all my games/saves etc.

All your saves etc must have been stored to SD, then. For people who have made changes to files on nand, this is definitely relevant.

 

[thaikhoa]

Nand injector should be

dd bs=512 if=/Users/khoa/Desktop/boot0.bin of=/dev/disk2 seek=2 conv=notrunc
dd bs=512 if=/Users/khoa/Desktop/boot1.bin of=/dev/disk2 seek=8194 conv=notrunc
dd bs=512 if=/Users/khoa/Desktop/rawnand.bin of=/dev/disk2 seek=16386 conv=notrunc

 

[GraFfiX420]

Nand injector should be

While this is accurate, it's not the recommended way to do it, at least on mac. My post in the tutorials section has the best route, dump the first 1024 bytes of your SD , concatenate that with your boot0/1 and rawnand, then write it back with dd, to /dev/rdisk* with a bs of 2m. While this will work, with a blocksize of 512bytes on a 29 gig file it will take forever, do yourself a favor and quickly dump the first 1024, concatenate, and write.

 

[thaikhoa]

While this is accurate, it's not the recommended way to do it, at least on mac. My post in the tutorials section has the best route, dump the first 1024 bytes of your SD , concatenate that with your boot0/1 and rawnand, then write it back with dd, to /dev/rdisk* with a bs of 2m. While this will work, with a blocksize of 512bytes on a 29 gig file it will take forever, do yourself a favor and quickly dump the first 1024, concatenate, and write.

Idk why using bs 1024 or larger (won't support larger than bs 1024 for extracting with skip or seek) won't increase the speed but longer waiting time. Extract or inject with bs 512 for 29GB takes around 1 hour.

 

[GraFfiX420]

Idk why using bs 1024 or larger (won't support larger than bs 1024 for extracting with skip or seek) won't increase the speed but longer waiting time. Extract or inject with bs 512 for 29GB takes around 1 hour.

This is not accurate, try to restore a rawnand with a 512byte blocksize, let me know how long it takes. A blocksize of 512 may be fine for dumping, but for writing larger the better. Same with traditional disk access versus raw, using /dev/disk versus /dev/rdisk, /dev/rdisk is rawdisk, and will increase speed dramatically.

 

[thaikhoa]

This is not accurate, try to restore a rawnand with a 512byte blocksize, let me know how long it takes. A blocksize of 512 may be fine for dumping, but for writing larger the better. Same with traditional disk access versus raw, using /dev/disk versus /dev/rdisk, /dev/rdisk is rawdisk, and will increase speed dramatically.

I've tried many times but I won't see any changes on speed using rdisk when dumping. I will try to restore a whole nand back to the SD.

 

[GraFfiX420]

I've tried many times but I won't see any changes on speed using rdisk when dumping. I will try to restore a whole nand back to the SD.

This would make sense, as dumping is accessing the raw device by default, try restoring, first with /dev/disk then with /dev/rdisk. I should also correct myself, when writing, a larger blocksize is faster to a point, there's a "sweet spot" for most systems. On macos, however, the limit on blocksize for the version of dd that's running is 2m, so this is the best that can be done.

 

[OvOvOv]

Is there an application that can do this in an automated way?

 

[thaikhoa]

While this is accurate, it's not the recommended way to do it, at least on mac. My post in the tutorials section has the best route, dump the first 1024 bytes of your SD , concatenate that with your boot0/1 and rawnand, then write it back with dd, to /dev/rdisk* with a bs of 2m. While this will work, with a blocksize of 512bytes on a 29 gig file it will take forever, do yourself a favor and quickly dump the first 1024, concatenate, and write.

Just successfully restored my rawnand backup to the hidden partition using dd bs512, took 3 hours.

 

[GraFfiX420]

Just successfully restored my rawnand backup to the hidden partition using dd bs512, took 3 hours.

With a 2m blocksize writing to rdisk it takes me ~20 minutes to restore a rawnand.

 

[enarky]

With a 2m blocksize writing to rdisk it takes me ~20 minutes to restore a rawnand.

31276925952 bytes transferred in 689.570969 secs (45357080 bytes/sec)

A bit more than 11 minutes for me. Switched SD cards, tried it with a raw copy of the smaller SD card to the bigger one and annoyingly found out that you can't just resize ExFat partitions on any OS (without expensive software). So I set up a new EmuNAND and transferred the old one to the new card.

 

[Kikolasi3D]

¿How can you do this in Windows?

 

[thaikhoa]

¿How can you do this in Windows?

http://www.chrysocome.net/dd

 

[enarky]

¿How can you do this in Windows?

The tool we use on OSX, dd, does not exist on Windows natively. It's probably part of the Windows Subsystem for Linux, though. Cygwin might also come with dd, but it's rather tedious to set up. I don't think a native Windows tool that does something similar exists, but I'd like to know if it does.

EDIT:

http://www.chrysocome.net/dd

Ah, looks like it does exist on Windows.

 

[intucabutucrowt]

Thanks a lot to GraFfiX420 for figuring this out. I was prepared to do some research on my own to try and figure out how the hidden partition worked, but thanks to you I didn't need to and was able to successfully copy my emunand.