[U-Boot] [ANN] U-Boot v2015.04-rc3 released

[U-Boot] [ANN] U-Boot v2015.04-rc3 released

[Tom Rini]

Hey all,

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

We're 2 weeks after -rc2 came out.  I need to go and look for
outstanding odds and ends and such tomorrow and I think once Simon fixes
the SPL series he's doing for BBB I'll be confident enough to pull that
in.

As always, if anything is broken please speak up.

Thanks all!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150303/a1802af1/attachment.sig>

[U-Boot] Regression in bootcmd handling in v2015.04-rc3?

[Stephen Warren]

On 03/11/2015 02:20 PM, Karsten Merker wrote:
> On Wed, Mar 04, 2015 at 08:53:37PM +0100, Karsten Merker wrote:
>> On Tue, Mar 03, 2015 at 06:31:37PM -0500, Tom Rini wrote:
>>
>>> I've pushed v2015.04-rc3 out to the repository and tarballs should exist
>>> soon.
>> [...]
>>> 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:
...
>> 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#
>>
>> 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?

Sorry, I didn't see the original email.

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?

[U-Boot] Regression in bootcmd handling in v2015.04-rc3? (was: [ANN] U-Boot v2015.04-rc3 released)

[Tom Rini]

On Wed, Mar 11, 2015 at 09:20:46PM +0100, Karsten Merker wrote:
> On Wed, Mar 04, 2015 at 08:53:37PM +0100, Karsten Merker wrote:
> > On Tue, Mar 03, 2015 at 06:31:37PM -0500, Tom Rini wrote:
> > 
> > > I've pushed v2015.04-rc3 out to the repository and tarballs should exist
> > > soon.
> > [...]
> > > 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#
> > 
> > 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?

Can you git bisect down to the problem commit and then we can poke the
authors and other folks with a strong opinion on the distro bootcmd
bits?  Thanks again!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150311/a29f29c7/attachment.sig>

[U-Boot] Regression in bootcmd handling in v2015.04-rc3?

[Stephen Warren]

On 03/11/2015 03:21 PM, Karsten Merker wrote:
> On Wed, Mar 11, 2015 at 02:31:07PM -0600, Stephen Warren wrote:
>
>> 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.

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

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.

[U-Boot] Regression in bootcmd handling in v2015.04-rc3?

[Tom Rini]

On Wed, Mar 11, 2015 at 10:48:25PM +0100, Karsten Merker wrote:
> On Wed, Mar 11, 2015 at 03:35:02PM -0600, Stephen Warren wrote:
> > On 03/11/2015 03:21 PM, Karsten Merker wrote:
> 
> > >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.
> > 
> > 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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150317/eba9152e/attachment.sig>

[U-Boot] config_distro_bootcmd and boot environment (was: Regression in bootcmd handling in v2015.04-rc3?)

[Karsten Merker]

Tom Rini <trini@konsulko.com> wrote:

> 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!

Following is a patch to add such a description to doc/README.distro.

Regards,
Karsten

Karsten Merker (1):
  Document config_distro_bootcmd environment variables for interactive
    booting.

 doc/README.distro |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

-- 
1.7.10.4

[U-Boot] [PATCH] Document config_distro_bootcmd environment variables for interactive booting.

[Karsten Merker]

Signed-off-by: Karsten Merker <merker@debian.org>
---
 doc/README.distro |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/doc/README.distro b/doc/README.distro
index dd0f1c7..5150eda 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -1,6 +1,7 @@
 /*
  * (C) Copyright 2014 Red Hat Inc.
  * Copyright (c) 2014-2015, NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (c) 2015 K. Merker <merker@debian.org>
  *
  * SPDX-License-Identifier:     GPL-2.0+
  */
@@ -339,3 +340,19 @@ scan_dev_for_scripts:
 
   If you want to disable boot.scr on all disks, set the value to something
   innocuous, e.g. setenv scan_dev_for_scripts true.
+
+
+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:
+
+ - run bootcmd_usb0
+   boots from the first USB mass storage device
+
+ - run bootcmd_mmc1
+   boots from the second MMC device
-- 
1.7.10.4

[U-Boot] [PATCH] Document config_distro_bootcmd environment variables for interactive booting.

[Stephen Warren]

On 03/19/2015 01:41 PM, Karsten Merker wrote:

A brief description would be nice.

> diff --git a/doc/README.distro b/doc/README.distro

> +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:
> +
> + - run bootcmd_usb0
> +   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, ...?

We should definitely mention that bootcmd_usb is an internal 
implementation detail even though bootcmd_usb0 is a command that we 
intend users to run. In the text, perhaps rephrase bootcmd_<target> as 
bootcmd_<devtype><devnum>, and note that <devnum> is not optional in the 
command name?

[U-Boot] [PATCH] Document config_distro_bootcmd environment variables for interactive booting.

[Stephen Warren]

On 03/19/2015 02:53 PM, Karsten Merker wrote:
> On Thu, Mar 19, 2015 at 01:53:14PM -0600, Stephen Warren wrote:
>
>>> +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:
>>> +
>>> + - run bootcmd_usb0
>>> +   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?

The list is limited to the macros that are set up in 
config_distro_bootcmd.h. At least for the device types supported there, 
and the set of platforms which use that header so far, a particular 
device type is always named the same on all platforms.

I'd expect a patch that added a new device type to the header to update 
the list in the documentation.

>> 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.

Ah yes. Perhaps continue to use <target> and then explain that when 
<target> is a storage device that can have multiple instances, the 
format of <target> must be <devtype><devnum>, but in other cases (pxe, 
dhcp), it is just a standalone name?

[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.

[Karsten Merker]

Changes since V1:

- Explicitly define the target format for storage and network targets
- Include a list of all valid bootcmd targets which are currently supported
- Make the commit log more verbose

Karsten Merker (1):
  Document config_distro_bootcmd environment variables for interactive
    booting.

 doc/README.distro |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

-- 
1.7.10.4

[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.

[Karsten Merker]

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 <merker@debian.org>
---
 doc/README.distro |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/doc/README.distro b/doc/README.distro
index dd0f1c7..0308a4c 100644
--- a/doc/README.distro
+++ b/doc/README.distro
@@ -1,6 +1,7 @@
 /*
  * (C) Copyright 2014 Red Hat Inc.
  * Copyright (c) 2014-2015, NVIDIA CORPORATION.  All rights reserved.
+ * Copyright (C) 2015 K. Merker <merker@debian.org>
  *
  * SPDX-License-Identifier:     GPL-2.0+
  */
@@ -339,3 +340,49 @@ scan_dev_for_scripts:
 
   If you want to disable boot.scr on all disks, set the value to something
   innocuous, e.g. setenv scan_dev_for_scripts true.
+
+
+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.
+
+If the target is a storage device, the format of the target is always
+<device type><device number>, e.g. mmc0.  Specifying the device number is
+mandatory for storage devices, even if only support for a single instance
+of the storage device is actually implemented.
+
+For network targets (dhcp, pxe), only the device type gets specified;
+they do not have a device number.
+
+Examples:
+
+ - run bootcmd_usb0
+   boots from the first USB mass storage device
+
+ - run bootcmd_mmc1
+   boots from the second MMC device
+
+ - run bootcmd_pxe
+   boots by tftp using a pxelinux.cfg
+
+The list of possible targets consists of:
+
+- network targets
+  * dhcp
+  * pxe
+
+- storage targets (to which a device number must be appended)
+  * mmc
+  * sata
+  * scsi
+  * ide
+  * usb
+
+Other *boot* variables than the ones defined above are only for internal use
+of the boot environment and are not guaranteed to exist or work in the same
+way in future u-boot versions.  In particular the <device type>_boot
+variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation
+detail and must not be used as a public interface.
-- 
1.7.10.4

[U-Boot] [PATCH V2] Document config_distro_bootcmd environment variables for interactive booting.

[Stephen Warren]

On 03/21/2015 07:15 AM, Karsten Merker wrote:
> 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.

Acked-by: Stephen Warren <swarren@nvidia.com>

[U-Boot] [U-Boot, V2] Document config_distro_bootcmd environment variables for interactive booting.

[Tom Rini]

On Sat, Mar 21, 2015 at 02:15:38PM +0100, Karsten Merker wrote:

> 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 <merker@debian.org>
> Acked-by: Stephen Warren <swarren@nvidia.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150328/660849f1/attachment.sig>