All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 1/2] Makefile: Create a file to indicate the config
@ 2022-01-30 15:52 Simon Glass
  2022-01-30 15:52 ` [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR Simon Glass
  2022-01-31 14:24 ` [PATCH v2 1/2] Makefile: Create a file to indicate the config Tom Rini
  0 siblings, 2 replies; 25+ messages in thread
From: Simon Glass @ 2022-01-30 15:52 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Tom Rini, Michal Simek, huang lin, Jeffy Chen, Simon Glass,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Masahiro Yamada, Wolfgang Denk

At present it is not actually possible to discover the defconfig file that
was used to build U-Boot, so far as I can tell. Write this out to a file
in the build directory, so this is visible.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

(no changes since v1)

 scripts/kconfig/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 12e525ee31f..83a40c7eb3b 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -92,8 +92,10 @@ else
 endif
 endif
 
+# Write out the defconfig name to a file so we know which board was configured
 %_defconfig: $(obj)/conf
 	$(Q)$< $(silent) --defconfig=arch/$(SRCARCH)/configs/$@ $(Kconfig)
+	$(Q)echo $(subst _defconfig,,$@) > .defconfig_name
 
 # Added for U-Boot (backward compatibility)
 %_config: %_defconfig
-- 
2.35.0.rc2.247.g8bbb082509-goog


^ permalink raw reply related	[flat|nested] 25+ messages in thread

* [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-30 15:52 [PATCH v2 1/2] Makefile: Create a file to indicate the config Simon Glass
@ 2022-01-30 15:52 ` Simon Glass
  2022-01-30 19:40   ` Michal Simek
  2022-01-31 14:24   ` Tom Rini
  2022-01-31 14:24 ` [PATCH v2 1/2] Makefile: Create a file to indicate the config Tom Rini
  1 sibling, 2 replies; 25+ messages in thread
From: Simon Glass @ 2022-01-30 15:52 UTC (permalink / raw)
  To: U-Boot Mailing List
  Cc: Tom Rini, Michal Simek, huang lin, Jeffy Chen, Simon Glass,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

More than a year after this migration message appeared, we still have new
boards being added with this option. Add a check against this.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

Changes in v2:
- Rebase to master

 Makefile                      |  6 ++++
 scripts/fit_gen_whitelist.txt | 65 +++++++++++++++++++++++++++++++++++
 2 files changed, 71 insertions(+)
 create mode 100644 scripts/fit_gen_whitelist.txt

diff --git a/Makefile b/Makefile
index 212124522e6..55faff3952f 100644
--- a/Makefile
+++ b/Makefile
@@ -1110,6 +1110,12 @@ ifeq ($(CONFIG_OF_EMBED)$(CONFIG_EFI_APP),y)
 	@echo >&2 "===================================================="
 endif
 ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
+	# Only allow existing users of this deprecated option. Please migrate!
+	@if ! grep -q $(shell cat .defconfig_name) \
+			$(srctree)/scripts/fit_gen_whitelist.txt; then \
+		echo >&2 "Error: CONFIG_SPL_FIT_GENERATOR is deprecated"; \
+		exit 1; \
+	fi
 	@echo >&2 "===================== WARNING ======================"
 	@echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
 	@echo >&2 "to binman instead, to avoid the proliferation of"
diff --git a/scripts/fit_gen_whitelist.txt b/scripts/fit_gen_whitelist.txt
new file mode 100644
index 00000000000..ac0890b3f39
--- /dev/null
+++ b/scripts/fit_gen_whitelist.txt
@@ -0,0 +1,65 @@
+# List of boards that need to be migrated from SPL_FIT_GENERATOR to binman
+# See https://patchwork.ozlabs.org/project/uboot/list/?series=242992&state=*
+# for an example series (see patches 7 and 13 in particular)
+
+# Please do not add to this file
+
+# Some TI boards need migration
+am335x_evm_spiboot
+am64x_evm_a53
+am64x_evm_r5
+am65x_evm_r5_usbdfu
+am65x_evm_r5_usbmsc
+
+# MX8 needs migration
+cgtqmx8
+imx8mm-icore-mx8mm-ctouch2
+imx8mm-icore-mx8mm-edimm2.2
+imx8qm_rom7720_a1_4G
+
+# Rockchip needs migration
+chromebook_bob
+evb-px30
+evb-px5
+evb-rk3308
+evb-rk3328
+evb-rk3399
+evb-rk3568
+ficus-rk3399
+firefly-px30
+firefly-rk3399
+khadas-edge-captain-rk3399
+khadas-edge-rk3399
+khadas-edge-v-rk3399
+leez-rk3399
+lion-rk3368
+nanopc-t4-rk3399
+nanopi-m4-2gb-rk3399
+nanopi-m4b-rk3399
+nanopi-m4-rk3399
+nanopi-neo4-rk3399
+nanopi-r2s-rk3328
+nanopi-r4s-rk3399
+odroid-go2
+roc-cc-rk3308
+orangepi-rk3399
+pinebook-pro-rk3399
+puma-rk3399
+px30-core-ctouch2-of10-px30
+px30-core-ctouch2-px30
+px30-core-edimm2.2-px30
+roc-cc-rk3308
+roc-cc-rk3328
+rock64-rk3328
+rock960-rk3399
+rock-pi-4c-rk3399
+rock-pi-4-rk3399
+rock-pi-e-rk3328
+rock-pi-n10-rk3399pro
+rockpro64-rk3399
+roc-pc-mezzanine-rk3399
+roc-pc-rk3399
+
+# Zynqmp needs mnigration
+avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0
+xilinx_zynqmp_virt
-- 
2.35.0.rc2.247.g8bbb082509-goog


^ permalink raw reply related	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-30 15:52 ` [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR Simon Glass
@ 2022-01-30 19:40   ` Michal Simek
  2022-01-30 23:14     ` Simon Glass
  2022-01-31 14:24   ` Tom Rini
  1 sibling, 1 reply; 25+ messages in thread
From: Michal Simek @ 2022-01-30 19:40 UTC (permalink / raw)
  To: Simon Glass, U-Boot Mailing List
  Cc: Tom Rini, huang lin, Jeffy Chen, Kever Yang, Philipp Tomsich,
	NXP i . MX U-Boot Team, Marek Behún, Masahiro Yamada



On 1/30/22 16:52, Simon Glass wrote:
> More than a year after this migration message appeared, we still have new
> boards being added with this option. Add a check against this.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
> Changes in v2:
> - Rebase to master
> 
>   Makefile                      |  6 ++++
>   scripts/fit_gen_whitelist.txt | 65 +++++++++++++++++++++++++++++++++++
>   2 files changed, 71 insertions(+)
>   create mode 100644 scripts/fit_gen_whitelist.txt
> 
> diff --git a/Makefile b/Makefile
> index 212124522e6..55faff3952f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1110,6 +1110,12 @@ ifeq ($(CONFIG_OF_EMBED)$(CONFIG_EFI_APP),y)
>   	@echo >&2 "===================================================="
>   endif
>   ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> +	# Only allow existing users of this deprecated option. Please migrate!
> +	@if ! grep -q $(shell cat .defconfig_name) \
> +			$(srctree)/scripts/fit_gen_whitelist.txt; then \
> +		echo >&2 "Error: CONFIG_SPL_FIT_GENERATOR is deprecated"; \
> +		exit 1; \
> +	fi
>   	@echo >&2 "===================== WARNING ======================"
>   	@echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
>   	@echo >&2 "to binman instead, to avoid the proliferation of"
> diff --git a/scripts/fit_gen_whitelist.txt b/scripts/fit_gen_whitelist.txt
> new file mode 100644
> index 00000000000..ac0890b3f39
> --- /dev/null
> +++ b/scripts/fit_gen_whitelist.txt
> @@ -0,0 +1,65 @@
> +# List of boards that need to be migrated from SPL_FIT_GENERATOR to binman
> +# See https://patchwork.ozlabs.org/project/uboot/list/?series=242992&state=*
> +# for an example series (see patches 7 and 13 in particular)
> +
> +# Please do not add to this file
> +
> +# Some TI boards need migration
> +am335x_evm_spiboot
> +am64x_evm_a53
> +am64x_evm_r5
> +am65x_evm_r5_usbdfu
> +am65x_evm_r5_usbmsc
> +
> +# MX8 needs migration
> +cgtqmx8
> +imx8mm-icore-mx8mm-ctouch2
> +imx8mm-icore-mx8mm-edimm2.2
> +imx8qm_rom7720_a1_4G
> +
> +# Rockchip needs migration
> +chromebook_bob
> +evb-px30
> +evb-px5
> +evb-rk3308
> +evb-rk3328
> +evb-rk3399
> +evb-rk3568
> +ficus-rk3399
> +firefly-px30
> +firefly-rk3399
> +khadas-edge-captain-rk3399
> +khadas-edge-rk3399
> +khadas-edge-v-rk3399
> +leez-rk3399
> +lion-rk3368
> +nanopc-t4-rk3399
> +nanopi-m4-2gb-rk3399
> +nanopi-m4b-rk3399
> +nanopi-m4-rk3399
> +nanopi-neo4-rk3399
> +nanopi-r2s-rk3328
> +nanopi-r4s-rk3399
> +odroid-go2
> +roc-cc-rk3308
> +orangepi-rk3399
> +pinebook-pro-rk3399
> +puma-rk3399
> +px30-core-ctouch2-of10-px30
> +px30-core-ctouch2-px30
> +px30-core-edimm2.2-px30
> +roc-cc-rk3308
> +roc-cc-rk3328
> +rock64-rk3328
> +rock960-rk3399
> +rock-pi-4c-rk3399
> +rock-pi-4-rk3399
> +rock-pi-e-rk3328
> +rock-pi-n10-rk3399pro
> +rockpro64-rk3399
> +roc-pc-mezzanine-rk3399
> +roc-pc-rk3399
> +
> +# Zynqmp needs mnigration

nit: I normally use zynqmp or ZynqMP.
But there is typo.

What's the migration path? Buildman?

M

-- 
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] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-30 19:40   ` Michal Simek
@ 2022-01-30 23:14     ` Simon Glass
  0 siblings, 0 replies; 25+ messages in thread
From: Simon Glass @ 2022-01-30 23:14 UTC (permalink / raw)
  To: Michal Simek
  Cc: U-Boot Mailing List, Tom Rini, huang lin, Jeffy Chen, Kever Yang,
	Philipp Tomsich, NXP i . MX U-Boot Team, Marek Behún,
	Masahiro Yamada

Hi Michal,

On Sun, 30 Jan 2022 at 12:41, Michal Simek <monstr@monstr.eu> wrote:
>
>
>
> On 1/30/22 16:52, Simon Glass wrote:
> > More than a year after this migration message appeared, we still have new
> > boards being added with this option. Add a check against this.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Rebase to master
> >
> >   Makefile                      |  6 ++++
> >   scripts/fit_gen_whitelist.txt | 65 +++++++++++++++++++++++++++++++++++
> >   2 files changed, 71 insertions(+)
> >   create mode 100644 scripts/fit_gen_whitelist.txt
> >
> > diff --git a/Makefile b/Makefile
> > index 212124522e6..55faff3952f 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1110,6 +1110,12 @@ ifeq ($(CONFIG_OF_EMBED)$(CONFIG_EFI_APP),y)
> >       @echo >&2 "===================================================="
> >   endif
> >   ifneq ($(CONFIG_SPL_FIT_GENERATOR),)
> > +     # Only allow existing users of this deprecated option. Please migrate!
> > +     @if ! grep -q $(shell cat .defconfig_name) \
> > +                     $(srctree)/scripts/fit_gen_whitelist.txt; then \
> > +             echo >&2 "Error: CONFIG_SPL_FIT_GENERATOR is deprecated"; \
> > +             exit 1; \
> > +     fi
> >       @echo >&2 "===================== WARNING ======================"
> >       @echo >&2 "This board uses CONFIG_SPL_FIT_GENERATOR. Please migrate"
> >       @echo >&2 "to binman instead, to avoid the proliferation of"
> > diff --git a/scripts/fit_gen_whitelist.txt b/scripts/fit_gen_whitelist.txt
> > new file mode 100644
> > index 00000000000..ac0890b3f39
> > --- /dev/null
> > +++ b/scripts/fit_gen_whitelist.txt
> > @@ -0,0 +1,65 @@
> > +# List of boards that need to be migrated from SPL_FIT_GENERATOR to binman
> > +# See https://patchwork.ozlabs.org/project/uboot/list/?series=242992&state=*
> > +# for an example series (see patches 7 and 13 in particular)
> > +
> > +# Please do not add to this file
> > +
> > +# Some TI boards need migration
> > +am335x_evm_spiboot
> > +am64x_evm_a53
> > +am64x_evm_r5
> > +am65x_evm_r5_usbdfu
> > +am65x_evm_r5_usbmsc
> > +
> > +# MX8 needs migration
> > +cgtqmx8
> > +imx8mm-icore-mx8mm-ctouch2
> > +imx8mm-icore-mx8mm-edimm2.2
> > +imx8qm_rom7720_a1_4G
> > +
> > +# Rockchip needs migration
> > +chromebook_bob
> > +evb-px30
> > +evb-px5
> > +evb-rk3308
> > +evb-rk3328
> > +evb-rk3399
> > +evb-rk3568
> > +ficus-rk3399
> > +firefly-px30
> > +firefly-rk3399
> > +khadas-edge-captain-rk3399
> > +khadas-edge-rk3399
> > +khadas-edge-v-rk3399
> > +leez-rk3399
> > +lion-rk3368
> > +nanopc-t4-rk3399
> > +nanopi-m4-2gb-rk3399
> > +nanopi-m4b-rk3399
> > +nanopi-m4-rk3399
> > +nanopi-neo4-rk3399
> > +nanopi-r2s-rk3328
> > +nanopi-r4s-rk3399
> > +odroid-go2
> > +roc-cc-rk3308
> > +orangepi-rk3399
> > +pinebook-pro-rk3399
> > +puma-rk3399
> > +px30-core-ctouch2-of10-px30
> > +px30-core-ctouch2-px30
> > +px30-core-edimm2.2-px30
> > +roc-cc-rk3308
> > +roc-cc-rk3328
> > +rock64-rk3328
> > +rock960-rk3399
> > +rock-pi-4c-rk3399
> > +rock-pi-4-rk3399
> > +rock-pi-e-rk3328
> > +rock-pi-n10-rk3399pro
> > +rockpro64-rk3399
> > +roc-pc-mezzanine-rk3399
> > +roc-pc-rk3399
> > +
> > +# Zynqmp needs mnigration
>
> nit: I normally use zynqmp or ZynqMP.
> But there is typo.

OK will fix.

>
> What's the migration path? Buildman?

Actually it is a binman description, see the imx8 ones, for example.
It can generate a FIT for you.

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 1/2] Makefile: Create a file to indicate the config
  2022-01-30 15:52 [PATCH v2 1/2] Makefile: Create a file to indicate the config Simon Glass
  2022-01-30 15:52 ` [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR Simon Glass
@ 2022-01-31 14:24 ` Tom Rini
  2022-01-31 16:13   ` Simon Glass
  1 sibling, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 14:24 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Masahiro Yamada, Wolfgang Denk

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

On Sun, Jan 30, 2022 at 08:52:24AM -0700, Simon Glass wrote:

> At present it is not actually possible to discover the defconfig file that
> was used to build U-Boot, so far as I can tell. Write this out to a file
> in the build directory, so this is visible.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

I don't think we need this really normally, it's just for the follow-up
patch.

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-30 15:52 ` [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR Simon Glass
  2022-01-30 19:40   ` Michal Simek
@ 2022-01-31 14:24   ` Tom Rini
  2022-01-31 16:13     ` Simon Glass
  1 sibling, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 14:24 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:

> More than a year after this migration message appeared, we still have new
> boards being added with this option. Add a check against this.
> 
> Signed-off-by: Simon Glass <sjg@chromium.org>

Please just make this an error in checkpatch.pl instead.

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 14:24   ` Tom Rini
@ 2022-01-31 16:13     ` Simon Glass
  2022-01-31 16:15       ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-01-31 16:13 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

Hi Tom,

On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
>
> > More than a year after this migration message appeared, we still have new
> > boards being added with this option. Add a check against this.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
>
> Please just make this an error in checkpatch.pl instead.

I couldn't think of a way of doing that...do you have an idea?

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 1/2] Makefile: Create a file to indicate the config
  2022-01-31 14:24 ` [PATCH v2 1/2] Makefile: Create a file to indicate the config Tom Rini
@ 2022-01-31 16:13   ` Simon Glass
  2022-01-31 16:21     ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-01-31 16:13 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Masahiro Yamada, Wolfgang Denk

Hi Tom,

On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Jan 30, 2022 at 08:52:24AM -0700, Simon Glass wrote:
>
> > At present it is not actually possible to discover the defconfig file that
> > was used to build U-Boot, so far as I can tell. Write this out to a file
> > in the build directory, so this is visible.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
>
> I don't think we need this really normally, it's just for the follow-up
> patch.

I'd argue that it is helpful to have this somewhere. Is there anywhere
else in the build directory where it can be discovered?

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 16:13     ` Simon Glass
@ 2022-01-31 16:15       ` Tom Rini
  2022-01-31 17:27         ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 16:15 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> >
> > > More than a year after this migration message appeared, we still have new
> > > boards being added with this option. Add a check against this.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> > Please just make this an error in checkpatch.pl instead.
> 
> I couldn't think of a way of doing that...do you have an idea?

Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
and initrd relocation") updates the check I had for fdt_high/initrd_high
being in the file at all to only be for additions.  And yes, I check
every PR for new checkpatch ERROR lines and only ignore the ones for
code imported from other projects.

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 1/2] Makefile: Create a file to indicate the config
  2022-01-31 16:13   ` Simon Glass
@ 2022-01-31 16:21     ` Tom Rini
  2022-01-31 17:27       ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 16:21 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Masahiro Yamada, Wolfgang Denk

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

On Mon, Jan 31, 2022 at 09:13:07AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Jan 30, 2022 at 08:52:24AM -0700, Simon Glass wrote:
> >
> > > At present it is not actually possible to discover the defconfig file that
> > > was used to build U-Boot, so far as I can tell. Write this out to a file
> > > in the build directory, so this is visible.
> > >
> > > Signed-off-by: Simon Glass <sjg@chromium.org>
> >
> > I don't think we need this really normally, it's just for the follow-up
> > patch.
> 
> I'd argue that it is helpful to have this somewhere. Is there anywhere
> else in the build directory where it can be discovered?

It's not a guarantee to exist is my first problem.  My minor problems
are this needs to be in .gitignore and also I think this wasn't ensuring
output directory not source directory.  But I don't see the use case
this is filling.  If you're in-tree, you should know what you configured
and are working on.  If you're out of tree and didn't do any sort of
naming convention to your objdirs, did you also really care what
defconfig exactly (I use a mix of named and garbage-named temp dirs)?
And if you're a tool of some sort, you were told what to use at some
point I would assume.  Which all gets back to I don't see the use case
exactly for it.

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 1/2] Makefile: Create a file to indicate the config
  2022-01-31 16:21     ` Tom Rini
@ 2022-01-31 17:27       ` Simon Glass
  0 siblings, 0 replies; 25+ messages in thread
From: Simon Glass @ 2022-01-31 17:27 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Masahiro Yamada, Wolfgang Denk

Hi Tom,

On Mon, 31 Jan 2022 at 09:21, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 31, 2022 at 09:13:07AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sun, Jan 30, 2022 at 08:52:24AM -0700, Simon Glass wrote:
> > >
> > > > At present it is not actually possible to discover the defconfig file that
> > > > was used to build U-Boot, so far as I can tell. Write this out to a file
> > > > in the build directory, so this is visible.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > I don't think we need this really normally, it's just for the follow-up
> > > patch.
> >
> > I'd argue that it is helpful to have this somewhere. Is there anywhere
> > else in the build directory where it can be discovered?
>
> It's not a guarantee to exist is my first problem.  My minor problems

Do you mean there might not be a defconfig file? Yes I see. But
generally there is, e.g. with buildman.

> are this needs to be in .gitignore and also I think this wasn't ensuring
> output directory not source directory.  But I don't see the use case
> this is filling.  If you're in-tree, you should know what you configured
> and are working on.  If you're out of tree and didn't do any sort of
> naming convention to your objdirs, did you also really care what
> defconfig exactly (I use a mix of named and garbage-named temp dirs)?
> And if you're a tool of some sort, you were told what to use at some
> point I would assume.  Which all gets back to I don't see the use case
> exactly for it.

I was just surprised that there was no way to find it out, that's all.
It seems like a gap. But I agree that if we don't have a specific use
case (e.g. we figure out another way of doing the next patch) then we
could wait.

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 16:15       ` Tom Rini
@ 2022-01-31 17:27         ` Simon Glass
  2022-01-31 18:00           ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-01-31 17:27 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

Hi Tom,

On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > >
> > > > More than a year after this migration message appeared, we still have new
> > > > boards being added with this option. Add a check against this.
> > > >
> > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > >
> > > Please just make this an error in checkpatch.pl instead.
> >
> > I couldn't think of a way of doing that...do you have an idea?
>
> Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> and initrd relocation") updates the check I had for fdt_high/initrd_high
> being in the file at all to only be for additions.  And yes, I check
> every PR for new checkpatch ERROR lines and only ignore the ones for
> code imported from other projects.

Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
certain boards, so there is no need to mention it anywhere in the
patch. Also someone could adjust the condition in the Kconfig to add
other boards.

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 17:27         ` Simon Glass
@ 2022-01-31 18:00           ` Tom Rini
  2022-01-31 19:57             ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 18:00 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > >
> > > > > More than a year after this migration message appeared, we still have new
> > > > > boards being added with this option. Add a check against this.
> > > > >
> > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > >
> > > > Please just make this an error in checkpatch.pl instead.
> > >
> > > I couldn't think of a way of doing that...do you have an idea?
> >
> > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > being in the file at all to only be for additions.  And yes, I check
> > every PR for new checkpatch ERROR lines and only ignore the ones for
> > code imported from other projects.
> 
> Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> certain boards, so there is no need to mention it anywhere in the
> patch. Also someone could adjust the condition in the Kconfig to add
> other boards.

Then you want something a bit more like the fdt|initrd_high check now,
along with updating the help around SPL_FIT_GENERATOR to note that this
option is deprecated, is the path forward then I think.

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 18:00           ` Tom Rini
@ 2022-01-31 19:57             ` Simon Glass
  2022-01-31 20:40               ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-01-31 19:57 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

Hi Tom,

On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > >
> > > > > > More than a year after this migration message appeared, we still have new
> > > > > > boards being added with this option. Add a check against this.
> > > > > >
> > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > Please just make this an error in checkpatch.pl instead.
> > > >
> > > > I couldn't think of a way of doing that...do you have an idea?
> > >
> > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > being in the file at all to only be for additions.  And yes, I check
> > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > code imported from other projects.
> >
> > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > certain boards, so there is no need to mention it anywhere in the
> > patch. Also someone could adjust the condition in the Kconfig to add
> > other boards.
>
> Then you want something a bit more like the fdt|initrd_high check now,
> along with updating the help around SPL_FIT_GENERATOR to note that this
> option is deprecated, is the path forward then I think.

I'm still a bit lost.

What I want: break the build if someone adds a new board that uses
SPL_FIT_GENERATOR

What you are offering: checkpatch check for people adding that option

But the patch doesn't generally include that option.

I can certainly mention in the Kconfig help that the option is
deprecated, but without checking if it is defined for a NEW board, I
cannot prevent it from growing.

What am I missing? Can you be more specific?

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 19:57             ` Simon Glass
@ 2022-01-31 20:40               ` Tom Rini
  2022-01-31 21:22                 ` Simon Glass
  2022-01-31 22:02                 ` Mark Kettenis
  0 siblings, 2 replies; 25+ messages in thread
From: Tom Rini @ 2022-01-31 20:40 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > >
> > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > boards being added with this option. Add a check against this.
> > > > > > >
> > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > >
> > > > > > Please just make this an error in checkpatch.pl instead.
> > > > >
> > > > > I couldn't think of a way of doing that...do you have an idea?
> > > >
> > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > being in the file at all to only be for additions.  And yes, I check
> > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > code imported from other projects.
> > >
> > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > certain boards, so there is no need to mention it anywhere in the
> > > patch. Also someone could adjust the condition in the Kconfig to add
> > > other boards.
> >
> > Then you want something a bit more like the fdt|initrd_high check now,
> > along with updating the help around SPL_FIT_GENERATOR to note that this
> > option is deprecated, is the path forward then I think.
> 
> I'm still a bit lost.
> 
> What I want: break the build if someone adds a new board that uses
> SPL_FIT_GENERATOR
> 
> What you are offering: checkpatch check for people adding that option
> 
> But the patch doesn't generally include that option.
> 
> I can certainly mention in the Kconfig help that the option is
> deprecated, but without checking if it is defined for a NEW board, I
> cannot prevent it from growing.
> 
> What am I missing? Can you be more specific?

How do you add a new board that enables SPL_FIT_GENERATOR without
"SPL_FIT_GENERATOR" being in the resulting patch, other than being
ARCH_ZYNQMP/ARCH_ROCKCHIP ?

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 20:40               ` Tom Rini
@ 2022-01-31 21:22                 ` Simon Glass
  2022-01-31 22:05                   ` Tom Rini
  2022-01-31 22:02                 ` Mark Kettenis
  1 sibling, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-01-31 21:22 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

Hi Tom,

On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > >
> > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > >
> > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > >
> > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > code imported from other projects.
> > > >
> > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > certain boards, so there is no need to mention it anywhere in the
> > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > other boards.
> > >
> > > Then you want something a bit more like the fdt|initrd_high check now,
> > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > option is deprecated, is the path forward then I think.
> >
> > I'm still a bit lost.
> >
> > What I want: break the build if someone adds a new board that uses
> > SPL_FIT_GENERATOR
> >
> > What you are offering: checkpatch check for people adding that option
> >
> > But the patch doesn't generally include that option.
> >
> > I can certainly mention in the Kconfig help that the option is
> > deprecated, but without checking if it is defined for a NEW board, I
> > cannot prevent it from growing.
> >
> > What am I missing? Can you be more specific?
>
> How do you add a new board that enables SPL_FIT_GENERATOR without
> "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> ARCH_ZYNQMP/ARCH_ROCKCHIP ?

Well that's the case I am most concerned with, actually. Also, someone
might add a new condition to SPL_FIT_GENERATOR.

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 20:40               ` Tom Rini
  2022-01-31 21:22                 ` Simon Glass
@ 2022-01-31 22:02                 ` Mark Kettenis
  1 sibling, 0 replies; 25+ messages in thread
From: Mark Kettenis @ 2022-01-31 22:02 UTC (permalink / raw)
  To: Tom Rini
  Cc: sjg, u-boot, monstr, hl, jeffy.chen, kever.yang, philipp.tomsich,
	uboot-imx, marek.behun, yamada.masahiro

> Date: Mon, 31 Jan 2022 15:40:39 -0500
> From: Tom Rini <trini@konsulko.com>
> 
> On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > Hi Tom,
> > 
> > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > >
> > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > >
> > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > >
> > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > >
> > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > code imported from other projects.
> > > >
> > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > certain boards, so there is no need to mention it anywhere in the
> > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > other boards.
> > >
> > > Then you want something a bit more like the fdt|initrd_high check now,
> > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > option is deprecated, is the path forward then I think.
> > 
> > I'm still a bit lost.
> > 
> > What I want: break the build if someone adds a new board that uses
> > SPL_FIT_GENERATOR
> > 
> > What you are offering: checkpatch check for people adding that option
> > 
> > But the patch doesn't generally include that option.
> > 
> > I can certainly mention in the Kconfig help that the option is
> > deprecated, but without checking if it is defined for a NEW board, I
> > cannot prevent it from growing.
> > 
> > What am I missing? Can you be more specific?
> 
> How do you add a new board that enables SPL_FIT_GENERATOR without
> "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> ARCH_ZYNQMP/ARCH_ROCKCHIP ?

Well, that's a problem isn't it?  Simon is basically saying no to any
new rk3399 board, which doesn't make any sense since this isn't a
board-specific issue but a SoC specific issue.  Adding new boards
doesn't make it more difficult to fix the issue.  I guess he is hoping
that saying no to a new rk3399 board will trick someone into actually
doing the work of adding the necessary code to binman?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 21:22                 ` Simon Glass
@ 2022-01-31 22:05                   ` Tom Rini
  2022-01-31 22:59                     ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 22:05 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > > >
> > > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > >
> > > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > > >
> > > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > > >
> > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > > code imported from other projects.
> > > > >
> > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > > certain boards, so there is no need to mention it anywhere in the
> > > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > > other boards.
> > > >
> > > > Then you want something a bit more like the fdt|initrd_high check now,
> > > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > > option is deprecated, is the path forward then I think.
> > >
> > > I'm still a bit lost.
> > >
> > > What I want: break the build if someone adds a new board that uses
> > > SPL_FIT_GENERATOR
> > >
> > > What you are offering: checkpatch check for people adding that option
> > >
> > > But the patch doesn't generally include that option.
> > >
> > > I can certainly mention in the Kconfig help that the option is
> > > deprecated, but without checking if it is defined for a NEW board, I
> > > cannot prevent it from growing.
> > >
> > > What am I missing? Can you be more specific?
> >
> > How do you add a new board that enables SPL_FIT_GENERATOR without
> > "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> > ARCH_ZYNQMP/ARCH_ROCKCHIP ?
> 
> Well that's the case I am most concerned with, actually. Also, someone
> might add a new condition to SPL_FIT_GENERATOR.

For the current cases, we just need to get them migrated since it's all
the same logic?  So it would I think be a one-and-done thing.  For a new
conditional, it should trip checkpatch by having the words in it, and
also since the help would also say to not do this, and we already
generate a warning, it shouldn't be an issue?

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 22:05                   ` Tom Rini
@ 2022-01-31 22:59                     ` Simon Glass
  2022-01-31 23:25                       ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-01-31 22:59 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

Hi Tom,

(yes Mark I am trying to stop further boards going in that use the
shell scripts)

On Mon, 31 Jan 2022 at 15:05, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > > > >
> > > > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > > >
> > > > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > > > >
> > > > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > > > >
> > > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > > > code imported from other projects.
> > > > > >
> > > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > > > certain boards, so there is no need to mention it anywhere in the
> > > > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > > > other boards.
> > > > >
> > > > > Then you want something a bit more like the fdt|initrd_high check now,
> > > > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > > > option is deprecated, is the path forward then I think.
> > > >
> > > > I'm still a bit lost.
> > > >
> > > > What I want: break the build if someone adds a new board that uses
> > > > SPL_FIT_GENERATOR
> > > >
> > > > What you are offering: checkpatch check for people adding that option
> > > >
> > > > But the patch doesn't generally include that option.
> > > >
> > > > I can certainly mention in the Kconfig help that the option is
> > > > deprecated, but without checking if it is defined for a NEW board, I
> > > > cannot prevent it from growing.
> > > >
> > > > What am I missing? Can you be more specific?
> > >
> > > How do you add a new board that enables SPL_FIT_GENERATOR without
> > > "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> > > ARCH_ZYNQMP/ARCH_ROCKCHIP ?
> >
> > Well that's the case I am most concerned with, actually. Also, someone
> > might add a new condition to SPL_FIT_GENERATOR.
>
> For the current cases, we just need to get them migrated since it's all
> the same logic?  So it would I think be a one-and-done thing.  For a new

Yes I think so and some of them are done. These are what I can find:

./arch/riscv/lib/mkimage_fit_opensbi.sh
./arch/arm/mach-zynqmp/mkimage_fit_atf.sh
./arch/arm/mach-imx/mkimage_fit_atf.sh
./arch/arm/mach-rockchip/make_fit_atf.py

but they are not used by that many boards.

I feel that the amount of pending migration is somewhat overwhelming
and we should take a stronger line in mainline.

Perhaps I should send a patch to simply remove the option? Would that
be acceptable?

Regards,
Simon
> conditional, it should trip checkpatch by having the words in it, and
> also since the help would also say to not do this, and we already
> generate a warning, it shouldn't be an issue?
>
> --
> Tom

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 22:59                     ` Simon Glass
@ 2022-01-31 23:25                       ` Tom Rini
  2022-01-31 23:32                         ` Tom Rini
  0 siblings, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 23:25 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Mon, Jan 31, 2022 at 03:59:08PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> (yes Mark I am trying to stop further boards going in that use the
> shell scripts)
> 
> On Mon, 31 Jan 2022 at 15:05, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > > > > >
> > > > > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > > > >
> > > > > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > > > > >
> > > > > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > > > > >
> > > > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > > > > code imported from other projects.
> > > > > > >
> > > > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > > > > certain boards, so there is no need to mention it anywhere in the
> > > > > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > > > > other boards.
> > > > > >
> > > > > > Then you want something a bit more like the fdt|initrd_high check now,
> > > > > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > > > > option is deprecated, is the path forward then I think.
> > > > >
> > > > > I'm still a bit lost.
> > > > >
> > > > > What I want: break the build if someone adds a new board that uses
> > > > > SPL_FIT_GENERATOR
> > > > >
> > > > > What you are offering: checkpatch check for people adding that option
> > > > >
> > > > > But the patch doesn't generally include that option.
> > > > >
> > > > > I can certainly mention in the Kconfig help that the option is
> > > > > deprecated, but without checking if it is defined for a NEW board, I
> > > > > cannot prevent it from growing.
> > > > >
> > > > > What am I missing? Can you be more specific?
> > > >
> > > > How do you add a new board that enables SPL_FIT_GENERATOR without
> > > > "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> > > > ARCH_ZYNQMP/ARCH_ROCKCHIP ?
> > >
> > > Well that's the case I am most concerned with, actually. Also, someone
> > > might add a new condition to SPL_FIT_GENERATOR.
> >
> > For the current cases, we just need to get them migrated since it's all
> > the same logic?  So it would I think be a one-and-done thing.  For a new
> 
> Yes I think so and some of them are done. These are what I can find:
> 
> ./arch/riscv/lib/mkimage_fit_opensbi.sh
> ./arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> ./arch/arm/mach-imx/mkimage_fit_atf.sh
> ./arch/arm/mach-rockchip/make_fit_atf.py
> 
> but they are not used by that many boards.
> 
> I feel that the amount of pending migration is somewhat overwhelming
> and we should take a stronger line in mainline.
> 
> Perhaps I should send a patch to simply remove the option? Would that
> be acceptable?

Is there something technically preventing their migration to buildman?
Looking over examples for imx8* conversions, it's just adding a binman
node and describing things there, yes?

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 23:25                       ` Tom Rini
@ 2022-01-31 23:32                         ` Tom Rini
  2022-02-01 14:05                           ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Tom Rini @ 2022-01-31 23:32 UTC (permalink / raw)
  To: Simon Glass
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

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

On Mon, Jan 31, 2022 at 06:25:33PM -0500, Tom Rini wrote:
> On Mon, Jan 31, 2022 at 03:59:08PM -0700, Simon Glass wrote:
> > Hi Tom,
> > 
> > (yes Mark I am trying to stop further boards going in that use the
> > shell scripts)
> > 
> > On Mon, 31 Jan 2022 at 15:05, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > > > > > >
> > > > > > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > > > > >
> > > > > > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > > > > > >
> > > > > > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > > > > > >
> > > > > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > > > > > code imported from other projects.
> > > > > > > >
> > > > > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > > > > > certain boards, so there is no need to mention it anywhere in the
> > > > > > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > > > > > other boards.
> > > > > > >
> > > > > > > Then you want something a bit more like the fdt|initrd_high check now,
> > > > > > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > > > > > option is deprecated, is the path forward then I think.
> > > > > >
> > > > > > I'm still a bit lost.
> > > > > >
> > > > > > What I want: break the build if someone adds a new board that uses
> > > > > > SPL_FIT_GENERATOR
> > > > > >
> > > > > > What you are offering: checkpatch check for people adding that option
> > > > > >
> > > > > > But the patch doesn't generally include that option.
> > > > > >
> > > > > > I can certainly mention in the Kconfig help that the option is
> > > > > > deprecated, but without checking if it is defined for a NEW board, I
> > > > > > cannot prevent it from growing.
> > > > > >
> > > > > > What am I missing? Can you be more specific?
> > > > >
> > > > > How do you add a new board that enables SPL_FIT_GENERATOR without
> > > > > "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> > > > > ARCH_ZYNQMP/ARCH_ROCKCHIP ?
> > > >
> > > > Well that's the case I am most concerned with, actually. Also, someone
> > > > might add a new condition to SPL_FIT_GENERATOR.
> > >
> > > For the current cases, we just need to get them migrated since it's all
> > > the same logic?  So it would I think be a one-and-done thing.  For a new
> > 
> > Yes I think so and some of them are done. These are what I can find:
> > 
> > ./arch/riscv/lib/mkimage_fit_opensbi.sh
> > ./arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> > ./arch/arm/mach-imx/mkimage_fit_atf.sh
> > ./arch/arm/mach-rockchip/make_fit_atf.py
> > 
> > but they are not used by that many boards.
> > 
> > I feel that the amount of pending migration is somewhat overwhelming
> > and we should take a stronger line in mainline.
> > 
> > Perhaps I should send a patch to simply remove the option? Would that
> > be acceptable?
> 
> Is there something technically preventing their migration to buildman?
> Looking over examples for imx8* conversions, it's just adding a binman
> node and describing things there, yes?

Poking at this a bit more, it seems like the outstanding imx platforms
to be converted still have pending patches and it's just part of the
general imx backlog.  The riscv one isn't used and should be removed.
That leaves rockchip and zynqmp needing conversion.  Michal has already
commented in this thread and I'll leave it to him to say how long he
needs to see how long zynqmp needs to update.  That leaves Rockchip.

-- 
Tom

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

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-01-31 23:32                         ` Tom Rini
@ 2022-02-01 14:05                           ` Simon Glass
  2022-02-01 15:42                             ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-02-01 14:05 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, Philipp Tomsich, NXP i . MX U-Boot Team,
	Marek Behún, Masahiro Yamada

Hi Tom,

On Mon, 31 Jan 2022 at 16:32, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Jan 31, 2022 at 06:25:33PM -0500, Tom Rini wrote:
> > On Mon, Jan 31, 2022 at 03:59:08PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > (yes Mark I am trying to stop further boards going in that use the
> > > shell scripts)
> > >
> > > On Mon, 31 Jan 2022 at 15:05, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > > > > > > Hi Tom,
> > > > > > > > > > >
> > > > > > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > > > > > >
> > > > > > > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > > > > > > >
> > > > > > > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > > > > > > >
> > > > > > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > > > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > > > > > > code imported from other projects.
> > > > > > > > >
> > > > > > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > > > > > > certain boards, so there is no need to mention it anywhere in the
> > > > > > > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > > > > > > other boards.
> > > > > > > >
> > > > > > > > Then you want something a bit more like the fdt|initrd_high check now,
> > > > > > > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > > > > > > option is deprecated, is the path forward then I think.
> > > > > > >
> > > > > > > I'm still a bit lost.
> > > > > > >
> > > > > > > What I want: break the build if someone adds a new board that uses
> > > > > > > SPL_FIT_GENERATOR
> > > > > > >
> > > > > > > What you are offering: checkpatch check for people adding that option
> > > > > > >
> > > > > > > But the patch doesn't generally include that option.
> > > > > > >
> > > > > > > I can certainly mention in the Kconfig help that the option is
> > > > > > > deprecated, but without checking if it is defined for a NEW board, I
> > > > > > > cannot prevent it from growing.
> > > > > > >
> > > > > > > What am I missing? Can you be more specific?
> > > > > >
> > > > > > How do you add a new board that enables SPL_FIT_GENERATOR without
> > > > > > "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> > > > > > ARCH_ZYNQMP/ARCH_ROCKCHIP ?
> > > > >
> > > > > Well that's the case I am most concerned with, actually. Also, someone
> > > > > might add a new condition to SPL_FIT_GENERATOR.
> > > >
> > > > For the current cases, we just need to get them migrated since it's all
> > > > the same logic?  So it would I think be a one-and-done thing.  For a new
> > >
> > > Yes I think so and some of them are done. These are what I can find:
> > >
> > > ./arch/riscv/lib/mkimage_fit_opensbi.sh
> > > ./arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> > > ./arch/arm/mach-imx/mkimage_fit_atf.sh
> > > ./arch/arm/mach-rockchip/make_fit_atf.py
> > >
> > > but they are not used by that many boards.
> > >
> > > I feel that the amount of pending migration is somewhat overwhelming
> > > and we should take a stronger line in mainline.
> > >
> > > Perhaps I should send a patch to simply remove the option? Would that
> > > be acceptable?
> >
> > Is there something technically preventing their migration to buildman?
> > Looking over examples for imx8* conversions, it's just adding a binman
> > node and describing things there, yes?
>
> Poking at this a bit more, it seems like the outstanding imx platforms
> to be converted still have pending patches and it's just part of the
> general imx backlog.  The riscv one isn't used and should be removed.
> That leaves rockchip and zynqmp needing conversion.  Michal has already
> commented in this thread and I'll leave it to him to say how long he
> needs to see how long zynqmp needs to update.  That leaves Rockchip.

Ah good! One option might be that I could try to convert
chromebook_bob, then see if we can just apply it to everything?

+Kever Yang again for that but it is New Year over there

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-02-01 14:05                           ` Simon Glass
@ 2022-02-01 15:42                             ` Simon Glass
  2022-02-01 16:08                               ` Mark Kettenis
  0 siblings, 1 reply; 25+ messages in thread
From: Simon Glass @ 2022-02-01 15:42 UTC (permalink / raw)
  To: Tom Rini
  Cc: U-Boot Mailing List, Michal Simek, huang lin, Jeffy Chen,
	Kever Yang, NXP i . MX U-Boot Team, Marek Behún,
	Masahiro Yamada

-Philipp

Hi Tom,

On Tue, 1 Feb 2022 at 07:05, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Mon, 31 Jan 2022 at 16:32, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Mon, Jan 31, 2022 at 06:25:33PM -0500, Tom Rini wrote:
> > > On Mon, Jan 31, 2022 at 03:59:08PM -0700, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > (yes Mark I am trying to stop further boards going in that use the
> > > > shell scripts)
> > > >
> > > > On Mon, 31 Jan 2022 at 15:05, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Mon, Jan 31, 2022 at 02:22:41PM -0700, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Mon, 31 Jan 2022 at 13:40, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Mon, Jan 31, 2022 at 12:57:57PM -0700, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Mon, 31 Jan 2022 at 11:00, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Mon, Jan 31, 2022 at 10:27:41AM -0700, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Mon, 31 Jan 2022 at 09:15, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Jan 31, 2022 at 09:13:02AM -0700, Simon Glass wrote:
> > > > > > > > > > > > Hi Tom,
> > > > > > > > > > > >
> > > > > > > > > > > > On Mon, 31 Jan 2022 at 07:24, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sun, Jan 30, 2022 at 08:52:25AM -0700, Simon Glass wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > More than a year after this migration message appeared, we still have new
> > > > > > > > > > > > > > boards being added with this option. Add a check against this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Simon Glass <sjg@chromium.org>
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please just make this an error in checkpatch.pl instead.
> > > > > > > > > > > >
> > > > > > > > > > > > I couldn't think of a way of doing that...do you have an idea?
> > > > > > > > > > >
> > > > > > > > > > > Yes, 2f3e8d6a86cb ("checkpatch: report ERROR only on disabling of fdt
> > > > > > > > > > > and initrd relocation") updates the check I had for fdt_high/initrd_high
> > > > > > > > > > > being in the file at all to only be for additions.  And yes, I check
> > > > > > > > > > > every PR for new checkpatch ERROR lines and only ignore the ones for
> > > > > > > > > > > code imported from other projects.
> > > > > > > > > >
> > > > > > > > > > Yes, I understand that, but SPL_FIT_GENERATOR defaults to on for
> > > > > > > > > > certain boards, so there is no need to mention it anywhere in the
> > > > > > > > > > patch. Also someone could adjust the condition in the Kconfig to add
> > > > > > > > > > other boards.
> > > > > > > > >
> > > > > > > > > Then you want something a bit more like the fdt|initrd_high check now,
> > > > > > > > > along with updating the help around SPL_FIT_GENERATOR to note that this
> > > > > > > > > option is deprecated, is the path forward then I think.
> > > > > > > >
> > > > > > > > I'm still a bit lost.
> > > > > > > >
> > > > > > > > What I want: break the build if someone adds a new board that uses
> > > > > > > > SPL_FIT_GENERATOR
> > > > > > > >
> > > > > > > > What you are offering: checkpatch check for people adding that option
> > > > > > > >
> > > > > > > > But the patch doesn't generally include that option.
> > > > > > > >
> > > > > > > > I can certainly mention in the Kconfig help that the option is
> > > > > > > > deprecated, but without checking if it is defined for a NEW board, I
> > > > > > > > cannot prevent it from growing.
> > > > > > > >
> > > > > > > > What am I missing? Can you be more specific?
> > > > > > >
> > > > > > > How do you add a new board that enables SPL_FIT_GENERATOR without
> > > > > > > "SPL_FIT_GENERATOR" being in the resulting patch, other than being
> > > > > > > ARCH_ZYNQMP/ARCH_ROCKCHIP ?
> > > > > >
> > > > > > Well that's the case I am most concerned with, actually. Also, someone
> > > > > > might add a new condition to SPL_FIT_GENERATOR.
> > > > >
> > > > > For the current cases, we just need to get them migrated since it's all
> > > > > the same logic?  So it would I think be a one-and-done thing.  For a new
> > > >
> > > > Yes I think so and some of them are done. These are what I can find:
> > > >
> > > > ./arch/riscv/lib/mkimage_fit_opensbi.sh
> > > > ./arch/arm/mach-zynqmp/mkimage_fit_atf.sh
> > > > ./arch/arm/mach-imx/mkimage_fit_atf.sh
> > > > ./arch/arm/mach-rockchip/make_fit_atf.py
> > > >
> > > > but they are not used by that many boards.
> > > >
> > > > I feel that the amount of pending migration is somewhat overwhelming
> > > > and we should take a stronger line in mainline.
> > > >
> > > > Perhaps I should send a patch to simply remove the option? Would that
> > > > be acceptable?
> > >
> > > Is there something technically preventing their migration to buildman?
> > > Looking over examples for imx8* conversions, it's just adding a binman
> > > node and describing things there, yes?
> >
> > Poking at this a bit more, it seems like the outstanding imx platforms
> > to be converted still have pending patches and it's just part of the
> > general imx backlog.  The riscv one isn't used and should be removed.
> > That leaves rockchip and zynqmp needing conversion.  Michal has already
> > commented in this thread and I'll leave it to him to say how long he
> > needs to see how long zynqmp needs to update.  That leaves Rockchip.
>
> Ah good! One option might be that I could try to convert
> chromebook_bob, then see if we can just apply it to everything?
>
> +Kever Yang again for that but it is New Year over there

It seems that rk3399 uses bl31.elf and splits out the sections into
pieces. What a mess! I wonder if that is necessary for ATF to work? It
seems to do the same for TEE.

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-02-01 15:42                             ` Simon Glass
@ 2022-02-01 16:08                               ` Mark Kettenis
  2022-02-01 16:24                                 ` Simon Glass
  0 siblings, 1 reply; 25+ messages in thread
From: Mark Kettenis @ 2022-02-01 16:08 UTC (permalink / raw)
  To: Simon Glass
  Cc: trini, u-boot, monstr, hl, jeffy.chen, kever.yang, uboot-imx,
	marek.behun, yamada.masahiro

> From: Simon Glass <sjg@chromium.org>
> Date: Tue, 1 Feb 2022 08:42:35 -0700
> 
> It seems that rk3399 uses bl31.elf and splits out the sections into
> pieces. What a mess! I wonder if that is necessary for ATF to work? It
> seems to do the same for TEE.

That's because bl31.elf really consists of three binary blobs packed
together into a single ELF object.  This is done such that specific
bits needed for suspend/resume land in the AP's SRAM and the PMU's
SRAM while the majority lands in DRAM.  The splitting happens to make
U-Boot's ITS stuff happy.

I suppose this could be done in a different way by packing the ELF
binary itself into the FIT image, but then SPL has to parse the ELF
headers and copy things in place which may be challenging.

(I'm not familliar with the TEE stuff)

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR
  2022-02-01 16:08                               ` Mark Kettenis
@ 2022-02-01 16:24                                 ` Simon Glass
  0 siblings, 0 replies; 25+ messages in thread
From: Simon Glass @ 2022-02-01 16:24 UTC (permalink / raw)
  To: Mark Kettenis
  Cc: Tom Rini, U-Boot Mailing List, Michal Simek, Lin Huang,
	Jeffy Chen, Kever Yang, dl-uboot-imx, Marek Behún,
	Masahiro Yamada

Hi Mark,

On Tue, 1 Feb 2022 at 09:08, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: Simon Glass <sjg@chromium.org>
> > Date: Tue, 1 Feb 2022 08:42:35 -0700
> >
> > It seems that rk3399 uses bl31.elf and splits out the sections into
> > pieces. What a mess! I wonder if that is necessary for ATF to work? It
> > seems to do the same for TEE.
>
> That's because bl31.elf really consists of three binary blobs packed
> together into a single ELF object.  This is done such that specific
> bits needed for suspend/resume land in the AP's SRAM and the PMU's
> SRAM while the majority lands in DRAM.  The splitting happens to make
> U-Boot's ITS stuff happy.

OK I see, thanks. I hadn't realised it was running from SDRAM. I
suppose SPL has set that up already. It would help if I could get my
firefly-rk3399 unblocked.

>
> I suppose this could be done in a different way by packing the ELF
> binary itself into the FIT image, but then SPL has to parse the ELF
> headers and copy things in place which may be challenging.

We do have code for that which we could press into service, but it
goes against the idea of SPL a bit, I think, when you can do it in
advance.

>
> (I'm not familliar with the TEE stuff)

Well if we need to do it for BL31, it is not really any more effort to
do it for TEE, I suppose.

Regards,
Simon

^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2022-02-01 16:25 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-30 15:52 [PATCH v2 1/2] Makefile: Create a file to indicate the config Simon Glass
2022-01-30 15:52 ` [PATCH v2 2/2] Makefile: Don't allow new boards with SPL_FIT_GENERATOR Simon Glass
2022-01-30 19:40   ` Michal Simek
2022-01-30 23:14     ` Simon Glass
2022-01-31 14:24   ` Tom Rini
2022-01-31 16:13     ` Simon Glass
2022-01-31 16:15       ` Tom Rini
2022-01-31 17:27         ` Simon Glass
2022-01-31 18:00           ` Tom Rini
2022-01-31 19:57             ` Simon Glass
2022-01-31 20:40               ` Tom Rini
2022-01-31 21:22                 ` Simon Glass
2022-01-31 22:05                   ` Tom Rini
2022-01-31 22:59                     ` Simon Glass
2022-01-31 23:25                       ` Tom Rini
2022-01-31 23:32                         ` Tom Rini
2022-02-01 14:05                           ` Simon Glass
2022-02-01 15:42                             ` Simon Glass
2022-02-01 16:08                               ` Mark Kettenis
2022-02-01 16:24                                 ` Simon Glass
2022-01-31 22:02                 ` Mark Kettenis
2022-01-31 14:24 ` [PATCH v2 1/2] Makefile: Create a file to indicate the config Tom Rini
2022-01-31 16:13   ` Simon Glass
2022-01-31 16:21     ` Tom Rini
2022-01-31 17:27       ` Simon Glass

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.