* [PATCH v4 01/27] x86: Change how selection of ROMs works
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-07-19 19:55 ` [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot Simon Glass
` (52 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
Most x86 boards build a u-boot.rom which is programmed into SPI flash. But
this is not unique to x86. For example some rockchip boards can also boot
from SPI flash.
Also, at least on x86, binary blobs are sadly quite common. It is not
possible to build a functional image without them, and U-Boot needs to
know this at build time.
Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is
built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary
blobs are also needed. If they are not needed, it is safe to build the ROM
always. Otherwise we still require the BUILD_ROM environment variable.
For now this affects only x86, but future patches will enable this for
rockchip too.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v2)
Changes in v2:
- Drop 'rockchip' tag since this commit no-longer affects rockchip yet
- Drop ROM_NEEDS_BLOBS for baytrail since HAVE_FSP already selects it
Kconfig | 18 +++++++++++++++++-
Makefile | 18 +++++++++++++-----
arch/Kconfig | 1 +
arch/x86/Kconfig | 4 ++++
arch/x86/cpu/quark/Kconfig | 1 +
5 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/Kconfig b/Kconfig
index 566ca72c92..b3b8532d2c 100644
--- a/Kconfig
+++ b/Kconfig
@@ -276,9 +276,25 @@ config PHYS_64BIT
This can be used not only for 64bit SoCs, but also for
large physical address extension on 32bit SoCs.
+config HAS_ROM
+ bool
+ select BINMAN
+ help
+ Enables building of a u-boot.rom target. This collects U-Boot and
+ any necessary binary blobs.
+
+config ROM_NEEDS_BLOBS
+ bool
+ depends on HAS_ROM
+ help
+ Enable this if building the u-boot.rom target needs binary blobs, and
+ so cannot be done normally. In this case, pass BUILD_ROM=1 to make
+ to tell U-Boot to build the ROM.
+
config BUILD_ROM
bool "Build U-Boot as BIOS replacement"
- depends on X86
+ depends on HAS_ROM
+ default y if !ROM_NEEDS_BLOBS
help
This option allows to build a ROM version of U-Boot.
The build process generally requires several binary blobs
diff --git a/Makefile b/Makefile
index f55e40c590..df4e3d6c6b 100644
--- a/Makefile
+++ b/Makefile
@@ -921,9 +921,12 @@ ALL-$(CONFIG_REMAKE_ELF) += u-boot.elf
ALL-$(CONFIG_EFI_APP) += u-boot-app.efi
ALL-$(CONFIG_EFI_STUB) += u-boot-payload.efi
+ifneq ($(CONFIG_HAS_ROM),)
ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
-ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+ALL-y += u-boot.rom
endif
+endif
+
ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy)
ALL-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
endif
@@ -1585,7 +1588,7 @@ endif
# reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
# the middle. This is handled by binman based on an image description in the
# board's device tree.
-ifneq ($(CONFIG_X86_RESET_VECTOR),)
+ifneq ($(CONFIG_HAS_ROM),)
rom: u-boot.rom FORCE
refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE
@@ -1595,11 +1598,12 @@ quiet_cmd_ldr = LD $@
cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
$(filter-out FORCE,$^) -o $@
-u-boot.rom: u-boot-x86-start16.bin u-boot-x86-reset16.bin u-boot.bin \
+rom-deps := u-boot.bin
+ifdef CONFIG_X86
+rom-deps += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
$(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \
- $(if $(CONFIG_HAVE_REFCODE),refcode.bin) FORCE
- $(call if_changed,binman)
+ $(if $(CONFIG_HAVE_REFCODE),refcode.bin)
OBJCOPYFLAGS_u-boot-x86-start16.bin := -O binary -j .start16
u-boot-x86-start16.bin: u-boot FORCE
@@ -1610,6 +1614,10 @@ u-boot-x86-reset16.bin: u-boot FORCE
$(call if_changed,objcopy)
endif
+u-boot.rom: $(rom-deps) FORCE
+ $(call if_changed,binman)
+endif
+
ifneq ($(CONFIG_ARCH_SUNXI),)
ifeq ($(CONFIG_ARM64),)
u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.img u-boot.dtb FORCE
diff --git a/arch/Kconfig b/arch/Kconfig
index 9be02d1319..7f3cbe2ec8 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -160,6 +160,7 @@ config X86
select TIMER
select USE_PRIVATE_LIBGCC
select X86_TSC_TIMER
+ imply HAS_ROM if X86_RESET_VECTOR
imply BLK
imply CMD_DM
imply CMD_FPGA_LOADMK
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 27295ef384..f51b7c9f41 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -360,6 +360,8 @@ config HAVE_FSP
bool "Add an Firmware Support Package binary"
depends on !EFI
select USE_HOB
+ select HAS_ROM
+ select ROM_NEEDS_BLOBS
help
Select this option to add an Firmware Support Package binary to
the resulting U-Boot image. It is a binary blob which U-Boot uses
@@ -519,6 +521,8 @@ config ENABLE_MRC_CACHE
config HAVE_MRC
bool "Add a System Agent binary"
+ select HAS_ROM
+ select ROM_NEEDS_BLOBS
depends on !HAVE_FSP
help
Select this option to add a System Agent binary to
diff --git a/arch/x86/cpu/quark/Kconfig b/arch/x86/cpu/quark/Kconfig
index 430cce184d..2fee38aed7 100644
--- a/arch/x86/cpu/quark/Kconfig
+++ b/arch/x86/cpu/quark/Kconfig
@@ -24,6 +24,7 @@ if INTEL_QUARK
config HAVE_RMU
bool "Add a Remote Management Unit (RMU) binary"
+ select ROM_NEEDS_BLOBS
help
Select this option to add a Remote Management Unit (RMU) binary
to the resulting U-Boot image. It is a data block (up to 64K) of
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
2020-07-19 19:55 ` [PATCH v4 01/27] x86: Change how selection of ROMs works Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-08-08 10:59 ` Kever Yang
2020-07-19 19:55 ` [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards Simon Glass
` (51 subsequent siblings)
53 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
Bob is a Chromebook and can boot from SPI flash. Add it to the condition
check for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/mach-rockchip/spl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
index cddf4fd3d5..f148d48b6a 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -54,7 +54,8 @@ u32 spl_boot_device(void)
#if defined(CONFIG_TARGET_CHROMEBOOK_JERRY) || \
defined(CONFIG_TARGET_CHROMEBIT_MICKEY) || \
defined(CONFIG_TARGET_CHROMEBOOK_MINNIE) || \
- defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY)
+ defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY) || \
+ defined(CONFIG_TARGET_CHROMEBOOK_BOB)
return BOOT_DEVICE_SPI;
#endif
if (CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM))
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot
2020-07-19 19:55 ` [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot Simon Glass
@ 2020-08-08 10:59 ` Kever Yang
2020-08-08 13:28 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Kever Yang @ 2020-08-08 10:59 UTC (permalink / raw)
To: u-boot
Hi Simon,
? 2020/7/20 ??3:55, Simon Glass ??:
> Bob is a Chromebook and can boot from SPI flash. Add it to the condition
> check for this.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v1)
>
> arch/arm/mach-rockchip/spl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> index cddf4fd3d5..f148d48b6a 100644
> --- a/arch/arm/mach-rockchip/spl.c
> +++ b/arch/arm/mach-rockchip/spl.c
> @@ -54,7 +54,8 @@ u32 spl_boot_device(void)
> #if defined(CONFIG_TARGET_CHROMEBOOK_JERRY) || \
> defined(CONFIG_TARGET_CHROMEBIT_MICKEY) || \
> defined(CONFIG_TARGET_CHROMEBOOK_MINNIE) || \
> - defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY)
> + defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY) || \
> + defined(CONFIG_TARGET_CHROMEBOOK_BOB)
Can we use "u-boot,spl-boot-order" in dts instead of hardcode define here?
Thanks,
- Kever
> return BOOT_DEVICE_SPI;
> #endif
> if (CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BROM))
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot
2020-08-08 10:59 ` Kever Yang
@ 2020-08-08 13:28 ` Simon Glass
0 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-08-08 13:28 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Sat, 8 Aug 2020 at 04:59, Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Simon,
>
> ? 2020/7/20 ??3:55, Simon Glass ??:
> > Bob is a Chromebook and can boot from SPI flash. Add it to the condition
> > check for this.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/mach-rockchip/spl.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-rockchip/spl.c b/arch/arm/mach-rockchip/spl.c
> > index cddf4fd3d5..f148d48b6a 100644
> > --- a/arch/arm/mach-rockchip/spl.c
> > +++ b/arch/arm/mach-rockchip/spl.c
> > @@ -54,7 +54,8 @@ u32 spl_boot_device(void)
> > #if defined(CONFIG_TARGET_CHROMEBOOK_JERRY) || \
> > defined(CONFIG_TARGET_CHROMEBIT_MICKEY) || \
> > defined(CONFIG_TARGET_CHROMEBOOK_MINNIE) || \
> > - defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY)
> > + defined(CONFIG_TARGET_CHROMEBOOK_SPEEDY) || \
> > + defined(CONFIG_TARGET_CHROMEBOOK_BOB)
>
> Can we use "u-boot,spl-boot-order" in dts instead of hardcode define here?
Yes that sounds better. Will take a look.
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
2020-07-19 19:55 ` [PATCH v4 01/27] x86: Change how selection of ROMs works Simon Glass
2020-07-19 19:55 ` [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-07-19 19:55 ` [PATCH v4 04/27] rockchip: jerry: Add serial support Simon Glass
` (50 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
Some non-x86 devices can use SPI flash to boot and need to produce images
of a fixed size to program the flash.
Add a way to handle this for non-x86 boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Add a comment about CONFIG_SPL_FRAMEWORK
Makefile | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Makefile b/Makefile
index df4e3d6c6b..eb2fa50464 100644
--- a/Makefile
+++ b/Makefile
@@ -1612,6 +1612,20 @@ u-boot-x86-start16.bin: u-boot FORCE
OBJCOPYFLAGS_u-boot-x86-reset16.bin := -O binary -j .resetvec
u-boot-x86-reset16.bin: u-boot FORCE
$(call if_changed,objcopy)
+
+else # !CONFIG_X86
+
+ifdef CONFIG_SPL
+rom-deps += spl/u-boot-spl.bin
+
+# We can rely on CONFIG_SPL_FRAMEWORK being set for boards that use binman
+rom-deps += u-boot.img
+endif
+
+ifdef CONFIG_TPL
+rom-deps += tpl/u-boot-tpl.bin
+endif
+
endif
u-boot.rom: $(rom-deps) FORCE
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 04/27] rockchip: jerry: Add serial support
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (2 preceding siblings ...)
2020-07-19 19:55 ` [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-07-19 19:55 ` [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting Simon Glass
` (49 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
This option allows the serial console to work correctly. Add it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/chromebook_jerry_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/chromebook_jerry_defconfig b/configs/chromebook_jerry_defconfig
index e32de90843..c410b844d5 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -85,6 +85,7 @@ CONFIG_PWM_ROCKCHIP=y
CONFIG_RAM=y
CONFIG_SPL_RAM=y
CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_ROCKCHIP_SERIAL=y
CONFIG_SOUND=y
CONFIG_I2S=y
CONFIG_I2S_ROCKCHIP=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (3 preceding siblings ...)
2020-07-19 19:55 ` [PATCH v4 04/27] rockchip: jerry: Add serial support Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-07-19 19:55 ` [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry Simon Glass
` (48 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
Update the config for chromebook_bob to support booting from SPI flash.
The existing SPL size is too small since ATF is needed, so double it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/chromebook_bob_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index dad96d2ad1..4ffc33398a 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -3,7 +3,7 @@ CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x00200000
CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_ENV_OFFSET=0x3F8000
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x20000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x40000
CONFIG_SPL_TEXT_BASE=0xff8c2000
CONFIG_ROCKCHIP_RK3399=y
CONFIG_ROCKCHIP_BOOT_MODE_REG=0
@@ -40,6 +40,7 @@ CONFIG_SPL_OF_CONTROL=y
CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
CONFIG_ENV_IS_IN_MMC=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_ROCKCHIP_GPIO=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_SYS_I2C_ROCKCHIP=y
@@ -53,6 +54,7 @@ CONFIG_MMC_DW=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=1
CONFIG_SF_DEFAULT_SPEED=20000000
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_DM_ETH=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (4 preceding siblings ...)
2020-07-19 19:55 ` [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-07-19 19:55 ` [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob Simon Glass
` (47 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
produces a ROM for jerry.
Change the binman image definition to support multiple images, since it
may be used to build both u-boot-rockchip.bin and u-boot.rom
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
- Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
arch/arm/dts/rk3288-u-boot.dtsi | 24 ++++++++++++++++++++++++
arch/arm/dts/rockchip-u-boot.dtsi | 8 +++++++-
arch/arm/mach-rockchip/Kconfig | 9 +++++++++
arch/arm/mach-rockchip/rk3288/Kconfig | 2 ++
4 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 51b6e018bd..c87f00141f 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -12,6 +12,30 @@
};
};
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+&binman {
+ rom {
+ filename = "u-boot.rom";
+ size = <0x400000>;
+ pad-byte = <0xff>;
+
+ mkimage {
+ args = "-n rk3288 -T rkspi";
+ u-boot-spl {
+ };
+ };
+ u-boot-img {
+ offset = <0x20000>;
+ };
+ u-boot {
+ offset = <0x300000>;
+ };
+ fdtmap {
+ };
+ };
+};
+#endif
+
&dmc {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index a2559e2db0..0451db735e 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -6,7 +6,13 @@
#include <config.h>
/ {
- binman {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+&binman {
+ simple-bin {
filename = "u-boot-rockchip.bin";
pad-byte = <0xff>;
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index e2b6326584..dd1eec9f18 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -366,6 +366,15 @@ config TPL_ROCKCHIP_EARLYRETURN_TO_BROM
config SPL_MMC_SUPPORT
default y if !SPL_ROCKCHIP_BACK_TO_BROM
+config ROCKCHIP_SPI_IMAGE
+ bool "Build a SPI image for rockchip"
+ depends on HAS_ROM
+ help
+ Some Rockchip SoCs support booting from SPI flash. Enable this
+ option to produce a 4MB SPI-flash image (called u-boot.rom)
+ containing U-Boot. The image is built by binman. U-Boot sits near
+ the start of the image.
+
source "arch/arm/mach-rockchip/px30/Kconfig"
source "arch/arm/mach-rockchip/rk3036/Kconfig"
source "arch/arm/mach-rockchip/rk3128/Kconfig"
diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig b/arch/arm/mach-rockchip/rk3288/Kconfig
index afb62fca78..bb715e9d0e 100644
--- a/arch/arm/mach-rockchip/rk3288/Kconfig
+++ b/arch/arm/mach-rockchip/rk3288/Kconfig
@@ -5,7 +5,9 @@ choice
config TARGET_CHROMEBOOK_JERRY
bool "Google/Rockchip Veyron-Jerry Chromebook"
+ select HAS_ROM
select BOARD_LATE_INIT
+ select ROCKCHIP_SPI_IMAGE
help
Jerry is a RK3288-based clamshell device with 2 USB 3.0 ports,
HDMI, an 11.9 inch EDP display, micro-SD card, touchpad and
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (5 preceding siblings ...)
2020-07-19 19:55 ` [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-08-08 12:39 ` Kever Yang
2020-10-11 15:39 ` Emmanuel Vadot
2020-07-19 19:55 ` [PATCH v4 08/27] tegra: Drop the unused non-binman code Simon Glass
` (46 subsequent siblings)
53 siblings, 2 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
produces a ROM for bob.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
- Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
arch/arm/dts/rk3399-gru.dtsi | 2 +-
arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
4 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
index 7bddc3acdb..390ac2bb5a 100644
--- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
@@ -4,3 +4,7 @@
*/
#include "rk3399-u-boot.dtsi"
+
+&spi_flash {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
index 7ac88392f2..f9c5bb607b 100644
--- a/arch/arm/dts/rk3399-gru.dtsi
+++ b/arch/arm/dts/rk3399-gru.dtsi
@@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
pinctrl-names = "default", "sleep";
pinctrl-1 = <&spi1_sleep>;
- spiflash at 0 {
+ spi_flash: spiflash at 0 {
compatible = "jedec,spi-nor";
reg = <0>;
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 8237782408..ecd230c720 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -4,11 +4,14 @@
*/
#define USB_CLASS_HUB 9
+#include "rockchip-u-boot.dtsi"
+
/ {
aliases {
mmc0 = &sdhci;
mmc1 = &sdmmc;
pci0 = &pcie0;
+ spi1 = &spi1;
};
cic: syscon at ff620000 {
@@ -57,6 +60,30 @@
};
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+&binman {
+ rom {
+ filename = "u-boot.rom";
+ size = <0x400000>;
+ pad-byte = <0xff>;
+
+ mkimage {
+ args = "-n rk3399 -T rkspi";
+ u-boot-spl {
+ };
+ };
+ u-boot-img {
+ offset = <0x40000>;
+ };
+ u-boot {
+ offset = <0x300000>;
+ };
+ fdtmap {
+ };
+ };
+};
+#endif
+
&cru {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig
index 254b9c5b4d..17628f9171 100644
--- a/arch/arm/mach-rockchip/rk3399/Kconfig
+++ b/arch/arm/mach-rockchip/rk3399/Kconfig
@@ -5,6 +5,8 @@ choice
config TARGET_CHROMEBOOK_BOB
bool "Asus Flip C101PA Chromebook (RK3399)"
+ select HAS_ROM
+ select ROCKCHIP_SPI_IMAGE
help
Bob is a small RK3299-based device similar in apperance to Minnie.
It has two USB 3.0 type-C ports, 4GB of SDRAM, WiFi and a 10.1",
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-07-19 19:55 ` [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob Simon Glass
@ 2020-08-08 12:39 ` Kever Yang
2020-08-08 13:28 ` Simon Glass
2020-10-11 15:39 ` Emmanuel Vadot
1 sibling, 1 reply; 94+ messages in thread
From: Kever Yang @ 2020-08-08 12:39 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 2020/7/20 ??3:55, Simon Glass wrote:
> Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
> produces a ROM for bob.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v4:
> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
>
> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
> arch/arm/dts/rk3399-gru.dtsi | 2 +-
> arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
> arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
> 4 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> index 7bddc3acdb..390ac2bb5a 100644
> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> @@ -4,3 +4,7 @@
> */
>
> #include "rk3399-u-boot.dtsi"
> +
> +&spi_flash {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> index 7ac88392f2..f9c5bb607b 100644
> --- a/arch/arm/dts/rk3399-gru.dtsi
> +++ b/arch/arm/dts/rk3399-gru.dtsi
> @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
> pinctrl-names = "default", "sleep";
> pinctrl-1 = <&spi1_sleep>;
>
> - spiflash at 0 {
> + spi_flash: spiflash at 0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8237782408..ecd230c720 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -4,11 +4,14 @@
> */
> #define USB_CLASS_HUB 9
>
> +#include "rockchip-u-boot.dtsi"
> +
> / {
> aliases {
> mmc0 = &sdhci;
> mmc1 = &sdmmc;
> pci0 = &pcie0;
> + spi1 = &spi1;
> };
>
> cic: syscon at ff620000 {
> @@ -57,6 +60,30 @@
>
> };
>
> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> +&binman {
> + rom {
> + filename = "u-boot.rom";
> + size = <0x400000>;
> + pad-byte = <0xff>;
> +
> + mkimage {
> + args = "-n rk3399 -T rkspi";
> + u-boot-spl {
> + };
> + };
> + u-boot-img {
> + offset = <0x40000>;
> + };
> + u-boot {
> + offset = <0x300000>;
> + };
> + fdtmap {
> + };
There is a output name 'u-boot.rom' including:
- u-boot-spl output with mkimage cmd at offset 0?
- u-boot-img at offset 0x40000, how this is generated and what is
inside? does binary in bl31.elf included?
- u-boot at offset 0x300000, what is this binary and where is it from?
Thanks,
- Kever
> + };
> +};
> +#endif
> +
> &cru {
> u-boot,dm-pre-reloc;
> };
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig
> index 254b9c5b4d..17628f9171 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -5,6 +5,8 @@ choice
>
> config TARGET_CHROMEBOOK_BOB
> bool "Asus Flip C101PA Chromebook (RK3399)"
> + select HAS_ROM
> + select ROCKCHIP_SPI_IMAGE
> help
> Bob is a small RK3299-based device similar in apperance to Minnie.
> It has two USB 3.0 type-C ports, 4GB of SDRAM, WiFi and a 10.1",
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-08-08 12:39 ` Kever Yang
@ 2020-08-08 13:28 ` Simon Glass
2020-08-10 7:46 ` Kever Yang
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-08 13:28 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Sat, 8 Aug 2020 at 06:40, Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Simon,
>
> On 2020/7/20 ??3:55, Simon Glass wrote:
> > Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
> > produces a ROM for bob.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v4:
> > - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> >
> > arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
> > arch/arm/dts/rk3399-gru.dtsi | 2 +-
> > arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
> > arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
> > 4 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> > index 7bddc3acdb..390ac2bb5a 100644
> > --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> > @@ -4,3 +4,7 @@
> > */
> >
> > #include "rk3399-u-boot.dtsi"
> > +
> > +&spi_flash {
> > + u-boot,dm-pre-reloc;
> > +};
> > diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> > index 7ac88392f2..f9c5bb607b 100644
> > --- a/arch/arm/dts/rk3399-gru.dtsi
> > +++ b/arch/arm/dts/rk3399-gru.dtsi
> > @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
> > pinctrl-names = "default", "sleep";
> > pinctrl-1 = <&spi1_sleep>;
> >
> > - spiflash at 0 {
> > + spi_flash: spiflash at 0 {
> > compatible = "jedec,spi-nor";
> > reg = <0>;
> >
> > diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> > index 8237782408..ecd230c720 100644
> > --- a/arch/arm/dts/rk3399-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> > @@ -4,11 +4,14 @@
> > */
> > #define USB_CLASS_HUB 9
> >
> > +#include "rockchip-u-boot.dtsi"
> > +
> > / {
> > aliases {
> > mmc0 = &sdhci;
> > mmc1 = &sdmmc;
> > pci0 = &pcie0;
> > + spi1 = &spi1;
> > };
> >
> > cic: syscon at ff620000 {
> > @@ -57,6 +60,30 @@
> >
> > };
> >
> > +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> > +&binman {
> > + rom {
> > + filename = "u-boot.rom";
> > + size = <0x400000>;
> > + pad-byte = <0xff>;
> > +
> > + mkimage {
> > + args = "-n rk3399 -T rkspi";
> > + u-boot-spl {
> > + };
> > + };
> > + u-boot-img {
> > + offset = <0x40000>;
> > + };
> > + u-boot {
> > + offset = <0x300000>;
> > + };
> > + fdtmap {
> > + };
>
> There is a output name 'u-boot.rom' including:
>
> - u-boot-spl output with mkimage cmd at offset 0?
Yes
>
> - u-boot-img at offset 0x40000, how this is generated and what is
> inside? does binary in bl31.elf included?
It is just the u-boot.img file created by the Makefile. There is no BL31.
>
> - u-boot at offset 0x300000, what is this binary and where is it from?
This is u-boot.bin as created by the Makefile.
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-08-08 13:28 ` Simon Glass
@ 2020-08-10 7:46 ` Kever Yang
2020-08-13 2:51 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Kever Yang @ 2020-08-10 7:46 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 2020/8/8 ??9:28, Simon Glass wrote:
>>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> +&binman {
>>> + rom {
>>> + filename = "u-boot.rom";
>>> + size = <0x400000>;
>>> + pad-byte = <0xff>;
>>> +
>>> + mkimage {
>>> + args = "-n rk3399 -T rkspi";
>>> + u-boot-spl {
>>> + };
>>> + };
>>> + u-boot-img {
>>> + offset = <0x40000>;
>>> + };
>>> + u-boot {
>>> + offset = <0x300000>;
>>> + };
>>> + fdtmap {
>>> + };
>> There is a output name 'u-boot.rom' including:
>>
>> - u-boot-spl output with mkimage cmd at offset 0?
> Yes
>
>> - u-boot-img at offset 0x40000, how this is generated and what is
>> inside? does binary in bl31.elf included?
> It is just the u-boot.img file created by the Makefile. There is no BL31.
>
>> - u-boot at offset 0x300000, what is this binary and where is it from?
> This is u-boot.bin as created by the Makefile.
Why do you need both u-boot.img and u-boot.bin, I don't understand this.
And if there is no BL31, the system is not possible to boot up.
Thanks,
- Kever
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-08-10 7:46 ` Kever Yang
@ 2020-08-13 2:51 ` Simon Glass
0 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-08-13 2:51 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Mon, 10 Aug 2020 at 01:47, Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Simon,
>
> On 2020/8/8 ??9:28, Simon Glass wrote:
>
> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> +&binman {
> + rom {
> + filename = "u-boot.rom";
> + size = <0x400000>;
> + pad-byte = <0xff>;
> +
> + mkimage {
> + args = "-n rk3399 -T rkspi";
> + u-boot-spl {
> + };
> + };
> + u-boot-img {
> + offset = <0x40000>;
> + };
> + u-boot {
> + offset = <0x300000>;
> + };
> + fdtmap {
> + };
>
> There is a output name 'u-boot.rom' including:
>
> - u-boot-spl output with mkimage cmd at offset 0?
>
> Yes
>
> - u-boot-img at offset 0x40000, how this is generated and what is
> inside? does binary in bl31.elf included?
>
> It is just the u-boot.img file created by the Makefile. There is no BL31.
>
> - u-boot at offset 0x300000, what is this binary and where is it from?
>
> This is u-boot.bin as created by the Makefile.
>
> Why do you need both u-boot.img and u-boot.bin, I don't understand this.
Neither do I. It needs a look.
>
> And if there is no BL31, the system is not possible to boot up.
This was done quite a while ago with the objective of getting a basic
U-Boot going on this board, so it needs more work to finish it off.
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-07-19 19:55 ` [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob Simon Glass
2020-08-08 12:39 ` Kever Yang
@ 2020-10-11 15:39 ` Emmanuel Vadot
2020-10-14 18:37 ` Hugh Cole-Baker
1 sibling, 1 reply; 94+ messages in thread
From: Emmanuel Vadot @ 2020-10-11 15:39 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Sun, 19 Jul 2020 13:55:58 -0600
Simon Glass <sjg@chromium.org> wrote:
> Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
> produces a ROM for bob.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v4:
> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
>
> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
> arch/arm/dts/rk3399-gru.dtsi | 2 +-
> arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
> arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
> 4 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> index 7bddc3acdb..390ac2bb5a 100644
> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> @@ -4,3 +4,7 @@
> */
>
> #include "rk3399-u-boot.dtsi"
> +
> +&spi_flash {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> index 7ac88392f2..f9c5bb607b 100644
> --- a/arch/arm/dts/rk3399-gru.dtsi
> +++ b/arch/arm/dts/rk3399-gru.dtsi
> @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
> pinctrl-names = "default", "sleep";
> pinctrl-1 = <&spi1_sleep>;
>
> - spiflash at 0 {
> + spi_flash: spiflash at 0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
>
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8237782408..ecd230c720 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -4,11 +4,14 @@
> */
> #define USB_CLASS_HUB 9
>
> +#include "rockchip-u-boot.dtsi"
> +
> / {
> aliases {
> mmc0 = &sdhci;
> mmc1 = &sdmmc;
> pci0 = &pcie0;
> + spi1 = &spi1;
I don't really understand why but this added alias break spi flash
detection on rockpro64.
Removing it make it work again.
Cheers,
> };
>
> cic: syscon at ff620000 {
> @@ -57,6 +60,30 @@
>
> };
>
> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> +&binman {
> + rom {
> + filename = "u-boot.rom";
> + size = <0x400000>;
> + pad-byte = <0xff>;
> +
> + mkimage {
> + args = "-n rk3399 -T rkspi";
> + u-boot-spl {
> + };
> + };
> + u-boot-img {
> + offset = <0x40000>;
> + };
> + u-boot {
> + offset = <0x300000>;
> + };
> + fdtmap {
> + };
> + };
> +};
> +#endif
> +
> &cru {
> u-boot,dm-pre-reloc;
> };
> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig
> index 254b9c5b4d..17628f9171 100644
> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
> @@ -5,6 +5,8 @@ choice
>
> config TARGET_CHROMEBOOK_BOB
> bool "Asus Flip C101PA Chromebook (RK3399)"
> + select HAS_ROM
> + select ROCKCHIP_SPI_IMAGE
> help
> Bob is a small RK3299-based device similar in apperance to Minnie.
> It has two USB 3.0 type-C ports, 4GB of SDRAM, WiFi and a 10.1",
> --
> 2.28.0.rc0.105.gf9edc3c819-goog
>
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-10-11 15:39 ` Emmanuel Vadot
@ 2020-10-14 18:37 ` Hugh Cole-Baker
2020-11-03 15:11 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Hugh Cole-Baker @ 2020-10-14 18:37 UTC (permalink / raw)
To: u-boot
Hello,
> On 11 Oct 2020, at 16:39, Emmanuel Vadot <manu@bidouilliste.com> wrote:
>
>
> Hi Simon,
>
> On Sun, 19 Jul 2020 13:55:58 -0600
> Simon Glass <sjg@chromium.org> wrote:
>
>> Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
>> produces a ROM for bob.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> Changes in v4:
>> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
>>
>> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
>> arch/arm/dts/rk3399-gru.dtsi | 2 +-
>> arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
>> arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
>> 4 files changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> index 7bddc3acdb..390ac2bb5a 100644
>> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>> @@ -4,3 +4,7 @@
>> */
>>
>> #include "rk3399-u-boot.dtsi"
>> +
>> +&spi_flash {
>> + u-boot,dm-pre-reloc;
>> +};
>> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
>> index 7ac88392f2..f9c5bb607b 100644
>> --- a/arch/arm/dts/rk3399-gru.dtsi
>> +++ b/arch/arm/dts/rk3399-gru.dtsi
>> @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
>> pinctrl-names = "default", "sleep";
>> pinctrl-1 = <&spi1_sleep>;
>>
>> - spiflash at 0 {
>> + spi_flash: spiflash at 0 {
>> compatible = "jedec,spi-nor";
>> reg = <0>;
>>
>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
>> index 8237782408..ecd230c720 100644
>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
>> @@ -4,11 +4,14 @@
>> */
>> #define USB_CLASS_HUB 9
>>
>> +#include "rockchip-u-boot.dtsi"
>> +
>> / {
>> aliases {
>> mmc0 = &sdhci;
>> mmc1 = &sdmmc;
>> pci0 = &pcie0;
>> + spi1 = &spi1;
>
> I don't really understand why but this added alias break spi flash
> detection on rockpro64.
> Removing it make it work again.
I've noticed the same problem - rockpro64 already had an alias
spi0 = &spi1;
so after this change there are spi0 and spi1 aliases pointing to &spi1.
In U-Boot proper, that seems to cause the SPI flash to appear on bus 1
rather than the former bus 0, e.g. sf probe 1:0 works but sf probe 0:0
doesn't.
So I tried removing the spi0 alias and setting CONFIG_SF_DEFAULT_BUS=1
which fixed the flash detection in U-Boot proper, but now the SPL can't
load U-Boot from SPI flash - it fails with an "Invalid bus 1 (err=-19)"
It seems like SPL doesn't pay attention to the spi1 alias in the same
way that U-boot proper does, I haven't yet figured out why.
>
> Cheers,
>
>> };
>>
>> cic: syscon at ff620000 {
>> @@ -57,6 +60,30 @@
>>
>> };
>>
>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>> +&binman {
>> + rom {
>> + filename = "u-boot.rom";
>> + size = <0x400000>;
>> + pad-byte = <0xff>;
>> +
>> + mkimage {
>> + args = "-n rk3399 -T rkspi";
>> + u-boot-spl {
>> + };
>> + };
>> + u-boot-img {
>> + offset = <0x40000>;
>> + };
>> + u-boot {
>> + offset = <0x300000>;
>> + };
>> + fdtmap {
>> + };
>> + };
>> +};
>> +#endif
>> +
>> &cru {
>> u-boot,dm-pre-reloc;
>> };
>> diff --git a/arch/arm/mach-rockchip/rk3399/Kconfig b/arch/arm/mach-rockchip/rk3399/Kconfig
>> index 254b9c5b4d..17628f9171 100644
>> --- a/arch/arm/mach-rockchip/rk3399/Kconfig
>> +++ b/arch/arm/mach-rockchip/rk3399/Kconfig
>> @@ -5,6 +5,8 @@ choice
>>
>> config TARGET_CHROMEBOOK_BOB
>> bool "Asus Flip C101PA Chromebook (RK3399)"
>> + select HAS_ROM
>> + select ROCKCHIP_SPI_IMAGE
>> help
>> Bob is a small RK3299-based device similar in apperance to Minnie.
>> It has two USB 3.0 type-C ports, 4GB of SDRAM, WiFi and a 10.1",
>> --
>> 2.28.0.rc0.105.gf9edc3c819-goog
>>
>
>
> --
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-10-14 18:37 ` Hugh Cole-Baker
@ 2020-11-03 15:11 ` Simon Glass
2020-11-07 18:00 ` Emmanuel Vadot
2020-11-08 14:05 ` Hugh Cole-Baker
0 siblings, 2 replies; 94+ messages in thread
From: Simon Glass @ 2020-11-03 15:11 UTC (permalink / raw)
To: u-boot
Hi Hugh,
On Wed, 14 Oct 2020 at 12:37, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
>
> Hello,
> > On 11 Oct 2020, at 16:39, Emmanuel Vadot <manu@bidouilliste.com> wrote:
> >
> >
> > Hi Simon,
> >
> > On Sun, 19 Jul 2020 13:55:58 -0600
> > Simon Glass <sjg@chromium.org> wrote:
> >
> >> Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
> >> produces a ROM for bob.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >>
> >> Changes in v4:
> >> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> >>
> >> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
> >> arch/arm/dts/rk3399-gru.dtsi | 2 +-
> >> arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
> >> arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
> >> 4 files changed, 34 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> >> index 7bddc3acdb..390ac2bb5a 100644
> >> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
> >> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> >> @@ -4,3 +4,7 @@
> >> */
> >>
> >> #include "rk3399-u-boot.dtsi"
> >> +
> >> +&spi_flash {
> >> + u-boot,dm-pre-reloc;
> >> +};
> >> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> >> index 7ac88392f2..f9c5bb607b 100644
> >> --- a/arch/arm/dts/rk3399-gru.dtsi
> >> +++ b/arch/arm/dts/rk3399-gru.dtsi
> >> @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
> >> pinctrl-names = "default", "sleep";
> >> pinctrl-1 = <&spi1_sleep>;
> >>
> >> - spiflash at 0 {
> >> + spi_flash: spiflash at 0 {
> >> compatible = "jedec,spi-nor";
> >> reg = <0>;
> >>
> >> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> >> index 8237782408..ecd230c720 100644
> >> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> >> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> >> @@ -4,11 +4,14 @@
> >> */
> >> #define USB_CLASS_HUB 9
> >>
> >> +#include "rockchip-u-boot.dtsi"
> >> +
> >> / {
> >> aliases {
> >> mmc0 = &sdhci;
> >> mmc1 = &sdmmc;
> >> pci0 = &pcie0;
> >> + spi1 = &spi1;
> >
> > I don't really understand why but this added alias break spi flash
> > detection on rockpro64.
> > Removing it make it work again.
>
> I've noticed the same problem - rockpro64 already had an alias
>
> spi0 = &spi1;
>
> so after this change there are spi0 and spi1 aliases pointing to &spi1.
> In U-Boot proper, that seems to cause the SPI flash to appear on bus 1
> rather than the former bus 0, e.g. sf probe 1:0 works but sf probe 0:0
> doesn't.
>
> So I tried removing the spi0 alias and setting CONFIG_SF_DEFAULT_BUS=1
> which fixed the flash detection in U-Boot proper, but now the SPL can't
> load U-Boot from SPI flash - it fails with an "Invalid bus 1 (err=-19)"
> It seems like SPL doesn't pay attention to the spi1 alias in the same
> way that U-boot proper does, I haven't yet figured out why.
>
Could this be CONFIG_SPL_DM_SEQ_ALIAS ?
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-11-03 15:11 ` Simon Glass
@ 2020-11-07 18:00 ` Emmanuel Vadot
2020-11-08 14:05 ` Hugh Cole-Baker
1 sibling, 0 replies; 94+ messages in thread
From: Emmanuel Vadot @ 2020-11-07 18:00 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Tue, 3 Nov 2020 08:11:59 -0700
Simon Glass <sjg@chromium.org> wrote:
> Hi Hugh,
>
> On Wed, 14 Oct 2020 at 12:37, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
> >
> > Hello,
> > > On 11 Oct 2020, at 16:39, Emmanuel Vadot <manu@bidouilliste.com> wrote:
> > >
> > >
> > > Hi Simon,
> > >
> > > On Sun, 19 Jul 2020 13:55:58 -0600
> > > Simon Glass <sjg@chromium.org> wrote:
> > >
> > >> Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
> > >> produces a ROM for bob.
> > >>
> > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >> ---
> > >>
> > >> Changes in v4:
> > >> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> > >>
> > >> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
> > >> arch/arm/dts/rk3399-gru.dtsi | 2 +-
> > >> arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
> > >> arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
> > >> 4 files changed, 34 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> > >> index 7bddc3acdb..390ac2bb5a 100644
> > >> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
> > >> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
> > >> @@ -4,3 +4,7 @@
> > >> */
> > >>
> > >> #include "rk3399-u-boot.dtsi"
> > >> +
> > >> +&spi_flash {
> > >> + u-boot,dm-pre-reloc;
> > >> +};
> > >> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
> > >> index 7ac88392f2..f9c5bb607b 100644
> > >> --- a/arch/arm/dts/rk3399-gru.dtsi
> > >> +++ b/arch/arm/dts/rk3399-gru.dtsi
> > >> @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
> > >> pinctrl-names = "default", "sleep";
> > >> pinctrl-1 = <&spi1_sleep>;
> > >>
> > >> - spiflash at 0 {
> > >> + spi_flash: spiflash at 0 {
> > >> compatible = "jedec,spi-nor";
> > >> reg = <0>;
> > >>
> > >> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> > >> index 8237782408..ecd230c720 100644
> > >> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> > >> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> > >> @@ -4,11 +4,14 @@
> > >> */
> > >> #define USB_CLASS_HUB 9
> > >>
> > >> +#include "rockchip-u-boot.dtsi"
> > >> +
> > >> / {
> > >> aliases {
> > >> mmc0 = &sdhci;
> > >> mmc1 = &sdmmc;
> > >> pci0 = &pcie0;
> > >> + spi1 = &spi1;
> > >
> > > I don't really understand why but this added alias break spi flash
> > > detection on rockpro64.
> > > Removing it make it work again.
> >
> > I've noticed the same problem - rockpro64 already had an alias
> >
> > spi0 = &spi1;
> >
> > so after this change there are spi0 and spi1 aliases pointing to &spi1.
> > In U-Boot proper, that seems to cause the SPI flash to appear on bus 1
> > rather than the former bus 0, e.g. sf probe 1:0 works but sf probe 0:0
> > doesn't.
> >
> > So I tried removing the spi0 alias and setting CONFIG_SF_DEFAULT_BUS=1
> > which fixed the flash detection in U-Boot proper, but now the SPL can't
> > load U-Boot from SPI flash - it fails with an "Invalid bus 1 (err=-19)"
> > It seems like SPL doesn't pay attention to the spi1 alias in the same
> > way that U-boot proper does, I haven't yet figured out why.
> >
>
> Could this be CONFIG_SPL_DM_SEQ_ALIAS ?
>
> Regards,
> Simon
I don't know if you suggested to set CONFIG_SPL_DM_SEQ_ALIAS=y in
configs/rockpro64-rk3399_defconfig but this doesn't help.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-11-03 15:11 ` Simon Glass
2020-11-07 18:00 ` Emmanuel Vadot
@ 2020-11-08 14:05 ` Hugh Cole-Baker
1 sibling, 0 replies; 94+ messages in thread
From: Hugh Cole-Baker @ 2020-11-08 14:05 UTC (permalink / raw)
To: u-boot
Hi Simon,
> On 3 Nov 2020, at 15:11, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Hugh,
>
> On Wed, 14 Oct 2020 at 12:37, Hugh Cole-Baker <sigmaris@gmail.com> wrote:
>>
>> Hello,
>>> On 11 Oct 2020, at 16:39, Emmanuel Vadot <manu@bidouilliste.com> wrote:
>>>
>>>
>>> Hi Simon,
>>>
>>> On Sun, 19 Jul 2020 13:55:58 -0600
>>> Simon Glass <sjg@chromium.org> wrote:
>>>
>>>> Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
>>>> produces a ROM for bob.
>>>>
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>> ---
>>>>
>>>> Changes in v4:
>>>> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
>>>>
>>>> arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
>>>> arch/arm/dts/rk3399-gru.dtsi | 2 +-
>>>> arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
>>>> arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
>>>> 4 files changed, 34 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm/dts/rk3399-gru-u-boot.dtsi b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>>> index 7bddc3acdb..390ac2bb5a 100644
>>>> --- a/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>>> +++ b/arch/arm/dts/rk3399-gru-u-boot.dtsi
>>>> @@ -4,3 +4,7 @@
>>>> */
>>>>
>>>> #include "rk3399-u-boot.dtsi"
>>>> +
>>>> +&spi_flash {
>>>> + u-boot,dm-pre-reloc;
>>>> +};
>>>> diff --git a/arch/arm/dts/rk3399-gru.dtsi b/arch/arm/dts/rk3399-gru.dtsi
>>>> index 7ac88392f2..f9c5bb607b 100644
>>>> --- a/arch/arm/dts/rk3399-gru.dtsi
>>>> +++ b/arch/arm/dts/rk3399-gru.dtsi
>>>> @@ -537,7 +537,7 @@ ap_i2c_audio: &i2c8 {
>>>> pinctrl-names = "default", "sleep";
>>>> pinctrl-1 = <&spi1_sleep>;
>>>>
>>>> - spiflash at 0 {
>>>> + spi_flash: spiflash at 0 {
>>>> compatible = "jedec,spi-nor";
>>>> reg = <0>;
>>>>
>>>> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
>>>> index 8237782408..ecd230c720 100644
>>>> --- a/arch/arm/dts/rk3399-u-boot.dtsi
>>>> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
>>>> @@ -4,11 +4,14 @@
>>>> */
>>>> #define USB_CLASS_HUB 9
>>>>
>>>> +#include "rockchip-u-boot.dtsi"
>>>> +
>>>> / {
>>>> aliases {
>>>> mmc0 = &sdhci;
>>>> mmc1 = &sdmmc;
>>>> pci0 = &pcie0;
>>>> + spi1 = &spi1;
>>>
>>> I don't really understand why but this added alias break spi flash
>>> detection on rockpro64.
>>> Removing it make it work again.
>>
>> I've noticed the same problem - rockpro64 already had an alias
>>
>> spi0 = &spi1;
>>
>> so after this change there are spi0 and spi1 aliases pointing to &spi1.
>> In U-Boot proper, that seems to cause the SPI flash to appear on bus 1
>> rather than the former bus 0, e.g. sf probe 1:0 works but sf probe 0:0
>> doesn't.
>>
>> So I tried removing the spi0 alias and setting CONFIG_SF_DEFAULT_BUS=1
>> which fixed the flash detection in U-Boot proper, but now the SPL can't
>> load U-Boot from SPI flash - it fails with an "Invalid bus 1 (err=-19)"
>> It seems like SPL doesn't pay attention to the spi1 alias in the same
>> way that U-boot proper does, I haven't yet figured out why.
>>
>
> Could this be CONFIG_SPL_DM_SEQ_ALIAS ?
>
> Regards,
> Simon
Thanks for the pointer, that was the last missing piece to get SPI boot
working again on my board. I've just submitted a patch with the fix.
Regards,
Hugh
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 08/27] tegra: Drop the unused non-binman code
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (6 preceding siblings ...)
2020-07-19 19:55 ` [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob Simon Glass
@ 2020-07-19 19:55 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs Simon Glass
` (45 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:55 UTC (permalink / raw)
To: u-boot
This has been in the Makefile long enough to ensure migration is complete.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 16 +---------------
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/Makefile b/Makefile
index eb2fa50464..5b07bec3be 100644
--- a/Makefile
+++ b/Makefile
@@ -1646,23 +1646,9 @@ u-boot-x86-with-spl.bin: spl/u-boot-spl.bin u-boot.bin FORCE
$(call if_changed,binman)
ifneq ($(CONFIG_ARCH_TEGRA),)
-ifneq ($(CONFIG_BINMAN),)
# Makes u-boot-dtb-tegra.bin u-boot-tegra.bin u-boot-nodtb-tegra.bin
-%-dtb-tegra.bin %-tegra.bin %-nodtb-tegra.bin: \
- spl/%-spl %.bin FORCE
+%-dtb-tegra.bin %-tegra.bin %-nodtb-tegra.bin: spl/%-spl %.bin FORCE
$(call if_changed,binman)
-else
-OBJCOPYFLAGS_u-boot-nodtb-tegra.bin = -O binary --pad-to=$(CONFIG_SYS_TEXT_BASE)
-u-boot-nodtb-tegra.bin: spl/u-boot-spl u-boot-nodtb.bin FORCE
- $(call if_changed,pad_cat)
-
-OBJCOPYFLAGS_u-boot-tegra.bin = -O binary --pad-to=$(CONFIG_SYS_TEXT_BASE)
-u-boot-tegra.bin: spl/u-boot-spl u-boot.bin FORCE
- $(call if_changed,pad_cat)
-
-u-boot-dtb-tegra.bin: u-boot-tegra.bin FORCE
- $(call if_changed,copy)
-endif # binman
endif
OBJCOPYFLAGS_u-boot-app.efi := $(OBJCOPYFLAGS_EFI)
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (7 preceding siblings ...)
2020-07-19 19:55 ` [PATCH v4 08/27] tegra: Drop the unused non-binman code Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y Simon Glass
` (44 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present only the ARMv7 tegra SoCs actually use binman to create an
image. Change the config to reflect this, since otherwise running binman
will produce an error.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/mach-tegra/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 15e7684028..a397748b72 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -41,7 +41,6 @@ config TEGRA_PMC_SECURE
config TEGRA_COMMON
bool "Tegra common options"
- select BINMAN
select BOARD_EARLY_INIT_F
select CLK
select DM
@@ -69,6 +68,7 @@ config TEGRA_NO_BPMP
config TEGRA_ARMV7_COMMON
bool "Tegra 32-bit common options"
+ select BINMAN
select CPU_V7A
select SPL
select SPL_BOARD_INIT if SPL
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (8 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed Simon Glass
` (43 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
When binman is in use, most of the targets built by the Makefile are
inputs to binman. We then need a final rule to run binman to produce the
final outputs.
Rename the variable to indicate this, and add a new 'inputs' target.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v4:
- Update for changes to arch/arm/mach-k3/config.mk
Makefile | 60 +++++++++++++++++---------------
arch/arm/config.mk | 10 +++---
arch/arm/mach-at91/config.mk | 2 +-
arch/arm/mach-davinci/config.mk | 2 +-
arch/arm/mach-k3/config.mk | 10 +++---
arch/arm/mach-keystone/config.mk | 4 +--
arch/arm/mach-omap2/config.mk | 28 +++++++--------
arch/arm/mach-rmobile/Makefile | 2 +-
arch/arm/mach-stm32mp/config.mk | 4 +--
board/BuR/brppt1/config.mk | 4 +--
board/BuR/brppt2/config.mk | 4 +--
board/BuR/brsmarc1/config.mk | 6 ++--
board/imgtec/boston/config.mk | 2 +-
board/intel/edison/config.mk | 2 +-
scripts/Makefile.spl | 24 ++++++-------
tools/binman/README | 2 +-
16 files changed, 85 insertions(+), 81 deletions(-)
diff --git a/Makefile b/Makefile
index 5b07bec3be..0147d9d49b 100644
--- a/Makefile
+++ b/Makefile
@@ -885,80 +885,80 @@ quiet_cmd_static_rela =
cmd_static_rela =
endif
-# Always append ALL so that arch config.mk's can add custom ones
-ALL-y += u-boot.srec u-boot.bin u-boot.sym System.map binary_size_check
+# Always append INPUTS so that arch config.mk's can add custom ones
+INPUTS-y += u-boot.srec u-boot.bin u-boot.sym System.map binary_size_check
-ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
+INPUTS-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin
ifeq ($(CONFIG_SPL_FSL_PBL),y)
-ALL-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin
+INPUTS-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin
else
ifneq ($(CONFIG_NXP_ESBC), y)
# For Secure Boot The Image needs to be signed and Header must also
# be included. So The image has to be built explicitly
-ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl
+INPUTS-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl
endif
endif
-ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin
+INPUTS-$(CONFIG_SPL) += spl/u-boot-spl.bin
ifeq ($(CONFIG_MX6)$(CONFIG_IMX_HAB), yy)
-ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot-ivt.img
+INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot-ivt.img
else
ifeq ($(CONFIG_MX7)$(CONFIG_IMX_HAB), yy)
-ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot-ivt.img
+INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot-ivt.img
else
-ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
+INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot.img
endif
endif
-ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
-ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb
+INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
+INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb
ifeq ($(CONFIG_SPL_FRAMEWORK),y)
-ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
+INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
endif
-ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
+INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
ifneq ($(CONFIG_SPL_TARGET),)
-ALL-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
+INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
endif
-ALL-$(CONFIG_REMAKE_ELF) += u-boot.elf
-ALL-$(CONFIG_EFI_APP) += u-boot-app.efi
-ALL-$(CONFIG_EFI_STUB) += u-boot-payload.efi
+INPUTS-$(CONFIG_REMAKE_ELF) += u-boot.elf
+INPUTS-$(CONFIG_EFI_APP) += u-boot-app.efi
+INPUTS-$(CONFIG_EFI_STUB) += u-boot-payload.efi
ifneq ($(CONFIG_HAS_ROM),)
ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
-ALL-y += u-boot.rom
+INPUTS-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
endif
endif
ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy)
-ALL-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
+INPUTS-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
endif
# Build a combined spl + u-boot image for sunxi
ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
-ALL-y += u-boot-sunxi-with-spl.bin
+INPUTS-y += u-boot-sunxi-with-spl.bin
endif
# enable combined SPL/u-boot/dtb rules for tegra
ifeq ($(CONFIG_ARCH_TEGRA)$(CONFIG_SPL),yy)
-ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
-ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
+INPUTS-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
+INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
endif
-ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
+INPUTS-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
# Add optional build target if defined in board/cpu/soc headers
ifneq ($(CONFIG_BUILD_TARGET),)
-ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
+INPUTS-y += $(CONFIG_BUILD_TARGET:"%"=%)
endif
ifeq ($(CONFIG_INIT_SP_RELATIVE)$(CONFIG_OF_SEPARATE),yy)
-ALL-y += init_sp_bss_offset_check
+INPUTS-y += init_sp_bss_offset_check
endif
ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
-ALL-y += u-boot-with-dtb.bin
+INPUTS-y += u-boot-with-dtb.bin
endif
ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
-ALL-y += u-boot-rockchip.bin
+INPUTS-y += u-boot-rockchip.bin
endif
LDFLAGS_u-boot += $(LDFLAGS_FINAL)
@@ -1015,7 +1015,11 @@ quiet_cmd_cfgcheck = CFGCHK $2
cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
$(srctree)/scripts/config_whitelist.txt $(srctree)
-all: $(ALL-y)
+PHONY += inputs
+inputs: $(INPUTS-y)
+
+all: inputs
+
ifeq ($(CONFIG_DEPRECATED),y)
$(warning "You have deprecated configuration options enabled in your .config! Please check your configuration.")
ifeq ($(CONFIG_SPI),y)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index f25603109e..4153f7e371 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -122,7 +122,7 @@ endif
ifneq ($(CONFIG_SPL_BUILD),y)
# Check that only R_ARM_RELATIVE relocations are generated.
-ALL-y += checkarmreloc
+INPUTS-y += checkarmreloc
# The movt / movw can hardcode 16 bit parts of the addresses in the
# instruction. Relocation is not supported for that case, so disable
# such usage by requiring word relocations.
@@ -154,17 +154,17 @@ endif
ifneq ($(CONFIG_IMX_CONFIG),)
ifdef CONFIG_SPL
ifndef CONFIG_SPL_BUILD
-ALL-y += SPL
+INPUTS-y += SPL
endif
else
ifeq ($(CONFIG_OF_SEPARATE),y)
-ALL-y += u-boot-dtb.imx
+INPUTS-y += u-boot-dtb.imx
else
-ALL-y += u-boot.imx
+INPUTS-y += u-boot.imx
endif
endif
ifneq ($(CONFIG_VF610),)
-ALL-y += u-boot.vyb
+INPUTS-y += u-boot.vyb
endif
endif
diff --git a/arch/arm/mach-at91/config.mk b/arch/arm/mach-at91/config.mk
index 9a023efb19..5426394651 100644
--- a/arch/arm/mach-at91/config.mk
+++ b/arch/arm/mach-at91/config.mk
@@ -4,6 +4,6 @@ endif
ifeq ($(CONFIG_CPU_V7A),y)
ifndef CONFIG_SPL_BUILD
-ALL-y += u-boot.img
+INPUTS-y += u-boot.img
endif
endif
diff --git a/arch/arm/mach-davinci/config.mk b/arch/arm/mach-davinci/config.mk
index 5a33982e2d..4674cae43b 100644
--- a/arch/arm/mach-davinci/config.mk
+++ b/arch/arm/mach-davinci/config.mk
@@ -2,5 +2,5 @@
#
# Copyright (C) 2012, Texas Instruments, Incorporated - http://www.ti.com/
ifndef CONFIG_SPL_BUILD
-ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.ais
+INPUTS-$(CONFIG_SPL_FRAMEWORK) += u-boot.ais
endif
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
index f7afef610c..c9538718e7 100644
--- a/arch/arm/mach-k3/config.mk
+++ b/arch/arm/mach-k3/config.mk
@@ -44,7 +44,7 @@ tiboot3.bin: image_check FORCE
$(srctree)/tools/k3_gen_x509_cert.sh -c 16 -b $(obj)/u-boot-spl.bin \
-o $@ -l $(CONFIG_SPL_TEXT_BASE) -k $(KEY)
-ALL-y += tiboot3.bin
+INPUTS-y += tiboot3.bin
endif
ifdef CONFIG_ARM64
@@ -52,10 +52,10 @@ ifdef CONFIG_ARM64
ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
SPL_ITS := u-boot-spl-k3_HS.its
$(SPL_ITS): export IS_HS=1
-ALL-y += tispl.bin_HS
+INPUTS-y += tispl.bin_HS
else
SPL_ITS := u-boot-spl-k3.its
-ALL-y += tispl.bin
+INPUTS-y += tispl.bin
endif
quiet_cmd_k3_mkits = MKITS $@
@@ -70,9 +70,9 @@ endif
else
ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ALL-y += u-boot.img_HS
+INPUTS-y += u-boot.img_HS
else
-ALL-y += u-boot.img
+INPUTS-y += u-boot.img
endif
endif
diff --git a/arch/arm/mach-keystone/config.mk b/arch/arm/mach-keystone/config.mk
index 5806f8f5d1..5a16891f23 100644
--- a/arch/arm/mach-keystone/config.mk
+++ b/arch/arm/mach-keystone/config.mk
@@ -9,9 +9,9 @@ include $(srctree)/arch/arm/mach-omap2/config_secure.mk
ifndef CONFIG_SPL_BUILD
ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ALL-y += u-boot_HS_MLO
+INPUTS-y += u-boot_HS_MLO
else
-ALL-y += MLO
+INPUTS-y += MLO
endif
endif
diff --git a/arch/arm/mach-omap2/config.mk b/arch/arm/mach-omap2/config.mk
index af455366ed..4f0d2598fa 100644
--- a/arch/arm/mach-omap2/config.mk
+++ b/arch/arm/mach-omap2/config.mk
@@ -18,9 +18,9 @@ ifeq ($(CONFIG_TI_SECURE_DEVICE),y) # Refer to README.ti-secure for more info
# For booting spl from QSPI or NOR use
# u-boot-spl_HS_X-LOADER
ifeq ($(CONFIG_OMAP54XX),y)
-ALL-y += u-boot-spl_HS_MLO
-ALL-y += u-boot-spl_HS_ULO
-ALL-y += u-boot-spl_HS_X-LOADER
+INPUTS-y += u-boot-spl_HS_MLO
+INPUTS-y += u-boot-spl_HS_ULO
+INPUTS-y += u-boot-spl_HS_X-LOADER
endif
# On AM43XX:
#
@@ -30,8 +30,8 @@ endif
# For booting spl from all other media use
# u-boot-spl_HS_ISSW
ifeq ($(CONFIG_AM43XX),y)
-ALL-y += u-boot-spl_HS_SPI_X-LOADER
-ALL-y += u-boot-spl_HS_ISSW
+INPUTS-y += u-boot-spl_HS_SPI_X-LOADER
+INPUTS-y += u-boot-spl_HS_ISSW
endif
# On AM33XX:
#
@@ -47,21 +47,21 @@ endif
# For booting spl over UART, USB, or Ethernet use
# u-boot-spl_HS_2ND
ifeq ($(CONFIG_AM33XX),y)
-ALL-y += u-boot-spl_HS_SPI_X-LOADER
-ALL-y += u-boot-spl_HS_X-LOADER
-ALL-y += u-boot-spl_HS_MLO
-ALL-y += u-boot-spl_HS_2ND
+INPUTS-y += u-boot-spl_HS_SPI_X-LOADER
+INPUTS-y += u-boot-spl_HS_X-LOADER
+INPUTS-y += u-boot-spl_HS_MLO
+INPUTS-y += u-boot-spl_HS_2ND
endif
else
-ALL-y += MLO
+INPUTS-y += MLO
ifeq ($(CONFIG_AM33XX),y)
-ALL-y += MLO.byteswap
+INPUTS-y += MLO.byteswap
endif
endif
else
ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ALL-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
-ALL-$(CONFIG_SPL_LOAD_FIT) += u-boot_HS.img
+INPUTS-$(CONFIG_QSPI_BOOT) += u-boot_HS_XIP_X-LOADER
+INPUTS-$(CONFIG_SPL_LOAD_FIT) += u-boot_HS.img
endif
-ALL-y += u-boot.img
+INPUTS-y += u-boot.img
endif
diff --git a/arch/arm/mach-rmobile/Makefile b/arch/arm/mach-rmobile/Makefile
index a3fdcc3bc0..3206bce722 100644
--- a/arch/arm/mach-rmobile/Makefile
+++ b/arch/arm/mach-rmobile/Makefile
@@ -84,5 +84,5 @@ spl/u-boot-spl.scif: spl/u-boot-spl.srec spl/u-boot-spl.bin
# if srec_cat is present build u-boot-spl.scif by default
has_srec_cat = $(call try-run,srec_cat -VERSion,y,n)
-ALL-$(has_srec_cat) += u-boot-spl.scif
+INPUTS-$(has_srec_cat) += u-boot-spl.scif
CLEAN_FILES += u-boot-spl.scif
diff --git a/arch/arm/mach-stm32mp/config.mk b/arch/arm/mach-stm32mp/config.mk
index 403af2a225..c30bf482f7 100644
--- a/arch/arm/mach-stm32mp/config.mk
+++ b/arch/arm/mach-stm32mp/config.mk
@@ -4,10 +4,10 @@
#
ifndef CONFIG_SPL
-ALL-y += u-boot.stm32
+INPUTS-y += u-boot.stm32
else
ifdef CONFIG_SPL_BUILD
-ALL-y += u-boot-spl.stm32
+INPUTS-y += u-boot-spl.stm32
endif
endif
diff --git a/board/BuR/brppt1/config.mk b/board/BuR/brppt1/config.mk
index b11b544c37..6853135f83 100644
--- a/board/BuR/brppt1/config.mk
+++ b/board/BuR/brppt1/config.mk
@@ -25,8 +25,8 @@ cmd_prodzip = \
zip -9 -r $@ misc/* >/dev/null $<
ifeq ($(hw-platform-y),brppt1-spi)
-ALL-y += $(hw-platform-y)_prog.bin
-ALL-y += $(hw-platform-y)_prod.zip
+INPUTS-y += $(hw-platform-y)_prog.bin
+INPUTS-y += $(hw-platform-y)_prod.zip
endif
$(hw-platform-y)_prog.bin: u-boot-dtb.img spl/u-boot-spl.bin
diff --git a/board/BuR/brppt2/config.mk b/board/BuR/brppt2/config.mk
index fa973db762..0d1638a97a 100644
--- a/board/BuR/brppt2/config.mk
+++ b/board/BuR/brppt2/config.mk
@@ -24,8 +24,8 @@ cmd_prodzip = \
ifeq ($(hw-platform-y),brppt2)
ifneq ($(CONFIG_SPL_BUILD),y)
-ALL-y += $(hw-platform-y)_prog.bin
-ALL-y += $(hw-platform-y)_prod.zip
+INPUTS-y += $(hw-platform-y)_prog.bin
+INPUTS-y += $(hw-platform-y)_prod.zip
endif
endif
diff --git a/board/BuR/brsmarc1/config.mk b/board/BuR/brsmarc1/config.mk
index 0692988507..1de971876c 100644
--- a/board/BuR/brsmarc1/config.mk
+++ b/board/BuR/brsmarc1/config.mk
@@ -23,11 +23,11 @@ cmd_prodzip = \
cp u-boot-dtb.img misc/ && \
zip -9 -r $@ misc/* >/dev/null $<
-ALL-y += $(hw-platform-y)_prog.bin
-ALL-y += $(hw-platform-y)_prod.zip
+INPUTS-y += $(hw-platform-y)_prog.bin
+INPUTS-y += $(hw-platform-y)_prod.zip
$(hw-platform-y)_prog.bin: u-boot-dtb.img spl/u-boot-spl.bin
$(call if_changed,prodbin)
$(hw-platform-y)_prod.zip: $(hw-platform-y)_prog.bin
- $(call if_changed,prodzip)
\ No newline@end of file
+ $(call if_changed,prodzip)
diff --git a/board/imgtec/boston/config.mk b/board/imgtec/boston/config.mk
index 8cfc9c6894..c1e242f108 100644
--- a/board/imgtec/boston/config.mk
+++ b/board/imgtec/boston/config.mk
@@ -11,5 +11,5 @@ u-boot.mcs: u-boot.bin
# if srec_cat is present build u-boot.mcs by default
has_srec_cat = $(call try-run,srec_cat -VERSion,y,n)
-ALL-$(has_srec_cat) += u-boot.mcs
+INPUTS-$(has_srec_cat) += u-boot.mcs
CLEAN_FILES += u-boot.mcs
diff --git a/board/intel/edison/config.mk b/board/intel/edison/config.mk
index fdcbbdf3b1..8c6087e290 100644
--- a/board/intel/edison/config.mk
+++ b/board/intel/edison/config.mk
@@ -10,7 +10,7 @@ cmd_mkalign_eds = \
dd if=$^ of=$@ bs=4k seek=1 2>/dev/null && \
mv $@ $^
-ALL-y += u-boot-align.bin
+INPUTS-y += u-boot-align.bin
u-boot-align.bin: u-boot.bin
$(call if_changed,mkalign_eds)
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e6d56a1286..d528c994ff 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -213,42 +213,42 @@ spl/boot.bin: $(obj)/$(SPL_BIN)-align.bin FORCE
$(call if_changed,mkimage)
endif
-ALL-y += $(obj)/$(SPL_BIN).bin
+INPUTS-y += $(obj)/$(SPL_BIN).bin
ifdef CONFIG_SAMSUNG
-ALL-y += $(obj)/$(BOARD)-spl.bin
+INPUTS-y += $(obj)/$(BOARD)-spl.bin
endif
ifneq ($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
-ALL-y += $(obj)/$(SPL_BIN).sfp
+INPUTS-y += $(obj)/$(SPL_BIN).sfp
endif
ifdef CONFIG_ARCH_SUNXI
-ALL-y += $(obj)/sunxi-spl.bin
+INPUTS-y += $(obj)/sunxi-spl.bin
ifdef CONFIG_NAND_SUNXI
-ALL-y += $(obj)/sunxi-spl-with-ecc.bin
+INPUTS-y += $(obj)/sunxi-spl-with-ecc.bin
endif
endif
ifeq ($(CONFIG_SYS_SOC),"at91")
-ALL-y += $(obj)/boot.bin
+INPUTS-y += $(obj)/boot.bin
endif
ifdef CONFIG_TPL_BUILD
-ALL-$(CONFIG_TPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-start16-tpl.bin \
+INPUTS-$(CONFIG_TPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-start16-tpl.bin \
$(obj)/u-boot-x86-reset16-tpl.bin
else
-ALL-$(CONFIG_SPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-start16-spl.bin \
+INPUTS-$(CONFIG_SPL_X86_16BIT_INIT) += $(obj)/u-boot-x86-start16-spl.bin \
$(obj)/u-boot-x86-reset16-spl.bin
endif
-ALL-$(CONFIG_ARCH_ZYNQ) += $(obj)/boot.bin
-ALL-$(CONFIG_ARCH_ZYNQMP) += $(obj)/boot.bin
+INPUTS-$(CONFIG_ARCH_ZYNQ) += $(obj)/boot.bin
+INPUTS-$(CONFIG_ARCH_ZYNQMP) += $(obj)/boot.bin
-ALL-$(CONFIG_ARCH_MEDIATEK) += $(obj)/u-boot-spl-mtk.bin
+INPUTS-$(CONFIG_ARCH_MEDIATEK) += $(obj)/u-boot-spl-mtk.bin
-all: $(ALL-y)
+all: $(INPUTS-y)
quiet_cmd_cat = CAT $@
cmd_cat = cat $(filter-out $(PHONY), $^) > $@
diff --git a/tools/binman/README b/tools/binman/README
index a6a3ee48aa..37ee3fc2d3 100644
--- a/tools/binman/README
+++ b/tools/binman/README
@@ -220,7 +220,7 @@ u-boot-<your_suffix>.bin: <input_file_1> <input_file_2> checkbinman FORCE
endif
This assumes that u-boot-<your_suffix>.bin is a target, and is the final file
-that you need to produce. You can make it a target by adding it to ALL-y
+that you need to produce. You can make it a target by adding it to INPUTS-y
either in the main Makefile or in a config.mk file in your arch subdirectory.
Once binman is executed it will pick up its instructions from a device-tree
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (9 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman Simon Glass
` (42 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
Quite a few boards using this SoC family don't use binman, yet
CONFIG_BINMAN is enabled for all of them. But the option should only be
enabled if we expect binman to produce an image. Calling binman when the
device tree is missing, etc. will cause failer.
Add a condition so that CONFIG_BINMAN is only enabled as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c2c577f60c..6a2e88fed2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -20,7 +20,7 @@ config MPC85xx
select CREATE_ARCH_SYMLINK
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
- select BINMAN
+ select BINMAN if OF_SEPARATE
imply CMD_HASH
imply CMD_IRQ
imply USB_EHCI_HCD if USB
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (10 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-08-05 14:20 ` sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman) André Przywara
2020-07-19 19:56 ` [PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM Simon Glass
` (41 subsequent siblings)
53 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
On x86 various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
Update the Makefile to have a separate, final step which runs binman,
once all input dependencies are present.
This avoid sprinkling the Makefile with arch-specific code.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Drop rockchip changes which should not be in this patch
Makefile | 63 +++++++++++++-------------------------------------------
1 file changed, 14 insertions(+), 49 deletions(-)
diff --git a/Makefile b/Makefile
index 0147d9d49b..b4b5b10813 100644
--- a/Makefile
+++ b/Makefile
@@ -921,16 +921,6 @@ INPUTS-$(CONFIG_REMAKE_ELF) += u-boot.elf
INPUTS-$(CONFIG_EFI_APP) += u-boot-app.efi
INPUTS-$(CONFIG_EFI_STUB) += u-boot-payload.efi
-ifneq ($(CONFIG_HAS_ROM),)
-ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
-INPUTS-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
-endif
-endif
-
-ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy)
-INPUTS-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
-endif
-
# Build a combined spl + u-boot image for sunxi
ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
INPUTS-y += u-boot-sunxi-with-spl.bin
@@ -961,6 +951,10 @@ ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
INPUTS-y += u-boot-rockchip.bin
endif
+INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
+ $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
+ $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin)
+
LDFLAGS_u-boot += $(LDFLAGS_FINAL)
# Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
@@ -1018,7 +1012,14 @@ cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
PHONY += inputs
inputs: $(INPUTS-y)
-all: inputs
+all: .binman_stamp inputs
+ifeq ($(CONFIG_BINMAN),y)
+ $(call if_changed,binman)
+endif
+
+# Timestamp file to make sure that binman always runs
+.binman_stamp: FORCE
+ @touch $@
ifeq ($(CONFIG_DEPRECATED),y)
$(warning "You have deprecated configuration options enabled in your .config! Please check your configuration.")
@@ -1311,7 +1312,7 @@ quiet_cmd_binman = BINMAN $@
cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \
--toolpath $(objtree)/tools \
$(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
- build -u -d u-boot.dtb -O . -m \
+ build -u -d u-boot.dtb -O . -m --allow-missing \
-I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
$(BINMAN_$(@F))
@@ -1588,27 +1589,11 @@ u-boot-br.bin: u-boot FORCE
endif
endif
-# x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
-# reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
-# the middle. This is handled by binman based on an image description in the
-# board's device tree.
-ifneq ($(CONFIG_HAS_ROM),)
-rom: u-boot.rom FORCE
-
-refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE
- $(call if_changed,copy)
-
quiet_cmd_ldr = LD $@
cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
$(filter-out FORCE,$^) -o $@
-rom-deps := u-boot.bin
ifdef CONFIG_X86
-rom-deps += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
- $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
- $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \
- $(if $(CONFIG_HAVE_REFCODE),refcode.bin)
-
OBJCOPYFLAGS_u-boot-x86-start16.bin := -O binary -j .start16
u-boot-x86-start16.bin: u-boot FORCE
$(call if_changed,objcopy)
@@ -1617,24 +1602,7 @@ OBJCOPYFLAGS_u-boot-x86-reset16.bin := -O binary -j .resetvec
u-boot-x86-reset16.bin: u-boot FORCE
$(call if_changed,objcopy)
-else # !CONFIG_X86
-
-ifdef CONFIG_SPL
-rom-deps += spl/u-boot-spl.bin
-
-# We can rely on CONFIG_SPL_FRAMEWORK being set for boards that use binman
-rom-deps += u-boot.img
-endif
-
-ifdef CONFIG_TPL
-rom-deps += tpl/u-boot-tpl.bin
-endif
-
-endif
-
-u-boot.rom: $(rom-deps) FORCE
- $(call if_changed,binman)
-endif
+endif # CONFIG_X86
ifneq ($(CONFIG_ARCH_SUNXI),)
ifeq ($(CONFIG_ARM64),)
@@ -1646,9 +1614,6 @@ u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.itb FORCE
endif
endif
-u-boot-x86-with-spl.bin: spl/u-boot-spl.bin u-boot.bin FORCE
- $(call if_changed,binman)
-
ifneq ($(CONFIG_ARCH_TEGRA),)
# Makes u-boot-dtb-tegra.bin u-boot-tegra.bin u-boot-nodtb-tegra.bin
%-dtb-tegra.bin %-tegra.bin %-nodtb-tegra.bin: spl/%-spl %.bin FORCE
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-07-19 19:56 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman Simon Glass
@ 2020-08-05 14:20 ` André Przywara
2020-08-05 15:05 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: André Przywara @ 2020-08-05 14:20 UTC (permalink / raw)
To: u-boot
On 19/07/2020 20:56, Simon Glass wrote:
Hi,
> On x86 various files that need to be created by binman. It does not make
> sense to enumerate these in the Makefile. They are described in the
> configuration (devicetree) for each board and we can simply run binman
> (always) to generate them.
>
> Update the Makefile to have a separate, final step which runs binman,
> once all input dependencies are present.
>
> This avoid sprinkling the Makefile with arch-specific code.
it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!).
When building current master, the Trusted Firmware binary does not make
it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux
won't get very far without BL31. To me it looks like we combine
u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains
bl31.bin.
I bisected down into the hunks of this patch here, and by reverting just
hunk #3 (the one introducing .binman_stamp) it works again.
My knowledge of the U-Boot build system is somewhat limited, so I don't
immediately see the problem or a fix.
A simple way to verify a build is complete would be:
$ strings u-boot-sunxi-with-spl.bin | grep BL31
If it reports some lines, TF-A is included and it would work correctly.
If it comes back empty, TF-A is missing and we won't boot.
I would be grateful for any insights!
Cheers,
Andre
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Drop rockchip changes which should not be in this patch
>
> Makefile | 63 +++++++++++++-------------------------------------------
> 1 file changed, 14 insertions(+), 49 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 0147d9d49b..b4b5b10813 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -921,16 +921,6 @@ INPUTS-$(CONFIG_REMAKE_ELF) += u-boot.elf
> INPUTS-$(CONFIG_EFI_APP) += u-boot-app.efi
> INPUTS-$(CONFIG_EFI_STUB) += u-boot-payload.efi
>
> -ifneq ($(CONFIG_HAS_ROM),)
> -ifneq ($(BUILD_ROM)$(CONFIG_BUILD_ROM),)
> -INPUTS-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
> -endif
> -endif
> -
> -ifeq ($(CONFIG_SYS_COREBOOT)$(CONFIG_SPL),yy)
> -INPUTS-$(CONFIG_BINMAN) += u-boot-x86-with-spl.bin
> -endif
> -
> # Build a combined spl + u-boot image for sunxi
> ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
> INPUTS-y += u-boot-sunxi-with-spl.bin
> @@ -961,6 +951,10 @@ ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
> INPUTS-y += u-boot-rockchip.bin
> endif
>
> +INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
> + $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
> + $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin)
> +
> LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>
> # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> @@ -1018,7 +1012,14 @@ cmd_cfgcheck = $(srctree)/scripts/check-config.sh $2 \
> PHONY += inputs
> inputs: $(INPUTS-y)
>
> -all: inputs
> +all: .binman_stamp inputs
> +ifeq ($(CONFIG_BINMAN),y)
> + $(call if_changed,binman)
> +endif
> +
> +# Timestamp file to make sure that binman always runs
> +.binman_stamp: FORCE
> + @touch $@
>
> ifeq ($(CONFIG_DEPRECATED),y)
> $(warning "You have deprecated configuration options enabled in your .config! Please check your configuration.")
> @@ -1311,7 +1312,7 @@ quiet_cmd_binman = BINMAN $@
> cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \
> --toolpath $(objtree)/tools \
> $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
> - build -u -d u-boot.dtb -O . -m \
> + build -u -d u-boot.dtb -O . -m --allow-missing \
> -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
> $(BINMAN_$(@F))
>
> @@ -1588,27 +1589,11 @@ u-boot-br.bin: u-boot FORCE
> endif
> endif
>
> -# x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
> -# reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
> -# the middle. This is handled by binman based on an image description in the
> -# board's device tree.
> -ifneq ($(CONFIG_HAS_ROM),)
> -rom: u-boot.rom FORCE
> -
> -refcode.bin: $(srctree)/board/$(BOARDDIR)/refcode.bin FORCE
> - $(call if_changed,copy)
> -
> quiet_cmd_ldr = LD $@
> cmd_ldr = $(LD) $(LDFLAGS_$(@F)) \
> $(filter-out FORCE,$^) -o $@
>
> -rom-deps := u-boot.bin
> ifdef CONFIG_X86
> -rom-deps += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
> - $(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
> - $(if $(CONFIG_TPL_X86_16BIT_INIT),tpl/u-boot-tpl.bin) \
> - $(if $(CONFIG_HAVE_REFCODE),refcode.bin)
> -
> OBJCOPYFLAGS_u-boot-x86-start16.bin := -O binary -j .start16
> u-boot-x86-start16.bin: u-boot FORCE
> $(call if_changed,objcopy)
> @@ -1617,24 +1602,7 @@ OBJCOPYFLAGS_u-boot-x86-reset16.bin := -O binary -j .resetvec
> u-boot-x86-reset16.bin: u-boot FORCE
> $(call if_changed,objcopy)
>
> -else # !CONFIG_X86
> -
> -ifdef CONFIG_SPL
> -rom-deps += spl/u-boot-spl.bin
> -
> -# We can rely on CONFIG_SPL_FRAMEWORK being set for boards that use binman
> -rom-deps += u-boot.img
> -endif
> -
> -ifdef CONFIG_TPL
> -rom-deps += tpl/u-boot-tpl.bin
> -endif
> -
> -endif
> -
> -u-boot.rom: $(rom-deps) FORCE
> - $(call if_changed,binman)
> -endif
> +endif # CONFIG_X86
>
> ifneq ($(CONFIG_ARCH_SUNXI),)
> ifeq ($(CONFIG_ARM64),)
> @@ -1646,9 +1614,6 @@ u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.itb FORCE
> endif
> endif
>
> -u-boot-x86-with-spl.bin: spl/u-boot-spl.bin u-boot.bin FORCE
> - $(call if_changed,binman)
> -
> ifneq ($(CONFIG_ARCH_TEGRA),)
> # Makes u-boot-dtb-tegra.bin u-boot-tegra.bin u-boot-nodtb-tegra.bin
> %-dtb-tegra.bin %-tegra.bin %-nodtb-tegra.bin: spl/%-spl %.bin FORCE
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-08-05 14:20 ` sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman) André Przywara
@ 2020-08-05 15:05 ` Simon Glass
2020-08-05 15:21 ` André Przywara
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-05 15:05 UTC (permalink / raw)
To: u-boot
Hi Andr?,
On Wed, 5 Aug 2020 at 08:20, Andr? Przywara <andre.przywara@arm.com> wrote:
>
> On 19/07/2020 20:56, Simon Glass wrote:
>
> Hi,
>
> > On x86 various files that need to be created by binman. It does not make
> > sense to enumerate these in the Makefile. They are described in the
> > configuration (devicetree) for each board and we can simply run binman
> > (always) to generate them.
> >
> > Update the Makefile to have a separate, final step which runs binman,
> > once all input dependencies are present.
> >
> > This avoid sprinkling the Makefile with arch-specific code.
>
> it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!).
> When building current master, the Trusted Firmware binary does not make
> it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux
> won't get very far without BL31. To me it looks like we combine
> u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains
> bl31.bin.
>
> I bisected down into the hunks of this patch here, and by reverting just
> hunk #3 (the one introducing .binman_stamp) it works again.
> My knowledge of the U-Boot build system is somewhat limited, so I don't
> immediately see the problem or a fix.
>
> A simple way to verify a build is complete would be:
> $ strings u-boot-sunxi-with-spl.bin | grep BL31
> If it reports some lines, TF-A is included and it would work correctly.
> If it comes back empty, TF-A is missing and we won't boot.
>
> I would be grateful for any insights!
Thanks for the info. Which board is this?
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-08-05 15:05 ` Simon Glass
@ 2020-08-05 15:21 ` André Przywara
2020-08-05 17:22 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: André Przywara @ 2020-08-05 15:21 UTC (permalink / raw)
To: u-boot
On 05/08/2020 16:05, Simon Glass wrote:
> Hi Andr?,
>
> On Wed, 5 Aug 2020 at 08:20, Andr? Przywara <andre.przywara@arm.com> wrote:
>>
>> On 19/07/2020 20:56, Simon Glass wrote:
>>
>> Hi,
>>
>>> On x86 various files that need to be created by binman. It does not make
>>> sense to enumerate these in the Makefile. They are described in the
>>> configuration (devicetree) for each board and we can simply run binman
>>> (always) to generate them.
>>>
>>> Update the Makefile to have a separate, final step which runs binman,
>>> once all input dependencies are present.
>>>
>>> This avoid sprinkling the Makefile with arch-specific code.
>>
>> it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!).
>> When building current master, the Trusted Firmware binary does not make
>> it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux
>> won't get very far without BL31. To me it looks like we combine
>> u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains
>> bl31.bin.
>>
>> I bisected down into the hunks of this patch here, and by reverting just
>> hunk #3 (the one introducing .binman_stamp) it works again.
>> My knowledge of the U-Boot build system is somewhat limited, so I don't
>> immediately see the problem or a fix.
>>
>> A simple way to verify a build is complete would be:
>> $ strings u-boot-sunxi-with-spl.bin | grep BL31
>> If it reports some lines, TF-A is included and it would work correctly.
>> If it comes back empty, TF-A is missing and we won't boot.
>>
>> I would be grateful for any insights!
>
> Thanks for the info. Which board is this?
I happened to see this on bananapi_m64_defconfig, but any arm64 sunxi
board should be affected.
Thanks,
Andre
^ permalink raw reply [flat|nested] 94+ messages in thread
* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-08-05 15:21 ` André Przywara
@ 2020-08-05 17:22 ` Simon Glass
0 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-08-05 17:22 UTC (permalink / raw)
To: u-boot
Hi Andr?,
On Wed, 5 Aug 2020 at 09:21, Andr? Przywara <andre.przywara@arm.com> wrote:
>
> On 05/08/2020 16:05, Simon Glass wrote:
> > Hi Andr?,
> >
> > On Wed, 5 Aug 2020 at 08:20, Andr? Przywara <andre.przywara@arm.com> wrote:
> >>
> >> On 19/07/2020 20:56, Simon Glass wrote:
> >>
> >> Hi,
> >>
> >>> On x86 various files that need to be created by binman. It does not make
> >>> sense to enumerate these in the Makefile. They are described in the
> >>> configuration (devicetree) for each board and we can simply run binman
> >>> (always) to generate them.
> >>>
> >>> Update the Makefile to have a separate, final step which runs binman,
> >>> once all input dependencies are present.
> >>>
> >>> This avoid sprinkling the Makefile with arch-specific code.
> >>
> >> it seems that this patch (committed as 42b18df80fdb) breaks sunxi(!).
> >> When building current master, the Trusted Firmware binary does not make
> >> it into the u-boot-sunxi-with-spl.bin file. U-Boot still runs, but Linux
> >> won't get very far without BL31. To me it looks like we combine
> >> u-boot.img with the SPL, instead of u-boot.itb. Only the latter contains
> >> bl31.bin.
> >>
> >> I bisected down into the hunks of this patch here, and by reverting just
> >> hunk #3 (the one introducing .binman_stamp) it works again.
> >> My knowledge of the U-Boot build system is somewhat limited, so I don't
> >> immediately see the problem or a fix.
> >>
> >> A simple way to verify a build is complete would be:
> >> $ strings u-boot-sunxi-with-spl.bin | grep BL31
> >> If it reports some lines, TF-A is included and it would work correctly.
> >> If it comes back empty, TF-A is missing and we won't boot.
> >>
> >> I would be grateful for any insights!
> >
> > Thanks for the info. Which board is this?
>
> I happened to see this on bananapi_m64_defconfig, but any arm64 sunxi
> board should be affected.
OK thanks, will try that. The problem is not obvious to me but I'll
take another look before the end of today.
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (11 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 14/27] sunxi: Makefile: Drop explicit targets built by binman Simon Glass
` (40 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
This Kconfig is not needed anymore since U-Boot will build the ROM if the
required binary blobs exist.
The BUILD_ROM environment variable used to request that the ROM be built.
Now this always happens if the required binary blobs are available. Update
it to mean that U-Boot should fail if the ROM cannot be built. This
behaviour should be compatible with how it used to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Kconfig | 7 +++++--
Makefile | 3 ++-
configs/qemu-x86_64_defconfig | 1 -
configs/qemu-x86_defconfig | 1 -
4 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Kconfig b/Kconfig
index b3b8532d2c..182f5d6f18 100644
--- a/Kconfig
+++ b/Kconfig
@@ -288,8 +288,11 @@ config ROM_NEEDS_BLOBS
depends on HAS_ROM
help
Enable this if building the u-boot.rom target needs binary blobs, and
- so cannot be done normally. In this case, pass BUILD_ROM=1 to make
- to tell U-Boot to build the ROM.
+ so cannot be done normally. In this case, U-Boot will only build the
+ ROM if the required blobs exist. If not, you will see an warning like:
+
+ Image 'main-section' is missing external blobs and is non-functional:
+ intel-descriptor intel-me intel-refcode intel-vga intel-mrc
config BUILD_ROM
bool "Build U-Boot as BIOS replacement"
diff --git a/Makefile b/Makefile
index b4b5b10813..03590de0ef 100644
--- a/Makefile
+++ b/Makefile
@@ -1312,7 +1312,8 @@ quiet_cmd_binman = BINMAN $@
cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \
--toolpath $(objtree)/tools \
$(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
- build -u -d u-boot.dtb -O . -m --allow-missing \
+ build -u -d u-boot.dtb -O . \
+ $(if $(BUILD_ROM),,-m --allow-missing) \
-I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
$(BINMAN_$(@F))
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index dd4ae62a30..4d156bc7fc 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -18,7 +18,6 @@ CONFIG_GENERATE_ACPI_TABLE=y
CONFIG_X86_OFFSET_U_BOOT=0xfff00000
CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BUILD_ROM=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_BOOTSTAGE=y
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index 4309c2352d..f0e8e7d967 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -8,7 +8,6 @@ CONFIG_GENERATE_PIRQ_TABLE=y
CONFIG_GENERATE_MP_TABLE=y
CONFIG_GENERATE_ACPI_TABLE=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BUILD_ROM=y
CONFIG_FIT=y
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 14/27] sunxi: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (12 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 15/27] tegra: " Simon Glass
` (39 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
On sunxi various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 03590de0ef..2c1d508a0b 100644
--- a/Makefile
+++ b/Makefile
@@ -922,7 +922,7 @@ INPUTS-$(CONFIG_EFI_APP) += u-boot-app.efi
INPUTS-$(CONFIG_EFI_STUB) += u-boot-payload.efi
# Build a combined spl + u-boot image for sunxi
-ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_SPL),yy)
+ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_ARM64)$(CONFIG_SPL),yyy)
INPUTS-y += u-boot-sunxi-with-spl.bin
endif
@@ -1606,10 +1606,7 @@ u-boot-x86-reset16.bin: u-boot FORCE
endif # CONFIG_X86
ifneq ($(CONFIG_ARCH_SUNXI),)
-ifeq ($(CONFIG_ARM64),)
-u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.img u-boot.dtb FORCE
- $(call if_changed,binman)
-else
+ifeq ($(CONFIG_ARM64),y)
u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.itb FORCE
$(call if_changed,cat)
endif
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 15/27] tegra: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (13 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 14/27] sunxi: Makefile: Drop explicit targets built by binman Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 16/27] mediatek: " Simon Glass
` (38 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
On tegra various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/Makefile b/Makefile
index 2c1d508a0b..f72e627fbe 100644
--- a/Makefile
+++ b/Makefile
@@ -926,12 +926,6 @@ ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_ARM64)$(CONFIG_SPL),yyy)
INPUTS-y += u-boot-sunxi-with-spl.bin
endif
-# enable combined SPL/u-boot/dtb rules for tegra
-ifeq ($(CONFIG_ARCH_TEGRA)$(CONFIG_SPL),yy)
-INPUTS-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
-INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
-endif
-
INPUTS-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
# Add optional build target if defined in board/cpu/soc headers
@@ -1612,12 +1606,6 @@ u-boot-sunxi-with-spl.bin: spl/sunxi-spl.bin u-boot.itb FORCE
endif
endif
-ifneq ($(CONFIG_ARCH_TEGRA),)
-# Makes u-boot-dtb-tegra.bin u-boot-tegra.bin u-boot-nodtb-tegra.bin
-%-dtb-tegra.bin %-tegra.bin %-nodtb-tegra.bin: spl/%-spl %.bin FORCE
- $(call if_changed,binman)
-endif
-
OBJCOPYFLAGS_u-boot-app.efi := $(OBJCOPYFLAGS_EFI)
u-boot-app.efi: u-boot FORCE
$(call if_changed,zobjcopy)
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 16/27] mediatek: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (14 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 15/27] tegra: " Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later Simon Glass
` (37 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
On mediatek various files that need to be created by binman. It does not
make sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Also update the binman definition so that idbloader.img is only needed
when SPL is actually being used.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Move in the rockchip changes mistakenly in the earlier x86 patch
Makefile | 24 ++++++++++++++++--------
arch/arm/dts/rockchip-u-boot.dtsi | 2 ++
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/Makefile b/Makefile
index f72e627fbe..e4b1c01de1 100644
--- a/Makefile
+++ b/Makefile
@@ -926,7 +926,10 @@ ifeq ($(CONFIG_ARCH_SUNXI)$(CONFIG_ARM64)$(CONFIG_SPL),yyy)
INPUTS-y += u-boot-sunxi-with-spl.bin
endif
+# Generate this input file for binman
+ifeq ($(CONFIG_SPL),)
INPUTS-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
+endif
# Add optional build target if defined in board/cpu/soc headers
ifneq ($(CONFIG_BUILD_TARGET),)
@@ -941,9 +944,20 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
INPUTS-y += u-boot-with-dtb.bin
endif
-ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
+ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
+# On ARM64 this target is produced by binman so we don't need this dep
+ifeq ($(CONFIG_ARM64),y)
+ifeq ($(CONFIG_SPL),y)
+# TODO: Get binman to generate this too
INPUTS-y += u-boot-rockchip.bin
endif
+else
+ifeq ($(CONFIG_SPL),y)
+# Generate these inputs for binman which will create the output files
+INPUTS-y += idbloader.img u-boot.img
+endif
+endif
+endif
INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
@@ -1459,10 +1473,7 @@ idbloader.img: spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
endif
-ifeq ($(CONFIG_ARM64),)
-u-boot-rockchip.bin: idbloader.img u-boot.img FORCE
- $(call if_changed,binman)
-else
+ifeq ($(CONFIG_ARM64),y)
OBJCOPYFLAGS_u-boot-rockchip.bin = -I binary -O binary \
--pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
u-boot-rockchip.bin: idbloader.img u-boot.itb FORCE
@@ -1689,9 +1700,6 @@ u-boot-elf.lds: arch/u-boot-elf.lds prepare FORCE
ifeq ($(CONFIG_SPL),y)
spl/u-boot-spl-mtk.bin: spl/u-boot-spl
-
-u-boot-mtk.bin: u-boot.dtb u-boot.img spl/u-boot-spl-mtk.bin FORCE
- $(call if_changed,binman)
else
MKIMAGEFLAGS_u-boot-mtk.bin = -T mtk_image \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index 0451db735e..eae3ee715d 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -11,6 +11,7 @@
};
};
+#ifdef CONFIG_SPL
&binman {
simple-bin {
filename = "u-boot-rockchip.bin";
@@ -25,3 +26,4 @@
};
};
};
+#endif
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (15 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 16/27] mediatek: " Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage Simon Glass
` (36 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present this is checked before the config has been loaded by the
Makefile, so it doesn't work.
Move the check to later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e4b1c01de1..fced33e777 100644
--- a/Makefile
+++ b/Makefile
@@ -278,7 +278,7 @@ HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
HOSTCC = cc
HOSTCXX = c++
KBUILD_HOSTCFLAGS := -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer \
- $(if $(CONFIG_TOOLS_DEBUG),-g) $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
+ $(HOST_LFS_CFLAGS) $(HOSTCFLAGS)
KBUILD_HOSTCXXFLAGS := -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS)
KBUILD_HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
KBUILD_HOSTLDLIBS := $(HOST_LFS_LIBS) $(HOSTLDLIBS)
@@ -735,6 +735,8 @@ KBUILD_CPPFLAGS += $(KCPPFLAGS)
KBUILD_AFLAGS += $(KAFLAGS)
KBUILD_CFLAGS += $(KCFLAGS)
+KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
+
# Use UBOOTINCLUDE when you must reference the include/ directory.
# Needed to be compatible with the O= option
UBOOTINCLUDE := \
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (16 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 19/27] Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty Simon Glass
` (35 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
Fix this line which is over the limit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index fced33e777..163dc0b8b9 100644
--- a/Makefile
+++ b/Makefile
@@ -999,7 +999,8 @@ cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $< $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
quiet_cmd_mkfitimage = MKIMAGE $@
-cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f $(U_BOOT_ITS) -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@\
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) \
+ -f $(U_BOOT_ITS) -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
quiet_cmd_cat = CAT $@
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 19/27] Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (17 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR Simon Glass
` (34 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present we use the empty string to indicate that there is no FIT
generator, but this doesn't allow an individual board to undefine it.
Create a separate bool instead.
Update the config of the boards which currently have an empty string.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Kconfig | 6 +++++-
Makefile | 2 +-
configs/am335x_evm_defconfig | 1 +
configs/am335x_hs_evm_defconfig | 1 +
configs/am335x_hs_evm_uart_defconfig | 1 +
configs/am43xx_evm_defconfig | 1 +
configs/am43xx_evm_rtconly_defconfig | 1 +
configs/am43xx_evm_usbhost_boot_defconfig | 1 +
configs/am43xx_hs_evm_defconfig | 1 +
configs/am57xx_evm_defconfig | 1 +
configs/am57xx_hs_evm_defconfig | 1 +
configs/am57xx_hs_evm_usb_defconfig | 1 +
configs/am65x_evm_a53_defconfig | 1 +
configs/am65x_evm_r5_defconfig | 1 +
configs/am65x_hs_evm_a53_defconfig | 1 +
configs/am65x_hs_evm_r5_defconfig | 1 +
configs/dh_imx6_defconfig | 1 +
configs/display5_defconfig | 1 +
configs/display5_factory_defconfig | 1 +
configs/dra7xx_evm_defconfig | 1 +
configs/dra7xx_hs_evm_defconfig | 1 +
configs/dra7xx_hs_evm_usb_defconfig | 1 +
configs/imx6qdl_icore_mipi_defconfig | 1 +
configs/imx6qdl_icore_mmc_defconfig | 1 +
configs/imx6qdl_icore_rqs_defconfig | 1 +
configs/j721e_evm_a72_defconfig | 1 +
configs/j721e_evm_r5_defconfig | 1 +
configs/j721e_hs_evm_a72_defconfig | 1 +
configs/j721e_hs_evm_r5_defconfig | 1 +
configs/ls1046ardb_qspi_spl_defconfig | 1 +
configs/mccmon6_nor_defconfig | 1 +
configs/mccmon6_sd_defconfig | 1 +
configs/mx6sabreauto_defconfig | 1 +
configs/mx6sabresd_defconfig | 1 +
configs/pico-imx6_defconfig | 1 +
configs/qemu-x86_64_defconfig | 1 +
configs/sandbox_spl_defconfig | 1 +
configs/socfpga_arria10_defconfig | 1 +
configs/stm32mp15_dhcom_basic_defconfig | 1 +
configs/stm32mp15_dhcor_basic_defconfig | 1 +
configs/wandboard_defconfig | 1 +
configs/xilinx_zynq_virt_defconfig | 1 +
42 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/Kconfig b/Kconfig
index 182f5d6f18..1dc5273c68 100644
--- a/Kconfig
+++ b/Kconfig
@@ -596,9 +596,13 @@ config SPL_FIT_SOURCE
U-Boot FIT image. This could specify further image to load and/or
execute.
+config USE_SPL_FIT_GENERATOR
+ bool "Use a script to generate the .its script"
+ default y if SPL_FIT
+
config SPL_FIT_GENERATOR
string ".its file generator script for U-Boot FIT image"
- depends on SPL_FIT
+ depends on USE_SPL_FIT_GENERATOR
default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && ARCH_ROCKCHIP
default "arch/arm/mach-zynqmp/mkimage_fit_atf.sh" if SPL_LOAD_FIT && ARCH_ZYNQMP
diff --git a/Makefile b/Makefile
index 163dc0b8b9..f1b5be1882 100644
--- a/Makefile
+++ b/Makefile
@@ -1350,7 +1350,7 @@ U_BOOT_ITS := u-boot.its
$(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
$(call if_changed,copy)
else
-ifneq ($(CONFIG_SPL_FIT_GENERATOR),"")
+ifneq ($(CONFIG_USE_SPL_FIT_GENERATOR),)
U_BOOT_ITS := u-boot.its
ifeq ($(CONFIG_SPL_FIT_GENERATOR),"arch/arm/mach-imx/mkimage_fit_atf.sh")
U_BOOT_ITS_DEPS += u-boot-nodtb.bin
diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
index b8333eb4b8..7c34fc5f81 100644
--- a/configs/am335x_evm_defconfig
+++ b/configs/am335x_evm_defconfig
@@ -6,6 +6,7 @@ CONFIG_AM33XX=y
CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run envboot; run distro_bootcmd"
CONFIG_LOGLEVEL=3
diff --git a/configs/am335x_hs_evm_defconfig b/configs/am335x_hs_evm_defconfig
index 4faab7fa5b..c4ebe54cf4 100644
--- a/configs/am335x_hs_evm_defconfig
+++ b/configs/am335x_hs_evm_defconfig
@@ -10,6 +10,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run envboot; run distro_bootcmd"
CONFIG_LOGLEVEL=3
diff --git a/configs/am335x_hs_evm_uart_defconfig b/configs/am335x_hs_evm_uart_defconfig
index fb4e11d1c7..9e8eeefe36 100644
--- a/configs/am335x_hs_evm_uart_defconfig
+++ b/configs/am335x_hs_evm_uart_defconfig
@@ -13,6 +13,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then run update_to_fit; fi; run findfdt; run init_console; run envboot; run distro_bootcmd"
CONFIG_LOGLEVEL=3
diff --git a/configs/am43xx_evm_defconfig b/configs/am43xx_evm_defconfig
index be88f28e9e..e92e9a1825 100644
--- a/configs/am43xx_evm_defconfig
+++ b/configs/am43xx_evm_defconfig
@@ -10,6 +10,7 @@ CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_MISC_INIT_R is not set
diff --git a/configs/am43xx_evm_rtconly_defconfig b/configs/am43xx_evm_rtconly_defconfig
index 8f1e60fd3e..6d32536129 100644
--- a/configs/am43xx_evm_rtconly_defconfig
+++ b/configs/am43xx_evm_rtconly_defconfig
@@ -10,6 +10,7 @@ CONFIG_SPL_RTC_DDR_SUPPORT=y
CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_MISC_INIT_R is not set
diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig
index 7afd328a49..6a9ec32bc7 100644
--- a/configs/am43xx_evm_usbhost_boot_defconfig
+++ b/configs/am43xx_evm_usbhost_boot_defconfig
@@ -9,6 +9,7 @@ CONFIG_AM43XX=y
CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_MISC_INIT_R is not set
diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index fa8d069910..598b14a580 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -18,6 +18,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_SYS_CONSOLE_INFO_QUIET=y
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index dce50dc4be..5afa372e95 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -18,6 +18,7 @@ CONFIG_AHCI=y
CONFIG_DEFAULT_DEVICE_TREE="am572x-idk"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS2,115200 androidboot.console=ttyS2 androidboot.hardware=beagle_x15board"
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 081a48f038..f4aaa429ef 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS2,115200 androidboot.console=ttyS2 androidboot.hardware=beagle_x15board"
diff --git a/configs/am57xx_hs_evm_usb_defconfig b/configs/am57xx_hs_evm_usb_defconfig
index 2ecc990683..b71cf14943 100644
--- a/configs/am57xx_hs_evm_usb_defconfig
+++ b/configs/am57xx_hs_evm_usb_defconfig
@@ -24,6 +24,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS2,115200 androidboot.console=ttyS2 androidboot.hardware=beagle_x15board"
diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 918ff4de0c..88f595b397 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -26,6 +26,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-am654-base-board"
CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
CONFIG_CONSOLE_MUX=y
diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
index 09c8b74aee..5b756d24e8 100644
--- a/configs/am65x_evm_r5_defconfig
+++ b/configs/am65x_evm_r5_defconfig
@@ -24,6 +24,7 @@ CONFIG_SPL_SPI_SUPPORT=y
CONFIG_DEFAULT_DEVICE_TREE="k3-am654-r5-base-board"
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_BOOTCOMMAND=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_STACK_R=y
diff --git a/configs/am65x_hs_evm_a53_defconfig b/configs/am65x_hs_evm_a53_defconfig
index bc3da74509..6786e75f3e 100644
--- a/configs/am65x_hs_evm_a53_defconfig
+++ b/configs/am65x_hs_evm_a53_defconfig
@@ -29,6 +29,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run get_fit_${boot}; run get_overlaystring; run run_fit"
CONFIG_CONSOLE_MUX=y
diff --git a/configs/am65x_hs_evm_r5_defconfig b/configs/am65x_hs_evm_r5_defconfig
index ead4a59c38..38fd5627fd 100644
--- a/configs/am65x_hs_evm_r5_defconfig
+++ b/configs/am65x_hs_evm_r5_defconfig
@@ -26,6 +26,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-am654-r5-base-board"
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_BOOTCOMMAND=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_STACK_R=y
diff --git a/configs/dh_imx6_defconfig b/configs/dh_imx6_defconfig
index 9b957eff4a..9f860e76c3 100644
--- a/configs/dh_imx6_defconfig
+++ b/configs/dh_imx6_defconfig
@@ -25,6 +25,7 @@ CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_F is not set
CONFIG_FIT=y
CONFIG_SPL_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_BOOTDELAY=3
# CONFIG_USE_BOOTCOMMAND is not set
diff --git a/configs/display5_defconfig b/configs/display5_defconfig
index ee5815514b..8577622cbe 100644
--- a/configs/display5_defconfig
+++ b/configs/display5_defconfig
@@ -28,6 +28,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI_SUPPORT=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q"
CONFIG_SUPPORT_RAW_INITRD=y
diff --git a/configs/display5_factory_defconfig b/configs/display5_factory_defconfig
index 9cb9612a95..a235170b9b 100644
--- a/configs/display5_factory_defconfig
+++ b/configs/display5_factory_defconfig
@@ -25,6 +25,7 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
CONFIG_SPL_SPI_SUPPORT=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q"
CONFIG_BOOTDELAY=3
diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 12f08ae6f9..bc142a565d 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -18,6 +18,7 @@ CONFIG_AHCI=y
CONFIG_DEFAULT_DEVICE_TREE="dra7-evm"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index e15f62eded..52593d9c67 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
diff --git a/configs/dra7xx_hs_evm_usb_defconfig b/configs/dra7xx_hs_evm_usb_defconfig
index 4178473ddf..c44a3204f2 100644
--- a/configs/dra7xx_hs_evm_usb_defconfig
+++ b/configs/dra7xx_hs_evm_usb_defconfig
@@ -25,6 +25,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="androidboot.serialno=${serial#} console=ttyS0,115200 androidboot.console=ttyS0 androidboot.hardware=jacinto6evmboard"
diff --git a/configs/imx6qdl_icore_mipi_defconfig b/configs/imx6qdl_icore_mipi_defconfig
index c08a361ee1..6bae7ae331 100644
--- a/configs/imx6qdl_icore_mipi_defconfig
+++ b/configs/imx6qdl_icore_mipi_defconfig
@@ -20,6 +20,7 @@ CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_BOOTDELAY=3
diff --git a/configs/imx6qdl_icore_mmc_defconfig b/configs/imx6qdl_icore_mmc_defconfig
index 66985bde31..5bf3b16721 100644
--- a/configs/imx6qdl_icore_mmc_defconfig
+++ b/configs/imx6qdl_icore_mmc_defconfig
@@ -23,6 +23,7 @@ CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_BOOTDELAY=3
diff --git a/configs/imx6qdl_icore_rqs_defconfig b/configs/imx6qdl_icore_rqs_defconfig
index 6cc50eb264..de455893d4 100644
--- a/configs/imx6qdl_icore_rqs_defconfig
+++ b/configs/imx6qdl_icore_rqs_defconfig
@@ -17,6 +17,7 @@ CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_BOOTDELAY=3
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 09a73e590d..90e1e43563 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -27,6 +27,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-common-proc-board"
CONFIG_DISTRO_DEFAULTS=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index a06fc7c3d2..6ab6040660 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -23,6 +23,7 @@ CONFIG_SPL_SPI_SUPPORT=y
CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-common-proc-board"
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_BOOTCOMMAND=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_BOARD_INIT=y
diff --git a/configs/j721e_hs_evm_a72_defconfig b/configs/j721e_hs_evm_a72_defconfig
index 9b5bc6cf54..5b4ada66c4 100644
--- a/configs/j721e_hs_evm_a72_defconfig
+++ b/configs/j721e_hs_evm_a72_defconfig
@@ -28,6 +28,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_IMAGE_POST_PROCESS=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; run get_fit_${boot}; run get_overlaystring; run run_fit"
CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
diff --git a/configs/j721e_hs_evm_r5_defconfig b/configs/j721e_hs_evm_r5_defconfig
index 1aa899e63c..9ef2dbcae4 100644
--- a/configs/j721e_hs_evm_r5_defconfig
+++ b/configs/j721e_hs_evm_r5_defconfig
@@ -26,6 +26,7 @@ CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-common-proc-board"
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_BOOTCOMMAND=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_STACK_R=y
diff --git a/configs/ls1046ardb_qspi_spl_defconfig b/configs/ls1046ardb_qspi_spl_defconfig
index 3f27ccf7e0..0385bbef9f 100644
--- a/configs/ls1046ardb_qspi_spl_defconfig
+++ b/configs/ls1046ardb_qspi_spl_defconfig
@@ -19,6 +19,7 @@ CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
CONFIG_QSPI_BOOT=y
CONFIG_BOOTDELAY=10
diff --git a/configs/mccmon6_nor_defconfig b/configs/mccmon6_nor_defconfig
index 3139567b80..13dc37a2b0 100644
--- a/configs/mccmon6_nor_defconfig
+++ b/configs/mccmon6_nor_defconfig
@@ -16,6 +16,7 @@ CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/liebherr/mccmon6/mon6_imximage_nor.cfg"
# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_BOARD_LATE_INIT=y
diff --git a/configs/mccmon6_sd_defconfig b/configs/mccmon6_sd_defconfig
index 24a7dd87a0..b26f847e19 100644
--- a/configs/mccmon6_sd_defconfig
+++ b/configs/mccmon6_sd_defconfig
@@ -17,6 +17,7 @@ CONFIG_SPL=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/liebherr/mccmon6/mon6_imximage_sd.cfg"
# CONFIG_USE_BOOTCOMMAND is not set
CONFIG_BOARD_LATE_INIT=y
diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index 5c12754e58..c0358cf430 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -19,6 +19,7 @@ CONFIG_NXP_BOARD_REVISION=y
CONFIG_FIT=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
# CONFIG_CONSOLE_MUX is not set
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index c03e0b54f5..330097b21a 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -18,6 +18,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_FIT=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
# CONFIG_CONSOLE_MUX is not set
CONFIG_SYS_CONSOLE_IS_IN_ENV=y
diff --git a/configs/pico-imx6_defconfig b/configs/pico-imx6_defconfig
index 04c132b474..2f6b4ce099 100644
--- a/configs/pico-imx6_defconfig
+++ b/configs/pico-imx6_defconfig
@@ -18,6 +18,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_BOOTCOMMAND="run default_boot"
CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index 4d156bc7fc..c7a7abcbb5 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -20,6 +20,7 @@ CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_SHOW_BOOT_PROGRESS=y
diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
index b3274a93b4..cd115bf6b2 100644
--- a/configs/sandbox_spl_defconfig
+++ b/configs/sandbox_spl_defconfig
@@ -13,6 +13,7 @@ CONFIG_FIT=y
CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_BOOTSTAGE_FDT=y
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig
index 625b597bbd..8fdd21c0d3 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_BOOTARGS=y
CONFIG_BOOTARGS="console=ttyS0,115200"
# CONFIG_USE_BOOTCOMMAND is not set
diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig
index cd9ba108b3..dc85625a8b 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -16,6 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcom.its"
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig
index 94361f3b10..1e1aa86426 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -16,6 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its"
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTCOMMAND="run bootcmd_stm32mp"
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig
index 8dfd218426..3209aad65e 100644
--- a/configs/wandboard_defconfig
+++ b/configs/wandboard_defconfig
@@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd"
# CONFIG_CONSOLE_MUX is not set
diff --git a/configs/xilinx_zynq_virt_defconfig b/configs/xilinx_zynq_virt_defconfig
index 76cc94ef23..5b08503395 100644
--- a/configs/xilinx_zynq_virt_defconfig
+++ b/configs/xilinx_zynq_virt_defconfig
@@ -15,6 +15,7 @@ CONFIG_FIT_SIGNATURE=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_FIT_PRINT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_USE_PREBOOT=y
CONFIG_SPL_STACK_R=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (18 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 19/27] Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-08-14 13:27 ` Michal Simek
2020-07-19 19:56 ` [PATCH v4 21/27] rockchip: Convert evb-rk3288 over to use binman Simon Glass
` (33 subsequent siblings)
53 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
This option is used to run arch-specific shell scripts which produce .its
files which are used to produce FIT images. We already have binman which
is designed to produce firmware images. It is more powerful and has tests.
So this option should be deprecated and not used. Existing uses should be
migrated.
Mentions of this in code reviews over the last year or so do not seem to
have resulted in action, and things are getting worse.
So let's add a warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Makefile b/Makefile
index f1b5be1882..d73c10a973 100644
--- a/Makefile
+++ b/Makefile
@@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
@echo >&2 "See doc/driver-model/migration.rst for more info."
@echo >&2 "===================================================="
endif
+endif
+ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
+ @echo >&2 "===================== WARNING ======================"
+ @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
+ @echo >&2 "to binman instead, to avoid the proliferation of"
+ @echo >&2 "arch-specific scripts with no tests."
+ @echo >&2 "===================================================="
endif
@# Check that this build does not use CONFIG options that we do not
@# know about unless they are in Kconfig. All the existing CONFIG
@@ -1345,6 +1352,8 @@ endif
# Boards with more complex image requirements can provide an .its source file
# or a generator script
+# NOTE: Please do not use this. We are migrating away from Makefile rules to use
+# binman instead.
ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
U_BOOT_ITS := u-boot.its
$(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-07-19 19:56 ` [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR Simon Glass
@ 2020-08-14 13:27 ` Michal Simek
2020-08-16 3:39 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Michal Simek @ 2020-08-14 13:27 UTC (permalink / raw)
To: u-boot
Hi Simon,
ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>
> This option is used to run arch-specific shell scripts which produce .its
> files which are used to produce FIT images. We already have binman which
> is designed to produce firmware images. It is more powerful and has tests.
>
> So this option should be deprecated and not used. Existing uses should be
> migrated.
>
> Mentions of this in code reviews over the last year or so do not seem to
> have resulted in action, and things are getting worse.
>
> So let's add a warning.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> (no changes since v1)
>
> Makefile | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index f1b5be1882..d73c10a973 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> @echo >&2 "See doc/driver-model/migration.rst for more info."
> @echo >&2 "===================================================="
> endif
> +endif
> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> + @echo >&2 "===================== WARNING ======================"
> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> + @echo >&2 "to binman instead, to avoid the proliferation of"
> + @echo >&2 "arch-specific scripts with no tests."
> + @echo >&2 "===================================================="
> endif
> @# Check that this build does not use CONFIG options that we do not
> @# know about unless they are in Kconfig. All the existing CONFIG
> @@ -1345,6 +1352,8 @@ endif
>
> # Boards with more complex image requirements can provide an .its source file
> # or a generator script
> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> +# binman instead.
> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> U_BOOT_ITS := u-boot.its
> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> --
> 2.28.0.rc0.105.gf9edc3c819-goog
>
I just got to this conversion and I am curious how that transition
should look like.
I found how FIT image is created which is fine but I didn't find any
reference on how to generate images based on CONFIG_OF_LIST.
If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
that I loop over this entry and create multiple DT nodes and the same
amount of configurations to cover it. Is this supported by binman?
If yes, what's the syntax for it?
I tried several configurations and we can use that for generating qspi
images and also images with different configurations to have them
ready
but first I need to be able to handle the case above.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-14 13:27 ` Michal Simek
@ 2020-08-16 3:39 ` Simon Glass
2020-08-17 6:49 ` Michal Simek
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-16 3:39 UTC (permalink / raw)
To: u-boot
Hi Michal,
On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>
> Hi Simon,
>
> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
> >
> > This option is used to run arch-specific shell scripts which produce .its
> > files which are used to produce FIT images. We already have binman which
> > is designed to produce firmware images. It is more powerful and has tests.
> >
> > So this option should be deprecated and not used. Existing uses should be
> > migrated.
> >
> > Mentions of this in code reviews over the last year or so do not seem to
> > have resulted in action, and things are getting worse.
> >
> > So let's add a warning.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> > (no changes since v1)
> >
> > Makefile | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index f1b5be1882..d73c10a973 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> > @echo >&2 "See doc/driver-model/migration.rst for more info."
> > @echo >&2 "===================================================="
> > endif
> > +endif
> > +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> > + @echo >&2 "===================== WARNING ======================"
> > + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> > + @echo >&2 "to binman instead, to avoid the proliferation of"
> > + @echo >&2 "arch-specific scripts with no tests."
> > + @echo >&2 "===================================================="
> > endif
> > @# Check that this build does not use CONFIG options that we do not
> > @# know about unless they are in Kconfig. All the existing CONFIG
> > @@ -1345,6 +1352,8 @@ endif
> >
> > # Boards with more complex image requirements can provide an .its source file
> > # or a generator script
> > +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> > +# binman instead.
> > ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> > U_BOOT_ITS := u-boot.its
> > $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> > --
> > 2.28.0.rc0.105.gf9edc3c819-goog
> >
>
> I just got to this conversion and I am curious how that transition
> should look like.
> I found how FIT image is created which is fine but I didn't find any
> reference on how to generate images based on CONFIG_OF_LIST.
> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
> that I loop over this entry and create multiple DT nodes and the same
> amount of configurations to cover it. Is this supported by binman?
> If yes, what's the syntax for it?
The easiest way is probably to create a new entry type, like zynq-fit.
Then you can generate the DT using the sequence writer functions. See
_ReadSubNodes() in fit.py for an example.
You can perhaps have a template subnode and use that in a for loop to
generate the nodes.
>
> I tried several configurations and we can use that for generating qspi
> images and also images with different configurations to have them
> ready
> but first I need to be able to handle the case above.
I was thinking of converting sunxi which has the same need, but it
sounds like you are on the case. Let me know if you need help.
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-16 3:39 ` Simon Glass
@ 2020-08-17 6:49 ` Michal Simek
2020-08-22 15:08 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Michal Simek @ 2020-08-17 6:49 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 16. 08. 20 5:39, Simon Glass wrote:
> Hi Michal,
>
> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>>
>> Hi Simon,
>>
>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>>>
>>> This option is used to run arch-specific shell scripts which produce .its
>>> files which are used to produce FIT images. We already have binman which
>>> is designed to produce firmware images. It is more powerful and has tests.
>>>
>>> So this option should be deprecated and not used. Existing uses should be
>>> migrated.
>>>
>>> Mentions of this in code reviews over the last year or so do not seem to
>>> have resulted in action, and things are getting worse.
>>>
>>> So let's add a warning.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>> (no changes since v1)
>>>
>>> Makefile | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index f1b5be1882..d73c10a973 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
>>> @echo >&2 "===================================================="
>>> endif
>>> +endif
>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
>>> + @echo >&2 "===================== WARNING ======================"
>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
>>> + @echo >&2 "arch-specific scripts with no tests."
>>> + @echo >&2 "===================================================="
>>> endif
>>> @# Check that this build does not use CONFIG options that we do not
>>> @# know about unless they are in Kconfig. All the existing CONFIG
>>> @@ -1345,6 +1352,8 @@ endif
>>>
>>> # Boards with more complex image requirements can provide an .its source file
>>> # or a generator script
>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
>>> +# binman instead.
>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>>> U_BOOT_ITS := u-boot.its
>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>>> --
>>> 2.28.0.rc0.105.gf9edc3c819-goog
>>>
>>
>> I just got to this conversion and I am curious how that transition
>> should look like.
>> I found how FIT image is created which is fine but I didn't find any
>> reference on how to generate images based on CONFIG_OF_LIST.
>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
>> that I loop over this entry and create multiple DT nodes and the same
>> amount of configurations to cover it. Is this supported by binman?
>> If yes, what's the syntax for it?
>
> The easiest way is probably to create a new entry type, like zynq-fit.
> Then you can generate the DT using the sequence writer functions. See
> _ReadSubNodes() in fit.py for an example.
>
> You can perhaps have a template subnode and use that in a for loop to
> generate the nodes.
>
>>
>> I tried several configurations and we can use that for generating qspi
>> images and also images with different configurations to have them
>> ready
>> but first I need to be able to handle the case above.
>
> I was thinking of converting sunxi which has the same need, but it
> sounds like you are on the case. Let me know if you need help.
Nope. I just saw that message and started to play with it to find out
what needs to be done and how this fits to bigger picture. If this
doesn't work directly then the work needs to be planned which will take
time especially when this utility is new for us and we could have issues
with writing code in python. Would be good if you can do the first shot
because you know this utility and I am more than happy to test it, try
and adopt if needed for our case.
Sunxi is very similar case as is zynqmp. Difference is they hardcode
default configuration to config_1. ZynqMP is setting up default based on
default DT configured at that time.
In connection to binman I see that there would be a need to generate
images with ATF and without ATF in configuration node and with different
default configuration. There could be also a need to add additional
loadable entry such as bitstreams.
Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
type because as was state in commit message u-boot.itb generation is
very similar for all these boards that's why name for this new entry
should be generic.
Thanks,
Michal
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-17 6:49 ` Michal Simek
@ 2020-08-22 15:08 ` Simon Glass
2020-08-24 14:11 ` Michal Simek
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-22 15:08 UTC (permalink / raw)
To: u-boot
Hi Michal,
On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
>
> Hi Simon,
>
> On 16. 08. 20 5:39, Simon Glass wrote:
> > Hi Michal,
> >
> > On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
> >>
> >> Hi Simon,
> >>
> >> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
> >>>
> >>> This option is used to run arch-specific shell scripts which produce .its
> >>> files which are used to produce FIT images. We already have binman which
> >>> is designed to produce firmware images. It is more powerful and has tests.
> >>>
> >>> So this option should be deprecated and not used. Existing uses should be
> >>> migrated.
> >>>
> >>> Mentions of this in code reviews over the last year or so do not seem to
> >>> have resulted in action, and things are getting worse.
> >>>
> >>> So let's add a warning.
> >>>
> >>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>> ---
> >>>
> >>> (no changes since v1)
> >>>
> >>> Makefile | 9 +++++++++
> >>> 1 file changed, 9 insertions(+)
> >>>
> >>> diff --git a/Makefile b/Makefile
> >>> index f1b5be1882..d73c10a973 100644
> >>> --- a/Makefile
> >>> +++ b/Makefile
> >>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> >>> @echo >&2 "See doc/driver-model/migration.rst for more info."
> >>> @echo >&2 "===================================================="
> >>> endif
> >>> +endif
> >>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> >>> + @echo >&2 "===================== WARNING ======================"
> >>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> >>> + @echo >&2 "to binman instead, to avoid the proliferation of"
> >>> + @echo >&2 "arch-specific scripts with no tests."
> >>> + @echo >&2 "===================================================="
> >>> endif
> >>> @# Check that this build does not use CONFIG options that we do not
> >>> @# know about unless they are in Kconfig. All the existing CONFIG
> >>> @@ -1345,6 +1352,8 @@ endif
> >>>
> >>> # Boards with more complex image requirements can provide an .its source file
> >>> # or a generator script
> >>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> >>> +# binman instead.
> >>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> >>> U_BOOT_ITS := u-boot.its
> >>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> >>> --
> >>> 2.28.0.rc0.105.gf9edc3c819-goog
> >>>
> >>
> >> I just got to this conversion and I am curious how that transition
> >> should look like.
> >> I found how FIT image is created which is fine but I didn't find any
> >> reference on how to generate images based on CONFIG_OF_LIST.
> >> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
> >> that I loop over this entry and create multiple DT nodes and the same
> >> amount of configurations to cover it. Is this supported by binman?
> >> If yes, what's the syntax for it?
> >
> > The easiest way is probably to create a new entry type, like zynq-fit.
> > Then you can generate the DT using the sequence writer functions. See
> > _ReadSubNodes() in fit.py for an example.
> >
> > You can perhaps have a template subnode and use that in a for loop to
> > generate the nodes.
> >
> >>
> >> I tried several configurations and we can use that for generating qspi
> >> images and also images with different configurations to have them
> >> ready
> >> but first I need to be able to handle the case above.
> >
> > I was thinking of converting sunxi which has the same need, but it
> > sounds like you are on the case. Let me know if you need help.
>
> Nope. I just saw that message and started to play with it to find out
> what needs to be done and how this fits to bigger picture. If this
> doesn't work directly then the work needs to be planned which will take
> time especially when this utility is new for us and we could have issues
> with writing code in python. Would be good if you can do the first shot
> because you know this utility and I am more than happy to test it, try
> and adopt if needed for our case.
>
> Sunxi is very similar case as is zynqmp. Difference is they hardcode
> default configuration to config_1. ZynqMP is setting up default based on
> default DT configured at that time.
>
> In connection to binman I see that there would be a need to generate
> images with ATF and without ATF in configuration node and with different
> default configuration. There could be also a need to add additional
> loadable entry such as bitstreams.
>
> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
> type because as was state in commit message u-boot.itb generation is
> very similar for all these boards that's why name for this new entry
> should be generic.
>
I sent an initial series to add this to binman. I've since found a few
problems so will send a v2 at some point. You can try it out at
u-boot-dm/binman-working
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-22 15:08 ` Simon Glass
@ 2020-08-24 14:11 ` Michal Simek
2020-08-25 15:04 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Michal Simek @ 2020-08-24 14:11 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 22. 08. 20 17:08, Simon Glass wrote:
> Hi Michal,
>
> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> Hi Simon,
>>
>> On 16. 08. 20 5:39, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>>>>>
>>>>> This option is used to run arch-specific shell scripts which produce .its
>>>>> files which are used to produce FIT images. We already have binman which
>>>>> is designed to produce firmware images. It is more powerful and has tests.
>>>>>
>>>>> So this option should be deprecated and not used. Existing uses should be
>>>>> migrated.
>>>>>
>>>>> Mentions of this in code reviews over the last year or so do not seem to
>>>>> have resulted in action, and things are getting worse.
>>>>>
>>>>> So let's add a warning.
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>> ---
>>>>>
>>>>> (no changes since v1)
>>>>>
>>>>> Makefile | 9 +++++++++
>>>>> 1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/Makefile b/Makefile
>>>>> index f1b5be1882..d73c10a973 100644
>>>>> --- a/Makefile
>>>>> +++ b/Makefile
>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
>>>>> @echo >&2 "===================================================="
>>>>> endif
>>>>> +endif
>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
>>>>> + @echo >&2 "===================== WARNING ======================"
>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
>>>>> + @echo >&2 "arch-specific scripts with no tests."
>>>>> + @echo >&2 "===================================================="
>>>>> endif
>>>>> @# Check that this build does not use CONFIG options that we do not
>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
>>>>> @@ -1345,6 +1352,8 @@ endif
>>>>>
>>>>> # Boards with more complex image requirements can provide an .its source file
>>>>> # or a generator script
>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
>>>>> +# binman instead.
>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>>>>> U_BOOT_ITS := u-boot.its
>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>>>>> --
>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
>>>>>
>>>>
>>>> I just got to this conversion and I am curious how that transition
>>>> should look like.
>>>> I found how FIT image is created which is fine but I didn't find any
>>>> reference on how to generate images based on CONFIG_OF_LIST.
>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
>>>> that I loop over this entry and create multiple DT nodes and the same
>>>> amount of configurations to cover it. Is this supported by binman?
>>>> If yes, what's the syntax for it?
>>>
>>> The easiest way is probably to create a new entry type, like zynq-fit.
>>> Then you can generate the DT using the sequence writer functions. See
>>> _ReadSubNodes() in fit.py for an example.
>>>
>>> You can perhaps have a template subnode and use that in a for loop to
>>> generate the nodes.
>>>
>>>>
>>>> I tried several configurations and we can use that for generating qspi
>>>> images and also images with different configurations to have them
>>>> ready
>>>> but first I need to be able to handle the case above.
>>>
>>> I was thinking of converting sunxi which has the same need, but it
>>> sounds like you are on the case. Let me know if you need help.
>>
>> Nope. I just saw that message and started to play with it to find out
>> what needs to be done and how this fits to bigger picture. If this
>> doesn't work directly then the work needs to be planned which will take
>> time especially when this utility is new for us and we could have issues
>> with writing code in python. Would be good if you can do the first shot
>> because you know this utility and I am more than happy to test it, try
>> and adopt if needed for our case.
>>
>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
>> default configuration to config_1. ZynqMP is setting up default based on
>> default DT configured at that time.
>>
>> In connection to binman I see that there would be a need to generate
>> images with ATF and without ATF in configuration node and with different
>> default configuration. There could be also a need to add additional
>> loadable entry such as bitstreams.
>>
>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
>> type because as was state in commit message u-boot.itb generation is
>> very similar for all these boards that's why name for this new entry
>> should be generic.
>>
>
> I sent an initial series to add this to binman. I've since found a few
> problems so will send a v2 at some point. You can try it out at
> u-boot-dm/binman-working
I looked at this branch and add my changes on the top.
The first thing what I see is that I miss fit,fdt-list = "of-list"; in
sunxi dt file. I had to add it to work for me.
With BINMAN_FDT enabled I am getting error that there is no valid
"binman node" in DT. I didn't study that code yet but that's the point
of keeping this DT node out there?
This is my binman configuration.
diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
b/arch/arm/dts/zynqmp-u-boot.dtsi
new file mode 100644
index 000000000000..b3364d3e2df8
--- /dev/null
+++ b/arch/arm/dts/zynqmp-u-boot.dtsi
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Xilinx, Inc.
+ */
+
+#include <config.h>
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+&binman {
+ u-boot-itb {
+ filename = "u-boot.itb";
+ fit {
+ fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
+ description = "FIT image with ATF support";
+ fit,fdt-list = "of-list";
+ #address-cells = <1>;
+
+ images {
+ uboot {
+ description = "U-Boot (64-bit)";
+ type = "firmware";
+ os = "u-boot";
+ arch = "arm64";
+ compression = "none";
+ load = <CONFIG_SYS_TEXT_BASE>;
+ entry = <CONFIG_SYS_TEXT_BASE>;
+
+ u-boot-nodtb {
+ };
+ };
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ os = "arm-trusted-firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0xfffea000>; /* FIXME */
+ entry = <0xfffea000>;
+
+ blob-ext {
+ filename = "bl31.bin";
+ };
+ };
+ @fdt-SEQ {
+ description = "NAME";
+ type = "flat_dt";
+ arch = "arm64";
+ compression = "none";
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ @config-SEQ {
+ description = "NAME";
+ firmware = "atf";
+ loadables = "uboot";
+ fdt = "fdt-SEQ";
+ };
+ };
+ };
+ fdtmap{};
+ };
+
+};
Anyway compare to current script default option is hardcoded to
config-1. Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
setting up default option based on selected default DT (I can fix this
by implementing board_fit_config_name_match() but IIRC it is looping
over all configurations and slowing down boot).
I will play with it a little bit more to get more experience with it
Thanks,
Michal
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-24 14:11 ` Michal Simek
@ 2020-08-25 15:04 ` Simon Glass
2020-08-25 15:12 ` Michal Simek
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-25 15:04 UTC (permalink / raw)
To: u-boot
Hi Michal,
On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>
> Hi Simon,
>
> On 22. 08. 20 17:08, Simon Glass wrote:
> > Hi Michal,
> >
> > On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 16. 08. 20 5:39, Simon Glass wrote:
> >>> Hi Michal,
> >>>
> >>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
> >>>>
> >>>> Hi Simon,
> >>>>
> >>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
> >>>>>
> >>>>> This option is used to run arch-specific shell scripts which produce .its
> >>>>> files which are used to produce FIT images. We already have binman which
> >>>>> is designed to produce firmware images. It is more powerful and has tests.
> >>>>>
> >>>>> So this option should be deprecated and not used. Existing uses should be
> >>>>> migrated.
> >>>>>
> >>>>> Mentions of this in code reviews over the last year or so do not seem to
> >>>>> have resulted in action, and things are getting worse.
> >>>>>
> >>>>> So let's add a warning.
> >>>>>
> >>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>>>> ---
> >>>>>
> >>>>> (no changes since v1)
> >>>>>
> >>>>> Makefile | 9 +++++++++
> >>>>> 1 file changed, 9 insertions(+)
> >>>>>
> >>>>> diff --git a/Makefile b/Makefile
> >>>>> index f1b5be1882..d73c10a973 100644
> >>>>> --- a/Makefile
> >>>>> +++ b/Makefile
> >>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> >>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
> >>>>> @echo >&2 "===================================================="
> >>>>> endif
> >>>>> +endif
> >>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> >>>>> + @echo >&2 "===================== WARNING ======================"
> >>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> >>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
> >>>>> + @echo >&2 "arch-specific scripts with no tests."
> >>>>> + @echo >&2 "===================================================="
> >>>>> endif
> >>>>> @# Check that this build does not use CONFIG options that we do not
> >>>>> @# know about unless they are in Kconfig. All the existing CONFIG
> >>>>> @@ -1345,6 +1352,8 @@ endif
> >>>>>
> >>>>> # Boards with more complex image requirements can provide an .its source file
> >>>>> # or a generator script
> >>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> >>>>> +# binman instead.
> >>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> >>>>> U_BOOT_ITS := u-boot.its
> >>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> >>>>> --
> >>>>> 2.28.0.rc0.105.gf9edc3c819-goog
> >>>>>
> >>>>
> >>>> I just got to this conversion and I am curious how that transition
> >>>> should look like.
> >>>> I found how FIT image is created which is fine but I didn't find any
> >>>> reference on how to generate images based on CONFIG_OF_LIST.
> >>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
> >>>> that I loop over this entry and create multiple DT nodes and the same
> >>>> amount of configurations to cover it. Is this supported by binman?
> >>>> If yes, what's the syntax for it?
> >>>
> >>> The easiest way is probably to create a new entry type, like zynq-fit.
> >>> Then you can generate the DT using the sequence writer functions. See
> >>> _ReadSubNodes() in fit.py for an example.
> >>>
> >>> You can perhaps have a template subnode and use that in a for loop to
> >>> generate the nodes.
> >>>
> >>>>
> >>>> I tried several configurations and we can use that for generating qspi
> >>>> images and also images with different configurations to have them
> >>>> ready
> >>>> but first I need to be able to handle the case above.
> >>>
> >>> I was thinking of converting sunxi which has the same need, but it
> >>> sounds like you are on the case. Let me know if you need help.
> >>
> >> Nope. I just saw that message and started to play with it to find out
> >> what needs to be done and how this fits to bigger picture. If this
> >> doesn't work directly then the work needs to be planned which will take
> >> time especially when this utility is new for us and we could have issues
> >> with writing code in python. Would be good if you can do the first shot
> >> because you know this utility and I am more than happy to test it, try
> >> and adopt if needed for our case.
> >>
> >> Sunxi is very similar case as is zynqmp. Difference is they hardcode
> >> default configuration to config_1. ZynqMP is setting up default based on
> >> default DT configured at that time.
> >>
> >> In connection to binman I see that there would be a need to generate
> >> images with ATF and without ATF in configuration node and with different
> >> default configuration. There could be also a need to add additional
> >> loadable entry such as bitstreams.
> >>
> >> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
> >> type because as was state in commit message u-boot.itb generation is
> >> very similar for all these boards that's why name for this new entry
> >> should be generic.
> >>
> >
> > I sent an initial series to add this to binman. I've since found a few
> > problems so will send a v2 at some point. You can try it out at
> > u-boot-dm/binman-working
>
> I looked at this branch and add my changes on the top.
>
> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
> sunxi dt file. I had to add it to work for me.
Ah yes, I decided to add this at the last minute so it is not relying
on a convention.
>
> With BINMAN_FDT enabled I am getting error that there is no valid
> "binman node" in DT. I didn't study that code yet but that's the point
> of keeping this DT node out there?
Is this in SPL? Perhaps something is filtering out the node.
>
> This is my binman configuration.
>
> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
> b/arch/arm/dts/zynqmp-u-boot.dtsi
> new file mode 100644
> index 000000000000..b3364d3e2df8
> --- /dev/null
> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
> @@ -0,0 +1,72 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Xilinx, Inc.
> + */
> +
> +#include <config.h>
> +
> +/ {
> + binman: binman {
> + multiple-images;
> + };
> +};
> +
> +&binman {
> + u-boot-itb {
> + filename = "u-boot.itb";
> + fit {
> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
> + description = "FIT image with ATF support";
> + fit,fdt-list = "of-list";
> + #address-cells = <1>;
> +
> + images {
> + uboot {
> + description = "U-Boot (64-bit)";
> + type = "firmware";
> + os = "u-boot";
> + arch = "arm64";
> + compression = "none";
> + load = <CONFIG_SYS_TEXT_BASE>;
> + entry = <CONFIG_SYS_TEXT_BASE>;
> +
> + u-boot-nodtb {
> + };
> + };
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + os = "arm-trusted-firmware";
> + arch = "arm64";
> + compression = "none";
> + load = <0xfffea000>; /* FIXME */
> + entry = <0xfffea000>;
> +
> + blob-ext {
> + filename = "bl31.bin";
> + };
> + };
> + @fdt-SEQ {
> + description = "NAME";
> + type = "flat_dt";
> + arch = "arm64";
> + compression = "none";
> + };
> + };
> +
> + configurations {
> + default = "config-1";
> + @config-SEQ {
> + description = "NAME";
> + firmware = "atf";
> + loadables = "uboot";
> + fdt = "fdt-SEQ";
> + };
> + };
> + };
> + fdtmap{};
> + };
> +
> +};
>
> Anyway compare to current script default option is hardcoded to
> config-1.
> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
> setting up default option based on selected default DT (I can fix this
> by implementing board_fit_config_name_match() but IIRC it is looping
> over all configurations and slowing down boot).
Is this using an environment variable to select the default? Would it
be OK to put this in the DT for each individual board?
>
> I will play with it a little bit more to get more experience with it
OK good luck!
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-25 15:04 ` Simon Glass
@ 2020-08-25 15:12 ` Michal Simek
2020-08-25 16:57 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Michal Simek @ 2020-08-25 15:12 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 25. 08. 20 17:04, Simon Glass wrote:
> Hi Michal,
>
> On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> Hi Simon,
>>
>> On 22. 08. 20 17:08, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On 16. 08. 20 5:39, Simon Glass wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>>>>>>>
>>>>>>> This option is used to run arch-specific shell scripts which produce .its
>>>>>>> files which are used to produce FIT images. We already have binman which
>>>>>>> is designed to produce firmware images. It is more powerful and has tests.
>>>>>>>
>>>>>>> So this option should be deprecated and not used. Existing uses should be
>>>>>>> migrated.
>>>>>>>
>>>>>>> Mentions of this in code reviews over the last year or so do not seem to
>>>>>>> have resulted in action, and things are getting worse.
>>>>>>>
>>>>>>> So let's add a warning.
>>>>>>>
>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>> ---
>>>>>>>
>>>>>>> (no changes since v1)
>>>>>>>
>>>>>>> Makefile | 9 +++++++++
>>>>>>> 1 file changed, 9 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Makefile b/Makefile
>>>>>>> index f1b5be1882..d73c10a973 100644
>>>>>>> --- a/Makefile
>>>>>>> +++ b/Makefile
>>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
>>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
>>>>>>> @echo >&2 "===================================================="
>>>>>>> endif
>>>>>>> +endif
>>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
>>>>>>> + @echo >&2 "===================== WARNING ======================"
>>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
>>>>>>> + @echo >&2 "arch-specific scripts with no tests."
>>>>>>> + @echo >&2 "===================================================="
>>>>>>> endif
>>>>>>> @# Check that this build does not use CONFIG options that we do not
>>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
>>>>>>> @@ -1345,6 +1352,8 @@ endif
>>>>>>>
>>>>>>> # Boards with more complex image requirements can provide an .its source file
>>>>>>> # or a generator script
>>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
>>>>>>> +# binman instead.
>>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>>>>>>> U_BOOT_ITS := u-boot.its
>>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>>>>>>> --
>>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
>>>>>>>
>>>>>>
>>>>>> I just got to this conversion and I am curious how that transition
>>>>>> should look like.
>>>>>> I found how FIT image is created which is fine but I didn't find any
>>>>>> reference on how to generate images based on CONFIG_OF_LIST.
>>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
>>>>>> that I loop over this entry and create multiple DT nodes and the same
>>>>>> amount of configurations to cover it. Is this supported by binman?
>>>>>> If yes, what's the syntax for it?
>>>>>
>>>>> The easiest way is probably to create a new entry type, like zynq-fit.
>>>>> Then you can generate the DT using the sequence writer functions. See
>>>>> _ReadSubNodes() in fit.py for an example.
>>>>>
>>>>> You can perhaps have a template subnode and use that in a for loop to
>>>>> generate the nodes.
>>>>>
>>>>>>
>>>>>> I tried several configurations and we can use that for generating qspi
>>>>>> images and also images with different configurations to have them
>>>>>> ready
>>>>>> but first I need to be able to handle the case above.
>>>>>
>>>>> I was thinking of converting sunxi which has the same need, but it
>>>>> sounds like you are on the case. Let me know if you need help.
>>>>
>>>> Nope. I just saw that message and started to play with it to find out
>>>> what needs to be done and how this fits to bigger picture. If this
>>>> doesn't work directly then the work needs to be planned which will take
>>>> time especially when this utility is new for us and we could have issues
>>>> with writing code in python. Would be good if you can do the first shot
>>>> because you know this utility and I am more than happy to test it, try
>>>> and adopt if needed for our case.
>>>>
>>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
>>>> default configuration to config_1. ZynqMP is setting up default based on
>>>> default DT configured at that time.
>>>>
>>>> In connection to binman I see that there would be a need to generate
>>>> images with ATF and without ATF in configuration node and with different
>>>> default configuration. There could be also a need to add additional
>>>> loadable entry such as bitstreams.
>>>>
>>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
>>>> type because as was state in commit message u-boot.itb generation is
>>>> very similar for all these boards that's why name for this new entry
>>>> should be generic.
>>>>
>>>
>>> I sent an initial series to add this to binman. I've since found a few
>>> problems so will send a v2 at some point. You can try it out at
>>> u-boot-dm/binman-working
>>
>> I looked at this branch and add my changes on the top.
>>
>> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
>> sunxi dt file. I had to add it to work for me.
>
> Ah yes, I decided to add this at the last minute so it is not relying
> on a convention.
>
>>
>> With BINMAN_FDT enabled I am getting error that there is no valid
>> "binman node" in DT. I didn't study that code yet but that's the point
>> of keeping this DT node out there?
>
> Is this in SPL? Perhaps something is filtering out the node.
Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
>
>>
>> This is my binman configuration.
>>
>> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
>> b/arch/arm/dts/zynqmp-u-boot.dtsi
>> new file mode 100644
>> index 000000000000..b3364d3e2df8
>> --- /dev/null
>> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
>> @@ -0,0 +1,72 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 Xilinx, Inc.
>> + */
>> +
>> +#include <config.h>
>> +
>> +/ {
>> + binman: binman {
>> + multiple-images;
>> + };
>> +};
>> +
>> +&binman {
>> + u-boot-itb {
>> + filename = "u-boot.itb";
>> + fit {
>> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
>> + description = "FIT image with ATF support";
>> + fit,fdt-list = "of-list";
>> + #address-cells = <1>;
>> +
>> + images {
>> + uboot {
>> + description = "U-Boot (64-bit)";
>> + type = "firmware";
>> + os = "u-boot";
>> + arch = "arm64";
>> + compression = "none";
>> + load = <CONFIG_SYS_TEXT_BASE>;
>> + entry = <CONFIG_SYS_TEXT_BASE>;
>> +
>> + u-boot-nodtb {
>> + };
>> + };
>> + atf {
>> + description = "ARM Trusted Firmware";
>> + type = "firmware";
>> + os = "arm-trusted-firmware";
>> + arch = "arm64";
>> + compression = "none";
>> + load = <0xfffea000>; /* FIXME */
>> + entry = <0xfffea000>;
>> +
>> + blob-ext {
>> + filename = "bl31.bin";
>> + };
>> + };
>> + @fdt-SEQ {
>> + description = "NAME";
>> + type = "flat_dt";
>> + arch = "arm64";
>> + compression = "none";
>> + };
>> + };
>> +
>> + configurations {
>> + default = "config-1";
>> + @config-SEQ {
>> + description = "NAME";
>> + firmware = "atf";
>> + loadables = "uboot";
>> + fdt = "fdt-SEQ";
>> + };
>> + };
>> + };
>> + fdtmap{};
>> + };
>> +
>> +};
>>
>> Anyway compare to current script default option is hardcoded to
>> config-1.
>
>
>> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
>> setting up default option based on selected default DT (I can fix this
>> by implementing board_fit_config_name_match() but IIRC it is looping
>> over all configurations and slowing down boot).
>
> Is this using an environment variable to select the default? Would it
> be OK to put this in the DT for each individual board?
I have added this code to board_fit_config_name_match() to select proper
configuration from SPL
+ if (!strcmp(name, DEVICE_TREE))
+ return 0;
DEVICE_TREE is setup in generated/dt.h.
I am not quite sure what you mean by put this to each individual board.
Like a property for SPL which DT should be select?
Thanks,
Michal
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-25 15:12 ` Michal Simek
@ 2020-08-25 16:57 ` Simon Glass
2020-08-26 14:11 ` Michal Simek
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-25 16:57 UTC (permalink / raw)
To: u-boot
Hi Michal,
On Tue, 25 Aug 2020 at 09:13, Michal Simek <michal.simek@xilinx.com> wrote:
>
> Hi Simon,
>
> On 25. 08. 20 17:04, Simon Glass wrote:
> > Hi Michal,
> >
> > On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 22. 08. 20 17:08, Simon Glass wrote:
> >>> Hi Michal,
> >>>
> >>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>
> >>>> Hi Simon,
> >>>>
> >>>> On 16. 08. 20 5:39, Simon Glass wrote:
> >>>>> Hi Michal,
> >>>>>
> >>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
> >>>>>>
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
> >>>>>>>
> >>>>>>> This option is used to run arch-specific shell scripts which produce .its
> >>>>>>> files which are used to produce FIT images. We already have binman which
> >>>>>>> is designed to produce firmware images. It is more powerful and has tests.
> >>>>>>>
> >>>>>>> So this option should be deprecated and not used. Existing uses should be
> >>>>>>> migrated.
> >>>>>>>
> >>>>>>> Mentions of this in code reviews over the last year or so do not seem to
> >>>>>>> have resulted in action, and things are getting worse.
> >>>>>>>
> >>>>>>> So let's add a warning.
> >>>>>>>
> >>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>>>>>> ---
> >>>>>>>
> >>>>>>> (no changes since v1)
> >>>>>>>
> >>>>>>> Makefile | 9 +++++++++
> >>>>>>> 1 file changed, 9 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/Makefile b/Makefile
> >>>>>>> index f1b5be1882..d73c10a973 100644
> >>>>>>> --- a/Makefile
> >>>>>>> +++ b/Makefile
> >>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> >>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
> >>>>>>> @echo >&2 "===================================================="
> >>>>>>> endif
> >>>>>>> +endif
> >>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> >>>>>>> + @echo >&2 "===================== WARNING ======================"
> >>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> >>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
> >>>>>>> + @echo >&2 "arch-specific scripts with no tests."
> >>>>>>> + @echo >&2 "===================================================="
> >>>>>>> endif
> >>>>>>> @# Check that this build does not use CONFIG options that we do not
> >>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
> >>>>>>> @@ -1345,6 +1352,8 @@ endif
> >>>>>>>
> >>>>>>> # Boards with more complex image requirements can provide an .its source file
> >>>>>>> # or a generator script
> >>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> >>>>>>> +# binman instead.
> >>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> >>>>>>> U_BOOT_ITS := u-boot.its
> >>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> >>>>>>> --
> >>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
> >>>>>>>
> >>>>>>
> >>>>>> I just got to this conversion and I am curious how that transition
> >>>>>> should look like.
> >>>>>> I found how FIT image is created which is fine but I didn't find any
> >>>>>> reference on how to generate images based on CONFIG_OF_LIST.
> >>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
> >>>>>> that I loop over this entry and create multiple DT nodes and the same
> >>>>>> amount of configurations to cover it. Is this supported by binman?
> >>>>>> If yes, what's the syntax for it?
> >>>>>
> >>>>> The easiest way is probably to create a new entry type, like zynq-fit.
> >>>>> Then you can generate the DT using the sequence writer functions. See
> >>>>> _ReadSubNodes() in fit.py for an example.
> >>>>>
> >>>>> You can perhaps have a template subnode and use that in a for loop to
> >>>>> generate the nodes.
> >>>>>
> >>>>>>
> >>>>>> I tried several configurations and we can use that for generating qspi
> >>>>>> images and also images with different configurations to have them
> >>>>>> ready
> >>>>>> but first I need to be able to handle the case above.
> >>>>>
> >>>>> I was thinking of converting sunxi which has the same need, but it
> >>>>> sounds like you are on the case. Let me know if you need help.
> >>>>
> >>>> Nope. I just saw that message and started to play with it to find out
> >>>> what needs to be done and how this fits to bigger picture. If this
> >>>> doesn't work directly then the work needs to be planned which will take
> >>>> time especially when this utility is new for us and we could have issues
> >>>> with writing code in python. Would be good if you can do the first shot
> >>>> because you know this utility and I am more than happy to test it, try
> >>>> and adopt if needed for our case.
> >>>>
> >>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
> >>>> default configuration to config_1. ZynqMP is setting up default based on
> >>>> default DT configured at that time.
> >>>>
> >>>> In connection to binman I see that there would be a need to generate
> >>>> images with ATF and without ATF in configuration node and with different
> >>>> default configuration. There could be also a need to add additional
> >>>> loadable entry such as bitstreams.
> >>>>
> >>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
> >>>> type because as was state in commit message u-boot.itb generation is
> >>>> very similar for all these boards that's why name for this new entry
> >>>> should be generic.
> >>>>
> >>>
> >>> I sent an initial series to add this to binman. I've since found a few
> >>> problems so will send a v2 at some point. You can try it out at
> >>> u-boot-dm/binman-working
> >>
> >> I looked at this branch and add my changes on the top.
> >>
> >> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
> >> sunxi dt file. I had to add it to work for me.
> >
> > Ah yes, I decided to add this at the last minute so it is not relying
> > on a convention.
> >
> >>
> >> With BINMAN_FDT enabled I am getting error that there is no valid
> >> "binman node" in DT. I didn't study that code yet but that's the point
> >> of keeping this DT node out there?
> >
> > Is this in SPL? Perhaps something is filtering out the node.
>
> Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
That needs debugging. I can't understand how the /binman node can be
missing in U-Boot. The C library is very simple and doesn't handle
finding nodes in multiple images...perhaps that is the problem?
>
> >
> >>
> >> This is my binman configuration.
> >>
> >> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
> >> b/arch/arm/dts/zynqmp-u-boot.dtsi
> >> new file mode 100644
> >> index 000000000000..b3364d3e2df8
> >> --- /dev/null
> >> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
> >> @@ -0,0 +1,72 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2020 Xilinx, Inc.
> >> + */
> >> +
> >> +#include <config.h>
> >> +
> >> +/ {
> >> + binman: binman {
> >> + multiple-images;
> >> + };
> >> +};
> >> +
> >> +&binman {
> >> + u-boot-itb {
> >> + filename = "u-boot.itb";
> >> + fit {
> >> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
> >> + description = "FIT image with ATF support";
> >> + fit,fdt-list = "of-list";
> >> + #address-cells = <1>;
> >> +
> >> + images {
> >> + uboot {
> >> + description = "U-Boot (64-bit)";
> >> + type = "firmware";
> >> + os = "u-boot";
> >> + arch = "arm64";
> >> + compression = "none";
> >> + load = <CONFIG_SYS_TEXT_BASE>;
> >> + entry = <CONFIG_SYS_TEXT_BASE>;
> >> +
> >> + u-boot-nodtb {
> >> + };
> >> + };
> >> + atf {
> >> + description = "ARM Trusted Firmware";
> >> + type = "firmware";
> >> + os = "arm-trusted-firmware";
> >> + arch = "arm64";
> >> + compression = "none";
> >> + load = <0xfffea000>; /* FIXME */
> >> + entry = <0xfffea000>;
> >> +
> >> + blob-ext {
> >> + filename = "bl31.bin";
> >> + };
> >> + };
> >> + @fdt-SEQ {
> >> + description = "NAME";
> >> + type = "flat_dt";
> >> + arch = "arm64";
> >> + compression = "none";
> >> + };
> >> + };
> >> +
> >> + configurations {
> >> + default = "config-1";
> >> + @config-SEQ {
> >> + description = "NAME";
> >> + firmware = "atf";
> >> + loadables = "uboot";
> >> + fdt = "fdt-SEQ";
> >> + };
> >> + };
> >> + };
> >> + fdtmap{};
> >> + };
> >> +
> >> +};
> >>
> >> Anyway compare to current script default option is hardcoded to
> >> config-1.
> >
> >
> >> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
> >> setting up default option based on selected default DT (I can fix this
> >> by implementing board_fit_config_name_match() but IIRC it is looping
> >> over all configurations and slowing down boot).
> >
> > Is this using an environment variable to select the default? Would it
> > be OK to put this in the DT for each individual board?
>
> I have added this code to board_fit_config_name_match() to select proper
> configuration from SPL
>
> + if (!strcmp(name, DEVICE_TREE))
> + return 0;
>
> DEVICE_TREE is setup in generated/dt.h.
>
> I am not quite sure what you mean by put this to each individual board.
> Like a property for SPL which DT should be select?
OK I see. In that case I think we need another entry argument to pass
${DEVICE_TREE} to the fit entry, and pass it in to binman from the
Makefile with another -a parameter.
>
> Thanks,
> Michal
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-25 16:57 ` Simon Glass
@ 2020-08-26 14:11 ` Michal Simek
2020-08-30 20:37 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Michal Simek @ 2020-08-26 14:11 UTC (permalink / raw)
To: u-boot
Hi,
On 25. 08. 20 18:57, Simon Glass wrote:
> Hi Michal,
>
> On Tue, 25 Aug 2020 at 09:13, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> Hi Simon,
>>
>> On 25. 08. 20 17:04, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On 22. 08. 20 17:08, Simon Glass wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 16. 08. 20 5:39, Simon Glass wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>>>>>>>>
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>>>>>>>>>
>>>>>>>>> This option is used to run arch-specific shell scripts which produce .its
>>>>>>>>> files which are used to produce FIT images. We already have binman which
>>>>>>>>> is designed to produce firmware images. It is more powerful and has tests.
>>>>>>>>>
>>>>>>>>> So this option should be deprecated and not used. Existing uses should be
>>>>>>>>> migrated.
>>>>>>>>>
>>>>>>>>> Mentions of this in code reviews over the last year or so do not seem to
>>>>>>>>> have resulted in action, and things are getting worse.
>>>>>>>>>
>>>>>>>>> So let's add a warning.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> (no changes since v1)
>>>>>>>>>
>>>>>>>>> Makefile | 9 +++++++++
>>>>>>>>> 1 file changed, 9 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/Makefile b/Makefile
>>>>>>>>> index f1b5be1882..d73c10a973 100644
>>>>>>>>> --- a/Makefile
>>>>>>>>> +++ b/Makefile
>>>>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
>>>>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
>>>>>>>>> @echo >&2 "===================================================="
>>>>>>>>> endif
>>>>>>>>> +endif
>>>>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
>>>>>>>>> + @echo >&2 "===================== WARNING ======================"
>>>>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>>>>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
>>>>>>>>> + @echo >&2 "arch-specific scripts with no tests."
>>>>>>>>> + @echo >&2 "===================================================="
>>>>>>>>> endif
>>>>>>>>> @# Check that this build does not use CONFIG options that we do not
>>>>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
>>>>>>>>> @@ -1345,6 +1352,8 @@ endif
>>>>>>>>>
>>>>>>>>> # Boards with more complex image requirements can provide an .its source file
>>>>>>>>> # or a generator script
>>>>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
>>>>>>>>> +# binman instead.
>>>>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>>>>>>>>> U_BOOT_ITS := u-boot.its
>>>>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>>>>>>>>> --
>>>>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
>>>>>>>>>
>>>>>>>>
>>>>>>>> I just got to this conversion and I am curious how that transition
>>>>>>>> should look like.
>>>>>>>> I found how FIT image is created which is fine but I didn't find any
>>>>>>>> reference on how to generate images based on CONFIG_OF_LIST.
>>>>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
>>>>>>>> that I loop over this entry and create multiple DT nodes and the same
>>>>>>>> amount of configurations to cover it. Is this supported by binman?
>>>>>>>> If yes, what's the syntax for it?
>>>>>>>
>>>>>>> The easiest way is probably to create a new entry type, like zynq-fit.
>>>>>>> Then you can generate the DT using the sequence writer functions. See
>>>>>>> _ReadSubNodes() in fit.py for an example.
>>>>>>>
>>>>>>> You can perhaps have a template subnode and use that in a for loop to
>>>>>>> generate the nodes.
>>>>>>>
>>>>>>>>
>>>>>>>> I tried several configurations and we can use that for generating qspi
>>>>>>>> images and also images with different configurations to have them
>>>>>>>> ready
>>>>>>>> but first I need to be able to handle the case above.
>>>>>>>
>>>>>>> I was thinking of converting sunxi which has the same need, but it
>>>>>>> sounds like you are on the case. Let me know if you need help.
>>>>>>
>>>>>> Nope. I just saw that message and started to play with it to find out
>>>>>> what needs to be done and how this fits to bigger picture. If this
>>>>>> doesn't work directly then the work needs to be planned which will take
>>>>>> time especially when this utility is new for us and we could have issues
>>>>>> with writing code in python. Would be good if you can do the first shot
>>>>>> because you know this utility and I am more than happy to test it, try
>>>>>> and adopt if needed for our case.
>>>>>>
>>>>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
>>>>>> default configuration to config_1. ZynqMP is setting up default based on
>>>>>> default DT configured at that time.
>>>>>>
>>>>>> In connection to binman I see that there would be a need to generate
>>>>>> images with ATF and without ATF in configuration node and with different
>>>>>> default configuration. There could be also a need to add additional
>>>>>> loadable entry such as bitstreams.
>>>>>>
>>>>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
>>>>>> type because as was state in commit message u-boot.itb generation is
>>>>>> very similar for all these boards that's why name for this new entry
>>>>>> should be generic.
>>>>>>
>>>>>
>>>>> I sent an initial series to add this to binman. I've since found a few
>>>>> problems so will send a v2 at some point. You can try it out at
>>>>> u-boot-dm/binman-working
>>>>
>>>> I looked at this branch and add my changes on the top.
>>>>
>>>> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
>>>> sunxi dt file. I had to add it to work for me.
>>>
>>> Ah yes, I decided to add this at the last minute so it is not relying
>>> on a convention.
>>>
>>>>
>>>> With BINMAN_FDT enabled I am getting error that there is no valid
>>>> "binman node" in DT. I didn't study that code yet but that's the point
>>>> of keeping this DT node out there?
>>>
>>> Is this in SPL? Perhaps something is filtering out the node.
>>
>> Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
>
> That needs debugging. I can't understand how the /binman node can be
> missing in U-Boot. The C library is very simple and doesn't handle
> finding nodes in multiple images...perhaps that is the problem?
I found the reason for this behavior. On our platforms we are checking
specific address where DTB can be placed. And because I have played with
it also with previous image. It was pick up automatically.
But still missing why BINMAN_FDT should be enabled by default on
platforms which don't call any binman functions. I see that you are
calling that functions from x86 platforms to try to map and find out
some image offsets/positions and it looks like that you are loading them.
I can imagine that this could be use for example for better space
utilization that my boot.bin with SPL can be followed immediately by
u-boot.itb in qspi. But for supporting this I expect spl_spi.c needs to
be aligned. And adding support in a generic way there needs to be an
agreement on node name which should be loaded.
>>
>>>
>>>>
>>>> This is my binman configuration.
>>>>
>>>> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
>>>> b/arch/arm/dts/zynqmp-u-boot.dtsi
>>>> new file mode 100644
>>>> index 000000000000..b3364d3e2df8
>>>> --- /dev/null
>>>> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
>>>> @@ -0,0 +1,72 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Copyright (C) 2020 Xilinx, Inc.
>>>> + */
>>>> +
>>>> +#include <config.h>
>>>> +
>>>> +/ {
>>>> + binman: binman {
>>>> + multiple-images;
>>>> + };
>>>> +};
>>>> +
>>>> +&binman {
>>>> + u-boot-itb {
>>>> + filename = "u-boot.itb";
>>>> + fit {
>>>> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
>>>> + description = "FIT image with ATF support";
>>>> + fit,fdt-list = "of-list";
>>>> + #address-cells = <1>;
>>>> +
>>>> + images {
>>>> + uboot {
>>>> + description = "U-Boot (64-bit)";
>>>> + type = "firmware";
>>>> + os = "u-boot";
>>>> + arch = "arm64";
>>>> + compression = "none";
>>>> + load = <CONFIG_SYS_TEXT_BASE>;
>>>> + entry = <CONFIG_SYS_TEXT_BASE>;
>>>> +
>>>> + u-boot-nodtb {
>>>> + };
>>>> + };
>>>> + atf {
>>>> + description = "ARM Trusted Firmware";
>>>> + type = "firmware";
>>>> + os = "arm-trusted-firmware";
>>>> + arch = "arm64";
>>>> + compression = "none";
>>>> + load = <0xfffea000>; /* FIXME */
>>>> + entry = <0xfffea000>;
>>>> +
>>>> + blob-ext {
>>>> + filename = "bl31.bin";
>>>> + };
>>>> + };
>>>> + @fdt-SEQ {
>>>> + description = "NAME";
>>>> + type = "flat_dt";
>>>> + arch = "arm64";
>>>> + compression = "none";
>>>> + };
>>>> + };
>>>> +
>>>> + configurations {
>>>> + default = "config-1";
>>>> + @config-SEQ {
>>>> + description = "NAME";
>>>> + firmware = "atf";
>>>> + loadables = "uboot";
>>>> + fdt = "fdt-SEQ";
>>>> + };
>>>> + };
>>>> + };
>>>> + fdtmap{};
>>>> + };
>>>> +
>>>> +};
>>>>
>>>> Anyway compare to current script default option is hardcoded to
>>>> config-1.
>>>
>>>
>>>> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
>>>> setting up default option based on selected default DT (I can fix this
>>>> by implementing board_fit_config_name_match() but IIRC it is looping
>>>> over all configurations and slowing down boot).
>>>
>>> Is this using an environment variable to select the default? Would it
>>> be OK to put this in the DT for each individual board?
>>
>> I have added this code to board_fit_config_name_match() to select proper
>> configuration from SPL
>>
>> + if (!strcmp(name, DEVICE_TREE))
>> + return 0;
>>
>> DEVICE_TREE is setup in generated/dt.h.
>>
>> I am not quite sure what you mean by put this to each individual board.
>> Like a property for SPL which DT should be select?
>
> OK I see. In that case I think we need another entry argument to pass
> ${DEVICE_TREE} to the fit entry, and pass it in to binman from the
> Makefile with another -a parameter.
Can you please include this option?
Also what's the easiest way to compose multiple images though binman and
share images among others configurations?
I will generate u-boot.itb through binman and then I want to use this
file for composing qspi image. Should I just point to u-boot.itb as blob
with filename?
Layout for qspi is quite simply spl/boot.bin which is generated as
./tools/mkimage -T zynqmpimage -R ./"" -n
"/home/monstr/data/disk/u-boot-bins/zynqmp/pmu.bin" -d
spl/u-boot-spl-align.bin spl/boot.bin >/dev/null && cat /dev/null
And then u-boot.itb placed at CONFIG_SYS_SPI_KERNEL_OFFS offset.
Thanks,
Michal
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-26 14:11 ` Michal Simek
@ 2020-08-30 20:37 ` Simon Glass
2020-09-01 15:15 ` Michal Simek
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-30 20:37 UTC (permalink / raw)
To: u-boot
Hi Michal,
On Wed, 26 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>
> Hi,
>
> On 25. 08. 20 18:57, Simon Glass wrote:
> > Hi Michal,
> >
> > On Tue, 25 Aug 2020 at 09:13, Michal Simek <michal.simek@xilinx.com> wrote:
> >>
> >> Hi Simon,
> >>
> >> On 25. 08. 20 17:04, Simon Glass wrote:
> >>> Hi Michal,
> >>>
> >>> On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>
> >>>> Hi Simon,
> >>>>
> >>>> On 22. 08. 20 17:08, Simon Glass wrote:
> >>>>> Hi Michal,
> >>>>>
> >>>>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>>>
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>> On 16. 08. 20 5:39, Simon Glass wrote:
> >>>>>>> Hi Michal,
> >>>>>>>
> >>>>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
> >>>>>>>>
> >>>>>>>> Hi Simon,
> >>>>>>>>
> >>>>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
> >>>>>>>>>
> >>>>>>>>> This option is used to run arch-specific shell scripts which produce .its
> >>>>>>>>> files which are used to produce FIT images. We already have binman which
> >>>>>>>>> is designed to produce firmware images. It is more powerful and has tests.
> >>>>>>>>>
> >>>>>>>>> So this option should be deprecated and not used. Existing uses should be
> >>>>>>>>> migrated.
> >>>>>>>>>
> >>>>>>>>> Mentions of this in code reviews over the last year or so do not seem to
> >>>>>>>>> have resulted in action, and things are getting worse.
> >>>>>>>>>
> >>>>>>>>> So let's add a warning.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>>>>>>>> ---
> >>>>>>>>>
> >>>>>>>>> (no changes since v1)
> >>>>>>>>>
> >>>>>>>>> Makefile | 9 +++++++++
> >>>>>>>>> 1 file changed, 9 insertions(+)
> >>>>>>>>>
> >>>>>>>>> diff --git a/Makefile b/Makefile
> >>>>>>>>> index f1b5be1882..d73c10a973 100644
> >>>>>>>>> --- a/Makefile
> >>>>>>>>> +++ b/Makefile
> >>>>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> >>>>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
> >>>>>>>>> @echo >&2 "===================================================="
> >>>>>>>>> endif
> >>>>>>>>> +endif
> >>>>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> >>>>>>>>> + @echo >&2 "===================== WARNING ======================"
> >>>>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> >>>>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
> >>>>>>>>> + @echo >&2 "arch-specific scripts with no tests."
> >>>>>>>>> + @echo >&2 "===================================================="
> >>>>>>>>> endif
> >>>>>>>>> @# Check that this build does not use CONFIG options that we do not
> >>>>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
> >>>>>>>>> @@ -1345,6 +1352,8 @@ endif
> >>>>>>>>>
> >>>>>>>>> # Boards with more complex image requirements can provide an .its source file
> >>>>>>>>> # or a generator script
> >>>>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> >>>>>>>>> +# binman instead.
> >>>>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> >>>>>>>>> U_BOOT_ITS := u-boot.its
> >>>>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> >>>>>>>>> --
> >>>>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I just got to this conversion and I am curious how that transition
> >>>>>>>> should look like.
> >>>>>>>> I found how FIT image is created which is fine but I didn't find any
> >>>>>>>> reference on how to generate images based on CONFIG_OF_LIST.
> >>>>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
> >>>>>>>> that I loop over this entry and create multiple DT nodes and the same
> >>>>>>>> amount of configurations to cover it. Is this supported by binman?
> >>>>>>>> If yes, what's the syntax for it?
> >>>>>>>
> >>>>>>> The easiest way is probably to create a new entry type, like zynq-fit.
> >>>>>>> Then you can generate the DT using the sequence writer functions. See
> >>>>>>> _ReadSubNodes() in fit.py for an example.
> >>>>>>>
> >>>>>>> You can perhaps have a template subnode and use that in a for loop to
> >>>>>>> generate the nodes.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> I tried several configurations and we can use that for generating qspi
> >>>>>>>> images and also images with different configurations to have them
> >>>>>>>> ready
> >>>>>>>> but first I need to be able to handle the case above.
> >>>>>>>
> >>>>>>> I was thinking of converting sunxi which has the same need, but it
> >>>>>>> sounds like you are on the case. Let me know if you need help.
> >>>>>>
> >>>>>> Nope. I just saw that message and started to play with it to find out
> >>>>>> what needs to be done and how this fits to bigger picture. If this
> >>>>>> doesn't work directly then the work needs to be planned which will take
> >>>>>> time especially when this utility is new for us and we could have issues
> >>>>>> with writing code in python. Would be good if you can do the first shot
> >>>>>> because you know this utility and I am more than happy to test it, try
> >>>>>> and adopt if needed for our case.
> >>>>>>
> >>>>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
> >>>>>> default configuration to config_1. ZynqMP is setting up default based on
> >>>>>> default DT configured at that time.
> >>>>>>
> >>>>>> In connection to binman I see that there would be a need to generate
> >>>>>> images with ATF and without ATF in configuration node and with different
> >>>>>> default configuration. There could be also a need to add additional
> >>>>>> loadable entry such as bitstreams.
> >>>>>>
> >>>>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
> >>>>>> type because as was state in commit message u-boot.itb generation is
> >>>>>> very similar for all these boards that's why name for this new entry
> >>>>>> should be generic.
> >>>>>>
> >>>>>
> >>>>> I sent an initial series to add this to binman. I've since found a few
> >>>>> problems so will send a v2 at some point. You can try it out at
> >>>>> u-boot-dm/binman-working
> >>>>
> >>>> I looked at this branch and add my changes on the top.
> >>>>
> >>>> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
> >>>> sunxi dt file. I had to add it to work for me.
> >>>
> >>> Ah yes, I decided to add this at the last minute so it is not relying
> >>> on a convention.
> >>>
> >>>>
> >>>> With BINMAN_FDT enabled I am getting error that there is no valid
> >>>> "binman node" in DT. I didn't study that code yet but that's the point
> >>>> of keeping this DT node out there?
> >>>
> >>> Is this in SPL? Perhaps something is filtering out the node.
> >>
> >> Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
> >
> > That needs debugging. I can't understand how the /binman node can be
> > missing in U-Boot. The C library is very simple and doesn't handle
> > finding nodes in multiple images...perhaps that is the problem?
>
> I found the reason for this behavior. On our platforms we are checking
> specific address where DTB can be placed. And because I have played with
> it also with previous image. It was pick up automatically.
>
> But still missing why BINMAN_FDT should be enabled by default on
> platforms which don't call any binman functions. I see that you are
> calling that functions from x86 platforms to try to map and find out
> some image offsets/positions and it looks like that you are loading them.
> I can imagine that this could be use for example for better space
> utilization that my boot.bin with SPL can be followed immediately by
> u-boot.itb in qspi. But for supporting this I expect spl_spi.c needs to
> be aligned. And adding support in a generic way there needs to be an
> agreement on node name which should be loaded.
If you don't need CONFIG_BINMAN_FDT then it is fine to disable it. You
could do that by updating the default condition there, or selecting a
different value for your arch.
>
>
> >>
> >>>
> >>>>
> >>>> This is my binman configuration.
> >>>>
> >>>> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
> >>>> b/arch/arm/dts/zynqmp-u-boot.dtsi
> >>>> new file mode 100644
> >>>> index 000000000000..b3364d3e2df8
> >>>> --- /dev/null
> >>>> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
> >>>> @@ -0,0 +1,72 @@
> >>>> +// SPDX-License-Identifier: GPL-2.0
> >>>> +/*
> >>>> + * Copyright (C) 2020 Xilinx, Inc.
> >>>> + */
> >>>> +
> >>>> +#include <config.h>
> >>>> +
> >>>> +/ {
> >>>> + binman: binman {
> >>>> + multiple-images;
> >>>> + };
> >>>> +};
> >>>> +
> >>>> +&binman {
> >>>> + u-boot-itb {
> >>>> + filename = "u-boot.itb";
> >>>> + fit {
> >>>> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
> >>>> + description = "FIT image with ATF support";
> >>>> + fit,fdt-list = "of-list";
> >>>> + #address-cells = <1>;
> >>>> +
> >>>> + images {
> >>>> + uboot {
> >>>> + description = "U-Boot (64-bit)";
> >>>> + type = "firmware";
> >>>> + os = "u-boot";
> >>>> + arch = "arm64";
> >>>> + compression = "none";
> >>>> + load = <CONFIG_SYS_TEXT_BASE>;
> >>>> + entry = <CONFIG_SYS_TEXT_BASE>;
> >>>> +
> >>>> + u-boot-nodtb {
> >>>> + };
> >>>> + };
> >>>> + atf {
> >>>> + description = "ARM Trusted Firmware";
> >>>> + type = "firmware";
> >>>> + os = "arm-trusted-firmware";
> >>>> + arch = "arm64";
> >>>> + compression = "none";
> >>>> + load = <0xfffea000>; /* FIXME */
> >>>> + entry = <0xfffea000>;
> >>>> +
> >>>> + blob-ext {
> >>>> + filename = "bl31.bin";
> >>>> + };
> >>>> + };
> >>>> + @fdt-SEQ {
> >>>> + description = "NAME";
> >>>> + type = "flat_dt";
> >>>> + arch = "arm64";
> >>>> + compression = "none";
> >>>> + };
> >>>> + };
> >>>> +
> >>>> + configurations {
> >>>> + default = "config-1";
> >>>> + @config-SEQ {
> >>>> + description = "NAME";
> >>>> + firmware = "atf";
> >>>> + loadables = "uboot";
> >>>> + fdt = "fdt-SEQ";
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> + fdtmap{};
> >>>> + };
> >>>> +
> >>>> +};
> >>>>
> >>>> Anyway compare to current script default option is hardcoded to
> >>>> config-1.
> >>>
> >>>
> >>>> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
> >>>> setting up default option based on selected default DT (I can fix this
> >>>> by implementing board_fit_config_name_match() but IIRC it is looping
> >>>> over all configurations and slowing down boot).
> >>>
> >>> Is this using an environment variable to select the default? Would it
> >>> be OK to put this in the DT for each individual board?
> >>
> >> I have added this code to board_fit_config_name_match() to select proper
> >> configuration from SPL
> >>
> >> + if (!strcmp(name, DEVICE_TREE))
> >> + return 0;
> >>
> >> DEVICE_TREE is setup in generated/dt.h.
> >>
> >> I am not quite sure what you mean by put this to each individual board.
> >> Like a property for SPL which DT should be select?
> >
> > OK I see. In that case I think we need another entry argument to pass
> > ${DEVICE_TREE} to the fit entry, and pass it in to binman from the
> > Makefile with another -a parameter.
>
> Can you please include this option?
OK I'll add something in the v2 series.
>
> Also what's the easiest way to compose multiple images though binman and
> share images among others configurations?
>
> I will generate u-boot.itb through binman and then I want to use this
> file for composing qspi image. Should I just point to u-boot.itb as blob
> with filename?
At present binman doesn't support including one image in another,
although since generation of images is ordered, yes it should be
possible to do it that way.
> Layout for qspi is quite simply spl/boot.bin which is generated as
> ./tools/mkimage -T zynqmpimage -R ./"" -n
> "/home/monstr/data/disk/u-boot-bins/zynqmp/pmu.bin" -d
> spl/u-boot-spl-align.bin spl/boot.bin >/dev/null && cat /dev/null
OK you should be able to use the mkimage entry-type for that.
>
> And then u-boot.itb placed at CONFIG_SYS_SPI_KERNEL_OFFS offset.
OK, you can access CONFIG options in the .dtsi
Can you please point me to the docs for zynqmp in the U-Boot tree? I
see stuff about zynq inthe tree but it is quite old. I think there
needs to be a link from doc/board/xilinx
Also is there a low-cost zynqmp board about? I'm thinking about adding
it to my lab.
Finally, these boards seem to use CONFIG_OF_EMBED which is not
allowed. Can you fix that sometime?
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-08-30 20:37 ` Simon Glass
@ 2020-09-01 15:15 ` Michal Simek
2020-09-01 15:26 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Michal Simek @ 2020-09-01 15:15 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 30. 08. 20 22:37, Simon Glass wrote:
> Hi Michal,
>
> On Wed, 26 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> Hi,
>>
>> On 25. 08. 20 18:57, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Tue, 25 Aug 2020 at 09:13, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>
>>>> Hi Simon,
>>>>
>>>> On 25. 08. 20 17:04, Simon Glass wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 22. 08. 20 17:08, Simon Glass wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>>>
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On 16. 08. 20 5:39, Simon Glass wrote:
>>>>>>>>> Hi Michal,
>>>>>>>>>
>>>>>>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>>>>>>>>>>>
>>>>>>>>>>> This option is used to run arch-specific shell scripts which produce .its
>>>>>>>>>>> files which are used to produce FIT images. We already have binman which
>>>>>>>>>>> is designed to produce firmware images. It is more powerful and has tests.
>>>>>>>>>>>
>>>>>>>>>>> So this option should be deprecated and not used. Existing uses should be
>>>>>>>>>>> migrated.
>>>>>>>>>>>
>>>>>>>>>>> Mentions of this in code reviews over the last year or so do not seem to
>>>>>>>>>>> have resulted in action, and things are getting worse.
>>>>>>>>>>>
>>>>>>>>>>> So let's add a warning.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> (no changes since v1)
>>>>>>>>>>>
>>>>>>>>>>> Makefile | 9 +++++++++
>>>>>>>>>>> 1 file changed, 9 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/Makefile b/Makefile
>>>>>>>>>>> index f1b5be1882..d73c10a973 100644
>>>>>>>>>>> --- a/Makefile
>>>>>>>>>>> +++ b/Makefile
>>>>>>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
>>>>>>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
>>>>>>>>>>> @echo >&2 "===================================================="
>>>>>>>>>>> endif
>>>>>>>>>>> +endif
>>>>>>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
>>>>>>>>>>> + @echo >&2 "===================== WARNING ======================"
>>>>>>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>>>>>>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
>>>>>>>>>>> + @echo >&2 "arch-specific scripts with no tests."
>>>>>>>>>>> + @echo >&2 "===================================================="
>>>>>>>>>>> endif
>>>>>>>>>>> @# Check that this build does not use CONFIG options that we do not
>>>>>>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
>>>>>>>>>>> @@ -1345,6 +1352,8 @@ endif
>>>>>>>>>>>
>>>>>>>>>>> # Boards with more complex image requirements can provide an .its source file
>>>>>>>>>>> # or a generator script
>>>>>>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
>>>>>>>>>>> +# binman instead.
>>>>>>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>>>>>>>>>>> U_BOOT_ITS := u-boot.its
>>>>>>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>>>>>>>>>>> --
>>>>>>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I just got to this conversion and I am curious how that transition
>>>>>>>>>> should look like.
>>>>>>>>>> I found how FIT image is created which is fine but I didn't find any
>>>>>>>>>> reference on how to generate images based on CONFIG_OF_LIST.
>>>>>>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
>>>>>>>>>> that I loop over this entry and create multiple DT nodes and the same
>>>>>>>>>> amount of configurations to cover it. Is this supported by binman?
>>>>>>>>>> If yes, what's the syntax for it?
>>>>>>>>>
>>>>>>>>> The easiest way is probably to create a new entry type, like zynq-fit.
>>>>>>>>> Then you can generate the DT using the sequence writer functions. See
>>>>>>>>> _ReadSubNodes() in fit.py for an example.
>>>>>>>>>
>>>>>>>>> You can perhaps have a template subnode and use that in a for loop to
>>>>>>>>> generate the nodes.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I tried several configurations and we can use that for generating qspi
>>>>>>>>>> images and also images with different configurations to have them
>>>>>>>>>> ready
>>>>>>>>>> but first I need to be able to handle the case above.
>>>>>>>>>
>>>>>>>>> I was thinking of converting sunxi which has the same need, but it
>>>>>>>>> sounds like you are on the case. Let me know if you need help.
>>>>>>>>
>>>>>>>> Nope. I just saw that message and started to play with it to find out
>>>>>>>> what needs to be done and how this fits to bigger picture. If this
>>>>>>>> doesn't work directly then the work needs to be planned which will take
>>>>>>>> time especially when this utility is new for us and we could have issues
>>>>>>>> with writing code in python. Would be good if you can do the first shot
>>>>>>>> because you know this utility and I am more than happy to test it, try
>>>>>>>> and adopt if needed for our case.
>>>>>>>>
>>>>>>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
>>>>>>>> default configuration to config_1. ZynqMP is setting up default based on
>>>>>>>> default DT configured at that time.
>>>>>>>>
>>>>>>>> In connection to binman I see that there would be a need to generate
>>>>>>>> images with ATF and without ATF in configuration node and with different
>>>>>>>> default configuration. There could be also a need to add additional
>>>>>>>> loadable entry such as bitstreams.
>>>>>>>>
>>>>>>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
>>>>>>>> type because as was state in commit message u-boot.itb generation is
>>>>>>>> very similar for all these boards that's why name for this new entry
>>>>>>>> should be generic.
>>>>>>>>
>>>>>>>
>>>>>>> I sent an initial series to add this to binman. I've since found a few
>>>>>>> problems so will send a v2 at some point. You can try it out at
>>>>>>> u-boot-dm/binman-working
>>>>>>
>>>>>> I looked at this branch and add my changes on the top.
>>>>>>
>>>>>> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
>>>>>> sunxi dt file. I had to add it to work for me.
>>>>>
>>>>> Ah yes, I decided to add this at the last minute so it is not relying
>>>>> on a convention.
>>>>>
>>>>>>
>>>>>> With BINMAN_FDT enabled I am getting error that there is no valid
>>>>>> "binman node" in DT. I didn't study that code yet but that's the point
>>>>>> of keeping this DT node out there?
>>>>>
>>>>> Is this in SPL? Perhaps something is filtering out the node.
>>>>
>>>> Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
>>>
>>> That needs debugging. I can't understand how the /binman node can be
>>> missing in U-Boot. The C library is very simple and doesn't handle
>>> finding nodes in multiple images...perhaps that is the problem?
>>
>> I found the reason for this behavior. On our platforms we are checking
>> specific address where DTB can be placed. And because I have played with
>> it also with previous image. It was pick up automatically.
>>
>> But still missing why BINMAN_FDT should be enabled by default on
>> platforms which don't call any binman functions. I see that you are
>> calling that functions from x86 platforms to try to map and find out
>> some image offsets/positions and it looks like that you are loading them.
>> I can imagine that this could be use for example for better space
>> utilization that my boot.bin with SPL can be followed immediately by
>> u-boot.itb in qspi. But for supporting this I expect spl_spi.c needs to
>> be aligned. And adding support in a generic way there needs to be an
>> agreement on node name which should be loaded.
>
> If you don't need CONFIG_BINMAN_FDT then it is fine to disable it. You
> could do that by updating the default condition there, or selecting a
> different value for your arch.
>
>>
>>
>>>>
>>>>>
>>>>>>
>>>>>> This is my binman configuration.
>>>>>>
>>>>>> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
>>>>>> b/arch/arm/dts/zynqmp-u-boot.dtsi
>>>>>> new file mode 100644
>>>>>> index 000000000000..b3364d3e2df8
>>>>>> --- /dev/null
>>>>>> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
>>>>>> @@ -0,0 +1,72 @@
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> +/*
>>>>>> + * Copyright (C) 2020 Xilinx, Inc.
>>>>>> + */
>>>>>> +
>>>>>> +#include <config.h>
>>>>>> +
>>>>>> +/ {
>>>>>> + binman: binman {
>>>>>> + multiple-images;
>>>>>> + };
>>>>>> +};
>>>>>> +
>>>>>> +&binman {
>>>>>> + u-boot-itb {
>>>>>> + filename = "u-boot.itb";
>>>>>> + fit {
>>>>>> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
>>>>>> + description = "FIT image with ATF support";
>>>>>> + fit,fdt-list = "of-list";
>>>>>> + #address-cells = <1>;
>>>>>> +
>>>>>> + images {
>>>>>> + uboot {
>>>>>> + description = "U-Boot (64-bit)";
>>>>>> + type = "firmware";
>>>>>> + os = "u-boot";
>>>>>> + arch = "arm64";
>>>>>> + compression = "none";
>>>>>> + load = <CONFIG_SYS_TEXT_BASE>;
>>>>>> + entry = <CONFIG_SYS_TEXT_BASE>;
>>>>>> +
>>>>>> + u-boot-nodtb {
>>>>>> + };
>>>>>> + };
>>>>>> + atf {
>>>>>> + description = "ARM Trusted Firmware";
>>>>>> + type = "firmware";
>>>>>> + os = "arm-trusted-firmware";
>>>>>> + arch = "arm64";
>>>>>> + compression = "none";
>>>>>> + load = <0xfffea000>; /* FIXME */
>>>>>> + entry = <0xfffea000>;
>>>>>> +
>>>>>> + blob-ext {
>>>>>> + filename = "bl31.bin";
>>>>>> + };
>>>>>> + };
>>>>>> + @fdt-SEQ {
>>>>>> + description = "NAME";
>>>>>> + type = "flat_dt";
>>>>>> + arch = "arm64";
>>>>>> + compression = "none";
>>>>>> + };
>>>>>> + };
>>>>>> +
>>>>>> + configurations {
>>>>>> + default = "config-1";
>>>>>> + @config-SEQ {
>>>>>> + description = "NAME";
>>>>>> + firmware = "atf";
>>>>>> + loadables = "uboot";
>>>>>> + fdt = "fdt-SEQ";
>>>>>> + };
>>>>>> + };
>>>>>> + };
>>>>>> + fdtmap{};
>>>>>> + };
>>>>>> +
>>>>>> +};
>>>>>>
>>>>>> Anyway compare to current script default option is hardcoded to
>>>>>> config-1.
>>>>>
>>>>>
>>>>>> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
>>>>>> setting up default option based on selected default DT (I can fix this
>>>>>> by implementing board_fit_config_name_match() but IIRC it is looping
>>>>>> over all configurations and slowing down boot).
>>>>>
>>>>> Is this using an environment variable to select the default? Would it
>>>>> be OK to put this in the DT for each individual board?
>>>>
>>>> I have added this code to board_fit_config_name_match() to select proper
>>>> configuration from SPL
>>>>
>>>> + if (!strcmp(name, DEVICE_TREE))
>>>> + return 0;
>>>>
>>>> DEVICE_TREE is setup in generated/dt.h.
>>>>
>>>> I am not quite sure what you mean by put this to each individual board.
>>>> Like a property for SPL which DT should be select?
>>>
>>> OK I see. In that case I think we need another entry argument to pass
>>> ${DEVICE_TREE} to the fit entry, and pass it in to binman from the
>>> Makefile with another -a parameter.
>>
>> Can you please include this option?
>
> OK I'll add something in the v2 series.
Thanks.
>
>>
>> Also what's the easiest way to compose multiple images though binman and
>> share images among others configurations?
>>
>> I will generate u-boot.itb through binman and then I want to use this
>> file for composing qspi image. Should I just point to u-boot.itb as blob
>> with filename?
>
> At present binman doesn't support including one image in another,
> although since generation of images is ordered, yes it should be
> possible to do it that way.
ok.
>
>> Layout for qspi is quite simply spl/boot.bin which is generated as
>> ./tools/mkimage -T zynqmpimage -R ./"" -n
>> "/home/monstr/data/disk/u-boot-bins/zynqmp/pmu.bin" -d
>> spl/u-boot-spl-align.bin spl/boot.bin >/dev/null && cat /dev/null
>
> OK you should be able to use the mkimage entry-type for that.
Normally it should be enough
mkimage {
args = "-T zynqmpimage -R $CONFIG_BOOT_INIT_FILE";
u-boot-spl-align {
};
};
It means I would have to create new type for u-boot-spl-align file.
And second in argument there is $CONFIG_BOOT_INIT_FILE.
Anyway I can simply take spl/boot.bin which is generated already as the
part of build and don't need to call mkimage from here.
>
>>
>> And then u-boot.itb placed at CONFIG_SYS_SPI_KERNEL_OFFS offset.
>
> OK, you can access CONFIG options in the .dtsi
>
> Can you please point me to the docs for zynqmp in the U-Boot tree? I
> see stuff about zynq inthe tree but it is quite old. I think there
> needs to be a link from doc/board/xilinx
We haven't really spent any time on writing proper doc for zynqmp.
But I normally just do this.
setup arm64 toochain
make xilinx_zynqmp_virt_defconfig
Fill
CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE - which points to pmu configuration
object.
and
CONFIG_PMUFW_INIT_FILE - which points to PMU binary file.
export DEVICE_TREE=zynqmp-zcu104-revC
make -j8
you get u-boot.itb and spl/boot.bin. You copy them to SD card and boot
from it. This will get you to u-boot running from EL3.
if you add bl31.bin to your source tree or point to it via BL31 variable
itb is created with ATF inside and you will get to to SPL->ATF->U-Boot
in EL2.
>
> Also is there a low-cost zynqmp board about? I'm thinking about adding
> it to my lab.
The cheapest is likely ultra96/zcu100. But v1 is sold out and v2 is made
by Avnet and they changed a lot of components and never invested time to
really support this board upstream.
But let me ask around if we have any v1 which we can share.
>
> Finally, these boards seem to use CONFIG_OF_EMBED which is not
> allowed. Can you fix that sometime?
Only that mini configurations which is used only for memory tests or
flash programming. Conversion to OF_SEPARATE should be easy but we need
to retest all configurations again.
Thanks,
Michal
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-09-01 15:15 ` Michal Simek
@ 2020-09-01 15:26 ` Simon Glass
2020-09-16 13:41 ` Michal Simek
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-09-01 15:26 UTC (permalink / raw)
To: u-boot
Hi Michal,
On Tue, 1 Sep 2020 at 09:15, Michal Simek <michal.simek@xilinx.com> wrote:
>
> Hi Simon,
>
> On 30. 08. 20 22:37, Simon Glass wrote:
> > Hi Michal,
> >
> > On Wed, 26 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
> >>
> >> Hi,
> >>
> >> On 25. 08. 20 18:57, Simon Glass wrote:
> >>> Hi Michal,
> >>>
> >>> On Tue, 25 Aug 2020 at 09:13, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>
> >>>> Hi Simon,
> >>>>
> >>>> On 25. 08. 20 17:04, Simon Glass wrote:
> >>>>> Hi Michal,
> >>>>>
> >>>>> On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>>>
> >>>>>> Hi Simon,
> >>>>>>
> >>>>>> On 22. 08. 20 17:08, Simon Glass wrote:
> >>>>>>> Hi Michal,
> >>>>>>>
> >>>>>>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
> >>>>>>>>
> >>>>>>>> Hi Simon,
> >>>>>>>>
> >>>>>>>> On 16. 08. 20 5:39, Simon Glass wrote:
> >>>>>>>>> Hi Michal,
> >>>>>>>>>
> >>>>>>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Simon,
> >>>>>>>>>>
> >>>>>>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
> >>>>>>>>>>>
> >>>>>>>>>>> This option is used to run arch-specific shell scripts which produce .its
> >>>>>>>>>>> files which are used to produce FIT images. We already have binman which
> >>>>>>>>>>> is designed to produce firmware images. It is more powerful and has tests.
> >>>>>>>>>>>
> >>>>>>>>>>> So this option should be deprecated and not used. Existing uses should be
> >>>>>>>>>>> migrated.
> >>>>>>>>>>>
> >>>>>>>>>>> Mentions of this in code reviews over the last year or so do not seem to
> >>>>>>>>>>> have resulted in action, and things are getting worse.
> >>>>>>>>>>>
> >>>>>>>>>>> So let's add a warning.
> >>>>>>>>>>>
> >>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
> >>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> >>>>>>>>>>> ---
> >>>>>>>>>>>
> >>>>>>>>>>> (no changes since v1)
> >>>>>>>>>>>
> >>>>>>>>>>> Makefile | 9 +++++++++
> >>>>>>>>>>> 1 file changed, 9 insertions(+)
> >>>>>>>>>>>
> >>>>>>>>>>> diff --git a/Makefile b/Makefile
> >>>>>>>>>>> index f1b5be1882..d73c10a973 100644
> >>>>>>>>>>> --- a/Makefile
> >>>>>>>>>>> +++ b/Makefile
> >>>>>>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
> >>>>>>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
> >>>>>>>>>>> @echo >&2 "===================================================="
> >>>>>>>>>>> endif
> >>>>>>>>>>> +endif
> >>>>>>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> >>>>>>>>>>> + @echo >&2 "===================== WARNING ======================"
> >>>>>>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> >>>>>>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
> >>>>>>>>>>> + @echo >&2 "arch-specific scripts with no tests."
> >>>>>>>>>>> + @echo >&2 "===================================================="
> >>>>>>>>>>> endif
> >>>>>>>>>>> @# Check that this build does not use CONFIG options that we do not
> >>>>>>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
> >>>>>>>>>>> @@ -1345,6 +1352,8 @@ endif
> >>>>>>>>>>>
> >>>>>>>>>>> # Boards with more complex image requirements can provide an .its source file
> >>>>>>>>>>> # or a generator script
> >>>>>>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
> >>>>>>>>>>> +# binman instead.
> >>>>>>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
> >>>>>>>>>>> U_BOOT_ITS := u-boot.its
> >>>>>>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
> >>>>>>>>>>> --
> >>>>>>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I just got to this conversion and I am curious how that transition
> >>>>>>>>>> should look like.
> >>>>>>>>>> I found how FIT image is created which is fine but I didn't find any
> >>>>>>>>>> reference on how to generate images based on CONFIG_OF_LIST.
> >>>>>>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
> >>>>>>>>>> that I loop over this entry and create multiple DT nodes and the same
> >>>>>>>>>> amount of configurations to cover it. Is this supported by binman?
> >>>>>>>>>> If yes, what's the syntax for it?
> >>>>>>>>>
> >>>>>>>>> The easiest way is probably to create a new entry type, like zynq-fit.
> >>>>>>>>> Then you can generate the DT using the sequence writer functions. See
> >>>>>>>>> _ReadSubNodes() in fit.py for an example.
> >>>>>>>>>
> >>>>>>>>> You can perhaps have a template subnode and use that in a for loop to
> >>>>>>>>> generate the nodes.
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I tried several configurations and we can use that for generating qspi
> >>>>>>>>>> images and also images with different configurations to have them
> >>>>>>>>>> ready
> >>>>>>>>>> but first I need to be able to handle the case above.
> >>>>>>>>>
> >>>>>>>>> I was thinking of converting sunxi which has the same need, but it
> >>>>>>>>> sounds like you are on the case. Let me know if you need help.
> >>>>>>>>
> >>>>>>>> Nope. I just saw that message and started to play with it to find out
> >>>>>>>> what needs to be done and how this fits to bigger picture. If this
> >>>>>>>> doesn't work directly then the work needs to be planned which will take
> >>>>>>>> time especially when this utility is new for us and we could have issues
> >>>>>>>> with writing code in python. Would be good if you can do the first shot
> >>>>>>>> because you know this utility and I am more than happy to test it, try
> >>>>>>>> and adopt if needed for our case.
> >>>>>>>>
> >>>>>>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
> >>>>>>>> default configuration to config_1. ZynqMP is setting up default based on
> >>>>>>>> default DT configured at that time.
> >>>>>>>>
> >>>>>>>> In connection to binman I see that there would be a need to generate
> >>>>>>>> images with ATF and without ATF in configuration node and with different
> >>>>>>>> default configuration. There could be also a need to add additional
> >>>>>>>> loadable entry such as bitstreams.
> >>>>>>>>
> >>>>>>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
> >>>>>>>> type because as was state in commit message u-boot.itb generation is
> >>>>>>>> very similar for all these boards that's why name for this new entry
> >>>>>>>> should be generic.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I sent an initial series to add this to binman. I've since found a few
> >>>>>>> problems so will send a v2 at some point. You can try it out at
> >>>>>>> u-boot-dm/binman-working
> >>>>>>
> >>>>>> I looked at this branch and add my changes on the top.
> >>>>>>
> >>>>>> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
> >>>>>> sunxi dt file. I had to add it to work for me.
> >>>>>
> >>>>> Ah yes, I decided to add this at the last minute so it is not relying
> >>>>> on a convention.
> >>>>>
> >>>>>>
> >>>>>> With BINMAN_FDT enabled I am getting error that there is no valid
> >>>>>> "binman node" in DT. I didn't study that code yet but that's the point
> >>>>>> of keeping this DT node out there?
> >>>>>
> >>>>> Is this in SPL? Perhaps something is filtering out the node.
> >>>>
> >>>> Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
> >>>
> >>> That needs debugging. I can't understand how the /binman node can be
> >>> missing in U-Boot. The C library is very simple and doesn't handle
> >>> finding nodes in multiple images...perhaps that is the problem?
> >>
> >> I found the reason for this behavior. On our platforms we are checking
> >> specific address where DTB can be placed. And because I have played with
> >> it also with previous image. It was pick up automatically.
> >>
> >> But still missing why BINMAN_FDT should be enabled by default on
> >> platforms which don't call any binman functions. I see that you are
> >> calling that functions from x86 platforms to try to map and find out
> >> some image offsets/positions and it looks like that you are loading them.
> >> I can imagine that this could be use for example for better space
> >> utilization that my boot.bin with SPL can be followed immediately by
> >> u-boot.itb in qspi. But for supporting this I expect spl_spi.c needs to
> >> be aligned. And adding support in a generic way there needs to be an
> >> agreement on node name which should be loaded.
> >
> > If you don't need CONFIG_BINMAN_FDT then it is fine to disable it. You
> > could do that by updating the default condition there, or selecting a
> > different value for your arch.
> >
> >>
> >>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> This is my binman configuration.
> >>>>>>
> >>>>>> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
> >>>>>> b/arch/arm/dts/zynqmp-u-boot.dtsi
> >>>>>> new file mode 100644
> >>>>>> index 000000000000..b3364d3e2df8
> >>>>>> --- /dev/null
> >>>>>> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
> >>>>>> @@ -0,0 +1,72 @@
> >>>>>> +// SPDX-License-Identifier: GPL-2.0
> >>>>>> +/*
> >>>>>> + * Copyright (C) 2020 Xilinx, Inc.
> >>>>>> + */
> >>>>>> +
> >>>>>> +#include <config.h>
> >>>>>> +
> >>>>>> +/ {
> >>>>>> + binman: binman {
> >>>>>> + multiple-images;
> >>>>>> + };
> >>>>>> +};
> >>>>>> +
> >>>>>> +&binman {
> >>>>>> + u-boot-itb {
> >>>>>> + filename = "u-boot.itb";
> >>>>>> + fit {
> >>>>>> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
> >>>>>> + description = "FIT image with ATF support";
> >>>>>> + fit,fdt-list = "of-list";
> >>>>>> + #address-cells = <1>;
> >>>>>> +
> >>>>>> + images {
> >>>>>> + uboot {
> >>>>>> + description = "U-Boot (64-bit)";
> >>>>>> + type = "firmware";
> >>>>>> + os = "u-boot";
> >>>>>> + arch = "arm64";
> >>>>>> + compression = "none";
> >>>>>> + load = <CONFIG_SYS_TEXT_BASE>;
> >>>>>> + entry = <CONFIG_SYS_TEXT_BASE>;
> >>>>>> +
> >>>>>> + u-boot-nodtb {
> >>>>>> + };
> >>>>>> + };
> >>>>>> + atf {
> >>>>>> + description = "ARM Trusted Firmware";
> >>>>>> + type = "firmware";
> >>>>>> + os = "arm-trusted-firmware";
> >>>>>> + arch = "arm64";
> >>>>>> + compression = "none";
> >>>>>> + load = <0xfffea000>; /* FIXME */
> >>>>>> + entry = <0xfffea000>;
> >>>>>> +
> >>>>>> + blob-ext {
> >>>>>> + filename = "bl31.bin";
> >>>>>> + };
> >>>>>> + };
> >>>>>> + @fdt-SEQ {
> >>>>>> + description = "NAME";
> >>>>>> + type = "flat_dt";
> >>>>>> + arch = "arm64";
> >>>>>> + compression = "none";
> >>>>>> + };
> >>>>>> + };
> >>>>>> +
> >>>>>> + configurations {
> >>>>>> + default = "config-1";
> >>>>>> + @config-SEQ {
> >>>>>> + description = "NAME";
> >>>>>> + firmware = "atf";
> >>>>>> + loadables = "uboot";
> >>>>>> + fdt = "fdt-SEQ";
> >>>>>> + };
> >>>>>> + };
> >>>>>> + };
> >>>>>> + fdtmap{};
> >>>>>> + };
> >>>>>> +
> >>>>>> +};
> >>>>>>
> >>>>>> Anyway compare to current script default option is hardcoded to
> >>>>>> config-1.
> >>>>>
> >>>>>
> >>>>>> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
> >>>>>> setting up default option based on selected default DT (I can fix this
> >>>>>> by implementing board_fit_config_name_match() but IIRC it is looping
> >>>>>> over all configurations and slowing down boot).
> >>>>>
> >>>>> Is this using an environment variable to select the default? Would it
> >>>>> be OK to put this in the DT for each individual board?
> >>>>
> >>>> I have added this code to board_fit_config_name_match() to select proper
> >>>> configuration from SPL
> >>>>
> >>>> + if (!strcmp(name, DEVICE_TREE))
> >>>> + return 0;
> >>>>
> >>>> DEVICE_TREE is setup in generated/dt.h.
> >>>>
> >>>> I am not quite sure what you mean by put this to each individual board.
> >>>> Like a property for SPL which DT should be select?
> >>>
> >>> OK I see. In that case I think we need another entry argument to pass
> >>> ${DEVICE_TREE} to the fit entry, and pass it in to binman from the
> >>> Makefile with another -a parameter.
> >>
> >> Can you please include this option?
> >
> > OK I'll add something in the v2 series.
>
> Thanks.
>
> >
> >>
> >> Also what's the easiest way to compose multiple images though binman and
> >> share images among others configurations?
> >>
> >> I will generate u-boot.itb through binman and then I want to use this
> >> file for composing qspi image. Should I just point to u-boot.itb as blob
> >> with filename?
> >
> > At present binman doesn't support including one image in another,
> > although since generation of images is ordered, yes it should be
> > possible to do it that way.
>
> ok.
>
> >
> >> Layout for qspi is quite simply spl/boot.bin which is generated as
> >> ./tools/mkimage -T zynqmpimage -R ./"" -n
> >> "/home/monstr/data/disk/u-boot-bins/zynqmp/pmu.bin" -d
> >> spl/u-boot-spl-align.bin spl/boot.bin >/dev/null && cat /dev/null
> >
> > OK you should be able to use the mkimage entry-type for that.
>
> Normally it should be enough
> mkimage {
> args = "-T zynqmpimage -R $CONFIG_BOOT_INIT_FILE";
> u-boot-spl-align {
> };
> };
>
> It means I would have to create new type for u-boot-spl-align file.
> And second in argument there is $CONFIG_BOOT_INIT_FILE.
One option would be to allow args to be a list of strings, i.e. one
string per argument. Then you could do:
args = "-T", "zynqmpimage", "-R", CONFIG_BOOT_INIT_FILE;
>
> Anyway I can simply take spl/boot.bin which is generated already as the
> part of build and don't need to call mkimage from here.
The goal here is to get rid of arch-specific stuff in Makefile.
>
>
> >
> >>
> >> And then u-boot.itb placed at CONFIG_SYS_SPI_KERNEL_OFFS offset.
> >
> > OK, you can access CONFIG options in the .dtsi
> >
> > Can you please point me to the docs for zynqmp in the U-Boot tree? I
> > see stuff about zynq inthe tree but it is quite old. I think there
> > needs to be a link from doc/board/xilinx
>
> We haven't really spent any time on writing proper doc for zynqmp.
> But I normally just do this.
>
> setup arm64 toochain
> make xilinx_zynqmp_virt_defconfig
> Fill
> CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE - which points to pmu configuration
> object.
> and
> CONFIG_PMUFW_INIT_FILE - which points to PMU binary file.
>
> export DEVICE_TREE=zynqmp-zcu104-revC
> make -j8
>
> you get u-boot.itb and spl/boot.bin. You copy them to SD card and boot
> from it. This will get you to u-boot running from EL3.
>
> if you add bl31.bin to your source tree or point to it via BL31 variable
> itb is created with ATF inside and you will get to to SPL->ATF->U-Boot
> in EL2.
Would you mind putting the above in a patch?
>
> >
> > Also is there a low-cost zynqmp board about? I'm thinking about adding
> > it to my lab.
>
> The cheapest is likely ultra96/zcu100. But v1 is sold out and v2 is made
> by Avnet and they changed a lot of components and never invested time to
> really support this board upstream.
> But let me ask around if we have any v1 which we can share.
OK ta. I can't see any around.
>
> >
> > Finally, these boards seem to use CONFIG_OF_EMBED which is not
> > allowed. Can you fix that sometime?
>
> Only that mini configurations which is used only for memory tests or
> flash programming. Conversion to OF_SEPARATE should be easy but we need
> to retest all configurations again.
OK. That should really be done as a priority as it should not have
been done that way. Perhaps after the binman conversion?
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-09-01 15:26 ` Simon Glass
@ 2020-09-16 13:41 ` Michal Simek
0 siblings, 0 replies; 94+ messages in thread
From: Michal Simek @ 2020-09-16 13:41 UTC (permalink / raw)
To: u-boot
Hi Simon,
On 01. 09. 20 17:26, Simon Glass wrote:
> Hi Michal,
>
> On Tue, 1 Sep 2020 at 09:15, Michal Simek <michal.simek@xilinx.com> wrote:
>>
>> Hi Simon,
>>
>> On 30. 08. 20 22:37, Simon Glass wrote:
>>> Hi Michal,
>>>
>>> On Wed, 26 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 25. 08. 20 18:57, Simon Glass wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Tue, 25 Aug 2020 at 09:13, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>
>>>>>> Hi Simon,
>>>>>>
>>>>>> On 25. 08. 20 17:04, Simon Glass wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>> On Mon, 24 Aug 2020 at 08:12, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>>>
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On 22. 08. 20 17:08, Simon Glass wrote:
>>>>>>>>> Hi Michal,
>>>>>>>>>
>>>>>>>>> On Mon, 17 Aug 2020 at 00:49, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On 16. 08. 20 5:39, Simon Glass wrote:
>>>>>>>>>>> Hi Michal,
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 14 Aug 2020 at 07:28, Michal Simek <monstr@monstr.eu> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>>
>>>>>>>>>>>> ne 19. 7. 2020 v 22:06 odes?latel Simon Glass <sjg@chromium.org> napsal:
>>>>>>>>>>>>>
>>>>>>>>>>>>> This option is used to run arch-specific shell scripts which produce .its
>>>>>>>>>>>>> files which are used to produce FIT images. We already have binman which
>>>>>>>>>>>>> is designed to produce firmware images. It is more powerful and has tests.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So this option should be deprecated and not used. Existing uses should be
>>>>>>>>>>>>> migrated.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Mentions of this in code reviews over the last year or so do not seem to
>>>>>>>>>>>>> have resulted in action, and things are getting worse.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So let's add a warning.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>>> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>> (no changes since v1)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Makefile | 9 +++++++++
>>>>>>>>>>>>> 1 file changed, 9 insertions(+)
>>>>>>>>>>>>>
>>>>>>>>>>>>> diff --git a/Makefile b/Makefile
>>>>>>>>>>>>> index f1b5be1882..d73c10a973 100644
>>>>>>>>>>>>> --- a/Makefile
>>>>>>>>>>>>> +++ b/Makefile
>>>>>>>>>>>>> @@ -1148,6 +1148,13 @@ ifneq ($(CONFIG_DM_ETH),y)
>>>>>>>>>>>>> @echo >&2 "See doc/driver-model/migration.rst for more info."
>>>>>>>>>>>>> @echo >&2 "===================================================="
>>>>>>>>>>>>> endif
>>>>>>>>>>>>> +endif
>>>>>>>>>>>>> +ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
>>>>>>>>>>>>> + @echo >&2 "===================== WARNING ======================"
>>>>>>>>>>>>> + @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>>>>>>>>>>>>> + @echo >&2 "to binman instead, to avoid the proliferation of"
>>>>>>>>>>>>> + @echo >&2 "arch-specific scripts with no tests."
>>>>>>>>>>>>> + @echo >&2 "===================================================="
>>>>>>>>>>>>> endif
>>>>>>>>>>>>> @# Check that this build does not use CONFIG options that we do not
>>>>>>>>>>>>> @# know about unless they are in Kconfig. All the existing CONFIG
>>>>>>>>>>>>> @@ -1345,6 +1352,8 @@ endif
>>>>>>>>>>>>>
>>>>>>>>>>>>> # Boards with more complex image requirements can provide an .its source file
>>>>>>>>>>>>> # or a generator script
>>>>>>>>>>>>> +# NOTE: Please do not use this. We are migrating away from Makefile rules to use
>>>>>>>>>>>>> +# binman instead.
>>>>>>>>>>>>> ifneq ($(CONFIG_SPL_FIT_SOURCE),"")
>>>>>>>>>>>>> U_BOOT_ITS := u-boot.its
>>>>>>>>>>>>> $(U_BOOT_ITS): $(subst ",,$(CONFIG_SPL_FIT_SOURCE))
>>>>>>>>>>>>> --
>>>>>>>>>>>>> 2.28.0.rc0.105.gf9edc3c819-goog
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I just got to this conversion and I am curious how that transition
>>>>>>>>>>>> should look like.
>>>>>>>>>>>> I found how FIT image is created which is fine but I didn't find any
>>>>>>>>>>>> reference on how to generate images based on CONFIG_OF_LIST.
>>>>>>>>>>>> If you look at arch/arm/mach-zynqmp/mkimage_fit_atf.sh you will see
>>>>>>>>>>>> that I loop over this entry and create multiple DT nodes and the same
>>>>>>>>>>>> amount of configurations to cover it. Is this supported by binman?
>>>>>>>>>>>> If yes, what's the syntax for it?
>>>>>>>>>>>
>>>>>>>>>>> The easiest way is probably to create a new entry type, like zynq-fit.
>>>>>>>>>>> Then you can generate the DT using the sequence writer functions. See
>>>>>>>>>>> _ReadSubNodes() in fit.py for an example.
>>>>>>>>>>>
>>>>>>>>>>> You can perhaps have a template subnode and use that in a for loop to
>>>>>>>>>>> generate the nodes.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I tried several configurations and we can use that for generating qspi
>>>>>>>>>>>> images and also images with different configurations to have them
>>>>>>>>>>>> ready
>>>>>>>>>>>> but first I need to be able to handle the case above.
>>>>>>>>>>>
>>>>>>>>>>> I was thinking of converting sunxi which has the same need, but it
>>>>>>>>>>> sounds like you are on the case. Let me know if you need help.
>>>>>>>>>>
>>>>>>>>>> Nope. I just saw that message and started to play with it to find out
>>>>>>>>>> what needs to be done and how this fits to bigger picture. If this
>>>>>>>>>> doesn't work directly then the work needs to be planned which will take
>>>>>>>>>> time especially when this utility is new for us and we could have issues
>>>>>>>>>> with writing code in python. Would be good if you can do the first shot
>>>>>>>>>> because you know this utility and I am more than happy to test it, try
>>>>>>>>>> and adopt if needed for our case.
>>>>>>>>>>
>>>>>>>>>> Sunxi is very similar case as is zynqmp. Difference is they hardcode
>>>>>>>>>> default configuration to config_1. ZynqMP is setting up default based on
>>>>>>>>>> default DT configured at that time.
>>>>>>>>>>
>>>>>>>>>> In connection to binman I see that there would be a need to generate
>>>>>>>>>> images with ATF and without ATF in configuration node and with different
>>>>>>>>>> default configuration. There could be also a need to add additional
>>>>>>>>>> loadable entry such as bitstreams.
>>>>>>>>>>
>>>>>>>>>> Back to zynq-fit new entry type. I don't think it should be zynq/zynqmp
>>>>>>>>>> type because as was state in commit message u-boot.itb generation is
>>>>>>>>>> very similar for all these boards that's why name for this new entry
>>>>>>>>>> should be generic.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I sent an initial series to add this to binman. I've since found a few
>>>>>>>>> problems so will send a v2 at some point. You can try it out at
>>>>>>>>> u-boot-dm/binman-working
>>>>>>>>
>>>>>>>> I looked at this branch and add my changes on the top.
>>>>>>>>
>>>>>>>> The first thing what I see is that I miss fit,fdt-list = "of-list"; in
>>>>>>>> sunxi dt file. I had to add it to work for me.
>>>>>>>
>>>>>>> Ah yes, I decided to add this at the last minute so it is not relying
>>>>>>> on a convention.
>>>>>>>
>>>>>>>>
>>>>>>>> With BINMAN_FDT enabled I am getting error that there is no valid
>>>>>>>> "binman node" in DT. I didn't study that code yet but that's the point
>>>>>>>> of keeping this DT node out there?
>>>>>>>
>>>>>>> Is this in SPL? Perhaps something is filtering out the node.
>>>>>>
>>>>>> Nope in full U-Boot but in SPL flow. SPL->ATF->FULL U-Boot.
>>>>>
>>>>> That needs debugging. I can't understand how the /binman node can be
>>>>> missing in U-Boot. The C library is very simple and doesn't handle
>>>>> finding nodes in multiple images...perhaps that is the problem?
>>>>
>>>> I found the reason for this behavior. On our platforms we are checking
>>>> specific address where DTB can be placed. And because I have played with
>>>> it also with previous image. It was pick up automatically.
>>>>
>>>> But still missing why BINMAN_FDT should be enabled by default on
>>>> platforms which don't call any binman functions. I see that you are
>>>> calling that functions from x86 platforms to try to map and find out
>>>> some image offsets/positions and it looks like that you are loading them.
>>>> I can imagine that this could be use for example for better space
>>>> utilization that my boot.bin with SPL can be followed immediately by
>>>> u-boot.itb in qspi. But for supporting this I expect spl_spi.c needs to
>>>> be aligned. And adding support in a generic way there needs to be an
>>>> agreement on node name which should be loaded.
>>>
>>> If you don't need CONFIG_BINMAN_FDT then it is fine to disable it. You
>>> could do that by updating the default condition there, or selecting a
>>> different value for your arch.
>>>
>>>>
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> This is my binman configuration.
>>>>>>>>
>>>>>>>> diff --git a/arch/arm/dts/zynqmp-u-boot.dtsi
>>>>>>>> b/arch/arm/dts/zynqmp-u-boot.dtsi
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..b3364d3e2df8
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/arch/arm/dts/zynqmp-u-boot.dtsi
>>>>>>>> @@ -0,0 +1,72 @@
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>>>> +/*
>>>>>>>> + * Copyright (C) 2020 Xilinx, Inc.
>>>>>>>> + */
>>>>>>>> +
>>>>>>>> +#include <config.h>
>>>>>>>> +
>>>>>>>> +/ {
>>>>>>>> + binman: binman {
>>>>>>>> + multiple-images;
>>>>>>>> + };
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +&binman {
>>>>>>>> + u-boot-itb {
>>>>>>>> + filename = "u-boot.itb";
>>>>>>>> + fit {
>>>>>>>> + fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
>>>>>>>> + description = "FIT image with ATF support";
>>>>>>>> + fit,fdt-list = "of-list";
>>>>>>>> + #address-cells = <1>;
>>>>>>>> +
>>>>>>>> + images {
>>>>>>>> + uboot {
>>>>>>>> + description = "U-Boot (64-bit)";
>>>>>>>> + type = "firmware";
>>>>>>>> + os = "u-boot";
>>>>>>>> + arch = "arm64";
>>>>>>>> + compression = "none";
>>>>>>>> + load = <CONFIG_SYS_TEXT_BASE>;
>>>>>>>> + entry = <CONFIG_SYS_TEXT_BASE>;
>>>>>>>> +
>>>>>>>> + u-boot-nodtb {
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> + atf {
>>>>>>>> + description = "ARM Trusted Firmware";
>>>>>>>> + type = "firmware";
>>>>>>>> + os = "arm-trusted-firmware";
>>>>>>>> + arch = "arm64";
>>>>>>>> + compression = "none";
>>>>>>>> + load = <0xfffea000>; /* FIXME */
>>>>>>>> + entry = <0xfffea000>;
>>>>>>>> +
>>>>>>>> + blob-ext {
>>>>>>>> + filename = "bl31.bin";
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> + @fdt-SEQ {
>>>>>>>> + description = "NAME";
>>>>>>>> + type = "flat_dt";
>>>>>>>> + arch = "arm64";
>>>>>>>> + compression = "none";
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> + configurations {
>>>>>>>> + default = "config-1";
>>>>>>>> + @config-SEQ {
>>>>>>>> + description = "NAME";
>>>>>>>> + firmware = "atf";
>>>>>>>> + loadables = "uboot";
>>>>>>>> + fdt = "fdt-SEQ";
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> + };
>>>>>>>> + fdtmap{};
>>>>>>>> + };
>>>>>>>> +
>>>>>>>> +};
>>>>>>>>
>>>>>>>> Anyway compare to current script default option is hardcoded to
>>>>>>>> config-1.
>>>>>>>
>>>>>>>
>>>>>>>> Current arch/arm/mach-zynqmp/mkimage_fit_atf.sh is also
>>>>>>>> setting up default option based on selected default DT (I can fix this
>>>>>>>> by implementing board_fit_config_name_match() but IIRC it is looping
>>>>>>>> over all configurations and slowing down boot).
>>>>>>>
>>>>>>> Is this using an environment variable to select the default? Would it
>>>>>>> be OK to put this in the DT for each individual board?
>>>>>>
>>>>>> I have added this code to board_fit_config_name_match() to select proper
>>>>>> configuration from SPL
>>>>>>
>>>>>> + if (!strcmp(name, DEVICE_TREE))
>>>>>> + return 0;
>>>>>>
>>>>>> DEVICE_TREE is setup in generated/dt.h.
>>>>>>
>>>>>> I am not quite sure what you mean by put this to each individual board.
>>>>>> Like a property for SPL which DT should be select?
>>>>>
>>>>> OK I see. In that case I think we need another entry argument to pass
>>>>> ${DEVICE_TREE} to the fit entry, and pass it in to binman from the
>>>>> Makefile with another -a parameter.
>>>>
>>>> Can you please include this option?
>>>
>>> OK I'll add something in the v2 series.
>>
>> Thanks.
>>
>>>
>>>>
>>>> Also what's the easiest way to compose multiple images though binman and
>>>> share images among others configurations?
>>>>
>>>> I will generate u-boot.itb through binman and then I want to use this
>>>> file for composing qspi image. Should I just point to u-boot.itb as blob
>>>> with filename?
>>>
>>> At present binman doesn't support including one image in another,
>>> although since generation of images is ordered, yes it should be
>>> possible to do it that way.
>>
>> ok.
>>
>>>
>>>> Layout for qspi is quite simply spl/boot.bin which is generated as
>>>> ./tools/mkimage -T zynqmpimage -R ./"" -n
>>>> "/home/monstr/data/disk/u-boot-bins/zynqmp/pmu.bin" -d
>>>> spl/u-boot-spl-align.bin spl/boot.bin >/dev/null && cat /dev/null
>>>
>>> OK you should be able to use the mkimage entry-type for that.
>>
>> Normally it should be enough
>> mkimage {
>> args = "-T zynqmpimage -R $CONFIG_BOOT_INIT_FILE";
>> u-boot-spl-align {
>> };
>> };
>>
>> It means I would have to create new type for u-boot-spl-align file.
>> And second in argument there is $CONFIG_BOOT_INIT_FILE.
>
> One option would be to allow args to be a list of strings, i.e. one
> string per argument. Then you could do:
>
> args = "-T", "zynqmpimage", "-R", CONFIG_BOOT_INIT_FILE;
>
>>
>> Anyway I can simply take spl/boot.bin which is generated already as the
>> part of build and don't need to call mkimage from here.
>
> The goal here is to get rid of arch-specific stuff in Makefile.
>
>>
>>
>>>
>>>>
>>>> And then u-boot.itb placed at CONFIG_SYS_SPI_KERNEL_OFFS offset.
>>>
>>> OK, you can access CONFIG options in the .dtsi
>>>
>>> Can you please point me to the docs for zynqmp in the U-Boot tree? I
>>> see stuff about zynq inthe tree but it is quite old. I think there
>>> needs to be a link from doc/board/xilinx
>>
>> We haven't really spent any time on writing proper doc for zynqmp.
>> But I normally just do this.
>>
>> setup arm64 toochain
>> make xilinx_zynqmp_virt_defconfig
>> Fill
>> CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE - which points to pmu configuration
>> object.
>> and
>> CONFIG_PMUFW_INIT_FILE - which points to PMU binary file.
>>
>> export DEVICE_TREE=zynqmp-zcu104-revC
>> make -j8
>>
>> you get u-boot.itb and spl/boot.bin. You copy them to SD card and boot
>> from it. This will get you to u-boot running from EL3.
>>
>> if you add bl31.bin to your source tree or point to it via BL31 variable
>> itb is created with ATF inside and you will get to to SPL->ATF->U-Boot
>> in EL2.
>
> Would you mind putting the above in a patch?
I have sent patches which updates documentation.
Thanks,
Michal
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 21/27] rockchip: Convert evb-rk3288 over to use binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (19 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 22/27] rockchip: Convert evb-rk3229 " Simon Glass
` (32 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
- Move the .itb output to a separate rockchip-optee.dtsi file
- Add a check for CONFIG_FIT before building the .its
Changes in v3:
- Drop use of rk322x.dtsi
- Add changes to rk3288-u-boot.dtsi instead
Kconfig | 2 +-
arch/arm/dts/rk3288-u-boot.dtsi | 1 +
arch/arm/dts/rockchip-optee.dtsi | 64 +++++++++++++++++++++++++++
arch/arm/mach-rockchip/rk3288/Kconfig | 1 +
configs/evb-rk3288_defconfig | 2 +-
5 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/rockchip-optee.dtsi
diff --git a/Kconfig b/Kconfig
index 1dc5273c68..11c71141db 100644
--- a/Kconfig
+++ b/Kconfig
@@ -321,7 +321,7 @@ config BUILD_TARGET
default "u-boot-with-spl.sfp" if TARGET_SOCFPGA_GEN5
default "u-boot-spl.kwb" if ARCH_MVEBU && SPL
default "u-boot-elf.srec" if RCAR_GEN3
- default "u-boot.itb" if SPL_LOAD_FIT && (ARCH_ROCKCHIP || \
+ default "u-boot.itb" if !BINMAN && SPL_LOAD_FIT && (ARCH_ROCKCHIP || \
ARCH_SUNXI || RISCV || ARCH_ZYNQMP)
default "u-boot.kwb" if ARCH_KIRKWOOD
default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index c87f00141f..e3c6c10f13 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include "rockchip-u-boot.dtsi"
+#include "rockchip-optee.dtsi"
/ {
chosen {
diff --git a/arch/arm/dts/rockchip-optee.dtsi b/arch/arm/dts/rockchip-optee.dtsi
new file mode 100644
index 0000000000..cde9b81b26
--- /dev/null
+++ b/arch/arm/dts/rockchip-optee.dtsi
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Google LLC
+ */
+
+#include <config.h>
+
+#if defined(CONFIG_HAS_ROM) && defined(CONFIG_FIT)
+&binman {
+ itb {
+ filename = "u-boot.itb";
+ fit {
+ fit,external-offset = <CONFIG_FIT_EXTERNAL_OFFSET>;
+ description = "FIT image with OP-TEE support";
+ #address-cells = <1>;
+
+ images {
+ uboot {
+ description = "U-Boot";
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm";
+ compression = "none";
+ load = <CONFIG_SYS_TEXT_BASE>;
+
+ u-boot-nodtb {
+ };
+ };
+ optee {
+ description = "OP-TEE";
+ type = "firmware";
+ arch = "arm";
+ os = "tee";
+ compression = "none";
+ load = <(CONFIG_SYS_SDRAM_BASE + 0x8400000)>;
+ entry = <(CONFIG_SYS_SDRAM_BASE + 0x8400000)>;
+
+ blob-ext {
+ filename = "tee.bin";
+ };
+ };
+ fdt {
+ description = CONFIG_SYS_BOARD;
+ type = "flat_dt";
+ compression = "none";
+
+ u-boot-dtb {
+ };
+ };
+ };
+
+ configurations {
+ default = "conf";
+ conf {
+ description = CONFIG_SYS_BOARD;
+ firmware = "optee";
+ loadables = "uboot";
+ fdt = "fdt";
+ };
+ };
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig b/arch/arm/mach-rockchip/rk3288/Kconfig
index bb715e9d0e..20a00c5be7 100644
--- a/arch/arm/mach-rockchip/rk3288/Kconfig
+++ b/arch/arm/mach-rockchip/rk3288/Kconfig
@@ -48,6 +48,7 @@ config TARGET_CHROMEBOOK_SPEEDY
config TARGET_EVB_RK3288
bool "Evb-RK3288"
+ select HAS_ROM
select BOARD_LATE_INIT
select TPL
help
diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 350189fc63..cd03767bd5 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -14,7 +14,7 @@ CONFIG_DEBUG_UART=y
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/fit_spl_optee.sh"
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_PREBOOT=y
CONFIG_SILENT_CONSOLE=y
CONFIG_DEFAULT_FDT_FILE="rk3288-evb-rk808.dtb"
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 22/27] rockchip: Convert evb-rk3229 over to use binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (20 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 21/27] rockchip: Convert evb-rk3288 over to use binman Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script Simon Glass
` (31 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Drop leftover debugging
configs/evb-rk3229_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/evb-rk3229_defconfig b/configs/evb-rk3229_defconfig
index 1d0fe3332b..406437d1d9 100644
--- a/configs/evb-rk3229_defconfig
+++ b/configs/evb-rk3229_defconfig
@@ -15,7 +15,7 @@ CONFIG_DEBUG_UART=y
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/fit_spl_optee.sh"
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_USE_PREBOOT=y
CONFIG_DEFAULT_FDT_FILE="rk3229-evb.dtb"
# CONFIG_DISPLAY_CPUINFO is not set
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (21 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 22/27] rockchip: Convert evb-rk3229 " Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs Simon Glass
` (30 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
Now that all board use binman instead of this script, drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/arm/mach-rockchip/fit_spl_optee.sh | 84 -------------------------
1 file changed, 84 deletions(-)
delete mode 100755 arch/arm/mach-rockchip/fit_spl_optee.sh
diff --git a/arch/arm/mach-rockchip/fit_spl_optee.sh b/arch/arm/mach-rockchip/fit_spl_optee.sh
deleted file mode 100755
index 4118472d9f..0000000000
--- a/arch/arm/mach-rockchip/fit_spl_optee.sh
+++ /dev/null
@@ -1,84 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2019 Rockchip Electronic Co.,Ltd
-#
-# Script to generate FIT image source for 32-bit Rockchip SoCs with
-# U-Boot proper, OPTEE, and devicetree.
-#
-# usage: $0 <dt_name>
-
-[ -z "$TEE" ] && TEE="tee.bin"
-
-if [ ! -f $TEE ]; then
- echo "WARNING: TEE file $TEE NOT found, U-Boot.itb is non-functional" >&2
- echo "Please export path for TEE or copy tee.bin to U-Boot folder" >&2
- TEE=/dev/null
-fi
-
-dtname=$1
-text_base=`sed -n "/SYS_TEXT_BASE=/s/CONFIG_SYS_TEXT_BASE=//p" .config \
- |tr -d '\r'`
-dram_base=`sed -n "/SYS_SDRAM_BASE=/s/CONFIG_SYS_SDRAM_BASE=//p" \
- include/autoconf.mk|tr -d '\r'`
-tee_base=`echo "obase=16;$(($dram_base+0x8400000))"|bc`
-tee_base='0x'$tee_base
-
-cat << __HEADER_EOF
-/*
- * Copyright (C) 2017-2019 Rockchip Electronic Co.,Ltd
- *
- * Simple U-boot FIT source file containing U-Boot, dtb and optee
- */
-
-/dts-v1/;
-
-/ {
- description = "FIT image with OP-TEE support";
- #address-cells = <1>;
-
- images {
- uboot {
- description = "U-Boot";
- data = /incbin/("u-boot-nodtb.bin");
- type = "standalone";
- os = "U-Boot";
- arch = "arm";
- compression = "none";
- load = <$text_base>;
- };
- optee {
- description = "OP-TEE";
- data = /incbin/("$TEE");
- type = "firmware";
- arch = "arm";
- os = "tee";
- compression = "none";
- load = <$tee_base>;
- entry = <$tee_base>;
- };
- fdt {
- description = "$(basename $dtname .dtb)";
- data = /incbin/("$dtname");
- type = "flat_dt";
- compression = "none";
- };
-__HEADER_EOF
-
-cat << __CONF_HEADER_EOF
- };
-
- configurations {
- default = "conf";
- conf {
- description = "$(basename $dtname .dtb)";
- firmware = "optee";
- loadables = "uboot";
- fdt = "fdt";
- };
-__CONF_HEADER_EOF
-
-cat << __ITS_EOF
- };
-};
-__ITS_EOF
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (22 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 25/27] x86: chromebook_link64: Correct the image layout Simon Glass
` (29 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
This causes conflicts on chromebook_link64. Move it to after U-Boot where
there should be plenty of space.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/x86/dts/u-boot.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index f0f8c71761..1e0a985b43 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -92,6 +92,8 @@
u-boot-dtb {
};
#endif
+ fdtmap {
+ };
#ifdef CONFIG_HAVE_X86_FIT
intel-fit {
};
@@ -139,8 +141,6 @@
filename = CONFIG_FSP_FILE_S;
};
#endif
- fdtmap {
- };
#ifdef CONFIG_HAVE_CMC
intel-cmc {
filename = CONFIG_CMC_FILE;
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 25/27] x86: chromebook_link64: Correct the image layout
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (23 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 26/27] x86: chromebook_panther: " Simon Glass
` (28 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present the image layout is not correct, since it uses the SDRAM
address of the 64-bit U-Boot as the ROM address. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
configs/chromebook_link64_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/chromebook_link64_defconfig b/configs/chromebook_link64_defconfig
index 7828e2dc34..772a75a8e7 100644
--- a/configs/chromebook_link64_defconfig
+++ b/configs/chromebook_link64_defconfig
@@ -17,8 +17,10 @@ CONFIG_HAVE_MRC=y
CONFIG_SMP=y
CONFIG_HAVE_VGA_BIOS=y
CONFIG_DEFAULT_DEVICE_TREE="chromebook_link"
+CONFIG_X86_OFFSET_U_BOOT=0xffa00000
CONFIG_FIT=y
CONFIG_SPL_LOAD_FIT=y
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_SHOW_BOOT_PROGRESS=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 26/27] x86: chromebook_panther: Correct the image layout
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (24 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 25/27] x86: chromebook_link64: Correct the image layout Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-19 19:56 ` [PATCH v4 27/27] x86: chromebook_samus_tpl: " Simon Glass
` (27 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
This board does not have microcode but at present that is not supported
by Kconfig nor the binman image layout. Fix both of these.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/x86/Kconfig | 7 ++++++-
arch/x86/dts/u-boot.dtsi | 6 +++++-
configs/chromebox_panther_defconfig | 2 ++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f51b7c9f41..e3ba38cefd 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -594,8 +594,13 @@ config HAVE_REFCODE
Various peripherals may fail to work.
config HAVE_MICROCODE
- bool
+ bool "Board requires a microcode binary"
default y if !FSP_VERSION2
+ help
+ Enable this if the board requires microcode to be loaded on boot.
+ Typically this is handed by the FSP for modern boards, but for
+ some older boards, it must be programmed by U-Boot, and that form
+ part of the image.
config SMP
bool "Enable Symmetric Multiprocessing"
diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index 1e0a985b43..fa8106c8b8 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -75,11 +75,15 @@
u-boot {
offset = <CONFIG_SYS_TEXT_BASE>;
};
-# else
+# elif defined(CONFIG_HAVE_MICROCODE)
/* If there is no SPL then we need to put microcode in U-Boot */
u-boot-with-ucode-ptr {
offset = <CONFIG_X86_OFFSET_U_BOOT>;
};
+# else
+ u-boot-nodtb {
+ offset = <CONFIG_X86_OFFSET_U_BOOT>;
+ };
# endif
#endif
#ifdef CONFIG_HAVE_MICROCODE
diff --git a/configs/chromebox_panther_defconfig b/configs/chromebox_panther_defconfig
index fd87ab262b..35ec3e912b 100644
--- a/configs/chromebox_panther_defconfig
+++ b/configs/chromebox_panther_defconfig
@@ -7,7 +7,9 @@ CONFIG_NR_DRAM_BANKS=8
CONFIG_VENDOR_GOOGLE=y
CONFIG_TARGET_CHROMEBOX_PANTHER=y
CONFIG_HAVE_MRC=y
+# CONFIG_HAVE_MICROCODE is not set
CONFIG_HAVE_VGA_BIOS=y
+CONFIG_X86_OFFSET_U_BOOT=0xffa00000
CONFIG_FIT=y
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 27/27] x86: chromebook_samus_tpl: Correct the image layout
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (25 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 26/27] x86: chromebook_panther: " Simon Glass
@ 2020-07-19 19:56 ` Simon Glass
2020-07-20 1:12 ` [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Bin Meng
` (26 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-19 19:56 UTC (permalink / raw)
To: u-boot
At present there is not enough space for U-Boot due to the EFI loader.
Correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v2)
Changes in v2:
- Add patches to partially migrate rockchip to use binman
configs/chromebook_samus_tpl_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configs/chromebook_samus_tpl_defconfig b/configs/chromebook_samus_tpl_defconfig
index e54a4ff6a6..43622f4182 100644
--- a/configs/chromebook_samus_tpl_defconfig
+++ b/configs/chromebook_samus_tpl_defconfig
@@ -17,8 +17,8 @@ CONFIG_HAVE_MRC=y
CONFIG_HAVE_REFCODE=y
CONFIG_SMP=y
CONFIG_HAVE_VGA_BIOS=y
-CONFIG_X86_OFFSET_U_BOOT=0xfff00000
CONFIG_DEFAULT_DEVICE_TREE="chromebook_samus"
+CONFIG_X86_OFFSET_U_BOOT=0xffee0000
CONFIG_BOOTSTAGE=y
CONFIG_BOOTSTAGE_REPORT=y
CONFIG_SHOW_BOOT_PROGRESS=y
--
2.28.0.rc0.105.gf9edc3c819-goog
^ permalink raw reply related [flat|nested] 94+ messages in thread* [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (26 preceding siblings ...)
2020-07-19 19:56 ` [PATCH v4 27/27] x86: chromebook_samus_tpl: " Simon Glass
@ 2020-07-20 1:12 ` Bin Meng
2020-07-20 3:07 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 27/27] x86: chromebook_samus_tpl: Correct the image layout Simon Glass
` (25 subsequent siblings)
53 siblings, 1 reply; 94+ messages in thread
From: Bin Meng @ 2020-07-20 1:12 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Jul 20, 2020 at 3:56 AM Simon Glass <sjg@chromium.org> wrote:
>
> Rockchip-based Chromebooks support booting from SPI flash. It is annoying
> to have to manually build the SPI image when the SD image is built
> automatically.
>
> This feature is already available for x86 devices, so the existing
> mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
> to be provided to indicate that any required binary blobs are present and
> it is safe to build the ROM.
>
> A new 'mkimage' type is added to binman to support building binaries
> containing mkimagem using a binman definition to configure it. This avoids
> Makefile/shell/Python code to do the same thing.
>
> This series also migrates some rockchip boards to use binman to produce
> their FIT as well, resulting in removing the fit_spl_optee.sh script.
>
> Other archs and the rest of rockchip could be migrated too.
>
> This series uses binman to produce a ROM image on two selected
> Chromebooks, Bob (RK3399) and Jerry (RK3388).
>
> Changes in v4:
> - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> - Update for changes to arch/arm/mach-k3/config.mk
> - Move the .itb output to a separate rockchip-optee.dtsi file
> - Add a check for CONFIG_FIT before building the .its
>
> Changes in v3:
> - Add a comment about CONFIG_SPL_FRAMEWORK
> - Drop rockchip changes which should not be in this patch
> - Move in the rockchip changes mistakenly in the earlier x86 patch
> - Drop use of rk322x.dtsi
> - Add changes to rk3288-u-boot.dtsi instead
> - Drop leftover debugging
It looks you have applied part of the v3 in u-boot-dm, and sent the
remaining patches as v4?
I re-assigned this series to you in patchwork.
Regards,
Bin
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman
2020-07-20 1:12 ` [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Bin Meng
@ 2020-07-20 3:07 ` Simon Glass
2020-07-24 14:48 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-07-20 3:07 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sun, 19 Jul 2020 at 19:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Mon, Jul 20, 2020 at 3:56 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Rockchip-based Chromebooks support booting from SPI flash. It is annoying
> > to have to manually build the SPI image when the SD image is built
> > automatically.
> >
> > This feature is already available for x86 devices, so the existing
> > mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
> > to be provided to indicate that any required binary blobs are present and
> > it is safe to build the ROM.
> >
> > A new 'mkimage' type is added to binman to support building binaries
> > containing mkimagem using a binman definition to configure it. This avoids
> > Makefile/shell/Python code to do the same thing.
> >
> > This series also migrates some rockchip boards to use binman to produce
> > their FIT as well, resulting in removing the fit_spl_optee.sh script.
> >
> > Other archs and the rest of rockchip could be migrated too.
> >
> > This series uses binman to produce a ROM image on two selected
> > Chromebooks, Bob (RK3399) and Jerry (RK3388).
> >
> > Changes in v4:
> > - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
> > - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> > - Update for changes to arch/arm/mach-k3/config.mk
> > - Move the .itb output to a separate rockchip-optee.dtsi file
> > - Add a check for CONFIG_FIT before building the .its
> >
> > Changes in v3:
> > - Add a comment about CONFIG_SPL_FRAMEWORK
> > - Drop rockchip changes which should not be in this patch
> > - Move in the rockchip changes mistakenly in the earlier x86 patch
> > - Drop use of rk322x.dtsi
> > - Add changes to rk3288-u-boot.dtsi instead
> > - Drop leftover debugging
>
> It looks you have applied part of the v3 in u-boot-dm, and sent the
> remaining patches as v4?
>
> I re-assigned this series to you in patchwork.
Yes I applied the binman patches and those that were reviewed.
I am not sure if this shold be an x86 or rockchip series, or perhaps
we just wait until people have had a look.
Regards,
Simon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman
2020-07-20 3:07 ` Simon Glass
@ 2020-07-24 14:48 ` Simon Glass
2020-08-08 11:32 ` Kever Yang
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-07-24 14:48 UTC (permalink / raw)
To: u-boot
Hi Kever (and other Rockchip people),
Are there any more comments on this series? I can pick it up via -dm
but I would like to get more comments if possible. I'd also like to
see if someone can take on removing the other ad-hoc Rockchip script.
Regards,
Simon
On Sun, 19 Jul 2020 at 21:07, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Sun, 19 Jul 2020 at 19:12, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Mon, Jul 20, 2020 at 3:56 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Rockchip-based Chromebooks support booting from SPI flash. It is annoying
> > > to have to manually build the SPI image when the SD image is built
> > > automatically.
> > >
> > > This feature is already available for x86 devices, so the existing
> > > mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
> > > to be provided to indicate that any required binary blobs are present and
> > > it is safe to build the ROM.
> > >
> > > A new 'mkimage' type is added to binman to support building binaries
> > > containing mkimagem using a binman definition to configure it. This avoids
> > > Makefile/shell/Python code to do the same thing.
> > >
> > > This series also migrates some rockchip boards to use binman to produce
> > > their FIT as well, resulting in removing the fit_spl_optee.sh script.
> > >
> > > Other archs and the rest of rockchip could be migrated too.
> > >
> > > This series uses binman to produce a ROM image on two selected
> > > Chromebooks, Bob (RK3399) and Jerry (RK3388).
> > >
> > > Changes in v4:
> > > - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
> > > - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> > > - Update for changes to arch/arm/mach-k3/config.mk
> > > - Move the .itb output to a separate rockchip-optee.dtsi file
> > > - Add a check for CONFIG_FIT before building the .its
> > >
> > > Changes in v3:
> > > - Add a comment about CONFIG_SPL_FRAMEWORK
> > > - Drop rockchip changes which should not be in this patch
> > > - Move in the rockchip changes mistakenly in the earlier x86 patch
> > > - Drop use of rk322x.dtsi
> > > - Add changes to rk3288-u-boot.dtsi instead
> > > - Drop leftover debugging
> >
> > It looks you have applied part of the v3 in u-boot-dm, and sent the
> > remaining patches as v4?
> >
> > I re-assigned this series to you in patchwork.
>
> Yes I applied the binman patches and those that were reviewed.
>
> I am not sure if this shold be an x86 or rockchip series, or perhaps
> we just wait until people have had a look.
>
> Regards,
> Simon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman
2020-07-24 14:48 ` Simon Glass
@ 2020-08-08 11:32 ` Kever Yang
2020-08-08 13:28 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Kever Yang @ 2020-08-08 11:32 UTC (permalink / raw)
To: u-boot
Hi Simon,
??? Sorry for reply late.
??? It's OK to use binman to generate firmware for 32bit SoCs which
only have optee.bin
which is easy replacement.
I still have some confuse(I'm sure I've ask before but I can't find now,
sorry):
- to support feature like this(Jagan asked in anoter thread):
??? tools/mkimage -n rk3399 -T rksd -d
tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img
??? Note that there are 2 inputs instead of 1 so that we can get
correct size for each of them in the header.
- bl31.elf parse which including multi binaries, we need to split them
first, and also sign them into u-boot.itb
arch/arm/mach-rockchip/make_fit_atf.py
??? If the feature in this script can be replaced by binman, them all
the rockchip platform can use binman.
- For rockchip platform we need separate idbloader.img and u-boot.itb
??? In many case, people don't want to erase the space which are not
the space for idbloader.img and u-boot.itb
??? eg. space at offset 0 is gpt, there should be available gpt in the
beginning and end of disk;
??? space between idbloader and u-boot.itb may have some useful vendor
data;
??? I can have a try if you can help give me some guide about how to
implement these features with binman,
them I can make it available to all other rockchip boards if all these
features are available.
Thanks,
- Kever
On 2020/7/24 ??10:48, Simon Glass wrote:
> Hi Kever (and other Rockchip people),
>
> Are there any more comments on this series? I can pick it up via -dm
> but I would like to get more comments if possible. I'd also like to
> see if someone can take on removing the other ad-hoc Rockchip script.
>
> Regards,
> Simon
>
>
> On Sun, 19 Jul 2020 at 21:07, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On Sun, 19 Jul 2020 at 19:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Mon, Jul 20, 2020 at 3:56 AM Simon Glass <sjg@chromium.org> wrote:
>>>> Rockchip-based Chromebooks support booting from SPI flash. It is annoying
>>>> to have to manually build the SPI image when the SD image is built
>>>> automatically.
>>>>
>>>> This feature is already available for x86 devices, so the existing
>>>> mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
>>>> to be provided to indicate that any required binary blobs are present and
>>>> it is safe to build the ROM.
>>>>
>>>> A new 'mkimage' type is added to binman to support building binaries
>>>> containing mkimagem using a binman definition to configure it. This avoids
>>>> Makefile/shell/Python code to do the same thing.
>>>>
>>>> This series also migrates some rockchip boards to use binman to produce
>>>> their FIT as well, resulting in removing the fit_spl_optee.sh script.
>>>>
>>>> Other archs and the rest of rockchip could be migrated too.
>>>>
>>>> This series uses binman to produce a ROM image on two selected
>>>> Chromebooks, Bob (RK3399) and Jerry (RK3388).
>>>>
>>>> Changes in v4:
>>>> - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
>>>> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
>>>> - Update for changes to arch/arm/mach-k3/config.mk
>>>> - Move the .itb output to a separate rockchip-optee.dtsi file
>>>> - Add a check for CONFIG_FIT before building the .its
>>>>
>>>> Changes in v3:
>>>> - Add a comment about CONFIG_SPL_FRAMEWORK
>>>> - Drop rockchip changes which should not be in this patch
>>>> - Move in the rockchip changes mistakenly in the earlier x86 patch
>>>> - Drop use of rk322x.dtsi
>>>> - Add changes to rk3288-u-boot.dtsi instead
>>>> - Drop leftover debugging
>>> It looks you have applied part of the v3 in u-boot-dm, and sent the
>>> remaining patches as v4?
>>>
>>> I re-assigned this series to you in patchwork.
>> Yes I applied the binman patches and those that were reviewed.
>>
>> I am not sure if this shold be an x86 or rockchip series, or perhaps
>> we just wait until people have had a look.
>>
>> Regards,
>> Simon
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman
2020-08-08 11:32 ` Kever Yang
@ 2020-08-08 13:28 ` Simon Glass
0 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-08-08 13:28 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Sat, 8 Aug 2020 at 05:32, Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Hi Simon,
>
> Sorry for reply late.
>
> It's OK to use binman to generate firmware for 32bit SoCs which
> only have optee.bin
>
> which is easy replacement.
>
> I still have some confuse(I'm sure I've ask before but I can't find now,
> sorry):
>
> - to support feature like this(Jagan asked in anoter thread):
>
> tools/mkimage -n rk3399 -T rksd -d
> tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader.img
>
> Note that there are 2 inputs instead of 1 so that we can get
> correct size for each of them in the header.
What I suggest is to add two subnodes to the mkimage node, one with
each file. At present this means to combine the two files into one and
pass them to mkimage with '-d'. So perhaps add a new property to the
mkimage node, like 'multi-input' and change mkimage.py to read that
property and behave differently in ObtainContents() in that case.
>
> - bl31.elf parse which including multi binaries, we need to split them
> first, and also sign them into u-boot.itb
See elf.py which has Elf parsing. The cbfs_util.py file calls
DecodeElf() which should be helpful. You can create a new rockchip-atf
type to do what you want, if the Rockchip code is speical.
>
> arch/arm/mach-rockchip/make_fit_atf.py
>
> If the feature in this script can be replaced by binman, them all
> the rockchip platform can use binman.
Yes and it is written in Python too, so some of the code can move over
into binman etypes.
>
> - For rockchip platform we need separate idbloader.img and u-boot.itb
>
> In many case, people don't want to erase the space which are not
> the space for idbloader.img and u-boot.itb
>
> eg. space at offset 0 is gpt, there should be available gpt in the
> beginning and end of disk;
>
> space between idbloader and u-boot.itb may have some useful vendor
> data;
Well you can perhaps output an image that has everything in one file
as well as a few other files that contain the pieces. Then you can
cover both options.
>
> I can have a try if you can help give me some guide about how to
> implement these features with binman,
>
> them I can make it available to all other rockchip boards if all these
> features are available.
That sounds good. I am happy to help!
Regards,
Simon
>
> Thanks,
> - Kever
> On 2020/7/24 ??10:48, Simon Glass wrote:
> > Hi Kever (and other Rockchip people),
> >
> > Are there any more comments on this series? I can pick it up via -dm
> > but I would like to get more comments if possible. I'd also like to
> > see if someone can take on removing the other ad-hoc Rockchip script.
> >
> > Regards,
> > Simon
> >
> >
> > On Sun, 19 Jul 2020 at 21:07, Simon Glass <sjg@chromium.org> wrote:
> >> Hi Bin,
> >>
> >> On Sun, 19 Jul 2020 at 19:12, Bin Meng <bmeng.cn@gmail.com> wrote:
> >>> Hi Simon,
> >>>
> >>> On Mon, Jul 20, 2020 at 3:56 AM Simon Glass <sjg@chromium.org> wrote:
> >>>> Rockchip-based Chromebooks support booting from SPI flash. It is annoying
> >>>> to have to manually build the SPI image when the SD image is built
> >>>> automatically.
> >>>>
> >>>> This feature is already available for x86 devices, so the existing
> >>>> mechanism is reused. Briefly, this allows a BUILD_ROM environment variable
> >>>> to be provided to indicate that any required binary blobs are present and
> >>>> it is safe to build the ROM.
> >>>>
> >>>> A new 'mkimage' type is added to binman to support building binaries
> >>>> containing mkimagem using a binman definition to configure it. This avoids
> >>>> Makefile/shell/Python code to do the same thing.
> >>>>
> >>>> This series also migrates some rockchip boards to use binman to produce
> >>>> their FIT as well, resulting in removing the fit_spl_optee.sh script.
> >>>>
> >>>> Other archs and the rest of rockchip could be migrated too.
> >>>>
> >>>> This series uses binman to produce a ROM image on two selected
> >>>> Chromebooks, Bob (RK3399) and Jerry (RK3388).
> >>>>
> >>>> Changes in v4:
> >>>> - Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
> >>>> - Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
> >>>> - Update for changes to arch/arm/mach-k3/config.mk
> >>>> - Move the .itb output to a separate rockchip-optee.dtsi file
> >>>> - Add a check for CONFIG_FIT before building the .its
> >>>>
> >>>> Changes in v3:
> >>>> - Add a comment about CONFIG_SPL_FRAMEWORK
> >>>> - Drop rockchip changes which should not be in this patch
> >>>> - Move in the rockchip changes mistakenly in the earlier x86 patch
> >>>> - Drop use of rk322x.dtsi
> >>>> - Add changes to rk3288-u-boot.dtsi instead
> >>>> - Drop leftover debugging
> >>> It looks you have applied part of the v3 in u-boot-dm, and sent the
> >>> remaining patches as v4?
> >>>
> >>> I re-assigned this series to you in patchwork.
> >> Yes I applied the binman patches and those that were reviewed.
> >>
> >> I am not sure if this shold be an x86 or rockchip series, or perhaps
> >> we just wait until people have had a look.
> >>
> >> Regards,
> >> Simon
> >
>
>
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 27/27] x86: chromebook_samus_tpl: Correct the image layout
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (27 preceding siblings ...)
2020-07-20 1:12 ` [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Bin Meng
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 26/27] x86: chromebook_panther: " Simon Glass
` (24 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
At present there is not enough space for U-Boot due to the EFI loader.
Correct this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v2)
Changes in v2:
- Add patches to partially migrate rockchip to use binman
configs/chromebook_samus_tpl_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 26/27] x86: chromebook_panther: Correct the image layout
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (28 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 27/27] x86: chromebook_samus_tpl: Correct the image layout Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 25/27] x86: chromebook_link64: " Simon Glass
` (23 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
This board does not have microcode but at present that is not supported
by Kconfig nor the binman image layout. Fix both of these.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/x86/Kconfig | 7 ++++++-
arch/x86/dts/u-boot.dtsi | 6 +++++-
configs/chromebox_panther_defconfig | 2 ++
3 files changed, 13 insertions(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 25/27] x86: chromebook_link64: Correct the image layout
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (29 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 26/27] x86: chromebook_panther: " Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs Simon Glass
` (22 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
At present the image layout is not correct, since it uses the SDRAM
address of the 64-bit U-Boot as the ROM address. Fix this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
configs/chromebook_link64_defconfig | 2 ++
1 file changed, 2 insertions(+)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (30 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 25/27] x86: chromebook_link64: " Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script Simon Glass
` (21 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
This causes conflicts on chromebook_link64. Move it to after U-Boot where
there should be plenty of space.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/x86/dts/u-boot.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (31 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 24/27] x86: Move the fdtmap away from the binary blobs Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 22/27] rockchip: Convert evb-rk3229 over to use binman Simon Glass
` (20 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
Now that all board use binman instead of this script, drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/arm/mach-rockchip/fit_spl_optee.sh | 84 -------------------------
1 file changed, 84 deletions(-)
delete mode 100755 arch/arm/mach-rockchip/fit_spl_optee.sh
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 22/27] rockchip: Convert evb-rk3229 over to use binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (32 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 23/27] rockchip: Drop the fit_spl_optee.sh script Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 21/27] rockchip: Convert evb-rk3288 " Simon Glass
` (19 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Drop leftover debugging
configs/evb-rk3229_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 21/27] rockchip: Convert evb-rk3288 over to use binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (33 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 22/27] rockchip: Convert evb-rk3229 over to use binman Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR Simon Glass
` (18 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
At present this board uses a custom script to produce the .its file.
Update it to use binman instead. Binman can create all the images that
are needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
- Move the .itb output to a separate rockchip-optee.dtsi file
- Add a check for CONFIG_FIT before building the .its
Changes in v3:
- Drop use of rk322x.dtsi
- Add changes to rk3288-u-boot.dtsi instead
Kconfig | 2 +-
arch/arm/dts/rk3288-u-boot.dtsi | 1 +
arch/arm/dts/rockchip-optee.dtsi | 64 +++++++++++++++++++++++++++
arch/arm/mach-rockchip/rk3288/Kconfig | 1 +
configs/evb-rk3288_defconfig | 2 +-
5 files changed, 68 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/rockchip-optee.dtsi
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (34 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 21/27] rockchip: Convert evb-rk3288 " Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 19/27] Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty Simon Glass
` (17 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
This option is used to run arch-specific shell scripts which produce .its
files which are used to produce FIT images. We already have binman which
is designed to produce firmware images. It is more powerful and has tests.
So this option should be deprecated and not used. Existing uses should be
migrated.
Mentions of this in code reviews over the last year or so do not seem to
have resulted in action, and things are getting worse.
So let's add a warning.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Makefile | 9 +++++++++
1 file changed, 9 insertions(+)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 19/27] Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (35 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 20/27] Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage Simon Glass
` (16 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
At present we use the empty string to indicate that there is no FIT
generator, but this doesn't allow an individual board to undefine it.
Create a separate bool instead.
Update the config of the boards which currently have an empty string.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Kconfig | 6 +++++-
Makefile | 2 +-
configs/am335x_evm_defconfig | 1 +
configs/am335x_hs_evm_defconfig | 1 +
configs/am335x_hs_evm_uart_defconfig | 1 +
configs/am43xx_evm_defconfig | 1 +
configs/am43xx_evm_rtconly_defconfig | 1 +
configs/am43xx_evm_usbhost_boot_defconfig | 1 +
configs/am43xx_hs_evm_defconfig | 1 +
configs/am57xx_evm_defconfig | 1 +
configs/am57xx_hs_evm_defconfig | 1 +
configs/am57xx_hs_evm_usb_defconfig | 1 +
configs/am65x_evm_a53_defconfig | 1 +
configs/am65x_evm_r5_defconfig | 1 +
configs/am65x_hs_evm_a53_defconfig | 1 +
configs/am65x_hs_evm_r5_defconfig | 1 +
configs/dh_imx6_defconfig | 1 +
configs/display5_defconfig | 1 +
configs/display5_factory_defconfig | 1 +
configs/dra7xx_evm_defconfig | 1 +
configs/dra7xx_hs_evm_defconfig | 1 +
configs/dra7xx_hs_evm_usb_defconfig | 1 +
configs/imx6qdl_icore_mipi_defconfig | 1 +
configs/imx6qdl_icore_mmc_defconfig | 1 +
configs/imx6qdl_icore_rqs_defconfig | 1 +
configs/j721e_evm_a72_defconfig | 1 +
configs/j721e_evm_r5_defconfig | 1 +
configs/j721e_hs_evm_a72_defconfig | 1 +
configs/j721e_hs_evm_r5_defconfig | 1 +
configs/ls1046ardb_qspi_spl_defconfig | 1 +
configs/mccmon6_nor_defconfig | 1 +
configs/mccmon6_sd_defconfig | 1 +
configs/mx6sabreauto_defconfig | 1 +
configs/mx6sabresd_defconfig | 1 +
configs/pico-imx6_defconfig | 1 +
configs/qemu-x86_64_defconfig | 1 +
configs/sandbox_spl_defconfig | 1 +
configs/socfpga_arria10_defconfig | 1 +
configs/stm32mp15_dhcom_basic_defconfig | 1 +
configs/stm32mp15_dhcor_basic_defconfig | 1 +
configs/wandboard_defconfig | 1 +
configs/xilinx_zynq_virt_defconfig | 1 +
42 files changed, 46 insertions(+), 2 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (36 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 19/27] Makefile: Allow CONFIG_SPL_FIT_GENERATOR to be empty Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later Simon Glass
` (15 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
Fix this line which is over the limit.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (37 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 18/27] Makefile: Fix a long line in cmd_mkfitimage Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 16/27] mediatek: Makefile: Drop explicit targets built by binman Simon Glass
` (14 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
At present this is checked before the config has been loaded by the
Makefile, so it doesn't work.
Move the check to later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 16/27] mediatek: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (38 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 17/27] Makefile: Move CONFIG_TOOLS_DEBUG check to later Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 15/27] tegra: " Simon Glass
` (13 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
On mediatek various files that need to be created by binman. It does not
make sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Also update the binman definition so that idbloader.img is only needed
when SPL is actually being used.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Move in the rockchip changes mistakenly in the earlier x86 patch
Makefile | 24 ++++++++++++++++--------
arch/arm/dts/rockchip-u-boot.dtsi | 2 ++
2 files changed, 18 insertions(+), 8 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 15/27] tegra: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (39 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 16/27] mediatek: Makefile: Drop explicit targets built by binman Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM Simon Glass
` (12 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
On tegra various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
This avoid sprinkling the Makefile with arch-specific code.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 12 ------------
1 file changed, 12 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (40 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 15/27] tegra: " Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-07-28 18:57 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman Simon Glass
` (11 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
This Kconfig is not needed anymore since U-Boot will build the ROM if the
required binary blobs exist.
The BUILD_ROM environment variable used to request that the ROM be built.
Now this always happens if the required binary blobs are available. Update
it to mean that U-Boot should fail if the ROM cannot be built. This
behaviour should be compatible with how it used to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
Kconfig | 7 +++++--
Makefile | 3 ++-
configs/qemu-x86_64_defconfig | 1 -
configs/qemu-x86_defconfig | 1 -
4 files changed, 7 insertions(+), 5 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (41 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 13/27] x86: Drop CONFIG_BUILD_ROM and repurpose BUILD_ROM Simon Glass
@ 2020-07-28 18:57 ` Simon Glass
2020-08-05 17:13 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman - BREAKS NETWORK ON SUNXI Heinrich Schuchardt
2020-07-28 18:58 ` [PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed Simon Glass
` (10 subsequent siblings)
53 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:57 UTC (permalink / raw)
To: u-boot
On x86 various files that need to be created by binman. It does not make
sense to enumerate these in the Makefile. They are described in the
configuration (devicetree) for each board and we can simply run binman
(always) to generate them.
Update the Makefile to have a separate, final step which runs binman,
once all input dependencies are present.
This avoid sprinkling the Makefile with arch-specific code.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Drop rockchip changes which should not be in this patch
Makefile | 63 +++++++++++++-------------------------------------------
1 file changed, 14 insertions(+), 49 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman - BREAKS NETWORK ON SUNXI
2020-07-28 18:57 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman Simon Glass
@ 2020-08-05 17:13 ` Heinrich Schuchardt
2020-08-05 17:30 ` Heinrich Schuchardt
0 siblings, 1 reply; 94+ messages in thread
From: Heinrich Schuchardt @ 2020-08-05 17:13 UTC (permalink / raw)
To: u-boot
On 28.07.20 20:57, Simon Glass wrote:
> On x86 various files that need to be created by binman. It does not make
> sense to enumerate these in the Makefile. They are described in the
> configuration (devicetree) for each board and we can simply run binman
> (always) to generate them.
>
> Update the Makefile to have a separate, final step which runs binman,
> once all input dependencies are present.
>
> This avoid sprinkling the Makefile with arch-specific code.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> (no changes since v3)
>
> Changes in v3:
> - Drop rockchip changes which should not be in this patch
>
> Makefile | 63 +++++++++++++-------------------------------------------
> 1 file changed, 14 insertions(+), 49 deletions(-)
>
> Applied to u-boot-dm, thanks!
>
Dear Simon,
since this patch merged as 42b18df80fdb network is broken on the
pine64-lts_defconfig:
Net: phy interface7
Could not get PHY for ethernet at 1c30000: addr 1
No ethernet found.
=> dhcp
phy interface7
mdio_register: non unique device name 'ethernet at 1c30000'
Could not get PHY for ethernet at 1c30000: addr 1
Please, provide a fix.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman - BREAKS NETWORK ON SUNXI
2020-08-05 17:13 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman - BREAKS NETWORK ON SUNXI Heinrich Schuchardt
@ 2020-08-05 17:30 ` Heinrich Schuchardt
2020-08-05 18:23 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Heinrich Schuchardt @ 2020-08-05 17:30 UTC (permalink / raw)
To: u-boot
On 05.08.20 19:13, Heinrich Schuchardt wrote:
> On 28.07.20 20:57, Simon Glass wrote:
>> On x86 various files that need to be created by binman. It does not make
>> sense to enumerate these in the Makefile. They are described in the
>> configuration (devicetree) for each board and we can simply run binman
>> (always) to generate them.
>>
>> Update the Makefile to have a separate, final step which runs binman,
>> once all input dependencies are present.
>>
>> This avoid sprinkling the Makefile with arch-specific code.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> (no changes since v3)
>>
>> Changes in v3:
>> - Drop rockchip changes which should not be in this patch
>>
>> Makefile | 63 +++++++++++++-------------------------------------------
>> 1 file changed, 14 insertions(+), 49 deletions(-)
>>
>> Applied to u-boot-dm, thanks!
>>
>
> Dear Simon,
>
> since this patch merged as 42b18df80fdb network is broken on the
> pine64-lts_defconfig:
>
> Net: phy interface7
> Could not get PHY for ethernet at 1c30000: addr 1
> No ethernet found.
>
> => dhcp
> phy interface7
> mdio_register: non unique device name 'ethernet at 1c30000'
> Could not get PHY for ethernet at 1c30000: addr 1
>
> Please, provide a fix.
The last build steps with your patch are:
cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O .
-m --allow-missing -I . -I . -I ./board/sunxi
The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is
broken.
Nowhere in the commit message you state that you want to run binman on
sunxi boards.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman - BREAKS NETWORK ON SUNXI
2020-08-05 17:30 ` Heinrich Schuchardt
@ 2020-08-05 18:23 ` Simon Glass
2020-08-05 18:25 ` Simon Glass
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-05 18:23 UTC (permalink / raw)
To: u-boot
Hi Heinrich,
On Wed, 5 Aug 2020 at 11:35, Heinrich Schuchardt <xypron.debian@gmx.de> wrote:
>
> On 05.08.20 19:13, Heinrich Schuchardt wrote:
> > On 28.07.20 20:57, Simon Glass wrote:
> >> On x86 various files that need to be created by binman. It does not make
> >> sense to enumerate these in the Makefile. They are described in the
> >> configuration (devicetree) for each board and we can simply run binman
> >> (always) to generate them.
> >>
> >> Update the Makefile to have a separate, final step which runs binman,
> >> once all input dependencies are present.
> >>
> >> This avoid sprinkling the Makefile with arch-specific code.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >>
> >> (no changes since v3)
> >>
> >> Changes in v3:
> >> - Drop rockchip changes which should not be in this patch
> >>
> >> Makefile | 63 +++++++++++++-------------------------------------------
> >> 1 file changed, 14 insertions(+), 49 deletions(-)
> >>
> >> Applied to u-boot-dm, thanks!
> >>
> >
> > Dear Simon,
> >
> > since this patch merged as 42b18df80fdb network is broken on the
> > pine64-lts_defconfig:
> >
> > Net: phy interface7
> > Could not get PHY for ethernet at 1c30000: addr 1
> > No ethernet found.
> >
> > => dhcp
> > phy interface7
> > mdio_register: non unique device name 'ethernet at 1c30000'
> > Could not get PHY for ethernet at 1c30000: addr 1
> >
> > Please, provide a fix.
>
> The last build steps with your patch are:
>
> cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
> ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O .
> -m --allow-missing -I . -I . -I ./board/sunxi
>
> The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is
> broken.
>
> Nowhere in the commit message you state that you want to run binman on
> sunxi boards.
Please see the existing thread with Andre. I'm going to take another
look at this later today.
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman - BREAKS NETWORK ON SUNXI
2020-08-05 18:23 ` Simon Glass
@ 2020-08-05 18:25 ` Simon Glass
2020-08-07 4:21 ` sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman) Samuel Holland
0 siblings, 1 reply; 94+ messages in thread
From: Simon Glass @ 2020-08-05 18:25 UTC (permalink / raw)
To: u-boot
Hi Heinrich,
On Wed, 5 Aug 2020 at 12:23, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Heinrich,
>
> On Wed, 5 Aug 2020 at 11:35, Heinrich Schuchardt <xypron.debian@gmx.de> wrote:
> >
> > On 05.08.20 19:13, Heinrich Schuchardt wrote:
> > > On 28.07.20 20:57, Simon Glass wrote:
> > >> On x86 various files that need to be created by binman. It does not make
> > >> sense to enumerate these in the Makefile. They are described in the
> > >> configuration (devicetree) for each board and we can simply run binman
> > >> (always) to generate them.
> > >>
> > >> Update the Makefile to have a separate, final step which runs binman,
> > >> once all input dependencies are present.
> > >>
> > >> This avoid sprinkling the Makefile with arch-specific code.
> > >>
> > >> Signed-off-by: Simon Glass <sjg@chromium.org>
> > >> ---
> > >>
> > >> (no changes since v3)
> > >>
> > >> Changes in v3:
> > >> - Drop rockchip changes which should not be in this patch
> > >>
> > >> Makefile | 63 +++++++++++++-------------------------------------------
> > >> 1 file changed, 14 insertions(+), 49 deletions(-)
> > >>
> > >> Applied to u-boot-dm, thanks!
> > >>
> > >
> > > Dear Simon,
> > >
> > > since this patch merged as 42b18df80fdb network is broken on the
> > > pine64-lts_defconfig:
> > >
> > > Net: phy interface7
> > > Could not get PHY for ethernet at 1c30000: addr 1
> > > No ethernet found.
> > >
> > > => dhcp
> > > phy interface7
> > > mdio_register: non unique device name 'ethernet at 1c30000'
> > > Could not get PHY for ethernet at 1c30000: addr 1
> > >
> > > Please, provide a fix.
> >
> > The last build steps with your patch are:
> >
> > cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
> > ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O .
> > -m --allow-missing -I . -I . -I ./board/sunxi
> >
> > The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is
> > broken.
> >
> > Nowhere in the commit message you state that you want to run binman on
> > sunxi boards.
BTW the commit does not change this. Sunxi boards were already using binman.
>
> Please see the existing thread with Andre. I'm going to take another
> look at this later today.
- simon
^ permalink raw reply [flat|nested] 94+ messages in thread
* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-08-05 18:25 ` Simon Glass
@ 2020-08-07 4:21 ` Samuel Holland
2020-08-07 15:44 ` Simon Glass
2020-08-07 16:23 ` Simon Glass
0 siblings, 2 replies; 94+ messages in thread
From: Samuel Holland @ 2020-08-07 4:21 UTC (permalink / raw)
To: u-boot
On 8/5/20 1:25 PM, Simon Glass wrote:
>>> The last build steps with your patch are:
>>>
>>> cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
>>> ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O .
>>> -m --allow-missing -I . -I . -I ./board/sunxi
>>>
>>> The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is
>>> broken.
>>>
>>> Nowhere in the commit message you state that you want to run binman on
>>> sunxi boards.
>
> BTW the commit does not change this. Sunxi boards were already using binman.
That is only half true. Before this commit, binman was *not* run for sunxi when
CONFIG_ARM64=y. 32-bit boards used binman with u-boot.img, and 64-bit boards
used mksunxi_fit_atf.sh to generate a FIT.
Since converting mksunxi_fit_atf.sh to the binman equivalent is nontrivial (how
do you expect to get environment variables into the device tree?), binman should
be disabled for sunxi with CONFIG_ARM64=y.
A workaround for those affected by this breakage: instead of running `make` with
no goals, run `make u-boot-sunxi-with-spl.bin` or the recently-added `make
inputs` to skip the binman step.
Regards,
Samuel
^ permalink raw reply [flat|nested] 94+ messages in thread
* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-08-07 4:21 ` sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman) Samuel Holland
@ 2020-08-07 15:44 ` Simon Glass
2020-08-07 16:23 ` Simon Glass
1 sibling, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-08-07 15:44 UTC (permalink / raw)
To: u-boot
Hi,
On Thu, 6 Aug 2020 at 22:20, Samuel Holland <samuel@sholland.org> wrote:
>
> On 8/5/20 1:25 PM, Simon Glass wrote:
> >>> The last build steps with your patch are:
> >>>
> >>> cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
> >>> ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O .
> >>> -m --allow-missing -I . -I . -I ./board/sunxi
> >>>
> >>> The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is
> >>> broken.
> >>>
> >>> Nowhere in the commit message you state that you want to run binman on
> >>> sunxi boards.
> >
> > BTW the commit does not change this. Sunxi boards were already using binman.
>
> That is only half true. Before this commit, binman was *not* run for sunxi when
> CONFIG_ARM64=y. 32-bit boards used binman with u-boot.img, and 64-bit boards
> used mksunxi_fit_atf.sh to generate a FIT.
>
> Since converting mksunxi_fit_atf.sh to the binman equivalent is nontrivial (how
> do you expect to get environment variables into the device tree?), binman should
> be disabled for sunxi with CONFIG_ARM64=y.
>
> A workaround for those affected by this breakage: instead of running `make` with
> no goals, run `make u-boot-sunxi-with-spl.bin` or the recently-added `make
> inputs` to skip the binman step.
It's a bit confusing, but the problem is that binman does create that
file, overwriting what is there, but the binman definition lacks ATF.
So I think a little hack can fix it for now. Will send a patch.
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman)
2020-08-07 4:21 ` sunxi/arm64 build broken (was: [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman) Samuel Holland
2020-08-07 15:44 ` Simon Glass
@ 2020-08-07 16:23 ` Simon Glass
1 sibling, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-08-07 16:23 UTC (permalink / raw)
To: u-boot
Hi Samuel,
On Thu, 6 Aug 2020 at 22:20, Samuel Holland <samuel@sholland.org> wrote:
>
> On 8/5/20 1:25 PM, Simon Glass wrote:
> >>> The last build steps with your patch are:
> >>>
> >>> cat spl/sunxi-spl.bin u-boot.itb > u-boot-sunxi-with-spl.bin
> >>> ./tools/binman/binman --toolpath ./tools build -u -d u-boot.dtb -O .
> >>> -m --allow-missing -I . -I . -I ./board/sunxi
> >>>
> >>> The file before binman is ok. After binman u-boot-sunxi-with-spl.bin is
> >>> broken.
> >>>
> >>> Nowhere in the commit message you state that you want to run binman on
> >>> sunxi boards.
> >
> > BTW the commit does not change this. Sunxi boards were already using binman.
>
> That is only half true. Before this commit, binman was *not* run for sunxi when
> CONFIG_ARM64=y. 32-bit boards used binman with u-boot.img, and 64-bit boards
> used mksunxi_fit_atf.sh to generate a FIT.
Yes that's right. CONFIG_BINMAN was enabled but binman was not executed.
>
> Since converting mksunxi_fit_atf.sh to the binman equivalent is nontrivial (how
> do you expect to get environment variables into the device tree?), binman should
> be disabled for sunxi with CONFIG_ARM64=y.
It shouldn't be too hard. See commit a32dd071485 for an example.
I don't think you need environment variables...but if so, what for?
The BL31_ADDR should really move to Kconfig I think, and BL31 can be
used to pass another -I parameter to binman.
The only new thing I can see is needing to create dtb and config nodes
on the fly. How about a new sunxi-fit etype which subclasses Entry_fit
and expands _ReadSubnode() to generate the extra nodes and properties?
Regards,
SImon
^ permalink raw reply [flat|nested] 94+ messages in thread
* [PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (42 preceding siblings ...)
2020-07-28 18:57 ` [PATCH v4 12/27] x86: Makefile: Drop explicit targets built by binman Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y Simon Glass
` (9 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Quite a few boards using this SoC family don't use binman, yet
CONFIG_BINMAN is enabled for all of them. But the option should only be
enabled if we expect binman to produce an image. Calling binman when the
device tree is missing, etc. will cause failer.
Add a condition so that CONFIG_BINMAN is only enabled as needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (43 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 11/27] powerpc: mpc85xx: Only enable binman when it is needed Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs Simon Glass
` (8 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
When binman is in use, most of the targets built by the Makefile are
inputs to binman. We then need a final rule to run binman to produce the
final outputs.
Rename the variable to indicate this, and add a new 'inputs' target.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v4:
- Update for changes to arch/arm/mach-k3/config.mk
Makefile | 60 +++++++++++++++++---------------
arch/arm/config.mk | 10 +++---
arch/arm/mach-at91/config.mk | 2 +-
arch/arm/mach-davinci/config.mk | 2 +-
arch/arm/mach-k3/config.mk | 10 +++---
arch/arm/mach-keystone/config.mk | 4 +--
arch/arm/mach-omap2/config.mk | 28 +++++++--------
arch/arm/mach-rmobile/Makefile | 2 +-
arch/arm/mach-stm32mp/config.mk | 4 +--
board/BuR/brppt1/config.mk | 4 +--
board/BuR/brppt2/config.mk | 4 +--
board/BuR/brsmarc1/config.mk | 6 ++--
board/imgtec/boston/config.mk | 2 +-
board/intel/edison/config.mk | 2 +-
scripts/Makefile.spl | 24 ++++++-------
tools/binman/README | 2 +-
16 files changed, 85 insertions(+), 81 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (44 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 10/27] Makefile: Rename ALL-y to INPUTS-y Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 08/27] tegra: Drop the unused non-binman code Simon Glass
` (7 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
At present only the ARMv7 tegra SoCs actually use binman to create an
image. Change the config to reflect this, since otherwise running binman
will produce an error.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/mach-tegra/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 08/27] tegra: Drop the unused non-binman code
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (45 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 09/27] tegra: Don't enable binman on ARMv8 SoCs Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob Simon Glass
` (6 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
This has been in the Makefile long enough to ensure migration is complete.
Drop it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
Makefile | 16 +---------------
1 file changed, 1 insertion(+), 15 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (46 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 08/27] tegra: Drop the unused non-binman code Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry Simon Glass
` (5 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
produces a ROM for bob.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
- Use CONFIG_ROCKCHIP_SPI_IMAGE to select the image
arch/arm/dts/rk3399-gru-u-boot.dtsi | 4 ++++
arch/arm/dts/rk3399-gru.dtsi | 2 +-
arch/arm/dts/rk3399-u-boot.dtsi | 27 +++++++++++++++++++++++++++
arch/arm/mach-rockchip/rk3399/Kconfig | 2 ++
4 files changed, 34 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (47 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 07/27] rockchip: Enable building a SPI ROM image on bob Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting Simon Glass
` (4 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Add a simple binman config and enable CONFIG_HAS_ROM so that U-Boot
produces a ROM for jerry.
Change the binman image definition to support multiple images, since it
may be used to build both u-boot-rockchip.bin and u-boot.rom
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v4:
- Add a new CONFIG_ROCKCHIP_SPI_IMAGE to control SPI-image generation
arch/arm/dts/rk3288-u-boot.dtsi | 24 ++++++++++++++++++++++++
arch/arm/dts/rockchip-u-boot.dtsi | 8 +++++++-
arch/arm/mach-rockchip/Kconfig | 9 +++++++++
arch/arm/mach-rockchip/rk3288/Kconfig | 2 ++
4 files changed, 42 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (48 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 06/27] rockchip: Enable building a SPI ROM image on jerry Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 04/27] rockchip: jerry: Add serial support Simon Glass
` (3 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Update the config for chromebook_bob to support booting from SPI flash.
The existing SPL size is too small since ATF is needed, so double it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/chromebook_bob_defconfig | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 04/27] rockchip: jerry: Add serial support
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (49 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 05/27] rockchip: bob: Support SPI-flash booting Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards Simon Glass
` (2 subsequent siblings)
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
This option allows the serial console to work correctly. Add it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/chromebook_jerry_defconfig | 1 +
1 file changed, 1 insertion(+)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (50 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 04/27] rockchip: jerry: Add serial support Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot Simon Glass
2020-07-28 18:58 ` [PATCH v4 01/27] x86: Change how selection of ROMs works Simon Glass
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Some non-x86 devices can use SPI flash to boot and need to produce images
of a fixed size to program the flash.
Add a way to handle this for non-x86 boards.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v3)
Changes in v3:
- Add a comment about CONFIG_SPL_FRAMEWORK
Makefile | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (51 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 03/27] Makefile: Allow building .rom files for non-x86 boards Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
2020-07-28 18:58 ` [PATCH v4 01/27] x86: Change how selection of ROMs works Simon Glass
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Bob is a Chromebook and can boot from SPI flash. Add it to the condition
check for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
arch/arm/mach-rockchip/spl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread* [PATCH v4 01/27] x86: Change how selection of ROMs works
2020-07-19 19:55 [PATCH v4 00/27] rockchip: x86: Support building ROM files automatically with binman Simon Glass
` (52 preceding siblings ...)
2020-07-28 18:58 ` [PATCH v4 02/27] rockchip: Allow Bob to use SPI boot Simon Glass
@ 2020-07-28 18:58 ` Simon Glass
53 siblings, 0 replies; 94+ messages in thread
From: Simon Glass @ 2020-07-28 18:58 UTC (permalink / raw)
To: u-boot
Most x86 boards build a u-boot.rom which is programmed into SPI flash. But
this is not unique to x86. For example some rockchip boards can also boot
from SPI flash.
Also, at least on x86, binary blobs are sadly quite common. It is not
possible to build a functional image without them, and U-Boot needs to
know this at build time.
Introduce a new CONFIG_HAS_ROM option which selects whether u-boot.rom is
built and a new CONFIG_ROM_NEEDS_BLOBS option to indicate whether binary
blobs are also needed. If they are not needed, it is safe to build the ROM
always. Otherwise we still require the BUILD_ROM environment variable.
For now this affects only x86, but future patches will enable this for
rockchip too.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
(no changes since v2)
Changes in v2:
- Drop 'rockchip' tag since this commit no-longer affects rockchip yet
- Drop ROM_NEEDS_BLOBS for baytrail since HAVE_FSP already selects it
Kconfig | 18 +++++++++++++++++-
Makefile | 18 +++++++++++++-----
arch/Kconfig | 1 +
arch/x86/Kconfig | 4 ++++
arch/x86/cpu/quark/Kconfig | 1 +
5 files changed, 36 insertions(+), 6 deletions(-)
Applied to u-boot-dm, thanks!
^ permalink raw reply [flat|nested] 94+ messages in thread