[v4 0/7] Fix Rockchip RK3399 bootstd migration

[v4 0/7] Fix Rockchip RK3399 bootstd migration

[Tom Rini]

Hey all,

I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
and it changed too much for everything else. I took about half of that
series and then reworked a few things. Now only rk3399 platforms change
at all and aside from bootcmd changes, the only thing is they now
disable true/test/sysboot/showvar/false/exit commands as those were
being pulled in from distro and now we don't set that flag. I think the
way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
perform more SoC migrations.

-- 
Tom

[v4 1/7] rockchip: Drop bootstage stash in TPL and SPL for rockpro64

[Tom Rini]

From: Simon Glass <sjg@chromium.org>

Unfortunately the IRAM used to stash the bootstage records in TPL
becomes inaccessible after SPL runs. Presumably this is because of ATF
taking it over.

We could move the stash to another address in SPL, before passing it to
U-Boot proper. But it seems easier to wait until we have support for
standard passage[1] which should not be too far away.

For now, disable it in TPL and SPL.

[1] https://patchwork.ozlabs.org/project/uboot/cover/
    20220117150428.1580273-1-sjg@chromium.org/

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Vagrant Cascadian <vagrant@debian.org>
---
Changes in v4:
None.
---
 configs/rockpro64-rk3399_defconfig | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
index dd67f9dff64b..496142368195 100644
--- a/configs/rockpro64-rk3399_defconfig
+++ b/configs/rockpro64-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_DM_RESET=y
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_TARGET_ROCKPRO64_RK3399=y
 CONFIG_SPL_STACK=0x400000
-CONFIG_BOOTSTAGE_STASH_ADDR=0xff8e0000
 CONFIG_DEBUG_UART_BASE=0xFF1A0000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
@@ -21,11 +20,7 @@ CONFIG_SPL_SPI=y
 CONFIG_SYS_LOAD_ADDR=0x800800
 CONFIG_DEBUG_UART=y
 CONFIG_BOOTSTAGE=y
-CONFIG_SPL_BOOTSTAGE=y
-CONFIG_TPL_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
-CONFIG_SPL_BOOTSTAGE_RECORD_COUNT=10
-CONFIG_BOOTSTAGE_STASH=y
 CONFIG_USE_PREBOOT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-- 
2.34.1

[v4 2/7] Move DISTRO_DEFAULTS into boot/

[Tom Rini]

From: Simon Glass <sjg@chromium.org>

This relates to booting so move it in to that Kconfig file, before
changing it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
None.
---
 Kconfig      | 27 ---------------------------
 boot/Kconfig | 27 +++++++++++++++++++++++++++
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/Kconfig b/Kconfig
index a75cce7e28fb..b8f65589f457 100644
--- a/Kconfig
+++ b/Kconfig
@@ -191,33 +191,6 @@ config XEN
 
 	  [1] - https://xenproject.org/
 
-config DISTRO_DEFAULTS
-	bool "Select defaults suitable for booting general purpose Linux distributions"
-	select AUTO_COMPLETE
-	select CMDLINE_EDITING
-	select CMD_BOOTI if ARM64
-	select CMD_BOOTZ if ARM && !ARM64
-	select CMD_DHCP if CMD_NET
-	select CMD_ENV_EXISTS
-	select CMD_EXT2
-	select CMD_EXT4
-	select CMD_FAT
-	select CMD_FS_GENERIC
-	select CMD_PART if PARTITIONS
-	select CMD_PING if CMD_NET
-	select CMD_PXE if NET
-	select CMD_SYSBOOT
-	select ENV_VARS_UBOOT_CONFIG
-	select HUSH_PARSER
-	select SUPPORT_RAW_INITRD
-	select SYS_LONGHELP
-	imply CMD_MII if NET
-	imply USB_STORAGE
-	imply USE_BOOTCOMMAND
-	help
-	  Select this to enable various options and commands which are suitable
-	  for building u-boot for booting general purpose Linux distributions.
-
 config ENV_VARS_UBOOT_CONFIG
 	bool "Add arch, board, vendor and soc variables to default environment"
 	help
diff --git a/boot/Kconfig b/boot/Kconfig
index 5f491625c820..170ab63f27dc 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -820,6 +820,33 @@ config SYS_BOOT_RAMDISK_HIGH
 
 endmenu		# Boot images
 
+config DISTRO_DEFAULTS
+	bool "Select defaults suitable for booting general purpose Linux distributions"
+	select AUTO_COMPLETE
+	select CMDLINE_EDITING
+	select CMD_BOOTI if ARM64
+	select CMD_BOOTZ if ARM && !ARM64
+	select CMD_DHCP if CMD_NET
+	select CMD_ENV_EXISTS
+	select CMD_EXT2
+	select CMD_EXT4
+	select CMD_FAT
+	select CMD_FS_GENERIC
+	select CMD_PART if PARTITIONS
+	select CMD_PING if CMD_NET
+	select CMD_PXE if NET
+	select CMD_SYSBOOT
+	select ENV_VARS_UBOOT_CONFIG
+	select HUSH_PARSER
+	select SUPPORT_RAW_INITRD
+	select SYS_LONGHELP
+	imply CMD_MII if NET
+	imply USB_STORAGE
+	imply USE_BOOTCOMMAND
+	help
+	  Select this to enable various options and commands which are suitable
+	  for building u-boot for booting general purpose Linux distributions.
+
 menu "Boot timing"
 
 config BOOTSTAGE
-- 
2.34.1

[v4 3/7] lmb: Enable LMB if SYS_BOOT_RAMDISK_HIGH

[Tom Rini]

From: Simon Glass <sjg@chromium.org>

Ramdisk relocation requires LMB, so enable it automatically to avoid
build errors.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
None.
---
 boot/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/boot/Kconfig b/boot/Kconfig
index 170ab63f27dc..8fa3181d7e23 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -814,6 +814,7 @@ config SYS_BOOT_RAMDISK_HIGH
 	depends on CMD_BOOTM || CMD_BOOTI || CMD_BOOTZ
 	depends on !(NIOS2 || SANDBOX || SH || XTENSA)
 	def_bool y
+	select LMB
 	help
 	  Enable initrd_high functionality.  If defined then the initrd_high
 	  feature is enabled and the boot* ramdisk subcommand is enabled.
-- 
2.34.1

[v4 4/7] boot: Create a common BOOT_DEFAULTS for distro and bootstd

[Tom Rini]

From: Simon Glass <sjg@chromium.org>

These two features use a lot of common options. Move them into a common
CONFIG to reduce duplication.

Use 'select' for most options since these are things that boards aren't
supposed to override. For now it is not possible to disable
BOOT_DEFAULTS but we may take another look later.

Note that five options use 'imply' to match existing behaviour.

Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Rework a bit so we don't grow so many platforms unintentionally]
Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v4:
- Reword the commit message
- Rework the logic so that build-wise, nothing changes.
---
 boot/Kconfig | 62 ++++++++++++++++++++++++----------------------------
 1 file changed, 28 insertions(+), 34 deletions(-)

diff --git a/boot/Kconfig b/boot/Kconfig
index 8fa3181d7e23..ad035695a4a3 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -350,6 +350,32 @@ config PXE_UTILS
 	help
 	  Utilities for parsing PXE file formats.
 
+config BOOT_DEFAULTS
+	bool  # Common defaults for standard boot and distroboot
+	imply USE_BOOTCOMMAND
+	select CMD_ENV_EXISTS
+	select CMD_EXT2
+	select CMD_EXT4
+	select CMD_FAT
+	select CMD_FS_GENERIC
+	select CMD_PART if PARTITIONS
+	select CMD_DHCP if CMD_NET
+	select CMD_PING if CMD_NET
+	select CMD_PXE if CMD_NET
+	select SUPPORT_RAW_INITRD
+	select ENV_VARS_UBOOT_CONFIG
+	select CMD_BOOTI if ARM64
+	select CMD_BOOTZ if ARM && !ARM64
+	imply CMD_MII if NET
+	imply USB_STORAGE
+	imply EFI_PARTITION
+	imply ISO_PARTITION
+	help
+	  These are not required but are commonly needed to support a good
+	  selection of booting methods. Enable this to improve the capability
+	  of U-Boot to boot various images. Currently much functionality is
+	  tied to enabling the command that exercises it.
+
 config BOOTSTD
 	bool "Standard boot support"
 	default y
@@ -410,24 +436,7 @@ config BOOTSTD_DEFAULTS
 	bool "Select some common defaults for standard boot"
 	depends on BOOTSTD
 	imply USE_BOOTCOMMAND
-	# Bring in some defaults which are generally needed. Boards can drop
-	# these as needed to save code space. Bootstd does not generally require
-	# the commands themselves to be enabled, but this is how some of the
-	# functionality is controlled at present
-	imply CMD_EXT2
-	imply CMD_EXT4
-	imply CMD_FAT
-	imply CMD_FS_GENERIC
-	imply CMD_PART
-	imply CMD_DHCP if NET
-	imply CMD_MII if NET
-	imply CMD_PING if NET
-	imply CMD_PXE if NET
-	imply USB_STORAGE
-	imply SUPPORT_RAW_INITRD
-	imply ENV_VARS_UBOOT_CONFIG
-	imply EFI_PARTITION
-	imply ISO_PARTITION
+	select BOOT_DEFAULTS
 	help
 	  These are not required but are commonly needed to support a good
 	  selection of booting methods. Enable this to improve the capability
@@ -823,27 +832,12 @@ endmenu		# Boot images
 
 config DISTRO_DEFAULTS
 	bool "Select defaults suitable for booting general purpose Linux distributions"
+	select BOOT_DEFAULTS
 	select AUTO_COMPLETE
 	select CMDLINE_EDITING
-	select CMD_BOOTI if ARM64
-	select CMD_BOOTZ if ARM && !ARM64
-	select CMD_DHCP if CMD_NET
-	select CMD_ENV_EXISTS
-	select CMD_EXT2
-	select CMD_EXT4
-	select CMD_FAT
-	select CMD_FS_GENERIC
-	select CMD_PART if PARTITIONS
-	select CMD_PING if CMD_NET
-	select CMD_PXE if NET
 	select CMD_SYSBOOT
-	select ENV_VARS_UBOOT_CONFIG
 	select HUSH_PARSER
-	select SUPPORT_RAW_INITRD
 	select SYS_LONGHELP
-	imply CMD_MII if NET
-	imply USB_STORAGE
-	imply USE_BOOTCOMMAND
 	help
 	  Select this to enable various options and commands which are suitable
 	  for building u-boot for booting general purpose Linux distributions.
-- 
2.34.1

[v4 5/7] rockchip: Disable DISTRO_DEFAULTS for rk3399 boards

[Tom Rini]

From: Simon Glass <sjg@chromium.org>

These board have moved to standard boot but the old 'distro_bootcmd'
command is still active. Disable DISTRO_DEFAULTS to fix this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Vagrant Cascadian <vagrant@debian.org>
---
Changes in v4:
None.
---
 arch/arm/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bd7fffcce0ba..4e7ebeaee87d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1955,7 +1955,7 @@ config ARCH_ROCKCHIP
 	imply ADC
 	imply CMD_DM
 	imply DEBUG_UART_BOARD_INIT
-	imply DISTRO_DEFAULTS
+	imply DISTRO_DEFAULTS if !ROCKCHIP_RK3399
 	imply FAT_WRITE
 	imply SARADC_ROCKCHIP
 	imply SPL_SYSRESET
-- 
2.34.1

[v4 6/7] rockchip: Use BOOTSTD_DEFAULTS if not DISTRO_DEFAULTS

[Tom Rini]

When we do not enable DISTRO_DEFAULTS (generally, to get distro_bootcmd)
we instea do want to imply BOOTSTD_DEFAULTS so that when using bootstd
the general distro boot functionality will still work.

Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v4:
- New patch
---
 arch/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4e7ebeaee87d..8a1e22342248 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1956,6 +1956,7 @@ config ARCH_ROCKCHIP
 	imply CMD_DM
 	imply DEBUG_UART_BOARD_INIT
 	imply DISTRO_DEFAULTS if !ROCKCHIP_RK3399
+	imply BOOTSTD_DEFAULTS if !DISTRO_DEFAULTS
 	imply FAT_WRITE
 	imply SARADC_ROCKCHIP
 	imply SPL_SYSRESET
-- 
2.34.1

[v4 7/7] rockchip: rk3399: Drop altbootcmd

[Tom Rini]

The defined altbootcmd was specific to distro_bootcmd which is not
longer in use on these platforms, so drop it.

Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v4:
- New patch

Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Jonas Karlman <jonas@kwiboo.se>
---
 include/configs/rk3399_common.h | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index 04dcbf20bcb5..96ba19c659bd 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -52,10 +52,7 @@
 	"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
 	"partitions=" PARTS_DEFAULT \
 	ROCKCHIP_DEVICE_SETTINGS \
-	"boot_targets=" BOOT_TARGETS "\0" \
-	"altbootcmd=" \
-		"setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \
-		"run distro_bootcmd\0"
+	"boot_targets=" BOOT_TARGETS "\0"
 
 #endif
 
-- 
2.34.1

Re: [v4 5/7] rockchip: Disable DISTRO_DEFAULTS for rk3399 boards

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

On 2023-03-24, Tom Rini wrote:
> These board have moved to standard boot but the old 'distro_bootcmd'
> command is still active. Disable DISTRO_DEFAULTS to fix this.

I successfully tested the v4 series against v2023.04-rc4 on
rockpro64-rk3399 and pinebook-pro-rk3399, and for good measure
double-checked that it did not introduce regressions on rock64-rk3328,
because it readily available to test. :)

Looks good to me, thanks!

live well,
  vagrant

> Signed-off-by: Simon Glass <sjg@chromium.org>
> Tested-by: Vagrant Cascadian <vagrant@debian.org>
> ---
> Changes in v4:
> None.
> ---
>  arch/arm/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index bd7fffcce0ba..4e7ebeaee87d 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1955,7 +1955,7 @@ config ARCH_ROCKCHIP
>  	imply ADC
>  	imply CMD_DM
>  	imply DEBUG_UART_BOARD_INIT
> -	imply DISTRO_DEFAULTS
> +	imply DISTRO_DEFAULTS if !ROCKCHIP_RK3399
>  	imply FAT_WRITE
>  	imply SARADC_ROCKCHIP
>  	imply SPL_SYSRESET
> -- 
> 2.34.1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: [v4 7/7] rockchip: rk3399: Drop altbootcmd

[Jonas Karlman]

Hi Tom,

On 2023-03-24 21:58, Tom Rini wrote:
> The defined altbootcmd was specific to distro_bootcmd which is not
> longer in use on these platforms, so drop it.
> 
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Changes in v4:
> - New patch
> 
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Jonas Karlman <jonas@kwiboo.se>
> ---
>  include/configs/rk3399_common.h | 5 +----
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
> index 04dcbf20bcb5..96ba19c659bd 100644
> --- a/include/configs/rk3399_common.h
> +++ b/include/configs/rk3399_common.h
> @@ -52,10 +52,7 @@
>  	"fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
>  	"partitions=" PARTS_DEFAULT \
>  	ROCKCHIP_DEVICE_SETTINGS \
> -	"boot_targets=" BOOT_TARGETS "\0" \
> -	"altbootcmd=" \
> -		"setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;" \
> -		"run distro_bootcmd\0"
> +	"boot_targets=" BOOT_TARGETS "\0"
>  
>  #endif
>  

With this series my rk3399 boards stop trying to use distro_bootcmd
and will now successfully boot using default bootcmd=bootflow scan.

So for the entire series:

Tested-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>

Regards,
Jonas

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Simon Glass]

Hi Tom,

On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
>
> Hey all,
>
> I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> and it changed too much for everything else. I took about half of that
> series and then reworked a few things. Now only rk3399 platforms change
> at all and aside from bootcmd changes, the only thing is they now
> disable true/test/sysboot/showvar/false/exit commands as those were
> being pulled in from distro and now we don't set that flag. I think the
> way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> perform more SoC migrations.

Thanks for digging into this. I haven't seen any comments on the rpi
conversion, so perhaps people could test that?

Regards,
Simon

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

On Mon, Mar 27, 2023 at 05:00:31PM +1300, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> >
> > Hey all,
> >
> > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > and it changed too much for everything else. I took about half of that
> > series and then reworked a few things. Now only rk3399 platforms change
> > at all and aside from bootcmd changes, the only thing is they now
> > disable true/test/sysboot/showvar/false/exit commands as those were
> > being pulled in from distro and now we don't set that flag. I think the
> > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > perform more SoC migrations.
> 
> Thanks for digging into this. I haven't seen any comments on the rpi
> conversion, so perhaps people could test that?

Well, it needs to be rebased on top of this series (which will be merged
in the next -rc today).

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Tom Rini]

On Fri, 24 Mar 2023 16:58:09 -0400, Tom Rini wrote:

> Hey all,
> 
> I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> and it changed too much for everything else. I took about half of that
> series and then reworked a few things. Now only rk3399 platforms change
> at all and aside from bootcmd changes, the only thing is they now
> disable true/test/sysboot/showvar/false/exit commands as those were
> being pulled in from distro and now we don't set that flag. I think the
> way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> perform more SoC migrations.
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Peter Robinson]

On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> >
> > Hey all,
> >
> > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > and it changed too much for everything else. I took about half of that
> > series and then reworked a few things. Now only rk3399 platforms change
> > at all and aside from bootcmd changes, the only thing is they now
> > disable true/test/sysboot/showvar/false/exit commands as those were
> > being pulled in from distro and now we don't set that flag. I think the
> > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > perform more SoC migrations.
>
> Thanks for digging into this. I haven't seen any comments on the rpi
> conversion, so perhaps people could test that?

I was planning on looking at that once 2023.04 was out but TBH I have
wasted so much time over the last few cycles dealing with regressions
through a bunch of these series that I now have so little time for
enhancements I now shy away. I know a lot of these series should
improve things in the future but they don't feel like when there's
unnecessary changes for things that are clearly untested.

There's also a lot of change for changes sake, for example the
rockchips ATF binaries needed is called bl31.elf by the default output
of the ATF build process, for others it's bl31.bin, binman for what
ever reason has changed that to be atf-bl31, now I have to change the
entire build process to be able to work out what is what on a board by
board basis to be able to set the required variable to be able to
specify the ATF where  previously it "just worked (tm)"..... I suppose
there is some perceived goal and improvement here but with both my
"U-Boot device maintainer" and "distro maintainer" hats on, both of
which I do in my own spare time, I currently fail to see it and I end
up.

All that said, thank you Tom for picking up the pieces for something
which should have been actually working when it landed.

Tested-by: Peter Robinson <pbrobinson@gmail.com>

Now I get to go and work out all of the rest of the mess!

Regards,
Peter

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Simon Glass]

Hi Peter,

On Tue, 28 Mar 2023 at 06:50, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > Hey all,
> > >
> > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > and it changed too much for everything else. I took about half of that
> > > series and then reworked a few things. Now only rk3399 platforms change
> > > at all and aside from bootcmd changes, the only thing is they now
> > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > being pulled in from distro and now we don't set that flag. I think the
> > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > perform more SoC migrations.
> >
> > Thanks for digging into this. I haven't seen any comments on the rpi
> > conversion, so perhaps people could test that?
>
> I was planning on looking at that once 2023.04 was out but TBH I have
> wasted so much time over the last few cycles dealing with regressions
> through a bunch of these series that I now have so little time for
> enhancements I now shy away. I know a lot of these series should
> improve things in the future but they don't feel like when there's
> unnecessary changes for things that are clearly untested.
>
> There's also a lot of change for changes sake, for example the
> rockchips ATF binaries needed is called bl31.elf by the default output
> of the ATF build process, for others it's bl31.bin, binman for what
> ever reason has changed that to be atf-bl31, now I have to change the
> entire build process to be able to work out what is what on a board by
> board basis to be able to set the required variable to be able to
> specify the ATF where  previously it "just worked (tm)"..... I suppose

For this point, you could use the BL31 environment variable, which
would allow the old file to be used. That is in the instructions for
some boards.

Also, the change to atf-bl31 is because no particular filename is
provided as a default, so we end up using the entry type. I suppose
the problem is that there are two names in common use (bl31.bin and
bl31.elf) and if we use the wrong one it won't boot. That is an
unfortunate result of how things work with ATF. But in any case this
is a decision for the SoC maintainer, who can provide a default
filename if desired, in the binman description for that SoC.

> there is some perceived goal and improvement here but with both my
> "U-Boot device maintainer" and "distro maintainer" hats on, both of
> which I do in my own spare time, I currently fail to see it and I end
> up.

Basically the benefit is that U-Boot is not full of loads of strange
shell / Python scripts for each SoC type, it is possible (at least in
principle) to figure out how to build an image without scanning the
web for vendor-specific instructions, tools which are needed to build
images are registered (binman tool -l) and can be fetched. Overall,
having a data-driven approach to firmware packaging is vastly superior
to a code-based approach, particularly as firmware fragments more and
more. You can find more here [1]

>
> All that said, thank you Tom for picking up the pieces for something
> which should have been actually working when it landed.
>
> Tested-by: Peter Robinson <pbrobinson@gmail.com>
>
> Now I get to go and work out all of the rest of the mess!

Yes, thank you Tom.

Thank you also Peter for your comments. I suspect a lot of people feel
the same way.

From my perspective, these migrations can be exhausting, particularly
when drawn out over a long period of time. Removing SPL_FIT_GENERATOR
started almost 3 years ago[2]. People continued adding new boards to
it even until recently.

It is also often difficult to predict how things will turn out, even
for people with many years of experience in software development. So
we sometimes make wrong turns.

I would love to see more attention from SoC maintainers, to sit down
with a coffee once a month and take a hard look at the state of the
code they look after, what migrations are outstanding, etc.

The firmware world is changing rapidly. We need to be able to keep on
top of the increasing complexity with new tools and techniques.
Perhaps it will settle down at some point, but for now it is quite a
daunting task and we all need to pitch in.

Regards,
Simon

[1] https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#motivation
[2] https://patchwork.ozlabs.org/project/uboot/patch/20200613205717.v2.42.I2428dcb9b077364f9517f2c291db63b6bac1e992@changeid/

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]

On Mon, Mar 27, 2023 at 06:50:41PM +0100, Peter Robinson wrote:
> On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > Hey all,
> > >
> > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > and it changed too much for everything else. I took about half of that
> > > series and then reworked a few things. Now only rk3399 platforms change
> > > at all and aside from bootcmd changes, the only thing is they now
> > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > being pulled in from distro and now we don't set that flag. I think the
> > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > perform more SoC migrations.
> >
> > Thanks for digging into this. I haven't seen any comments on the rpi
> > conversion, so perhaps people could test that?
> 
> I was planning on looking at that once 2023.04 was out but TBH I have
> wasted so much time over the last few cycles dealing with regressions
> through a bunch of these series that I now have so little time for
> enhancements I now shy away. I know a lot of these series should
> improve things in the future but they don't feel like when there's
> unnecessary changes for things that are clearly untested.

I too am unhappy with how some of these have gone. The _intent_ here is
that getting the current "boot generic distro" framework is complex /
error prone, and we can do better. Unfortunately the first set of
platforms to switch to this are Rockchip and I think there was overlap
there with platforms that got broken at the end of the v2023.01 cycle to
fix other platforms, and then those sets of platforms flipped early in
v2023.04 and took until -rc2? to get resolved.  Which was less than
ideal.

> There's also a lot of change for changes sake, for example the
> rockchips ATF binaries needed is called bl31.elf by the default output
> of the ATF build process, for others it's bl31.bin, binman for what
> ever reason has changed that to be atf-bl31, now I have to change the
> entire build process to be able to work out what is what on a board by
> board basis to be able to set the required variable to be able to
> specify the ATF where  previously it "just worked (tm)"..... I suppose
> there is some perceived goal and improvement here but with both my
> "U-Boot device maintainer" and "distro maintainer" hats on, both of
> which I do in my own spare time, I currently fail to see it and I end
> up.

I wish I knew where to talk to with ATF / TF-A to get some agreed upon
naming scheme going as one of the things that is very frustrating is
getting the names and combinations of everything else that's required
Just Right for every chip. And feedback that things aren't working is
appreciated, since we do need to make things easier.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Peter Robinson]

On Wed, Mar 29, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Mar 27, 2023 at 06:50:41PM +0100, Peter Robinson wrote:
> > On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Tom,
> > >
> > > On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > Hey all,
> > > >
> > > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > > and it changed too much for everything else. I took about half of that
> > > > series and then reworked a few things. Now only rk3399 platforms change
> > > > at all and aside from bootcmd changes, the only thing is they now
> > > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > > being pulled in from distro and now we don't set that flag. I think the
> > > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > > perform more SoC migrations.
> > >
> > > Thanks for digging into this. I haven't seen any comments on the rpi
> > > conversion, so perhaps people could test that?
> >
> > I was planning on looking at that once 2023.04 was out but TBH I have
> > wasted so much time over the last few cycles dealing with regressions
> > through a bunch of these series that I now have so little time for
> > enhancements I now shy away. I know a lot of these series should
> > improve things in the future but they don't feel like when there's
> > unnecessary changes for things that are clearly untested.
>
> I too am unhappy with how some of these have gone. The _intent_ here is
> that getting the current "boot generic distro" framework is complex /
> error prone, and we can do better. Unfortunately the first set of
> platforms to switch to this are Rockchip and I think there was overlap
> there with platforms that got broken at the end of the v2023.01 cycle to
> fix other platforms, and then those sets of platforms flipped early in
> v2023.04 and took until -rc2? to get resolved.  Which was less than
> ideal.
>
> > There's also a lot of change for changes sake, for example the
> > rockchips ATF binaries needed is called bl31.elf by the default output
> > of the ATF build process, for others it's bl31.bin, binman for what
> > ever reason has changed that to be atf-bl31, now I have to change the
> > entire build process to be able to work out what is what on a board by
> > board basis to be able to set the required variable to be able to
> > specify the ATF where  previously it "just worked (tm)"..... I suppose
> > there is some perceived goal and improvement here but with both my
> > "U-Boot device maintainer" and "distro maintainer" hats on, both of
> > which I do in my own spare time, I currently fail to see it and I end
> > up.
>
> I wish I knew where to talk to with ATF / TF-A to get some agreed upon
> naming scheme going as one of the things that is very frustrating is
> getting the names and combinations of everything else that's required
> Just Right for every chip. And feedback that things aren't working is
> appreciated, since we do need to make things easier.

In all of the various make_fit_atf.py the various vendors specified
them, this is the case for the rockchip one [1]. This is the case for
the Allwinner boards [2] but the rockchip ports have missed this so it
also should be fixed for GA.

A side point is that binman should not be storing firmware build
specifics in the device tree which is a means of describing the
hardware, This really needs to be fixed as it really isn't the right
place for that sort of things. I suspect a file in arch/arm/mach-<SOC>
is likely a better location, or if it's board specific in the board/
sub directory.

Peter

[1] https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_atf.py#L227
[2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L64

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Simon Glass]

Hi Peter,

On Thu, 30 Mar 2023 at 19:56, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> On Wed, Mar 29, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Mar 27, 2023 at 06:50:41PM +0100, Peter Robinson wrote:
> > > On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > Hey all,
> > > > >
> > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > > > and it changed too much for everything else. I took about half of that
> > > > > series and then reworked a few things. Now only rk3399 platforms change
> > > > > at all and aside from bootcmd changes, the only thing is they now
> > > > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > > > being pulled in from distro and now we don't set that flag. I think the
> > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > > > perform more SoC migrations.
> > > >
> > > > Thanks for digging into this. I haven't seen any comments on the rpi
> > > > conversion, so perhaps people could test that?
> > >
> > > I was planning on looking at that once 2023.04 was out but TBH I have
> > > wasted so much time over the last few cycles dealing with regressions
> > > through a bunch of these series that I now have so little time for
> > > enhancements I now shy away. I know a lot of these series should
> > > improve things in the future but they don't feel like when there's
> > > unnecessary changes for things that are clearly untested.
> >
> > I too am unhappy with how some of these have gone. The _intent_ here is
> > that getting the current "boot generic distro" framework is complex /
> > error prone, and we can do better. Unfortunately the first set of
> > platforms to switch to this are Rockchip and I think there was overlap
> > there with platforms that got broken at the end of the v2023.01 cycle to
> > fix other platforms, and then those sets of platforms flipped early in
> > v2023.04 and took until -rc2? to get resolved.  Which was less than
> > ideal.
> >
> > > There's also a lot of change for changes sake, for example the
> > > rockchips ATF binaries needed is called bl31.elf by the default output
> > > of the ATF build process, for others it's bl31.bin, binman for what
> > > ever reason has changed that to be atf-bl31, now I have to change the
> > > entire build process to be able to work out what is what on a board by
> > > board basis to be able to set the required variable to be able to
> > > specify the ATF where  previously it "just worked (tm)"..... I suppose
> > > there is some perceived goal and improvement here but with both my
> > > "U-Boot device maintainer" and "distro maintainer" hats on, both of
> > > which I do in my own spare time, I currently fail to see it and I end
> > > up.
> >
> > I wish I knew where to talk to with ATF / TF-A to get some agreed upon
> > naming scheme going as one of the things that is very frustrating is
> > getting the names and combinations of everything else that's required
> > Just Right for every chip. And feedback that things aren't working is
> > appreciated, since we do need to make things easier.
>
> In all of the various make_fit_atf.py the various vendors specified
> them, this is the case for the rockchip one [1]. This is the case for
> the Allwinner boards [2] but the rockchip ports have missed this so it
> also should be fixed for GA.
>
> A side point is that binman should not be storing firmware build
> specifics in the device tree which is a means of describing the
> hardware, This really needs to be fixed as it really isn't the right
> place for that sort of things. I suspect a file in arch/arm/mach-<SOC>
> is likely a better location, or if it's board specific in the board/
> sub directory.

Sorry, I don't agree with that at all. We store configuration
information in devicetree in firmware as this seems to be best format
for it, particularly with the growing number of firmware components
that need to share this information at runtime. The layout of firmware
is an important part of the system. We are still figuring out the
flows though. Also I have not attempted to upstream the binman
binding. I am very open to ideas on how best to do that.

Regards,
Simon


>
> Peter
>
> [1] https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_atf.py#L227
> [2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L64

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Peter Robinson]

Hi Simon,

> > > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > > > > and it changed too much for everything else. I took about half of that
> > > > > > series and then reworked a few things. Now only rk3399 platforms change
> > > > > > at all and aside from bootcmd changes, the only thing is they now
> > > > > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > > > > being pulled in from distro and now we don't set that flag. I think the
> > > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > > > > perform more SoC migrations.
> > > > >
> > > > > Thanks for digging into this. I haven't seen any comments on the rpi
> > > > > conversion, so perhaps people could test that?
> > > >
> > > > I was planning on looking at that once 2023.04 was out but TBH I have
> > > > wasted so much time over the last few cycles dealing with regressions
> > > > through a bunch of these series that I now have so little time for
> > > > enhancements I now shy away. I know a lot of these series should
> > > > improve things in the future but they don't feel like when there's
> > > > unnecessary changes for things that are clearly untested.
> > >
> > > I too am unhappy with how some of these have gone. The _intent_ here is
> > > that getting the current "boot generic distro" framework is complex /
> > > error prone, and we can do better. Unfortunately the first set of
> > > platforms to switch to this are Rockchip and I think there was overlap
> > > there with platforms that got broken at the end of the v2023.01 cycle to
> > > fix other platforms, and then those sets of platforms flipped early in
> > > v2023.04 and took until -rc2? to get resolved.  Which was less than
> > > ideal.
> > >
> > > > There's also a lot of change for changes sake, for example the
> > > > rockchips ATF binaries needed is called bl31.elf by the default output
> > > > of the ATF build process, for others it's bl31.bin, binman for what
> > > > ever reason has changed that to be atf-bl31, now I have to change the
> > > > entire build process to be able to work out what is what on a board by
> > > > board basis to be able to set the required variable to be able to
> > > > specify the ATF where  previously it "just worked (tm)"..... I suppose
> > > > there is some perceived goal and improvement here but with both my
> > > > "U-Boot device maintainer" and "distro maintainer" hats on, both of
> > > > which I do in my own spare time, I currently fail to see it and I end
> > > > up.
> > >
> > > I wish I knew where to talk to with ATF / TF-A to get some agreed upon
> > > naming scheme going as one of the things that is very frustrating is
> > > getting the names and combinations of everything else that's required
> > > Just Right for every chip. And feedback that things aren't working is
> > > appreciated, since we do need to make things easier.
> >
> > In all of the various make_fit_atf.py the various vendors specified
> > them, this is the case for the rockchip one [1]. This is the case for
> > the Allwinner boards [2] but the rockchip ports have missed this so it
> > also should be fixed for GA.

Can you do a patch to fix this regression please and then specify the
correct pieces in the binman section then?

> > A side point is that binman should not be storing firmware build
> > specifics in the device tree which is a means of describing the
> > hardware, This really needs to be fixed as it really isn't the right
> > place for that sort of things. I suspect a file in arch/arm/mach-<SOC>
> > is likely a better location, or if it's board specific in the board/
> > sub directory.
>
> Sorry, I don't agree with that at all. We store configuration
> information in devicetree in firmware as this seems to be best format
> for it, particularly with the growing number of firmware components
> that need to share this information at runtime. The layout of firmware
> is an important part of the system. We are still figuring out the
> flows though. Also I have not attempted to upstream the binman
> binding. I am very open to ideas on how best to do that.

Rob what's your thoughts on the binman firmware build pieces being in
device tree and the process on upstreaming the bindings?

Regards,
Peter

> > [1] https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_atf.py#L227
> > [2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L64

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5602 bytes --]

On Fri, Mar 31, 2023 at 09:39:53AM +0100, Peter Robinson wrote:
> Hi Simon,
> 
> > > > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > > > > > and it changed too much for everything else. I took about half of that
> > > > > > > series and then reworked a few things. Now only rk3399 platforms change
> > > > > > > at all and aside from bootcmd changes, the only thing is they now
> > > > > > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > > > > > being pulled in from distro and now we don't set that flag. I think the
> > > > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > > > > > perform more SoC migrations.
> > > > > >
> > > > > > Thanks for digging into this. I haven't seen any comments on the rpi
> > > > > > conversion, so perhaps people could test that?
> > > > >
> > > > > I was planning on looking at that once 2023.04 was out but TBH I have
> > > > > wasted so much time over the last few cycles dealing with regressions
> > > > > through a bunch of these series that I now have so little time for
> > > > > enhancements I now shy away. I know a lot of these series should
> > > > > improve things in the future but they don't feel like when there's
> > > > > unnecessary changes for things that are clearly untested.
> > > >
> > > > I too am unhappy with how some of these have gone. The _intent_ here is
> > > > that getting the current "boot generic distro" framework is complex /
> > > > error prone, and we can do better. Unfortunately the first set of
> > > > platforms to switch to this are Rockchip and I think there was overlap
> > > > there with platforms that got broken at the end of the v2023.01 cycle to
> > > > fix other platforms, and then those sets of platforms flipped early in
> > > > v2023.04 and took until -rc2? to get resolved.  Which was less than
> > > > ideal.
> > > >
> > > > > There's also a lot of change for changes sake, for example the
> > > > > rockchips ATF binaries needed is called bl31.elf by the default output
> > > > > of the ATF build process, for others it's bl31.bin, binman for what
> > > > > ever reason has changed that to be atf-bl31, now I have to change the
> > > > > entire build process to be able to work out what is what on a board by
> > > > > board basis to be able to set the required variable to be able to
> > > > > specify the ATF where  previously it "just worked (tm)"..... I suppose
> > > > > there is some perceived goal and improvement here but with both my
> > > > > "U-Boot device maintainer" and "distro maintainer" hats on, both of
> > > > > which I do in my own spare time, I currently fail to see it and I end
> > > > > up.
> > > >
> > > > I wish I knew where to talk to with ATF / TF-A to get some agreed upon
> > > > naming scheme going as one of the things that is very frustrating is
> > > > getting the names and combinations of everything else that's required
> > > > Just Right for every chip. And feedback that things aren't working is
> > > > appreciated, since we do need to make things easier.
> > >
> > > In all of the various make_fit_atf.py the various vendors specified
> > > them, this is the case for the rockchip one [1]. This is the case for
> > > the Allwinner boards [2] but the rockchip ports have missed this so it
> > > also should be fixed for GA.
> 
> Can you do a patch to fix this regression please and then specify the
> correct pieces in the binman section then?
> 
> > > A side point is that binman should not be storing firmware build
> > > specifics in the device tree which is a means of describing the
> > > hardware, This really needs to be fixed as it really isn't the right
> > > place for that sort of things. I suspect a file in arch/arm/mach-<SOC>
> > > is likely a better location, or if it's board specific in the board/
> > > sub directory.
> >
> > Sorry, I don't agree with that at all. We store configuration
> > information in devicetree in firmware as this seems to be best format
> > for it, particularly with the growing number of firmware components
> > that need to share this information at runtime. The layout of firmware
> > is an important part of the system. We are still figuring out the
> > flows though. Also I have not attempted to upstream the binman
> > binding. I am very open to ideas on how best to do that.
> 
> Rob what's your thoughts on the binman firmware build pieces being in
> device tree and the process on upstreaming the bindings?

One question I have is, with your distribution person hat on, what do
you think the right answer here is? It's not that U-Boot requires TF-A
(and also other blobs depending on SoC) but rather that modern ARM SoCs
are like x86-64 SoCs have been for ages and require multiple parts to
get assembled "just so", to result in something that initializes enough
of the system to get to loading something that can load the OS, and also
provide assorted run time services. You have one set of fixups for
amlogic SoCs, another for sunxi, yet another for imx8* and so on. And so
long as the software does the job, some of those parts can be swapped
for different ones.  U-Boot has binman *stuff* because it's really
useful for us to be able to take an output and test our part of the
world. And since it's gotten more and more complex over the years, we've
moved from handfuls of one-off tools to binman with the intention of
making it easier, not harder, for the case of "I care about multiple
vastly different SoCs".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

[Simon Glass]

Hi Peter,

On Fri, 31 Mar 2023 at 21:40, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Simon,
>
> > > > > > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > > > > > and it changed too much for everything else. I took about half of that
> > > > > > > series and then reworked a few things. Now only rk3399 platforms change
> > > > > > > at all and aside from bootcmd changes, the only thing is they now
> > > > > > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > > > > > being pulled in from distro and now we don't set that flag. I think the
> > > > > > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > > > > > perform more SoC migrations.
> > > > > >
> > > > > > Thanks for digging into this. I haven't seen any comments on the rpi
> > > > > > conversion, so perhaps people could test that?
> > > > >
> > > > > I was planning on looking at that once 2023.04 was out but TBH I have
> > > > > wasted so much time over the last few cycles dealing with regressions
> > > > > through a bunch of these series that I now have so little time for
> > > > > enhancements I now shy away. I know a lot of these series should
> > > > > improve things in the future but they don't feel like when there's
> > > > > unnecessary changes for things that are clearly untested.
> > > >
> > > > I too am unhappy with how some of these have gone. The _intent_ here is
> > > > that getting the current "boot generic distro" framework is complex /
> > > > error prone, and we can do better. Unfortunately the first set of
> > > > platforms to switch to this are Rockchip and I think there was overlap
> > > > there with platforms that got broken at the end of the v2023.01 cycle to
> > > > fix other platforms, and then those sets of platforms flipped early in
> > > > v2023.04 and took until -rc2? to get resolved.  Which was less than
> > > > ideal.
> > > >
> > > > > There's also a lot of change for changes sake, for example the
> > > > > rockchips ATF binaries needed is called bl31.elf by the default output
> > > > > of the ATF build process, for others it's bl31.bin, binman for what
> > > > > ever reason has changed that to be atf-bl31, now I have to change the
> > > > > entire build process to be able to work out what is what on a board by
> > > > > board basis to be able to set the required variable to be able to
> > > > > specify the ATF where  previously it "just worked (tm)"..... I suppose
> > > > > there is some perceived goal and improvement here but with both my
> > > > > "U-Boot device maintainer" and "distro maintainer" hats on, both of
> > > > > which I do in my own spare time, I currently fail to see it and I end
> > > > > up.
> > > >
> > > > I wish I knew where to talk to with ATF / TF-A to get some agreed upon
> > > > naming scheme going as one of the things that is very frustrating is
> > > > getting the names and combinations of everything else that's required
> > > > Just Right for every chip. And feedback that things aren't working is
> > > > appreciated, since we do need to make things easier.
> > >
> > > In all of the various make_fit_atf.py the various vendors specified
> > > them, this is the case for the rockchip one [1]. This is the case for
> > > the Allwinner boards [2] but the rockchip ports have missed this so it
> > > also should be fixed for GA.
>
> Can you do a patch to fix this regression please and then specify the
> correct pieces in the binman section then?

Yes I think this should be fixed.

We don't have any Rockchip maintainers / contributors on this thread.
Would you like to start a new one, or add them to this thread?

>
> > > A side point is that binman should not be storing firmware build
> > > specifics in the device tree which is a means of describing the
> > > hardware, This really needs to be fixed as it really isn't the right
> > > place for that sort of things. I suspect a file in arch/arm/mach-<SOC>
> > > is likely a better location, or if it's board specific in the board/
> > > sub directory.
> >
> > Sorry, I don't agree with that at all. We store configuration
> > information in devicetree in firmware as this seems to be best format
> > for it, particularly with the growing number of firmware components
> > that need to share this information at runtime. The layout of firmware
> > is an important part of the system. We are still figuring out the
> > flows though. Also I have not attempted to upstream the binman
> > binding. I am very open to ideas on how best to do that.
>
> Rob what's your thoughts on the binman firmware build pieces being in
> device tree and the process on upstreaming the bindings?

It might be easier for Rob to comment on an actual proposal, which I
have not done. It is on my radar though.

Regards,
Simon


>
> Regards,
> Peter
>
> > > [1] https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_atf.py#L227
> > > [2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L64