New U-boot features

[kilowatt]

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

Rabeeh,

See the new topic I started:

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

Mark

[rocklee92]

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.

From the way I see it,  bootcmd should contains something like this :
bootcmd="bootcmd_nand; recovery_usb;"

bootcmd_nand contains the commands to load stuff from nand and boot from there. If bootcmd_nand fails,
it will execute "recovery_usb". If there's a USB plugged-in and if the files are present on the USB the "recovery_usb"
will do its work. We can also add something like "recovery_sd". BTW, bootcmd_nand, recovery_usb and recovery_sd are just
U-boot environment scripts not commands. This is to have flexibility on booting and recovery.

Man I wish I had the SheevaPlug right now....   

[dietsche]

I just wanted to echo the sentiment that booting from a SD card would be very ideal (kernel and all) instead of being limited to the usb. I understand if it's not currently possible, but it should be high on the wish list!

[KostaP]

It would be nice to have NFS boot option in SheevaPlug boot loder just as in recent u-boot versions.

[philipl]

Will you consider merging kwonsk's SD patch?

[rc3]

I don't like the idea of booting kernel from the first partition of the NAND memory and the first partition of the SD card (as the rootfs). Booting completely from SD makes updating kernel much easier (kwonsk has made this happen). I would definitely like the idea of being able to change the bootdelay parameter using setenv command. Currently saved bootdelay always got overwritten on reset. As a matter of fact I found bootdelay is totally useless as you can always press the Enter key before the bootdelay prompt in order to get to the uboot console.

[tinker]

Have you considered replacing U-Boot with OpenFirmware?
OpenFirmware is feature rich and easily extensible via forth scripts.
OpenFirmware is being actively developed.  I know the person that has recently updated the ARM port. If you are interested I can point you to him.

[Rabeeh Khoury]

Hi,

I'm certaintly interested.
Can you please connect me with the developer?

My email is - rabeeh at marvell dt com

[dieterk]

Hi Rabeeh Khoury,

what are the plans about supporting some additional drivers inside u-boot for the sheeva?
I think about:
- GPIO-Driver
- TDM (SPI Port) because the Pin Mulitplexing of the common SPI bus is not very helpful. You couldn't use it in parallel with SD / NAND

Do you something about it?

Thanks and last but not least: You boys do a really good job supporting the sheeva!
Dieter

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.

[Rabeeh Khoury]

what are the plans about supporting some additional drivers inside u-boot for the sheeva?
I think about:
- GPIO-Driver
- TDM (SPI Port) because the Pin Mulitplexing of the common SPI bus is not very helpful. You couldn't use it in parallel with SD / NAND

For GPIO stuff in U-Boot, you can directly access the registers and poke them. I can give you instructions how to do it.

For TDM / SPI stuff; those are not exported as buses on the plug, so I'm not sure how you are willing to use those?

[dieterk]

Hi  Rabeeh,

I'm also in contact with Prafulla on u-boot mailing list regarding this,
The plug is at the moment my evalution platform. I'm working on a custom hardware design.
So maybe my question is a little of toppic
But nevertheless the TDMI SPI pins are on the Header from the main pcb to the jtag interface and maybe
some others find it useful to have an additional hardware interface, too?

It would be very fine if you can give me some instructions how to poke the registers!
Thanks,
Dieter

what are the plans about supporting some additional drivers inside u-boot for the sheeva?
I think about:
- GPIO-Driver
- TDM (SPI Port) because the Pin Mulitplexing of the common SPI bus is not very helpful. You couldn't use it in parallel with SD / NAND

For GPIO stuff in U-Boot, you can directly access the registers and poke them. I can give you instructions how to do it.

For TDM / SPI stuff; those are not exported as buses on the plug, so I'm not sure how you are willing to use those?

[prafulla]

Hi all,

I think, bootloader should be limited to it's objective , i.e. boot the kernel and rfs from supported media SF, NANDF (additional  MMC, or USB), any specific h/w usage should be ported on OS level, otherwise boot loader may be equally fat AS kernel :-)

Mostly this is the approach with the u-boot development.

At this moment it U-boot Kirkwood support enables SF,NANDF and network interface, USB will be anther useful interface in the pipeline,
Apart from this I don't think other things are really needed in u-boot.

Regards..
Prafulla . .
 

[dieterk]

Hi Prafulla, hi Rabeeh,

from your point of view this is surely right.
Sadly, I don't know what the intention of the marvell.git u-boot is.
If you only want to support the sheevaplug than you're right. There is no need for any enhancements.
But for a hardware develpers purposes there is maybe something different.
I'm developing highly customized boards for industrial customers for a few years now (formerly based on TI DaVinci and Netsilicon ARM9 CPUs)
and there was always the need to bring up some hardware before you start the kernel. The alternative was to do the initialisation in early kernel init code
which isn't much fun for me and gives some other problems
So GPIO and legacy serial protocols like I2C and SPI are very helpful!
This gives you the change to do all the setup on board level by using well defined interfaces and no need to hack somewhere deep inside u-boot.
Which makes it more easy to keep your u-boot up to date with upstream.

So if Marvell plans to support industrial customers too it would be a good idea to also support some legacy protocols inside u-boot - as many other archs
do.
The main purpose of u-boot is surely to boot the kernel but sometimes it is also essential to bring up some hardware (like PLLs for example) before you boot
the kernel.

What do you think about that?
Dieter

Hi all,

I think, bootloader should be limited to it's objective , i.e. boot the kernel and rfs from supported media SF, NANDF (additional  MMC, or USB), any specific h/w usage should be ported on OS level, otherwise boot loader may be equally fat AS kernel :-)

Mostly this is the approach with the u-boot development.

At this moment it U-boot Kirkwood support enables SF,NANDF and network interface, USB will be anther useful interface in the pipeline,
Apart from this I don't think other things are really needed in u-boot.

Regards..
Prafulla . .
 

[rc3]

Currently if you do a printenv you will get output in this format:

key=settings

I think it would be nice if a new command, let's say showenv, does something similar to printenv but in a different format:

setenv key 'settings'

This way it would be much easier to copy and paste the settings from other people.

[charlesW]

Hi, kilowatt,

Do you decide what new features will be in? Also what does the time table look like?

thx,

cw