New U-boot features

[Rabeeh Khoury]

All,

We are looking for a new version of U-Boot that has more features. We are mainly interested in having users life easier with the plug.
The things we are looking at are -
1. Reflash Linux kernel and rootfs without the need of serial port.
2. Ready to use bootcmd to easier boot kernel from tftp / NAND flash / USB stick, and then easier way to mount the rootfs.

Look for details below how we intend to implement those, but for now any feedback and new features are welcomed; but we are not promising that all features will be included.

--- Reflash Linux kernel and rootfs without the need of serial port ---
On every boot, U-Boot will look for a USB stick, and if found one then it will look for a uImage.recovery and initrd.recovery files. If found it will boot from them.
Afterwards the uImage and initrd should do anything the user intends to. For example you can have a debian or other distro installer and you can network install a brand new distro and at the end change u-boot environment variables to boot from the new distro.

Note that this will be done on EVERY boot, so if you are using a mechanical drive on the USB port it will wait until the drive spins etc... so potentially it will delay the boot time up to 10 seconds.
I'm not sure how this boot delay will be acceptable by the users, so please provide feedback on this.

--- Ready to use bootcmd ----
As a reminder, every boot, u-boot counts down for 3 seconds and then executes the 'bootcmd' environment variable.
The default 'bootcmd' in U-Boot will be changed to much simpler - 'run bootcmd_nand'
and 'bootcmd_nand' will be something like

Code:

'nand read 0x00200000 0x00100000 0x00200000; setenv bootargs $(console) $(bootargs_root) nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip)$(bootargs_end); bootm 0x00200000'

Besides that, there will be other ready to use environment variable like 'bootcmd_nfs' which will have -

Code:

'tftpboot 0x2000000 $(image_name);setenv bootargs $(console) $(bootargs_root) nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip)$(bootargs_end) $(mvNetConfig) $(mvPhoneConfig); bootm 0x2000000;'

So, if you want to change the boot source from NAND to TFTP/NFS then you would change the bootcmd from 'run bootcmd_nand' to 'run bootcmd_nfs'

We will have other bootcmd for USB boot. If something else required please reply to the post.

[plugit]

On every boot, U-Boot will look for a USB stick, and if found one then it will look for a uImage.recovery and initrd.recovery files. If found it will boot from them.

This would be terrific.

Could your new u-Boot support a uImage on SD? That would be a massive win.

[Rabeeh Khoury]

No support for SD in U-boot. sorry

[augustus]

Rabeeh, could you expand on the SD in U-boot, why is it not available, and will it ever be, I'm very new to the U-boot stuff.  Thanks!  You may add in your setups one for running the FS off the SD card as well (grabbing the uImage from flash)

[bzhou]

Thanks Rabeeh, these are great improvement. Some comments and questions:

1. File system on USB drive that contains uImage.recovery and initrd.recovery, fat, ext2, or either one works?
2. Can this "wait and check" be suppressed with some u-boot environment?
3. Versioning of u-boot?

[plugit]

...and a changelog on the download page.

[Rabeeh Khoury]

Thanks Rabeeh, these are great improvement. Some comments and questions:

1. File system on USB drive that contains uImage.recovery and initrd.recovery, fat, ext2, or either one works?
2. Can this "wait and check" be suppressed with some u-boot environment?
3. Versioning of u-boot?

1. we have both
2. the recovery will be part of the bootcmd environment variable, so if you don't want it you can remove that part of the bootcmd
3. what do you mean by versioning of u-boot? we do have version number (i mean the version of the marvell patch that is applied on the u-boot).

[Rabeeh Khoury]

Rabeeh, could you expand on the SD in U-boot, why is it not available, and will it ever be, I'm very new to the U-boot stuff.  Thanks!  You may add in your setups one for running the FS off the SD card as well (grabbing the uImage from flash)

Today we don't have support for SD cards in u-boot; and unfortunately we don't have plans in the near future to do that.
We will add a special bootcmd_sd that will load the kernel from the flash and will boot from first partition on the SD card - sounds reasonable?

[augustus]

Rabeeh,
sounds reasonable, Thanks!

[kilowatt]

Rabeeh,

We will add a special bootcmd_sd that will load the kernel from the flash and will boot from first partition on the SD card

You might need to do the same for USB boot.  I found that more often than not uboot would not succeed in reading the kernel from an external USB harddrive.  It seemed happier with a USB flash drive.  It would be best if you could find the problem and fix the uboot code to reliably detect and boot the kernel from USB harddrives.  Otherwise the uboot environment settings might not be enough.

I whole heartedly support your proposal.  I think it will be a great enhancement.  I'm just concerned that from what I've seen it will require you to fix a few uboot bugs for it to work.

See http://openplug.org/plugforum/index.php?topic=33.0 for more details on my observations.

Mark

[Rabeeh Khoury]

It would be best if you could find the problem and fix the uboot code to reliably detect and boot the kernel from USB harddrives.  Otherwise the uboot environment settings might not be enough.

Can you please provide details? I'm not familiar with such issues.

[HankScorpio]

Request that U-BOOT respects bootdelay env variable. To allow the uart to be used with other devices such as ZIGBEE, GPS.

Or U-BOOT supports  CONFIG_AUTOBOOT_STOP_STR  to allow the definition of a string that will not conflict with the attached device.

[plugit]

It would be best if you could find the problem and fix the uboot code to reliably detect and boot the kernel from USB harddrives.  Otherwise the uboot environment settings might not be enough.

Can you please provide details? I'm not familiar with such issues.

I've also found detection of spinning-disk USB to be exceptionally hit and miss (well, more miss than hit) with the current u-Boot. There's some special alignment of the planets that has to occur in order for the plug to see a storage device, and I'm not sure exactly what it is. Does work sometimes, though.

Like kilowatt, I gave up and chose an alternate boot source --- USB disk is fine for the rootfs, though.

[Nod51]

I have booted 3 or 4 times from a spinning disk USB drive without problems (did you add the delay of 10 seconds and make sure the drive is spun up?), but random is random...

I doubt anything can be done to fix my problem or if anyone else would even care, but I have a 7 port USB plugged in and 3 hard drives connected, one of which I want to boot from. I saw how to define /dev/sda1 as the device to look for the kernel, but with all 3 drives plugged in, I have not had U-boot pick the right drive yet. I tried doing it by UUID (/dev/disk/by-uuid/...) but it fails. The solution is to just wait until the kernel is loaded then plug in the remaining 2 drives.

If it is possible to define the SD card partition 1 to look for the uImage I can just go back to making my SD card root again. I stopped that because the internal flash corrupted the kernel that came with it, and since I was having to have a USB drive hold the uImage anyhow, I just made it the root as well.

[kilowatt]

The problem with the spinning disk is not running the file system from it.  As long as you add the 10 second delay the kernel doesn't have a problem getting the drive initialized and ready to start up the file system.

The problem is trying to read the kernel from the spinning drive with Uboot.

See: http://openplug.org/plugforum/index.php?topic=131.0