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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.