| Message ID | 20221207085137.445249-72-sjg@chromium.org |
|---|---|
| State | Superseded |
| Delegated to: | Tom Rini |
| Headers | show |
| Series | bootstd: Allow migration from distro_bootcmd scripts | expand |
On 2022-12-07, Simon Glass wrote: > Drop the use of scripts and rely on standard boot for all operation. This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke booting on pinebook-pro-rk3399, which still tries to "run distro_bootcmd" but distro_bootcmd is no longer defined... probably several other rk3399 systems are similarly affected? Maybe other rockchip systems as well? Reverting the patch fixes booting on the pinebook-pro-rk3399, at least. It seems that rockpro64-rk3399 was used as an example, so that presumably works, but in actuality, this commit only modifies common files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 specific, so the commit message is a bit misleading. I am not sure what the best way forward is; to quickly convert all the other boards in a new patch series, or incrementally shift one system at a time over (and somehow restore previous behavior in the meantime?)... as it stands it appears we are left with rk3399 boards partially converted but broken... FWIW, I have not confirmed for sure that other boards are broken, so it might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 based boards I can test to confirm... live well, vagrant > include/configs/rk3399_common.h | 5 +---- > include/configs/rockchip-common.h | 2 ++ > 2 files changed, 3 insertions(+), 4 deletions(-) > > diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h > index 2f9aee58197..f2c231dd978 100644 > --- a/include/configs/rk3399_common.h > +++ b/include/configs/rk3399_common.h > @@ -42,15 +42,12 @@ > #define ROCKCHIP_DEVICE_SETTINGS > #endif > > -#include <config_distro_bootcmd.h> > -#include <environment/distro/sf.h> > #define CONFIG_EXTRA_ENV_SETTINGS \ > ENV_MEM_LAYOUT_SETTINGS \ > "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ > "partitions=" PARTS_DEFAULT \ > ROCKCHIP_DEVICE_SETTINGS \ > - BOOTENV \ > - BOOTENV_SF \ > + "boot_targets=" BOOT_TARGETS "\0" \ > "altbootcmd=" \ > "setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \ > "run distro_bootcmd\0" > diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h > index 4c964cc3770..5a06365c760 100644 > --- a/include/configs/rockchip-common.h > +++ b/include/configs/rockchip-common.h > @@ -67,12 +67,14 @@ > BOOT_TARGET_PXE(func) \ > BOOT_TARGET_DHCP(func) \ > BOOT_TARGET_SF(func) > +#define BOOT_TARGETS "mmc1 mmc0 nvme scsi usb pxe dhcp spi" > #else > #define BOOT_TARGET_DEVICES(func) \ > BOOT_TARGET_MMC(func) \ > BOOT_TARGET_USB(func) \ > BOOT_TARGET_PXE(func) \ > BOOT_TARGET_DHCP(func) > +#define BOOT_TARGETS "mmc1 mmc0 usb pxe dhcp" > #endif > > #ifdef CONFIG_ARM64 > -- > 2.39.0.rc0.267.gcb52ba06e7-goog
Hi Vagrant, On Sat, 18 Feb 2023 at 19:19, Vagrant Cascadian <vagrant@debian.org> wrote: > > On 2022-12-07, Simon Glass wrote: > > Drop the use of scripts and rely on standard boot for all operation. > > This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke > booting on pinebook-pro-rk3399, which still tries to "run > distro_bootcmd" but distro_bootcmd is no longer defined... probably > several other rk3399 systems are similarly affected? Maybe other > rockchip systems as well? Reverting the patch fixes booting on the > pinebook-pro-rk3399, at least. > > It seems that rockpro64-rk3399 was used as an example, so that > presumably works, but in actuality, this commit only modifies common > files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 > specific, so the commit message is a bit misleading. > > I am not sure what the best way forward is; to quickly convert all the > other boards in a new patch series, or incrementally shift one system at > a time over (and somehow restore previous behavior in the > meantime?)... as it stands it appears we are left with rk3399 boards > partially converted but broken... > > FWIW, I have not confirmed for sure that other boards are broken, so it > might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 > based boards I can test to confirm... I suspect it needs BOOTSTD_DEFAULTS enabled. Could you try that? I can send a patch if you like? See also this series, in case we should apply patch 1 to -master https://patchwork.ozlabs.org/project/uboot/list/?series=342718 Regards, Simon
Hi Vagrant, On Mon, 20 Feb 2023 at 09:21, Simon Glass <sjg@chromium.org> wrote: > > Hi Vagrant, > > On Sat, 18 Feb 2023 at 19:19, Vagrant Cascadian <vagrant@debian.org> wrote: > > > > On 2022-12-07, Simon Glass wrote: > > > Drop the use of scripts and rely on standard boot for all operation. > > > > This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke > > booting on pinebook-pro-rk3399, which still tries to "run > > distro_bootcmd" but distro_bootcmd is no longer defined... probably > > several other rk3399 systems are similarly affected? Maybe other > > rockchip systems as well? Reverting the patch fixes booting on the > > pinebook-pro-rk3399, at least. > > > > It seems that rockpro64-rk3399 was used as an example, so that > > presumably works, but in actuality, this commit only modifies common > > files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 > > specific, so the commit message is a bit misleading. > > > > I am not sure what the best way forward is; to quickly convert all the > > other boards in a new patch series, or incrementally shift one system at > > a time over (and somehow restore previous behavior in the > > meantime?)... as it stands it appears we are left with rk3399 boards > > partially converted but broken... > > > > FWIW, I have not confirmed for sure that other boards are broken, so it > > might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 > > based boards I can test to confirm... > > I suspect it needs BOOTSTD_DEFAULTS enabled. Could you try that? I can > send a patch if you like? > > See also this series, in case we should apply patch 1 to -master > > https://patchwork.ozlabs.org/project/uboot/list/?series=342718 It turns out to be boostage, as the IRAM seems to get protected. I'll send a little series for all of this. Regards, Simon
On 2023-02-20, Simon Glass wrote: > On Sat, 18 Feb 2023 at 19:19, Vagrant Cascadian <vagrant@debian.org> wrote: >> On 2022-12-07, Simon Glass wrote: >> > Drop the use of scripts and rely on standard boot for all operation. >> >> This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke >> booting on pinebook-pro-rk3399, which still tries to "run >> distro_bootcmd" but distro_bootcmd is no longer defined... probably >> several other rk3399 systems are similarly affected? Maybe other >> rockchip systems as well? Reverting the patch fixes booting on the >> pinebook-pro-rk3399, at least. >> >> It seems that rockpro64-rk3399 was used as an example, so that >> presumably works, but in actuality, this commit only modifies common >> files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 >> specific, so the commit message is a bit misleading. >> >> I am not sure what the best way forward is; to quickly convert all the >> other boards in a new patch series, or incrementally shift one system at >> a time over (and somehow restore previous behavior in the >> meantime?)... as it stands it appears we are left with rk3399 boards >> partially converted but broken... >> >> FWIW, I have not confirmed for sure that other boards are broken, so it >> might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 >> based boards I can test to confirm... > > I suspect it needs BOOTSTD_DEFAULTS enabled. Could you try that? I can > send a patch if you like? I added CONFIG_BOOTSTD_DEFAULTS=y to configs/pinebook-pro-rk3399_defconfig but it still had the same issue... bootcmd does not get updated to use bootstd instead of distro_bootcmd ... and distro_bootcmd is not defined, so it fails to boot! At least it gets as far as a u-boot prompt! As mentioned on irc, I wasn't able to get rockpro64-rk3399 to boot at all (hanging at SPL), so cannot test if it also needs further changes for BOOTSTD to work... and for good measure, rock64-rk3328 also fails in the same way. I also have puma-rk3399, firefly-rk3399 and firefly-rk3288 to test... though might wait on some of those till the dust settles a bit... live well, vagrant
Hi Vagrant, On Tue, 21 Feb 2023 at 13:32, Vagrant Cascadian <vagrant@debian.org> wrote: > > On 2023-02-20, Simon Glass wrote: > > On Sat, 18 Feb 2023 at 19:19, Vagrant Cascadian <vagrant@debian.org> wrote: > >> On 2022-12-07, Simon Glass wrote: > >> > Drop the use of scripts and rely on standard boot for all operation. > >> > >> This patch, applied as 3891c68ef50eda38d78c95ecd03aed030aa6bb53 broke > >> booting on pinebook-pro-rk3399, which still tries to "run > >> distro_bootcmd" but distro_bootcmd is no longer defined... probably > >> several other rk3399 systems are similarly affected? Maybe other > >> rockchip systems as well? Reverting the patch fixes booting on the > >> pinebook-pro-rk3399, at least. > >> > >> It seems that rockpro64-rk3399 was used as an example, so that > >> presumably works, but in actuality, this commit only modifies common > >> files for many rockchip and rk3399 boards and nothing rockpro64-rk3399 > >> specific, so the commit message is a bit misleading. > >> > >> I am not sure what the best way forward is; to quickly convert all the > >> other boards in a new patch series, or incrementally shift one system at > >> a time over (and somehow restore previous behavior in the > >> meantime?)... as it stands it appears we are left with rk3399 boards > >> partially converted but broken... > >> > >> FWIW, I have not confirmed for sure that other boards are broken, so it > >> might just be pinebook-pro-rk3399 for some reason. I have a few rk3399 > >> based boards I can test to confirm... > > > > I suspect it needs BOOTSTD_DEFAULTS enabled. Could you try that? I can > > send a patch if you like? > > I added CONFIG_BOOTSTD_DEFAULTS=y to > configs/pinebook-pro-rk3399_defconfig but it still had the same issue... > > bootcmd does not get updated to use bootstd instead of distro_bootcmd > ... and distro_bootcmd is not defined, so it fails to boot! At least it > gets as far as a u-boot prompt! > > > As mentioned on irc, I wasn't able to get rockpro64-rk3399 to boot at > all (hanging at SPL), so cannot test if it also needs further changes > for BOOTSTD to work... and for good measure, rock64-rk3328 also fails in > the same way. > > I also have puma-rk3399, firefly-rk3399 and firefly-rk3288 to > test... though might wait on some of those till the dust settles a > bit... Yes, see my note about this a few minutes back. I sent 3 patches at lunchtime too: https://patchwork.ozlabs.org/project/uboot/list/?series=343056 Regards, Simon
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h index 2f9aee58197..f2c231dd978 100644 --- a/include/configs/rk3399_common.h +++ b/include/configs/rk3399_common.h @@ -42,15 +42,12 @@ #define ROCKCHIP_DEVICE_SETTINGS #endif -#include <config_distro_bootcmd.h> -#include <environment/distro/sf.h> #define CONFIG_EXTRA_ENV_SETTINGS \ ENV_MEM_LAYOUT_SETTINGS \ "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \ "partitions=" PARTS_DEFAULT \ ROCKCHIP_DEVICE_SETTINGS \ - BOOTENV \ - BOOTENV_SF \ + "boot_targets=" BOOT_TARGETS "\0" \ "altbootcmd=" \ "setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \ "run distro_bootcmd\0" diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h index 4c964cc3770..5a06365c760 100644 --- a/include/configs/rockchip-common.h +++ b/include/configs/rockchip-common.h @@ -67,12 +67,14 @@ BOOT_TARGET_PXE(func) \ BOOT_TARGET_DHCP(func) \ BOOT_TARGET_SF(func) +#define BOOT_TARGETS "mmc1 mmc0 nvme scsi usb pxe dhcp spi" #else #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_MMC(func) \ BOOT_TARGET_USB(func) \ BOOT_TARGET_PXE(func) \ BOOT_TARGET_DHCP(func) +#define BOOT_TARGETS "mmc1 mmc0 usb pxe dhcp" #endif #ifdef CONFIG_ARM64
Drop the use of scripts and rely on standard boot for all operation. Signed-off-by: Simon Glass <sjg@chromium.org> --- include/configs/rk3399_common.h | 5 +---- include/configs/rockchip-common.h | 2 ++ 2 files changed, 3 insertions(+), 4 deletions(-)