Re: [U-Boot-Users] DiskOnChip, filesystems, and other booting options
Dear Udi,
in message 01qhav4dc6n97kctt8ob8f9qsjrva8v3sm@4ax.com you wrote:
Yes, I know about these - what I meant was that the D.O.C support is still at the sector level, without any filesystem support.
Right.
IMHO all filesystem stuff for U-Boot should be split into a separate layer (standalone applications acting as second stage bootstrap loaders).
As far as I know (correct me if I'm wrong), NFTL does block-level remapping of bad blocks as well as wear levering by constantly changing the logical<>physical sector mapping on each write (so that if you write the same "logical" sector 1000 times it would spread over all the flash).
So they claim to do.
If my understanding is accurate, how can I use the U-Boot raw sectors without disturbing the NFTL mapping that is handled by the Linux MTD package?
I think that the "binary partition" is not subject to this, i. e. you can do direct I/O with the binary partition on the DoC.
Besides, I've peeked into the D.O.C code in U-boot and it's full of NFTL references. In fact, as far as I can see, binary partitions are part of NFTL.
Yes.
I've been looking at the files in fs/fdos/... and the CMD_FDC, CMD_FDOS code which calls them., and I see it contains complete code to read a FAT filesystem.
Something to be cleaned up and implemented in a more general way...
I understand from the above that I don't need it, but just for the sake of understanding - couldn't I drop the NFTL+normal filesystem and use JFFS2 over the raw D.O.C sectors, since JFFS2 does bad block mapping and wear levering (or does it??)
I don't know if it is possible to extend the size of the binary partition to cover the whole device.
OK, so where to I stand now?
- My kernel correctly identifies the D.O.C but for some reason manages
to mount it only partially. /dev/mtdchar0 is non functional, but /dev/nftla seems to work between reboots. I can correctly partition the D.O.C using fdisk, and the format is kept when I leave fdisk and re-run it, btu once I reboot, all the partitioning done is lost.
That rings a bell to me. We fixed exactly such a problem once.
In the old version of the code some internal data structures of the NFTL driver, which are initialized only at boot-time, become invalid after you run nftl_format.
See my message "DOC / NFTL problem, and fix" from Aug 28, 2002, to the MTD mailing list: http://lists.infradead.org/pipermail/linux-mtd/2002-August/005853.html I don't know if they ever accepted the patch, and/or if it is included with your version of the MTD tools. Just in case I attach this patch again below.
I think this part of my questions should be sent to the MTD list I guess.
Agreed.
Best regards,
Wolfgang Denk
On Fri, 25 Apr 2003 10:13:42 +0200, Wolfgang Denk wd@denx.de wrote:
OK, so where to I stand now?
- My kernel correctly identifies the D.O.C but for some reason manages
to mount it only partially. /dev/mtdchar0 is non functional, but /dev/nftla seems to work between reboots. I can correctly partition the D.O.C using fdisk, and the format is kept when I leave fdisk and re-run it, btu once I reboot, all the partitioning done is lost.
That rings a bell to me. We fixed exactly such a problem once.
In the old version of the code some internal data structures of the NFTL driver, which are initialized only at boot-time, become invalid after you run nftl_format.
See my message "DOC / NFTL problem, and fix" from Aug 28, 2002, to the MTD mailing list: http://lists.infradead.org/pipermail/linux-mtd/2002-August/005853.html I don't know if they ever accepted the patch, and/or if it is included with your version of the MTD tools. Just in case I attach this patch again below.
OK, I've taken the patch, and it's not in the latest linuxppc_2_4 tree on which I'm working (when I began working, this was 2.4.20-pre7 I think its now in -rc1).
I had to do only minimal changes (one actually - ioctl no. 9 and 10 were occupied, so now your MEMREVALIDATE ioctl is now 11 instead of 9).
Surprisingly (or not...), my /dev/nftla partition now works! I formatted it under ext2 and it survived reboots without getting corrupted.
Now I have another problem - when I write my working kernel on the doc at sector 0, and read it back, booting it fails with a CRC error, and 'cmp' fails.
when I look at the first 16-32 bytes before/after saving/loading the image on the DOC, it seems that the corruption is only at part of the image, and that its reproducible (retrying get the same corruption).
I think this part of my questions should be sent to the MTD list I guess.
Peeking at the latest CVS code for MTD, it seems the codebase got very far off the MTD snapshot we use.
Agreed.
Best regards,
Wolfgang Denk
thanks, Udi
In message hkqtav4smc76q8ureekpjol3rfslt3q6mj@4ax.com you wrote:
OK, I've taken the patch, and it's not in the latest linuxppc_2_4 tree on which I'm working (when I began working, this was 2.4.20-pre7 I think its now in -rc1).
This is what I expected :-(
Surprisingly (or not...), my /dev/nftla partition now works! I formatted it under ext2 and it survived reboots without getting corrupted.
Fine.
Now I have another problem - when I write my working kernel on the doc at sector 0, and read it back, booting it fails with a CRC error, and 'cmp' fails.
How _exactly_ do you erase + format + write your DoC? Maybe you can show a full log?
when I look at the first 16-32 bytes before/after saving/loading the image on the DOC, it seems that the corruption is only at part of the image, and that its reproducible (retrying get the same corruption).
F'up to MTD?
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message hkqtav4smc76q8ureekpjol3rfslt3q6mj@4ax.com you wrote:
Now I have another problem - when I write my working kernel on the doc at sector 0, and read it back, booting it fails with a CRC error, and 'cmp' fails.
How _exactly_ do you erase + format + write your DoC? Maybe you can show a full log?
The ease and nftl_format commands were done exactly as they appeared in the CPU86 PPCBoot manual, except for the fact that I've used a 1MB binary partition on a 8MB Millenium DOC.
eraseall /dev/mtdchar0 nftl_format /dev/mtdchar0 0x00100000
Once I rebooted back to the u-boot prompt, I ran the following (I have 16MB SDRAM mapped from 0x00000000 to 0x007fffff): ------------------------------------------------------------- => tftp 500000 uImage ARP broadcast 1 TFTP from server 10.10.10.4; our IP address is 10.10.10.8 Filename 'uImage'. Load address: 0x500000 Loading: ################################################################# ################################################################# ## done Bytes transferred = 670984 (a3d08 hex) => doc write 500000 0 $(filesize)
DOC write: device 0 offset 0, size 670984 ... 670984 bytes write: OK =>
DOC read: device 0 offset 0, size 670984 ... 670984 bytes read: OK => cmp 500000 600000 100 word at 0x00500004 (0xbaa4a195) != word at 0x00600004 (0xa8a0a185) Total of 1 word were the same => => md 500000 20 00500000: 27051956 baa4a195 3eaea814 000a3cc8 '..V....>.....<. 00500010: 00000000 00000000 8d06d069 05070201 ...........i.... 00500020: 4c696e75 78204b65 726e656c 20496d61 Linux Kernel Ima 00500030: 67650000 00000000 00000000 00000000 ge.............. 00500040: 1f8b0808 10a8ae3e 02036c69 6e75782e .......>..linux. 00500050: 62696e00 e45a7f70 1475967f dd33931f bin..Z.p.u...3.. 00500060: 24a72376 c8484832 232c9bc0 380e0ad2 $.#v.HH2#,..8... 00500070: f383d041 7407c2e9 4025240a 9e13c3d6 ...At...@%$..... => md 600000 20 00600000: 27051956 a8a0a185 3eae0014 000a0080 '..V....>....... 00600010: 00000000 00000000 88029048 05070201 ...........H.... 00600020: 4c696e75 78204b65 726e656c 20496d61 Linux Kernel Ima 00600030: 67650000 00000000 00000000 00000000 ge.............. 00600040: 1f8b0808 1000ae3e 02036c69 6e75782e .......>..linux. 00600050: 62696e00 e45a7f70 1475967f dd33931f bin..Z.p.u...3.. 00600060: 24a72376 c8484832 232c9bc0 380e0ad2 $.#v.HH2#,..8... 00600070: f383d041 740782c1 00000000 1c038284 ...At........... => doc write 500000 200 $(filesize)
DOC write: device 0 offset 512, size 670984 ... 670984 bytes write: OK =>
DOC read: device 0 offset 512, size 670984 ... 670984 bytes read: OK => cmp 500000 700000 100 word at 0x00500000 (0x27051956) != word at 0x00700000 (0x24001042) Total of 0 words were the same => => md 700000 00700000: 24001042 32000080 0ca82000 00083400 $..B2..... ...4. 00700010: 00000000 00000000 04020001 04040201 ................ 00700020: 00216e65 10200245 00202528 00412160 .!ne. .E. %(.A!` 00700030: 41040000 00000000 00000000 00000000 A............... 00700040: 18010000 0000a600 00020029 00500008 ...........).P.. 00700050: 20080000 04100000 00001004 8410820b ............... 00700060: 00a20200 00480000 20009900 28080800 .....H.. ...(... 00700070: 40004000 00020000 40050400 18114156 @.@.....@.....AV => doc write 500000 0 $(filesize)
DOC write: device 0 offset 0, size 670984 ... 670984 bytes write: OK => doc read 300000 0 $(filesize)
DOC read: device 0 offset 0, size 670984 ... 670984 bytes read: OK => => cmp 300000 500000 100 word at 0x00300004 (0xa8a0a185) != word at 0x00500004 (0xbaa4a195) Total of 1 word were the same => => cmp 300000 600000 100 word at 0x00300200 (0x24001042) != word at 0x00600200 (0xe4221062) Total of 128 words were the same => -------------------------------------------------------------
Also, once I tried this, and then rebooted once again to Linux using a tftp'ed kernel and NFS root, I found out that the DOC was completely corrupted. A perfectly valid ext2 partition mounted on /dev/nftla1 that worked completely fine before (including multiple reboots that did not use the doc read/write U-boot commands), was now non-recognized to the point of fdisk not finding my partition table.
F'up to MTD?
Its no longer an MTD issue per-se, since the problematic code lines in u-boot.
Best regards,
Wolfgang Denk
thanks, Udi
participants (2)
-
Udi Finkelstein -
Wolfgang Denk