[PATCH] CI: Update test/nokia_rx51_test.sh to use prebuilt images
From: Pali Rohár Now that the Dockerfile creates images which have the binaries we require included, have CI make symlinks for them and update the existing script to support this. Signed-off-by: Tom Rini --- Pali, since you posted this in a thread as untested, can you please reply with a S-o-b tag? I tweaked it slightly while testing. Thanks. --- .azure-pipelines.yml| 9 - .gitlab-ci.yml | 11 +-- test/nokia_rx51_test.sh | 24 3 files changed, 33 insertions(+), 11 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 8327edf87aa1..30025ff7517e 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -2,7 +2,7 @@ variables: windows_vm: windows-2019 ubuntu_vm: ubuntu-22.04 macos_vm: macOS-12 - ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-10Feb2023 + ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 # Add '-u 0' options for Azure pipelines, otherwise we get "permission # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", # since our $(ci_runner_image) user is not root. @@ -187,6 +187,13 @@ stages: options: $(container_option) steps: - script: | + mkdir nokia_rx51_tmp + ln -s /opt/nokia/u-boot-gen-combined nokia_rx51_tmp/ + ln -s /opt/nokia/qemu-n900.tar.gz nokia_rx51_tmp/ + ln -s /opt/nokia/kernel_2.6.28-20103103+0m5_armel.deb nokia_rx51_tmp/ + ln -s /opt/nokia/libc6_2.5.1-1eglibc27+0m5_armel.deb nokia_rx51_tmp/ + ln -s /opt/nokia/busybox_1.10.2.legal-1osso30+0m5_armel.deb nokia_rx51_tmp/ + ln -s /opt/nokia/qemu-system-arm nokia_rx51_tmp/ export PATH=/opt/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin:$PATH test/nokia_rx51_test.sh diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index c3ceca2974d3..e320a24ef31e 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -2,7 +2,7 @@ # Grab our configured image. The source for this is found # in the u-boot tree at tools/docker/Dockerfile -image: trini/u-boot-gitlab-ci-runner:jammy-20230126-10Feb2023 +image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 # We run some tests in different order, to catch some failures quicker. stages: @@ -213,7 +213,14 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites: Run tests for Nokia RX-51 (aka N900): stage: testsuites script: -- export PATH=/opt/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin:$PATH; +- mkdir nokia_rx51_tmp; + ln -s /opt/nokia/u-boot-gen-combined nokia_rx51_tmp/; + ln -s /opt/nokia/qemu-n900.tar.gz nokia_rx51_tmp/; + ln -s /opt/nokia/kernel_2.6.28-20103103+0m5_armel.deb nokia_rx51_tmp/; + ln -s /opt/nokia/libc6_2.5.1-1eglibc27+0m5_armel.deb nokia_rx51_tmp/; + ln -s /opt/nokia/busybox_1.10.2.legal-1osso30+0m5_armel.deb nokia_rx51_tmp/; + ln -s /opt/nokia/qemu-system-arm nokia_rx51_tmp/; + export PATH=/opt/gcc-12.2.0-nolibc/arm-linux-gnueabi/bin:$PATH; test/nokia_rx51_test.sh # Check for any pylint regressions diff --git a/test/nokia_rx51_test.sh b/test/nokia_rx51_test.sh index a516ec2967c3..dca9ef3027b7 100755 --- a/test/nokia_rx51_test.sh +++ b/test/nokia_rx51_test.sh @@ -83,8 +83,10 @@ echo # Download qflasher and nolo images # This is proprietary qemu flasher tool with first stage images, but license allows non-commercial redistribution -wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz -tar -xf qemu-n900.tar.gz +if ! test -f qflasher || ! test -f xloader-qemu.bin || ! test -f secondary-qemu.bin; then + test -f qemu-n900.tar.gz || wget -c http://repository.maemo.org/qemu-n900/qemu-n900.tar.gz + tar -xf qemu-n900.tar.gz +fi # Download Maemo script u-boot-gen-combined if ! test -f u-boot-gen-combined; then @@ -94,16 +96,22 @@ if ! test -f u-boot-gen-combined; then fi # Download Maemo fiasco kernel -wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb -dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28 +if ! test -d kernel_2.6.28; then + test -f kernel_2.6.28-20103103+0m5_armel.deb || wget -c http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb + dpkg -x kernel_2.6.28-20103103+0m5_armel.deb kernel_2.6.28 +fi # Download Maemo libc -wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb -dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1 +if ! test -d libc6_2.5.1; then + test -f libc6_2.5.1-1eglibc27+0m5_armel.deb || wget -c http://repository.maemo.org/pool/maemo5.0/free/g/glibc/libc6_2.5.1-1eglibc27+0m5_armel.deb + dpkg -x libc6_2.5.1-1eglibc27+0m5_armel.deb libc6_2.5.1 +fi # Download Maemo busybox -wget -c http://repository.maemo.org/pool/maemo5.0/free/b/busybox/busybox_1.10.2.legal-1osso30+0m5_armel.deb -dpkg -x busybox_1.10
Re: [PATCHv4 4/5] fwu: meta-data: switch to management by common code
On Sat, Feb 04, 2023 at 09:02:02PM -0600, jassisinghb...@gmail.com wrote: > From: Jassi Brar > > The common code can now read, verify and fix meta-data copies > while exposing one consistent structure to users. > Only the .read_mdata() and .write_mdata() callbacks of fwu_mdata_ops > are needed. Get rid of .get_mdata() .update_mdata() .get_mdata_part_num() > .read_mdata_partition() and .write_mdata_partition() and also the > corresponding wrapper functions. > > Signed-off-by: Jassi Brar > Reviewed-by: Etienne Carriere > --- > cmd/fwu_mdata.c | 17 +- > drivers/fwu-mdata/fwu-mdata-uclass.c | 165 --- > drivers/fwu-mdata/gpt_blk.c | 124 +- > include/fwu.h| 199 --- > lib/fwu_updates/fwu.c| 235 --- > 5 files changed, 38 insertions(+), 702 deletions(-) This forgot to update test/dm/fwu_mdata.c and so CI fails: https://source.denx.de/u-boot/u-boot/-/jobs/580820#L347 -- Tom signature.asc Description: PGP signature
Re: [PATCHv4 0/5] FWU: Handle meta-data in common code
On Sat, Feb 04, 2023 at 09:00:56PM -0600, jassisinghb...@gmail.com wrote: > From: Jassi Brar > > The patchset reduces ~400 lines of code, while keeping the functionality same > and making > meta-data operations much faster (by using cached structures). > > Issue: > meta-data copies (primary and secondary) are being handled by the > backend/storage layer > instead of the common core in fwu.c (as also noted by Ilias) that is, > gpt_blk.c manages > meta-data and similarly raw_mtd.c will have to do the same when it arrives. > The code > could by make smaller, cleaner and optimised. > > Basic idea: > Introduce .read_mdata() and .write_mdata() in fwu_mdata_ops that simply > read/write > meta-data copy. The core code takes care of integrity and redundancy of the > meta-data, > as a result we can get rid of every other callback .get_mdata() > .update_mdata() > .get_mdata_part_num() .read_mdata_partition() .write_mdata_partition() and > the > corresponding wrapper functions thereby making the code 100s of LOC smaller. > > Get rid of fwu_check_mdata_validity() and fwu_mdata_check() which expected > underlying > layer to manage and verify mdata copies. > Implement fwu_get_verified_mdata(struct fwu_mdata *mdata) public function > that reads, > verifies and, if needed, fixes the meta-data copies. > > Verified copy of meta-data is now cached as 'g_mdata' in fwu.c, which avoids > multiple > low-level expensive read and parse calls. > gpt meta-data partition numbers are now cached in gpt_blk.c, so that we don't > have to do expensive part_get_info() and uid ops. > > Changes since v3: > * Fix error log wording > * call fwu_write_mdata() with part & PRIMARY_PART ? true: false > > Changes since v2: > * Drop whitespace changes > * Fix missing mdata copy before return > > Changes since v1: > * Fix typos and misc cosmetic changes > * Catch error returns > > > Jassi Brar (5): > fwu: gpt: use cached meta-data partition numbers > fwu: move meta-data management in core > fwu: gpt: implement read_mdata and write_mdata callbacks > fwu: meta-data: switch to management by common code > fwu: rename fwu_get_verified_mdata to fwu_get_mdata > > cmd/fwu_mdata.c | 17 +- > drivers/fwu-mdata/fwu-mdata-uclass.c | 151 +- > drivers/fwu-mdata/gpt_blk.c | 175 +--- > include/fwu.h| 198 ++ > lib/fwu_updates/fwu.c| 294 +++ > 5 files changed, 207 insertions(+), 628 deletions(-) FWIW, aside from the failure I reported, everything else seems fine. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 11/95] Correct SPL use of PHY_CADENCE_SIERRA
On Tue, Feb 21, 2023 at 12:35:41PM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 14 Feb 2023 at 09:31, Tom Rini wrote: > > > > On Sun, Feb 12, 2023 at 04:15:14PM -0700, Simon Glass wrote: > > > This converts 1 usage of this option to the non-SPL form, since there is > > > no SPL_PHY_CADENCE_SIERRA defined in Kconfig > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > (no changes since v1) > > > > > > drivers/phy/cadence/Makefile | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/phy/cadence/Makefile b/drivers/phy/cadence/Makefile > > > index af63b32d9f5..c247feb8262 100644 > > > --- a/drivers/phy/cadence/Makefile > > > +++ b/drivers/phy/cadence/Makefile > > > @@ -1,2 +1,2 @@ > > > -obj-$(CONFIG_$(SPL_)PHY_CADENCE_SIERRA) += phy-cadence-sierra.o > > > +obj-$(CONFIG_PHY_CADENCE_SIERRA) += phy-cadence-sierra.o > > > obj-$(CONFIG_$(SPL_)PHY_CADENCE_TORRENT) += phy-cadence-torrent.o > > > > This, and then PHY_CADENCE_TORRENT take this the wrong direction, both > > symbols should be false for non-PPL builds. > > This one is odd, since the board defines SPL_PHY, presumably for a > reason. It could always undefine that if needed. > > I'll add some more notes in v5. The platforms in question are fairly complex and I want to say it needs a PHY for USB in SPL, but not a PHY for networking, in SPL. -- Tom signature.asc Description: PGP signature
Re: [PATCH 9/9] Makefile: Show binman missing blob message
On Tue, Feb 21, 2023 at 12:41:52PM -0700, Simon Glass wrote: > Hi Jonas > > +Tom Rini > > On Sun, 19 Feb 2023 at 15:02, Jonas Karlman wrote: > > > > When binman is invoked during a build of U-Boot and an external blob is > > missing, the user is usually presented with a generic file not found in > > input path message. > > > > Invoke binman with --allow-missing so that binman can show relevant > > missing blob help messages. Build continue to fail with missing blobs > > unless BINMAN_ALLOW_MISSING=1 is used. > > > > This changes the following error message: > > > > binman: Filename 'atf-bl31' not found in input path (...) > > > > to the following: > > > > Image 'itb' is missing external blobs and is non-functional: atf-blob > > > > /binman/itb/fit/images/atf/atf-blob (bl31.bin): > > See the documentation for your board. You may need to build ARM Trusted > > Firmware and build with BL31=/path/to/bl31.bin > > > > Signed-off-by: Jonas Karlman > > --- > > Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index 58f8c7a35335..c2860824f6f2 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1326,7 +1326,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if > > $(BINMAN_DEBUG),-D) \ > > --toolpath $(objtree)/tools \ > > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ > > build -u -d u-boot.dtb -O . -m \ > > - $(if $(BINMAN_ALLOW_MISSING),--allow-missing > > --ignore-missing) \ > > + --allow-missing $(if > > $(BINMAN_ALLOW_MISSING),--ignore-missing) \ > > -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \ > > -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \ > > $(foreach f,$(BINMAN_INDIRS),-I $(f)) \ > > -- > > 2.39.2 > > > > I agree this is better, but we should see what Tom thinks. > > Reviewed-by: Simon Glass This sounds like a binman bug. We shouldn't need to say --allow-missing to then make use of the missing-msg node. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 00/10] usb: dwc3: Refactor dwc3-generic and apply to dwc3-uniphier
On Wed, Feb 22, 2023 at 04:27:54AM +0100, Marek Vasut wrote: > On 2/22/23 03:00, Kunihiko Hayashi wrote: > > Hi Marek, > > > > On 2023/02/21 0:53, Marek Vasut wrote: > > > On 2/20/23 06:50, Kunihiko Hayashi wrote: > > > > This series achieves refactoring of dwc3-generic. > > > > > > > > First, dwc3-generic allows DT controller nodes to be children of glue > > > > nodes, > > > > but outside of glue nodes. > > > > > > > > To achieve this goal, define a glue-specific function to get controller > > > > node, > > > > look up more reference clocks in the controller node, and initialize > > > > clocks > > > > in children of glue node before access to the controller, > > > > > > > > Next, this series exports the structures and functions from the driver > > > > source > > > > to the header, and replaces dwc3-uniphier driver as one implementation > > > > using > > > > them. This expects dwc3-generic to prevent more SoC-dependent codes. > > > > > > > > The dwc3-uniphier has original USB node, however, tentatively added its > > > > own > > > > node dedicated to U-Boot. After this refactoring, the driver > > > > needs to add > > > > clock entries and PHY driver to enable them corresponding to the > > > > properties > > > > in the original node. > > > > > > > > PATCH 1 has been provided below. > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20221215223822.137739-1-ma...@denx.de/ > > > > > > > > PATCH 2 is based on the suggested patch from Marek. > > > > > > > > PATCH 4-5 and 9-10 have been already reviewed in the previous v1. > > > > https://lists.denx.de/pipermail/u-boot/2023-January/505689.html > > > I think this series is good to go. Do you want to pull this through the > > > uniphier git tree and send PR to Tom that way , or shall I pick it all > > > via usb git tree ? I think the former option is better. > > > > Currently I don't have the public uniphier git tree and > > the maintainership, so I'd like to choose the latter at the moment. > > Colud you please pick it now? > > Applied to usb/next , thanks . > > +CC Tom, I think it would be good to get you a git tree for the uniphier > stuff , what do you think ? Yes, I agree this would be good to take in to my next branch. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 12/24] ringneck-px30: remove check for ENV_IS_NOWHERE, it is an SPL config
On Wed, Feb 22, 2023 at 03:45:17PM +0100, Quentin Schulz wrote: > Hi Troy, > > On 2/22/23 02:38, Troy Kisky wrote: > > When IS_ENABLED(CONFIG_ENV_IS_NOWHERE) is converted to > > CONFIG_IS_ENABLED(ENV_IS_NOWHERE) this will give unwanted errors > > on spl builds. > > > > Signed-off-by: Troy Kisky > > --- > > > > board/theobroma-systems/ringneck_px30/ringneck-px30.c | 4 > > 1 file changed, 4 deletions(-) > > > > diff --git a/board/theobroma-systems/ringneck_px30/ringneck-px30.c > > b/board/theobroma-systems/ringneck_px30/ringneck-px30.c > > index 47d1a40ef7c..bb1bb4acf5c 100644 > > --- a/board/theobroma-systems/ringneck_px30/ringneck-px30.c > > +++ b/board/theobroma-systems/ringneck_px30/ringneck-px30.c > > @@ -118,10 +118,6 @@ int mmc_get_env_dev(void) > > return CONFIG_SYS_MMC_ENV_DEV; > > } > > -#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE) > > -#error Please enable CONFIG_ENV_IS_NOWHERE > > -#endif > > - > > NACK. We absolutely require CONFIG_ENV_IS_NOWHERE for our SoMs in U-Boot OK, so please select it in the config TARGET_... stanza, and make sure doc/board/... explains what's going on. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 19/24] arm: mach-imx: use CONFIG_$(SPL_)SATA instead of CONFIG_SATA
On Tue, Feb 21, 2023 at 05:38:16PM -0800, Troy Kisky wrote: > This avoid an error with enable_sata_clock when > defined(CONFIG_SATA) is changed to CONFIG_IS_ENABLED(SATA). > > Signed-off-by: Troy Kisky > --- > > arch/arm/mach-imx/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile > index 4dfc60eedc4..50f26975eac 100644 > --- a/arch/arm/mach-imx/Makefile > +++ b/arch/arm/mach-imx/Makefile > @@ -54,7 +54,7 @@ obj-$(CONFIG_IMX_RDC) += rdc-sema.o > ifneq ($(CONFIG_SPL_BUILD),y) > obj-$(CONFIG_IMX_BOOTAUX) += imx_bootaux.o > endif > -obj-$(CONFIG_SATA) += sata.o > +obj-$(CONFIG_$(SPL_)SATA) += sata.o > obj-$(CONFIG_IMX_HAB)+= hab.o > obj-$(CONFIG_SYSCOUNTER_TIMER) += syscounter.o > endif In that Simon thinks the $(SPL_) syntax here is ugly, lets just move this line in to the existing guard for non-SPL builds, with imx_bootaux.o. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 21/24] gateworks: venice: surround call of setup_fec with if IS_ENABLED(CONFIG_NET)
On Tue, Feb 21, 2023 at 05:38:18PM -0800, Troy Kisky wrote:
> This is the same as the definition is surrounded by.
> It avoids an error in converting to CONFIG_IS_ENABLED(NET).
>
> Signed-off-by: Troy Kisky
> ---
>
> board/gateworks/venice/venice.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/board/gateworks/venice/venice.c b/board/gateworks/venice/venice.c
> index c4d86c26a9b..ad27835caaf 100644
> --- a/board/gateworks/venice/venice.c
> +++ b/board/gateworks/venice/venice.c
> @@ -41,7 +41,7 @@ int board_fit_config_name_match(const char *name)
> return -1;
> }
>
> -#if (IS_ENABLED(CONFIG_NET))
> +#if IS_ENABLED(CONFIG_NET)
> static int setup_fec(void)
> {
> struct iomuxc_gpr_base_regs *gpr =
> @@ -113,10 +113,12 @@ int board_init(void)
> {
> venice_eeprom_init(1);
>
> +#if IS_ENABLED(CONFIG_NET)
> if (IS_ENABLED(CONFIG_FEC_MXC))
> setup_fec();
> if (IS_ENABLED(CONFIG_DWC_ETH_QOS))
> setup_eqos();
> +#endif
>
> return 0;
> }
We should be able to not-guard setup_fec (and setup_eqos), as if
(IS_ENABLED(...)) will lead to the compiler optimizing it all away, but
if (0) { func() } shouldn't result in unused function warnings.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1 18/24] solidrun: mx6cuboxi: use CONFIG_IS_ENABLED(SATA) instead of CONFIG_CMD_SATA
On Tue, Feb 21, 2023 at 05:38:15PM -0800, Troy Kisky wrote:
> setup_sata is linked with
> obj-$(CONFIG_SATA) += sata.o
>
> So use SATA instead of CMD_SATA.
>
> Signed-off-by: Troy Kisky
> ---
>
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 7c44379ec4a..e31a7e9552f 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -275,7 +275,7 @@ int board_early_init_f(void)
> {
> setup_iomux_uart();
>
> -#ifdef CONFIG_CMD_SATA
> +#if CONFIG_IS_ENABLED(SATA)
> setup_sata();
> #endif
> setup_fec();
Note that wandboard needs a similar fix.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v1 17/24] ns16550: match when to define bdf with uart code
On Tue, Feb 21, 2023 at 05:38:14PM -0800, Troy Kisky wrote:
> When switching defined(CONFIG_PCI) to CONFIG_IS_ENABLED(PCI)
> bdf is no longer accessible. So change to preprocessor to avoid access.
>
> Signed-off-by: Troy Kisky
> ---
>
> arch/x86/cpu/apollolake/uart.c | 6 +++---
> include/ns16550.h | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/cpu/apollolake/uart.c b/arch/x86/cpu/apollolake/uart.c
> index a9362436000..143217755ff 100644
> --- a/arch/x86/cpu/apollolake/uart.c
> +++ b/arch/x86/cpu/apollolake/uart.c
> @@ -79,11 +79,11 @@ void apl_uart_init(pci_dev_t bdf, ulong base)
>
> static int apl_ns16550_probe(struct udevice *dev)
> {
> +#if !CONFIG_IS_ENABLED(PCI)
> struct apl_ns16550_plat *plat = dev_get_plat(dev);
>
> - if (!CONFIG_IS_ENABLED(PCI))
> - apl_uart_init(plat->ns16550.bdf, plat->ns16550.base);
> -
> + apl_uart_init(plat->ns16550.bdf, plat->ns16550.base);
> +#endif
> return ns16550_serial_probe(dev);
> }
>
> diff --git a/include/ns16550.h b/include/ns16550.h
> index e7e68663d03..8d7eb7d8f9c 100644
> --- a/include/ns16550.h
> +++ b/include/ns16550.h
> @@ -74,7 +74,7 @@ struct ns16550_plat {
> int clock;
> u32 fcr;
> int flags;
> -#if defined(CONFIG_PCI) && defined(CONFIG_SPL)
> +#if !CONFIG_IS_ENABLED(PCI) || CONFIG_IS_ENABLED(OF_PLATDATA)
> int bdf;
> #endif
> };
This isn't equivalent. This means platforms such as am335x_evm which do
not enable PCI nor SPL_PCI now get this field and grow their rodata.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On Wed, Feb 22, 2023 at 10:19:03AM -0800, Vagrant Cascadian wrote: > On 2023-02-21, Vagrant Cascadian wrote: > > On 2023-02-21, Simon Glass wrote: > >> This board has moved to standard boot but the old 'distro_bootcmd' > >> command is still active. Disable DISTRO_DEFAULTS to fix this. > > > > Works for booting rockpro64-rk3399, thanks! > > I can also confirm that applying a very similar patch for > pinebook-pro-rk3399 works booting with bootstd. > > Seems worth adding if there is a v2 of the patch series. > > Alternately, rather than doing this on a board-by-board basis, is there > some way to disable CONFIG_DISTRO_DEFAULTS when a board is using > BOOTSTD? I think that's possibly a bit dangerous? DISTRO_DEFAULTS and BOOTSTD_DEFAULTS need to be reconciled to a single new symbol, and the DISTRO_DEFAULTS method of select not imply for most things is also I suspect the right path. -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/next
On Wed, Feb 22, 2023 at 04:36:08PM +0100, Marek Vasut wrote: > The following changes since commit 4eb7c5030d3f3c707c02a64dc8ea90de3da89928: > > Merge tag 'efi-2023-04-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-02-19 17:03:30 > -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next This seems to be based on current master and not current next, can you please rebase? -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On Wed, Feb 22, 2023 at 11:58:37AM -0700, Simon Glass wrote: > Hi, > > On Wed, 22 Feb 2023 at 11:56, Jonas Karlman wrote: > > > > On 2023-02-22 19:24, Tom Rini wrote: > > > On Wed, Feb 22, 2023 at 10:19:03AM -0800, Vagrant Cascadian wrote: > > >> On 2023-02-21, Vagrant Cascadian wrote: > > >>> On 2023-02-21, Simon Glass wrote: > > >>>> This board has moved to standard boot but the old 'distro_bootcmd' > > >>>> command is still active. Disable DISTRO_DEFAULTS to fix this. > > >>> > > >>> Works for booting rockpro64-rk3399, thanks! > > >> > > >> I can also confirm that applying a very similar patch for > > >> pinebook-pro-rk3399 works booting with bootstd. > > >> > > >> Seems worth adding if there is a v2 of the patch series. > > >> > > >> Alternately, rather than doing this on a board-by-board basis, is there > > >> some way to disable CONFIG_DISTRO_DEFAULTS when a board is using > > >> BOOTSTD? > > > > > > I think that's possibly a bit dangerous? DISTRO_DEFAULTS and > > > BOOTSTD_DEFAULTS need to be reconciled to a single new symbol, and the > > > DISTRO_DEFAULTS method of select not imply for most things is also I > > > suspect the right path. > > > > > > > Another option would be to set BOOTSTD_BOOTCOMMAND=y, this is the main > > issue with rk3399 at the moment, distro_bootcmd got removed from env, > > yet bootcmd is still "run distro_bootcmd" due to DISTRO_DEFAULTS=y. > > > > > > config BOOTCOMMAND > > default "bootflow scan -lb" if BOOTSTD_BOOTCOMMAND && > > CMD_BOOTFLOW_FULL > > default "bootflow scan" if BOOTSTD_BOOTCOMMAND && !CMD_BOOTFLOW_FULL > > default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && > > DISTRO_DEFAULTS > > > > config BOOTSTD_BOOTCOMMAND > > default y if !DISTRO_DEFAULTS > > That seems reasonable to me, along with a 'depends on BOOTSTD' > > At present DISTRO_DEFAULTS is both enabled in defconfig files (about > 350) and Kconfig (another 300). For rockchip it is the latter. > > It doesn't really make sense to use DISTRO_DEFAULTS when using > BOOTSTD_DEFAULTS. One is 'run distro_bootcmd' and the other is > 'bootflow scan', possibly with -lb flags. But we really don't want > people flipping back and forward. It doesn't make linguistic sense to have "distro defaults" and "bootstd defaults" enabled. It makes compute sense to have these two symbols combined as they're nearly identical and have a similar conceptual need (make sure we have things like bootz/booti/ext4/etc support). -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] rockchip: Disable DISTRO_DEFAULTS for rockpro64
On Wed, Feb 22, 2023 at 12:03:58PM -0700, Simon Glass wrote: > Hi Tom, > > On Wed, 22 Feb 2023 at 12:01, Tom Rini wrote: > > > > On Wed, Feb 22, 2023 at 11:58:37AM -0700, Simon Glass wrote: > > > Hi, > > > > > > On Wed, 22 Feb 2023 at 11:56, Jonas Karlman wrote: > > > > > > > > On 2023-02-22 19:24, Tom Rini wrote: > > > > > On Wed, Feb 22, 2023 at 10:19:03AM -0800, Vagrant Cascadian wrote: > > > > >> On 2023-02-21, Vagrant Cascadian wrote: > > > > >>> On 2023-02-21, Simon Glass wrote: > > > > >>>> This board has moved to standard boot but the old 'distro_bootcmd' > > > > >>>> command is still active. Disable DISTRO_DEFAULTS to fix this. > > > > >>> > > > > >>> Works for booting rockpro64-rk3399, thanks! > > > > >> > > > > >> I can also confirm that applying a very similar patch for > > > > >> pinebook-pro-rk3399 works booting with bootstd. > > > > >> > > > > >> Seems worth adding if there is a v2 of the patch series. > > > > >> > > > > >> Alternately, rather than doing this on a board-by-board basis, is > > > > >> there > > > > >> some way to disable CONFIG_DISTRO_DEFAULTS when a board is using > > > > >> BOOTSTD? > > > > > > > > > > I think that's possibly a bit dangerous? DISTRO_DEFAULTS and > > > > > BOOTSTD_DEFAULTS need to be reconciled to a single new symbol, and the > > > > > DISTRO_DEFAULTS method of select not imply for most things is also I > > > > > suspect the right path. > > > > > > > > > > > > > Another option would be to set BOOTSTD_BOOTCOMMAND=y, this is the main > > > > issue with rk3399 at the moment, distro_bootcmd got removed from env, > > > > yet bootcmd is still "run distro_bootcmd" due to DISTRO_DEFAULTS=y. > > > > > > > > > > > > config BOOTCOMMAND > > > > default "bootflow scan -lb" if BOOTSTD_BOOTCOMMAND && > > > > CMD_BOOTFLOW_FULL > > > > default "bootflow scan" if BOOTSTD_BOOTCOMMAND && > > > > !CMD_BOOTFLOW_FULL > > > > default "run distro_bootcmd" if !BOOTSTD_BOOTCOMMAND && > > > > DISTRO_DEFAULTS > > > > > > > > config BOOTSTD_BOOTCOMMAND > > > > default y if !DISTRO_DEFAULTS > > > > > > That seems reasonable to me, along with a 'depends on BOOTSTD' > > > > > > At present DISTRO_DEFAULTS is both enabled in defconfig files (about > > > 350) and Kconfig (another 300). For rockchip it is the latter. > > > > > > It doesn't really make sense to use DISTRO_DEFAULTS when using > > > BOOTSTD_DEFAULTS. One is 'run distro_bootcmd' and the other is > > > 'bootflow scan', possibly with -lb flags. But we really don't want > > > people flipping back and forward. > > > > It doesn't make linguistic sense to have "distro defaults" and "bootstd > > defaults" enabled. It makes compute sense to have these two symbols > > combined as they're nearly identical and have a similar conceptual need > > (make sure we have things like bootz/booti/ext4/etc support). > > Oh, so you are talking about DISTRO_DEFAULTS, not the actual command? > In that case I can do a patch to make them both use a common symbol to > bring in most stuff, although bootstd does not need hush and a few > other things that are needed by distro_bootcmd. > > Let me know if that makes sense. Yeah, the Kconfig symbols DISTRO_DEFAULTS and BOOTSTD_DEFAULTS need to be reconciled and combined. This is separate from setting bootcmd to "run distro_bootcmd", which should be separate, and yes, not be the chosen symbol when we have bootstd enabled. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 68/95] socfpga: Use the correct condition for SYS_L2_PL310
On Wed, Feb 22, 2023 at 12:16:53PM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 14 Feb 2023 at 09:38, Tom Rini wrote:
> >
> > On Sun, Feb 12, 2023 at 04:16:11PM -0700, Simon Glass wrote:
> >
> > > Update this to use the PPL condition instead, so that nothing changes when
> > > building for SPL with split config.
> > >
> > > Signed-off-by: Simon Glass
> > > ---
> > >
> > > (no changes since v1)
> > >
> > > arch/arm/mach-socfpga/misc.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> > > index 5b5a81a255d..b09b898051b 100644
> > > --- a/arch/arm/mach-socfpga/misc.c
> > > +++ b/arch/arm/mach-socfpga/misc.c
> > > @@ -32,7 +32,7 @@ phys_addr_t socfpga_clkmgr_base __section(".data");
> > > phys_addr_t socfpga_rstmgr_base __section(".data");
> > > phys_addr_t socfpga_sysmgr_base __section(".data");
> > >
> > > -#ifdef CONFIG_SYS_L2_PL310
> > > +#ifdef CONFIG_PPL_SYS_L2_PL310
> > > static const struct pl310_regs *const pl310 =
> > > (struct pl310_regs *)CFG_SYS_PL310_BASE;
> > > #endif
> > > @@ -66,7 +66,7 @@ void enable_caches(void)
> > > #endif
> > > }
> > >
> > > -#ifdef CONFIG_SYS_L2_PL310
> > > +#ifdef CONFIG_PPL_SYS_L2_PL310
> > > void v7_outer_cache_enable(void)
> > > {
> > > struct udevice *dev;
> >
> > Why can we not continue to use CONFIG_SYS_L2_PL310 in this case?
>
> This is because the code is compiled for SPL too, iwc that option is
> not enabled with split config.
>
> For now I'll move it to the mythical 'splg' series (that actually does
> split config)
That this is discarded normally, today, as seems intentional:
$ make socfpga_socrates_defconfig
#
# configuration written to .config
#
$ grep PL310 .config
CONFIG_SYS_L2_PL310=y
# CONFIG_SPL_SYS_L2_PL310 is not set
$
But needs changes like this with split config is worrisome.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 9/9] Makefile: Show binman missing blob message
On Wed, Feb 22, 2023 at 02:20:08PM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 21 Feb 2023 at 16:09, Tom Rini wrote: > > > > On Tue, Feb 21, 2023 at 12:41:52PM -0700, Simon Glass wrote: > > > Hi Jonas > > > > > > +Tom Rini > > > > > > On Sun, 19 Feb 2023 at 15:02, Jonas Karlman wrote: > > > > > > > > When binman is invoked during a build of U-Boot and an external blob is > > > > missing, the user is usually presented with a generic file not found in > > > > input path message. > > > > > > > > Invoke binman with --allow-missing so that binman can show relevant > > > > missing blob help messages. Build continue to fail with missing blobs > > > > unless BINMAN_ALLOW_MISSING=1 is used. > > > > > > > > This changes the following error message: > > > > > > > > binman: Filename 'atf-bl31' not found in input path (...) > > > > > > > > to the following: > > > > > > > > Image 'itb' is missing external blobs and is non-functional: atf-blob > > > > > > > > /binman/itb/fit/images/atf/atf-blob (bl31.bin): > > > > See the documentation for your board. You may need to build ARM > > > > Trusted > > > > Firmware and build with BL31=/path/to/bl31.bin > > > > > > > > Signed-off-by: Jonas Karlman > > > > --- > > > > Makefile | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/Makefile b/Makefile > > > > index 58f8c7a35335..c2860824f6f2 100644 > > > > --- a/Makefile > > > > +++ b/Makefile > > > > @@ -1326,7 +1326,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if > > > > $(BINMAN_DEBUG),-D) \ > > > > --toolpath $(objtree)/tools \ > > > > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ > > > > build -u -d u-boot.dtb -O . -m \ > > > > - $(if $(BINMAN_ALLOW_MISSING),--allow-missing > > > > --ignore-missing) \ > > > > + --allow-missing $(if > > > > $(BINMAN_ALLOW_MISSING),--ignore-missing) \ > > > > -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \ > > > > -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \ > > > > $(foreach f,$(BINMAN_INDIRS),-I $(f)) \ > > > > -- > > > > 2.39.2 > > > > > > > > > > I agree this is better, but we should see what Tom thinks. > > > > > > Reviewed-by: Simon Glass > > > > This sounds like a binman bug. We shouldn't need to say --allow-missing > > to then make use of the missing-msg node. > > Without --allow-missing binman just dies when it cannot find > something. This is useful because it allows debugging of problems. > > I'm not sure how easy it would be to change this. The error is > reported by the tools module which has no knowledge of binman. We > could catch the exception, but again that makes things non-debuggable. Why wouldn't it be debuggable? Wouldn't it be more debuggable now that we're saying "You're missing foo.blob, this is typically provided by the foo project", which we can just say because the message has been filled out already in the etype. > At the moment we have two cases: > - normal: missing files cause an immediate abort > - --allow-missing: missing files are collected with a report at the end > > Worse, we can have missing tools, not just missing blobs. The > complexity of this gets completely out of hand if we try to meld the > normal and --allow-missing cases together. > > I actually don't see much of a downside to passing allow-missing > always. But perhaps the BINMAN_ALLOW_MISSING should be renamed to > BINMAN_IGNORE_MISSING (with a similar change in buildman). We could > actually keep BINMAN_ALLOW_MISSING to mean to pass --allow-missing, > pointing out in the docs that this is a bad idea as you won't see any > blob help? Maybe the problem is the flag is badly named? I still think this speaks to bugs in the tooling if we can't make use of the helpful error message that we have available without some special flags to be set. -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-socfpga/master
On Wed, Feb 22, 2023 at 02:04:43AM +0100, Marek Vasut wrote: > The following changes since commit 4eb7c5030d3f3c707c02a64dc8ea90de3da89928: > > Merge tag 'efi-2023-04-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-02-19 17:03:30 > -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-socfpga.git master > > for you to fetch changes up to 52b8fca7178afdcacb31cfcdfea9429779d084a1: > > chameleonv3: Convert CONFIG_SPL_MAX_SIZE to Kconfig (2023-02-22 00:28:39 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/master
On Wed, Feb 22, 2023 at 05:27:16PM +0100, Marek Vasut wrote: > The following changes since commit 4eb7c5030d3f3c707c02a64dc8ea90de3da89928: > > Merge tag 'efi-2023-04-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-02-19 17:03:30 > -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git master > > for you to fetch changes up to 237d1f60b1db52074441bc3a5848fe98503726a2: > > usb: dwc3: Use the devm_gpiod_get_optional() API for reset gpio > (2023-02-22 00:28:05 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/next
On Wed, Feb 22, 2023 at 11:09:00PM +0100, Marek Vasut wrote: > On 2/22/23 19:37, Tom Rini wrote: > > On Wed, Feb 22, 2023 at 04:36:08PM +0100, Marek Vasut wrote: > > > > > The following changes since commit > > > 4eb7c5030d3f3c707c02a64dc8ea90de3da89928: > > > > > >Merge tag 'efi-2023-04-rc3' of > > > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-02-19 17:03:30 > > > -0500) > > > > > > are available in the Git repository at: > > > > > >git://source.denx.de/u-boot-usb.git next > > > > This seems to be based on current master and not current next, can you > > please rebase? > > Try below, build just passed > > The following changes since commit 2bfd217a16978794b43f0a30111b7472fba232b6: > > Merge tag 'dm-next-valentine' of > https://source.denx.de/u-boot/custodians/u-boot-dm into next (2023-02-14 > 15:11:37 -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next > > for you to fetch changes up to aeb8b59f2f4aeb02ac87ec39f834177a0e260f85: > > uniphier_defconfig: Disable USB_XHCI_DWC3 (2023-02-22 19:40:11 +0100) > > > Kunihiko Hayashi (9): > usb: dwc3-generic: Allow different controller DT node pattern > usb: dwc3-generic: Add clock initialization in child DT node > usb: dwc3-generic: Export glue structures and functions > usb: dwc3-generic: Add the size of regs property to glue structure > reset: uniphier: Add USB glue reset support > clk: uniphier: Add missing USB SS-PHY clocks > phy: socionext: Add UniPhier USB3 PHY driver > usb: dwc3-uniphier: Use dwc3-generic instead of xhci-dwc3 > uniphier_defconfig: Disable USB_XHCI_DWC3 > > Marek Vasut (1): > usb: dwc3: Look up reference clock DT phandle in both controller DT > nodes Getting there. I see: +(uniphier_v8 uniphier_v7) WARNING: unmet direct dependencies detected for PHY_UNIPHIER_USB3 +(uniphier_v8 uniphier_v7) Depends on [n]: PHY [=n] && ARCH_UNIPHIER [=y] +(uniphier_v8 uniphier_v7) Selected by [y]: +(uniphier_v8 uniphier_v7) - USB_DWC3_UNIPHIER [=y] && USB [=y] && ARCH_UNIPHIER [=y] && USB_DWC3 [=y] Which I will take a quick run at fixing, if you don't, shortly. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 1/1] tools: env: use /run to store lockfile
On Thu, Feb 23, 2023 at 01:06:20AM +, chl...@nuvoton.com wrote: > Hi Tom, > > Is this commit valuable to merge into u-boot upstream? > Thanks your reviewing, just ping this event friendly. Yes, I'll be putting this in next soon, thanks. > > Best regards, > Tim > > -----Original Message- > From: Tom Rini > Sent: Friday, February 10, 2023 11:30 PM > To: Tim Lee > Cc: s...@chromium.org; CS20 CHLi30 ; u-boot@lists.denx.de > Subject: Re: [PATCH v1 1/1] tools: env: use /run to store lockfile > > On Fri, Feb 10, 2023 at 05:05:39PM +0800, Tim Lee wrote: > > > According this issue https://github.com/ppp-project/ppp/issues/339. > > Eventually, the dt-utils changed lock directory to fix missing > > /var/lock directory error then make dt-utils can run normally. > > > > We also have a similar issue with these two utilities fw_printenv and > > fw_setenv will failed when the directory /var/lock is non-existent. > > > > We have a custom linux distribution built with yocto (OpenBMC) that > > use systemd and it deprecated the /var/lock directory. > > More discussion in systemd/systemd#15668. > > > > Thus, we sync with community's solution for uboot/tools/env utilities: > > The current location /var/lock is considered legacy (at least by systemd). > > Just use /run to store the lockfile and append the usual .lock suffix. > > > > Tested: > > Verified /run/lock is now present and fw_printenv can work in OpenBMC. > > > > Signed-off-by: Tim Lee > > Reviewed-by: Tom Rini > > -- > Tom > > > The privileged confidential information contained in this email is intended > for use only by the addressees as indicated by the original sender of this > email. If you are not the addressee indicated in this email or are not > responsible for delivery of the email to such a person, please kindly reply > to the sender indicating this fact and delete all copies of it from your > computer and network server immediately. Your cooperation is highly > appreciated. It is advised that any unauthorized use of confidential > information of Nuvoton is strictly prohibited; and any information in this > email irrelevant to the official business of Nuvoton shall be deemed as > neither given nor endorsed by Nuvoton. -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: bzip2: remove inlining
On Thu, Feb 23, 2023 at 08:15:25AM +0100, Heinrich Schuchardt wrote: > Compiling sandbox_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y and > gcc 12.2.0-14ubuntu1 leads to a build error: > > lib/bzip2/bzlib.c: In function 'BZ2_decompress': > lib/bzip2/bzlib.c:726:18: error: inlining failed in call to > 'always_inline' 'BZ2_indexIntoF': function not considered for inlining > 726 | __inline__ Int32 BZ2_indexIntoF ( Int32 indx, Int32 *cftab ) > | ^ > > Leave it to the compiler if it inlines or not. > > Signed-off-by: Heinrich Schuchardt What did previous compilers do here? If we're telling the compiler to always inline, presumably for good reason, we shouldn't just stop. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] env: mmc: Clean up macro usage
On Thu, Feb 23, 2023 at 02:22:51PM +0100, Marek Vasut wrote:
> On 2/23/23 11:41, Patrick DELAUNAY wrote:
> > Hi Marek,
>
> Hi,
>
> > On 2/9/23 13:30, Marek Vasut wrote:
> > > Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of
> > > mix of ifdef.
> > >
> > > Signed-off-by: Marek Vasut
> > > ---
> > > Cc: Patrice Chotard
> > > Cc: Patrick Delaunay
> > > Cc: Tom Rini
> > > ---
> > > V2: Replace CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) with
> > > IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)
> > > ---
> > > env/mmc.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/env/mmc.c b/env/mmc.c
> > > index 5b01f657a7a..d51a5579128 100644
> > > --- a/env/mmc.c
> > > +++ b/env/mmc.c
> > > @@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const
> > > char *str, int copy, s64 *val)
> > > if (str && !strncmp((const char *)info.name, str,
> > > sizeof(info.name)))
> > > break;
> > > -#ifdef CONFIG_PARTITION_TYPE_GUID
> > > - if (!str) {
> > > + if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID) && !str) {
> > > const efi_guid_t env_guid = PARTITION_U_BOOT_ENVIRONMENT;
> > > efi_guid_t type_guid;
> > > @@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const
> > > char *str, int copy, s64 *val)
> > > if (!memcmp(&env_guid, &type_guid, sizeof(efi_guid_t)))
> > > break;
> > > }
> > > -#endif
> > > }
> > > /* round up to info.blksz */
> >
> >
> > If I remenber, I try this test with IS_ENABLED when I propose my patch
> >
> > and I have compilation issue on next line
> >
> >
> > + uuid_str_to_bin(info.type_guid, type_guid.b,
> > UUID_STR_FORMAT_GUID);
> >
> >
> > because "info.type_guid" don't exist in struct disk_partition
> >
> > see ./include/part.h:59
> >
> >
> > struct disk_partition {
> > lbaint_t start; /* # of first block in partition */
> > ...
> > #ifdef CONFIG_PARTITION_TYPE_GUID
> > char type_guid[UUID_STR_LEN + 1]; /* type GUID as string, if
> > exists */
> > #endif
> > ...
> > };
>
> Uh, which defconfig triggers this ?
>
> Also, is there a way to deal with this failure without reinstating the ifdef
> ? Tom ?
It's likely on one of the platforms that disables EFI_LOADER, where this
ends up being a fail to build. I don't recall which, but I've seen it
before. So we probably don't end up converting this to a macro check.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] usb: dwc3-uniphier: Select PHY
On Thu, Feb 23, 2023 at 05:29:24PM +0100, Marek Vasut wrote: > Make sure the PHY subsystem is activated for the uniphier DWC3 glue > logic, as it depends on PHY implementation there. > > Signed-off-by: Marek Vasut Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/next
On Wed, Feb 22, 2023 at 11:09:00PM +0100, Marek Vasut wrote: > On 2/22/23 19:37, Tom Rini wrote: > > On Wed, Feb 22, 2023 at 04:36:08PM +0100, Marek Vasut wrote: > > > > > The following changes since commit > > > 4eb7c5030d3f3c707c02a64dc8ea90de3da89928: > > > > > >Merge tag 'efi-2023-04-rc3' of > > > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-02-19 17:03:30 > > > -0500) > > > > > > are available in the Git repository at: > > > > > >git://source.denx.de/u-boot-usb.git next > > > > This seems to be based on current master and not current next, can you > > please rebase? > > Try below, build just passed > > The following changes since commit 2bfd217a16978794b43f0a30111b7472fba232b6: > > Merge tag 'dm-next-valentine' of > https://source.denx.de/u-boot/custodians/u-boot-dm into next (2023-02-14 > 15:11:37 -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next > > for you to fetch changes up to aeb8b59f2f4aeb02ac87ec39f834177a0e260f85: > > uniphier_defconfig: Disable USB_XHCI_DWC3 (2023-02-22 19:40:11 +0100) > > > Kunihiko Hayashi (9): > usb: dwc3-generic: Allow different controller DT node pattern > usb: dwc3-generic: Add clock initialization in child DT node > usb: dwc3-generic: Export glue structures and functions > usb: dwc3-generic: Add the size of regs property to glue structure > reset: uniphier: Add USB glue reset support > clk: uniphier: Add missing USB SS-PHY clocks > phy: socionext: Add UniPhier USB3 PHY driver > usb: dwc3-uniphier: Use dwc3-generic instead of xhci-dwc3 > uniphier_defconfig: Disable USB_XHCI_DWC3 > > Marek Vasut (1): > usb: dwc3: Look up reference clock DT phandle in both controller DT > nodes > > configs/uniphier_v7_defconfig | 1 - > configs/uniphier_v8_defconfig | 1 - > drivers/clk/uniphier/clk-uniphier-sys.c | 5 +++ > drivers/phy/socionext/Kconfig | 8 + > drivers/phy/socionext/Makefile| 1 + > drivers/phy/socionext/phy-uniphier-usb3.c | 168 > +++ > drivers/reset/reset-uniphier.c| 78 > +- > drivers/usb/dwc3/Kconfig | 4 ++- > drivers/usb/dwc3/dwc3-generic.c | 132 > --- > drivers/usb/dwc3/dwc3-generic.h | 33 ++ > drivers/usb/dwc3/dwc3-uniphier.c | 116 > +-- > 11 files changed, 453 insertions(+), 94 deletions(-) > create mode 100644 drivers/phy/socionext/phy-uniphier-usb3.c > create mode 100644 drivers/usb/dwc3/dwc3-generic.h Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: bzip2: remove inlining
On Thu, Feb 23, 2023 at 05:39:08PM +0100, Heinrich Schuchardt wrote: > On 2/23/23 17:30, Tom Rini wrote: > > On Thu, Feb 23, 2023 at 08:15:25AM +0100, Heinrich Schuchardt wrote: > > > Compiling sandbox_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y and > > > gcc 12.2.0-14ubuntu1 leads to a build error: > > > > > > lib/bzip2/bzlib.c: In function 'BZ2_decompress': > > > lib/bzip2/bzlib.c:726:18: error: inlining failed in call to > > > 'always_inline' 'BZ2_indexIntoF': function not considered for > > > inlining > > >726 | __inline__ Int32 BZ2_indexIntoF ( Int32 indx, Int32 *cftab ) > > >| ^ > > > > > > Leave it to the compiler if it inlines or not. > > > > > > Signed-off-by: Heinrich Schuchardt > > > > What did previous compilers do here? If we're telling the compiler to > > always inline, presumably for good reason, we shouldn't just stop. > > > > Inlining may make the code a bit faster. But without inlining it would be > smaller. Grep for BZ_GET_SMALL to find where the inlined function is used. > > In test/compression.c we check the result. 'ut compression' does not find a > problem. OK, and I'm wondering if the compiler regressed. -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: bzip2: remove inlining
On Thu, Feb 23, 2023 at 10:53:44PM +0100, Heinrich Schuchardt wrote: > > > On 2/23/23 17:40, Tom Rini wrote: > > On Thu, Feb 23, 2023 at 05:39:08PM +0100, Heinrich Schuchardt wrote: > > > On 2/23/23 17:30, Tom Rini wrote: > > > > On Thu, Feb 23, 2023 at 08:15:25AM +0100, Heinrich Schuchardt wrote: > > > > > Compiling sandbox_defconfig with CONFIG_CC_OPTIMIZE_FOR_DEBUG=y and > > > > > gcc 12.2.0-14ubuntu1 leads to a build error: > > > > > > > > > > lib/bzip2/bzlib.c: In function 'BZ2_decompress': > > > > > lib/bzip2/bzlib.c:726:18: error: inlining failed in call to > > > > > 'always_inline' 'BZ2_indexIntoF': function not considered for > > > > > inlining > > > > > 726 | __inline__ Int32 BZ2_indexIntoF ( Int32 indx, Int32 > > > > > *cftab ) > > > > > | ^ > > > > > > > > > > Leave it to the compiler if it inlines or not. > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > > > > What did previous compilers do here? If we're telling the compiler to > > > > always inline, presumably for good reason, we shouldn't just stop. > > > > > > > > > > Inlining may make the code a bit faster. But without inlining it would be > > > smaller. Grep for BZ_GET_SMALL to find where the inlined function is used. > > > > > > In test/compression.c we check the result. 'ut compression' does not find > > > a > > > problem. > > > > OK, and I'm wondering if the compiler regressed. > > > > CONFIG_CC_OPTIMIZE_FOR_DEBUG is not used in any of our defconfigs and has > been introduced long after bzip2. > > Typically CONFIG_CC_OPTIMIZE_FOR_DEBUG is used in conjunction with > CONFIG_LTO=n. In this case the error does not occur. > > It seems that gcc with -Og -flto has an issue. OK, so this combination is fine with: gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0 Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. So I'd really like to get some compiler people to confirm that there's not a regression on their end here. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1 19/24] arm: mach-imx: use CONFIG_$(SPL_)SATA instead of CONFIG_SATA
On Thu, Feb 23, 2023 at 11:23:47AM -0800, Troy Kisky wrote: > On Wed, Feb 22, 2023 at 7:05 AM Tom Rini wrote: > > > On Tue, Feb 21, 2023 at 05:38:16PM -0800, Troy Kisky wrote: > > > > > This avoid an error with enable_sata_clock when > > > defined(CONFIG_SATA) is changed to CONFIG_IS_ENABLED(SATA). > > > > > > Signed-off-by: Troy Kisky > > > --- > > > > > > arch/arm/mach-imx/Makefile | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile > > > index 4dfc60eedc4..50f26975eac 100644 > > > --- a/arch/arm/mach-imx/Makefile > > > +++ b/arch/arm/mach-imx/Makefile > > > @@ -54,7 +54,7 @@ obj-$(CONFIG_IMX_RDC) += rdc-sema.o > > > ifneq ($(CONFIG_SPL_BUILD),y) > > > obj-$(CONFIG_IMX_BOOTAUX) += imx_bootaux.o > > > endif > > > -obj-$(CONFIG_SATA) += sata.o > > > +obj-$(CONFIG_$(SPL_)SATA) += sata.o > > > obj-$(CONFIG_IMX_HAB)+= hab.o > > > obj-$(CONFIG_SYSCOUNTER_TIMER) += syscounter.o > > > endif > > > > In that Simon thinks the $(SPL_) syntax here is ugly, lets just move > > this line in to the existing guard for non-SPL builds, with > > imx_bootaux.o. > > > > -- > > Tom > > > > Hi Tom > > I don't think that does the same thing for mach-mvebu. > > arch/arm/mach-mvebu/Kconfig-config MVEBU_SPL_BOOT_DEVICE_SATA > arch/arm/mach-mvebu/Kconfig-bool "SATA" > arch/arm/mach-mvebu/Kconfig:imply SPL_SATA > > Shouldn't it be linked in SPL builds as well for that one? Well, OK. I see there's not yet SPL_SATA functional on imx, but, when the time comes, that file is likely to be used, so this change make sense, thanks for explaining. -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] configs: j7200: Merge HS and non-HS defconfigs
On Wed, Feb 22, 2023 at 09:02:12AM -0600, Andrew Davis wrote: > On 2/22/23 1:56 AM, Manorit Chawdhry wrote: > > K3 devices have runtime type board detection. Make the default defconfig > > include the secure configuration. Then remove the HS specific config. > > > > Non-HS devices will continue to boot due to runtime device type detection. > > If TI_SECURE_DEV_PKG is not set the build will emit warnings, for non-HS > > devices these can be ignored. > > > > Signed-off-by: Manorit Chawdhry > > --- > > This will help with keeping the HS and non-HS configs in sync :) > > Acked-by: Andrew Davis Please re-spin both of these to update the MAINTAINERS file as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH] lmb: Bump CONFIG_LMB_MAX_REGIONS
On Thu, Feb 23, 2023 at 10:24:44AM +0100, Patrick DELAUNAY wrote:
> Hi,
>
> On 2/17/23 10:28, Michal Suchánek wrote:
> > Hello,
> >
> > On Sun, Feb 12, 2023 at 06:45:36PM -0500, Tom Rini wrote:
> > > On Wed, Feb 08, 2023 at 02:50:16PM -0500, Tom Rini wrote:
> > > > On Wed, Feb 08, 2023 at 08:11:34PM +0100, Michal Suchánek wrote:
> > > > > Hello,
> > > > >
> > > > > On Wed, Feb 08, 2023 at 01:25:50PM -0500, Tom Rini wrote:
> > > > > > On Wed, Feb 08, 2023 at 07:24:25PM +0100, Francesco Dolcini wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > On Fri, Jan 27, 2023 at 08:54:55AM -0500, Tom Rini wrote:
> > > > > > > > On Fri, Jan 27, 2023 at 02:00:12PM +0100, Michal Suchanek wrote:
> > > > > > > > > It is reported that in some configurations it is not possible
> > > > > > > > > to boot
> > > > > > > > > because u-boot runs out of lmbs.
> > > > > > > > >
> > > > > > > > > commit 06d514d77c ("lmb: consider EFI memory map") increases
> > > > > > > > > lmb usage,
> > > > > > > > > hence is likely the cause of the lmb overflow.
> > > > > > > > >
> > > > > > > > > Fixes: 06d514d77c ("lmb: consider EFI memory map")
> > > > > > > > > Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1207562
> > > > > > > > > Signed-off-by: Michal Suchanek
> > > > > > > Reviewed-by: Francesco Dolcini
> > > > > > >
> > > > > > > > I plan to pick up
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230125230823.1567778-1-tr...@konsulko.com/
> > > > > > > > as the alternative fix for this issue and would suggest that
> > > > > > > > any distro
> > > > > > > > hitting the problem on v2023.01 apply the above instead of
> > > > > > > > increasing
> > > > > > > > the limit.
> > > > > > > Tom, my understanding is that you plan to merge this or an
> > > > > > > equivalent
> > > > > > > change, correct? Otherwise I would need to send some more patches
> > > > > > > to
> > > > > > > update a few board defconfig that are affected by this specific
> > > > > > > issue.
> > > > > > Yes, I was hoping to push the equivalent of this patch a few hours
> > > > > > ago,
> > > > > > along with the revert. Then I noticed the test in test/lib/lmb.c
> > > > > > doesn't
> > > > > > scale past 8, and I just now figured out what that should look like
> > > > > > instead, I believe.
> > > > > reportedly neither fixes the problem in all cases, and raising
> > > > > CONFIG_LMB_RESERVED_REGIONS is required.
> > > > >
> > > > > Looks like the mechanism to add regions above the default number does
> > > > > not work as intended.
> > > > >
> > > > > The test is to boot rPi 4 from USB directly with recent firmware.
> > > > Well, given 0089affee275 ("configs: stm32mp15: increase the number of
> > > > reserved memory region in lmb") I guess this has been run in to before,
> > > > but not resolved more generically.
> > > I wonder if
> > > https://patchwork.ozlabs.org/project/uboot/patch/20230212150706.2967007-2-sjo...@collabora.com/
> > > is what will finish dealing with these issues, even the ones that had
> > > perhaps shown up before and been addressed in the commit I mentioned
> > > above?
> > Looks like this together with raising the maximum number of regions
> > works, that is v2023.04-rc2 should be fixed.
> >
> > Thanks
> >
> > Michal
>
>
> For STM32MP15x platform with have the same issue when the number of reserved
> regions increased in Linux device tree.
>
>
> I try to increase the region by default with CONFIG_LMB_MAX_REGIONS,
>
> but my patch increase the used RAM size for some platform (with compilation
> issue).
>
>
> For Tom ask me to propose a backward compatible configuration
>
> https://lore.kernel.org/all/18550712-c32d-e08b-c38e-6c63bad09...@foss.st.com/
>
> => CONFIG_US
Re: [PATCH v1 0/3] fdt: Fix mtparts fixup
On Thu, Feb 23, 2023 at 11:23:41AM +0100, Patrick DELAUNAY wrote: > Hi, > > On 1/23/23 21:01, Tom Rini wrote: > > On Mon, Jan 23, 2023 at 11:06:06AM +0100, Miquel Raynal wrote: > > > Hi Tom, > > > > > > tr...@konsulko.com wrote on Fri, 13 Jan 2023 14:34:11 -0500: > > > > > > > On Fri, Jan 13, 2023 at 07:45:44PM +0100, Francesco Dolcini wrote: > > > > > > > > > From: Francesco Dolcini > > > > > > > > > > Recently we had a boot regression on colibri-imx7 because of a > > > > > cleanup change > > > > > on Linux imx7.dtsi setting nand controller node #size-cells from 1 to > > > > > 0. > > > > > > > > > > Because of that Linux partition parser was no longer able to properly > > > > > parse the OF partitions leading to a boot failure, the above change > > > > > was > > > > > reverted in the meantime as an immediate workaround, but some > > > > > improvement > > > > > is required on both Linux and U-Boot. > > > > > > > > > > This change improve the U-Boot part of it, #size-cell is set to 1 when > > > > > it has an invalid value. This has the limitation to work only with > > > > > devices > > > > > smaller than 4GiB. In general the suggestion from the Linux MTD > > > > > maintainer would > > > > > be to just deprecate using this U-Boot function and pass the MTD > > > > > partitions > > > > > from the command line, unless they are statically defined in the DTS > > > > > file > > > > > in the first place. > > > > > > > > > > This series therefore convert colibri-imx6ull and colibri-imx7 to > > > > > pass the > > > > > partition list from the command line instead of fixing up the DT. > > > > > > > > > > Link: > > > > > https://lore.kernel.org/all/20221202071900.1143950-1-france...@dolcini.it/ > > > > > Link: > > > > > https://lore.kernel.org/all/y4dgbtgnwpm6s...@francesco-nb.int.toradex.com/ > > > > My higher level question / concern here is, is using one of the dts > > > > partition schemes still valid / preferred, or should everyone now have > > > > reverted to passing via the kernel command line? If device tree still, > > > > is mtd/partitions/fixed-partitions.yaml the one to follow or something > > > > else? > > > I don't think we can "prefer" one mode over the other between cmdline > > > and DTS. Both should work pretty well. Of course on the cmdline you can > > > only define fixed partitions and many devices require more advanced > > > parsers, which are only available through DTS, but for simple > > > partitions, it works totally okay. > > When both are present, which one is used? > > > > > The only thing that I would like to avoid is the need to write code in > > > the bootloaders to tweak the FDT in order to add partitions. That is > > > clearly not needed, error prone, and do not follow evolution of the > > > "standard", as we just discovered. > > I'm not sure about this. Looking around in U-Boot today, I see two types > > of cases. One of which, the colibri case, can clearly be not done and > > either passed on the command line, or put in to the device tree as > > there's nothing run-time related being tweaked here. That's a fine path > > to take on those platforms and Francesco's patches should be updated to > > remove the unused C code too from the board code. > > > > But the other cases are doing something dynamic and run-time related. > > There's the omap3 igep00x0 family (which yes, legacy) that is doing NAND > > or oneNAND and adjusting things at run time. I don't know how much > > anyone has interest in those platforms at this point, nor exactly who to > > contact (for Linux or U-Boot). There's also the stm32mp1 family doing > > something that's very not obvious at first glance, so I've cc'd the > > maintainers there. > > > > For information, today for stm32mp1 family we are using the build > > of MTDPARTS and fdt fixup, only for backward compatibility issue > > (the MTD partitions change for boot with or without OP-TEE, > > with or wihtout FIP, with SPL). > > > Today we are already plan to remove this dynamic management > > and to switch to static MTD partition defined in device tree, > > as already proposed by Tom in the serie > > "mtd: spi: nor: force mtd name to "nor%d"" > > http://patchwork.ozlabs.org/project/uboot/patch/20210916155040.v3.2.Ia461e670c7438478aa8f8939209d45c818ccd284@changeid/ > > > This patchset is already ready, we are currently testing it internally > > and it should be pushed when it will be validated in our donwstream. Great, thanks. -- Tom signature.asc Description: PGP signature
Re: Pull request for efi-2023-04-rc3-2
On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > The following changes since commit 8c3acb726ef083d3d5de12f20318ee0e5070: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-04-rc3-2 > > for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > > cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > 07:44:35 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > > > Pull request for efi-2023-04-rc3-2 > > Documentation: > Fix links to fwu_updates.rst This is a fix. > > UEFI: > Allocate device-tree copy from high memory in bootefi command This I think counts as a fix, but I'm a little confused about allocate in this context. Can you point me at the patch please? > Correct attributes checks in SetVariable() This is a fix.. > Other: > Allow SPL to load main U-Boot via partition type GUID This is new functionality, and I didn't quite see that everyone agreed this was a good idea? Not for master at this point in the cycle. > Test case for crc8 function This I suppose can count as a fix. -- Tom signature.asc Description: PGP signature
Re: [PATCH] fs: btrfs: limit the mapped length to the original length
On Mon, Feb 13, 2023 at 08:37:59AM +0800, Qu Wenruo wrote:
> [BUG]
> There is a bug report that btrfs driver caused hang during file read:
>
> This breaks btrfs on the HiFive Unmatched.
>
> => pci enum
> PCIE-0: Link up (Gen1-x8, Bus0)
> => nvme scan
> => load nvme 0:2 0x8c00 /boot/dtb/sifive/hifive-unmatched-a00.dtb
> [hangs]
>
> [CAUSE]
> The reporter provided some debug output:
>
> read_extent_data: cur=615817216, orig_len=16384, cur_len=16384
> read_extent_data: btrfs_map_block: cur_len=479944704; ret=0
> read_extent_data: ret=0
> read_extent_data: cur=615833600, orig_len=4096, cur_len=4096
> read_extent_data: btrfs_map_block: cur_len=479928320; ret=0
>
> Note the second and the last line, the @cur_len is 450+MiB, which is
> almost a chunk size.
>
> And inside __btrfs_map_block(), we limits the returned value to stripe
> length, but that's depending on the chunk type:
>
> if (map->type & (BTRFS_BLOCK_GROUP_RAID0 | BTRFS_BLOCK_GROUP_RAID1 |
>BTRFS_BLOCK_GROUP_RAID1C3 | BTRFS_BLOCK_GROUP_RAID1C4 |
>BTRFS_BLOCK_GROUP_RAID5 | BTRFS_BLOCK_GROUP_RAID6 |
>BTRFS_BLOCK_GROUP_RAID10 |
>BTRFS_BLOCK_GROUP_DUP)) {
> /* we limit the length of each bio to what fits in a stripe */
> *length = min_t(u64, ce->size - offset,
> map->stripe_len - stripe_offset);
> } else {
> *length = ce->size - offset;
> }
>
> This means, if the chunk is SINGLE profile, then we don't limit the
> returned length at all, and even for other profiles, we can still return
> a length much larger than the requested one.
>
> [FIX]
> Properly clamp the returned length, preventing it from returning a much
> larger range than expected.
>
> Reported-by: Andreas Schwab
> Signed-off-by: Qu Wenruo
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/2] Makefile: Link with -z noexectack
On Tue, Feb 14, 2023 at 03:09:31PM -0500, Tom Rini wrote:
> When moving to gcc-12.2 we started trying to quiet some of the new
> linker warnings, that are not relevant to us. However, a
> misunderstanding of the mechanics at play meant that I intentionally
> omitted passing -z noexecstack to the linker, when we do need to. Add
> this flag and in turn remove warnings from the linker.
>
> Fixes: 1e1c51f8ace8 ("Makefile: link with --no-warn-rwx-segments")
> Signed-off-by: Tom Rini
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 2/2] x86: Pass -z execstack for EFI payload flags
On Tue, Feb 14, 2023 at 03:09:32PM -0500, Tom Rini wrote: > To match how we link EFI executables elsewhere, and to silence a linker > warning, pass -z execstack here as well. > > Cc: Bin Meng > Cc: Heinrich Schuchardt > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] env: mmc: Apply GPT only on eMMC user HW partition
On Thu, Feb 09, 2023 at 01:30:10PM +0100, Marek Vasut wrote:
> Apply the GPT U-Boot environment GUID type look up only on eMMC user
> HW partition, do not apply the look up on eMMC boot HW partitions as
> mmc_offset_try_partition() assumes either SD partitions or eMMC user
> HW partition.
>
> This fixes environment operation on systems where CONFIG_SYS_MMC_ENV_PART
> is non-zero and CONFIG_SYS_REDUNDAND_ENVIRONMENT is set.
>
> Fixes: 80105d8fd52 ("env: mmc: select GPT env partition by type guid")
> Signed-off-by: Marek Vasut
> Reviewed-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] trace: Relax test requirements
On Fri, Feb 17, 2023 at 03:45:16PM -0700, Simon Glass wrote:
> We expect the profile and bootstage to agree on timing, but when
> running on slow machines there can be a larger descrepency. Increase the
> tolerance to fix this.
>
> Fixes: 9cea4797aeb ("trace: Add a test")
> Signed-off-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: Pull request, u-boot-tegra/master
On Thu, Feb 23, 2023 at 02:25:04PM -0700, Tom Warren wrote: > Tom, > > Please pull u-boot-tegra/master into U-Boot/master. Thanks. > It has passed 'buildman tegra' w/o error, and Thierry has tested it on his > Tegra boards. > > The following changes since commit 8c3acb726ef083d3d5de12f20318ee0e5070: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > -0500) > > are available in the git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tegra.git master > > for you to fetch changes up to 5a8fe1ee818e0f8a74fa088f6a3d705a01b6afbe: > > ARM: tegra20: implement BCT patching (2023-02-23 12:55:37 -0700) > This is a bit later than I'd like in general, but I know you've been working at this for a bit, and since it's tested on a wide array of the targets in question, I'll take it this time, to master. Also please push it through CI on source.denx.de in the future, I had to fixup a few doc problems (and CI should be enabled). Thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for efi-2023-04-rc3-2
On Fri, Feb 24, 2023 at 04:52:06PM +0200, Ilias Apalodimas wrote: > Hi all, > > Just to put some context > > On Fri, 24 Feb 2023 at 16:44, Heinrich Schuchardt > wrote: > > > > On 2/24/23 15:42, Tom Rini wrote: > > > On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > > >> The following changes since commit > > >> 8c3acb726ef083d3d5de12f20318ee0e5070: > > >> > > >>Merge branch 'master' of > > >> https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > > >> -0500) > > >> > > >> are available in the Git repository at: > > >> > > >>https://source.denx.de/u-boot/custodians/u-boot-efi.git > > >> tags/efi-2023-04-rc3-2 > > >> > > >> for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > > >> > > >>cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > > >> 07:44:35 +0100) > > >> > > >> Gitlab CI showed no issues: > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > > >> > > >> > > >> Pull request for efi-2023-04-rc3-2 > > >> > > >> Documentation: > > >> Fix links to fwu_updates.rst > > > > > > This is a fix. > > > > > >> > > >> UEFI: > > >> Allocate device-tree copy from high memory in bootefi command > > > > > > This I think counts as a fix, but I'm a little confused about allocate > > > in this context. Can you point me at the patch please? > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/commit/0bb5d6b1e4105ec4215239958830a396658bfed8 > > The TL;DR is that we were placing the DT on 127mb. This might > overwrite previously loaded binaries. The efi-stub of the linux kernel > doesn't use the DTB in place. Instead, it copies it and adds some > nodes for the efi-stub -> kernel proper handover (e.g a kaslr-seed). > So we as far as linux is concerned we are free to place the DT > wherever we want. > > Unless people from risc-v want this in *now*, we are better of landing > this in -next. Ah, thanks. So the sinking feeling that I had that we had duplicated the complex logic of "where _IS_ a safe place in memory to put things" was done again, but without being configurable, was right. Sigh. I don't have an idea on here's how we solve it, but I do worry we're going to have, once again, some of the overlap and silent corruption problems of old. But maybe not this time, since we're finally getting payloads that we can determine the BSS of, etc. > > >> Correct attributes checks in SetVariable() > > This can wait. This fixes one minor issue on the SystemReady Security > extensions test suite. This is a test suite (mostly running as EFI > apps) from Arm to check conformance for UEFI Secure Boot and Measured > boot. Ah, OK. -- Tom signature.asc Description: PGP signature
Re: Pull request for efi-2023-04-rc3-2
On Fri, Feb 24, 2023 at 03:44:19PM +0100, Heinrich Schuchardt wrote: > On 2/24/23 15:42, Tom Rini wrote: > > On Fri, Feb 24, 2023 at 11:02:57AM +0100, Heinrich Schuchardt wrote: > > > The following changes since commit > > > 8c3acb726ef083d3d5de12f20318ee0e5070: > > > > > >Merge branch 'master' of > > > https://source.denx.de/u-boot/custodians/u-boot-usb (2023-02-22 13:36:29 > > > -0500) > > > > > > are available in the Git repository at: > > > > > >https://source.denx.de/u-boot/custodians/u-boot-efi.git > > > tags/efi-2023-04-rc3-2 > > > > > > for you to fetch changes up to 0bb5d6b1e4105ec4215239958830a396658bfed8: > > > > > >cmd: bootefi: allocate device-tree copy from high memory (2023-02-24 > > > 07:44:35 +0100) > > > > > > Gitlab CI showed no issues: > > > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/15340 > > > > > > > > > Pull request for efi-2023-04-rc3-2 > > > > > > Documentation: > > > Fix links to fwu_updates.rst > > > > This is a fix. > > > > > > > > UEFI: > > > Allocate device-tree copy from high memory in bootefi command > > > > This I think counts as a fix, but I'm a little confused about allocate > > in this context. Can you point me at the patch please? > > > > > Correct attributes checks in SetVariable() > > > > This is a fix.. > > > > > Other: > > > Allow SPL to load main U-Boot via partition type GUID > > > > This is new functionality, and I didn't quite see that everyone agreed > > this was a good idea? Not for master at this point in the cycle. > > Would you take it for next? The last feedback I saw was that the idea isn't exactly workable and presents its own challenges for distributions / OSes, or did I miss some further messages? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] Dockerfile: download binaries for Nokia RX-51
On Fri, Jan 13, 2023 at 07:25:01PM +0100, Heinrich Schuchardt wrote: > Downloading files for a test may fail if the server is offline. > It is preferable to provide the files in our Docker image. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] Dockerfile: build qemu for Nokia n900
On Fri, Jan 13, 2023 at 08:31:33PM +0100, Heinrich Schuchardt wrote: > Using a pre-built QEMU saves a lot of time when testing. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: Update test/nokia_rx51_test.sh to use prebuilt images
On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote: > From: Pali Rohár > > Now that the Dockerfile creates images which have the binaries we > require included, have CI make symlinks for them and update the existing > script to support this. > > Signed-off-by: Tom Rini > Signed-off-by: Pali Rohár > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: Update test/nokia_rx51_test.sh to use prebuilt images
On Sat, Feb 25, 2023 at 07:35:28PM +0100, Pali Rohár wrote: > On Saturday 25 February 2023 13:23:33 Tom Rini wrote: > > On Tue, Feb 21, 2023 at 11:22:29AM -0500, Tom Rini wrote: > > > > > From: Pali Rohár > > > > > > Now that the Dockerfile creates images which have the binaries we > > > require included, have CI make symlinks for them and update the existing > > > script to support this. > > > > > > Signed-off-by: Tom Rini > > > Signed-off-by: Pali Rohár > > > Reviewed-by: Simon Glass > > > > Applied to u-boot/next, thanks! > > > > -- > > Tom > > Maybe you wanted this in master to make CI reliable also for master branch? I'm trying to follow my own "just fixes, really" rule. I don't know _why_ Azure fails out randomly, but I don't think bumping the containers for just this, right now, is a fix, exactly. -- Tom signature.asc Description: PGP signature
Re: [PATCH] kconfig: Proposed language extension for multiple builds
On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > > > Hi Masahiro, > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada wrote: > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass wrote: > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > I do not know. > > > This seems a shorthand in Kconfig level. > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > 5401080 24872 > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > 163 3267462 > > > > > > If hundreds of duplications are not manageable, > > > go for it, but kconfig will be out-of-sync from the > > > upstream Kconfig. > > > > Yes that's right, it is a shorthand in Kconfig. > > > > The counts above understand the problem a little since quite a few > > CONFIG options without an SPL prefix are used in SPL. We don't have > > tools to estimate how many, and we sometimes add a new symbol to 'gain > > control' of a particular feature in a phase. > > > > My intent in sending this patch was to check whether this support for > > configuring multiple related builds (or something like it) could go > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > This complexity is absolutely unneeded for Linux. > > So, the answer is no. Well, I think Simon summarized himself a bit shorter here than he did in the patch itself. So, to what extent does the kernel want to consider all of the other projects using the Kconfig language and their needs / use cases? -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 18/19] test/py: android: extend abootimg test
On Mon, Feb 27, 2023 at 03:15:31PM +0100, Safae Ouajih wrote: > > On 07/02/2023 20:02, Tom Rini wrote: > > On Mon, Feb 06, 2023 at 12:50:20AM +0100, Safae Ouajih wrote: > > > > > test_abootimg is extended to include the testing of boot images > > > version 4. For this, boot.img and vendor_boot.img have been > > > generated using mkbootimg tool with setting the header > > > version to 4. > > > > > > This tests: > > > - Getting the header version using abootimg > > > - Extracting the load address of the dtb > > > - Extracting the dtb start address in RAM > > > > > > Running test: > > > $ ./test/py/test.py --bd sandbox --build -k test_abootimg > > > > > > Signed-off-by: Safae Ouajih > > > Reviewed-by: Simon Glass > > > --- > > > test/py/tests/test_android/test_abootimg.py | 136 ++-- > > > 1 file changed, 123 insertions(+), 13 deletions(-) > > Alright, so I don't know where the failure starts, exactly. And to make > > testing this easier, there's currently the > > trini/u-boot-gitlab-ci-runner:jammy-20230126-07Feb2023 container you can > > use to replicate my problem. The problem is that while this test passes > > in CI, with GCC, with Clang it fails, consistently: > > https://source.denx.de/u-boot/u-boot/-/jobs/572239#L284 > > and I'm not quite sure why. I hope that building sandbox with clang and > > also just trying these features out interactively will fail too, and so > > debugging this will be less of a problem. > > > Hello Tom, > > I have investigated this issue, clang has a strange behavior in: > > * abootimg_get_dtb_load_addr() : cmd/abootimg.c > * android_image_get_dtb_by_index() : boot/image-android.c > > That is probably linked to some sort of optimization clang does. > > However, The fail is not reproducible using clang-15 and clang-16 and also > not reproducible when turning off clang optimizations. > > I suggest using clang-15 to run the test or I can remove all optimizations > > on the related functions if clang-14 is used. Thanks for investigating. I see that 15 is now considered stable, so I'll update the next branch for that, then re-take this series. -- Tom signature.asc Description: PGP signature
Re: Pull request for u-boot-nand-20230227
On Mon, Feb 27, 2023 at 05:52:29PM +0100, Dario Binacchi wrote: > Hi Tom, > > The following changes since commit 0024e7f72b689f8c2df731a69e20f47b6f8dc5a7: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-tegra (2023-02-23 > 17:40:18 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git > tags/u-boot-nand-20230227 > > for you to fetch changes up to d9fa61f54e7f9ac3e31c362cddda834675200a23: > > mtd: nand: Show reserved block in chip.erase (2023-02-27 16:30:13 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/15388 > > Pull request for u-boot-nand-20230227 > > - mark reserved blocks from Ashok Reddy Soma > - backport BRCMNAND changes from Linux from Linus Walleij > - fix display of unknown raw ID from Patrice Chotard > - show reserved block in chip.erase from Michael Trimarchi As this has both new features and fixes, I assume this is for next, and I'll take it in once I get -rc3 out (and pull that in to -next). -- Tom signature.asc Description: PGP signature
Re: [PATCH] kconfig: Proposed language extension for multiple builds
On Sun, Feb 26, 2023 at 12:23:00PM -0700, Simon Glass wrote: > Hi Masahiro, > > On Sun, 26 Feb 2023 at 10:36, Masahiro Yamada wrote: > > > > On Sun, Feb 26, 2023 at 11:44 PM Tom Rini wrote: > > > > > > On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > > > > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass wrote: > > > > > > > > > > Hi Masahiro, > > > > > > > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada > > > > > wrote: > > > > > > > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not know. > > > > > > This seems a shorthand in Kconfig level. > > > > > > > > > > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > > > > 5401080 24872 > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > > > > 163 3267462 > > > > > > > > > > > > If hundreds of duplications are not manageable, > > > > > > go for it, but kconfig will be out-of-sync from the > > > > > > upstream Kconfig. > > > > > > > > > > Yes that's right, it is a shorthand in Kconfig. > > > > > > > > > > The counts above understand the problem a little since quite a few > > > > > CONFIG options without an SPL prefix are used in SPL. We don't have > > > > > tools to estimate how many, and we sometimes add a new symbol to 'gain > > > > > control' of a particular feature in a phase. > > > > > > > > > > My intent in sending this patch was to check whether this support for > > > > > configuring multiple related builds (or something like it) could go > > > > > upstream, which for Kconfig is Linux, I believe. What do you think? > > > > > > > > > > > > This complexity is absolutely unneeded for Linux. > > > > > > > > So, the answer is no. > > > > > > Well, I think Simon summarized himself a bit shorter here than he did in > > > the patch itself. So, to what extent does the kernel want to consider > > > all of the other projects using the Kconfig language and their needs / > > > use cases? > > > > > > -- > > > Tom > > > > > > > > In principle, only features that are useful for Linux. > > I'm disappointed in this attitude. It is the same thing that we saw > from the DT bindings until recently. > > > > > Kconfig has small piece of code that is useful for other projects, > > for example, > > > > #ifndef CONFIG_ > > #define CONFIG_ "CONFIG_" > > #endif > > > > which might be useful for Buildroot, but this is exceptionally small. > > How about refactoring patches that would make a possible > implementation easier to maintain, like [1] ? Would they be > acceptable? > > > > > > > The multi-phase is too cluttered, and that is not what Linux wants to have. > > Clearly it is not useful to Linux, which only has one build. I'm honestly not sure about this part. I keep pondering if some of the module related options wouldn't be just as logical under a phases type thing. But it would also probably be more forcing a solution at a good-enough concept than finding a solution to a problem. -- Tom signature.asc Description: PGP signature
Re: [PATCH] kconfig: Proposed language extension for multiple builds
On Mon, Feb 27, 2023 at 11:52:57PM +0900, Masahiro Yamada wrote: > Hi Simon, > > On Mon, Feb 27, 2023 at 1:00 PM Simon Glass wrote: > > > > Hi Masahiro, > > > > On Sun, 26 Feb 2023 at 20:36, Masahiro Yamada wrote: > > > > > > Hi Simon, > > > > > > On Mon, Feb 27, 2023 at 4:23 AM Simon Glass wrote: > > > > > > > > Hi Masahiro, > > > > > > > > On Sun, 26 Feb 2023 at 10:36, Masahiro Yamada > > > > wrote: > > > > > > > > > > On Sun, Feb 26, 2023 at 11:44 PM Tom Rini wrote: > > > > > > > > > > > > On Sun, Feb 26, 2023 at 11:32:03PM +0900, Masahiro Yamada wrote: > > > > > > > On Sun, Feb 26, 2023 at 11:04 PM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Masahiro, > > > > > > > > > > > > > > > > On Sat, 25 Feb 2023 at 20:31, Masahiro Yamada > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sat, Feb 25, 2023 at 11:38 AM Simon Glass > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > +Masahiro Yamada > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do not know. > > > > > > > > > This seems a shorthand in Kconfig level. > > > > > > > > > > > > > > > > > > > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config SPL_' | wc > > > > > > > > > 5401080 24872 > > > > > > > > > masahiro@zoe:~/ref/u-boot(master)$ rgrep '^config TPL_' | wc > > > > > > > > > 163 3267462 > > > > > > > > > > > > > > > > > > If hundreds of duplications are not manageable, > > > > > > > > > go for it, but kconfig will be out-of-sync from the > > > > > > > > > upstream Kconfig. > > > > > > > > > > > > > > > > Yes that's right, it is a shorthand in Kconfig. > > > > > > > > > > > > > > > > The counts above understand the problem a little since quite a > > > > > > > > few > > > > > > > > CONFIG options without an SPL prefix are used in SPL. We don't > > > > > > > > have > > > > > > > > tools to estimate how many, and we sometimes add a new symbol > > > > > > > > to 'gain > > > > > > > > control' of a particular feature in a phase. > > > > > > > > > > > > > > > > My intent in sending this patch was to check whether this > > > > > > > > support for > > > > > > > > configuring multiple related builds (or something like it) > > > > > > > > could go > > > > > > > > upstream, which for Kconfig is Linux, I believe. What do you > > > > > > > > think? > > > > > > > > > > > > > > > > > > > > > This complexity is absolutely unneeded for Linux. > > > > > > > > > > > > > > So, the answer is no. > > > > > > > > > > > > Well, I think Simon summarized himself a bit shorter here than he > > > > > > did in > > > > > > the patch itself. So, to what extent does the kernel want to > > > > > > consider > > > > > > all of the other projects using the Kconfig language and their > > > > > > needs / > > > > > > use cases? > > > > > > > > > > > > -- > > > > > > Tom > > > > > > > > > > > > > > > > > > > > In principle, only features that are useful for Linux. > > > > > > > > I'm disappointed in this attitude. It is the same thing that we saw > > > > from the DT bindings until recently. > > > > > > > > > Sorry, but this is the maintainer's job. > >
[PATCH 2/7] dlmalloc: Fix a warning with clang-15
With clang-15 we now will get warnings such as:
warning: a function declaration without a prototype is deprecated in all
versions of C [-Wstrict-prototypes]
And it is easy enough to address this warning here, as we aren't
concerned with re-syncing with an upstream.
Signed-off-by: Tom Rini
---
common/dlmalloc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 41c7230424cc..0f9b7262d512 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -80,7 +80,7 @@ GmListElement* makeGmListElement (void* bas)
return this;
}
-void gcleanup ()
+void gcleanup (void)
{
BOOL rval;
assert ( (head == NULL) || (head->base == (void*)gAddressBase));
@@ -2340,7 +2340,7 @@ size_t malloc_usable_size(mem) Void_t* mem;
/* Utility to update current_mallinfo for malloc_stats and mallinfo() */
#ifdef DEBUG
-static void malloc_update_mallinfo()
+static void malloc_update_mallinfo(void)
{
int i;
mbinptr b;
@@ -2397,7 +2397,7 @@ static void malloc_update_mallinfo()
*/
#ifdef DEBUG
-void malloc_stats()
+void malloc_stats(void)
{
malloc_update_mallinfo();
printf("max system bytes = %10u\n",
@@ -2418,7 +2418,7 @@ void malloc_stats()
*/
#ifdef DEBUG
-struct mallinfo mALLINFo()
+struct mallinfo mALLINFo(void)
{
malloc_update_mallinfo();
return current_mallinfo;
--
2.34.1
[PATCH 1/7] global: Disable deprecated-non-prototype warning with clang
We have a number of places in the code which use the following syntax:
void func(a, b, c)
int a; /* Does a */
something_t *b; /* Pointer to b */
int c; /* Does c */
{
...
}
Which while not what we document as our coding style, this is also code
which we have imported from other projects, and would like to re-sync
with in the future. While the biggest example of this is the zlib code,
there are other places as well. For now, we will silence this warning.
Signed-off-by: Tom Rini
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 54f894dab841..d2c132be6e09 100644
--- a/Makefile
+++ b/Makefile
@@ -790,6 +790,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning,
tautological-compare)
# See modpost pattern 2
KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,)
KBUILD_CFLAGS += $(call cc-option, -fcatch-undefined-behavior)
+KBUILD_CFLAGS += $(call cc-disable-warning, deprecated-non-prototype)
endif
# These warnings generated too much noise in a regular build.
--
2.34.1
[PATCH 4/7] zlib: trees.c: Fix a warning with clang-15
With clang-15 we now will get warnings such as:
warning: a function declaration without a prototype is deprecated in all
versions of C [-Wstrict-prototypes]
And it is easy enough to address this warning here, even if we would
like to stay in sync more with upstream as it's a single location.
Signed-off-by: Tom Rini
---
lib/zlib/trees.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/zlib/trees.c b/lib/zlib/trees.c
index 970bc5dbc64e..e040617686a1 100644
--- a/lib/zlib/trees.c
+++ b/lib/zlib/trees.c
@@ -237,7 +237,7 @@ local void send_bits(s, value, length)
/* ===
* Initialize the various 'constant' tables.
*/
-local void tr_static_init()
+local void tr_static_init(void)
{
#if defined(GEN_TREES_H) || !defined(STDC)
static int static_init_done = 0;
--
2.34.1
[PATCH 3/7] libavb: Fix a warning with clang-15
With clang-15 we now will get warnings such as:
warning: a function declaration without a prototype is deprecated in all
versions of C [-Wstrict-prototypes]
And it is easy enough to address this warning here, as we aren't
concerned with re-syncing with an upstream.
Signed-off-by: Tom Rini
---
Cc: Igor Opaniuk
---
lib/libavb/avb_cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/libavb/avb_cmdline.c b/lib/libavb/avb_cmdline.c
index cb54e658c487..a58ce6c48c01 100644
--- a/lib/libavb/avb_cmdline.c
+++ b/lib/libavb/avb_cmdline.c
@@ -394,7 +394,7 @@ out:
return ret;
}
-AvbCmdlineSubstList* avb_new_cmdline_subst_list() {
+AvbCmdlineSubstList* avb_new_cmdline_subst_list(void) {
return (AvbCmdlineSubstList*)avb_calloc(sizeof(AvbCmdlineSubstList));
}
--
2.34.1
[PATCH 5/7] imx8image: Remove unused cont_img_count variable
With clang-15, it is now reported that cont_img_count is unused. This is true as the code will increment / reset this counter, but never functionally use it. Remove it. Signed-off-by: Tom Rini --- Cc: Peng Fan Cc: Mikhail Ilin Cc: Stefano Babic Cc: Fabio Estevam Cc: "NXP i.MX U-Boot Team" --- tools/imx8image.c | 5 - 1 file changed, 5 deletions(-) diff --git a/tools/imx8image.c b/tools/imx8image.c index 395d5c64bdf0..c25ea84e25c5 100644 --- a/tools/imx8image.c +++ b/tools/imx8image.c @@ -829,7 +829,6 @@ static int build_container(soc_type_t soc, uint32_t sector_size, int ret; int container = -1; - int cont_img_count = 0; /* indexes to arrange the container */ memset((char *)&imx_header, 0, sizeof(imx_header_v3_t)); @@ -879,7 +878,6 @@ static int build_container(soc_type_t soc, uint32_t sector_size, img_sp->src = file_off; file_off += ALIGN(sbuf.st_size, sector_size); - cont_img_count++; break; case SECO: @@ -899,7 +897,6 @@ static int build_container(soc_type_t soc, uint32_t sector_size, img_sp->src = file_off; file_off += sbuf.st_size; - cont_img_count++; break; case NEW_CONTAINER: @@ -908,8 +905,6 @@ static int build_container(soc_type_t soc, uint32_t sector_size, CONTAINER_ALIGNMENT, CONTAINER_FLAGS_DEFAULT, fuse_version); - /* reset img count when moving to new container */ - cont_img_count = 0; scfw_flags = 0; break; -- 2.34.1
[PATCH 7/7] CI: Move to clang-15
As this is now the stable release, move to using that now for our tests. Signed-off-by: Tom Rini --- .azure-pipelines.yml| 6 +++--- .gitlab-ci.yml | 4 ++-- tools/docker/Dockerfile | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 30025ff7517e..59629b39265c 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -2,7 +2,7 @@ variables: windows_vm: windows-2019 ubuntu_vm: ubuntu-22.04 macos_vm: macOS-12 - ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 + ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20230126-27Feb2023 # Add '-u 0' options for Azure pipelines, otherwise we get "permission # denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer", # since our $(ci_runner_image) user is not root. @@ -244,7 +244,7 @@ stages: TEST_PY_BD: "sandbox" sandbox_clang: TEST_PY_BD: "sandbox" - OVERRIDE: "-O clang-14" + OVERRIDE: "-O clang-15" sandbox_nolto: TEST_PY_BD: "sandbox" BUILD_ENV: "NO_LTO=1" @@ -498,7 +498,7 @@ stages: OVERRIDE: "-a ASAN" sandbox_clang_asan: BUILDMAN: "sandbox" - OVERRIDE: "-O clang-14 -a ASAN" + OVERRIDE: "-O clang-15 -a ASAN" samsung_socfpga: BUILDMAN: "samsung socfpga" sun4i: diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index e320a24ef31e..068f39eb1114 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -2,7 +2,7 @@ # Grab our configured image. The source for this is found # in the u-boot tree at tools/docker/Dockerfile -image: trini/u-boot-gitlab-ci-runner:jammy-20230126-17Feb2023 +image: trini/u-boot-gitlab-ci-runner:jammy-20230126-27Feb2023 # We run some tests in different order, to catch some failures quicker. stages: @@ -260,7 +260,7 @@ sandbox test.py: sandbox with clang test.py: variables: TEST_PY_BD: "sandbox" -OVERRIDE: "-O clang-14" +OVERRIDE: "-O clang-15" <<: *buildman_and_testpy_dfn sandbox without LTO test.py: diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index c367bb482b4d..99da8cd38cae 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -12,7 +12,7 @@ ENV DEBIAN_FRONTEND=noninteractive # Add LLVM repository RUN apt-get update && apt-get install -y gnupg2 wget xz-utils && rm -rf /var/lib/apt/lists/* RUN wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key | apt-key add - -RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-14 main | tee /etc/apt/sources.list.d/llvm.list +RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-15 main | tee /etc/apt/sources.list.d/llvm.list # Manually install the kernel.org "Crosstool" based toolchains for gcc-12.2.0 RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-aarch64-linux.tar.xz | tar -C /opt -xJ @@ -39,7 +39,7 @@ RUN apt-get update && apt-get install -y \ binutils-dev \ bison \ build-essential \ - clang-14 \ + clang-15 \ coreutils \ cpio \ cppcheck \ -- 2.34.1
[PATCH 6/7] proftool: Remove unused variables in make_flame_tree
With clang-15 we now get reported that in the make_flame_tree function,
neither the missing_count nor depth variables are used, only
incremenete/decremented. Remove these.
Signed-off-by: Tom Rini
---
Cc: Simon Glass
---
tools/proftool.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/tools/proftool.c b/tools/proftool.c
index 089360428c2c..101bcb63334e 100644
--- a/tools/proftool.c
+++ b/tools/proftool.c
@@ -1713,18 +1713,11 @@ static int make_flame_tree(enum out_format_t out_format,
struct flame_state state;
struct flame_node *tree;
struct trace_call *call;
- int missing_count = 0;
- int i, depth;
+ int i;
/* maintain a stack of start times, etc. for 'calling' functions */
state.stack_ptr = 0;
- /*
-* The first thing in the trace may not be the top-level function, so
-* set the initial depth so that no function goes below depth 0
-*/
- depth = -calc_min_depth();
-
tree = create_node("tree");
if (!tree)
return -1;
@@ -1736,16 +1729,10 @@ static int make_flame_tree(enum out_format_t out_format,
ulong timestamp = call->flags & FUNCF_TIMESTAMP_MASK;
struct func_info *func;
- if (entry)
- depth++;
- else
- depth--;
-
func = find_func_by_offset(call->func);
if (!func) {
warn("Cannot find function at %lx\n",
text_offset + call->func);
- missing_count++;
continue;
}
--
2.34.1
[ANN] U-Boot v2023.04-rc3 released
Hey all, It's the scheduled day for -rc3, and it's the end of my day, mainly because I got side-tracked. The delta between -rc2 and -rc3 is bigger than I'd have liked, but, I can accept it. I will be more stringent moving forward, and at this point the only "big" changes I'm expecting are the fixes for m68k, and powerpc 8xx platforms, which have been posted for a while and I believe it's a matter of custodian time to collect and test everything. In terms of a changelog, git log --merges v2023.04-rc2..v2023.04-rc3 contains what I've pulled but as always, better PR messages and tags will provide better results here. Continuing on schedule now and that means the rest of the rcs every other Monday, and with final release on April 3rd, 2023. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH] CI: gitlab: Collect pytest artifacts
On Mon, Feb 27, 2023 at 11:51:30PM +0100, Marek Vasut wrote:
> Copy build artifacts for all test.py tests, so they show up in
> artifacts storage for later inspection. The test.py tests output
> in CI is basically useless, but it is far more useful in the html
> output for analysis and debugging.
>
> Suggested-by: Simon Glass
> Signed-off-by: Marek Vasut
> ---
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> .gitlab-ci.yml | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 272d69e2206..1b761f26e9a 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -77,9 +77,12 @@ stages:
> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
> # It seems that the files in /tmp go away, so copy out what we need
We can drop this comment.
> -- if [[ "${TEST_PY_BD}" == "coreboot" ]]; then
> -cp -v /tmp/coreboot/*.{html,css} .;
> - fi
> +- cp -v /tmp/${TEST_PY_BD}/*.{html,css} .
> + artifacts:
> +paths:
> + - "*.html"
> + - "*.css"
> +expire_in: 1 week
>
> build all 32bit ARM platforms:
>stage: world build
> @@ -454,9 +457,4 @@ coreboot test.py:
> TEST_PY_BD: "coreboot"
> TEST_PY_TEST_SPEC: "not sleep"
> TEST_PY_ID: "--id qemu"
> - artifacts:
> -paths:
> - - "*.html"
> - - "*.css"
> -expire_in: 1 week
><<: *buildman_and_testpy_dfn
So, what looks like a debugging artifact was included in the proper
patch and merged, and yes,
https://u-boot.source-pages.denx.de/-/u-boot/-/jobs/585388/artifacts/test-log.html
is quite handy in the case of test failure.
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 0/6] FWU: Handle meta-data in common code
On Mon, Feb 27, 2023 at 06:51:35PM -0600, jassisinghb...@gmail.com wrote: > From: Jassi Brar > > The patchset reduces ~400 lines of code, while keeping the functionality same > and making > meta-data operations much faster (by using cached structures). > > Issue: > meta-data copies (primary and secondary) are being handled by the > backend/storage layer > instead of the common core in fwu.c (as also noted by Ilias) that is, > gpt_blk.c manages > meta-data and similarly raw_mtd.c will have to do the same when it arrives. > The code > could by make smaller, cleaner and optimised. > > Basic idea: > Introduce .read_mdata() and .write_mdata() in fwu_mdata_ops that simply > read/write > meta-data copy. The core code takes care of integrity and redundancy of the > meta-data, > as a result we can get rid of every other callback .get_mdata() > .update_mdata() > .get_mdata_part_num() .read_mdata_partition() .write_mdata_partition() and > the > corresponding wrapper functions thereby making the code 100s of LOC smaller. > > Get rid of fwu_check_mdata_validity() and fwu_mdata_check() which expected > underlying > layer to manage and verify mdata copies. > Implement fwu_get_verified_mdata(struct fwu_mdata *mdata) public function > that reads, > verifies and, if needed, fixes the meta-data copies. > > Verified copy of meta-data is now cached as 'g_mdata' in fwu.c, which avoids > multiple > low-level expensive read and parse calls. > gpt meta-data partition numbers are now cached in gpt_blk.c, so that we don't > have to do expensive part_get_info() and uid ops. > > Changes since v4: > * Change fwu-mdata-mtd bindings to not require external changes > * Handle 'part == BOTH_PARTS' in fwu_sync_mdata > * use parts_ok[] and parts_mdata[] instead of pri/sec_ok and p/s_mdata Did you run this through CI / build sandbox? This doesn't read like you fixed the problem I reported in CI, when I was trying to merge v4. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 0/6] FWU: Handle meta-data in common code
On Mon, Feb 27, 2023 at 07:00:10PM -0600, Jassi Brar wrote: > On Mon, 27 Feb 2023 at 18:58, Tom Rini wrote: > > > > On Mon, Feb 27, 2023 at 06:51:35PM -0600, jassisinghb...@gmail.com wrote: > > > > > From: Jassi Brar > > > > > > The patchset reduces ~400 lines of code, while keeping the functionality > > > same and making > > > meta-data operations much faster (by using cached structures). > > > > > > Issue: > > > meta-data copies (primary and secondary) are being handled by the > > > backend/storage layer > > > instead of the common core in fwu.c (as also noted by Ilias) that is, > > > gpt_blk.c manages > > > meta-data and similarly raw_mtd.c will have to do the same when it > > > arrives. The code > > > could by make smaller, cleaner and optimised. > > > > > > Basic idea: > > > Introduce .read_mdata() and .write_mdata() in fwu_mdata_ops that > > > simply read/write > > > meta-data copy. The core code takes care of integrity and redundancy of > > > the meta-data, > > > as a result we can get rid of every other callback .get_mdata() > > > .update_mdata() > > > .get_mdata_part_num() .read_mdata_partition() .write_mdata_partition() > > > and the > > > corresponding wrapper functions thereby making the code 100s of LOC > > > smaller. > > > > > > Get rid of fwu_check_mdata_validity() and fwu_mdata_check() which > > > expected underlying > > > layer to manage and verify mdata copies. > > > Implement fwu_get_verified_mdata(struct fwu_mdata *mdata) public > > > function that reads, > > > verifies and, if needed, fixes the meta-data copies. > > > > > > Verified copy of meta-data is now cached as 'g_mdata' in fwu.c, which > > > avoids multiple > > > low-level expensive read and parse calls. > > > gpt meta-data partition numbers are now cached in gpt_blk.c, so that we > > > don't have to do expensive part_get_info() and uid ops. > > > > > > Changes since v4: > > > * Change fwu-mdata-mtd bindings to not require external changes > > > * Handle 'part == BOTH_PARTS' in fwu_sync_mdata > > > * use parts_ok[] and parts_mdata[] instead of pri/sec_ok and > > > p/s_mdata > > > > Did you run this through CI / build sandbox? This doesn't read like you > > fixed the problem I reported in CI, when I was trying to merge v4. > > > I know that remains to be done. > The dt-bindings for fwu-mdata is changed in this patchset and I > thought any testcase may be impacted by it. So you're not expecting this iteration to be merged, as CI doesn't pass, and that's known? OK. -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/7] dlmalloc: Fix a warning with clang-15
On Mon, Feb 27, 2023 at 05:35:30PM -0700, Simon Glass wrote: > Hi Tom, > > On Mon, 27 Feb 2023 at 15:08, Tom Rini wrote: > > > > With clang-15 we now will get warnings such as: > > > > warning: a function declaration without a prototype is deprecated in all > > versions of C [-Wstrict-prototypes] > > > > And it is easy enough to address this warning here, as we aren't > > concerned with re-syncing with an upstream. > > > > Signed-off-by: Tom Rini > > --- > > common/dlmalloc.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > Reviewed-by: Simon Glass > > > > > diff --git a/common/dlmalloc.c b/common/dlmalloc.c > > index 41c7230424cc..0f9b7262d512 100644 > > --- a/common/dlmalloc.c > > +++ b/common/dlmalloc.c > > @@ -80,7 +80,7 @@ GmListElement* makeGmListElement (void* bas) > > return this; > > } > > > > -void gcleanup () > > +void gcleanup (void) > > drop space before ( ? The file is so badly out of sync with our coding style I literally just went and did %s/()$/(void)/ to move on to the next sets of problems. So I'd rather not fix one more style issue here when I suspect there's a barely exaggerated thousand more. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] MAINTAINERS: Add entry for SPI NAND framework and drivers
On Tue, Feb 28, 2023 at 09:52:45AM +0100, Frieder Schrempf wrote: > On 27.02.23 16:24, Dario Binacchi wrote: > > Hi Frieder, > > > > On Mon, Feb 13, 2023 at 10:47 AM Frieder Schrempf wrote: > >> > >> From: Frieder Schrempf > >> > >> In [1] Michael agreed on taking patches for SPI NAND through the RAW > >> NAND tree. Add a dedicated entry to the MAINTAINERS file which adds > >> Michael and Dario as maintainers and myself as reviewer. > >> > >> [1] > >> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fpipermail%2Fu-boot%2F2023-February%2F508571.html&data=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4HDR%2BwouzdpqPFWPdvnZWRXSyjc94T%2F0pPHaXTYNrsM%3D&reserved=0 > >> > >> Signed-off-by: Frieder Schrempf > >> Cc: Jagan Teki > >> Cc: Dario Binacchi > >> Cc: Michael Nazzareno Trimarchi > >> Cc: Tom Rini > >> --- > >> MAINTAINERS | 8 > >> 1 file changed, 8 insertions(+) > >> > >> diff --git a/MAINTAINERS b/MAINTAINERS > >> index b9c505d5fa..e40c401337 100644 > >> --- a/MAINTAINERS > >> +++ b/MAINTAINERS > >> @@ -1375,6 +1375,14 @@ T: git > >> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-spi.git&data=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RPFcfbNZYy7sKTu8PruDhcIDts7ufkzrUtPr1cR8yhw%3D&reserved=0 > >> F: drivers/spi/ > >> F: include/spi* > >> > >> +SPI NAND > >> +M: Dario Binacchi > >> +M: Michael Trimarchi > >> +R: Frieder Schrempf > >> +S: Maintained > >> +T: git > >> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.denx.de%2Fu-boot%2Fcustodians%2Fu-boot-nand-flash.git&data=05%7C01%7Cfrieder.schrempf%40kontron.de%7C0ec7e2ff745f4303d31208db18d6c423%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C638131082918732044%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pGjKSC7chQZ4%2BvT7QVNDdselY2P4llM5AeEMLTjzYUI%3D&reserved=0 > >> +F: drivers/mtd/nand/spi/ > >> + > > > > Please re-send a single patch where you only consider drivers/mtd/nand > > for NAND FLASH > > in order to be as similar as possible to the Linux kernel MAINTAINERS file. > > Add to it "+R: Frieder Schrempf " > > Actually, I don't really like to be listed as reviewer for the whole > NAND subsystem. I only have limited time and knowledge and SPI NAND is > an area I feel I can provide help. > > > Neither SPI NAND nor RAW NAND exists in the Linux kernel MAINTAINERS file. > > Is there a requirement to have MAINTAINERS in sync with Linux? What matters most is that get_maintainers.pl returns something useful and correct. So if you're only comfortable with SPI NAND, the above is fine, we have similar for SPI-NOR already. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/5] Convert the LS208xA RDB/QDS boards to DM_SERIAL
On Tue, Feb 28, 2023 at 06:32:07PM +0200, Ioana Ciornei wrote: > This patch set converts the LS208xA based boards to DM_SERIAL. > > Since we don't want to introduce even more differences between the > U-Boot's and Linux's device trees the first 4 patches make the necessary > updates so that the serial nodes are synced with their counterpart. > > The last patch just enables DM_SERIAL in the associated configs. > > Ioana Ciornei (5): > arch: arm: dst: fsl-ls2080a.dtsi: add an 'soc' node > arch: arm: dst: fsl-ls2080a.dtsi: move the serial nodes under soc > arch: arm: dst: fsl-ls2080a.dts: sync serial nodes with Linux > arch: arm: dst: fsl-ls2080a.dts: tag serial nodes with bootph-all > configs: ls208x: enable DM_SERIAL > > arch/arm/dts/fsl-ls2080a.dtsi| 57 +++- > configs/ls2088aqds_tfa_defconfig | 5 +- > configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 4 +- > configs/ls2088ardb_tfa_defconfig | 4 +- > 4 files changed, 53 insertions(+), 17 deletions(-) This is good to see. My main question is, can we do a more complete sync with the upstream dts files? -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/5] Convert the LS208xA RDB/QDS boards to DM_SERIAL
On Tue, Feb 28, 2023 at 06:47:04PM +0200, Ioana Ciornei wrote: > On Tue, Feb 28, 2023 at 11:40:15AM -0500, Tom Rini wrote: > > On Tue, Feb 28, 2023 at 06:32:07PM +0200, Ioana Ciornei wrote: > > > This patch set converts the LS208xA based boards to DM_SERIAL. > > > > > > Since we don't want to introduce even more differences between the > > > U-Boot's and Linux's device trees the first 4 patches make the necessary > > > updates so that the serial nodes are synced with their counterpart. > > > > > > The last patch just enables DM_SERIAL in the associated configs. > > > > > > Ioana Ciornei (5): > > > arch: arm: dst: fsl-ls2080a.dtsi: add an 'soc' node > > > arch: arm: dst: fsl-ls2080a.dtsi: move the serial nodes under soc > > > arch: arm: dst: fsl-ls2080a.dts: sync serial nodes with Linux > > > arch: arm: dst: fsl-ls2080a.dts: tag serial nodes with bootph-all > > > configs: ls208x: enable DM_SERIAL > > > > > > arch/arm/dts/fsl-ls2080a.dtsi| 57 +++- > > > configs/ls2088aqds_tfa_defconfig | 5 +- > > > configs/ls2088ardb_tfa_SECURE_BOOT_defconfig | 4 +- > > > configs/ls2088ardb_tfa_defconfig | 4 +- > > > 4 files changed, 53 insertions(+), 17 deletions(-) > > > > This is good to see. My main question is, can we do a more complete > > sync with the upstream dts files? > > > > Sure, that would be the plan. Not in this patch set though. OK. It is future work I would very much like to see, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] rpi: Use OF_BOARD rather than OF_EMBED
On Tue, Feb 28, 2023 at 03:56:05PM +, Peter Robinson wrote: > The use of OF_EMBED isn't recommended for standard use and the OF_BOARD > is actually a better fit for the Raspberry Pi as the prior firmware > provides a DT that can be used by U-Boot and the subsequent OS too, but > it still allows the loading of a DT from disk as well if users wish > to use the upstream kernel DT. > > Signed-off-by: Peter Robinson > --- > configs/rpi_0_w_defconfig | 2 +- > configs/rpi_2_defconfig| 2 +- > configs/rpi_3_32b_defconfig| 2 +- > configs/rpi_3_b_plus_defconfig | 2 +- > configs/rpi_3_defconfig| 2 +- > configs/rpi_4_32b_defconfig| 1 + > configs/rpi_4_defconfig| 1 + > configs/rpi_arm64_defconfig| 1 + > configs/rpi_defconfig | 2 +- > 9 files changed, 9 insertions(+), 6 deletions(-) My only concern is from when I did: https://patchwork.ozlabs.org/project/uboot/patch/20211224165704.2855211-1-tr...@konsulko.com/ so I think you need to also drop the "imply OF_HAS_PRIOR_STAGE" from the Kconfig files and should probably move to select (do not allow the user to override this, it shall always be OF_EMBED now), or at least imply (sufficiently advanced users may want a different choice and should be able to make it). -- Tom signature.asc Description: PGP signature
Re: Pull request for u-boot-nand-20230227
On Mon, Feb 27, 2023 at 05:52:29PM +0100, Dario Binacchi wrote: > Hi Tom, > > The following changes since commit 0024e7f72b689f8c2df731a69e20f47b6f8dc5a7: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-tegra (2023-02-23 > 17:40:18 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-nand-flash.git > tags/u-boot-nand-20230227 > > for you to fetch changes up to d9fa61f54e7f9ac3e31c362cddda834675200a23: > > mtd: nand: Show reserved block in chip.erase (2023-02-27 16:30:13 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/15388 Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for tpm-next-28022023
On Tue, Feb 28, 2023 at 11:28:24AM +0200, Ilias Apalodimas wrote: > Hi Tom, > > The following changes since commit 5b197eee334bdf75cc9e9148161299679a5251ea: > > Merge tag 'v2023.04-rc3' into next (2023-02-27 17:28:21 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/tpm-next-28022023 > > for you to fetch changes up to a11be4c303eabb142e074c7ca14b6ae0d293f0cb: > > tpm: Implement tpm_auto_start() for TPMv1.2 (2023-02-28 09:44:33 +0200) > > The CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/15398 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/2] Azure CI: Be explicit about pytest cache directory
The default pytest cache directory is in a read-only directory in Azure,
which results in a warning on the build page. Use the pytest command
line option to set the cache dir to somewhere writable.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 609020fa5498..e0c499f8a407 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -198,7 +198,7 @@ stages:
export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
# "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if
not
- ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"} --build-dir
"$UBOOT_TRAVIS_BUILD_DIR" --report-dir "$UBOOT_TRAVIS_BUILD_DIR";
+ ./test/py/test.py -ra -o
cache_dir="$UBOOT_TRAVIS_BUILD_DIR"/.pytest_cache --bd ${TEST_PY_BD}
${TEST_PY_ID} ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"} --build-dir
"$UBOOT_TRAVIS_BUILD_DIR" --report-dir "$UBOOT_TRAVIS_BUILD_DIR";
# the below corresponds to .gitlab-ci.yml "after_script"
rm -rf /tmp/uboot-test-hooks /tmp/venv
EOF
--
2.34.1
[PATCH 1/2] Azure CI: Save pytest output automatically
Enable use of the python-azurepipelines package which provides automatic
formatting and uploading of the pytest output.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index f6609bbd6bd1..609020fa5498 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -194,10 +194,11 @@ stages:
virtualenv -p /usr/bin/python3 /tmp/venv
. /tmp/venv/bin/activate
pip install -r test/py/requirements.txt
+ pip install pytest-azurepipelines
export PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
# "${var:+"-k $var"}" expands to "" if $var is empty, "-k $var" if
not
- ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"} --build-dir
"$UBOOT_TRAVIS_BUILD_DIR";
+ ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"} --build-dir
"$UBOOT_TRAVIS_BUILD_DIR" --report-dir "$UBOOT_TRAVIS_BUILD_DIR";
# the below corresponds to .gitlab-ci.yml "after_script"
rm -rf /tmp/uboot-test-hooks /tmp/venv
EOF
--
2.34.1
Re: [PULL] Please pull u-boot-coldfire/master
On Tue, Feb 28, 2023 at 09:21:23PM +0100, Angelo Dureghello wrote: > The following changes since commit e8c80ac0f7a13bf0fc016ce324b870c0cff7a2b8: > > Prepare v2023.04-rc3 (2023-02-27 17:18:36 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-coldfire.git master > > for you to fetch changes up to 4c885f9f64cd85471614c75027620e3bcf3046bd: > > m68k: dts: stmark2: set correct compatible field for spi nor (2023-02-28 > 21:19:47 +0100) > > > Angelo Dureghello (6): > board: amcore: fix u-boot mtd partition > m68k: use longword-based jumps > m68k: add global variable sdhc_per_clk for m68k > board: stmark2: fix clock value > arch: enable private libgcc for m68k > m68k: dts: stmark2: set correct compatible field for spi nor > > arch/Kconfig| 1 + > arch/m68k/cpu/mcf530x/start.S | 18 -- > arch/m68k/dts/stmark2.dts | 2 +- > arch/m68k/include/asm/global_data.h | 3 +++ > board/sysam/stmark2/Kconfig | 2 +- > include/configs/amcore.h| 20 +++- > 6 files changed, 33 insertions(+), 13 deletions(-) OK, you need to re-work a few of the changes: https://source.denx.de/u-boot/u-boot/-/jobs/586499 Things are either in a Kconfig (and the defconfig), or now "CFG_..." instead of "CONFIG_...". -- Tom signature.asc Description: PGP signature
Re: [PULL] Please pull u-boot-coldfire/master
On Tue, Feb 28, 2023 at 10:01:46PM +0100, Angelo Dureghello wrote: > Hi Tom, > > On 28/02/23 9:34 PM, Tom Rini wrote: > > On Tue, Feb 28, 2023 at 09:21:23PM +0100, Angelo Dureghello wrote: > > > > > The following changes since commit > > > e8c80ac0f7a13bf0fc016ce324b870c0cff7a2b8: > > > > > >Prepare v2023.04-rc3 (2023-02-27 17:18:36 -0500) > > > > > > are available in the Git repository at: > > > > > >git://git.denx.de/u-boot-coldfire.git master > > > > > > for you to fetch changes up to 4c885f9f64cd85471614c75027620e3bcf3046bd: > > > > > >m68k: dts: stmark2: set correct compatible field for spi nor > > > (2023-02-28 > > > 21:19:47 +0100) > > > > > > > > > Angelo Dureghello (6): > > >board: amcore: fix u-boot mtd partition > > >m68k: use longword-based jumps > > >m68k: add global variable sdhc_per_clk for m68k > > >board: stmark2: fix clock value > > >arch: enable private libgcc for m68k > > >m68k: dts: stmark2: set correct compatible field for spi nor > > > > > > arch/Kconfig| 1 + > > > arch/m68k/cpu/mcf530x/start.S | 18 -- > > > arch/m68k/dts/stmark2.dts | 2 +- > > > arch/m68k/include/asm/global_data.h | 3 +++ > > > board/sysam/stmark2/Kconfig | 2 +- > > > include/configs/amcore.h| 20 +++- > > > 6 files changed, 33 insertions(+), 13 deletions(-) > > > > OK, you need to re-work a few of the changes: > > https://source.denx.de/u-boot/u-boot/-/jobs/586499 > > > > Things are either in a Kconfig (and the defconfig), or now "CFG_..." > > instead of "CONFIG_...". > > > > i received the automated email. Fixes are in progress, but > not ready still, there are several CFG to be fixed. > Could i ask another pull request later, for next release ? Yes, that's fine. -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-at91-fixes-2023.04-a
On Wed, Mar 01, 2023 at 11:26:52AM +0200, Eugen Hristev wrote: > Hello Tom, > > Please pull tag u-boot-at91-fixes-2023.04-a , the first set of at91 > fixes for the cycle 2023.04 . > > This fixes set include one clock index fix for sama7g5 and two board > configuration alignments for pm9g45. > > Thanks, > Eugen > > > The following changes since commit e8c80ac0f7a13bf0fc016ce324b870c0cff7a2b8: > > Prepare v2023.04-rc3 (2023-02-27 17:18:36 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-at91.git > tags/u-boot-at91-fixes-2023.04-a > > for you to fetch changes up to 1415cdac77d66b3d6ed4b4367e31c61dae41aebe: > > ARM: dts: at91: sama7g5: fix clock id for ebi node (2023-02-28 10:38:19 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-rockchip-20230228
On Wed, Mar 01, 2023 at 08:23:50AM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the updates for rockchip platform: > - Add support for rk3588 soc; > - Add rk3588 Edgeble Neu6 board and Radxa ROCK5B board; > - Add rk3308 Radxa ROCK Pi S board; > - Add rk3568 Radxa ROCK 3 board, > - Add rk3566 Radxa Compute Module 3 board; > - Add support for sdram reg info version 3 > - Refactor rockchip OTP/eFuse driver and add more soc support; > - Add external TPL support for binman; > > binman support for mkimage ignore missing entry is based on [1]; > > CI: > https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/15403 > > Thanks, > - Kever > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20230219220158.4160763-7-jo...@kwiboo.se/ > > > The following changes since commit e8c80ac0f7a13bf0fc016ce324b870c0cff7a2b8: > > Prepare v2023.04-rc3 (2023-02-27 17:18:36 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20230228 > > for you to fetch changes up to a6e85a35b50ade7df5f32092c1cc05ade303a22a: > > board: rock5b-rk3588: add memory gaps into kernel's DTB (2023-02-28 > 18:07:29 +0800) > As I have been waiting for this, as it resolves some fairly important fixes, I've taken this to master for the next release. But looking forward, lets please try and get these bigger PRs done by -rc1 or -rc2 at the latest. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 02/26] cmd: nvedit: check for ENV_SUPPORT
On Fri, Feb 24, 2023 at 10:10:23AM -0800, Troy Kisky wrote:
> Avoid error messages when SPL,TPL,VPL build don't
> have the environment options of the main build.
> This is needed when defined(CONFIG_ENV_IS_IN_xxx) is changed
> to CONFIG_IS_ENABLED(ENV_IS_IN_xxx).
>
> Signed-off-by: Troy Kisky
> Reviewed-by: Simon Glass
> ---
>
> (no changes since v1)
>
> cmd/nvedit.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index 7cbc3fd573a..ef0fe55431c 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -43,6 +43,7 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if CONFIG_IS_ENABLED(ENV_SUPPORT)
> #if defined(CONFIG_ENV_IS_IN_EEPROM)|| \
> defined(CONFIG_ENV_IS_IN_FLASH) || \
> defined(CONFIG_ENV_IS_IN_MMC) || \
> @@ -60,10 +61,12 @@ DECLARE_GLOBAL_DATA_PTR;
> #endif
>
> #if !defined(ENV_IS_IN_DEVICE) && \
> - !defined(CONFIG_ENV_IS_NOWHERE)
> + !defined(CONFIG_ENV_IS_NOWHERE) && \
> + !defined(CONFIG_VPL_BUILD)
> # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|MMC|FAT|EXT4|\
> NAND|NVRAM|ONENAND|SATA|SPI_FLASH|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
> #endif
> +#endif
This is one of the #error messes that we no longer need with Kconfig,
where we can ensure things happen. Maybe we can use def_bool y if ..
instead of default y if ..., in the ENV_IS_NOWHERE choice ?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 03/26] lib: crc32: prepare for CONFIG_IS_ENABLED changes
On Fri, Feb 24, 2023 at 10:10:24AM -0800, Troy Kisky wrote: > We need to include in order to include > files that use CONFIG_IS_ENABLED. TO prepare for that > be more direct with using defined(USE_HOSTCC). > > Signed-off-by: Troy Kisky > Reviewed-by: Simon Glass > --- > > Changes in v2: > - delay include of linux/kconfig.h to do from Makefile > - as suggested by Simon > > lib/crc32.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/lib/crc32.c b/lib/crc32.c > index aa94d70ef3e..12c104c62a4 100644 > --- a/lib/crc32.c > +++ b/lib/crc32.c > @@ -14,11 +14,14 @@ > #else > #include > #include > +#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) > +#define PET_WDG > +#endif Lets introduce a Kconfig symbol like HAS_WATCHDOG_RUNNING and then update all of the places we have this convention (there's a few this series doesn't touch). -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 08/26] tools: prevent CONFIG_IS_ENABLED errors by including linux/kconfig.h
On Fri, Feb 24, 2023 at 10:10:29AM -0800, Troy Kisky wrote: > We need to include in order to include > files that use CONFIG_IS_ENABLED. > > Signed-off-by: Troy Kisky > Reviewed-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 09/26] tools: Makefile: prepare for CONFIG_IS_ENABLED changes by adding CONFIG_TOOLS_xxx
On Fri, Feb 24, 2023 at 10:10:30AM -0800, Troy Kisky wrote: > CONFIG_IS_ENABLED(FIT_SIGNATURE) will check for > CONFIG_TOOLS_FIT_SIGNATURE. So define it now in preparation. > > Signed-off-by: Troy Kisky > Reviewed-by: Simon Glass > --- > > (no changes since v1) > > tools/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/Makefile b/tools/Makefile > index 5d6284e6451..86f1b6b5049 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -162,8 +162,10 @@ ifdef CONFIG_TOOLS_LIBCRYPTO > # This affects include/image.h, but including the board config file > # is tricky, so manually define this options here. > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE > +HOST_EXTRACFLAGS += -DCONFIG_TOOLS_FIT_SIGNATURE=1 > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x > HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER > +HOST_EXTRACFLAGS += -DCONFIG_TOOLS_FIT_CIPHER=1 > endif Is the "=1" required here, as in we check the value of the define, not just that it is defined? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 14/26] puma-rk3399: use IS_ENABLED_NOCHECK to avoid CI test failure for ENV_IS_NOWHERE
On Fri, Feb 24, 2023 at 10:10:35AM -0800, Troy Kisky wrote: > When usage_of_is_enabled_check.sh is added, this will show a false > positive for IS_ENABLED(CONFIG_ENV_IS_NOWHERE). > Use IS_ENABLED_NOCHECK to avoid check and error on SPL builds. > > Signed-off-by: Troy Kisky > --- > > Changes in v2: > - keep #error, but change condition to use IS_ENABLED_NOCHECK > > board/theobroma-systems/puma_rk3399/puma-rk3399.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) As I said against v1, the platform needs to select ENV_IS_NOWHERE. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 5/6] Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On Wed, Mar 01, 2023 at 03:01:30PM +0530, Manorit Chawdhry wrote:
> In non-combined boot flow for K3, all the firewalls are locked by default
> until sysfw comes up. Rom configures some of the firewall for its usage
> along with the SRAM for R5 but the PSRAM region is still locked.
>
> The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
> firewall exception before sysfw came up. The exception started happening
> after adding multi dtb support that accesses the scratchpad for reading
> EEPROM contents.
>
> The commit changes R5 MCU scratchpad for j721e to an SRAM region.
>
> Old Map:
> ┌─┐ 0x41c0
> │ SPL │
> ├─┤ 0x41c4 (approx)
> │STACK│
> ├─┤ 0x41c85b20
> │ Global data │
> │ sizeof(struct global_data) = 0xd8 │
> ├─┤ gd->malloc_base = 0x41c85bfc
> │HEAP │
> │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> ├─┤ CONFIG_SPL_BSS_START_ADDR
> │ SPL BSS │ (0x41cf5bfc)
> │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> (0x41cffbfc)
>
> New Map:
> ┌─┐ 0x41c0
> │ SPL │
> ├─┤ 0x41c4 (approx)
> │EMPTY│
> ├─┤ 0x41c81920
> │STACK│
> │ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
> ├─┤ 0x41c85920
> │ Global data │
> │ sizeof(struct global_data) = 0xd8 │
> ├─┤ gd->malloc_base = 0x41c859f0
> │HEAP │
> │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> ├─┤ CONFIG_SPL_BSS_START_ADDR
> │ SPL BSS │ (0x41cf59f0)
> │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> ├─┤ 0x41cff9fc
> │ NEW MCU SCRATCHPAD │
> │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
> └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> (0x41cffbfc)
>
> Fixes: ab977c8b91b4 ("configs: j721s2_evm_r5: Enable support for building
> multiple dtbs into FIT")
>
> Signed-off-by: Manorit Chawdhry
> [n-fran...@ti.com: SRAM allocation addressing diagram]
> Signed-off-by: Neha Francis
Reviewed-by: Tom Rini
But can we please get that map information in something under
doc/board/ti/ as a follow-up?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 1/1] editorconfig: introduce .editorconfig
On Wed, Mar 01, 2023 at 01:43:38PM +0300, Dzmitry Sankouski wrote:
> Current process of sending patches includes running checkpatch.pl
> script for each patch, and fixing found style problems.
> EditorConfig may help to prevent some style related problems
> (like spaces vs tab indentation) on the fly.
>
> Reviewed-by: Simon Glass
> ---
> Changes for v2:
> - add section in coding style rst doc
> - unify Kconfig with other files
>
> .editorconfig | 15 +++
> .gitignore | 1 +
> doc/develop/codingstyle.rst | 4
> 3 files changed, 20 insertions(+)
> create mode 100644 .editorconfig
>
> diff --git a/.editorconfig b/.editorconfig
> new file mode 100644
> index 00..10fe165f09
> --- /dev/null
> +++ b/.editorconfig
> @@ -0,0 +1,15 @@
> +; This file is for unifying the coding style for different editors and IDEs.
> +; Plugins are available for notepad++, emacs, vim, gedit,
> +; textmate, visual studio, and more.
> +;
> +; See http://editorconfig.org for details.
> +
> +# Top-most EditorConfig file.
> +root = true
> +
> +[{**.c, **.h, **Kconfig}]
> +indent_style = tab
> +indent_size=8
As Simon noted before, this should be " = 8".
> +end_of_line = lf
> +trim_trailing_whitespace = true
> +insert_final_newline = true
> diff --git a/.gitignore b/.gitignore
> index 3a4d056edf..ed8ca226fe 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -7,6 +7,7 @@
> #
> .*
> !.checkpatch.conf
> +!.editorconfig
> *.a
> *.asn1.[ch]
> *.bin
> diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> index 1d5d0192b3..741bc58b83 100644
> --- a/doc/develop/codingstyle.rst
> +++ b/doc/develop/codingstyle.rst
> @@ -27,6 +27,10 @@ The following rules apply:
>more information, read :doc:`checkpatch`. Note that this should be done
>*before* posting on the mailing list!
>
> +* Some code style rules may be applied automatically by your editor using
"using the"
> + EditorConfig tool. Feel free to setup your editor to work with u-boot's
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] image: Fix potentially uninitialized data variable
On Mon, Feb 27, 2023 at 08:56:31PM +0100, Marek Vasut wrote: > In case fitImage support is disabled, and image_locate_script() is > passed a fitImage, then the 'data' variable is used uninitialized. > Drop into the default: branch of the switch-case statement and do > not return the uninitialized data, and do not modify the return > pointer either, just print an error message. > > Reported by clang build: > " > $ make HOSTCC=clang CC=clang KCFLAGS=-Werror sandbox64_defconfig && make > HOSTCC=clang CC=clang KCFLAGS=-Werror > ... > boot/image-board.c:1006:7: error: variable 'data' is used uninitialized > whenever switch case is taken [-Werror,-Wsometimes-uninitialized] > case IMAGE_FORMAT_LEGACY: > ^~~ > include/image.h:608:29: note: expanded from macro 'IMAGE_FORMAT_LEGACY' > ^~~~ > boot/image-board.c:1128:19: note: uninitialized use occurs here > *datap = (char *)data; > ^~~~ > boot/image-board.c:1001:11: note: initialize the variable 'data' to silence > this warning > u32 *data; > ^ > = NULL > " > > Signed-off-by: Marek Vasut Reviewed-by: Tom Rini And can you please do a follow-up that adds sandbox64 + clang, after the sandbox + clang test in GitLab/Azure? -- Tom signature.asc Description: PGP signature
Re: Re-writing SMC91111 Ethernet driver
On Sat, Feb 18, 2023 at 11:30:28PM +, Robert Catherall wrote: > Hi, > > The SMC9 Ethernet driver was removed in commit > > ecf1d2741d95f5f84e31dc1d0bef149d8ff1f0a3 > > because it had not been converted to DM_ETH. > > I would be interested in doing the conversion and re-instating the driver to > support Arm FastModel virtual prototypes (and Juno r0 hardware while I'm at > it). I had a couple of questions > > 1. Is there any advantage or preference for starting with the previous code > or am I free to start from another point? > > My inclination was to copy'n'paste something like the SMC91x driver in order > to get the outline, CONFIG_OF and DM_ETH framework correct and then fill out > the actual moving parts with code from the previous implementation (or the > Linux kernel if that has been updated more recently). > > 2. Can I ignore all the original CONFIG_ options and just write a driver > that supports one fixed combination of those options and is only intended to > work in the vexpress64 config? > > Based on the commit above it was only still in use on two armltd platforms: > integrator (splendidly obsolete) and vexpress64 (which covers my two cases). > > I don't want to unnecessarily disadvantage another platform that could > otherwise benefit from re-enabling the device again, but equally it would be > nice to avoid the various macros for different types of access especially if > I can't test them, and they are unlikely to ever be used. Sorry for the late reply. Yes, please feel free to write a driver that feeds the needs you have today for it, and not feel bound by what was used previously. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/next
On Wed, Mar 01, 2023 at 04:49:01PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the following Marvell MVEBU related patches into next: > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/1] editorconfig: introduce .editorconfig
On Thu, Mar 02, 2023 at 06:00:43PM +0300, Dzmitry Sankouski wrote:
> ср, 1 мар. 2023 г. в 18:58, Tom Rini :
> >
> > On Wed, Mar 01, 2023 at 01:43:38PM +0300, Dzmitry Sankouski wrote:
> > > Current process of sending patches includes running checkpatch.pl
> > > script for each patch, and fixing found style problems.
> > > EditorConfig may help to prevent some style related problems
> > > (like spaces vs tab indentation) on the fly.
> > >
> > > Reviewed-by: Simon Glass
> > > ---
> > > Changes for v2:
> > > - add section in coding style rst doc
> > > - unify Kconfig with other files
> > >
> > > .editorconfig | 15 +++
> > > .gitignore | 1 +
> > > doc/develop/codingstyle.rst | 4
> > > 3 files changed, 20 insertions(+)
> > > create mode 100644 .editorconfig
> > >
> > > diff --git a/.editorconfig b/.editorconfig
> > > new file mode 100644
> > > index 00..10fe165f09
> > > --- /dev/null
> > > +++ b/.editorconfig
> > > @@ -0,0 +1,15 @@
> > > +; This file is for unifying the coding style for different editors and
> > > IDEs.
> > > +; Plugins are available for notepad++, emacs, vim, gedit,
> > > +; textmate, visual studio, and more.
> > > +;
> > > +; See http://editorconfig.org for details.
> > > +
> > > +# Top-most EditorConfig file.
> > > +root = true
> > > +
> > > +[{**.c, **.h, **Kconfig}]
> > > +indent_style = tab
> > > +indent_size=8
> >
> > As Simon noted before, this should be " = 8".
> >
> oops, I thought he meant consistent spacing in a sense of 8 spaces.
> I personally like Kconfigs with 4 indent more.
Ah. But, in both cases it should be 8, as well.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 6/8] boot: Create a common BOOT_DEFAULTS for distro and bootstd
On Wed, Mar 01, 2023 at 08:39:27PM -0700, Simon Glass wrote: > These two features use a lot of common options. Move them into a common > CONFIG to reduce duplication. > > Resync defconfigs since this makes a lot of changes. > > Signed-off-by: Simon Glass [snip] > diff --git a/boot/Kconfig b/boot/Kconfig > index da18d4738a7..7f7ec208a54 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -350,6 +350,35 @@ config PXE_UTILS > help > Utilities for parsing PXE file formats. > > +config BOOT_DEFAULTS > + bool # Common defaults for standard boot and distroboot > + imply USE_BOOTCOMMAND > + # Bring in some defaults which are generally needed. Boards can drop > + # these as needed to save code space. Bootstd does not generally require > + # the commands themselves to be enabled, but this is how some of the > + # functionality is controlled at present > + select CMD_ENV_EXISTS > + imply CMD_EXT2 > + imply CMD_EXT4 > + imply CMD_FAT > + imply CMD_FS_GENERIC > + imply CMD_PART if PARTITIONS > + imply CMD_DHCP if NET > + imply CMD_MII if NET > + imply CMD_PING if NET > + imply CMD_PXE if NET > + imply USB_STORAGE > + imply SUPPORT_RAW_INITRD > + imply ENV_VARS_UBOOT_CONFIG > + imply EFI_PARTITION > + imply ISO_PARTITION > + select CMD_BOOTI if ARM64 > + select CMD_BOOTZ if ARM && !ARM64 > + help > + These are not required but are commonly needed to support a good > + selection of booting methods. Enable this to improve the capability > + of U-Boot to boot various images. We want the more heavy-handed select rather than imply here, as this is part of making sure people do end up with a set of default that will work and not unexpectedly fail to boot off-the-shelf things. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/8] rockchip: Disable DISTRO_DEFAULTS for rk3399 boards
On Wed, Mar 01, 2023 at 08:39:23PM -0700, Simon Glass wrote: > These board have moved to standard boot but the old 'distro_bootcmd' > command is still active. Disable DISTRO_DEFAULTS to fix this. > > Signed-off-by: Simon Glass > Tested-by: Vagrant Cascadian > --- > > (no changes since v1) > > arch/arm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index bd7fffcce0b..4e7ebeaee87 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1955,7 +1955,7 @@ config ARCH_ROCKCHIP > imply ADC > imply CMD_DM > imply DEBUG_UART_BOARD_INIT > - imply DISTRO_DEFAULTS > + imply DISTRO_DEFAULTS if !ROCKCHIP_RK3399 > imply FAT_WRITE > imply SARADC_ROCKCHIP > imply SPL_SYSRESET This is just opening the door to the next conversion failing for the same reason I think. We need a new Kconfig symbol, DISTRO_BOOTCMD which is askable and default y depends on DISTRO_DEFAULTS. Then you can do imply/select logic for the conversion based on if they have DISTRO_BOOTCMD or BOOTSTD_BOOTCOMMAND. Because part of the problem here is that we don't have an option for distro_bootcmd itself, so we need one. That's in essence the second half of the patch you did which moves "this is functionality really everyone should enable, for a good general user experience" out of DISTRO_DEFAULTS&&BOOTSTD_DEFAULTS and in to its own symbol. -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-dm
On Wed, Mar 01, 2023 at 01:10:57PM -0700, Simon Glass wrote: > Hi Tom, > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/15430 > > The following changes since commit b0eda49bc9b00503366f2ec431be0178caf9e9b5: > > Merge tag 'u-boot-at91-fixes-2023.04-a' of > https://source.denx.de/u-boot/custodians/u-boot-at91 (2023-03-01 > 09:39:18 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-29feb23 > > for you to fetch changes up to abe2a16aa52ea21acb435e9f1d9c85f5ac4e7794: > > tools: binman: minor formatting fix in docs (2023-03-01 11:22:40 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: No such file or directory: lxdialog/dialog.h
On Wed, Mar 01, 2023 at 08:19:24PM -0500, Nick Carraway wrote: > Hello! > > Apologies to bother y'all with this. I am at wit's end. I think this > is an issue that I've encountered before and figured out how to solve, > but I can't for the life of me figure out what to do this time around. > > Whenever I try to `make O=../generic-build menuconfig` from my u-boot > build directory, I get this error: > > "Error: No such file or directory: lxdialog/dialog.h" in line 22 the > file scripts/kconfig/mconf.c. It's one of the first parts of the > menuconfig issues. > > This error occurs on Debian bullseye and Debian buster! And I'm pretty > sure it was working before, because I have successful builds from the > 2021-10-rc5. But even when I git rollback to that one, I still get the > error. I thought it was my build environment until I switched machines > and got the same result! Both machines run arm64 - is that the issue?? > > I went into the library paths. One of the machines has a "dialog.h" > header, but it's not in the "lxdialog/dialog.h" header. How do I get > this library?? I'm so confused. > > Bullseye and buster both have libncurses5 and 6, w5, and w6, but > nothing beyond that. I say this because this is what most search > engines seem to hint that the problem is. I think this is not really a > dependency error though, and something else is going on. I really just > don't know what the problem is because this code was working about a > year ago and nothing on the machine changed, but now I can't figure > out what I did to make it work! I have a feeling there's something funny going on with your system, but, a "V=1" passed to make will at least start showing you what/where gcc is looking. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 18/44] env: Avoid checking ENV_IS_IN when env disabled
On Wed, Feb 22, 2023 at 09:33:59AM -0700, Simon Glass wrote:
> This check is not needed when the environment is not enabled, e.g. in
> SPL. Add a condition to handle this.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> cmd/nvedit.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index 7cbc3fd573a..277293679df 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -59,11 +59,13 @@ DECLARE_GLOBAL_DATA_PTR;
>
> #endif
>
> +#if CONFIG_IS_ENABLED(ENV_SUPPORT)
> #if !defined(ENV_IS_IN_DEVICE) && \
> !defined(CONFIG_ENV_IS_NOWHERE)
> # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|MMC|FAT|EXT4|\
> NAND|NVRAM|ONENAND|SATA|SPI_FLASH|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
> #endif
> +#endif /* ENV_SUPPORT */
We need to move this kind of sanity enforcement to Kconfig, and drop the
#error.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 09/26] tools: Makefile: prepare for CONFIG_IS_ENABLED changes by adding CONFIG_TOOLS_xxx
On Thu, Mar 02, 2023 at 10:21:29AM -0800, Troy Kisky wrote: > On Wed, Mar 1, 2023 at 7:33 AM Tom Rini wrote: > > > On Fri, Feb 24, 2023 at 10:10:30AM -0800, Troy Kisky wrote: > > > CONFIG_IS_ENABLED(FIT_SIGNATURE) will check for > > > CONFIG_TOOLS_FIT_SIGNATURE. So define it now in preparation. > > > > > > Signed-off-by: Troy Kisky > > > Reviewed-by: Simon Glass > > > --- > > > > > > (no changes since v1) > > > > > > tools/Makefile | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/tools/Makefile b/tools/Makefile > > > index 5d6284e6451..86f1b6b5049 100644 > > > --- a/tools/Makefile > > > +++ b/tools/Makefile > > > @@ -162,8 +162,10 @@ ifdef CONFIG_TOOLS_LIBCRYPTO > > > # This affects include/image.h, but including the board config file > > > # is tricky, so manually define this options here. > > > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE > > > +HOST_EXTRACFLAGS += -DCONFIG_TOOLS_FIT_SIGNATURE=1 > > > HOST_EXTRACFLAGS += -DCONFIG_FIT_SIGNATURE_MAX_SIZE=0x > > > HOST_EXTRACFLAGS += -DCONFIG_FIT_CIPHER > > > +HOST_EXTRACFLAGS += -DCONFIG_TOOLS_FIT_CIPHER=1 > > > endif > > > > Is the "=1" required here, as in we check the value of the define, not > > just that it is defined? > > > > -- > > Tom > > > > When it is converted to CONFIG_IS_ENABLED it will require the =1 > The CONFIG_IS_ENABLED logic counts the number of parameters and "empty > string" doesn't count. > I think it also compares to 1 somewhere in there. Ah, OK, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 44/44] command: Don't allow commands in SPL
On Wed, Feb 22, 2023 at 09:34:25AM -0700, Simon Glass wrote: > At present we compile commands into U-Boot SPL even though they cannot > be used. This wastes space. Adjust the condition to avoid this. > > Signed-off-by: Simon Glass > --- > > Changes in v5: > - Drop FSL_ISBC_KEY_EXT patch as it changes the size > - Drop PHY_CADENCE_SIERRA patch as it changes the size > > Changes in v3: > - Add a new patch to disallow commands in SPL > > include/command.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) As a follow-up, "git grep -l u_boot_list_2_cmd" shows some lds scripts that I believe can be updated, after this change. And in reviewing this change, yes, a few boards now discard some functionality, but, it looks like it's reasonable and not that we're removing some intentional but odd configurations. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 21/44] x86: Use string functions for all 32-bit builds
On Wed, Feb 22, 2023 at 09:34:02AM -0700, Simon Glass wrote: > At present these are not included in SPL. They do add to code size but > are a bit faster, so adjust the setting to add them. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/x86/include/asm/string.h | 2 +- > arch/x86/lib/Makefile | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/include/asm/string.h b/arch/x86/include/asm/string.h > index c15b264a5c0..0254a022160 100644 > --- a/arch/x86/include/asm/string.h > +++ b/arch/x86/include/asm/string.h > @@ -14,7 +14,7 @@ extern char *strrchr(const char *s, int c); > #undef __HAVE_ARCH_STRCHR > extern char *strchr(const char *s, int c); > > -#ifdef CONFIG_X86_64 > +#if CONFIG_IS_ENABLED(X86_64) > > #undef __HAVE_ARCH_MEMCPY > extern void *memcpy(void *, const void *, __kernel_size_t); > diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile > index a6f22441474..ea7ff2bcf38 100644 > --- a/arch/x86/lib/Makefile > +++ b/arch/x86/lib/Makefile > @@ -4,7 +4,7 @@ > # Wolfgang Denk, DENX Software Engineering, w...@denx.de. > > obj-y+= bdinfo.o > -ifndef CONFIG_X86_64 > +ifndef CONFIG_$(SPL_TPL_)X86_64 > ifndef CONFIG_TPL_BUILD > obj-y += bios.o > obj-y += bios_asm.o This is just.. confusing. Please re-work the string selection code to be more direct, with a new symbol if needed. And please re-examine if SPL_X86_64 is needed as a symbol at all. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 38/44] freescale: Fix odd use of ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
On Wed, Feb 22, 2023 at 09:34:19AM -0700, Simon Glass wrote:
> This is not a CONFIG option so we should not be using IS_ENABLED() on it,
> particularly not when it is not defined to anything, so shows up as
> calling IS_ENABLED() with no arguments.
>
> Just check it normally.
>
> For fsl_esdhc.c set it to 0 at the top of the file if it is not defined.
> This sort-of matches the behaviour in fsl_esdhc_mmc.c which seem to have
> a similar problem.
>
> This fixes a build error with split config on T2080QDS.
>
> Note: This should be handled in the devicetree.
>
> Signed-off-by: Simon Glass
> ---
> No size changes on affected boards:
>
>aarch64: w+ ls1088aqds ls1088aqds_qspi ls1088aqds_qspi_SECURE_BOOT
> ls1088aqds_sdcard_ifc ls1088aqds_sdcard_qspi ls1088aqds_tfa ls1088ardb_qspi
> ls1088ardb_qspi_SECURE_BOOT ls1088ardb_sdcard_qspi
> ls1088ardb_sdcard_qspi_SECURE_BOOT ls1088ardb_tfa ls1088ardb_tfa_SECURE_BOOT
> ls2080aqds ls2080aqds_nand ls2080aqds_qspi ls2080aqds_sdcard
> ls2080aqds_SECURE_BOOT ls2088aqds_tfa
>arm: w+ am57xx_hs_evm_usb
>powerpc: w+ P2041RDB P2041RDB_NAND P2041RDB_SDCARD P2041RDB_SPIFLASH
> T1024RDB T1024RDB_NAND T1024RDB_SDCARD T1024RDB_SPIFLASH T1042D4RDB
> T1042D4RDB_NAND T1042D4RDB_SDCARD T1042D4RDB_SPIFLASH T2080QDS T2080QDS_NAND
> T2080QDS_SDCARD T2080QDS_SECURE_BOOT T2080QDS_SPIFLASH
> T2080QDS_SRIO_PCIE_BOOT T2080RDB T2080RDB_NAND T2080RDB_revD
> T2080RDB_revD_NAND T2080RDB_revD_SDCARD T2080RDB_revD_SPIFLASH
> T2080RDB_SDCARD T2080RDB_SPIFLASH kmcent2
>
> Changes in v5:
> - Change approach and expand notes after more investigation
>
> arch/powerpc/include/asm/config_mpc85xx.h | 6 +++---
> drivers/mmc/fsl_esdhc.c | 6 +-
> drivers/mmc/fsl_esdhc_imx.c | 4 +++-
> 3 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/config_mpc85xx.h
> b/arch/powerpc/include/asm/config_mpc85xx.h
> index d990ecff96f..358ccef7f1d 100644
> --- a/arch/powerpc/include/asm/config_mpc85xx.h
> +++ b/arch/powerpc/include/asm/config_mpc85xx.h
> @@ -134,7 +134,7 @@
> #define CFG_FM_PLAT_CLK_DIV 1
> #define CFG_SYS_FM1_CLK CFG_FM_PLAT_CLK_DIV
> #define CFG_SYS_FM_MURAM_SIZE0x3
> -#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE0
> #define QE_MURAM_SIZE0x6000UL
> #define MAX_QE_RISC 1
> #define QE_NUM_OF_SNUM 28
> @@ -147,7 +147,7 @@
> #define CFG_SYS_FM1_CLK 0
> #define CFG_QBMAN_CLK_DIV1
> #define CFG_SYS_FM_MURAM_SIZE0x3
> -#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE0
> #define QE_MURAM_SIZE0x6000UL
> #define MAX_QE_RISC 1
> #define QE_NUM_OF_SNUM 28
> @@ -166,7 +166,7 @@
> #define CFG_SYS_PME_CLK CFG_PME_PLAT_CLK_DIV
> #define CFG_SYS_FM1_CLK 0
> #define CFG_SYS_FM_MURAM_SIZE0x28000
> -#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE0
>
>
> #elif defined(CONFIG_ARCH_C29X)
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> index d506698..ecb9c3b30c9 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc.c
> @@ -34,6 +34,10 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#ifndef ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE0
> +#endif
> +
> struct fsl_esdhc {
> uintdsaddr; /* SDMA system address register */
> uintblkattr;/* Block attributes register */
> @@ -325,7 +329,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
> struct mmc *mmc,
> (timeout == 4 || timeout == 8 || timeout == 12))
> timeout++;
>
> - if (IS_ENABLED(ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE))
> + if (ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE)
> timeout = 0xE;
>
> esdhc_clrsetbits32(®s->sysctl, SYSCTL_TIMEOUT_MASK, timeout << 16);
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index 66caf683f74..9d9ffd0990a 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -43,6 +43,8 @@
> #ifndef ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE
> #ifdef CONFIG_FSL_USDHC
> #define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE1
> +#else
> +#define ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE0
> #endif
> #endif
>
> @@ -375,7 +377,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
> struct mmc *mmc,
> (timeout == 4 || timeout == 8 || timeout == 12))
> timeout++;
>
> - if (IS_ENABLED(ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE))
> + if (ESDHCI_QUIRK_BROKEN_TIMEOUT_VALUE)
> timeout = 0xE;
>
> esdhc_clrsetbits32(®s->sysctl, SYSCTL_TIMEOUT_MASK, timeout << 16);
Looking at commit 52faec31827e ("mmc: fsl_esdhc: replace most #ifdefs by
IS
Re: [PATCH v5 32/44] x86: Fix up use of X86_32BIT_INIT and X86_64 options
On Wed, Feb 22, 2023 at 09:34:13AM -0700, Simon Glass wrote: > Drop the invalid SPL_ in a CONFIG_IS_ENABLED() usage. Use the correct > X86_64 option in msr.h since SPL may be 32-bit when U-Bout proper is > not. > > Signed-off-by: Simon Glass > --- > > (no changes since v4) > > Changes in v4: > - Reduce and rename commit > > arch/x86/cpu/qemu/qemu.c | 2 +- > arch/x86/include/asm/msr.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) This changes spl on chromebook_link64 a lot, have you confirmed it there? -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 3/4] Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region
On Fri, Mar 03, 2023 at 03:59:35PM +0530, Manorit Chawdhry wrote:
> In non-combined boot flow for K3, all the firewalls are locked by default
> until sysfw comes up. Rom configures some of the firewall for its usage
> along with the SRAM for R5 but the PSRAM region is still locked.
>
> The K3 MCU Scratchpad for j721e was set to a PSRAM region triggering the
> firewall exception before sysfw came up. The exception started happening
> after adding multi dtb support that accesses the scratchpad for reading
> EEPROM contents.
>
> The commit changes R5 MCU scratchpad for j721e to an SRAM region.
>
> Old Map:
> ┌─┐ 0x41c0
> │ SPL │
> ├─┤ 0x41c4 (approx)
> │STACK│
> ├─┤ 0x41c85b20
> │ Global data │
> │ sizeof(struct global_data) = 0xd8 │
> ├─┤ gd->malloc_base = 0x41c85bfc
> │HEAP │
> │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> ├─┤ CONFIG_SPL_BSS_START_ADDR
> │ SPL BSS │ (0x41cf5bfc)
> │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> (0x41cffbfc)
>
> New Map:
> ┌─┐ 0x41c0
> │ SPL │
> ├─┤ 0x41c4 (approx)
> │EMPTY│
> ├─┤ 0x41c81920
> │STACK│
> │ SPL_SIZE_LIMIT_PROVIDE_STACK=0x4000 │
> ├─┤ 0x41c85920
> │ Global data │
> │ sizeof(struct global_data) = 0xd8 │
> ├─┤ gd->malloc_base = 0x41c859f0
> │HEAP │
> │ CONFIG_SYS_MALLOC_F_LEN = 0x7 │
> ├─┤ CONFIG_SPL_BSS_START_ADDR
> │ SPL BSS │ (0x41cf59f0)
> │ CONFIG_SPL_BSS_MAX_SIZE = 0xA000 │
> ├─┤ 0x41cff9fc
> │ NEW MCU SCRATCHPAD │
> │ SYS_K3_MCU_SCRATCHPAD_SIZE = 0x200 │
> └─┘ CONFIG_SYS_K3_BOOT_PARAM_TABLE_INDEX
> (0x41cffbfc)
>
> Fixes: ab977c8b91b4 ("configs: j721s2_evm_r5: Enable support for building
> multiple dtbs into FIT")
>
> Signed-off-by: Manorit Chawdhry
> [n-fran...@ti.com: SRAM allocation addressing diagram]
> Signed-off-by: Neha Francis
> Reviewed-by: Tom Rini
> ---
> arch/arm/mach-k3/Kconfig | 3 ++-
> configs/j721e_evm_r5_defconfig | 10 --
> doc/board/ti/j721e_evm.rst | 24
OK, sorry. I'm glad you added this to the rst, but it's not a literal
drop-in. The first issue is that "make htmldocs" notices indentation
problems, and I was checking this because I'm not sure how what you did
would render. Please make sure "make htmldocs" at least passes, and
check the output in a browser as well to make sure the table reads
well. FWIW, this is the same sphinx docbook stuff as the kernel, so
there's probably some other examples in tree there you can look at if
you can't find anything in-tree here that gets you the output you want.
--
Tom
signature.asc
Description: PGP signature
Re: [PULL] u-boot-usb/next
On Fri, Mar 03, 2023 at 01:05:10AM +0100, Marek Vasut wrote: > The following changes since commit 49cba67852f1fb5ef481bef3532b2cda96816e45: > > Merge branch 'next' of > https://source.denx.de/u-boot/custodians/u-boot-marvell into next > (2023-03-01 11:00:22 -0500) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next > > for you to fetch changes up to ea436dbc40e01a6c483c41d7ec1e4a419fc6b7c0: > > dt-bindings: usb: mtk-xhci: add support mt8195 (2023-03-02 22:43:44 +0100) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/13] common/Kconfig: Reword text for BOARD_TYPES
On Wed, Feb 15, 2023 at 10:36:47PM -0500, Tom Rini wrote: > While it is true that for some Samsung platforms, we call > get_board_type() the main usage of this CONFIG switch is to enable > board_types in global data, which is then used by various platforms. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/13] arm: mvebu: Add select on ARCH_EARLY_INIT_R if ARM64
On Wed, Feb 15, 2023 at 10:36:48PM -0500, Tom Rini wrote: > We need to be calling arch_early_init_r() on 64bit mvebu platforms, so > move this to a select. > > Cc: Stefan Roese > Signed-off-by: Tom Rini > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 03/13] arm: zynq: Move to select'ing ARCH_EARLY_INIT_R if we have FPGA
On Wed, Feb 15, 2023 at 10:36:49PM -0500, Tom Rini wrote: > The function arch_early_init_r only does anything on these platforms if > we have FPGA (or SPL and SPL_FPGA) enabled, so move the logic to select > based on that. > > Cc: Michal Simek > Signed-off-by: Tom Rini > Reviewed-by: Michal Simek > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 04/13] arm: rk3368: Select ARCH_EARLY_INIT_R when used
On Wed, Feb 15, 2023 at 10:36:50PM -0500, Tom Rini wrote: > On the lion and evb-px5 platforms, we need this function, so select it. > > Cc: Andy Yan > Cc: Quentin Schulz > Cc: Klaus Goger > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass > Reviewed-by: Quentin Schulz Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
