Re: ubifs/NAND problem?
On Mon, 2012-01-16 at 00:26 +0100, Boudewijn wrote: [log journey skipped] Choosing the NAND/ubi-zlib boot option, there were some warnings, I guess relating to running SHRs kernel on QtMoko. Anyway, QtMoko booted! Gennady, thank you! :-) You welcome =) Actually all is simple with this ubi stuff, misleading is that Qi hiding all kinds of logs from users and can't display any status information on screen and uses compiled-in kernel parameters. And may be yes, I never tried to study question but flashing with latest u-boot differers from flashing with older NOR version, so may be flashing u-boot to nand and using it to flash data to other partitions has some sense. Gennady ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ubifs/NAND problem?
Hi List, I have problems with NAND, it seems, but I don't know how to troubleshoot it. For a while I have been unable to boot SHR from NAND, but since I had another install on uSD, it didn't really matter. Lately I wanted to move to NAND anyway, to free up the relatively fast uSD for my Phoenux. The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). No better result either. (For a moment I thought the MD5 sum was incorrect, downloaded again and flashed, but it turned out Sourceforge hid part of the sum when there's no mouseover). I used to be able to mount jffs2-partitions, but mounting ubifs seems a bit different (or broken otherwise in my installation) I have tried: - using the mtdblock6-device - using the ubi-device (not available) [1] - using the device-less method [1] - using ubiattach (might create a dev node, but segfaults on mtd6 and hangs on mtd6ro I guess ubifs is in the kernel; there's no such thing as ubi in lsmod, and modprobe ubifs returns an error. I added the modules from SHR-core, but they do not include UBI. dmesg gives some info, see attached text for a bit more: [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 What does it try tell me? What can I do about it? Boudewijn [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 [ 1274.33] pgd = c6ff [ 1274.33] [00100104] *pgd=36ed6831, *pte=, *ppte= [ 1274.33] Internal error: Oops: 817 [#1] [ 1274.33] last sysfs file: /sys/class/ubi/version [ 1274.33] Modules linked in: snd_soc_wm8753 snd_soc_s3c24xx snd_soc_neo1973_wm8753 snd_soc_s3c24xx_i2s snd_soc_dfbmcs320 snd_soc_core snd_pcm snd_timer snd soundcore snd_page_alloc rfcomm ppp_generic slhc ohci_hcd usbcore ipv6 hidp g_ether s3c2410_udc bnep bluetooth ar6000 [ 1274.33] CPU: 0Not tainted (2.6.39.4 #1) [ 1274.33] PC is at kmem_cache_destroy+0x40/0xfc [ 1274.33] LR is at kmem_cache_destroy+0x34/0xfc [ 1274.33] pc : [c0098a50]lr : [c0098a44]psr: 6013 [ 1274.33] sp : c6f77e30 ip : 0004 fp : 0200 [ 1274.33] r10: c6f2dcb4 r9 : c6f2dcb4 r8 : c03f2528 [ 1274.33] r7 : ffea r6 : c6f2dcac r5 : c6f2dca0 r4 : c78bf4e0 [ 1274.33] r3 : 00200200 r2 : 00100100 r1 : c78bf4e0 r0 : c78bf4e0 [ 1274.33] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 1274.33] Control: c000717f Table: 36ff DAC: 0015 [ 1274.33] Process ubiattach (pid: 787, stack limit = 0xc6f76270) [ 1274.33] Stack: (0xc6f77e30 to 0xc6f78000) [ 1274.33] 7e20: c6f2dca0 c01fc0c4 c6f2dca0 [ 1274.33] 7e40: c6f51800 ffea c03f2528 c01fc3e8 00d2 c01f40d0 [ 1274.33] 7e60: 00d0 c6f2dcac 37d3 c7973800 c6f2dcbc c6f51800 c6f2dca4 c0092a40 [ 1274.33] 7e80: 00d2 37d3 c7973800 c6f51800 c7973800 0800 [ 1274.33] 7ea0: 0200 c01f40e4 c6f77ec4 07ff 0068 c7810260 c7409834 bef07ae8 [ 1274.33] 7ec0: c7973800 40186f40 0003 c0026fe4 c6f76000 b858 c01f49b0 [ 1274.33] 7ee0: 0006 c797cb94 bef07ae8 [ 1274.33] 7f00: 40186f40 c00a9194 c6fe8005 c740bdd4 c797cb94 0101 0004 [ 1274.33] 7f20: c6e8a228 bf54 00014a3c c6f75560 [ 1274.33] 7f40: 0003 c6fe8000 c6e8a220 0003 c6e8a228 0020 [ 1274.33] 7f60: c6fe8000 c6e8a220 bef07ae8 40186f40 0003 c0026fe4 c6f76000 [ 1274.33] 7f80: b858
Re: ubifs/NAND problem?
On Sunday 15 January 2012 18:10:11 Boudewijn wrote: Hi List, I have problems with NAND, it seems, but I don't know how to troubleshoot it. For a while I have been unable to boot SHR from NAND, but since I had another install on uSD, it didn't really matter. Lately I wanted to move to NAND anyway, to free up the relatively fast uSD for my Phoenux. The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). No better result either. (For a moment I thought the MD5 sum was incorrect, downloaded again and flashed, but it turned out Sourceforge hid part of the sum when there's no mouseover). I used to be able to mount jffs2-partitions, but mounting ubifs seems a bit different (or broken otherwise in my installation) I have tried: - using the mtdblock6-device - using the ubi-device (not available) [1] - using the device-less method [1] - using ubiattach (might create a dev node, but segfaults on mtd6 and hangs on mtd6ro I guess ubifs is in the kernel; there's no such thing as ubi in lsmod, and modprobe ubifs returns an error. I added the modules from SHR-core, but they do not include UBI. dmesg gives some info, see attached text for a bit more: [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 What does it try tell me? What can I do about it? Boudewijn By the way, I noticed the partitions start at 0, so partition 6 is 7, so I repeated with 5 instead. It does not segfault, it just hangs (ctrl-c gives no response other than printingg ^C, ctrl-d does not quit the session). No new mention of attach or ubi in dmesg either. Boudewijn smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
Am Sonntag, 15. Januar 2012, 18:10:11 schrieb Boudewijn: [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 What does it try tell me? What can I do about it? I have to specify the data offset manually. Try passing the options ubi.mtd=6,2048 root=ubi0:name_of_rootfs or ubi.mtd=6,2048 root=ubi0_0 to kernel or use ubiattach -m 6 -O 2048 at commandline. Rico signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sun, 15 Jan 2012 18:10:11 +0100 Boudewijn wankelwan...@yahoo.com wrote: Hi List, I have problems with NAND, it seems, but I don't know how to troubleshoot it. For a while I have been unable to boot SHR from NAND, but since I had another install on uSD, it didn't really matter. Lately I wanted to move to NAND anyway, to free up the relatively fast uSD for my Phoenux. The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). No better result either. (For a moment I thought the MD5 sum was incorrect, downloaded again and flashed, but it turned out Sourceforge hid part of the sum when there's no mouseover). Hi Boudewijn, I had a similar problem, couldn't boot anything from NAND(qi or uboot the same). Jffs worked fine. While trying different UBIFS distributions I have accidently flashed kernel to where bootloader should be. Reflashed everything as it should be, and the phone started to boot from NAND. The distrib was QtMoko v35. I think there could be some wrong data or bad blocks somewhere that were erased by flashing kernel to the wrong place. Or some bug was fixed in qi or kernel. Cant check. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 18:58:29 Rico Rommel wrote: Am Sonntag, 15. Januar 2012, 18:10:11 schrieb Boudewijn: [ 1274.33] UBI: attaching mtd6 to ubi0 [ 1274.33] UBI: physical eraseblock size: 131072 bytes (128 KiB) [ 1274.33] UBI: logical eraseblock size:129024 bytes [ 1274.33] UBI: smallest flash I/O unit:2048 [ 1274.33] UBI: sub-page size: 512 [ 1274.33] UBI: VID header offset: 512 (aligned 512) [ 1274.33] UBI: data offset:2048 [ 1274.33] UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512 [ 1274.33] UBI error: validate_ec_hdr: bad EC header [ 1274.33] UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0 [ 1274.33] Unable to handle kernel paging request at virtual address 00100104 What does it try tell me? What can I do about it? I have to specify the data offset manually. Try passing the options ubi.mtd=6,2048 root=ubi0:name_of_rootfs or ubi.mtd=6,2048 root=ubi0_0 to kernel or use ubiattach -m 6 -O 2048 at commandline. Rico Thanks, that works. I used the commandline, which gave me /dev/ubi0_0 (and equally /dev/ubi0), besides /dev/ubi_ctrl. After that I can mount -t ubifs /dev/ubi0_0 /mnt/ and it nicely shows my QtMoko v35 installation. I tried the same with partitions 0-5, but no luck there (either with/without - O 2048; perhaps they need another offset). The fact that no distro will boot gives reason to think that the kernel partition has a problem. I consulted the wiki to find out which offset might be applicable, and found the bad blocks [1] page. I could find out which blocks are not good using u-boot: The u-boot command nand bad lists the offsets of the bad blocks. I'm not experienced in either serial interfacing nor calculating between memory mappings and partition tables. I have an idea what to do, but not clear enough to start right away. If other things fail, I'll give it a try anyway :-) I'll first give Ivans method of flashing a way to big file to a partition a try, it might shake up things enough to start writing to a good location afterward. (I guess it will just start complaining about lack of space, instead of breaking more than I intended...) Boudewijn [1] http://wiki.openmoko.org/wiki/NAND_bad_blocks smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote: On Sun, 15 Jan 2012 18:10:11 +0100 Boudewijn wankelwan...@yahoo.com wrote: Hi List, I have problems with NAND, it seems, but I don't know how to troubleshoot it. For a while I have been unable to boot SHR from NAND, but since I had another install on uSD, it didn't really matter. Lately I wanted to move to NAND anyway, to free up the relatively fast uSD for my Phoenux. The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). No better result either. (For a moment I thought the MD5 sum was incorrect, downloaded again and flashed, but it turned out Sourceforge hid part of the sum when there's no mouseover). Hi Boudewijn, I had a similar problem, couldn't boot anything from NAND(qi or uboot the same). Jffs worked fine. While trying different UBIFS distributions I have accidently flashed kernel to where bootloader should be. Reflashed everything as it should be, and the phone started to boot from NAND. The distrib was QtMoko v35. I think there could be some wrong data or bad blocks somewhere that were erased by flashing kernel to the wrong place. Or some bug was fixed in qi or kernel. Cant check. Thanks for the suggestion! I actually started writing as a follow-up to your thread, but since you started out with v36 and ended with v35 I started a new one (I started with v35 a couple of times right away) If I understand correctly, you now use UBI, not jffs, don't you? If all goes well, I can send success in a couple of minutes :-) Boudewijn smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 22:53:24 Boudewijn wrote: On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote: On Sun, 15 Jan 2012 18:10:11 +0100 Boudewijn wankelwan...@yahoo.com wrote: Hi List, I have problems with NAND, it seems, but I don't know how to troubleshoot it. For a while I have been unable to boot SHR from NAND, but since I had another install on uSD, it didn't really matter. Lately I wanted to move to NAND anyway, to free up the relatively fast uSD for my Phoenux. The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). No better result either. (For a moment I thought the MD5 sum was incorrect, downloaded again and flashed, but it turned out Sourceforge hid part of the sum when there's no mouseover). Hi Boudewijn, I had a similar problem, couldn't boot anything from NAND(qi or uboot the same). Jffs worked fine. While trying different UBIFS distributions I have accidently flashed kernel to where bootloader should be. Reflashed everything as it should be, and the phone started to boot from NAND. The distrib was QtMoko v35. I think there could be some wrong data or bad blocks somewhere that were erased by flashing kernel to the wrong place. Or some bug was fixed in qi or kernel. Cant check. Thanks for the suggestion! I actually started writing as a follow-up to your thread, but since you started out with v36 and ended with v35 I started a new one (I started with v35 a couple of times right away) If I understand correctly, you now use UBI, not jffs, don't you? If all goes well, I can send success in a couple of minutes :-) What I did: - flash kernel partition with random 27-meg PDF - flash boot partition with kernel image - boot in u-boot (NOR) -- wrong image, returning to u-boot-menu - reboot in u-boot (NOR) -- booting SHR from uSD using Qi -- Qi is not broken? I have not patched my u-boot (NOR) in any way to cope with large kernels or other filesystems. I used neotool for flashing. It seems it did not flash the kernel partition: bytes_per_hash=539430 Copying data from PC to DFU device Starting download: [Resetting USB to switch back to runtime mode (there are no hashes showing the download, so maybe nothing is downloaded) Some data got downloaded to the boot partition, but fewer hashes (of more bytes) than usual: bytes_per_hash=44949 Copying data from PC to DFU device Starting download: [#Resetting USB to switch back to runtime mode On second try, I used a PDF of 3 MB for the kernel partition, and a 1 MB PDF for boot. This time the kernel downloaded as supposed, and the boot loader has more hashes, but Qi runs anyway. Third time I skipped the kernel partition, and downloaded a 40k-log as boot loader. That gave a long enough hash-line (smaller hashes, of course). Funny enough, this time DFU-util exited with an error (Thanks Thormod/Stephan!): bytes_per_hash=806 Copying data from PC to DFU device Starting download: [##] finished! state(10) = dfuERROR, status(1) = File is not targeted for use by this device Finally I downloaded the QtMoko-files (kernel v35 and qi v35), removed USB and battery, reconnected power supplies and sat back. SHR. No offense, SHR is nice enough ;-) But not what I had in mind for tonight. I did notice something I was looking for earlier on the u-boot screen. The DFU-util log says: Starting Atomic DFU DOWNLOAD to partition 'u-boot' device 0 offset 0x4, size 0x4 (BBT address? Too slow typing to catch it before FR shut down)... At least I got some offset for dev 0 now, but I come to realize that it's not UBI at all, so no gain here. Sorry for the long story. TL;DR: I overwrote my boot partition and kernel partition with useless (in this context) data multiple times. I expected Qi to break at some point, but it didn't. It also did not become unbroken: it refuses to boot the kernel in NAND. Any pointer? Boudewijn PS: For now I'll start reading about u-boot on the wiki. smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
On Sunday 15 January 2012 23:29:58 Boudewijn wrote: On Sunday 15 January 2012 22:53:24 Boudewijn wrote: On Sunday 15 January 2012 21:56:04 Ivan Matveev wrote: On Sun, 15 Jan 2012 18:10:11 +0100 Boudewijn wankelwan...@yahoo.com wrote: The Freerunner still won't boot from NAND though. I reflashed with SHR-core (and SHR's ubi-qi), to no avail. After that I flashed QtMoko v35 (and QtMoko's qi v35). Hi Boudewijn, I had a similar problem, couldn't boot anything from NAND(qi or uboot the same). Jffs worked fine. While trying different UBIFS distributions I have accidently flashed kernel to where bootloader should be. Reflashed everything as it should be, and the phone started to boot from NAND. Thanks for the suggestion! I actually started writing as a follow-up to your thread, but since you started out with v36 and ended with v35 I started a new one (I started with v35 a couple of times right away) TL;DR: I overwrote my boot partition and kernel partition with useless (in this context) data multiple times. I expected Qi to break at some point, but it didn't. It also did not become unbroken: it refuses to boot the kernel in NAND. Any pointer? Boudewijn PS: For now I'll start reading about u-boot on the wiki. First achievement after downloading gena2x' u-boot to the FR: Qi is gone. After that, I downloaded Qi again, resulting in a booting SHR from uSD. For now I'll focus my attention on the kernel partition; the boot loader seems OK. I downloaded one of the last SHR-kernels (2.6.39-xx16...), to see if anything happened. That's not the case: upon booting I still get SHR from uSD, not QtMoko with a SHR kernel and a crash after half a minute. Lacking a crash, a boot log or anything except a running SHR, I turned back to u-boot, and continued following gena2x' excellent howto. Lacking a running environment to copy the Qi-settings from, I started off with his sample config. Now I got somewhere: using the boot jffs from NAND option crashed the UBI- kernel (once again, I realize there's UBI to be had here anyway ;-) ) Just before the crash (unable to mount root fs on unknown-block(0,0) ), it listed the list of all partitions, with addresses (and driver? behind every item). With some luck, those are all jffs-driver on UBI-fs errors. Choosing the NAND/ubi-zlib boot option, there were some warnings, I guess relating to running SHRs kernel on QtMoko. Anyway, QtMoko booted! Gennady, thank you! :-) Boudewijn smime.p7s Description: S/MIME cryptographic signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ubifs/NAND problem?
For the record, I've never had ubifs work by flashing an image using dfu-util. I did get it to work using nandwrite though! Basically boot into your working uSD install and put your ubifs image on there. Then use nandwrite to flash it into nand (it's also much faster than dfu-util). See http://wiki.openmoko.org/wiki/Ubifs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
