Message ID | 20210711230709.31513-1-andre.przywara@arm.com |
---|---|
State | Accepted |
Commit | ccadfca251aa83982e01fc6278405a316831c933 |
Delegated to: | Tom Rini |
Headers | show |
Series | distro_boot: Fix block device after DHCP boot sequence | expand |
On Sun, 11 Jul 2021 at 17:07, Andre Przywara <andre.przywara@arm.com> wrote: > > The generic distro boot sequence iterates over several types of devices, > trying one after another. In doing do, it starts with setting the > "devtype" variable, then uses this later in more generic commands. > > Now most (block) device types use a local variable for that, but DHCP > puts the type into the environment, where it shadows any local variables. > As a consequence any boot attempt after bootcmd_dhcp has been run fails: > =========================== > VExpress64# run bootcmd_dhcp > ... > VExpress64# run bootcmd_sata0 > SATA#0: > (3.0 Gbps) > SATA#1: > (No RDY) > Device 0: Model: 16GB SATA Flash Drive .... > ... is now current device > Couldn't find partition dhcp 0:1 > =========================== > This problem typically doesn't show, because DHCP is mostly the last > command to try, but is a problem when this order is different, or when > distro_bootcmd or bootcmd_xxx are run separately or multiple times. > > Let bootcmd_dhcp use a local variable, as the other kids do, to make the > order of boot commands irrelevant, and allow repeated calls. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > --- > include/config_distro_bootcmd.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass <sjg@chromium.org>
On Mon, Jul 12, 2021 at 12:07:09AM +0100, Andre Przywara wrote: > The generic distro boot sequence iterates over several types of devices, > trying one after another. In doing do, it starts with setting the > "devtype" variable, then uses this later in more generic commands. > > Now most (block) device types use a local variable for that, but DHCP > puts the type into the environment, where it shadows any local variables. > As a consequence any boot attempt after bootcmd_dhcp has been run fails: > =========================== > VExpress64# run bootcmd_dhcp > ... > VExpress64# run bootcmd_sata0 > SATA#0: > (3.0 Gbps) > SATA#1: > (No RDY) > Device 0: Model: 16GB SATA Flash Drive .... > ... is now current device > Couldn't find partition dhcp 0:1 > =========================== > This problem typically doesn't show, because DHCP is mostly the last > command to try, but is a problem when this order is different, or when > distro_bootcmd or bootcmd_xxx are run separately or multiple times. > > Let bootcmd_dhcp use a local variable, as the other kids do, to make the > order of boot commands irrelevant, and allow repeated calls. > > Signed-off-by: Andre Przywara <andre.przywara@arm.com> > Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks!
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index 2627c2a6a54..e70423f25dd 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -375,7 +375,7 @@ #endif #define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \ "bootcmd_dhcp=" \ - "setenv devtype " #devtypel "; " \ + "devtype=" #devtypel "; " \ BOOTENV_RUN_NET_USB_START \ BOOTENV_RUN_PCI_ENUM \ "if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \
The generic distro boot sequence iterates over several types of devices, trying one after another. In doing do, it starts with setting the "devtype" variable, then uses this later in more generic commands. Now most (block) device types use a local variable for that, but DHCP puts the type into the environment, where it shadows any local variables. As a consequence any boot attempt after bootcmd_dhcp has been run fails: =========================== VExpress64# run bootcmd_dhcp ... VExpress64# run bootcmd_sata0 SATA#0: (3.0 Gbps) SATA#1: (No RDY) Device 0: Model: 16GB SATA Flash Drive .... ... is now current device Couldn't find partition dhcp 0:1 =========================== This problem typically doesn't show, because DHCP is mostly the last command to try, but is a problem when this order is different, or when distro_bootcmd or bootcmd_xxx are run separately or multiple times. Let bootcmd_dhcp use a local variable, as the other kids do, to make the order of boot commands irrelevant, and allow repeated calls. Signed-off-by: Andre Przywara <andre.przywara@arm.com> --- include/config_distro_bootcmd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)