U-Boot v2015.04-rc3 released

Quoted 13 lines · Karsten Merker

Quoted 2 lines · Tom Rini

I've pushed v2015.04-rc3 out to the repository and tarballs should exist soon.

[...]

Quoted 1 line

As always, if anything is broken please speak up.

Hello,

I have tested v2015.04-rc3 and have stumbled over a problem with the distro_bootcmd framework when trying to boot from a specific device at the u-boot command prompt by using "run <device>_boot". Autobooting without user interruption of the boot process works fine:

Quoted 12 lines

Interrupting the boot sequence and then manually executing e.g. "run usb_boot" results in a "** Bad device specification usb devplist **" error message:

sunxi# run usb_boot

USB device 0: Vendor: Intenso Rev: Prod: Rainbow
Type: Removable Hard Disk
Capacity: 7620.0 MB = 7.4 GB (15605760 x 512)
** Bad device specification usb devplist ** sunxi#

Quoted 9 lines

The reason for this is that in this constellation ${devnum} is undefined, which leads to a failure of the "part list ${devtype} ${devnum} devplist" command in ${scan_dev_for_boot_part}. Older versions of u-boot did not use the part list command, so this problem did not occur there. Using "run bootcmd_usb0" instead of "run usb_boot" works, but my understanding (which may of course be wrong) was that the user is expected to use "run <device>_boot" for booting from a specific device at the u-boot command prompt, and that has worked without problems in previous u-boot versions.

Hello,

as my original email appears to have fallen through the cracks, I'd like to ask again whether using "run <device>_boot" is "officially" expected to work or not. If it is not, what is the officially supported way for a user to boot from a certain device at the u-boot prompt? Should people use "setenv boot_targets foo; run bootcmd" instead?

Quoted 9 lines · Stephen Warren

For manual booting, I would expect to always run the device-specific command (e.g. bootcmd_usb0 or bootcmd_mmc1) rather than the device-type-specific command (e.g. usb_boot, mmc_boot).

I'm not sure how the type-generic commands ever worked without variables such as ${devnum} set, since they all pass ${devnum} to a variety of commands in addition to the new "part list". Perhaps those commands default to devnum==0 if the parameter is missing, and you never wanted to boot e.g. from mmc 1 instead of mmc 0?

Yes, indeed - my boards only have a single instance of all devices.

I have just tried to "single-step" through the bootcmd framework in u-boot 2014.10 (which is what Debian 8 will release with and where "run usb_boot" works). All commands used there work when ${devnum} is empty and then default to 0, while the later-added "part list" fails without an explictly set ${devnum}.

As a result I will need to update the Debian installation documentation. As I would like to do it right this time ;-), I just would like to get the confirmation that the device-specific commands, such as "run bootcmd_usb0", are an "official" interface that is going to stay in future u-boot versions, or - if they are not - get the information what is the offical method for booting from a specific device at the prompt.

Quoted 13 lines · Stephen Warren

Quoted 7 lines · Karsten Merker

As a result I will need to update the Debian installation documentation. As I would like to do it right this time ;-), I just would like to get the confirmation that the device-specific commands, such as "run bootcmd_usb0", are an "official" interface that is going to stay in future u-boot versions, or - if they are not - get the information what is the offical method for booting from a specific device at the prompt.

We don't actually have an official specification of that at present. doc/README.distro should probably cover this but doesn't.

Quoted 4 lines

Suffice to say, I use those macros all the time, and I intended them to be used this way when I wrote the boot scripts. So, if I notice a change that stops them from working without extremely good reason, I'll complain.

Thanks, I'll update the Debian docs accordingly.

So then we're settled on "run bootcmd_usb" was unintended but "run bootcmd_usb0" is and must remain so if anything a slight update to doc/README.distro would be expected and we're good, right? Thanks guys!

doc/README.distro +4 -0

 
+Interactively booting from a specific device at the u-boot prompt
+=================================================================
+
+For interactively booting from a user-selected device at the u-boot command

Quoted 9 lines · Stephen Warren

Quoted 9 lines

doc/README.distro +9 -0

+Interactively booting from a specific device at the u-boot prompt
+=================================================================
+
+For interactively booting from a user-selected device at the u-boot command
+prompt, the environment provides predefined bootcmd_<target> variables for
+every target defined in boot_targets, which can be run be the user.
+
+Examples:
+

Quoted 8 lines

doc/README.distro scan_dev_for_scripts: · line 358

Quoted 5 lines

+ - run bootcmd_usb0

doc/README.distro +4 -0

+   boots from the first USB mass storage device
+
+ - run bootcmd_mmc1
+   boots from the second MMC device

Should we enumerate all the possible device types, e.g. include bootcmd_sata0, bootcmd_ide0, ...?

Hm, I suppose that depends on whether there is such a thing as definitve list of all possible device types on all platforms and how many elements are in this list. Are functionally equivalent devices named the same on all platforms, i.e. is a PATA interface always ide0, or could it be ide0 on one platform and pata0 on another?

Quoted 3 lines

In the text, perhaps rephrase bootcmd_<target> as bootcmd_<devtype><devnum>, and note that <devnum> is not optional in the command name?

I had thought about explictly using devtype and devnum, but there are device types such as pxe which do not have a devnum, so I chose to use the generic <target> designation instead. I can change that, but it might cause confusion so that a user would try to use something like "run bootcmd_pxe0" which would not work. I would therefore prefer the generic <target> designation.

config_distro_bootcmd.h defines a common boot environment for multiple platforms, including several environment variables that are intended for interactive use by an end-user. Document which variables are considered public interfaces that must remain compatible in future u-boot versions.

config_distro_bootcmd.h defines a common boot environment for multiple platforms, including several environment variables that are intended for interactive use by an end-user. Document which variables are considered public interfaces that must remain compatible in future u-boot versions.

Signed-off-by Karsten Merker <[email protected]>

Acked-by Stephen Warren <[email protected]>

Quoted 73 lines · Karsten Merker

Quoted 2 lines · Tom Rini

I've pushed v2015.04-rc3 out to the repository and tarballs should exist soon.

[...]

Quoted 1 line

As always, if anything is broken please speak up.

Hello,

I have tested v2015.04-rc3 and have stumbled over a problem with the distro_bootcmd framework when trying to boot from a specific device at the u-boot command prompt by using "run <device>_boot". Autobooting without user interruption of the boot process works fine:

U-Boot SPL 2015.04-rc3 (Mar 04 2015 - 19:43:43)
DRAM: 1024 MiB CPU: 960000000Hz, AXI/AHB/APB: 3/2/2

U-Boot 2015.04-rc3 (Mar 04 2015 - 19:43:43) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0

*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
SCSI:  SUNXI SCSI INIT
SATA link 0 timeout.
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
Net:   dwmac.1c50000

starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 2 USB Device(s) found
USB1: USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
scanning bus for devices...
Found 0 device(s).

SCSI device 0:
Device 0: not available

USB device 0:
Device 0: Vendor: Intenso Rev: Prod: Rainbow
Type: Removable Hard Disk
Capacity: 7620.0 MB = 7.4 GB (15605760 x 512)
... is now current device
Scanning usb 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
1263 bytes read in 22 ms (55.7 KiB/s)
## Executing script at 43100000
[...]

Interrupting the boot sequence and then manually executing e.g. "run usb_boot" results in a "** Bad device specification usb devplist **" error message:

sunxi# run usb_boot

USB device 0: Vendor: Intenso Rev: Prod: Rainbow
Type: Removable Hard Disk
Capacity: 7620.0 MB = 7.4 GB (15605760 x 512)
** Bad device specification usb devplist ** sunxi#

Quoted 9 lines

The reason for this is that in this constellation ${devnum} is undefined, which leads to a failure of the "part list ${devtype} ${devnum} devplist" command in ${scan_dev_for_boot_part}. Older versions of u-boot did not use the part list command, so this problem did not occur there. Using "run bootcmd_usb0" instead of "run usb_boot" works, but my understanding (which may of course be wrong) was that the user is expected to use "run <device>_boot" for booting from a specific device at the u-boot command prompt, and that has worked without problems in previous u-boot versions.

Hello,

as my original email appears to have fallen through the cracks, I'd like to ask again whether using "run <device>_boot" is "officially" expected to work or not. If it is not, what is the officially supported way for a user to boot from a certain device at the u-boot prompt? Should people use "setenv boot_targets foo; run bootcmd" instead?