|
Post by spannernick on Nov 25, 2020 21:09:45 GMT
Well I just tested my script and it worked... its working again, so your best bet is to use PCUAE with it, my nand already has Autoboot in it already so it will Autoboot PCUAE. I will change everything back to how it was before I changed the games and the music and see if I can update it then.
|
|
|
Post by spannernick on Nov 25, 2020 22:00:03 GMT
I just deleted all the games so it has no games in firmware and PCUAE still boots so it not the games causing it but could be space where you have not enough space for the update cause it has games included.
|
|
|
Post by refused75 on Nov 25, 2020 22:41:48 GMT
Thank you Nick, I am sorry you have messed up your mini for testing new firmware update. Sure you have immediatly recovered it through your new script. My view is that this "black screen" matter you got now is much more related to this 1.4.2 upgrade that maybe has some problems than related to your special carousel. I also remember now that the day when I got my "black screen" I had upgraded my mini to the new firmware 1.4.2 just few hours back.
So now after reading what happened to you I think that it's not
just a coincidence.
|
|
|
Post by spannernick on Dec 16, 2020 22:57:34 GMT
I just sorted out my THEC64 Mini with ESMT nand(had to put the original games back) and updated it to v1.4.2, and it worked, done, I will copy it as nanda and nandb too, you can get it here now, its in folder "backup_nand_V1.4.2_ESMT-C64Mini-PAL".
|
|
|
Post by grasshopper on Dec 17, 2020 12:03:09 GMT
Could this be made to work with the C64 Maxi? It would be nice to have a backup of last resort.
The nand_rw utility currently gives an error when run on the C64 Maxi, presumably because it has a different nand chip.
|
|
|
Post by jj0 on Dec 17, 2020 12:29:49 GMT
Could this be made to work with the C64 Maxi? It would be nice to have a backup of last resort. The nand_rw utility currently gives an error when run on the C64 Maxi, presumably because it has a different nand chip. nand_rw should work on the Maxi as well - it doesn't care about nand chip types/manufacturers but you do need to provide the pagesize and #of pages of the nand chip as parameters. What error do you get? And what nand id does it report?
|
|
|
Post by spannernick on Dec 17, 2020 12:56:10 GMT
how do get the pagesize and #of pages of the nand chip as parameters, from the ID...? is THEVIC20 nand the same as the maxi so can use the same parameters..?
|
|
|
Post by jj0 on Dec 17, 2020 13:05:49 GMT
how do get the pagesize and #of pages of the nand chip as parameters, from the ID...? is THEVIC20 nand the same as the maxi so can use the same parameters..? You look up the specifications by googling for the nand ID + manufacturer, or if you can read it on the nand chip itself the actual type number. That will most likely get you a pdf with specifications. In that pdf it will tell you the pagesize (use the one including OOB) and the total number of pages. Note: Don't use the extra info that nand_rw gives on pagesize and #of pages, that is usually wrong. I should really take that out, it was in the original source that I used.
|
|
|
Post by grasshopper on Dec 17, 2020 18:57:10 GMT
Could this be made to work with the C64 Maxi? It would be nice to have a backup of last resort. The nand_rw utility currently gives an error when run on the C64 Maxi, presumably because it has a different nand chip. nand_rw should work on the Maxi as well - it doesn't care about nand chip types/manufacturers but you do need to provide the pagesize and #of pages of the nand chip as parameters. What error do you get? And what nand id does it report? I just tried booting into FEL mode using your rescue image.
When I type "nand_rw read_id" I get the following error message:
Segmentation fault
It occurred to me that the error message might be because the nand module is automatically loaded by the init script. But when I type "rmmod nand" I get the following error message:
rmmod: ERROR: Module nand is in use
I presume it's in use because the nand partitions are being presented as mass storage devices to the PC. So I now need to work out how to reverse that operation, or create a new rescue image.....
|
|
|
Post by jj0 on Dec 18, 2020 8:41:19 GMT
nand_rw should work on the Maxi as well - it doesn't care about nand chip types/manufacturers but you do need to provide the pagesize and #of pages of the nand chip as parameters. What error do you get? And what nand id does it report? I just tried booting into FEL mode using your rescue image.
When I type "nand_rw read_id" I get the following error message:
Segmentation fault
It occurred to me that the error message might be because the nand module is automatically loaded by the init script. But when I type "rmmod nand" I get the following error message:
rmmod: ERROR: Module nand is in use
I presume it's in use because the nand partitions are being presented as mass storage devices to the PC. So I now need to work out how to reverse that operation, or create a new rescue image.....
nand_rw requires a delay and pagesize: / # nand_rw usage: nand_rw <delay> <pagesize> <command> ... <delay> is used to slow down operations (50 should work, increase in case of bad reads) Commands: read_id (no arguments) : read and decrypt chip ID read_full <page #> <# of pages> <output file> : read N pages including spare read_data <page #> <# of pages> <output file> : read N pages, discard spare write_full <page #> <# of pages> <input file> : write N pages, including spare write_data <page #> <# of pages> <input file> : write N pages, discard spare erase_blocks <block number> <# of blocks> : erase N blocks
Notes: This program assumes PAGE_SIZE == 0
So to read the ID: / # nand_rw 50 2112 read_id Raw ID data: 0xAD 0xDA 0x90 0x95 0x46
NAND manufacturer: Hynix (0xAD) NAND model: HY27UF082G2B (0xDA)
I/O|7|6|5|4|3|2|1|0| 3rd ID data: |1|0|0|1|0|0|0|0| (0x90) 4th ID data: |1|0|0|1|0|1|0|1| (0x95) 5th ID data: |0|1|0|0|0|1|1|0| (0x46)
Page size: 2048 bytes Block size: 131072 bytes RAS (/512 bytes): 16 bytes Organisation: 8 bit Serial access: 25ns minimum Number of planes: 2 Plane size: 134217728 bytes
NAND size: 256 MB NAND size + RAS: 256 MB Number of blocks: 2048 Number of pages: 131072
In this case the additional info displayed is correct, so #pages is 131072 and the OOB size = 2048/512*16=64 so pagesize = 2048+64=2112. But yes, the nand driver will get very confused if you do this. The main purpose of the FEL rescue is to restore nandb (and if needed nanda). But You can easily change the initrd to not load the nand driver.
|
|
|
Post by spannernick on Dec 18, 2020 12:18:35 GMT
I just tried booting into FEL mode using your rescue image. When I type "nand_rw read_id" I get the following error message: Segmentation fault It occurred to me that the error message might be because the nand module is automatically loaded by the init script. But when I type "rmmod nand" I get the following error message: rmmod: ERROR: Module nand is in use I presume it's in use because the nand partitions are being presented as mass storage devices to the PC. So I now need to work out how to reverse that operation, or create a new rescue image.....
nand_rw requires a delay and pagesize: / # nand_rw usage: nand_rw <delay> <pagesize> <command> ... <delay> is used to slow down operations (50 should work, increase in case of bad reads) Commands: read_id (no arguments) : read and decrypt chip ID read_full <page #> <# of pages> <output file> : read N pages including spare read_data <page #> <# of pages> <output file> : read N pages, discard spare write_full <page #> <# of pages> <input file> : write N pages, including spare write_data <page #> <# of pages> <input file> : write N pages, discard spare erase_blocks <block number> <# of blocks> : erase N blocks
Notes: This program assumes PAGE_SIZE == 0
So to read the ID: / # nand_rw 50 2112 read_id Raw ID data: 0xAD 0xDA 0x90 0x95 0x46
NAND manufacturer: Hynix (0xAD) NAND model: HY27UF082G2B (0xDA)
I/O|7|6|5|4|3|2|1|0| 3rd ID data: |1|0|0|1|0|0|0|0| (0x90) 4th ID data: |1|0|0|1|0|1|0|1| (0x95) 5th ID data: |0|1|0|0|0|1|1|0| (0x46)
Page size: 2048 bytes Block size: 131072 bytes RAS (/512 bytes): 16 bytes Organisation: 8 bit Serial access: 25ns minimum Number of planes: 2 Plane size: 134217728 bytes
NAND size: 256 MB NAND size + RAS: 256 MB Number of blocks: 2048 Number of pages: 131072
In this case the additional info displayed is correct, so #pages is 131072 and the OOB size = 2048/512*16=64 so pagesize = 2048+64=2112. But yes, the nand driver will get very confused if you do this. The main purpose of the FEL rescue is to restore nandb (and if needed nanda). But You can easily change the initrd to not load the nand driver. Is that the maxi nand..? I could add it to my nandrw.sh script but put a check in it to stop it running if you run the script on a THEC64 Mini so if you press that option its say it only works in FEL Mode on THEC64 Maxi/VIC20, I need to add THEC64 Mini NTSC nand to the script too.
|
|
|
Post by spannernick on Dec 18, 2020 12:44:25 GMT
nand_rw should work on the Maxi as well - it doesn't care about nand chip types/manufacturers but you do need to provide the pagesize and #of pages of the nand chip as parameters. What error do you get? And what nand id does it report? I just tried booting into FEL mode using your rescue image. When I type "nand_rw read_id" I get the following error message: Segmentation fault It occurred to me that the error message might be because the nand module is automatically loaded by the init script. But when I type "rmmod nand" I get the following error message: rmmod: ERROR: Module nand is in use I presume it's in use because the nand partitions are being presented as mass storage devices to the PC. So I now need to work out how to reverse that operation, or create a new rescue image.....
Your THEC64 Maxi boots...? then you can do this it get a shell up... 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 boot You will end up at a root shell running from the kernels ramdisk, then you can copy the whole nand with nand_rw, just do not start the kernel driver. so then.. mount /dev/sda1 /mnt cd /mnt ./nand_rw (command for your nand chip)
|
|
|
Post by jj0 on Dec 18, 2020 13:01:17 GMT
I just tried booting into FEL mode using your rescue image. When I type "nand_rw read_id" I get the following error message: Segmentation fault It occurred to me that the error message might be because the nand module is automatically loaded by the init script. But when I type "rmmod nand" I get the following error message: rmmod: ERROR: Module nand is in use I presume it's in use because the nand partitions are being presented as mass storage devices to the PC. So I now need to work out how to reverse that operation, or create a new rescue image.....
Your THEC64 Maxi boots...? then you can do this it get a shell up... 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 boot ---------------------------------- You will end up at a root shell running from the kernels ramdisk, then you can copy nand with nand_rw, just do not start the kernel driver. then.. -------------------------- mount /dev/sda1 /mnt cd /mnt ./nand_rw ........ -------------------------- Yes but he needs an UART connection for that.
|
|
|
Post by spannernick on Dec 18, 2020 13:07:28 GMT
Oh yes he's using Gadget Mode in Fel Mode on the THEC64 Maxi.. If when the drives come up of the nand and if you eject the nanda and nandb and just leave the USB stick up would the shell see the nand cause they are not mounted no more and able to copy it with nand_rw..?
|
|
|
Post by jj0 on Dec 18, 2020 15:25:14 GMT
Oh yes he's using Gadget Mode in Fel Mode on the THEC64 Maxi.. If when the drives come up of the nand and if you eject the nanda and nandb and just leave the USB stick up would the shell see the nand cause they are not mounted no more and able to copy it with nand_rw..? As long as the nand driver is loaded it will conflict with nand_rw, regardless whether nandb is mounted or not.. The nand_rw copy might still be valid though. It's hard to say...
|
|
|
Post by grasshopper on Dec 18, 2020 15:34:38 GMT
Hi, I've modified the FEL Rescue Boot Image so that it doesn't load the nand module, and doesn't enable mass storage over USB. The "nand_rw 50 2112 read_id" now works as expected (although I'm still not clear where the 50 and 2112 parameters come from).
I've found a data sheet for the nand chip which I've attached.
However, I'm not sure of the next step. Can anyone help?
Thanks
|
|
|
Post by grasshopper on Dec 18, 2020 16:22:18 GMT
Well when I type 'nand_rw 50 2112 read_id', I get the following output: Raw ID data: 0xAD 0xDA 0x90 0x95 0x46
NAND manufacturer: Hynix (0xAD) NAND model: HY27UF082G2B (0xDA)
I/O|7|6|5|4|3|2|1|0| 3rd ID data: |1|0|0|1|0|0|0|0| (0x90) 4th ID data: |1|0|0|1|0|1|0|1| (0x95) 5th ID data: |0|1|0|0|0|1|1|0| (0x46)
Page size: 2048 bytes Block size: 131072 bytes RAS (/512 bytes): 16 bytes Organisation: 8 bit Serial access: 25ns minimum Number of planes: 2 Plane size: 134217728 bytes
NAND size: 256 MB NAND size + RAS: 256 MB Number of blocks: 2048
Number of pages: 131072
That's the data I used to search for the data sheet.
|
|
|
Post by jj0 on Dec 18, 2020 16:56:30 GMT
Well when I type 'nand_rw 50 2112 read_id', I get the following output: Raw ID data: 0xAD 0xDA 0x90 0x95 0x46
NAND manufacturer: Hynix (0xAD) NAND model: HY27UF082G2B (0xDA)
I/O|7|6|5|4|3|2|1|0| 3rd ID data: |1|0|0|1|0|0|0|0| (0x90) 4th ID data: |1|0|0|1|0|1|0|1| (0x95) 5th ID data: |0|1|0|0|0|1|1|0| (0x46)
Page size: 2048 bytes Block size: 131072 bytes RAS (/512 bytes): 16 bytes Organisation: 8 bit Serial access: 25ns minimum Number of planes: 2 Plane size: 134217728 bytes
NAND size: 256 MB NAND size + RAS: 256 MB Number of blocks: 2048
Number of pages: 131072 That's the data I used to search for the data sheet.
The key info from the data sheet is: PAGE SIZE - (2K + 64 spare) Bytes
This tells you that the page size is 2048 (2K) bytes for data and 64 bytes for error correction etc. These 64 bytes are also called OOB (out-of-band) data. So page size + OOB =2112 bytes. This is confirmed again with: Hynix NAND HY27UF(08/16)2G2B Series have 256Mx8bit with spare 8Mx8 bit capacity.and The device contains 2048 blocks, composed by 64 pages. A program operation allows to write the 2112-byte page in typical 200us and an erase operation can be performed in typical 1.5ms on a 128K-byte blockThis also confirms the #of pages (2048 * 64=) 131072. But you can also calculate these from the nand size (256MB / 2048 = 131072). So the command to backup the entire nand from page 0 to page 131071 would be: nand_rw 50 2112 read_full 0 131072 My_first_C64_Maxi_Hynix_nand_backup_pagesize_2112_pages_131072.bin Instead of the delay of 50 you could also use 25 or 20, as long as you don't get more than 5 read errors per page it should be OK. A bad.log is created as well listing unreadable pages. To write back the data you first need to erase the nand and then write back tha pages: nand_rw 50 2112 erase_blocks 0 2048 nand_rw 50 2112 write_full 0 131072 My_first_C64_Maxi_Hynix_nand_backup_pagesize_2112_pages_131072.bin You can probably write back a backup of a different manufacturers nand as long as it has the same specs for pagesize+OOB and #of pages. Here are some other nand spec sheets (+Hynix).
|
|
|
Post by spannernick on Dec 18, 2020 17:20:46 GMT
Well when I type 'nand_rw 50 2112 read_id', I get the following output: Raw ID data: 0xAD 0xDA 0x90 0x95 0x46
NAND manufacturer: Hynix (0xAD) NAND model: HY27UF082G2B (0xDA)
I/O|7|6|5|4|3|2|1|0| 3rd ID data: |1|0|0|1|0|0|0|0| (0x90) 4th ID data: |1|0|0|1|0|1|0|1| (0x95) 5th ID data: |0|1|0|0|0|1|1|0| (0x46)
Page size: 2048 bytes Block size: 131072 bytes RAS (/512 bytes): 16 bytes Organisation: 8 bit Serial access: 25ns minimum Number of planes: 2 Plane size: 134217728 bytes
NAND size: 256 MB NAND size + RAS: 256 MB Number of blocks: 2048
Number of pages: 131072 That's the data I used to search for the data sheet.
The key info from the data sheet is: PAGE SIZE - (2K + 64 spare) Bytes
This tells you that the page size is 2048 (2K) bytes for data and 64 bytes for error correction etc. These 64 bytes are also called OOB (out-of-band) data. So page size + OOB =2112 bytes. This is confirmed again with: Hynix NAND HY27UF(08/16)2G2B Series have 256Mx8bit with spare 8Mx8 bit capacity.and The device contains 2048 blocks, composed by 64 pages. A program operation allows to write the 2112-byte page in typical 200us and an erase operation can be performed in typical 1.5ms on a 128K-byte blockThis also confirms the #of pages (2048 * 64=) 131072. But you can also calculate these from the nand size (256MB / 2048 = 131072). So the command to backup the entire nand from page 0 to page 131071 would be: nand_rw 50 2112 read_full 0 131072 My_first_C64_Maxi_Hynix_nand_backup_pagesize_2112_pages_131072.bin Instead of the delay of 50 you could also use 25 or 20, as long as you don't get more than 5 read errors per page it should be OK. A bad.log is created as well listing unreadable pages. To write back the data you first need to erase the nand and then write back tha pages: nand_rw 50 2112 erase_blocks 0 2048 nand_rw 50 2112 write_full 0 131072 My_first_C64_Maxi_Hynix_nand_backup_pagesize_2112_pages_131072.bin You can probably write back a backup of a different manufacturers nand as long as it has the same specs for pagesize+OOB and #of pages. Here are some other nand spec sheets (+Hynix).What is that nand for, THEC64 Mini..? how many are there..
|
|
|
Post by grasshopper on Dec 18, 2020 17:31:40 GMT
Thanks for the comprehensive answer.
I do have one more question though. Can you clarify how the nand_rw program deals with bad blocks?
I'm wondering what would happen if I took a backup of my C64 Maxi's nand chip, and then restored it to another C64 Maxi. Presumably the two nand chips might have bad blocks in different locations. Would the nand_rw program be able to adjust for that scenario?
|
|
|
Post by jj0 on Dec 18, 2020 19:01:44 GMT
Thanks for the comprehensive answer. I do have one more question though. Can you clarify how the nand_rw program deals with bad blocks? I'm wondering what would happen if I took a backup of my C64 Maxi's nand chip, and then restored it to another C64 Maxi. Presumably the two nand chips might have bad blocks in different locations. Would the nand_rw program be able to adjust for that scenario? The nand_rw program talks directly to the nand chip and does not manage page relocation nor ECC nor bad block managment. Those are all functions of a combination of the NAND Flash Controller of the A20 (Mini) or H3 (Maxi/VIC-20) SoC and the nand.ko driver. If nand_rw fails to write a page it retries 4 times (so total 5 attempts) before giving up. So yes, there is some risk associated with writing back a full nand backup, even to the same nand chip it came from. However for example I wrote back a copy of spannernick's Toshiba Mini nand to my Toshiba Mini nand and that worked out great.
|
|
|
Post by grasshopper on Dec 18, 2020 22:28:06 GMT
Thanks. That's kind of what I expected. I'll take a nand backup anyway, but I'll need to treat it as a not necessarily reliable means of unbricking the device. So, I guess we're back to needing the source code for the nand driver. According to modinfo it was written by a company called Soft-Reuuimlla. I did some googling on that name, and it appears that Reuuimlla is actually Allwinner written backwards, and partly upside down! The reasons why the name was changed appear to be bit murky. So it appears to be an Allwinner driver, or a derivative of one. I'm guessing the same driver is also used by other Allwinner devices that are fitted with a nand chip. So the source code could probably be found somewhere. But without the parameters that were used to build the source. it could still be difficult to make any progress.
|
|
|
Post by jj0 on Dec 20, 2020 11:47:53 GMT
Thanks. That's kind of what I expected. I'll take a nand backup anyway, but I'll need to treat it as a not necessarily reliable means of unbricking the device. So, I guess we're back to needing the source code for the nand driver. According to modinfo it was written by a company called Soft-Reuuimlla. I did some googling on that name, and it appears that Reuuimlla is actually Allwinner written backwards, and partly upside down! The reasons why the name was changed appear to be bit murky. So it appears to be an Allwinner driver, or a derivative of one. I'm guessing the same driver is also used by other Allwinner devices that are fitted with a nand chip. So the source code could probably be found somewhere. But without the parameters that were used to build the source. it could still be difficult to make any progress.
Most SDK's and released source codes for devices (like NES and SNES Mini) that use Allwinner SoC's have the critical part of the nand driver as binary blob library. The critical part (for me anyway) is the part where the parameters for various nand chips are defined,as that would need to be changed to add the Maxi's nand variants. I've tried to hexedit the Armbian legacy driver but while this leads to that driver to recognise the Fidelix/Hynix nand of my Maxi it still errors out. The difficulty is that there are a number of different Allwinner nand drivers, with a different number of bytes for the nand parameters. For example, the Maxi's driver used 72 bytes and the Armbian's driver 52.This is partly due to some parameters increasing from e.g. single bytes to multiple bytes but also additional parameters being added. There is a full source of the nand driver for the A20 SoC that the Mini uses in the linux-sunxi source: github.com/linux-sunxi/linux-sunxi/tree/sunxi-3.4/drivers/block/sunxi_nandAnd also in the official Allwinner source, for more models but not the H3: github.com/allwinner-zh/linux-3.4-sunxi/tree/master/modules/nand
|
|