[U-Boot-Users] Re: JFFS2: CRC Problem with Kernel Image
Which version of U-Boot is this?
0.4.1
Are you sure the image is still OK?
My target mounts root filesystem over NFS. So running on my host system "mkimage -l /mnt/pImage" works:
Target:
bash-2.05# mount -t jffs2 /dev/mtdblock1 /mnt/ bash-2.05# cd /mnt/ bash-2.05# ll total 514 -rw-r--r-- 1 root root 525815 Jul 22 13:31 pImage bash-2.05# cp pImage /pImage
Host:
vm@pc241:/nfs/eldk/ppc_8xx> mkimage -l pImage Image Name: Linux-2.4.4 Created: Tue Jul 22 15:28:19 2003 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 525751 Bytes = 513.43 kB = 0.50 MB Load Address: 0x00000000 Entry Point: 0x00000000
With the same image "tftpboot" works fine.
->tftp 100000 pImage TFTP from server 172.22.20.193; our IP address is 172.22.10.33 Filename 'pImage'. Load address: 0x100000 Loading: T ################################## done Bytes transferred = 525815 (805f7 hex) ->imi ## Checking Image at 00100000 ... Image Name: Linux-2.4.4 Created: 2003-07-22 13:28:19 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 525751 Bytes = 513.4 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ->
So I am sure that my image file is OK, I suppose something goes wrong in "fsload", when pImage will copied to memory.
How did the pImage file get to /dev/mtdblock1 in the first place?
We had a problem a while back where using scp to copy an image to a jffs2 flash partition would corrupt the image (happened like 12% of the time). Finally the cause was found to be a timer in scp used to update the progress bar to the user (timer alarm was handled mid-write to flash). We ended up masking the timer alarm in scp until the write was finished, and all was OK.
In reality, we're working around some bug in the kernel jffs2 code...
hth, -mark
On Tuesday, July 22, 2003, at 06:44 AM, Martin, Vitali wrote:
Which version of U-Boot is this?
0.4.1
Are you sure the image is still OK?
My target mounts root filesystem over NFS. So running on my host system "mkimage -l /mnt/pImage" works: Target: bash-2.05# mount -t jffs2 /dev/mtdblock1 /mnt/ bash-2.05# cd /mnt/ bash-2.05# ll total 514 -rw-r--r-- 1 root root 525815 Jul 22 13:31 pImage bash-2.05# cp pImage /pImage
Host: vm@pc241:/nfs/eldk/ppc_8xx> mkimage -l pImage Image Name: Linux-2.4.4 Created: Tue Jul 22 15:28:19 2003 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 525751 Bytes = 513.43 kB = 0.50 MB Load Address: 0x00000000 Entry Point: 0x00000000
With the same image "tftpboot" works fine. ->tftp 100000 pImage TFTP from server 172.22.20.193; our IP address is 172.22.10.33 Filename 'pImage'. Load address: 0x100000 Loading: T ################################## done Bytes transferred = 525815 (805f7 hex) ->imi ## Checking Image at 00100000 ... Image Name: Linux-2.4.4 Created: 2003-07-22 13:28:19 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 525751 Bytes = 513.4 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK -> So I am sure that my image file is OK, I suppose something goes wrong in "fsload", when pImage will copied to memory.
participants (2)
-
Mark Rakes -
Martin, Vitali