* [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 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 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 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 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
* 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 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 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 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
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.