I have downloaded this, checked the MD5 as correct, put it on a micro SD card and flashed the Mini210s board. I have tried this a few times with Linux and once with Android with different SD cards and on reboot I always get... Failed at 1 read What does it mean? If I go back to the previous version it's OK. Thanks Andy.
Have you flashed the ISO file or the image inside the ISO file?
I extracted the ISO, copied the images directory to the SD card and edited the ini file for what I wanted to install - I have done it a few times before over the years...
This issue is down to superboot.bin, use an older version.
Hi Reggie I think I had the old superboot fused to the card and the new one on the card. Tried with both being the old one and the new image would never get installed, got stuck at 34%. Made sure they were both the new superboot and it eventually installed but there are a lot more blocks skipped, and quite a few more ECC errors when booting and running than with the older image. Maybe it's a duff NAND chip? Skipped blocks beloooowwwww.... Installing OS 'LINUX' Installing bootloader... file: /images/Superboot210.bin: 528 KB(540672 Byte) Installing bootloader succeed Installing kernel... file: /images/Linux/zImage: 4 MB(4810580 Byte) Skip block 0x00000004 Skip block 0x00000005 Installing kernel succeed Installing yaffs2-image... file: /images/Linux/rootfs_qtopia_qt4-mlc2.img: 253 MB(265752384 Byte) Skip block 0x00000010 Skip block 0x00000011 Skip block 0x0000001A Skip block 0x0000001F Skip block 0x00000020 Skip block 0x00000021 Skip block 0x00000022 Skip block 0x00000023 Skip block 0x00000024 Skip block 0x00000025 Skip block 0x0000002B Skip block 0x00000031 Skip block 0x00000032 Skip block 0x00000046 Skip block 0x00000047 Skip block 0x0000004B Skip block 0x0000004C Skip block 0x0000004D Skip block 0x0000005B Skip block 0x00000076 Skip block 0x00000077 Skip block 0x00000078 Skip block 0x00000079 Skip block 0x0000007A Skip block 0x0000007B Skip block 0x0000007C Skip block 0x0000007D Skip block 0x0000007E Skip block 0x0000007F Skip block 0x00000080 Skip block 0x00000081 Skip block 0x00000082 Skip block 0x00000083 Skip block 0x00000084 Skip block 0x00000085 Skip block 0x00000086 Skip block 0x00000087 Skip block 0x00000088 Skip block 0x00000089 Skip block 0x0000008A Skip block 0x0000008B Skip block 0x0000008C Skip block 0x0000008D Skip block 0x0000008E Skip block 0x0000008F Skip block 0x00000090 Skip block 0x00000091 Skip block 0x00000092 Skip block 0x00000093 Skip block 0x00000094 Skip block 0x00000095 Skip block 0x00000096 Skip block 0x00000097 Skip block 0x00000098 Skip block 0x00000099 Installing yaffs2-image succeed OS 'LINUX' Installed
What version of superboot are you using? the version that I found to have the least issues so far is 1.1, I would also suggest doing a LowFormat=Yes in the friendlyarm.ini. The reason I suggest to do a low-format is if the nand has been poorly written to then the nand could appear 'bad' to the driver, so generally, at that point you would want to attempt a nand scrub and then re-write the bad block table, at least that's how it's done in general on boards that use u-boot. the LowFormat=Yes option is the closest sounding thing that we've got to scrubbing the nand and even then I'm not 100% certain that it does that but it seems to have gotten rid of bad block errors for me on 2 boards. I do question whether it's bad nand, I had a board recently that didn't have nand errors, flashed a new superboot, kernel, rootfs and got exactly your errors, reverted back to using 1.1 superboot LowFormat option and the kernel booted but got ecc errors on the nand, reverted back to an original android kernel(3.0.8) and rootfs 4.0.3 from the June 2012 DVD and things seem to be much better. I tried this method on a couple of mini210S with the same result.
The above was with Superboot 1.3 which does appear to have a problem. If I use the newer kernel and Superboot 1.1 I still get all the block errors on flashing and loads of ECC errors when it runs - and crashes... But the new kernel did not seem to exhibit the serial port problems I had with the old kernel - until it crashed. I did get an email from Charlie late Friday and he says they are working on it and he will hopefully get back to me on Monday. I agree, it's got to be code related as I have been writing embedded code for devices for many years and it's quite easy to screw up flash writing. I have now gone back to the original Superboot 1.1 and kernel and I think that the NAND is probably screwed up as it's taking ~4 to 5 mins to flash the rootfs, with low-format not really making any difference.
I have done some relatively extensive tests over the weekend, V1.13 breaks the nand. My testing consisted of using the kernel/android ics image from the 20120621 dvd and each of the SuperBoot210.bin files that we have access to: 1.6, 1.7, 1.10, 1.13 I used SD flasher to burn each version of superboot to the SD card and then burnt the corresponding version of superboot. The kernel/rootfs was burnt with the same friendlyarm.ini settings on each test (lowFormat=Yes) to nand. The first 3 versions of superboot all worked absolutely fine, no errors during burning, all booted android without any 'uncorrectable nand ecc errors'. V1.13 burnt everything to nand without errors but as soon as the kernel attempted to mount the rootfs partition, I got uncorrectable nand ecc errors, I reburnt to make sure that it wasn't just a coincidence and got exactly the same errors. I then proceeded to burn v1.10 to the SD card using sd-flasher and then reburnt the kernel and rootfs back onto the nand with the new superboot, rebooted and nand errors had disappeared. So, In conclusion, I believe there was an error introduced in v1.13 of superboot. As for the burning taking 4-5 minutes and low format, after you know the nand is borked due to software it's normal to scrub the nand and rebuild the bad block table, however, we don't have any direct command that we know of that does this, so I suggested LowFormat as it seemed to be the closest thing, the formatting is actually very quick, so I suspect that it might actually be scrubbing the nand when it does the writing, hence it taking longer with LowFormat=Yes.
I initially thought there were issues with the img files, so I looked at the tools FA supplied, they look like old, fixed versions of mkyaffs2image for different nand page sizes but as they are closed source, there's no way to tell exactly what they're doing. I looked on the net and found various yaffs2 utils around, all with their own quirks, some even broken between versions. A few months back I dumped the oob layout from the nand driver so I used this data in and source code to make a set of yaffs2utils that will read/write our own image files, with open source code. I have a mini210S here that has had the nand ecc errors for months, I stopped using the nand and just booted from SD, however I've been doing all of my testing on this unit, one thing that I noticed was that when I originally rolled back from superboot v1.13 to v1.10, I needed to do the lowformat, that fixed superboot but I still got errors, what fixed it for me was compiling my own kernel using the latest kernel sources and grabbing the s5p_nand_mlc.fo from the 20120913 kernel sources (that's the first release of the 3.0.8 source code).
I tried LowFormat but I think it does not take long enough to actually scrub the NAND. I think my NAND is completely screwed without getting some utility to recover it - maybe MetCal time if I can get some spare chips, it's only 0.5mm pitch... I have actually gone back to my Mini6410 as the code is the same until this is resolved. Thanks Andy.
yeah, agreed LowFormat is incredibly quick, it's over in a couple of seconds, but that's what makes me think it's being done at the write stage?
I know that bulk formatting can be quite quick and it could be doing that, but there is no way a bad block table could be built that quickly as it needs quite a lot doing - like write then read all the chip using checkerboard etc patterns to find stuck bits. Still not heard from Charlie, it's probably quite a deep problem to be fixed, considering it will have to be done to most units successfully who are already in the field...
Hi Andy, agreed, that's why I Thought it might be doing the bbt rewrite at the time it writes the files to the nand. I hadn't checked how long it was taking before you mentioned it, I really should time it again with and without low-format option turned on. It *always* skips 4 blocks on my nand when burning, so I'm assuming that these are factory marked bad blocks, so this also makes me wonder whether they're just leaving the blocks clean to be marked bad once the driver attempts to write to them? That having been said, the lowformat option without a doubt helps with my issues. I must also point out that I've performed the same tests on 2 mini210S boards now too and have identical results.