|
|
Post by spannernick on Jun 9, 2020 20:23:12 GMT
How to make a backup the Firmware------------------------------------------ I made the thread because there is nothing about restoring the Nand firmware, well it scattered around the forum. **RECOMENDED BACKUP**
This works on THEC64 Mini/Maxi and THEVIC 20.
You can run THEC64 X-Windows Mod in Project Carousel USB, by pressing CTRL-Z, its the easiest way of running XWM(its included with PCUAE v1.3.1) To backup the firmware in THEC64 X-Windows Mod, you just double click on the `Backup TheC64 nand and game files` icon on the top right, you see a Terminal(shell) open and start copying files, then if you look in the USB Drive you will see a folder called `backup` and in there you find files.001 and nand.001 folders, the Firmware game files are in files.001 folder
and the nanda and nandb are in nand.001 folder.
That's it, you now have a backup of your games and nanda and nandb on your USB Drive, its that easy ..  Done, now just log out or (PCU) press CTRL-RESTORE to restart.You can use FEL-Mode to make a backup or restore your firmware, nanda and nandb on THEC64 Mini. You can now use FEL-Mode to make a backup or restore your firmware, nanda and nandb on THEC64 Maxi/Vic20. You can use a Terminal or Putty to copy your nand with these commands... You can get a copy of nanda and nandb HERE under NAND_Backups
You need to mount the USB stick first so you can copy the nand backups there..
mount /tmp/usbdrive/sda1 /mnt
Then you copy the nand parts to the USB stick with:
cp /dev/nand* /mnt
---------------------------------- There is not a lot of talk about flashing the nanda or nandb and fixing a bricked THEC64 Mini or Maxi. If anyone want to talk about or needs help with it post in this tread, you can make a new thread about it, if you want to. Anyone want to add to this your welcome too, there's more users out there that know more then me.. mnt is the root of the USB Drive. TheC64 Mini: Either start in FEL mode or using an USB2UART converter (UART Cable and connecting it to THEC64 Mini board) in the initial ramdisk mode(see below for more info) . Then after doing the 'insmod /lib/modules/3.4.39/nand.ko' and 'mount /dev/sda1 /mnt' (assuming your backup is on the only USB disk that's inserted) you can use the command 'dd if=/mnt/(backup/nand.001/)nanda of=/dev/nanda' to restore nanda (usually not needed, it not usually nanda that corrupted) or 'dd if=/mnt/(backup/nand.001/)nandb of=/dev/nandb' to restore nandb (nandb is where the file system is kept and where updates are copied to so can get corrupted).TheC64 Maxi: Using an USB2UART converter (UART Cable and connecting it to THEC64 Maxi board) in the initial ramdisk mode . Then (after doing the 'insmod /lib/modules/3.4.39/nand.ko' and 'mount /dev/sda1 /mnt' (assuming your backup is on the only USB disk that's inserted) you can use the command 'dd if=/mnt/(backup/nand.001/)nanda of=/dev/nanda' to restore nanda (usually not needed, it not usually nanda that corrupted) or 'dd if=/mnt/(backup/nand.001/)nandb of=/dev/nandb' to restore nandb (nandb is where the file system is kept and where updates are copied to so can get corrupted).More info on Initial Ramdisk Mode and copying nandb to THEC64 Mini/Maxi----------------------------------------------------------------------------------------------- Normally, assuming the USB drive is /dev/sda1: Interrupt u-boot by holding 's' on the keyboard when you are connected to THEC64 Mini/Maxi with Putty via UART. In the u-boot prompt type: setenv console ttyS0,115200 ramfs
bootYou will end up at a root shell running from the kernels ramdisk. Then load the nand driver and copy the backup back into /dev/nandb: Copy nandb to the root of the usb drive: insmod /lib/modules/3.4.39/nand.ko
mount /dev/sda1 /mnt
dd if=/mnt/nandb of=/dev/nandb
sync
umount /mntor point to the folder its in, like when you copy the nand with THEC64 X-Windows Mod:dd if=/mnt/backup/nand.001/nandb of=/dev/nandbYou will see only a flashing cursor, so now just wait for it to finish. After you can check nandb with:e2fsck -v /dev/nandbIf you want to but it should not be needed.
Once it's copies the backup back to thec64, then power off/on again and fingers crossed it should boot like normal. Do the same above for nanda but where its say nandb replace it with nanda.(you could change THEC64 Maxi into a THE VIC 20 this way, if you had the nanda and nandb of THE VIC 20 and copy them over THEC64 Maxi's nanda and nanbdb cause there are both the same machine really, never tried it, but I have got THEC64 Maxi and THE VIC 20 nanda and nandb working on the OPI.) Post from Discord that might help to give pointers about restoring the nanda and nandb...
|
|
|
|
Post by grasshopper on Oct 24, 2020 15:46:16 GMT
Hi, I'm not sure whether I should start a new thread on this, but I was wondering whether any of you guys know a reliable way to backup and restore all of the C64 Maxi's firmware from/to bare metal?
I'd like to start experimenting with hacking the stock firmware. However, I'm not prepared to do this until I have a 100% reliable method of restoring the device back to its factory state if something goes horribly wrong. The problem is that all of the backup methods I've seen on this site seem to rely on the device being bootable.
Ideally, I'd like to be able to dump the entire contents of the NAND chip to or from a file. Presumably this would have to be done using FEL mode, but I can't find any documentation on this. Can anyone here point me in the right direction?
Thanks in advance.
|
|
|
|
Post by darbyram on Oct 24, 2020 17:21:21 GMT
Hi, I'm not sure whether I should start a new thread on this, but I was wondering whether any of you guys know a reliable way to backup and restore all of the C64 Maxi's firmware from/to bare metal? I'd like to start experimenting with hacking the stock firmware. However, I'm not prepared to do this until I have a 100% reliable method of restoring the device back to its factory state if something goes horribly wrong. The problem is that all of the backup methods I've seen on this site seem to rely on the device being bootable. Ideally, I'd like to be able to dump the entire contents of the NAND chip to or from a file. Presumably this would have to be done using FEL mode, but I can't find any documentation on this. Can anyone here point me in the right direction? Thanks in advance. |
|
|
|
Post by grasshopper on Oct 25, 2020 11:37:09 GMT
Hi, I'm not sure whether I should start a new thread on this, but I was wondering whether any of you guys know a reliable way to backup and restore all of the C64 Maxi's firmware from/to bare metal? I'd like to start experimenting with hacking the stock firmware. However, I'm not prepared to do this until I have a 100% reliable method of restoring the device back to its factory state if something goes horribly wrong. The problem is that all of the backup methods I've seen on this site seem to rely on the device being bootable. Ideally, I'd like to be able to dump the entire contents of the NAND chip to or from a file. Presumably this would have to be done using FEL mode, but I can't find any documentation on this. Can anyone here point me in the right direction? Thanks in advance. Please forgive my ignorance, but I was under the impression that the two backup methods you've linked to, required the device to be bootable using the stock firmware. Is that not correct?
What I'm really after is a method for backing up and restoring that can be used even if the nanda and nandb partitions have been completely overwritten i.e. the device is not bootable.
|
|
|
|
Post by spannernick on Oct 25, 2020 16:13:28 GMT
Please forgive my ignorance, but I was under the impression that the two backup methods you've linked to, required the device to be bootable using the stock firmware. Is that not correct? What I'm really after is a method for backing up and restoring that can be used even if the nanda and nandb partitions have been completely overwritten i.e. the device is not bootable.
There would be no reason why you would go over nanda that where the kernal is and the THEC64 Mini/maxi only works with one kernal so you would still be able to get into ram disk mode, that why its has a nanda and nandb, nandb is the filesystem, they can't run another kernal, only the kernal that are made for them by RGL, well THEC64 Mini can run another kernal using THEC64 Mini Fel Mode but that cause we have the source code for it, we don't have the source code for THEC64 Maxi kernal yet, that why there is no fel mode on THEC64 Maxi yet. If say THEC64 Mini don't boot you can use THEC64 Mini Fel Mode to fix it cause it boots its own ram disk and kernal, on THEC64 Mini it can be fixed even if the device is not bootable but can not do that on THEC64 Maxi at the moment, no source code for it's kernal. THE VIC 20 is the same as THEC64 Maxi so both use the same kernel, its the same machine, THEC64 Maxi, it just a wolf in sheep's clothing.. jj-0 would be better at answering this question then me, he might know other ways in to THEC64 Maxi than I do ...  |
|
|
|
Post by grasshopper on Oct 29, 2020 12:21:01 GMT
Well, I've been doing some more background reading on this subject. This rabbit hole goes very deep...
From what I gather, you don't actually need to build a new kernel. But you do need to build a new bootloader with parameters that are specific to each Allwinner device. Why do they have to make this stuff so complicated? I really wish the ARM SOC manufacturers would get together and come up with a standardised boot process, similar to what we have enjoyed in the X86 world for decades. It's crazy that you have to acquire so much arcane knowledge just to do something trivial like back up your firmware.
Anyway, I'm wondering whether it might be possible to avoid having to build a new bootloader, by extracting the bootloader that is already on the device's NAND chip. Does that sound plausible?
|
|
|
|
Post by spannernick on Oct 29, 2020 15:08:49 GMT
Don't see why not, it might work, I never done it so don't know.
|
|
|
|
Post by grasshopper on Oct 30, 2020 16:33:19 GMT
I'm wondering whether it might be better if I simply buy an Orange Pi PC board as you have done, and run the firmware on that. They cost less that £20 shipped, with a case and power cable included. It's almost worth paying that just to have the ability to run the firmware from a removable SD card. The only thing that's making me hesitate is that I've had some bad experiences with Aliexpress in the past.
That's another of RGL's cost cutting measures that really frustrates me. It would have cost them literally pennies to have added a working SD card slot to their board. And that simple addition would have made the device vastly more useful to the hacking community.
|
|
|
|
Post by jj0 on Oct 30, 2020 18:05:48 GMT
Please forgive my ignorance, but I was under the impression that the two backup methods you've linked to, required the device to be bootable using the stock firmware. Is that not correct? What I'm really after is a method for backing up and restoring that can be used even if the nanda and nandb partitions have been completely overwritten i.e. the device is not bootable.
First boot the Maxi in FEL mode. Similar to booting the Mini in FEL mode, but you need to replace some stuff: - The uboot with one suitable for the H3 SoC of the Maxi. The one from this fel-mass-storage git might work, though it's more fun to compile a new uboot yourself. - The kernel with one suitable for the H3 SoC of the Maxi. If you first dump nanda then you could use that, or the kernel from the fel-mass storge git. Or compile a kernel for the Orange PI PC. Then when booted into a console via FEL use the nand_rw tool from here to dump the entire nand including uboot bootloader. To use nand_rw properly you have to first get your nand chip make, size and blocksize (both data and spare) so you can correctly dump it. |
|
|
|
Post by jj0 on Oct 30, 2020 18:06:43 GMT
I'm wondering whether it might be better if I simply buy an Orange Pi PC board as you have done, and run the firmware on that. They cost less that £20 shipped, with a case and power cable included. It's almost worth paying that just to have the ability to run the firmware from a removable SD card. The only thing that's making me hesitate is that I've had some bad experiences with Aliexpress in the past. That's another of RGL's cost cutting measures that really frustrates me. It would have cost them literally pennies to have added a working SD card slot to their board. And that simple addition would have made the device vastly more useful to the hacking community. Yes but then you are no longer hacking the Maxi itself. |
|
|
|
Post by grasshopper on Nov 3, 2020 18:06:22 GMT
Please forgive my ignorance, but I was under the impression that the two backup methods you've linked to, required the device to be bootable using the stock firmware. Is that not correct? What I'm really after is a method for backing up and restoring that can be used even if the nanda and nandb partitions have been completely overwritten i.e. the device is not bootable.
First boot the Maxi in FEL mode. Similar to booting the Mini in FEL mode, but you need to replace some stuff: - The uboot with one suitable for the H3 SoC of the Maxi. The one from this fel-mass-storage git might work, though it's more fun to compile a new uboot yourself. - The kernel with one suitable for the H3 SoC of the Maxi. If you first dump nanda then you could use that, or the kernel from the fel-mass storge git. Or compile a kernel for the Orange PI PC. Then when booted into a console via FEL use the nand_rw tool from here to dump the entire nand including uboot bootloader. To use nand_rw properly you have to first get your nand chip make, size and blocksize (both data and spare) so you can correctly dump it.
Thanks for the information.
I'm currently following your instructions but I've hit a snag.
I've made backups of the nanda and nandb partitions using the script bundled with the C64 X-Windows Mod. However, I can't seem to mount either partition when running Ubuntu Linux on my PC. I've tried doing it on the command line and by using the Disks utility that comes with Ubuntu. However, they don't appear to be recognised as valid disk image files. Can you point me in the right direction?
Thanks
|
|
|
|
Post by jj0 on Nov 3, 2020 18:11:35 GMT
First boot the Maxi in FEL mode. Similar to booting the Mini in FEL mode, but you need to replace some stuff: - The uboot with one suitable for the H3 SoC of the Maxi. The one from this fel-mass-storage git might work, though it's more fun to compile a new uboot yourself. - The kernel with one suitable for the H3 SoC of the Maxi. If you first dump nanda then you could use that, or the kernel from the fel-mass storge git. Or compile a kernel for the Orange PI PC. Then when booted into a console via FEL use the nand_rw tool from here to dump the entire nand including uboot bootloader. To use nand_rw properly you have to first get your nand chip make, size and blocksize (both data and spare) so you can correctly dump it.
Thanks for the information.
I'm currently following your instructions but I've hit a snag.
I've made backups of the nanda and nandb partitions using the script bundled with the C64 X-Windows Mod. However, I can't seem to mount either partition when running Ubuntu Linux on my PC. I've tried doing it on the command line and by using the Disks utility that comes with Ubuntu. However, they don't appear to be recognised as valid disk image files. Can you point me in the right direction?
Thanks
You can't mount nanda as that's the kernel boot image. Nandb you should be able to mount with something like 'sudo mount nandb /mnt'. Do you get any error message? Also, what does 'file nandb' say? |
|
|
|
Post by grasshopper on Nov 3, 2020 18:40:47 GMT
When I run 'file nandb', I get the following output:
nandb: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-0000-675f-946fc0f9f25b (needs journal recovery) (extents) (large files)
When I run 'sudo mount nandb mnt', I get the following output:
mount: /media/xxxxx/KINGSTON/backup/nand.001/mnt: cannot mount /dev/loop12 read-only.
|
|
|
|
Post by grasshopper on Nov 3, 2020 18:49:10 GMT
Can you also clarify how the nanda kernel boot image works?
I'm only familiar with how Linux typically boots on X86 machines, where the kernel image (and in most cases also a matching ramdisk image) are just files stored on the boot partition. Does the kernel on the C64 Maxi not use an initial ramdisk for booting?
|
|
|
|
Post by jj0 on Nov 4, 2020 8:15:41 GMT
When I run 'file nandb', I get the following output: nandb: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-abf4-0000-675f-946fc0f9f25b (needs journal recovery) (extents) (large files) When I run 'sudo mount nandb mnt', I get the following output: mount: /media/xxxxx/KINGSTON/backup/nand.001/mnt: cannot mount /dev/loop12 read-only. The 'needs journal recovery' probably prevents it from mounting. So you need to check/repair the filesystem first: 'sudo e2fsck -y nandb' and then mount it. |
|
|
|
Post by jj0 on Nov 4, 2020 8:20:02 GMT
Can you also clarify how the nanda kernel boot image works? I'm only familiar with how Linux typically boots on X86 machines, where the kernel image (and in most cases also a matching ramdisk image) are just files stored on the boot partition. Does the kernel on the C64 Maxi not use an initial ramdisk for booting? Nanda is packed as an android boot image. You can unpack and repack the kernel and ramdisk with e.g. abootimg (installable with apt/apt-get or you can get it from github.com/ggrandou/abootimg). |
|
|
|
Post by grasshopper on Nov 4, 2020 17:10:51 GMT
The 'needs journal recovery' probably prevents it from mounting. So you need to check/repair the filesystem first: 'sudo e2fsck -y nandb' and then mount it.
Thanks. That did the trick. I presume this happened because the partition was in use whilst it was being backed up. |
|
|
|
Post by grasshopper on Nov 4, 2020 17:11:50 GMT
Nanda is packed as an android boot image. You can unpack and repack the kernel and ramdisk with e.g. abootimg (installable with apt/apt-get or you can get it from github.com/ggrandou/abootimg).
Thanks. I'll check that out.
|
|
|
|
Post by spannernick on Nov 4, 2020 19:09:42 GMT
First boot the Maxi in FEL mode. Similar to booting the Mini in FEL mode, but you need to replace some stuff: - The uboot with one suitable for the H3 SoC of the Maxi. The one from this fel-mass-storage git might work, though it's more fun to compile a new uboot yourself. - The kernel with one suitable for the H3 SoC of the Maxi. If you first dump nanda then you could use that, or the kernel from the fel-mass storge git. Or compile a kernel for the Orange PI PC. Then when booted into a console via FEL use the nand_rw tool from here to dump the entire nand including uboot bootloader. To use nand_rw properly you have to first get your nand chip make, size and blocksize (both data and spare) so you can correctly dump it. Thanks for the information. I'm currently following your instructions but I've hit a snag. I've made backups of the nanda and nandb partitions using the script bundled with the C64 X-Windows Mod. However, I can't seem to mount either partition when running Ubuntu Linux on my PC. I've tried doing it on the command line and by using the Disks utility that comes with Ubuntu. However, they don't appear to be recognised as valid disk image files. Can you point me in the right direction? Thanks
I had the same problem in Linux mint, I worked out that if I changed nandb to nandb.7z then I could read it like a 7zip archive and see the files inside it, and you can open it with 7zip on windows 10 too. |
|
|
|
Post by grasshopper on Nov 4, 2020 22:12:56 GMT
First boot the Maxi in FEL mode. Similar to booting the Mini in FEL mode, but you need to replace some stuff: - The uboot with one suitable for the H3 SoC of the Maxi. The one from this fel-mass-storage git might work, though it's more fun to compile a new uboot yourself. - The kernel with one suitable for the H3 SoC of the Maxi. If you first dump nanda then you could use that, or the kernel from the fel-mass storge git. Or compile a kernel for the Orange PI PC. Then when booted into a console via FEL use the nand_rw tool from here to dump the entire nand including uboot bootloader. To use nand_rw properly you have to first get your nand chip make, size and blocksize (both data and spare) so you can correctly dump it.
OK. I've made a bit of progress.
I downloaded your FEL boot tools.
I then downloaded the u-boot-sunxi-with-spl.bin file from the fel-mass-storage git and placed the file in the boot directory.
I then copied my nanda file to the boot directory and renamed it uImage (replacing the existing uImage file). Note, I've left the script.bin and uEnv.txt files alone, but I'm not sure if that's correct.
I then put the machine into FEL mode and ran 'sudo ./boot.sh'.
The following output is produced:
USB device 003:004 Allwinner H3 02c00181:94704620:78a04610:08330393
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
Generating the new MMU translation table at 0x00008000
=> Executing the SPL... done.
Setting write-combine mapping for DRAM.
Setting cached mapping for BROM.
Writing back the MMU translation table.
Enabling I-cache, MMU and branch prediction... done.
Writing image "U-Boot 2016.09-armbian-fel-mass-", 247509 bytes @ 0x4A000000.
Passing boot info via sunxi SPL: script address = 0x43100000, uEnv length = 260
Starting U-Boot (0x4A000000).
According to your instructions, I should now be logged into the C64 Maxi. But instead, I get returned to the standard bash prompt on my Linux PC.
|
|
|
|
Post by jj0 on Nov 5, 2020 8:39:07 GMT
First boot the Maxi in FEL mode. Similar to booting the Mini in FEL mode, but you need to replace some stuff: - The uboot with one suitable for the H3 SoC of the Maxi. The one from this fel-mass-storage git might work, though it's more fun to compile a new uboot yourself. - The kernel with one suitable for the H3 SoC of the Maxi. If you first dump nanda then you could use that, or the kernel from the fel-mass storge git. Or compile a kernel for the Orange PI PC. Then when booted into a console via FEL use the nand_rw tool from here to dump the entire nand including uboot bootloader. To use nand_rw properly you have to first get your nand chip make, size and blocksize (both data and spare) so you can correctly dump it.
OK. I've made a bit of progress.
I downloaded your FEL boot tools.
I then downloaded the u-boot-sunxi-with-spl.bin file from the fel-mass-storage git and placed the file in the boot directory.
I then copied my nanda file to the boot directory and renamed it uImage (replacing the existing uImage file). Note, I've left the script.bin and uEnv.txt files alone, but I'm not sure if that's correct.
I then put the machine into FEL mode and ran 'sudo ./boot.sh'.
The following output is produced:
USB device 003:004 Allwinner H3 02c00181:94704620:78a04610:08330393
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
Generating the new MMU translation table at 0x00008000
=> Executing the SPL... done.
Setting write-combine mapping for DRAM.
Setting cached mapping for BROM.
Writing back the MMU translation table.
Enabling I-cache, MMU and branch prediction... done.
Writing image "U-Boot 2016.09-armbian-fel-mass-", 247509 bytes @ 0x4A000000.
Passing boot info via sunxi SPL: script address = 0x43100000, uEnv length = 260
Starting U-Boot (0x4A000000).
According to your instructions, I should now be logged into the C64 Maxi. But instead, I get returned to the standard bash prompt on my Linux PC.
You have probably succeeded in booting the kernel via FEL mode, and the kernel probably loaded and executed its ramdisk. But that doesn't magically make a command prompt appear, though there might be one on the UART. For the Mini FEL thing I created my own ramdisk with added stuff to get an onscreen command prompt. So you could use that ramdisk as a starting point for changes to make to the Maxi's ramdisk. You can't use the Mini's ramdisk directly though because the kernel modules in it are for the Mini's kernel/SoC, not the Maxi's kernel/SoC. Do you have an UART connected so you can see the Maxi's output? That really helps in understanding what's happening. Sorry I can't be of more direct help, I've been off sick without access to my Maxi for weeks now, so I'm doing this from memory. |
|
|
|
Post by grasshopper on Nov 6, 2020 19:47:08 GMT
Thanks for your help so far. And no apology is necessary. We all have to fit this hobby around more important things happening in our lives.
With regards to your question, no I haven't got a UART connector fitted to my board. I'm a bit reluctant to undertake a soldering job on a device that is still fairly new and under guarantee. However, if all else fails, I might eventually bite the bullet and solder on a UART connector.
|
|
|
|
Post by grasshopper on Nov 6, 2020 20:01:09 GMT
Incidentally, I struggled a bit to get my C64 Maxi into FEL mode. Connecting it to my PC using the micro USB power socket didn't work. It might possibly have been the cables I used (I did try several), or perhaps my PC's USB connectors didn't provide enough power. But anyway, what eventually did work is as follows:
- I connected the USB socket on the back of the C64 Maxi to one of my PC's USB sockets using a USB-A to USB-A cable.
- I then pressed the FEL mode button and kept it pressed.
- then connected the power cable to the C64 Maxi.
- I then pressed the black button on the side of the C64 Maxi.
- After a few seconds, I released the FEL mode button.
|
|
|
|
Post by jj0 on Nov 7, 2020 10:36:40 GMT
Regarding the UART, it really is a great help to see what's going on at the Maxi end of things. You can avoid soldering by using my (still not patented) 'rubber band' methods 1 or 2. Or just plug the USB2UART converter pins straight into the appropriate holes in the PCB and bend them at the other side of the PCB to secure it. Works great for me. My way of booting the Maxi into FEL mode is very simple, it boils down to: - Insert USB A to A cable in Maxi USB port on the back
- Press FEL button and keep it pressed
- Insert the other end of the USB A to A cable in PC USB port
- Wait a few seconds then release the FEL button
Though instead of removing and inserting the USB A-A cable I actually use a (powered) USB hub with on/off switch per port so my A-A cable is permanently connected to the hub and the Maxi and I press the FEL button and then switch the USB port on on the hub.
|
|
xnyarlx
Creatures
Atarowca kop z gumowca!
Posts: 10
|
Post by xnyarlx on Jan 5, 2021 8:23:33 GMT
I need backup nand from THEC64 MAXI european (Poland) somebody have?
|
|
|
|
Post by spannernick on Jan 5, 2021 16:24:08 GMT
I need backup nand from THEC64 MAXI european (Poland) somebody have? You can get a copy of nanda and nandb here under NAND_Backups |
|
xnyarlx
Creatures
Atarowca kop z gumowca!
Posts: 10
|
Post by xnyarlx on Jan 13, 2021 2:42:08 GMT
I need backup nand from THEC64 MAXI european (Poland) somebody have? You can get a copy of nanda and nandb here under NAND_Backups Thank U |
|
|
|
Post by retrochlop on Jan 30, 2021 15:40:23 GMT
Hey. My MAXI stopped responding  Only the splash screen starts, then only a black screen Can I fix it somehow  Warranty has expired |
|
|
|
Post by jj0 on Jan 30, 2021 16:34:24 GMT
Hey. My MAXI stopped responding Only the splash screen starts, then only a black screen Can I fix it somehow Warranty has expired You probably mean 'My Maxi stopped responding after I modded it with too many games'? Start at the first post in this thread (the FEL-mode for the Maxi) which should allow you to see the internal storage in Windows (or Linux) so you can restore it. |
|
|
|
Post by retrochlop on Jan 30, 2021 16:53:40 GMT
I've just found help The only problem is the USB cable haha ... This is how I screwed up MAXI by uploading too many games |
|
Done, now just log out or (PCU) press CTRL-RESTORE to restart.
Only the splash screen starts, then only a black screen 
Warranty has expired