[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Wolfgang Denk]

Dear Udi,

in message <fsrgav0iq16cgicc588ms3p7nvc2gtogbb@4ax.com> you wrote:
> 
> In an ideal world, I would like the DiskOnChip to be:

Maybe you can find some useful information in  section  ``7.3.  Using
Disk On Chip "Drives"'' at
http://www.denx.de/doc/CPU86/advanced-topics.html#DISK-ON-CHIP

> 1. Partition into one or more partitions

You can use "nftl_format" to crewate a "binary partition"  (which  is
ideal  to  hold  one  or  more  Linux  kernel images) and you can use
"fdisk" to partition the remainder of the DoC in the classical way.

> 2. Boot the kernel from a file in one of the partitions (could be FAT)

Put the kernel in the binary partition, and boot it from there.

Or extend U-Boot and add MSDOS filesystem support.

> 3. mount root from separate partition, (if kernel is on FAT), or same
> partition as the kernel (if possible).

Put the kernel in the binary partition, and mount one of teh  regular
partitions as root filesystem.

> I'm slightly confused as to the status of JFFS2, DOS partitioning, DOS
> FAT/VFAT, and the DiskOnChip support. More specifically:

JFFS2 has nothing to do with  this.  DOS  FAT/VFAT  support  is  non-
existent.

> 1. As far as I can tell, the only DiskOnChip support are the "doc read" and
> "doc write" commands, therefore if I use these commands I must load the kernel
> directly off the raw sectors - no filesystem support whatsoever. Am I correct?

No, you are not correct.

First, the "doc" command provides more sub-commands, like "doc  info"
or "doc erase".

"help doc" helps ;-)


> 2. Does the "doc read" and "doc write" use the NFTL layer, or do they access
> the raw device sectors?

They do not use NFTL. They use raw binary offset addresses.


> 3. As far as I can tell, the FAT support is hardwired to the floppy controller
> device, and the DOS partition support is wired to the IDE support. Am I right?

???


> It seems to me it is quite trivial to construct a simple interface (a struct
> containing the block device geometry, plus a pointer to sector read function),
> and have both the partitioning and the DOS FAT code access this. This could
> help support DOS filesystems on D.O.C, floppies and IDE devices.

Are you talking about U-Boot or Linux here?


> 4. What is the best way to achieve my requirements above? (booting a kernel
> from a filesystem on the D.O.C). Can JFFS2 help me in any way?

See  the  document  mentioned  above.  It  contains  pretty  detailed
instructions. And no, JFFS2 has nothing to do with it.

> 5. Failing all the above, can I partition the device under Linux into 2
> partitions, write down the sector range for the 1st partition, and use it  to
> read/write the kernel using the "doc read" and "doc write interface"?
> I would then mount the 2nd partition after booting the kernel.

Yes, you can do that. See above.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
All easy problems have already been solved.

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Udi Finkelstein]

Hello everyone,

I've finished porting U-boot 0.3.0 to my MPX823 board. It contains a 512KB
29LV040 that boots u-boot, an extra 8MB DiskOnChip Millenium, and an Ethernet
controller (it contains other hardware as well, but that's not relevant).

I can now successfully boot the board into Linux by tftp'ing the kernel, and
using root nfs (exported NFS is /opt/eldk/ppc_8xx - thanks Worlfgang!).

I compiled my own kernel based on the latest linuxppc_2_4 CVS branch.
I can successfully access my DiskOnchip under both u-boot and Linux.

I now want to boot my board from the on-board Flash.

In an ideal world, I would like the DiskOnChip to be:
1. Partition into one or more partitions
2. Boot the kernel from a file in one of the partitions (could be FAT)
3. mount root from separate partition, (if kernel is on FAT), or same
partition as the kernel (if possible).

I'm slightly confused as to the status of JFFS2, DOS partitioning, DOS
FAT/VFAT, and the DiskOnChip support. More specifically:

1. As far as I can tell, the only DiskOnChip support are the "doc read" and
"doc write" commands, therefore if I use these commands I must load the kernel
directly off the raw sectors - no filesystem support whatsoever. Am I correct?

2. Does the "doc read" and "doc write" use the NFTL layer, or do they access
the raw device sectors?

3. As far as I can tell, the FAT support is hardwired to the floppy controller
device, and the DOS partition support is wired to the IDE support. Am I right?
It seems to me it is quite trivial to construct a simple interface (a struct
containing the block device geometry, plus a pointer to sector read function),
and have both the partitioning and the DOS FAT code access this. This could
help support DOS filesystems on D.O.C, floppies and IDE devices.

4. What is the best way to achieve my requirements above? (booting a kernel
from a filesystem on the D.O.C). Can JFFS2 help me in any way?

5. Failing all the above, can I partition the device under Linux into 2
partitions, write down the sector range for the 1st partition, and use it to
read/write the kernel using the "doc read" and "doc write interface"?
I would then mount the 2nd partition after booting the kernel.

thanks,
Udi

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Wolfgang Denk]

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?
> 1. 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Do not underestimate the value of print statements for debugging.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: mtd_nftl.patch
Type: application/x-patch
Size: 6104 bytes
Desc: mtd_nftl.patch
Url : http://lists.denx.de/pipermail/u-boot/attachments/20030425/ec2bdf1a/attachment.bin 

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Udi Finkelstein]

On Fri, 25 Apr 2003 01:18:43 +0200, Wolfgang Denk <wd@denx.de> wrote:

>Dear Udi,

Thanks for your help Wolfgang!

>
>in message <fsrgav0iq16cgicc588ms3p7nvc2gtogbb@4ax.com> you wrote:
>> 
>> In an ideal world, I would like the DiskOnChip to be:
>
>Maybe you can find some useful information in  section  ``7.3.  Using
>Disk On Chip "Drives"'' at
>http://www.denx.de/doc/CPU86/advanced-topics.html#DISK-ON-CHIP

Thanks, I just began reading it, and it looks like it answers all my
questions.
My D.O.C was already partitioned with 1MB binary partition, which I
successfully used for the Linux kernel.
However, I still didn't manage to get my D.O.C working under Linux, (see
below, at the end of this EMail).

>> 1. As far as I can tell, the only DiskOnChip support are the "doc read" and
>> "doc write" commands, therefore if I use these commands I must load the kernel
>> directly off the raw sectors - no filesystem support whatsoever. Am I correct?
>
>No, you are not correct.
>
>First, the "doc" command provides more sub-commands, like "doc  info"
>or "doc erase".
>
>"help doc" helps ;-)

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.

>> 2. Does the "doc read" and "doc write" use the NFTL layer, or do they access
>> the raw device sectors?
>
>They do not use NFTL. They use raw binary offset addresses.

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).

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?

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.
(And U-BOOT successfully identifies a 1MB on my D.O.C - it was probably
preformatted when I got it - its not a new board).

>> 3. As far as I can tell, the FAT support is hardwired to the floppy controller
>> device, and the DOS partition support is wired to the IDE support. Am I right?
>
>???

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.

>> It seems to me it is quite trivial to construct a simple interface (a struct
>> containing the block device geometry, plus a pointer to sector read function),
>> and have both the partitioning and the DOS FAT code access this. This could
>> help support DOS filesystems on D.O.C, floppies and IDE devices.
>
>Are you talking about U-Boot or Linux here?
Yes, see above. I mean reusing the code from fs/fdos.

>> 4. What is the best way to achieve my requirements above? (booting a kernel
>> from a filesystem on the D.O.C). Can JFFS2 help me in any way?
>
>See  the  document  mentioned  above.  It  contains  pretty  detailed
>instructions. And no, JFFS2 has nothing to do with it.

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??)

OK, so where to I stand now?
1. 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.

I think this part of my questions should be sent to the MTD list I guess.

-------------------------------------------------------------------
=> run 'b'
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 = 666269 (a2a9d hex)
## Booting image at 00500000 ...
   Image Name:   Linux Kernel Image
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    666205 Bytes = 650.6 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
Linux version 2.4.21-pre7 (udif at localhost.localdomain) (gcc version 2.95.4
20010319 (prerelease/franzo/20011204)) #5 Thu Apr 24 21:04:12 IDT 2003
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: /dev/nfs rw nfsroot=10.10.10.4:/opt/eldk/ppc_8xx ip=dhcp
Decrementer Frequency = 180000000/60
Calibrating delay loop... 47.71 BogoMIPS
Memory: 14448k available (1264k kernel code, 404k data, 64k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch at atnf.csiro.au)
devfs: boot_options: 0x0
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
CPM UART driver version 0.03
ttyS00 at 0x0280 is a SMC
ttyS01 at 0x0380 is a SMC
pty: 256 Unix98 ptys configured
eth0: CPM ENET Version 0.2 on SCC2, 00:50:01:02:03:04
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
Using configured DiskOnChip probe address 0x4000000
DiskOnChip Millennium found at address 0x4000000
Flash chip found: Manufacturer ID: 98, Chip ID: E6 (Toshiba:NAND 8MB 3,3V)
1 flash chips found. Total DiskOnChip size: 8 MiB
NFTL driver: nftlcore.c $Revision: 1.87 $, nftlmount.c $Revision: 1.31 $
Unreferenced block 130, formatting it
Partition check:
 nftla: unknown partition table
devfs_register(disc): NULL ops, got c0169364 from major table
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 10.10.10.10
IP-Config: Complete:
      device=eth0, addr=10.10.10.10, mask=255.255.255.0, gw=10.10.10.1,
     host=10.10.10.10, domain=, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=10.10.10.4, rootpath=
ip_conntrack version 2.1 (128 buckets, 1024 max) - 292 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
arp_tables: (C) 2002 David S. Miller
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Looking up port of RPC 100003/2 on 10.10.10.4
Looking up port of RPC 100005/1 on 10.10.10.4
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 64k init
INIT: version 2.78 booting
		Welcome to DENX Embedded Linux Environment
		Press 'I' to enter interactive startup.
Mounting proc filesystem:  [  OK  ]
Configuring kernel parameters:  [  OK  ]
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Setting clock : Sat Dec 13 18:57:33 EST 1952 [  OK  ]
Activating swap partitions:  [  OK  ]
Setting hostname 10.10.10.10:  [  OK  ]
modprobe: Can't open dependencies file /lib/modules/2.4.21-pre7/modules.dep
(No such file or directory)
Checking filesystems
[  OK  ]
Mounting local filesystems:  [  OK  ]
Enabling swap space:  [  OK  ]
INIT: Entering runlevel: 3
Entering non-interactive startup
Starting system logger: [  OK  ]
Starting kernel logger: [  OK  ]
Starting xinetd: [  OK  ]

10 login: root

Last login: Sat Dec 13 12:40:42 on console
bash-2.05# eraseall /dev/mtdchar0
eraseall: /dev/mtdchar0: No such device
bash-2.05# 
bash-2.05# nftl_format /dev/mtdchar0 0x000C0000
$Id: nftl_format.c,v 1.19 2002/05/01 10:59:04 dwmw2 Exp $
Open flash device: No such device
bash-2.05# 
bash-2.05# fdisk /dev/nftla
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF
disklabel
Building a new DOS disklabel. Changes will remain in memory only,
until you decide to write them. After that, of course, the previous
content won't be recoverable.


Command (m for help): p

Command (m for help): 
Disk /dev/nftla: 14 heads, 1 sectors, 1000 cylinders
Units = cylinders of 14 * 512 bytes

     Device Boot    Start       End    Blocks   Id  System

Command (m for help): Command (m for help): n

Command action
   e   extended
   p   primary partition (1-4)
Command action
   e   extended
   p   primary partition (1-4)
p

Partition number (1-4): Value out of range.
Partition number (1-4): 1

First cylinder (1-1000, default 1): Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1000, default 1000): 

Using default value 1000

Command (m for help): Command (m for help): p


Disk /dev/nftla: 14 heads, 1 sectors, 1000 cylinders
Units = cylinders of 14 * 512 bytes

     Device Boot    Start       End    Blocks   Id  System
/dev/nftla1             1      1000      6999+  83  Linux

Command (m for help): Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
bash-2.05# 
bash-2.05# fdisk /dev/nftla

Command (m for help): p

Command (m for help): 
Disk /dev/nftla: 14 heads, 1 sectors, 1000 cylinders
Units = cylinders of 14 * 512 bytes

     Device Boot    Start       End    Blocks   Id  System
/dev/nftla1             1      1000      6999+  83  Linux

Command (m for help): Command (m for help): q


bash-2.05# 
-------------------------------------------------------------------



>
>Best regards,
>
>Wolfgang Denk

thanks,
Udi

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It's a small world, but I wouldn't want to paint it.

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Udi Finkelstein]

On Fri, 25 Apr 2003 10:13:42 +0200, Wolfgang Denk <wd@denx.de> wrote:

>> OK, so where to I stand now?
>> 1. 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

[U-Boot-Users] DiskOnChip, filesystems, and other booting options

[Udi Finkelstein]

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