From: Udi Finkelstein <udif@bigfoot.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] DiskOnChip, filesystems, and other booting options
Date: Wed, 30 Apr 2003 13:20:04 +0300 [thread overview]
Message-ID: <3EAFA354.8010607@bigfoot.com> (raw)
In-Reply-To: <20030429210652.26979C5F48@atlas.denx.de>
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 @. at .....@.....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
next prev parent reply other threads:[~2003-04-30 10:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-25 8:13 [U-Boot-Users] DiskOnChip, filesystems, and other booting options Wolfgang Denk
2003-04-29 21:23 ` Udi Finkelstein
2003-04-29 21:06 ` Wolfgang Denk
2003-04-30 10:20 ` Udi Finkelstein [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-04-24 23:37 Udi Finkelstein
2003-04-24 23:18 ` Wolfgang Denk
2003-04-25 8:21 ` Udi Finkelstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EAFA354.8010607@bigfoot.com \
--to=udif@bigfoot.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox