Included uImage too large to write to NAND

[moshiach]

   Anyone notice that uImage.sheeva.20090319 is just a tiny bit too large to fit into mtd1? Unless I miss my guess, this means you can't setup the plug to boot from itself.

-sh-3.2# nandwrite -p /dev/mtd1 uImage.sheeva.20090319
Image 2106760 bytes, NAND page 2048 bytes, OOB area 2048 bytes, device size 2097152 bytes
Input file does not fit into device: Success
Data was only partially written due to error
: Success

I've successfully gotten it to boot off TFTP and NFS, but I need it to be standalone.

Also, the wiki and the documentation disagree on how to get the uImage file onto the system.  The docs say to nandwrite uImage.sheeva.20090319 to mtd1 and the wiki says to cat uImage.Sheeva to mtdblock1.


So, has anyone out there managed to make their plug boot by itself?

[moshiach]

This is driving me mad!!

To try to get around the slightly offsized uImage I'm passing this as my mtdparts line:

Code:

mtdparts=0:1M(u-Boot)ro,2.5M(uImage),-(rootfs)rw

which should create 3 mtd partitions: 1M for uboot, 2.5M for the image and the rest for the rootfs.  However after booting my proc/mtd is still:

Code:

dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00200000 00020000 "uImage"
mtd2: 1fd00000 00020000 "root"

Looking back at the kernel while it's loading I see

Code:

Using static partition definition
Creating 3 MTD partitions on "nand_mtd":
0x00000000-0x00100000 : "u-boot"
0x00100000-0x00300000 : "uImage"
0x00300000-0x20000000 : "root"

So my question is, how do I override the static definitions?  And why isn't my kernel parameter doing that since I defintiely see it in /proc/cmdline?

[moshiach]

Ok hopefully someone from the company is reading these forums, because the kernel command line mtdparts=x  does not work AT ALL.  No matter what format is used it always defaults to using the static partition table.  Anyone at all know how to change this table?

[moshiach]

It suddenly started working.  No idea why.   Here are some things I tried, hopefully someone will find them useful:

Current working environment (only necessary stuff):

Code:

serverip=192.168.1.2
bootargs_end=:::DB88FXX81:eth0:none
ipaddr=192.168.1.5
console=console=ttyS0,115200
mtdids=nand0=nand_mtd
mtdargs=mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)
partition=nand0,0
mtddevnum=0
mtddevname=uBoot
bootcmd=nand read.e 0x8000000 0x100000 0x500000;bootm 0x8000000
bootargs_root=root=/dev/mtdblock2
bootargs=console=ttyS0,115200
       mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)                             
       root=/dev/mtdblock2    :::DB88FXX81:eth0:none

That gave me more than enough space to flash the kernel image into /dev/mtd1.  I think the key was that mtdparts on the command line cannot have any spaces.  Also, you'll notice I returned to the hex representation of the image sizes (in Kb) and offsets.

I now have a working plug that doesn't touch any other computer on my network to get it's information. 

Out of the box, you shouldn't have the same problems I did unless you are silly enough to plunge ahead with the "wrtiting Jaunty Filesystem" pdf without trying to boot up first.  The devices are shipped with the default uImage and ubuntu filesystem already flashed.

Now the only major problems left are getting the USB device to be the root instead of mtdblock2 and recompiling the kernel to have CIFS support.  Once that's solved I'll have a 5-10 watt computer capable of mounting my media shares from NAS (only samba and CIFS), serving as the squeezecenter server, internal mail hub, backup server, DNS/DHCP and Mysql database server.  I suppose I could just use the usb storage to mount the various directories under /.  That way I'm not writing things to flash all the time and I'll have a harddrive I can move to another plug should this one fail.

See my posts in Getting serial console working for how to get Linux to recognize the sheeva as a valid tty device if you are using Linux and having difficulty getting minicom or another terminal program to read ttyUSB1.   I still haven't figured out how to talk to it with JTAG in case I somehow screw up the u-boot installation.
 
Once you've got it talking, open the "Wrtiing Jaunty Filesystem on NAND Flash" pdf and follow Appendic A,B and C  (making sure to adjust the size of mtdparts each time if like me you have an image too large to fit into mtd1.)in order to get it to the point where you can finally flash the kernel and filesystem to NAND using Chapter 2 of the same document.

[plugit]

I'm starting to feel a bit better about my plug not arriving yet. You'll have documented all the things I want to do by the time it shows up. 

[mteel]

You say you were booting from TFTP with an NFS mounted root filesystem? Could you possibly share your u-boot environment that works for nfs mounted root filesystem? I've been all over it and although it claims to mount, it cannot execute /sbin/init or /bin/bash from the supplied root filesystem.

Any clues would be appreciated.

Mark

[moshiach]

First make sure you can mount your NFS directory on another computer.  I've got everything on a spare linux computer under /tftpboot and I'm running atftp and NFS off of that.

On the NFS computer:

/etc/exports:

Code:

/tftpboot/ 192.168.1.0/24(rw,sync,no_root_squash,subtree_check)

Under /tftpboot I have the kernel image uImage.sheeva.20090319 and the untard contents of the filesystem found in the host software support package (renamed the directory to /tftpboot/sheevaroot).

Here's a snapshot of the relevant environment variables that you will want to set. 

Code:

ethaddr=00:50:43:b4:32:1d 
serverip=192.168.1.2
ipaddr=192.168.1.5
bootargs_end=:::DB88FXX81:eth0:none
console=console=ttyS0,115200
image_name=uImage.sheeva.20090319
rootpath=/tftpboot/sheevaroot
bootargs_root=root=/dev/nfs rw
mtdargs=mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)
bootcmd=tftpboot 0x2000000 $(image_name);setenv bootargs $(console) $(mtdargs) $(bootargs_root) nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip) $(bootargs_end);bootm 0x2000000

and for completeness' sake
bootargs=console=ttyS0,115200 mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs) root=/dev/nfs rw :::DB88FXX81:eth0:none
 although bootargs will be set by the bootcmd if everything is done properly.

Input them in that order then save, reset and interrupt the boot.  Print bootargs to make sure it was set to something approaching what I have there.  If it is, then reset and you should be able to boot with the kernel coming from tftp and the filesystem mounting from NFS.  If it doesn't work, copy the errors.  I suspect you are simply using the wrong filesystem when you mount from NFS or your rootpath doesn't point to the actual root of that filesystem.  Rootpath should point to , well the root of the filesystem.  On my host computer under tftpboot/sheevaroot I have everything as if it was the root of the computer (ie /tftpboot/sheevaroot/usr /tftpboot/sheevaroot/bin etc.)

Also, don't copy and paste the lines.  Type them in by hand.  I've found that minicom doesn't like cut and paste when it goes over the linesize of the terminal.

Getting it to boot from NFS isn't that hard.  Getting it to boot by itself is the tough part

[mteel]

I can mount the rootfs from other linux boxes and from OSX. It is the rootfs distributed with sheevaPlug. I'm running atftp and the rootfs is at /tftpboot/rootfs.

TFTP boot is trivial with u-boot, been doing that for years. My env variables are similar to yours. Note that bootargs is set for the duration of the bootcmd execution and does not persist to the next boot (and your example in your env for bootargs is not correct). Further, placing a space before $(bootargs_end) is bad magic causing the plug to do DHCP.

I am not aware of any way to specify the filesystem from the client which is mounting root via NFS. rootpath=/tftpboot/rootfs

See my post at: http://openplug.org/plugforum/index.php?topic=23.0 for the output during the kernel boot. It appears to mount but can't find a console device and can't execute /sbin/init.

[kilowatt]

I have mine booting from NFS.  Pretty much the same setup as moshiach.

I was getting the 'can't find a console device' error and found it was because when I untared the files system I was not executing the tar as root so the owner:group of all the directories in the root directory were myuser:mygroup and not root:root. 

Make sure you are either su or use sudo when you untar the root file system on your nfs server. 

[mteel]

Excellent! I must have untarred the rootfs as my normal user then chown'd it to root. After untarring it as root, it works perfectly.

Thanks!
Mark

[moshiach]

You are right on the money about $bootargs_end.  I've modified that in my environment and it works as it should now.  Thanks for that tip.  Glad you go t your NFS working.

As for my bootargs, They are persistent only because I also have a few other enviroment variables that more properly set the bootargs (I have a boottftp , bootusb and bootnand variable that sets up my enviroment depending on what I want to boot from , then saves the enviroment.  In truth I could easily leave that part of the bootcmd off and not have to worry about it.

Code:

       
//general commands
image_name=uImage.6plug                                                         
rootpath=/tftpboot/sheevaselinux                                               
ethaddr=00:50:43:b4:32:1d                                                       
serverip=192.168.1.2 
ipaddr=192.168.1.5                                                             
bootargs_end=:::DB88FXX81:eth0:none                                             
console=console=ttyS0,115200                                                           
mtdids=nand0=nand_mtd                                                           
mtdargs=mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)                                             
partition=nand0,0                                                               
mtddevnum=0                                                                     
mtddevname=uBoot                                                               
image_name-old=uImage.sheeva.20090319                                           
bootargs_hold=$(console) $(mtdargs) $(bootargs_root) $(bootargs_middle)$(bootargs_end)    //Used to create new bootarg_x variables

//Nand
bootcmd_nand=nand read.e 0x8000000 0x100000 0x500000;bootm 0x8000000           
bootargs_root_nand=root=/dev/mtdblock2                                         
bootargs_nand=console=ttyS0,115200
                           mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)
                           root=/dev/mtdblock2:::DB88FXX81:eth0:none                                                       

//TFTP
bootcmd_tftp=tftpboot 0x2000000 $(image_name);setenv bootargs $(console) $(mtdargs) $(bootargs_root) nfsroot=$(serverip):$(rootpath)
                       ip=$(ipaddr):$(serverip)$(bootargs_end);bootm 0x2000000                                                   
bootargs_root_tftp=root=/dev/nfs rw                                             
bootargs_tftp=console=ttyS0,115200
                        mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)
                        root=/dev/nfs rw :::DB88FXX81:eth0:none                                                           


//USB  Still not working properly
bootcmd_usb=usb start; nand read.e 0x8000000 0x100000 0x500000;bootm 0x8000000 
bootargs_root_usb=root=/dev/sda2                                               
bootargs_usb=console=ttyS0,115200
                        mtdparts=nand_mtd:0x00100000@0x00000000(uBoot),0x00500000@0x00100000(uImage),0x1fa00000@0x00600000(rootfs)
                        root=/dev/sda2:::DB88FXX81:eth0:none                                                             

//run these commands to change enviroment for booting
bootusb=set bootargs_root $(bootargs_root_usb);set bootargs $(bootargs_usb);set bootcmd $(bootcmd_usb);save                                                     
bootnand=set bootargs_root $(bootargs_root_nand);set bootargs $(bootargs_nand);set bootcmd $(bootcmd_nand);save                                                 
boottftp=set bootargs_root $(bootargs_root_tftp);set bootargs $(bootargs_tftp);set bootcmd $(bootcmd_tftp);save                                                 

                                                                   

So if I  want to boot from NAND, I set the image_name and rootpath then run bootnand and it sets the bootargs_root, then the bootargs, then the bootcmd then saves the environment.  After that I reset and boot into NAND.  Makes it easy to test new and different enviroments just by changing the image_name, rootpath and running the appropriate bootX command.

[axman5389]

 

I had the exact same problem as moshiach.  Different results..   

I have re-sized /dev/mtd1 pretty much same as he posted.
I have flashed uImage on to the Plug using both the nandwrite and 'cat > /dev' methods.

In both cases, (after I resized the partition) I can boot once with success.  But only once.

Making zero changes after a cold boot of a fresh flash of uImage, all bootargs are sane and *ought* to boot from flash.

The second time I try to cold boot, it fails every time with Bad Data CRC.

I'm not sure what to try next.  I have 2 suspicions.  But I could be totally wrong..  anyway,

1) flash_eraseall is misbehaving.
2) something is screwy with Plug's Ecc bits.

The uImage file that I flash with is exact same image file that I boot via NFS.  It works via NFS every time.  So I think it safe to rule out "corrupt image file."

Next steps I think are to investigate the beginning pages of each partition;
a) in current state = no boot 'Bad Data CRC'
b) right after a flash_eraseall
c) right after a "successful" flash operation
d) after a failed boot

Any suggestions are most welcome.

[tap]

@axman5389,

I have had exactly the same problem, it is something to do with the length of what is loaded. I experimented by loading the uImage from a USB and tftp server and then running it with root as the flash drive and it loads perfectly in that case. Also, I noticed that flash is named in the docs differently than what some of the other posters have booted with.

to get around it till someone figures out the problem, I have been booting the uImage from USB and mounting the root on the USB drive as well. I had posted how I had done that in another thread. USB seems pretty fast.

[axman5389]

Tap,

Thanks for suggestion.  I will get to filesystem on USB eventually.  Maybe sooner than I like..

Your words about "length of what is loaded" give me a hint..  At work right now, can't play.  But I will experiment tonight and will report if succes (and will whine some more if fail.)

[moshiach]

I've run into the bad CRC error before.  It ALWAYS happened when I flashed without erasing.  In fact just to test I reflashed my kernel and rebooted and sure enought here it was.  So you might try after getting a successful boot from tFTP:
flash_eraseall /dev/mtd1
nandwrite -pm /dev/mtd1 <yourimage>