RE: [EXT] Re: [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m series with CAAM enabled
Hi Fabio Thanks for the patch information. @Rasmus Villemoes I hope this fixed your problem? Regards Gaurav Jain > -Original Message- > From: Fabio Estevam > Sent: Monday, October 10, 2022 7:45 PM > To: Rasmus Villemoes ; Marcel Ziswiler > > Cc: ZHIZHIKIN Andrey ; Gaurav > Jain ; u-boot@lists.denx.de; feste...@denx.de; > sba...@denx.de; Michael Walle ; Tommaso Merciai > ; Michael Trimarchi > ; Marek Vasut ; Simon > Glass ; Patrick Delaunay > ; Stefan Roese ; Horia Geanta > ; Pankaj Gupta ; Varun > Sethi ; Ye Li ; dl-uboot-imx i...@nxp.com> > Subject: [EXT] Re: [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m > series with CAAM enabled > > Caution: EXT Email > > Hi Rasmus, > > On Mon, Oct 10, 2022 at 11:07 AM Rasmus Villemoes > wrote: > > > This is still broken in v2022.10. Are there any plans to fix this? > > If I recall correctly the fix for this issue is to sync imx8m dts files with > Linux so > that the following commit can be in place: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%2F > commit%2F%3Fh%3Dv6.0%26id%3Ddc9c1ceb555ff661e6fc1081434600771f29 > 657c&data=05%7C01%7Cgaurav.jain%40nxp.com%7Ce5f346e2f2024b08 > 83ab08daaac9e5c7%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6 > 38010081361514213%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7 > C&sdata=oEYSt8zYXlvu0mfmmop76Eshz0WKySE%2Buk6D3MKgpRM%3 > D&reserved=0 > > Marcel submitted some imx8m dtsi sync patches, which should address this > failure.
[PATCH] riscv: ae350: Check firmware_fdt_addr header
Check firmware_fdt_addr header to see if it is a valid
fdt blob.
Signed-off-by: Rick Chen
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 36f0dd4..f348066 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -60,7 +60,7 @@ void *board_fdt_blob_setup(int *err)
*err = 0;
if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
- if (gd->arch.firmware_fdt_addr)
+ if (fdt_magic(gd->arch.firmware_fdt_addr) == FDT_MAGIC)
return (void *)(ulong)gd->arch.firmware_fdt_addr;
}
--
2.7.4
Re: [PATCH v3] schemas: Add schema for U-Boot driver model 'phase tags'
Hi Rob,
On Mon, 10 Oct 2022 at 10:34, Rob Herring wrote:
>
> On Tue, Oct 4, 2022 at 6:22 PM Simon Glass wrote:
> >
> > Until recently it has not been possible to add any U-Boot-specific
> > properties to the device tree schema. Now that it is somewhat separated
> > from Linux and people are feeling the enormous pain of the bifurcated
> > schema, it seems like a good time to add this and other U-Boot-specific
> > bindings.
>
> It's been possible provided there was agreement on the properties.
> There just wasn't in this case.
>
> What's the pain point precisely? I can think of several. Syncing dts
> files from Linux tree, running schema validation on a dtb from u-boot,
> or ...?
U-Boot
See Tom's response.
As Tom says, I am not bothered about history and can change anything
in the commit message. Just so long as history never repeats!
>
> > U-Boot has some particular challenges with device tree and devices which
> > are not faced with Linux:
> >
> > - U-Boot has multiple build phases, such as a Secondary Program Loader
> > (SPL) phase which typically runs in a pre-SDRAM environment where code
> > and data space are limited. In particular, there may not be enough
> > space for the full device tree blob. U-Boot uses various automated
> > techniques to reduce the size from perhaps 40KB to 3KB.
>
> As this is a build time thing, would this be better handled as a
> source annotation rather than properties? We already have a 'delete if
> unreferenced' tag for similar reasons. We could add something more
> flexible like '/tag spl, tpl/' and dtc could have command line options
> to keep or delete nodes based on tag names. (Added David G for his
> thoughts on this)
If you like. I imagine that would work.
This would involve recompiling the DT from source multiple times,
which we don't currently do. Of all the DTs that are built for a
particular U-Boot board, the 'default' one is selected and used for
SPL. I cannot think of any problem it would cause, though.
>
> Yes, there is also a runtime need for a portion of this, but I think
> it's 2 different problems AIUI.
It's a little tricky. At present we can pass the full DT to xPL and it
can do the right thing, in principle. We use this sort of thing with
sandbox, which is the test/CI environment running natively on Linux.
If we split this up it would have impacts on that, but it would need
to be tried.
The removal of the tags in SPL (by fdtgrep) and the ignoring of them
in xPL builds is an optimisation to save space:
https://lxr.missinglinkelectronics.com/uboot+v2022.07/drivers/core/ofnode.c#L977
https://lxr.missinglinkelectronics.com/uboot+v2022.07/scripts/Makefile.lib#L584
We need to be careful not to make this impossible to test / debug.
>
> > - Some U-Boot phases needs to run before the clocks are properly set up,
> > where the CPU may be running very slowly. Therefore it is important to
> > bind only those devices which are actually needed in that phase
> > - Unlike Linux or UEFI, U-Boot uses lazy initialisation for its devices,
> > with 'bind' and 'probe' being separate steps. Even if a device is bound,
> > it is not actually probed until it is used. This is necessary to keep
> > the boot time reasonable, e.g. to under a second
>
> Linux could do this now if we wanted. There's a full dependency graph.
> Once you have that, it's just an implementation decision whether you
> probe top down or bottom up. We have this graph because Linux specific
> probing hint properties in DT was rejected. (Not saying u-boot needs
> to go implement a dependency graph, but rather u-boot is not unique
> here and there's more than one way to solve it.)
OK good.
As Tom notes, I can remove any references to other projects from the
commit message. They are not relevant to operation, but I wanted to
save a dozen back-and-forward emails by trying to cover the obvious
points up front, so I seem to have included things that are
irrelevant.
BTW, does Linux separate bind() from probe()? I had not seen that up to now.
I'm also interested in the rejected hint-properties patch, if you can
point to it.
>
> > The phases of U-Boot in order are: TPL, VPL, SPL, U-Boot (first
> > pre-relocation, then post-relocation). ALl but the last two are optional.
> >
> > For the above reasons, U-Boot only includes the full device tree in the
> > final 'U-Boot proper' build. Even then, before relocation U-Boot only
> > processes nodes which are marked as being needed.
> >
> > For this to work, U-Boot's driver model[1] provides a way to mark device
> > tree nodes as applicable for a particular phase. This works by adding a
> > tag to the node, e.g.:
> >
> >cru: clock-controller@ff76 {
> > u-boot,dm-all;
> > compatible = "rockchip,rk3399-cru";
> > reg = <0x0 0xff76 0x0 0x1000>;
> > rockchip,grf = <&grf>;
> > #clock-cells = <1>;
> > #reset-cells = <1>;
> > ...
> >};
> >
> > Here the "u-boot,dm-all" tag indicates that the no
Re: [PATCH v6 01/20] dm: core: Fix uclass_probe_all to really probe all devices
On Wed, 12 Oct 2022 at 13:58, Michal Suchanek wrote:
>
> uclass_probe_all uses uclass_first_device/uclass_next_device assigning
> the return value.
>
> The interface for getting meaningful error is
> uclass_first_device_check/uclass_next_device_check, use it.
>
> Also do not stop iteration when an error is encountered. Probing all
> devices includes those that happen to be after a failing device in the
> uclass order.
>
> Fixes: a59153dfeb ("dm: core: add function uclass_probe_all() to probe all
> devices")
> Signed-off-by: Michal Suchanek
> ---
> v6: add test
> ---
> drivers/core/uclass.c | 12 +---
> test/dm/test-fdt.c| 19 +++
> 2 files changed, 20 insertions(+), 11 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH v6 14/20] dm: pci: Update error handling in pci_sriov_init
On Wed, 12 Oct 2022 at 13:58, Michal Suchanek wrote: > > Check the returned value from pci_get_bus. After a later patch > uclass_first_device_err may return a device on error and then checking > that a device is returned will not suffice. > > Signed-off-by: Michal Suchanek > --- > v6: - split off as separate patch > --- > drivers/pci/pci-uclass.c | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v6 15/20] mpc83xx: gazerbeam: Update sysinfo_get error handling
On Wed, 12 Oct 2022 at 14:01, Michal Suchanek wrote: > > In a later patch sysinfo_get will be changed to return the device in cae > of an error. Set sysinfo to NULL on error to preserve previous behavior. > > Signed-off-by: Michal Suchanek > --- > board/gdsys/mpc8308/gazerbeam.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v6 16/20] dm: core: Switch uclass_foreach_dev_probe to use simple iterator
On Wed, 12 Oct 2022 at 13:58, Michal Suchanek wrote: > > The return value is not used for anythig, and in a later patch the > behavior of the _err iterator will change in an incompatible way. > > Signed-off-by: Michal Suchanek > --- > v6: - split off as separate patch > --- > include/dm/uclass.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v6 18/20] dm: core: Non-activated device may be returned from uclass iterators that provide error handling
On Wed, 12 Oct 2022 at 13:58, Michal Suchanek wrote: > > Note in documentation that a non-activated device can be returned on > error. > > Signed-off-by: Michal Suchanek > --- > v6: - split off as separate patch > --- > include/dm/uclass.h | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH 2/2] spl: spl_legacy: Fix printing image name
On Wed, 12 Oct 2022 at 13:47, Michal Suchanek wrote: > > image_set_name does not terminate the name in the image header. > > Then is should not be assument it's nul terminated. image_print_contents > correctly print only IH_NMLEN characters. > > Fix printing the unterminated field in spl_parse_legacy_header. The > format specifies the minimum printed length, not maximum. > > Signed-off-by: Michal Suchanek > --- > > common/spl/spl_legacy.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: Bad Data CRC
Hi, On Wed, 12 Oct 2022 at 07:50, momo aubin wrote: > > Thanks Fabio and Simon, > > find attached the log picture. > When I changed the size of the one partition in the kernel, I got this > message. Does the calculation of CRC in uboot depended on the size ? It seems like your kernel is corrupt and the crc is failing. Yes the crc is calculated based on the full size of the kernel data as shown. - Simon > > > > Thanks, > Aubin > > On Wed, 12 Oct 2022 at 15:05, Fabio Estevam wrote: >> >> On Mon, Oct 10, 2022 at 6:31 PM momo aubin wrote: >> > >> > Hello Simon, >> > >> > My board boots well . When I added the second partition into my kernel I >> > got this message >> > *Verifying Checksum ... Bad Data CRC* >> > what could be the root cause ? >> >> Try to run "saveenv",
Re: [PATCH 5/6] sunxi: f1c100: dtsi: add UART1 pins
Hi Andre,
Dne sreda, 12. oktober 2022 ob 18:34:57 CEST je Andre Przywara napisal(a):
> The F1Cx00 SoCs connect the first PortA pins to UART1.
>
> Add this to the SoC .dtsi, so boards can reference UART1 pins.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> ---
> arch/arm/dts/suniv-f1c100s.dtsi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/dts/suniv-f1c100s.dtsi
> b/arch/arm/dts/suniv-f1c100s.dtsi index 0edc1724407..bc563c12e95 100644
> --- a/arch/arm/dts/suniv-f1c100s.dtsi
> +++ b/arch/arm/dts/suniv-f1c100s.dtsi
> @@ -175,6 +175,11 @@
> pins = "PE0", "PE1";
> function = "uart0";
> };
> +
> + uart1_pa_pins: uart1-pa-pins {
> + pins = "PA2", "PA3";
> + function = "uart1";
> + };
> };
>
> timer@1c20c00 {
> --
> 2.25.1
Re: [PATCH 4/6] sunxi: f1c100: add UART1 support
Hi Andre,
Dne sreda, 12. oktober 2022 ob 18:34:56 CEST je Andre Przywara napisal(a):
> Some boards use UART1 for its debug UART, so define the pins for the SPL
> and the pinmux name and mux value for U-Boot proper.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/mach-sunxi/board.c | 4
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 62bb40b8c89..77216157908 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -147,6 +147,10 @@ static int gpio_init(void)
> sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
> sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
> sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
> +#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV)
> + sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0);
> + sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0);
> + sunxi_gpio_set_pull(SUNXI_GPA(3), SUNXI_GPIO_PULL_UP);
> #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
> sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1);
> sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1);
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c index 9ce2bc1b3af..061104be056
> 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -245,6 +245,7 @@ static const struct sunxi_pinctrl_function
> suniv_f1c100s_pinctrl_functions[] = { #else
> { "uart0", 5 },/* PE0-PE1 */
> #endif
> + { "uart1", 5 },/* PA0-PA3 */
Comment should be PA2-PA3. With that fixed:
Reviewed-by: Jernej Skrabec
Best regards,
Jernej
> };
>
> static const struct sunxi_pinctrl_desc __maybe_unused
> suniv_f1c100s_pinctrl_desc = { --
> 2.25.1
Re: [PATCH 3/6] sunxi: f1c100: move SKIP_LOWLEVEL_INIT_ONLY into Kconfig
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:34:55 CEST je Andre Przywara napisal(a): > So far we stated the lack of a lowlevel() init function for the F1C100s > board by defining the respective SKIP_* symbol in the board's > defconfig. However we don't expect any *board* to employ such low level > code, so expect this to be never used for the ARMv5 Allwinner SoCs. > > Select the appropriate symbols in the Kconfig, so that we can remove > them from the defconfig, and avoid putting them in future defconfigs for > other boards. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > arch/arm/mach-sunxi/Kconfig | 2 ++ > configs/licheepi_nano_defconfig | 2 -- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 9aa66deb9fd..fc5d8bb3c19 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -185,6 +185,8 @@ config MACH_SUNIV > select CPU_ARM926EJS > select SUNXI_GEN_SUN6I > select SUPPORT_SPL > + select SKIP_LOWLEVEL_INIT_ONLY > + select SPL_SKIP_LOWLEVEL_INIT_ONLY > > config MACH_SUN4I > bool "sun4i (Allwinner A10)" > diff --git a/configs/licheepi_nano_defconfig > b/configs/licheepi_nano_defconfig index 14e6bcda927..09f1a19cdbe 100644 > --- a/configs/licheepi_nano_defconfig > +++ b/configs/licheepi_nano_defconfig > @@ -1,6 +1,4 @@ > CONFIG_ARM=y > -CONFIG_SKIP_LOWLEVEL_INIT_ONLY=y > -CONFIG_SPL_SKIP_LOWLEVEL_INIT_ONLY=y > CONFIG_SYS_DCACHE_OFF=y > CONFIG_ARCH_SUNXI=y > CONFIG_DEFAULT_DEVICE_TREE="suniv-f1c100s-licheepi-nano" > -- > 2.25.1
Re: [PATCH 2/6] sunxi: fix 32MB load address layout
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:34:54 CEST je Andre Przywara napisal(a): > The default load addresses for the various payloads (kernel, DT, > ramdisk) on systems with just 32MB of DRAM have some issues: > For a start the preceding comment doesn't match the actual values: > apparently they were copied from the 64MB S3 layout, then halved, but > since 0x5 is NOT the half of 0x10, they don't match up. > Also those projected maximum sizes are quite restrictive: it's not easy > to build a compressed kernel image with just 4MB. The only defconfig in > mainline Linux that supports the F1C100s (the only 32MB user so far) > creates a 6MB compressed / 15MB uncompressed kernel. > Rearrange the default load addresses to accommodate such a kernel: we > allow an 7MB/16MB kernel, and up to 5MB of ramdisk, stuffing the smaller > binaries like the DTB towards the end, just before the relocated U-Boot. > Shrink the size for DTB and scripts on the way, there is no need for > allowing up to 512K for them. > > Signed-off-by: Andre Przywara > --- > include/configs/sunxi-common.h | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 416a0422861..fe90d55bd45 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -165,17 +165,17 @@ > > #elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 32) > /* > - * 32M RAM minus 1MB heap + 8MB for u-boot, stack, fb, etc. > - * 8M uncompressed kernel, 4M compressed kernel, 512K fdt, > - * 512K script, 512K pxe and the ramdisk at the end. > + * 32M RAM minus 2.5MB for u-boot, heap, stack, etc. > + * 16M uncompressed kernel, 7M compressed kernel, 128K fdt, 64K script, > + * 128K DT overlay, 128K PXE and the ramdisk in the rest (max. 5MB) DT overlays and PXE could be even much smaller, but I guess it doesn't make much of a difference. Reviewed-by: Jernej Skrabec Best regards, Jernej > */ > #define BOOTM_SIZE__stringify(0x170) > -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(050)) > -#define FDT_ADDR_R__stringify(SDRAM_OFFSET(0C0)) > -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(0C5)) > -#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(0D0)) > -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(0D5)) > -#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(0D6)) > +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(100)) > +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(1d5)) > +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(1d4)) > +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(1d0)) > +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1d2)) > +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(180)) > > #else > #error Need at least 32MB of DRAM. Please adjust load addresses. > -- > 2.25.1
Re: [PATCH 1/6] sunxi: Kconfig: introduce SUNXI_MINIMUM_DRAM_MB
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:34:53 CEST je Andre Przywara napisal(a): > Traditionally we assumed that every Allwinner board would come with at > least 256 MB of DRAM, and set our DRAM layout accordingly. This affected > both the default load addresses, but also U-Boot's own address > expectations (like being loaded at 160 MB). > > Some SoCs come with co-packaged DRAM, but only provide 32 or 64MB. So > far we special-cased those *chips*, as there was only one chip per DRAM > size. However new chips force us to take a more general approach. > > Introduce a Kconfig symbol, which provides the minimum DRAM size of the > board. If nothing else is specified, we use 256 MB, and default to > smaller values for those co-packaged SoCs. > Then select the different DRAM maps according to this new symbol, so > that different SoCs with the same DRAM size can share those definitions. > > Inspired by an idea from Icenowy. > > This is just refactoring: compiled for all boards before and after this > patch: the binaries were identical. > > Signed-off-by: Andre Przywara Nice approach. Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > Kconfig| 6 +++--- > arch/arm/mach-sunxi/Kconfig| 12 > boot/Kconfig | 4 ++-- > include/configs/sunxi-common.h | 31 +-- > 4 files changed, 34 insertions(+), 19 deletions(-) > > diff --git a/Kconfig b/Kconfig > index 2ea735d38e4..d297513bac6 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -312,9 +312,9 @@ config SYS_MALLOC_LEN > default 0x400 if SANDBOX > default 0x200 if ARCH_ROCKCHIP || ARCH_OMAP2PLUS || ARCH_MESON > default 0x20 if ARCH_BMIPS || X86 > - default 0x12 if MACH_SUNIV > - default 0x22 if MACH_SUN8I_V3S > - default 0x402 if ARCH_SUNXI > + default 0x402 if SUNXI_MINIMUM_DRAM_MB >= 256 > + default 0x22 if SUNXI_MINIMUM_DRAM_MB >= 64 > + default 0x12 if SUNXI_MINIMUM_DRAM_MB >= 32 > default 0x40 > help > This defines memory to be allocated for Dynamic allocation > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 6b16f43494f..9aa66deb9fd 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -615,6 +615,18 @@ config SYS_BOARD > config SYS_SOC > default "sunxi" > > +config SUNXI_MINIMUM_DRAM_MB > + int "minimum DRAM size" > + default 32 if MACH_SUNIV > + default 64 if MACH_SUN8I_V3S > + default 256 > + ---help--- > + Minimum DRAM size expected on the board. Traditionally we assumed > + 256 MB, so that U-Boot would load at 160MB. With co-packaged DRAM > + we have smaller sizes, though, so that U-Boot's own load address and > + the default payload addresses must be shifted down. > + This is expected to be fixed by the SoC selection. > + > config UART0_PORT_F > bool "UART0 on MicroSD breakout board" > ---help--- > diff --git a/boot/Kconfig b/boot/Kconfig > index 6b3b8f072cb..45f86e946cd 100644 > --- a/boot/Kconfig > +++ b/boot/Kconfig > @@ -499,8 +499,8 @@ config SYS_TEXT_BASE > default 0x8080 if ARCH_OMAP2PLUS || ARCH_K3 > default 0x8170 if MACH_SUNIV > default 0x2a00 if MACH_SUN9I > - default 0x42e0 if MACH_SUN8I_V3S > - default 0x4a00 if ARCH_SUNXI > + default 0x4a00 if SUNXI_MINIMUM_DRAM_MB >= 256 > + default 0x42e0 if SUNXI_MINIMUM_DRAM_MB >= 64 > hex "Text Base" > help > The address in memory that U-Boot will be running from, initially. > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h > index 0f0ef4f64bb..416a0422861 100644 > --- a/include/configs/sunxi-common.h > +++ b/include/configs/sunxi-common.h > @@ -135,7 +135,21 @@ > #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(FE0)) > #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(FF0)) > > -#elif defined(CONFIG_MACH_SUN8I_V3S) > +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 256) > +/* > + * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, > etc. + * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, > + * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. > + */ > +#define BOOTM_SIZE__stringify(0xa00) > +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200)) > +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300)) > +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310)) > +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320)) > +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330)) > +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340)) > + > +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 64) > /* > * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc. > * 16M uncompressed kernel, 8M compressed kernel, 1M fdt, > @@ -149,7 +163,7 @@ > #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1
Re: [PATCH] sunxi: defconfig: Add X96 Mate TV box
Hi Andre, Dne sreda, 12. oktober 2022 ob 18:26:10 CEST je Andre Przywara napisal(a): > The X96 Mate TV box is a TV box with the Allwinner H616 SoC. It is > available with up to 4GB of DRAM and 64GB eMMC. > The DRAM chips require a different configuration when compared to the > OrangePi Zero2, we must not use read/write training and write leveling. > > Add a defconfig for the box, so that we can easily build U-Boot for it. > We synced the .dts file already from the kernel tree. > > Signed-off-by: Andre Przywara Reviewed-by: Jernej Skrabec Best regards, Jernej > --- > configs/x96_mate_defconfig | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 configs/x96_mate_defconfig > > diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig > new file mode 100644 > index 000..4276f4f543b > --- /dev/null > +++ b/configs/x96_mate_defconfig > @@ -0,0 +1,15 @@ > +CONFIG_ARM=y > +CONFIG_ARCH_SUNXI=y > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h616-x96-mate" > +CONFIG_SPL=y > +CONFIG_DRAM_SUN50I_H616_READ_CALIBRATION=y > +CONFIG_MACH_SUN50I_H616=y > +CONFIG_MMC0_CD_PIN="PF6" > +CONFIG_R_I2C_ENABLE=y > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set > +CONFIG_SPL_I2C=y > +CONFIG_SPL_SYS_I2C_LEGACY=y > +CONFIG_SYS_I2C_MVTWSI=y > +CONFIG_SYS_I2C_SLAVE=0x7f > +CONFIG_SYS_I2C_SPEED=40 > +CONFIG_SUPPORT_EMMC_BOOT=y > -- > 2.25.1
[PATCH v6 17/20] dm: core: Switch uclass_*_device_err to use uclass_*_device_check
The _err variant iterators use the simple iterators without suffix as
basis.
However, there is no user that uclass_next_device_err for iteration,
many users of uclass_first_device_err use it to get the first and
(assumed) only device of an uclass, and a couple that use
uclass_next_device_err to get the device following a known device in the
uclass list.
While there are some truly singleton device classes in which more than
one device cannot exist these are quite rare, and most classes can have
multiple devices even if it is not the case on the SoC's EVB.
In a later patch the simple iterators will be updated to not stop on
error and return next device instead. With this in many cases the code
that expects the first device or an error if it fails to probe may get
the next device instead. Use the _check iterators as the basis of _err
iterators to preserve the old behavior.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v5: - udate documentation
- fix up a few more cases where device returned on error may cause
problem
v6: - split the additional changes into separate patches
---
drivers/core/uclass.c | 28 ++--
include/dm/uclass.h | 22 +++---
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index a591e22403..b7d11bdd23 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -586,19 +586,6 @@ int uclass_first_device(enum uclass_id id, struct udevice
**devp)
return uclass_get_device_tail(dev, ret, devp);
}
-int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
-{
- int ret;
-
- ret = uclass_first_device(id, devp);
- if (ret)
- return ret;
- else if (!*devp)
- return -ENODEV;
-
- return 0;
-}
-
int uclass_next_device(struct udevice **devp)
{
struct udevice *dev = *devp;
@@ -611,11 +598,24 @@ int uclass_next_device(struct udevice **devp)
return uclass_get_device_tail(dev, ret, devp);
}
+int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
+{
+ int ret;
+
+ ret = uclass_first_device_check(id, devp);
+ if (ret)
+ return ret;
+ else if (!*devp)
+ return -ENODEV;
+
+ return 0;
+}
+
int uclass_next_device_err(struct udevice **devp)
{
int ret;
- ret = uclass_next_device(devp);
+ ret = uclass_next_device_check(devp);
if (ret)
return ret;
else if (!*devp)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 990e9c02d1..823a16527f 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -332,17 +332,6 @@ int uclass_get_device_by_driver(enum uclass_id id, const
struct driver *drv,
*/
int uclass_first_device(enum uclass_id id, struct udevice **devp);
-/**
- * uclass_first_device_err() - Get the first device in a uclass
- *
- * The device returned is probed if necessary, and ready for use
- *
- * @id: Uclass ID to look up
- * @devp: Returns pointer to the first device in that uclass, or NULL if none
- * Return: 0 if found, -ENODEV if not found, other -ve on error
- */
-int uclass_first_device_err(enum uclass_id id, struct udevice **devp);
-
/**
* uclass_next_device() - Get the next device in a uclass
*
@@ -358,6 +347,17 @@ int uclass_first_device_err(enum uclass_id id, struct
udevice **devp);
*/
int uclass_next_device(struct udevice **devp);
+/**
+ * uclass_first_device_err() - Get the first device in a uclass
+ *
+ * The device returned is probed if necessary, and ready for use
+ *
+ * @id: Uclass ID to look up
+ * @devp: Returns pointer to the first device in that uclass, or NULL if none
+ * Return: 0 if found, -ENODEV if not found, other -ve on error
+ */
+int uclass_first_device_err(enum uclass_id id, struct udevice **devp);
+
/**
* uclass_next_device_err() - Get the next device in a uclass
*
--
2.37.3
[PATCH v6 19/20] dm: treewide: Do not use the return value of simple uclass iterator
uclass_first_device/uclass_next_device return value will be removed,
don't use it.
With the current implementation dev is equivalent to !ret. It is
redundant to check both, ret check can be replaced with dev check, and
ret check inside the iteration is dead code.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v5: - consolidate multiple similar patches
---
cmd/virtio.c | 9 +++--
drivers/dma/dma-uclass.c | 7 +++
drivers/gpio/gpio-uclass.c | 14 ++
drivers/pci/pci-uclass.c | 15 +++
drivers/w1/w1-uclass.c | 9 ++---
5 files changed, 17 insertions(+), 37 deletions(-)
diff --git a/cmd/virtio.c b/cmd/virtio.c
index ec87d4f02c..019e317e75 100644
--- a/cmd/virtio.c
+++ b/cmd/virtio.c
@@ -23,18 +23,15 @@ static int do_virtio(struct cmd_tbl *cmdtp, int flag, int
argc,
* device_probe() for children (i.e. virtio devices)
*/
struct udevice *bus, *child;
- int ret;
- ret = uclass_first_device(UCLASS_VIRTIO, &bus);
- if (ret)
+ uclass_first_device(UCLASS_VIRTIO, &bus);
+ if (!bus)
return CMD_RET_FAILURE;
while (bus) {
device_foreach_child_probe(child, bus)
;
- ret = uclass_next_device(&bus);
- if (ret)
- break;
+ uclass_next_device(&bus);
}
return CMD_RET_SUCCESS;
diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
index 012609bb53..952cbc2170 100644
--- a/drivers/dma/dma-uclass.c
+++ b/drivers/dma/dma-uclass.c
@@ -209,10 +209,9 @@ int dma_get_cfg(struct dma *dma, u32 cfg_id, void
**cfg_data)
int dma_get_device(u32 transfer_type, struct udevice **devp)
{
struct udevice *dev;
- int ret;
- for (ret = uclass_first_device(UCLASS_DMA, &dev); dev && !ret;
-ret = uclass_next_device(&dev)) {
+ for (uclass_first_device(UCLASS_DMA, &dev); dev;
+uclass_next_device(&dev)) {
struct dma_dev_priv *uc_priv;
uc_priv = dev_get_uclass_priv(dev);
@@ -228,7 +227,7 @@ int dma_get_device(u32 transfer_type, struct udevice **devp)
*devp = dev;
- return ret;
+ return 0;
}
int dma_memcpy(void *dst, void *src, size_t len)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index a00880e446..3429ccaaca 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -59,11 +59,10 @@ static int gpio_to_device(unsigned int gpio, struct
gpio_desc *desc)
{
struct gpio_dev_priv *uc_priv;
struct udevice *dev;
- int ret;
- for (ret = uclass_first_device(UCLASS_GPIO, &dev);
+ for (uclass_first_device(UCLASS_GPIO, &dev);
dev;
-ret = uclass_next_device(&dev)) {
+uclass_next_device(&dev)) {
uc_priv = dev_get_uclass_priv(dev);
if (gpio >= uc_priv->gpio_base &&
gpio < uc_priv->gpio_base + uc_priv->gpio_count) {
@@ -73,7 +72,7 @@ static int gpio_to_device(unsigned int gpio, struct gpio_desc
*desc)
}
/* No such GPIO */
- return ret ? ret : -ENOENT;
+ return -ENOENT;
}
#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
@@ -121,12 +120,11 @@ int dm_gpio_lookup_name(const char *name, struct
gpio_desc *desc)
struct udevice *dev;
ulong offset;
int numeric;
- int ret;
numeric = isdigit(*name) ? dectoul(name, NULL) : -1;
- for (ret = uclass_first_device(UCLASS_GPIO, &dev);
+ for (uclass_first_device(UCLASS_GPIO, &dev);
dev;
-ret = uclass_next_device(&dev)) {
+uclass_next_device(&dev)) {
int len;
uc_priv = dev_get_uclass_priv(dev);
@@ -154,7 +152,7 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc
*desc)
}
if (!dev)
- return ret ? ret : -EINVAL;
+ return -EINVAL;
gpio_desc_init(desc, dev, offset);
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 6dd19650f9..9343cfc62a 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1211,7 +1211,6 @@ static int pci_bridge_write_config(struct udevice *bus,
pci_dev_t bdf,
static int skip_to_next_device(struct udevice *bus, struct udevice **devp)
{
struct udevice *dev;
- int ret = 0;
/*
* Scan through all the PCI controllers. On x86 there will only be one
@@ -1223,9 +1222,7 @@ static int skip_to_next_device(struct udevice *bus,
struct udevice **devp)
*devp = dev;
return 0;
}
- ret = uclass_next_device(&bus);
- if (ret)
- retu
[PATCH v6 20/20] dm: core: Do not stop uclass iteration on error
When probing a device fails NULL pointer is returned, and following
devices in uclass list cannot be iterated. Skip to next device on error
instead.
With that the only condition under which these simple iteration
functions return error is when the dm is not initialized at uclass_get
time. This is not all that interesting, change return type to void.
Fixes: 6494d708bf ("dm: Add base driver model support")
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v2: - Fix up tests
v3: - Fix up API doc
- Correctly forward error from uclass_get
- Do not return an error when last device fails to probe
- Drop redundant initialization
- Wrap at 80 columns
v4: - change return value to void
- further simplify iteration
---
drivers/core/uclass.c | 30 ++
include/dm/uclass.h | 13 ++---
test/dm/core.c| 10 --
test/dm/test-fdt.c| 27 ---
4 files changed, 48 insertions(+), 32 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index b7d11bdd23..1762a0796d 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -574,28 +574,34 @@ int uclass_get_device_by_phandle(enum uclass_id id,
struct udevice *parent,
}
#endif
-int uclass_first_device(enum uclass_id id, struct udevice **devp)
+/*
+ * Starting from the given device @dev, return pointer to the first device in
+ * the uclass that probes successfully in @devp.
+ */
+static void _uclass_next_device(struct udevice *dev, struct udevice **devp)
+{
+ for (; dev; uclass_find_next_device(&dev)) {
+ if (!device_probe(dev))
+ break;
+ }
+ *devp = dev;
+}
+
+void uclass_first_device(enum uclass_id id, struct udevice **devp)
{
struct udevice *dev;
int ret;
- *devp = NULL;
ret = uclass_find_first_device(id, &dev);
- if (!dev)
- return 0;
- return uclass_get_device_tail(dev, ret, devp);
+ _uclass_next_device(dev, devp);
}
-int uclass_next_device(struct udevice **devp)
+void uclass_next_device(struct udevice **devp)
{
struct udevice *dev = *devp;
- int ret;
- *devp = NULL;
- ret = uclass_find_next_device(&dev);
- if (!dev)
- return 0;
- return uclass_get_device_tail(dev, ret, devp);
+ uclass_find_next_device(&dev);
+ _uclass_next_device(dev, devp);
}
int uclass_first_device_err(enum uclass_id id, struct udevice **devp)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index b1c016ef9f..ee15c92063 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -320,32 +320,31 @@ int uclass_get_device_by_driver(enum uclass_id id, const
struct driver *drv,
* uclass_first_device() - Get the first device in a uclass
*
* The device returned is probed if necessary, and ready for use
+ * Devices that fail to probe are skipped
*
* This function is useful to start iterating through a list of devices which
* are functioning correctly and can be probed.
*
* @id: Uclass ID to look up
* @devp: Returns pointer to the first device in that uclass if no error
- * occurred, or NULL if there is no first device, or an error occurred with
- * that device.
- * Return: 0 if OK (found or not found), other -ve on error
+ * occurred, or NULL if there is no usable device
*/
-int uclass_first_device(enum uclass_id id, struct udevice **devp);
+void uclass_first_device(enum uclass_id id, struct udevice **devp);
/**
* uclass_next_device() - Get the next device in a uclass
*
* The device returned is probed if necessary, and ready for use
+ * Devices that fail to probe are skipped
*
* This function is useful to iterate through a list of devices which
* are functioning correctly and can be probed.
*
* @devp: On entry, pointer to device to lookup. On exit, returns pointer
* to the next device in the uclass if no error occurred, or NULL if there is
- * no next device, or an error occurred with that next device.
- * Return: 0 if OK (found or not found), other -ve on error
+ * no next device
*/
-int uclass_next_device(struct udevice **devp);
+void uclass_next_device(struct udevice **devp);
/**
* uclass_first_device_err() - Get the first device in a uclass
diff --git a/test/dm/core.c b/test/dm/core.c
index 84eb76ed5f..7f3f8d183b 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -1078,11 +1078,10 @@ static int dm_test_uclass_devices_get(struct
unit_test_state *uts)
struct udevice *dev;
int ret;
- for (ret = uclass_first_device(UCLASS_TEST, &dev);
+ for (ret = uclass_first_device_check(UCLASS_TEST, &dev);
dev;
-ret = uclass_next_device(&dev)) {
+ret = uclass_next_device_check(&dev)) {
ut_assert(!ret);
- ut_assert(dev);
ut_assert(device_active(dev));
}
@@ -1112,11 +,10 @@ static int dm_test_uclass_devices_get_by_nam
[PATCH v6 18/20] dm: core: Non-activated device may be returned from uclass iterators that provide error handling
Note in documentation that a non-activated device can be returned on error. Signed-off-by: Michal Suchanek --- v6: - split off as separate patch --- include/dm/uclass.h | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/include/dm/uclass.h b/include/dm/uclass.h index 823a16527f..b1c016ef9f 100644 --- a/include/dm/uclass.h +++ b/include/dm/uclass.h @@ -350,7 +350,8 @@ int uclass_next_device(struct udevice **devp); /** * uclass_first_device_err() - Get the first device in a uclass * - * The device returned is probed if necessary, and ready for use + * The device returned is probed if necessary, and ready for use if no error is + * returned * * @id: Uclass ID to look up * @devp: Returns pointer to the first device in that uclass, or NULL if none @@ -361,7 +362,8 @@ int uclass_first_device_err(enum uclass_id id, struct udevice **devp); /** * uclass_next_device_err() - Get the next device in a uclass * - * The device returned is probed if necessary, and ready for use + * The device returned is probed if necessary, and ready for use if no error is + * returned * * @devp: On entry, pointer to device to lookup. On exit, returns pointer * to the next device in the uclass if no error occurred, or NULL if @@ -373,7 +375,8 @@ int uclass_next_device_err(struct udevice **devp); /** * uclass_first_device_check() - Get the first device in a uclass * - * The device returned is probed if necessary, and ready for use + * The device returned is probed if necessary, and ready for use if no error is + * returned * * This function is useful to start iterating through a list of devices which * are functioning correctly and can be probed. @@ -389,7 +392,8 @@ int uclass_first_device_check(enum uclass_id id, struct udevice **devp); /** * uclass_next_device_check() - Get the next device in a uclass * - * The device returned is probed if necessary, and ready for use + * The device returned is probed if necessary, and ready for use if no error is + * returned * * This function is useful to start iterating through a list of devices which * are functioning correctly and can be probed. -- 2.37.3
[PATCH v6 15/20] mpc83xx: gazerbeam: Update sysinfo_get error handling
In a later patch sysinfo_get will be changed to return the device in cae
of an error. Set sysinfo to NULL on error to preserve previous behavior.
Signed-off-by: Michal Suchanek
---
board/gdsys/mpc8308/gazerbeam.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/board/gdsys/mpc8308/gazerbeam.c b/board/gdsys/mpc8308/gazerbeam.c
index 3d4a7e57fe..ba88401f13 100644
--- a/board/gdsys/mpc8308/gazerbeam.c
+++ b/board/gdsys/mpc8308/gazerbeam.c
@@ -49,8 +49,10 @@ int board_early_init_r(void)
int mc = 0;
int con = 0;
- if (sysinfo_get(&sysinfo))
+ if (sysinfo_get(&sysinfo)) {
puts("Could not find sysinfo information device.\n");
+ sysinfo = NULL;
+ }
/* Initialize serdes */
uclass_get_device_by_phandle(UCLASS_MISC, sysinfo, "serdes", &serdes);
@@ -92,8 +94,10 @@ int checksysinfo(void)
int mc = 0;
int con = 0;
- if (sysinfo_get(&sysinfo))
+ if (sysinfo_get(&sysinfo)) {
puts("Could not find sysinfo information device.\n");
+ sysinfo = NULL;
+ }
sysinfo_get_int(sysinfo, BOARD_MULTICHANNEL, &mc);
sysinfo_get_int(sysinfo, BOARD_VARIANT, &con);
@@ -130,8 +134,10 @@ int last_stage_init(void)
struct udevice *tpm;
int ret;
- if (sysinfo_get(&sysinfo))
+ if (sysinfo_get(&sysinfo)) {
puts("Could not find sysinfo information device.\n");
+ sysinfo = NULL;
+ }
if (sysinfo) {
int res = sysinfo_get_int(sysinfo, BOARD_HWVERSION,
--
2.37.3
[PATCH v6 13/20] net: eth-uclass: Do not set device on error
eth_get_dev relies on the broken behavior that returns an error but not the device on which the error happened which gives the caller no reasonable way to report or handle the error. In a later patch uclass_first_device_err will be changed to return the device on error but eth_get_dev stores the returned device pointer directly in a global state without checking the return value. Unset the pointer again in the error case. Signed-off-by: Michal Suchanek Reviewed-by: Simon Glass --- v6: split off as separate patch --- net/eth-uclass.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/eth-uclass.c b/net/eth-uclass.c index 8c3f9cc31b..f41da4b37b 100644 --- a/net/eth-uclass.c +++ b/net/eth-uclass.c @@ -93,6 +93,8 @@ struct udevice *eth_get_dev(void) if (eth_errno) eth_errno = uclass_first_device_err(UCLASS_ETH, &uc_priv->current); + if (eth_errno) + uc_priv->current = NULL; } return uc_priv->current; } -- 2.37.3
[PATCH v6 14/20] dm: pci: Update error handling in pci_sriov_init
Check the returned value from pci_get_bus. After a later patch uclass_first_device_err may return a device on error and then checking that a device is returned will not suffice. Signed-off-by: Michal Suchanek --- v6: - split off as separate patch --- drivers/pci/pci-uclass.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c index 5cff81ac44..6dd19650f9 100644 --- a/drivers/pci/pci-uclass.c +++ b/drivers/pci/pci-uclass.c @@ -1777,10 +1777,9 @@ int pci_sriov_init(struct udevice *pdev, int vf_en) bdf = dm_pci_get_bdf(pdev); - pci_get_bus(PCI_BUS(bdf), &bus); - - if (!bus) - return -ENODEV; + ret = pci_get_bus(PCI_BUS(bdf), &bus); + if (ret) + return ret; bdf += PCI_BDF(0, 0, vf_offset); -- 2.37.3
[PATCH v6 16/20] dm: core: Switch uclass_foreach_dev_probe to use simple iterator
The return value is not used for anythig, and in a later patch the behavior of the _err iterator will change in an incompatible way. Signed-off-by: Michal Suchanek --- v6: - split off as separate patch --- include/dm/uclass.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/dm/uclass.h b/include/dm/uclass.h index f6c0110b06..990e9c02d1 100644 --- a/include/dm/uclass.h +++ b/include/dm/uclass.h @@ -491,7 +491,7 @@ int uclass_id_count(enum uclass_id id); * are no more devices. */ #define uclass_foreach_dev_probe(id, dev) \ - for (int _ret = uclass_first_device_err(id, &dev); !_ret && dev; \ -_ret = uclass_next_device_err(&dev)) + for (uclass_first_device(id, &dev); dev; \ +uclass_next_device(&dev)) #endif -- 2.37.3
[PATCH v6 12/20] dm: blk: Do not use uclass_next_device_err
blk_first_device_err/blk_next_device_err uses
uclass_first_device_err/uclass_next_device_err for device iteration.
Although the function names superficially match the return value from
uclass_first_device_err/uclass_next_device_err is never used
meaningfully, and uclass_first_device/uclass_next_device works equally
well for this purpose.
In the following patch the semantic of
uclass_first_device_err/uclass_next_device_err will be changed to be
based on uclass_first_device_check/uclass_next_device_check breaking
this sole user that uses uclass_next_device_err for iteration.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
drivers/block/blk-uclass.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 7d12d5413f..bcc14a684b 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -593,11 +593,9 @@ int blk_find_next(enum blk_flag_t flags, struct udevice
**devp)
int blk_first_device_err(enum blk_flag_t flags, struct udevice **devp)
{
- int ret;
-
- for (ret = uclass_first_device_err(UCLASS_BLK, devp);
-!ret;
-ret = uclass_next_device_err(devp)) {
+ for (uclass_first_device(UCLASS_BLK, devp);
+*devp;
+uclass_next_device(devp)) {
if (!blk_flags_check(*devp, flags))
return 0;
}
@@ -607,11 +605,9 @@ int blk_first_device_err(enum blk_flag_t flags, struct
udevice **devp)
int blk_next_device_err(enum blk_flag_t flags, struct udevice **devp)
{
- int ret;
-
- for (ret = uclass_next_device_err(devp);
-!ret;
-ret = uclass_next_device_err(devp)) {
+ for (uclass_next_device(devp);
+*devp;
+uclass_next_device(devp)) {
if (!blk_flags_check(*devp, flags))
return 0;
}
--
2.37.3
[PATCH v6 11/20] dm: treewide: Use uclass_next_device_err when accessing second device
There are a couple users of uclass_next_device return value that get the
first device by other means and use uclass_next_device assuming the
following device in the uclass is related to the first one.
Use uclass_next_device_err because the return value from
uclass_next_device will be removed in a later patch.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
arch/arm/mach-k3/j721s2_init.c | 2 +-
board/atmel/common/mac_eeprom.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/j721s2_init.c b/arch/arm/mach-k3/j721s2_init.c
index 12da8136f9..dd0c7ba18f 100644
--- a/arch/arm/mach-k3/j721s2_init.c
+++ b/arch/arm/mach-k3/j721s2_init.c
@@ -164,7 +164,7 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM 0 init failed: %d\n", ret);
- ret = uclass_next_device(&dev);
+ ret = uclass_next_device_err(&dev);
if (ret)
panic("DRAM 1 init failed: %d\n", ret);
}
diff --git a/board/atmel/common/mac_eeprom.c b/board/atmel/common/mac_eeprom.c
index a723ba723c..4606008c69 100644
--- a/board/atmel/common/mac_eeprom.c
+++ b/board/atmel/common/mac_eeprom.c
@@ -56,7 +56,7 @@ int at91_set_eth1addr(int offset)
return ret;
/* attempt to obtain a second eeprom device */
- ret = uclass_next_device(&dev);
+ ret = uclass_next_device_err(&dev);
if (ret)
return ret;
--
2.37.3
[PATCH v6 10/20] dm: treewide: Use uclass_first_device_err when accessing one device
There is a number of users that use uclass_first_device to access the
first and (assumed) only device in uclass.
Some check the return value of uclass_first_device and also that a
device was returned which is exactly what uclass_first_device_err does.
Some are not checking that a device was returned and can potentially
crash if no device exists in the uclass. Finally there is one that
returns NULL on error either way.
Convert all of these to use uclass_first_device_err instead, the return
value will be removed from uclass_first_device in a later patch.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v6: drop errno_str
---
arch/arm/mach-omap2/am33xx/board.c| 4 ++--
arch/x86/cpu/broadwell/cpu.c | 4 +---
arch/x86/cpu/intel_common/cpu.c | 4 +---
arch/x86/lib/pinctrl_ich6.c | 4 +---
board/intel/cougarcanyon2/cougarcanyon2.c | 4 +---
drivers/mmc/omap_hsmmc.c | 2 +-
drivers/serial/serial-uclass.c| 2 +-
drivers/serial/serial_bcm283x_mu.c| 2 +-
drivers/serial/serial_bcm283x_pl011.c | 2 +-
drivers/sysreset/sysreset_ast.c | 2 +-
drivers/video/exynos/exynos_fb.c | 14 +++---
drivers/video/mali_dp.c | 2 +-
drivers/video/stm32/stm32_dsi.c | 2 +-
drivers/video/tegra124/dp.c | 4 ++--
lib/acpi/acpi_table.c | 2 +-
lib/efi_loader/efi_gop.c | 2 +-
net/eth-uclass.c | 4 ++--
test/boot/bootmeth.c | 2 +-
test/dm/acpi.c| 14 +++---
test/dm/devres.c | 4 ++--
test/dm/i2c.c | 8
test/dm/virtio_device.c | 8
test/dm/virtio_rng.c | 2 +-
test/fuzz/cmd_fuzz.c | 2 +-
test/fuzz/virtio.c| 2 +-
25 files changed, 43 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-omap2/am33xx/board.c
b/arch/arm/mach-omap2/am33xx/board.c
index 7f1b84e466..f393ff9144 100644
--- a/arch/arm/mach-omap2/am33xx/board.c
+++ b/arch/arm/mach-omap2/am33xx/board.c
@@ -265,8 +265,8 @@ int arch_misc_init(void)
struct udevice *dev;
int ret;
- ret = uclass_first_device(UCLASS_MISC, &dev);
- if (ret || !dev)
+ ret = uclass_first_device_err(UCLASS_MISC, &dev);
+ if (ret)
return ret;
#if defined(CONFIG_DM_ETH) && defined(CONFIG_USB_ETHER)
diff --git a/arch/x86/cpu/broadwell/cpu.c b/arch/x86/cpu/broadwell/cpu.c
index 2adcf4b242..7877961451 100644
--- a/arch/x86/cpu/broadwell/cpu.c
+++ b/arch/x86/cpu/broadwell/cpu.c
@@ -31,11 +31,9 @@ static int broadwell_init_cpu(void *ctx, struct event *event)
int ret;
/* Start up the LPC so we have serial */
- ret = uclass_first_device(UCLASS_LPC, &dev);
+ ret = uclass_first_device_err(UCLASS_LPC, &dev);
if (ret)
return ret;
- if (!dev)
- return -ENODEV;
ret = cpu_set_flex_ratio_to_tdp_nominal();
if (ret)
return ret;
diff --git a/arch/x86/cpu/intel_common/cpu.c b/arch/x86/cpu/intel_common/cpu.c
index 96d05e2eb3..8f489e6c65 100644
--- a/arch/x86/cpu/intel_common/cpu.c
+++ b/arch/x86/cpu/intel_common/cpu.c
@@ -61,11 +61,9 @@ int cpu_common_init(void)
/* Early chipset init required before RAM init can work */
uclass_first_device(UCLASS_NORTHBRIDGE, &dev);
- ret = uclass_first_device(UCLASS_LPC, &lpc);
+ ret = uclass_first_device_err(UCLASS_LPC, &lpc);
if (ret)
return ret;
- if (!lpc)
- return -ENODEV;
/* Cause the SATA device to do its early init */
uclass_first_device(UCLASS_AHCI, &dev);
diff --git a/arch/x86/lib/pinctrl_ich6.c b/arch/x86/lib/pinctrl_ich6.c
index fd5e311b29..c93f245845 100644
--- a/arch/x86/lib/pinctrl_ich6.c
+++ b/arch/x86/lib/pinctrl_ich6.c
@@ -160,11 +160,9 @@ static int ich6_pinctrl_probe(struct udevice *dev)
u32 iobase = -1;
debug("%s: start\n", __func__);
- ret = uclass_first_device(UCLASS_PCH, &pch);
+ ret = uclass_first_device_err(UCLASS_PCH, &pch);
if (ret)
return ret;
- if (!pch)
- return -ENODEV;
/*
* Get the memory/io base address to configure every pins.
diff --git a/board/intel/cougarcanyon2/cougarcanyon2.c
b/board/intel/cougarcanyon2/cougarcanyon2.c
index ce11eae59d..7f61ef8b36 100644
--- a/board/intel/cougarcanyon2/cougarcanyon2.c
+++ b/board/intel/cougarcanyon2/cougarcanyon2.c
@@ -21,11 +21,9 @@ int board_early_init_f(void)
struct udevice *pch;
int ret;
- ret = uclass_first_device(UCLASS_PCH, &pch);
+ ret = uclass_first_device_err(UCLASS_PCH, &pch);
if (ret)
return ret;
- if (!pch)
- return -ENODEV;
[PATCH v6 09/20] cmd: List all uclass devices regardless of probe error
There are a few commands that iterate uclass with
uclass_first_device/uclass_next_device or the _err variant.
Use the _check class iterator variant to get devices that fail to probe
as well, and print the status.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v6: Drop errno_str
---
cmd/adc.c | 20
cmd/demo.c | 15 +--
cmd/gpio.c | 15 +++
cmd/pmic.c | 15 ---
cmd/regulator.c | 13 +++--
5 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/cmd/adc.c b/cmd/adc.c
index 1c5d3e10a3..a739d9e464 100644
--- a/cmd/adc.c
+++ b/cmd/adc.c
@@ -12,23 +12,19 @@ static int do_adc_list(struct cmd_tbl *cmdtp, int flag, int
argc,
char *const argv[])
{
struct udevice *dev;
- int ret;
+ int ret, err;
- ret = uclass_first_device_err(UCLASS_ADC, &dev);
- if (ret) {
- printf("No available ADC device\n");
- return CMD_RET_FAILURE;
- }
+ ret = err = uclass_first_device_check(UCLASS_ADC, &dev);
- do {
- printf("- %s\n", dev->name);
+ while (dev) {
+ printf("- %s status: %i\n", dev->name, ret);
- ret = uclass_next_device(&dev);
+ ret = uclass_next_device_check(&dev);
if (ret)
- return CMD_RET_FAILURE;
- } while (dev);
+ err = ret;
+ }
- return CMD_RET_SUCCESS;
+ return err ? CMD_RET_FAILURE : CMD_RET_SUCCESS;
}
static int do_adc_info(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/cmd/demo.c b/cmd/demo.c
index 571f562ec6..ebd5a241c3 100644
--- a/cmd/demo.c
+++ b/cmd/demo.c
@@ -64,20 +64,23 @@ static int do_demo_light(struct cmd_tbl *cmdtp, int flag,
int argc,
int do_demo_list(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct udevice *dev;
- int i, ret;
+ int i, ret, err = 0;
puts("Demo uclass entries:\n");
- for (i = 0, ret = uclass_first_device(UCLASS_DEMO, &dev);
+ for (i = 0, ret = uclass_first_device_check(UCLASS_DEMO, &dev);
dev;
-ret = uclass_next_device(&dev)) {
- printf("entry %d - instance %08x, ops %08x, plat %08x\n",
+ret = uclass_next_device_check(&dev)) {
+ printf("entry %d - instance %08x, ops %08x, plat %08x, status
%i\n",
i++, (uint)map_to_sysmem(dev),
(uint)map_to_sysmem(dev->driver->ops),
- (uint)map_to_sysmem(dev_get_plat(dev)));
+ (uint)map_to_sysmem(dev_get_plat(dev)),
+ ret);
+ if (ret)
+ err = ret;
}
- return cmd_process_error(cmdtp, ret);
+ return cmd_process_error(cmdtp, err);
}
static struct cmd_tbl demo_commands[] = {
diff --git a/cmd/gpio.c b/cmd/gpio.c
index 53e9ce666f..f4565982ec 100644
--- a/cmd/gpio.c
+++ b/cmd/gpio.c
@@ -77,17 +77,24 @@ static int do_gpio_status(bool all, const char *gpio_name)
struct udevice *dev;
int banklen;
int flags;
- int ret;
+ int ret, err = 0;
flags = 0;
if (gpio_name && !*gpio_name)
gpio_name = NULL;
- for (ret = uclass_first_device(UCLASS_GPIO, &dev);
+ for (ret = uclass_first_device_check(UCLASS_GPIO, &dev);
dev;
-ret = uclass_next_device(&dev)) {
+ret = uclass_next_device_check(&dev)) {
const char *bank_name;
int num_bits;
+ if (ret) {
+ printf("GPIO device %s probe error %i\n",
+ dev->name, ret);
+ err = ret;
+ continue;
+ }
+
flags |= FLAG_SHOW_BANK;
if (all)
flags |= FLAG_SHOW_ALL;
@@ -120,7 +127,7 @@ static int do_gpio_status(bool all, const char *gpio_name)
flags |= FLAG_SHOW_NEWLINE;
}
- return ret;
+ return err;
}
#endif
diff --git a/cmd/pmic.c b/cmd/pmic.c
index 0cb44d0740..49a405fa29 100644
--- a/cmd/pmic.c
+++ b/cmd/pmic.c
@@ -51,25 +51,26 @@ static int do_list(struct cmd_tbl *cmdtp, int flag, int
argc,
char *const argv[])
{
struct udevice *dev;
- int ret;
+ int ret, err = 0;
printf("| %-*.*s| %-*.*s| %s @ %s\n",
LIMIT_DEV, LIMIT_DEV, "Name",
LIMIT_PARENT, LIMIT_PARENT, "Parent name",
"Parent uclass", "seq");
- for (ret = uclass_first_device(UCLASS_PMIC, &dev); dev;
-ret = uclass_next_device(&dev)) {
+ for (ret = uclass_first_device_check(UCLASS_PMIC, &dev); dev;
+ret = uclass_next_device_check(&dev)) {
if (ret)
- continue;
+
[PATCH v6 07/20] video: ipuv3: Fix error handling when getting the display
The code checks that uclass_first_device returned a device but the
returned value that is assigned is never used. Use
uclass_first_device_err instead, and move the error return outside of
the if block.
Fixes: f4ec1ae08e ("mxc_ipuv3_fb.c: call display_enable")
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
drivers/video/imx/mxc_ipuv3_fb.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/imx/mxc_ipuv3_fb.c b/drivers/video/imx/mxc_ipuv3_fb.c
index 49bbeefdd8..8b01a1be11 100644
--- a/drivers/video/imx/mxc_ipuv3_fb.c
+++ b/drivers/video/imx/mxc_ipuv3_fb.c
@@ -609,12 +609,11 @@ static int ipuv3_video_probe(struct udevice *dev)
return ret;
#if defined(CONFIG_DISPLAY)
- ret = uclass_first_device(UCLASS_DISPLAY, &disp_dev);
- if (disp_dev) {
+ ret = uclass_first_device_err(UCLASS_DISPLAY, &disp_dev);
+ if (!ret)
ret = display_enable(disp_dev, 16, NULL);
- if (ret < 0)
- return ret;
- }
+ if (ret < 0)
+ return ret;
#endif
if (CONFIG_IS_ENABLED(PANEL)) {
struct udevice *panel_dev;
--
2.37.3
[PATCH v6 06/20] stdio: Fix class iteration in stdio_add_devices()
There is a complaint in the code that iterates keyboards that we don't
have the _check variant of class iterator but we in fact do, use it.
In the code that iterates video devices there is an attempt to print
errors but the simple iterator does not return a device when there is an
error. Use the _check variant of the iterator as well.
Also format error messages consistently.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v6:
- drop errno_str
- fix dev vs vdev in video error print
---
common/stdio.c | 32 +---
1 file changed, 13 insertions(+), 19 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index 13083842cb..e316a355fa 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -314,7 +314,6 @@ int stdio_init_tables(void)
int stdio_add_devices(void)
{
struct udevice *dev;
- struct uclass *uc;
int ret;
if (IS_ENABLED(CONFIG_DM_KEYBOARD)) {
@@ -324,24 +323,18 @@ int stdio_add_devices(void)
* have a list of input devices to start up in the stdin
* environment variable. That work probably makes more sense
* when stdio itself is converted to driver model.
-*
-* TODO(s...@chromium.org): Convert changing
-* uclass_first_device() etc. to return the device even on
-* error. Then we could use that here.
*/
- ret = uclass_get(UCLASS_KEYBOARD, &uc);
- if (ret)
- return ret;
/*
* Don't report errors to the caller - assume that they are
* non-fatal
*/
- uclass_foreach_dev(dev, uc) {
- ret = device_probe(dev);
+ for (ret = uclass_first_device_check(UCLASS_KEYBOARD, &dev);
+ dev;
+ ret = uclass_next_device_check(&dev)) {
if (ret)
- printf("Failed to probe keyboard '%s'\n",
- dev->name);
+ printf("%s: Failed to probe keyboard '%s'
(ret=%d)\n",
+ __func__, dev->name, ret);
}
}
#if CONFIG_IS_ENABLED(SYS_I2C_LEGACY)
@@ -361,13 +354,14 @@ int stdio_add_devices(void)
int ret;
if (!IS_ENABLED(CONFIG_SYS_CONSOLE_IS_IN_ENV)) {
- for (ret = uclass_first_device(UCLASS_VIDEO, &vdev);
-vdev;
-ret = uclass_next_device(&vdev))
- ;
- if (ret)
- printf("%s: Video device failed (ret=%d)\n",
- __func__, ret);
+ for (ret = uclass_first_device_check(UCLASS_VIDEO,
+&vdev);
+ vdev;
+ ret = uclass_next_device_check(&vdev)) {
+ if (ret)
+ printf("%s: Failed to probe video
device '%s' (ret=%d)\n",
+ __func__, vdev->name, ret);
+ }
}
if (IS_ENABLED(CONFIG_SPLASH_SCREEN) &&
IS_ENABLED(CONFIG_CMD_BMP))
--
2.37.3
[PATCH v6 08/20] w1: Fix bus counting in w1_get_bus
Use uclass_first_device_check/uclass_next_device_check to correctly
count buses that fail to probe.
Fixes: d3e19cf919 ("w1: Add 1-Wire uclass")
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
drivers/w1/w1-uclass.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/w1/w1-uclass.c b/drivers/w1/w1-uclass.c
index 52b519c21d..de4f25bcf9 100644
--- a/drivers/w1/w1-uclass.c
+++ b/drivers/w1/w1-uclass.c
@@ -16,6 +16,7 @@
#include
#include
+#include
#include
#include
#include
@@ -182,24 +183,25 @@ static int w1_enumerate(struct udevice *bus)
int w1_get_bus(int busnum, struct udevice **busp)
{
int ret, i = 0;
-
struct udevice *dev;
- for (ret = uclass_first_device(UCLASS_W1, &dev);
-dev && !ret;
-ret = uclass_next_device(&dev), i++) {
+ for (ret = uclass_first_device_check(UCLASS_W1, &dev);
+ dev;
+ ret = uclass_next_device_check(&dev), i++) {
if (i == busnum) {
+ if (ret) {
+ debug("Cannot probe w1 bus %d: %d (%s)\n",
+ busnum, ret, errno_str(ret));
+ return ret;
+ }
*busp = dev;
return 0;
}
}
- if (!ret) {
- debug("Cannot find w1 bus %d\n", busnum);
- ret = -ENODEV;
- }
+ debug("Cannot find w1 bus %d\n", busnum);
- return ret;
+ return -ENODEV;
}
u8 w1_get_device_family(struct udevice *dev)
--
2.37.3
[PATCH v6 05/20] usb: ether: Fix error handling in usb_ether_init
The code checks the return value from uclass_first_device as well as
that the device exists but it passes on the return value which may be
zero if there are no gadget devices. Just check that a device was
returned and return -ENODEV otherwise.
Also remove the dev variable which is not really used for anything.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
drivers/usb/gadget/ether.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 6ce389de9f..43aec7ffa7 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2636,18 +2636,17 @@ static const struct eth_ops usb_eth_ops = {
int usb_ether_init(void)
{
- struct udevice *dev;
struct udevice *usb_dev;
int ret;
- ret = uclass_first_device(UCLASS_USB_GADGET_GENERIC, &usb_dev);
- if (!usb_dev || ret) {
+ uclass_first_device(UCLASS_USB_GADGET_GENERIC, &usb_dev);
+ if (!usb_dev) {
pr_err("No USB device found\n");
- return ret;
+ return -ENODEV;
}
- ret = device_bind_driver(usb_dev, "usb_ether", "usb_ether", &dev);
- if (!dev || ret) {
+ ret = device_bind_driver(usb_dev, "usb_ether", "usb_ether", NULL);
+ if (ret) {
pr_err("usb - not able to bind usb_ether device\n");
return ret;
}
--
2.37.3
[PATCH v6 04/20] bootstd: Fix listing boot devices
bootdev_list() uses uclass_*_device_err() to iterate devices.
However, the only value _err adds is returning an error when the device
pointer is null, and that's checked anyway.
Also there is some intent to report errors, and that's what
uclass_*_device_check() is for, use it.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v6: Drop errno_str
---
boot/bootdev-uclass.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 13ac69eb39..9d98bee454 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -195,7 +195,7 @@ void bootdev_list(bool probe)
printf("Seq Probed Status UclassName\n");
printf("--- -- -- --\n");
if (probe)
- ret = uclass_first_device_err(UCLASS_BOOTDEV, &dev);
+ ret = uclass_first_device_check(UCLASS_BOOTDEV, &dev);
else
ret = uclass_find_first_device(UCLASS_BOOTDEV, &dev);
for (i = 0; dev; i++) {
@@ -204,7 +204,7 @@ void bootdev_list(bool probe)
ret ? simple_itoa(ret) : "OK",
dev_get_uclass_name(dev_get_parent(dev)), dev->name);
if (probe)
- ret = uclass_next_device_err(&dev);
+ ret = uclass_next_device_check(&dev);
else
ret = uclass_find_next_device(&dev);
}
--
2.37.3
[PATCH v6 02/20] dm: treewide: Do not opencode uclass_probe_all()
We already have a function for probing all devices of a specific class,
use it.
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
drivers/cpu/cpu-uclass.c | 20
drivers/virtio/virtio-uclass.c | 15 +--
test/dm/core.c | 17 +++--
test/test-main.c | 11 +--
4 files changed, 9 insertions(+), 54 deletions(-)
diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
index 71e5900d70..a754832526 100644
--- a/drivers/cpu/cpu-uclass.c
+++ b/drivers/cpu/cpu-uclass.c
@@ -20,25 +20,13 @@ DECLARE_GLOBAL_DATA_PTR;
int cpu_probe_all(void)
{
- struct udevice *cpu;
- int ret;
+ int ret = uclass_probe_all(UCLASS_CPU);
- ret = uclass_first_device(UCLASS_CPU, &cpu);
if (ret) {
- debug("%s: No CPU found (err = %d)\n", __func__, ret);
- return ret;
- }
-
- while (cpu) {
- ret = uclass_next_device(&cpu);
- if (ret) {
- debug("%s: Error while probing CPU (err = %d)\n",
- __func__, ret);
- return ret;
- }
+ debug("%s: Error while probing CPUs (err = %d %s)\n",
+ __func__, ret, errno_str(ret));
}
-
- return 0;
+ return ret;
}
int cpu_is_current(struct udevice *cpu)
diff --git a/drivers/virtio/virtio-uclass.c b/drivers/virtio/virtio-uclass.c
index 9e2d0e06a1..da4f2f26a6 100644
--- a/drivers/virtio/virtio-uclass.c
+++ b/drivers/virtio/virtio-uclass.c
@@ -183,21 +183,8 @@ void virtio_driver_features_init(struct virtio_dev_priv
*priv,
int virtio_init(void)
{
- struct udevice *bus;
- int ret;
-
/* Enumerate all known virtio devices */
- ret = uclass_first_device(UCLASS_VIRTIO, &bus);
- if (ret)
- return ret;
-
- while (bus) {
- ret = uclass_next_device(&bus);
- if (ret)
- break;
- }
-
- return ret;
+ return uclass_probe_all(UCLASS_VIRTIO);
}
static int virtio_uclass_pre_probe(struct udevice *udev)
diff --git a/test/dm/core.c b/test/dm/core.c
index fd4d756972..84eb76ed5f 100644
--- a/test/dm/core.c
+++ b/test/dm/core.c
@@ -512,23 +512,15 @@ static int dm_test_leak(struct unit_test_state *uts)
int i;
for (i = 0; i < 2; i++) {
- struct udevice *dev;
int ret;
- int id;
dm_leak_check_start(uts);
ut_assertok(dm_scan_plat(false));
ut_assertok(dm_scan_fdt(false));
- /* Scanning the uclass is enough to probe all the devices */
- for (id = UCLASS_ROOT; id < UCLASS_COUNT; id++) {
- for (ret = uclass_first_device(UCLASS_TEST, &dev);
-dev;
-ret = uclass_next_device(&dev))
- ;
- ut_assertok(ret);
- }
+ ret = uclass_probe_all(UCLASS_TEST);
+ ut_assertok(ret);
ut_assertok(dm_leak_check_end(uts));
}
@@ -653,10 +645,7 @@ static int dm_test_children(struct unit_test_state *uts)
ut_asserteq(2 + NODE_COUNT, dm_testdrv_op_count[DM_TEST_OP_PROBE]);
/* Probe everything */
- for (ret = uclass_first_device(UCLASS_TEST, &dev);
-dev;
-ret = uclass_next_device(&dev))
- ;
+ ret = uclass_probe_all(UCLASS_TEST);
ut_assertok(ret);
ut_asserteq(total, dm_testdrv_op_count[DM_TEST_OP_PROBE]);
diff --git a/test/test-main.c b/test/test-main.c
index d74df297c4..a98a77d68f 100644
--- a/test/test-main.c
+++ b/test/test-main.c
@@ -165,16 +165,7 @@ static int dm_test_post_run(struct unit_test_state *uts)
/* Ensure all the test devices are probed */
static int do_autoprobe(struct unit_test_state *uts)
{
- struct udevice *dev;
- int ret;
-
- /* Scanning the uclass is enough to probe all the devices */
- for (ret = uclass_first_device(UCLASS_TEST, &dev);
-dev;
-ret = uclass_next_device(&dev))
- ;
-
- return ret;
+ return uclass_probe_all(UCLASS_TEST);
}
/*
--
2.37.3
[PATCH v6 01/20] dm: core: Fix uclass_probe_all to really probe all devices
uclass_probe_all uses uclass_first_device/uclass_next_device assigning
the return value.
The interface for getting meaningful error is
uclass_first_device_check/uclass_next_device_check, use it.
Also do not stop iteration when an error is encountered. Probing all
devices includes those that happen to be after a failing device in the
uclass order.
Fixes: a59153dfeb ("dm: core: add function uclass_probe_all() to probe all
devices")
Signed-off-by: Michal Suchanek
---
v6: add test
---
drivers/core/uclass.c | 12 +---
test/dm/test-fdt.c| 19 +++
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
index 08d9ed82de..a591e22403 100644
--- a/drivers/core/uclass.c
+++ b/drivers/core/uclass.c
@@ -799,20 +799,18 @@ int uclass_pre_remove_device(struct udevice *dev)
int uclass_probe_all(enum uclass_id id)
{
struct udevice *dev;
- int ret;
+ int ret, err;
- ret = uclass_first_device(id, &dev);
- if (ret || !dev)
- return ret;
+ err = uclass_first_device_check(id, &dev);
/* Scanning uclass to probe all devices */
while (dev) {
- ret = uclass_next_device(&dev);
+ ret = uclass_next_device_check(&dev);
if (ret)
- return ret;
+ err = ret;
}
- return 0;
+ return err;
}
int uclass_id_count(enum uclass_id id)
diff --git a/test/dm/test-fdt.c b/test/dm/test-fdt.c
index 012f2f455f..1f14513d9f 100644
--- a/test/dm/test-fdt.c
+++ b/test/dm/test-fdt.c
@@ -392,10 +392,10 @@ DM_TEST(dm_test_fdt_offset,
UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT | UT_TESTF_FLAT_TREE);
/**
- * Test various error conditions with uclass_first_device() and
- * uclass_next_device()
+ * Test various error conditions with uclass_first_device(),
+ * uclass_next_device(), and uclass_probe_all()
*/
-static int dm_test_first_next_device(struct unit_test_state *uts)
+static int dm_test_first_next_device_probeall(struct unit_test_state *uts)
{
struct dm_testprobe_pdata *pdata;
struct udevice *dev, *parent = NULL;
@@ -428,9 +428,20 @@ static int dm_test_first_next_device(struct
unit_test_state *uts)
device_remove(parent, DM_REMOVE_NORMAL);
ut_asserteq(-ENOENT, uclass_first_device(UCLASS_TEST_PROBE, &dev));
+ /* Now that broken devices are set up test probe_all */
+ device_remove(parent, DM_REMOVE_NORMAL);
+ /* There are broken devices so an error should be returned */
+ ut_assert(uclass_probe_all(UCLASS_TEST_PROBE) < 0);
+ /* but non-error device should be probed nonetheless */
+ ut_assertok(uclass_get_device(UCLASS_TEST_PROBE, 2, &dev));
+ ut_assert(dev_get_flags(dev) & DM_FLAG_ACTIVATED);
+ ut_assertok(uclass_get_device(UCLASS_TEST_PROBE, 3, &dev));
+ ut_assert(dev_get_flags(dev) & DM_FLAG_ACTIVATED);
+
return 0;
}
-DM_TEST(dm_test_first_next_device, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+DM_TEST(dm_test_first_next_device_probeall,
+ UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
/* Test iteration through devices in a uclass */
static int dm_test_uclass_foreach(struct unit_test_state *uts)
--
2.37.3
[PATCH v6 03/20] dm: pci: Fix device PCI iteration
When there is no PCI bus uclass_first_device will return no bus and no
error which will result in pci_find_first_device calling
skip_to_next_device with no bus, and the bus is only checked at the end
of the while cycle, not the beginning.
Fixes: 76c3fbcd3d ("dm: pci: Add a way to iterate through all PCI devices")
Signed-off-by: Michal Suchanek
Reviewed-by: Simon Glass
---
v6: Move dropping the use of uclass iterator return value to later patch
---
drivers/pci/pci-uclass.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 058b2f6359..5cff81ac44 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1217,7 +1217,7 @@ static int skip_to_next_device(struct udevice *bus,
struct udevice **devp)
* Scan through all the PCI controllers. On x86 there will only be one
* but that is not necessarily true on other hardware.
*/
- do {
+ while (bus) {
device_find_first_child(bus, &dev);
if (dev) {
*devp = dev;
@@ -1226,7 +1226,7 @@ static int skip_to_next_device(struct udevice *bus,
struct udevice **devp)
ret = uclass_next_device(&bus);
if (ret)
return ret;
- } while (bus);
+ }
return 0;
}
--
2.37.3
Re: [PATCH v6 7/8] net: add MV88E61xx DSA driver
On Mon, Oct 10, 2022 at 09:39:43AM -0700, Tim Harvey wrote:
> Add a DSA driver for the MV88E6xxx compatible Ethernet switches.
>
> Cc: Marek BehĂșn
> Cc: Vladimir Oltean
> Signed-off-by: Tim Harvey
> Reviewed-by: Vladimir Oltean
> Reviewed-by: Fabio Estevam
> ---
> v6:
> - update commit msg (s/MV88E61xx/MV88E6xxx)
really?
> - remove GbE from commit msg and Kconfig desc
> - squash accidental change from patch 7 into patch 6
> - added error print on failure to read switch id
> - mv88e6xxx_probe:
> - check for switch enabled
> - remove unused variable enabled
> - remove unnecessary call to dsa_set_tagging
> - port_probe:
> - new function to configure phy features by calling phy_config
> - port_enable:
> - only enable energy-detect sensing on phy ports
> - add phy/cmode verification mistmatch warning
> - remove mv88e6xxx_fixed_port_setup()
> - always force link up for fixed ports
> - always set SERDES mode regardless of cpu port
really?
> +struct mv88e6xxx_priv {
> + int smi_addr;
> + int id;
> + int port_count; /* Number of switch ports */
> + int port_reg_base; /* Base of the switch port registers */
> + u8 global1; /* Offset of Switch Global 1 registers */
> + u8 global2; /* Offset of Switch Global 2 registers */
> + u8 phy_ctrl1_en_det_shift; /* 'EDet' bit field offset */
> + u8 phy_ctrl1_en_det_width; /* Width of 'EDet' bit field */
> + u8 phy_ctrl1_en_det_ctrl; /* 'EDet' control value */
> +};
> +
> +static inline int smi_cmd(int cmd, int addr, int reg)
If the convention in U-Boot is the same as in Linux (which it well may be,
except for the fact that more things escape review), then you should
avoid manually defining functions as inline in C files. The compiler
will decide whether to inline or not regardless of what you specify here.
Although I wonder if these couldn't be in fact expressed more clearly
using plain, boring old logical | and << operators as part of a macro.
> +{
> + cmd = bitfield_replace(cmd, SMI_CMD_ADDR_SHIFT, SMI_CMD_ADDR_WIDTH,
> +addr);
> + cmd = bitfield_replace(cmd, SMI_CMD_REG_SHIFT, SMI_CMD_REG_WIDTH, reg);
> + return cmd;
> +}
> +
> +static inline int smi_cmd_read(int addr, int reg)
> +{
> + return smi_cmd(SMI_CMD_READ, addr, reg);
> +}
> +
> +static inline int smi_cmd_write(int addr, int reg)
> +{
> + return smi_cmd(SMI_CMD_WRITE, addr, reg);
> +}
> +
> +/* Wait for the current SMI indirect command to complete */
> +static int mv88e6xxx_smi_wait(struct udevice *dev, int smi_addr)
> +{
> + int val;
> + u32 timeout = 100;
> +
> + do {
> + val = dm_mdio_read(dev->parent, smi_addr, MDIO_DEVAD_NONE,
> SMI_CMD_REG);
> + if (val >= 0 && (val & SMI_BUSY) == 0)
> + return 0;
> +
> + mdelay(1);
> + } while (--timeout);
> +
> + dev_err(dev, "SMI busy timeout\n");
> + return -ETIMEDOUT;
> +}
> +
> +static int mv88e6xxx_serdes_init(struct udevice *dev)
> +{
> + int val;
> +
> + val = mv88e6xxx_set_page(dev, DEVADDR_SERDES, PHY_PAGE_SERDES);
> + if (val < 0)
> + return val;
> +
> + /* Power up serdes module */
> + val = mv88e6xxx_phy_read(dev, DEVADDR_SERDES, MII_BMCR);
> + if (val < 0)
> + return val;
> + val &= ~(BMCR_PDOWN);
> + val = mv88e6xxx_phy_write(dev, DEVADDR_SERDES, MII_BMCR, val);
> + if (val < 0)
> + return val;
> +
> + return 0;
> +}
> +
> +static int mv88e6xxx_port_enable(struct udevice *dev, int port, struct
> phy_device *phy)
> +{
> + struct dsa_pdata *dsa_pdata = dev_get_uclass_plat(dev);
> + struct mv88e6xxx_priv *priv = dev_get_priv(dev);
> + int val, ret;
> +
> + dev_dbg(dev, "%s P%d phy:0x%08x %s\n", __func__, port,
> + phy->phy_id, phy_string_for_interface(phy->interface));
> +
> + /*
> + * Enable energy-detect sensing on PHY, used to determine when a PHY
> + * port is physically connected
> + */
> + if (port != dsa_pdata->cpu_port) {
Can you test based on phy->interface == PHY_INTERFACE_MODE_INTERNAL?
Support may come later for cascade ports, and those are ports without an
internal PHY which are not CPU ports.
> + val = mv88e6xxx_phy_read(dev, port, PHY_REG_CTRL1);
> + if (val < 0)
> + return val;
> + val = bitfield_replace(val, priv->phy_ctrl1_en_det_shift,
> +priv->phy_ctrl1_en_det_width,
> +priv->phy_ctrl1_en_det_ctrl);
> + val = mv88e6xxx_phy_write(dev, port, PHY_REG_CTRL1, val);
> + if (val < 0)
> + return val;
> + }
> +
> + /* enable port */
> + val = mv88e6xxx_port_read(dev, port, PORT_REG_CTRL);
> + if (val < 0)
> + return val;
> + val = bitfield_replace(val, PORT_REG_CTRL_PSTATE_SHIFT,
> +
Re: [PATCH 2/3] clk: stm32mp13: introduce STM32MP13 RCC driver
On 10/12/22 08:33, Gabriel Fernandez wrote:
Introduce STM32MP13 RCC driver using Common Clock Framework.
Signed-off-by: Gabriel Fernandez
---
drivers/clk/stm32/Kconfig | 15 +
drivers/clk/stm32/Makefile |2 +
drivers/clk/stm32/clk-stm32-core.c | 349 ++
drivers/clk/stm32/clk-stm32-core.h | 154 +++
drivers/clk/stm32/clk-stm32mp13.c | 839 +
drivers/clk/stm32/stm32mp13_rcc.h | 1751
6 files changed, 3110 insertions(+)
create mode 100644 drivers/clk/stm32/clk-stm32-core.c
create mode 100644 drivers/clk/stm32/clk-stm32-core.h
create mode 100644 drivers/clk/stm32/clk-stm32mp13.c
create mode 100644 drivers/clk/stm32/stm32mp13_rcc.h
diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
index eac3fc1e9d..7a34ea23c3 100644
--- a/drivers/clk/stm32/Kconfig
+++ b/drivers/clk/stm32/Kconfig
@@ -14,6 +14,12 @@ config CLK_STM32H7
This clock driver adds support for RCC clock management
for STM32H7 SoCs.
+config CLK_STM32_CORE
+ bool "Enable RCC clock core driver for STM32MP"
+ depends on ARCH_STM32MP && CLK
+ select CLK_CCF
+ select CLK_COMPOSITE_CCF
+
config CLK_STM32MP1
bool "Enable RCC clock driver for STM32MP15"
depends on ARCH_STM32MP && CLK
@@ -21,3 +27,12 @@ config CLK_STM32MP1
help
Enable the STM32 clock (RCC) driver. Enable support for
manipulating STM32MP15's on-SoC clocks.
+
+config CLK_STM32MP13
+ bool "Enable RCC clock driver for STM32MP13"
+ depends on ARCH_STM32MP && CLK
+ default y if STM32MP13x
+ select CLK_STM32_CORE
+ help
+ Enable the STM32 clock (RCC) driver. Enable support for
+ manipulating STM32MP13's on-SoC clocks.
diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index f66f295403..20afbc3cfc 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -2,6 +2,8 @@
#
# Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+obj-$(CONFIG_CLK_STM32_CORE) += clk-stm32-core.o
obj-$(CONFIG_CLK_STM32F) += clk-stm32f.o
obj-$(CONFIG_CLK_STM32H7) += clk-stm32h7.o
obj-$(CONFIG_CLK_STM32MP1) += clk-stm32mp1.o
+obj-$(CONFIG_CLK_STM32MP13) += clk-stm32mp13.o
diff --git a/drivers/clk/stm32/clk-stm32-core.c
b/drivers/clk/stm32/clk-stm32-core.c
new file mode 100644
index 00..5e02807c1e
--- /dev/null
+++ b/drivers/clk/stm32/clk-stm32-core.c
@@ -0,0 +1,349 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ * Author: Gabriel Fernandez for
STMicroelectronics.
+ */
+
+#define LOG_CATEGORY UCLASS_CLK
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clk-stm32-core.h"
+
+int stm32_rcc_init(struct device *dev,
+ const struct stm32_clock_match_data *data,
+ void __iomem *base)
+{
+ int i;
+
+ for (i = 0; i < data->num_clocks; i++) {
+ const struct clock_config *cfg = &data->tab_clocks[i];
+ struct clk *clk = ERR_PTR(-ENOENT);
+
+ if (data->check_security) {
+ if ((*data->check_security)(base, cfg))
Why do you need to dereference this?
You can also rewrite this as
if (data->check_security && data->check_security(base, cfg))
continue;
+ continue;
+ }
+
+ if (cfg->func)
+ clk = (*cfg->func)(NULL, data, base, NULL, cfg);
ditto wrt dereferencing
+
+ if (IS_ERR(clk)) {
this can be the else branch from above
+ log_err("%s: failed to register clock %s\n", __func__,
+ cfg->name);
+
+ return PTR_ERR(clk);
you can just return -ENOENT
+ }
+
+ clk->id = cfg->id;
+ }
+
+ return 0;
+}
+
+static const struct clk_ops *clk_dev_ops(struct udevice *dev)
+{
+ return (const struct clk_ops *)dev->driver->ops;
+}
+
+static int stm32_clk_enable(struct clk *clk)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id || clk_get_by_id(clk->id, &clkp))
+ return -ENOENT;
+
+ ops = clk_dev_ops(clkp->dev);
+ if (!ops->enable)
+ return 0;
+
+ return ops->enable(clkp);
+}
+
+static int stm32_clk_disable(struct clk *clk)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id || clk_get_by_id(clk->id, &clkp))
+ return -ENOENT;
+
+ ops = clk_dev_ops(clkp->dev);
+ if (!ops->disable)
+ return 0;
+
+ return ops->disable(clkp);
+}
+
+static ulong stm32_clk_get_rate(struct clk *clk)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id || clk_get_by_id(clk->id, &clkp))
+
[PATCH 2/2] spl: spl_legacy: Fix printing image name
image_set_name does not terminate the name in the image header. Then is should not be assument it's nul terminated. image_print_contents correctly print only IH_NMLEN characters. Fix printing the unterminated field in spl_parse_legacy_header. The format specifies the minimum printed length, not maximum. Signed-off-by: Michal Suchanek --- common/spl/spl_legacy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/spl/spl_legacy.c b/common/spl/spl_legacy.c index b3624dfbb7..11c459254b 100644 --- a/common/spl/spl_legacy.c +++ b/common/spl/spl_legacy.c @@ -55,7 +55,7 @@ int spl_parse_legacy_header(struct spl_image_info *spl_image, spl_image->os = image_get_os(header); spl_image->name = image_get_name(header); debug(SPL_TPL_PROMPT - "payload image: %32s load addr: 0x%lx size: %d\n", + "payload image: %.*s load addr: 0x%lx size: %d\n", IH_NMLEN, spl_image->name, spl_image->load_addr, spl_image->size); return 0; -- 2.37.3
[PATCH 1/2] image: Suppress string truncation warning
In file included from ../tools/imagetool.h:24,
from ../tools/default_image.c:16:
In function ‘image_set_name’,
inlined from ‘image_set_header’ at ../tools/default_image.c:133:2:
../include/image.h:786:9: warning: ‘strncpy’ specified bound 32 equals
destination size [-Wstringop-truncation]
786 | strncpy(image_get_name(hdr), name, IH_NMLEN);
| ^~~~
There is no standard function that can be used to make the copy without
a warning.
Signed-off-by: Michal Suchanek
---
include/image.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/image.h b/include/image.h
index d7d6a3fe5b..e08ef6ed55 100644
--- a/include/image.h
+++ b/include/image.h
@@ -783,7 +783,14 @@ image_set_hdr_b(comp) /* image_set_comp */
static inline void image_set_name(struct legacy_img_hdr *hdr, const char *name)
{
+#if defined(__GNUC__) && (__GNUC__ > 7)
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wstringop-truncation"
+#endif
strncpy(image_get_name(hdr), name, IH_NMLEN);
+#if defined(__GNUC__) && (__GNUC__ > 7)
+#pragma GCC diagnostic pop
+#endif
}
int image_check_hcrc(const struct legacy_img_hdr *hdr);
--
2.37.3
Re: [PATCH] Nokia RX-51: Fix double space key press
On Sun, Oct 09, 2022 at 09:38:25PM +0200, Pali Rohár wrote: > Space key is indicated by two different bits. Some HW models indicate press > of space key only by the first bit. Qemu indicates it by both bits at the > same time, which is currently interpreted by u-boot as double key press. > > Fix this issue by setting first bit when only second is set (to support HW > models which indicate press only by second bit) and always clearing second > bit before processing to not report double space key press. > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Nokia RX-51: Remove CONFIG_UBI_SIZE
On Sun, Oct 09, 2022 at 03:12:09PM +0200, Pali Rohár wrote: > CONFIG_UBI_SIZE option is not used, so remove it. > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] Fix typo in CONFIG_USBNET_DEVADDR
On Sat, Oct 08, 2022 at 09:50:56AM -0500, nachopitt wrote: > From: Ignacio Zamora > > Fix typo that was causing the same feature to be > splitted into 2 different configuration options > > Replacing CONFIG_USBNET_DEVADDR with CONFIG_USBNET_DEV_ADDR > > Signed-off-by: Ignacio Zamora Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tools: k3_gen_x509_cert: Do not print SWRV on build
On Fri, Oct 07, 2022 at 03:35:31PM -0500, Andrew Davis wrote: > This matches the others here. > > Signed-off-by: Andrew Davis Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] smem: msm: add missing
On Fri, Oct 07, 2022 at 11:52:44AM +0200, Robert Marko wrote: > MSM SMEM driver is currently missing header and throws > the following compile error: > > drivers/smem/msm_smem.c: In function ‘qcom_smem_get_ptable’: > drivers/smem/msm_smem.c:635:71: error: ‘SZ_4K’ undeclared (first use in this > function) > 635 | ptable = smem->regions[0].virt_base + smem->regions[0].size - > SZ_4K; > > Signed-off-by: Robert Marko > Cc: luka.per...@sartura.hr Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] test: run setexpr test only on sandbox
On Sat, Oct 01, 2022 at 09:42:35PM +0200, Heinrich Schuchardt wrote: > The test relies on memory being available at 0x0. This in not valid for > many boards. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] firmware: scmi: fix the multi channel support with CCF
On Fri, Sep 30, 2022 at 09:36:38AM +0200, Patrick Delaunay wrote:
> When the CCF is activated, the dev->parent is not necessary
> the reference to SCMI transport and the function devm_scmi_of_get_channel
> failed for the registered SCMI clock, child for protocol@14,
> the channel is null and the SCMI clock driver crash for any operations.
>
> This patch changes the first parameter of the ops of_get_channel(),
> aligned with other process_msg() to pass directly the good reference,
> i.e. parent result of find_scmi_transport_device(dev)
> which return the reference of the scmi transport device.
>
> Fixes: 8e96801aa6a ("firmware: scmi: add multi-channel support")
> Signed-off-by: Patrick Delaunay
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] regmap: fix range checks
On Thu, Sep 29, 2022 at 10:27:06PM +, Heinrich Schuchardt wrote: > On the 32bit ARM sandbox 'dm ut dm_test_devm_regmap' fails with an abort. > This is due to incorrect range checks. > > On 32-bit systems the size of size_t and int is both 32 bit. The expression > (offset + val_len) is bound to overflow if offset == -1. Add an overflow > check. > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] cmd: ubi: Add 'ubi list' command for printing list of all UBI volumes
On Mon, Sep 12, 2022 at 11:38:55AM +0200, Pali Rohár wrote: > To allow easily iterate over all UBI volumes, add a new command which > either print all user UBI volumes on output or set them into env variable. > > As UBI volumes can have arbitrary name/label, in most cases it is useful to > iterate them by their numbers. This can be achieved by -numeric flag. > > This functionality is similar to already existing 'part list' command which > prints partitions on formatted block device. > > Signed-off-by: Pali Rohár Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 8/8] board: gw_ventana: enable MV88E6XXX DSA support
On Mon, Oct 10, 2022 at 09:39:44AM -0700, Tim Harvey wrote: > Add MV88E6XXX DSA support: > - update dt to provide internal MDIO bus and port handles. >U-Boot requires a more restrictive subset of the dt bindings >required by Linux for the sake of simplifying code > - update defconfig to remove old driver and enable new one > - replace mv88e61xx_hw_reset weak override with board_phy_config support >for register configuration that is outside the scope of the DSA driver > > Signed-off-by: Tim Harvey > Reviewed-by: Fabio Estevam > --- Reviewed-by: Vladimir Oltean
Re: [PATCH v6 4/8] net: dsa: allow rcv() and xmit() to be optional
Hi Simon, On Mon, Oct 10, 2022 at 04:25:29PM -0600, Simon Glass wrote: > Hi Tim, > > On Mon, 10 Oct 2022 at 10:40, Tim Harvey wrote: > > > > Allow rcv() and xmit() dsa driver ops to be optional in case a driver > > does not care to mangle a packet as in U-Boot only one network port is > > enabled at a time and thus no packet mangling is necessary. > > Should the tests be updated for this? Patch 3/8 serves as a runtime validation for this change. I don't believe that adding something more to test/dm/dsa.c is warranted, and I don't see exactly what can be added, either.
Re: [PATCH] distro_bootcmd: Always check for custom boot scripts first
On 2022-10-12, Tom Rini wrote:
> On Fri, Sep 02, 2022 at 01:06:16AM +0300, Andrey Skvortsov wrote:
>> If extlinux.conf is used, then it's not possible to customize boot
>> environment, because scripts are not loaded.
>> Usually it's possible to make some changes manually using command line
>> and save boot environment. But if exlinux.conf is loaded
>> from ext4 partition (for example on PinePhone), then environment are
>> not saved/loaded at boot time from boot partition and it's not
>> possible to persistently change boot environment without recompiling
>> u-boot.
>>
>> Signed-off-by: Andrey Skvortsov
>> ---
>>
>> include/config_distro_bootcmd.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/config_distro_bootcmd.h
>> b/include/config_distro_bootcmd.h
>> index 5506f3168f..7f4ef960a1 100644
>> --- a/include/config_distro_bootcmd.h
>> +++ b/include/config_distro_bootcmd.h
>> @@ -477,8 +477,8 @@
>> "echo Scanning ${devtype} " \
>> "${devnum}:${distro_bootpart}...; " \
>> "for prefix in ${boot_prefixes}; do " \
>> -"run scan_dev_for_extlinux; " \
>> "run scan_dev_for_scripts; " \
>> +"run scan_dev_for_extlinux; " \
>> "done;" \
>> SCAN_DEV_FOR_EFI \
>> "\0" \
>
> Reworking the CC list a bit, I think this works against the intent. If
> the distro provides extlinux.conf, that's what should be used, and
> customized by the user (through normal distro methods), rather than
> looking for a boot script that might be out of date / etc. Can you
> please elaborate on what you're seeing and trying to do on the
> PinePhone?
With my Debian hat on, I would prefer to not change default behaviors;
these have been present in this order for many years now. It is also
not uncommon (for better or worse) for a Debian system to have both a
boot script and an extlinux.conf, and possibly an EFI boot option, so
this would be a significant behavior change...
There are definitely cases where the flexibility of a bootscript might
be preferred, but in those cases, one should remove the extlinux.conf
and the packaging hooks that generate it (e.g. u-boot-menu package on
debian).
Alternately, adding another search for a bootscript at a different path
before extlinux.conf is loaded *might* be worth considering, but not
sure the extra complication and duplication is worth it...
Also curious on the status of "U-boot Standard Boot"
https://u-boot.readthedocs.io/en/latest/develop/bootstd.html which might
solve some of these problems?
live well,
vagrant
signature.asc
Description: PGP signature
[PATCH 1/1] powerpc: fix fdt_fixup_liodn_tbl_fman()
Builiding with GCC 12.2 fails:
arch/powerpc/cpu/mpc85xx/liodn.c: In function 'fdt_fixup_liodn_tbl_fman':
arch/powerpc/cpu/mpc85xx/liodn.c:340:35: error: the comparison will
always evaluate as 'false' for the address of 'compat'
will never be NULL [-Werror=address]
340 | if (tbl[i].compat == NULL)
|
Remove the superfluous check.
Fixes: 97a8d010e029 ("net/fman: Support both new and legacy FMan Compatibles")
Signed-off-by: Heinrich Schuchardt
---
arch/powerpc/cpu/mpc85xx/liodn.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/liodn.c b/arch/powerpc/cpu/mpc85xx/liodn.c
index a084002494..2d55916841 100644
--- a/arch/powerpc/cpu/mpc85xx/liodn.c
+++ b/arch/powerpc/cpu/mpc85xx/liodn.c
@@ -337,9 +337,6 @@ static void fdt_fixup_liodn_tbl_fman(void *blob,
for (i = 0; i < sz; i++) {
int off;
- if (tbl[i].compat == NULL)
- continue;
-
/* Try the new compatible first.
* If the node is missing, try the old.
*/
--
2.37.2
[PATCH 1/1] board: gateworks: gw_ventana: fix building with GCC 12.2
Building with GCC 12.2 results in an error
board/gateworks/gw_ventana/gw_ventana.c:636:68: error: the comparison
will always evaluate as 'true' for the address of 'pwm_padmux' will
never be NULL [-Werror=address]
636 | } else if (hwconfig_subarg_cmp(arg, "mode", "pwm")
&&
|
^~
Remove the superfluous check.
Signed-off-by: Heinrich Schuchardt
---
board/gateworks/gw_ventana/gw_ventana.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/board/gateworks/gw_ventana/gw_ventana.c
b/board/gateworks/gw_ventana/gw_ventana.c
index 99f52b9953..78d317d864 100644
--- a/board/gateworks/gw_ventana/gw_ventana.c
+++ b/board/gateworks/gw_ventana/gw_ventana.c
@@ -633,8 +633,7 @@ void setup_board_gpio(int board, struct ventana_board_info
*info)
ctrl);
gpio_requestf(cfg->gpio_param, "dio%d", i);
gpio_direction_input(cfg->gpio_param);
- } else if (hwconfig_subarg_cmp(arg, "mode", "pwm") &&
- cfg->pwm_padmux) {
+ } else if (hwconfig_subarg_cmp(arg, "mode", "pwm")) {
if (!cfg->pwm_param) {
printf("DIO%d: Error: pwm config invalid\n",
i);
--
2.37.2
Re: [PATCH] distro_bootcmd: Always check for custom boot scripts first
On Fri, Sep 02, 2022 at 01:06:16AM +0300, Andrey Skvortsov wrote:
> If extlinux.conf is used, then it's not possible to customize boot
> environment, because scripts are not loaded.
> Usually it's possible to make some changes manually using command line
> and save boot environment. But if exlinux.conf is loaded
> from ext4 partition (for example on PinePhone), then environment are
> not saved/loaded at boot time from boot partition and it's not
> possible to persistently change boot environment without recompiling
> u-boot.
>
> Signed-off-by: Andrey Skvortsov
> ---
>
> include/config_distro_bootcmd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index 5506f3168f..7f4ef960a1 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -477,8 +477,8 @@
> "echo Scanning ${devtype} " \
> "${devnum}:${distro_bootpart}...; " \
> "for prefix in ${boot_prefixes}; do " \
> - "run scan_dev_for_extlinux; " \
> "run scan_dev_for_scripts; " \
> + "run scan_dev_for_extlinux; " \
> "done;" \
> SCAN_DEV_FOR_EFI \
> "\0" \
Reworking the CC list a bit, I think this works against the intent. If
the distro provides extlinux.conf, that's what should be used, and
customized by the user (through normal distro methods), rather than
looking for a boot script that might be out of date / etc. Can you
please elaborate on what you're seeing and trying to do on the
PinePhone?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/3] arm: dts: stm32mp13: add support of RCC driver
Hi, On 10/12/22 14:33, Gabriel Fernandez wrote: Adds support of Clock and Reset drivers for STM32MP13 platform. Signed-off-by: Gabriel Fernandez --- arch/arm/dts/stm32mp13-u-boot.dtsi | 4 + arch/arm/dts/stm32mp131.dtsi | 119 +++-- arch/arm/dts/stm32mp133.dtsi | 4 +- arch/arm/dts/stm32mp13xf.dtsi | 3 +- 4 files changed, 52 insertions(+), 78 deletions(-) Reviewed-by: Patrick Delaunay Thanks Patrick
[PATCH 6/6] sunxi: add CherryPi-F1C200s support
The CherryPi F1C200s board is a small development board, featuring the
F1C200s with 64MB of co-packaged DRAM. It comes with two USB-C sockets,
of which one is connected to a USB-UART chip, that provides easy access
to UART1.
Beside the usual micro-SD card slot, the board comes with a SPI NAND
flash chip, which is not yet supported.
Signed-off-by: Andre Przywara
---
.../dts/suniv-f1c100s-cherrypi-f1c200s.dts| 45 +++
configs/cherrypi_f1c200s_defconfig| 11 +
2 files changed, 56 insertions(+)
create mode 100644 arch/arm/dts/suniv-f1c100s-cherrypi-f1c200s.dts
create mode 100644 configs/cherrypi_f1c200s_defconfig
diff --git a/arch/arm/dts/suniv-f1c100s-cherrypi-f1c200s.dts
b/arch/arm/dts/suniv-f1c100s-cherrypi-f1c200s.dts
new file mode 100644
index 000..f0ebcb6d893
--- /dev/null
+++ b/arch/arm/dts/suniv-f1c100s-cherrypi-f1c200s.dts
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2022 Arm Ltd.
+ * based on another DT, which is:
+ * Copyright 2018 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "suniv-f1c100s.dtsi"
+
+/ {
+ model = "Cherry Pi F1C200s";
+ compatible = "lctech,cherrypi-f1c200s", "allwinner,suniv-f1c100s";
+
+ aliases {
+ mmc0 = &mmc0;
+ serial0 = &uart1;
+ spi0 = &spi0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+&mmc0 {
+ broken-cd;
+ bus-width = <4>;
+ disable-wp;
+ status = "okay";
+ vmmc-supply = <®_vcc3v3>;
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pa_pins>;
+ status = "okay";
+};
diff --git a/configs/cherrypi_f1c200s_defconfig
b/configs/cherrypi_f1c200s_defconfig
new file mode 100644
index 000..306d363f485
--- /dev/null
+++ b/configs/cherrypi_f1c200s_defconfig
@@ -0,0 +1,11 @@
+CONFIG_ARM=y
+CONFIG_SYS_DCACHE_OFF=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_DEFAULT_DEVICE_TREE="suniv-f1c100s-cherrypi-f1c200s"
+CONFIG_SPL=y
+CONFIG_MACH_SUNIV=y
+CONFIG_DRAM_CLK=156
+CONFIG_DRAM_ZQ=0
+CONFIG_SUNXI_MINIMUM_DRAM_MB=64
+# CONFIG_VIDEO_SUNXI is not set
+CONFIG_CONS_INDEX=2
--
2.25.1
[PATCH 5/6] sunxi: f1c100: dtsi: add UART1 pins
The F1Cx00 SoCs connect the first PortA pins to UART1.
Add this to the SoC .dtsi, so boards can reference UART1 pins.
Signed-off-by: Andre Przywara
---
arch/arm/dts/suniv-f1c100s.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/suniv-f1c100s.dtsi b/arch/arm/dts/suniv-f1c100s.dtsi
index 0edc1724407..bc563c12e95 100644
--- a/arch/arm/dts/suniv-f1c100s.dtsi
+++ b/arch/arm/dts/suniv-f1c100s.dtsi
@@ -175,6 +175,11 @@
pins = "PE0", "PE1";
function = "uart0";
};
+
+ uart1_pa_pins: uart1-pa-pins {
+ pins = "PA2", "PA3";
+ function = "uart1";
+ };
};
timer@1c20c00 {
--
2.25.1
[PATCH 4/6] sunxi: f1c100: add UART1 support
Some boards use UART1 for its debug UART, so define the pins for the SPL
and the pinmux name and mux value for U-Boot proper.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/board.c | 4
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 62bb40b8c89..77216157908 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -147,6 +147,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV)
+ sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0);
+ sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0);
+ sunxi_gpio_set_pull(SUNXI_GPA(3), SUNXI_GPIO_PULL_UP);
#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUN5I)
sunxi_gpio_set_cfgpin(SUNXI_GPG(3), SUN5I_GPG_UART1);
sunxi_gpio_set_cfgpin(SUNXI_GPG(4), SUN5I_GPG_UART1);
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 9ce2bc1b3af..061104be056 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -245,6 +245,7 @@ static const struct sunxi_pinctrl_function
suniv_f1c100s_pinctrl_functions[] = {
#else
{ "uart0", 5 },/* PE0-PE1 */
#endif
+ { "uart1", 5 },/* PA0-PA3 */
};
static const struct sunxi_pinctrl_desc __maybe_unused
suniv_f1c100s_pinctrl_desc = {
--
2.25.1
[PATCH 3/6] sunxi: f1c100: move SKIP_LOWLEVEL_INIT_ONLY into Kconfig
So far we stated the lack of a lowlevel() init function for the F1C100s board by defining the respective SKIP_* symbol in the board's defconfig. However we don't expect any *board* to employ such low level code, so expect this to be never used for the ARMv5 Allwinner SoCs. Select the appropriate symbols in the Kconfig, so that we can remove them from the defconfig, and avoid putting them in future defconfigs for other boards. Signed-off-by: Andre Przywara --- arch/arm/mach-sunxi/Kconfig | 2 ++ configs/licheepi_nano_defconfig | 2 -- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 9aa66deb9fd..fc5d8bb3c19 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -185,6 +185,8 @@ config MACH_SUNIV select CPU_ARM926EJS select SUNXI_GEN_SUN6I select SUPPORT_SPL + select SKIP_LOWLEVEL_INIT_ONLY + select SPL_SKIP_LOWLEVEL_INIT_ONLY config MACH_SUN4I bool "sun4i (Allwinner A10)" diff --git a/configs/licheepi_nano_defconfig b/configs/licheepi_nano_defconfig index 14e6bcda927..09f1a19cdbe 100644 --- a/configs/licheepi_nano_defconfig +++ b/configs/licheepi_nano_defconfig @@ -1,6 +1,4 @@ CONFIG_ARM=y -CONFIG_SKIP_LOWLEVEL_INIT_ONLY=y -CONFIG_SPL_SKIP_LOWLEVEL_INIT_ONLY=y CONFIG_SYS_DCACHE_OFF=y CONFIG_ARCH_SUNXI=y CONFIG_DEFAULT_DEVICE_TREE="suniv-f1c100s-licheepi-nano" -- 2.25.1
[PATCH 2/6] sunxi: fix 32MB load address layout
The default load addresses for the various payloads (kernel, DT, ramdisk) on systems with just 32MB of DRAM have some issues: For a start the preceding comment doesn't match the actual values: apparently they were copied from the 64MB S3 layout, then halved, but since 0x5 is NOT the half of 0x10, they don't match up. Also those projected maximum sizes are quite restrictive: it's not easy to build a compressed kernel image with just 4MB. The only defconfig in mainline Linux that supports the F1C100s (the only 32MB user so far) creates a 6MB compressed / 15MB uncompressed kernel. Rearrange the default load addresses to accommodate such a kernel: we allow an 7MB/16MB kernel, and up to 5MB of ramdisk, stuffing the smaller binaries like the DTB towards the end, just before the relocated U-Boot. Shrink the size for DTB and scripts on the way, there is no need for allowing up to 512K for them. Signed-off-by: Andre Przywara --- include/configs/sunxi-common.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 416a0422861..fe90d55bd45 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -165,17 +165,17 @@ #elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 32) /* - * 32M RAM minus 1MB heap + 8MB for u-boot, stack, fb, etc. - * 8M uncompressed kernel, 4M compressed kernel, 512K fdt, - * 512K script, 512K pxe and the ramdisk at the end. + * 32M RAM minus 2.5MB for u-boot, heap, stack, etc. + * 16M uncompressed kernel, 7M compressed kernel, 128K fdt, 64K script, + * 128K DT overlay, 128K PXE and the ramdisk in the rest (max. 5MB) */ #define BOOTM_SIZE__stringify(0x170) -#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(050)) -#define FDT_ADDR_R__stringify(SDRAM_OFFSET(0C0)) -#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(0C5)) -#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(0D0)) -#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(0D5)) -#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(0D6)) +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(100)) +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(1d5)) +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(1d4)) +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(1d0)) +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1d2)) +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(180)) #else #error Need at least 32MB of DRAM. Please adjust load addresses. -- 2.25.1
[PATCH 1/6] sunxi: Kconfig: introduce SUNXI_MINIMUM_DRAM_MB
Traditionally we assumed that every Allwinner board would come with at least 256 MB of DRAM, and set our DRAM layout accordingly. This affected both the default load addresses, but also U-Boot's own address expectations (like being loaded at 160 MB). Some SoCs come with co-packaged DRAM, but only provide 32 or 64MB. So far we special-cased those *chips*, as there was only one chip per DRAM size. However new chips force us to take a more general approach. Introduce a Kconfig symbol, which provides the minimum DRAM size of the board. If nothing else is specified, we use 256 MB, and default to smaller values for those co-packaged SoCs. Then select the different DRAM maps according to this new symbol, so that different SoCs with the same DRAM size can share those definitions. Inspired by an idea from Icenowy. This is just refactoring: compiled for all boards before and after this patch: the binaries were identical. Signed-off-by: Andre Przywara --- Kconfig| 6 +++--- arch/arm/mach-sunxi/Kconfig| 12 boot/Kconfig | 4 ++-- include/configs/sunxi-common.h | 31 +-- 4 files changed, 34 insertions(+), 19 deletions(-) diff --git a/Kconfig b/Kconfig index 2ea735d38e4..d297513bac6 100644 --- a/Kconfig +++ b/Kconfig @@ -312,9 +312,9 @@ config SYS_MALLOC_LEN default 0x400 if SANDBOX default 0x200 if ARCH_ROCKCHIP || ARCH_OMAP2PLUS || ARCH_MESON default 0x20 if ARCH_BMIPS || X86 - default 0x12 if MACH_SUNIV - default 0x22 if MACH_SUN8I_V3S - default 0x402 if ARCH_SUNXI + default 0x402 if SUNXI_MINIMUM_DRAM_MB >= 256 + default 0x22 if SUNXI_MINIMUM_DRAM_MB >= 64 + default 0x12 if SUNXI_MINIMUM_DRAM_MB >= 32 default 0x40 help This defines memory to be allocated for Dynamic allocation diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 6b16f43494f..9aa66deb9fd 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -615,6 +615,18 @@ config SYS_BOARD config SYS_SOC default "sunxi" +config SUNXI_MINIMUM_DRAM_MB + int "minimum DRAM size" + default 32 if MACH_SUNIV + default 64 if MACH_SUN8I_V3S + default 256 + ---help--- + Minimum DRAM size expected on the board. Traditionally we assumed + 256 MB, so that U-Boot would load at 160MB. With co-packaged DRAM + we have smaller sizes, though, so that U-Boot's own load address and + the default payload addresses must be shifted down. + This is expected to be fixed by the SoC selection. + config UART0_PORT_F bool "UART0 on MicroSD breakout board" ---help--- diff --git a/boot/Kconfig b/boot/Kconfig index 6b3b8f072cb..45f86e946cd 100644 --- a/boot/Kconfig +++ b/boot/Kconfig @@ -499,8 +499,8 @@ config SYS_TEXT_BASE default 0x8080 if ARCH_OMAP2PLUS || ARCH_K3 default 0x8170 if MACH_SUNIV default 0x2a00 if MACH_SUN9I - default 0x42e0 if MACH_SUN8I_V3S - default 0x4a00 if ARCH_SUNXI + default 0x4a00 if SUNXI_MINIMUM_DRAM_MB >= 256 + default 0x42e0 if SUNXI_MINIMUM_DRAM_MB >= 64 hex "Text Base" help The address in memory that U-Boot will be running from, initially. diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 0f0ef4f64bb..416a0422861 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -135,7 +135,21 @@ #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(FE0)) #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(FF0)) -#elif defined(CONFIG_MACH_SUN8I_V3S) +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 256) +/* + * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc. + * 32M uncompressed kernel, 16M compressed kernel, 1M fdt, + * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end. + */ +#define BOOTM_SIZE__stringify(0xa00) +#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200)) +#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300)) +#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310)) +#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320)) +#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330)) +#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340)) + +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 64) /* * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc. * 16M uncompressed kernel, 8M compressed kernel, 1M fdt, @@ -149,7 +163,7 @@ #define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1B0)) #define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(1C0)) -#elif defined(CONFIG_MACH_SUNIV) +#elif (CONFIG_SUNXI_MINIMUM_DRAM_MB >= 32) /* * 32M RAM minus 1MB heap + 8MB for u-boot, stack, fb, etc. * 8M uncompressed kernel, 4M compressed kernel, 512K fdt, @@ -164,18 +178,7 @@ #define RAM
[PATCH 0/6] sunxi: improve F1C200s support
The Allwinner F1C200s is reportedly the same chip as the F1C100s, just with twice the amount of co-packaged DRAM: 64MB instead of just 32MB. U-Boot's F1C100 platform supported this quite naturally (since the DRAM size is auto-detected), but those better chips do not need to suffer from the same memory constraints as their smaller siblings. Patch 1/6 adds a notion of "minimum DRAM size" to Kconfig, so that we can select those smaller sizes independently from the actual SoC. This makes it easy to let the F1C200s use a more generous memory map, but also paves the way for the T113-S3 and D1s, later. Patch 2/6 uses the opportunity to improve the 32MB memory map, which was not really practical, and arguably also somewhat buggy. Patch 3/6 helps to keep the _defconfig files small, while patch 4+5 add support for the console on UART1. The final patch then adds a defconfig and .dts file for the CherryPi F1C200s board, which is used as an example for a F1C200s board. Please have a look and test, if possible. Cheers, Andre Andre Przywara (6): sunxi: Kconfig: introduce SUNXI_MINIMUM_DRAM_MB sunxi: fix 32MB load address layout sunxi: f1c100: move SKIP_LOWLEVEL_INIT_ONLY into Kconfig sunxi: f1c100: add UART1 support sunxi: f1c100: dtsi: add UART1 pins sunxi: add CherryPi-F1C200s support Kconfig | 6 +-- .../dts/suniv-f1c100s-cherrypi-f1c200s.dts| 45 + arch/arm/dts/suniv-f1c100s.dtsi | 5 ++ arch/arm/mach-sunxi/Kconfig | 14 ++ arch/arm/mach-sunxi/board.c | 4 ++ boot/Kconfig | 4 +- configs/cherrypi_f1c200s_defconfig| 11 + configs/licheepi_nano_defconfig | 2 - drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 + include/configs/sunxi-common.h| 49 ++- 10 files changed, 111 insertions(+), 30 deletions(-) create mode 100644 arch/arm/dts/suniv-f1c100s-cherrypi-f1c200s.dts create mode 100644 configs/cherrypi_f1c200s_defconfig -- 2.25.1
Re: [PATCH] mkimage: fit: Fix signing of configs with external data
On 10/12/22 08:59, Simon Glass wrote:
Hi Sean,
On Tue, 11 Oct 2022 at 15:52, Sean Anderson wrote:
Just like we exclude data-size, data-position, and data-offset from
fit_config_check_sig, we must exclude them while signing as well.
Fixes: 8edecd3110e ("fit: Fix verification of images with external data")
Fixes: c522949a29d ("rsa: sig: fix config signature check for fit with padding")
Signed-off-by: Sean Anderson
---
tools/image-host.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/image-host.c b/tools/image-host.c
index 698adfb3e1d..5ba6e3bbce0 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -917,7 +917,12 @@ static int fit_config_get_regions(const void *fit, int
conf_noffset,
int *region_countp, char **region_propp,
int *region_proplen)
{
- char * const exc_prop[] = {"data"};
+ char * const exc_prop[] = {
+ "data",
+ "data-size",
+ "data-position",
+ "data-offset"
+ };
struct strlist node_inc;
struct image_region *region;
struct fdt_region fdt_regions[100];
--
2.35.1.1320.gc452695387.dirty
It looks like we should be able to use FIT_DATA_POSITION_PROP (etc.) here?
Probably. fit_config_check_sig would also need to be updated.
--Sean
Re: [PATCH 2/3] clk: stm32mp13: introduce STM32MP13 RCC driver
Hi Gabriel, On 10/12/22 14:33, Gabriel Fernandez wrote: Introduce STM32MP13 RCC driver using Common Clock Framework. Signed-off-by: Gabriel Fernandez --- drivers/clk/stm32/Kconfig | 15 + drivers/clk/stm32/Makefile |2 + drivers/clk/stm32/clk-stm32-core.c | 349 ++ drivers/clk/stm32/clk-stm32-core.h | 154 +++ drivers/clk/stm32/clk-stm32mp13.c | 839 + drivers/clk/stm32/stm32mp13_rcc.h | 1751 6 files changed, 3110 insertions(+) create mode 100644 drivers/clk/stm32/clk-stm32-core.c create mode 100644 drivers/clk/stm32/clk-stm32-core.h create mode 100644 drivers/clk/stm32/clk-stm32mp13.c create mode 100644 drivers/clk/stm32/stm32mp13_rcc.h Reviewed-by: Patrick Delaunay Tested-by: Patrick Delaunay tested on STM32MP135F-DK board, stm32mp13_defconfig. I have a dependency with patch "firmware: scmi: fix the multi channel support with CCF" http://patchwork.ozlabs.org/project/uboot/patch/20220930093635.1.I38e66d79350b381b6059a6a80ce60c62f01f3894@changeid/ This this patch the SD-Card boot is OK with 2 traces : 1- because USBPHY is not yet present in DT: clk_register: failed to get ck_usbo_48m device (parent of usbo_k) 2- the console trace is pertubated by UART RESET introduction in DT => the UART FIFO is not flush before the probe after relocation and the reset of HW device Clocks: - MPU : 650 MHz - AXI : 266.500 MHz - PER : 24 MHz - DDR�Core: 165 devices, 23 uclasses, devicetree: board MMC: STM32 SD/MMC: 0 For information "clk dump" command cause a crash because the SCMI clock are not probed when clk_get_rate is used, but I prepare a patch to avoid this issue. Thanks Patrick
Re: [PATCH] image: fit: Fix not verifying data configuration
On 10/12/22 08:59, Simon Glass wrote:
Hi Sean,
On Tue, 11 Oct 2022 at 17:25, Sean Anderson wrote:
When reading data from a FIT image, we must verify the configuration we
get it from. This is because when we have a key with required = "conf",
the image does not need any particular signature or hash. The
configuration is the only required verification, so we must verify it.
Users of fit_get_data_node are liable to load unsigned data unless the
user has set required = "image". Even then, they are vulnerable to
mix-and-match attacks. This also affects other callers of
fit_image_verify which don't first call fit_config_verify, such as
source and imxtract. I don't think there is a backwards-compatible way
to fix these interfaces. Fundamentally, selecting data by image when
images are not required to be verified is unsafe.
Fixes: 37feaf2f727 ("image: fit: Add some helpers for getting data")
Signed-off-by: Sean Anderson
---
boot/image-fit.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 9c04ff78a15..632fd405e29 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1948,7 +1948,14 @@ int fit_get_data_node(const void *fit, const char
*image_uname,
int fit_get_data_conf_prop(const void *fit, const char *prop_name,
const void **data, size_t *size)
{
- int noffset = fit_conf_get_node(fit, NULL);
+ int ret, noffset = fit_conf_get_node(fit, NULL);
+
+ if (noffset < 0)
+ return noffset;
+
+ ret = fit_config_verify(fit, noffset);
+ if (ret)
+ return ret;
noffset = fit_conf_get_prop_node(fit, noffset, prop_name);
return fit_get_data_tail(fit, noffset, data, size);
--
2.35.1.1320.gc452695387.dirty
This is supposed to work by first verifying the configuration with
fit_config_verify(). After that, images in that configuration can be
freely loaded, verified by the hash that each image has.
Well, this function was made to replaces several cases where code loaded
a FIT image from somewhere, and then wanted to get data from an image
based on the configuration. Typically they only want to extract one
image, which is the common case for e.g. loading firmware. This idea of
this function is to make the common case of "find me the image data from
the default config and verify it" easier. If you look at the existing
code which uses this function, they do not verify the configuration
first. This is mainly because the original versions of this code which I
replaced with this function did not verify the configuration either.
So while the above process works for an integrated verification process,
like what is done by bootm, it doesn't really work for one-off loading
of image data. In particular, the requirements to make this secure
(using required = "image" for your key), are not default. When I was
trying to determine whether the source command would be OK to use to
load some configuration, I looked at it and saw that it did
fit_image_verify. I thought that was fine, but if you use required =
"config", then all that does is verify the hash. Same thing for
imxtract. Almost every instance of FIT loading outside of bootm has this
issue, which you can easily see when grepping for fit_config_verify. The
only other users are the SPL boot process, and fdt checksign. The latter
isn't even that useful, since you then need to re-parse the fit in hush
to determine the default configuration and determine the image names to
use.
Unfortunately, it's not trivial to determine whether any existing
systems are vulnerable to this issue. If they set required = "image",
then they can use source and imxtract (and any of the firmware loading
methods) however they want. But if they don't (and there is no option to
mkimage to do this, you have to use fdtset or something), then there is
a problem.
So we need to make sure that first step is taken in all code paths,
rather than adding it willy nilly.
If people don't add hashes (or perhaps signature if they want to use
more CPU time) for the images, then there is no protection. We could
add warnings or errors to mkimage for this case?
Yes, there probably should be a warning if you skip cryptographic hashes
on images with signed configs. But this is not really the root of the
issue.
--Sean
Re: [PATCH] image: fit: Fix not verifying data configuration
On 10/12/22 08:59, Simon Glass wrote:
Hi Sean,
On Tue, 11 Oct 2022 at 17:25, Sean Anderson wrote:
When reading data from a FIT image, we must verify the configuration we
get it from. This is because when we have a key with required = "conf",
the image does not need any particular signature or hash. The
configuration is the only required verification, so we must verify it.
Users of fit_get_data_node are liable to load unsigned data unless the
user has set required = "image". Even then, they are vulnerable to
mix-and-match attacks. This also affects other callers of
fit_image_verify which don't first call fit_config_verify, such as
source and imxtract. I don't think there is a backwards-compatible way
to fix these interfaces. Fundamentally, selecting data by image when
images are not required to be verified is unsafe.
Fixes: 37feaf2f727 ("image: fit: Add some helpers for getting data")
Signed-off-by: Sean Anderson
---
boot/image-fit.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 9c04ff78a15..632fd405e29 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1948,7 +1948,14 @@ int fit_get_data_node(const void *fit, const char
*image_uname,
int fit_get_data_conf_prop(const void *fit, const char *prop_name,
const void **data, size_t *size)
{
- int noffset = fit_conf_get_node(fit, NULL);
+ int ret, noffset = fit_conf_get_node(fit, NULL);
+
+ if (noffset < 0)
+ return noffset;
+
+ ret = fit_config_verify(fit, noffset);
+ if (ret)
+ return ret;
noffset = fit_conf_get_prop_node(fit, noffset, prop_name);
return fit_get_data_tail(fit, noffset, data, size);
--
2.35.1.1320.gc452695387.dirty
This is supposed to work by first verifying the configuration with
fit_config_verify(). After that, images in that configuration can be
freely loaded, verified by the hash that each image has.
Well, this function was made to replaces several cases where code loaded
a FIT image from somewhere, and then wanted to get data from an image
based on the configuration. Typically they only want to extract one
image, which is the common case for e.g. loading firmware. This idea of
this function is to make the common case of "find me the image data from
the default config and verify it" easier. If you look at the existing
code which uses this function, they do not verify the configuration
first. This is mainly because the original versions of this code which I
replaced with this function did not verify the configuration either.
So while the above process works for an integrated verification process,
like what is done by bootm, it doesn't really work for one-off loading
of image data. In particular, the requirements to make this secure
(using required = "image" for your key), are not default. When I was
trying to determine whether the source command would be OK to use to
load some configuration, I looked at it and saw that it did
fit_image_verify. I thought that was fine, but if you use required =
"config", then all that does is verify the hash. Same thing for
imxtract. Almost every instance of FIT loading outside of bootm has this
issue, which you can easily see when grepping for fit_config_verify. The
only other users are the SPL boot process, and fdt checksign. The latter
isn't even that useful, since you then need to re-parse the fit in hush
to determine the default configuration and determine the image names to
use.
Unfortunately, it's not trivial to determine whether any existing
systems are vulnerable to this issue. If they set required = "image",
then they can use source and imxtract (and any of the firmware loading
methods) however they want. But if they don't (and there is no option to
mkimage to do this, you have to use fdtset or something), then there is
a problem.
So we need to make sure that first step is taken in all code paths,
rather than adding it willy nilly.
If people don't add hashes (or perhaps signature if they want to use
more CPU time) for the images, then there is no protection. We could
add warnings or errors to mkimage for this case?
Yes, there probably should be a warning if you skip cryptographic hashes
on images with signed configs. But this is not really the root of the
issue.
--Sean
[PATCH] sunxi: defconfig: Add X96 Mate TV box
The X96 Mate TV box is a TV box with the Allwinner H616 SoC. It is available with up to 4GB of DRAM and 64GB eMMC. The DRAM chips require a different configuration when compared to the OrangePi Zero2, we must not use read/write training and write leveling. Add a defconfig for the box, so that we can easily build U-Boot for it. We synced the .dts file already from the kernel tree. Signed-off-by: Andre Przywara --- configs/x96_mate_defconfig | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 configs/x96_mate_defconfig diff --git a/configs/x96_mate_defconfig b/configs/x96_mate_defconfig new file mode 100644 index 000..4276f4f543b --- /dev/null +++ b/configs/x96_mate_defconfig @@ -0,0 +1,15 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h616-x96-mate" +CONFIG_SPL=y +CONFIG_DRAM_SUN50I_H616_READ_CALIBRATION=y +CONFIG_MACH_SUN50I_H616=y +CONFIG_MMC0_CD_PIN="PF6" +CONFIG_R_I2C_ENABLE=y +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_SPL_I2C=y +CONFIG_SPL_SYS_I2C_LEGACY=y +CONFIG_SYS_I2C_MVTWSI=y +CONFIG_SYS_I2C_SLAVE=0x7f +CONFIG_SYS_I2C_SPEED=40 +CONFIG_SUPPORT_EMMC_BOOT=y -- 2.25.1
Re: [PATCH 1/3] dt-bindings: stm32mp13: add clock & reset support for STM32MP13
Hi Gabriel, On 10/12/22 14:33, Gabriel Fernandez wrote: Add support of stm32mp13 DT bindings of clock and reset. Signed-off-by: Gabriel Fernandez --- MAINTAINERS | 2 + include/dt-bindings/clock/stm32mp13-clks.h | 229 +++ include/dt-bindings/reset/stm32mp13-resets.h | 100 3 files changed, 331 insertions(+) create mode 100644 include/dt-bindings/clock/stm32mp13-clks.h create mode 100644 include/dt-bindings/reset/stm32mp13-resets.h Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH 2/3] timer-uclass: relocate ops pointers for CONFIG_NEEDS_MANUAL_RELOC
Hi Simon, On 10/12/22 15:59, Simon Glass wrote: On Tue, 11 Oct 2022 at 23:37, Ovidiu Panait wrote: Relocate timer_ops pointers when CONFIG_NEEDS_MANUAL_RELOC is enabled. The (gd->flags & GD_FLG_RELOC) check was added to make sure the reloc_done logic works for drivers that use DM_FLAG_PRE_RELOC. Signed-off-by: Ovidiu Panait --- drivers/timer/timer-uclass.c | 14 ++ 1 file changed, 14 insertions(+) Reviewed-by: Simon Glass Which (broken) toolchain are you using? Microblaze and m68k still use CONFIG_NEEDS_MANUAL_RELOC=y by default. I was testing on microblaze. Ovidiu
Re: [PATCH 2/2] buildman: Add --allow-missing-binaries flag to build with BINMAN_ALLOW_MISSING=1
On Wed, Oct 12, 2022 at 06:59:35AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Tue, 11 Oct 2022 at 10:22, Tom Rini wrote:
> >
> > On Mon, Oct 10, 2022 at 05:48:55PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Mon, 10 Oct 2022 at 09:18, Tom Rini wrote:
> > > >
> > > > Add a new flag to buildman so that we will in turn pass
> > > > BINMAN_ALLOW_MISSING=1 to 'make'. Make use of this flag in CI.
> > > >
> > > > Cc: Rasmus Villemoes
> > > > Cc: Simon Glass
> > > > Signed-off-by: Tom Rini
> > > > ---
> > > > .azure-pipelines.yml| 2 +-
> > > > .gitlab-ci.yml | 6 +++---
> > > > tools/buildman/builder.py | 5 -
> > > > tools/buildman/builderthread.py | 2 ++
> > > > tools/buildman/cmdline.py | 3 +++
> > > > tools/buildman/control.py | 3 ++-
> > > > 6 files changed, 15 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > > index f200b40dbb24..c932c2b3c619 100644
> > > > --- a/.azure-pipelines.yml
> > > > +++ b/.azure-pipelines.yml
> > > > @@ -553,7 +553,7 @@ stages:
> > > >cat << "EOF" >> build.sh
> > > >if [[ "${BUILDMAN}" != "" ]]; then
> > > >ret=0;
> > > > - tools/buildman/buildman -o /tmp -P -E -W ${BUILDMAN}
> > > > ${OVERRIDE} || ret=$?;
> > > > + tools/buildman/buildman -o /tmp -P -E -W
> > > > --allow-missing-binaries ${BUILDMAN} ${OVERRIDE} || ret=$?;
> > >
> > > This is fine for CI.
> >
> > I think one of the issues here is we need to agree on the common use
> > cases. I don't think most people use buildman to build, they use make.
>
> OK. With the new -I/--ide flag I use buildman directly for single
> builds on some machines at least.
> > Of the people that do use buildman, how many aren't already using a
> > wrapper script? I know I always do.
>
> I don't know, but I always use buildman directly for build-testing
> multiple boards.
I've been building for single machines with buildman for years, with
--keep being passed to my wrapper script. And always use it for multiple
boards. But this is you and I, to borrow a meme, we're builders georg
and are outliers who should perhaps not be counted.
> > Can we also not just deal with
> > setting this flag in ~/.buildman ? Would it Just Work as:
> > [builder]
> > allow-missing-binaries = True
> >
> > Or is more code needed?
>
> Yes I think that would work, although I think we would need two flags,
> one for building current source (where people might want it off) and
> another for building multiple boards (when presumably you want it on).
I'm not sure. It's not "always use fake binaries" it's allow them. I'm
honestly not sure how to tell buildman to use external binaries
correctly, that's one of the cases where I use a different script that
just manages output directories and known-good additional binaries.
> ...although I don't see the advantage of this approach over the series
> I sent. Basically, the build should fail if there are missing blobs.
> The only question is whether we want to handle missing blobs by:
>
> 1. failing immediately when we see the first missing blob (your approach)
> 2. failing at the end after all binman processing is done (my approach)
>
> The nice thing about 2 is that the build does complete and the exit
> code lets buildman decide what to do afterwards (i.e. we can make
> missing blobs be an error or a warning).
>
> Option 1 has the benefit that we don't do any of the blob handling, so
> it just dies right away. Perhaps this is a philosophical question, but
> it is a little subtle and I'm not actually sure people would notice
> the difference so long as they get the errors as expected.
The way I'm thinking of it is there's two cases. The first case is
someone who is testing on the hardware that requires these files. Stop
ASAP because they either will know they forgot to pass X/Y/Z files or
they'll re-read the board instructions page and see oh, they need to
grab binaries X/Y/Z too. Waiting to collect up missing file errors
doesn't save time. It's also still hugely likely I believe that they're
using make and not buildman.
The second case is someone building multiple boards at once to
build-check (but not run-time check) something in multiple places. This
is where passing a specific failure exit code can be helpful, yes.
> BTW we need a one-character flag if we do this as it will be a very
> common requirement.
Sadly both -a and -A are taken. We could use -M for Missing ?
> > > But having to provide a flag to do build testing seems like the tail
> > > is wagging the dog. Boards should be discouraged to use blobs and we
> > > don't want to make it hard for everyone else (who doesn't have the
> > > blobs) to test whether their patch breaks a build.
> >
> > I'm not sure this ends up being a common case. If someone is build
> > testing for something they can't run test, the error is going to be
> > after whatever they compile-test
Re: [PATCH 4/5] binman: Use an exit code when blobs are missing
On Wed, Oct 12, 2022 at 06:59:21AM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 11 Oct 2022 at 15:05, Tom Rini wrote: > > > > On Mon, Oct 10, 2022 at 04:25:36PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 10 Oct 2022 at 14:41, Tom Rini wrote: > > > > > > > > On Mon, Oct 10, 2022 at 02:00:31PM -0600, Simon Glass wrote: > > > > > > > > > At present binman returns success when told to handle missing blobs. > > > > > This is confusing this in fact the resulting image cannot work. > > > > > > > > > > Use exit code 103 to signal this problem, with a -W option to convert > > > > > it to a warning. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > I'm still not sure I like this, rather than changing the default "make" > > > > behavior. > > > > > > I did change that, in the sense that 'make' now fails if there are > > > missing blobs. > > > > > > > And then it gets me a bit worried that we have CI not doing > > > > some other things "right" as we don't want to ignore warnings in CI, we > > > > want warnings to become errors so that new warnings don't make it > > > > in-tree. > > > > > > That would be quite a big effort, and unrelated to this series. Here > > > are some warning types I'm aware of: > > > > > > - migration > > > - device tree > > > - compiler > > > - missing blobs > > > > > > Do we need a per-board whitelist for warnings? It seems pretty tricky to > > > me. > > > > > > It is true that warnings are ignored in CI and this does create > > > problems...I'd love to make them into errors if we can. > > > > This is I guess also a related concern. When I say warnings, I mean > > C compiler warnings. That we have flags to suppress "warnings" that are > > other kinds of valid warnings is at least a little confusing. > > Yes. But of course binman doesn't have any other kind of warning, so > so long as we don't propagate that flag further, it makes sense I > think. > > The warnings in U-Boot are at least somewhat out of control IMO, as > per my list above. Well, lets dig down in to those for a minute? For "missing blobs", if we're passing the "fake these blobs" flag AND we don't ever default to passing that flag in regular build rules, I can see making it so that we only see those messages either when we don't pass the fake these blobs flag or we have a verbose option set. For device tree warnings? I think we're mirroring the kernel still in terms of ignoring problems so it's likely a matter of poking board maintainers to resync their trees and/or address the warnings upstream too (which upstream would appreciate). For migration warnings, well, which? Are there some that can be easily done and compile tested? Looking at the Makefile atm, I think the CONFIG_DM migration warning logic can go away as there's no boards missing that. There's nothing in the "this passed so long ago we should delete boards" list, but it would be a good idea (so I'll fire off some builds in a moment) to see who trips up on each and email maintainers. -- Tom signature.asc Description: PGP signature
Re: [PATCH] Kconfig: distro: Use imply instead of select for CMD_FAT
On Wed, Oct 12, 2022 at 07:04:24AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 12 Oct 2022 at 06:50, Tom Rini wrote: > > > > On Fri, Sep 02, 2022 at 11:28:49AM +0800, Jit Loon Lim wrote: > > > > > From: Tien Fong Chee > > > > > > Using imply instead of select for CMD_FAT so overwritten is allowed in > > > later configuration. > > > > > > Signed-off-by: Tien Fong Chee > > > --- > > > Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/Kconfig b/Kconfig > > > index 991b260182..71374980e9 100644 > > > --- a/Kconfig > > > +++ b/Kconfig > > > @@ -201,7 +201,7 @@ config DISTRO_DEFAULTS > > > select CMD_ENV_EXISTS > > > select CMD_EXT2 > > > select CMD_EXT4 > > > - select CMD_FAT > > > + imply CMD_FAT > > > select CMD_FS_GENERIC > > > select CMD_PART if PARTITIONS > > > select CMD_PING if CMD_NET > > > > NAK, at least without explaining what the use case here is. A big part > > of generic distro work is "oh, you have that FAT32 ESP to use". > > Isn't that just for EFI? > > In general I try to use 'imply' so it is possible for a board to > disable the option. Calling it an ESP? Yes. Expecting the first partition to be FAT? No, that's a forever-and-ever thing distros have been expecting on x86 and want to see everyone else do too (so their installer logic doesn't have to get further complex). -- Tom signature.asc Description: PGP signature
Re: Bad Data CRC
Thanks Fabio and Simon, find attached the log picture. When I changed the size of the one partition in the kernel, I got this message. Does the calculation of CRC in uboot depended on the size ? [image: image.png] Thanks, Aubin On Wed, 12 Oct 2022 at 15:05, Fabio Estevam wrote: > On Mon, Oct 10, 2022 at 6:31 PM momo aubin wrote: > > > > Hello Simon, > > > > My board boots well . When I added the second partition into my kernel I > > got this message > > *Verifying Checksum ... Bad Data CRC* > > what could be the root cause ? > > Try to run "saveenv", >
Re: Bad Data CRC
On Mon, Oct 10, 2022 at 6:31 PM momo aubin wrote: > > Hello Simon, > > My board boots well . When I added the second partition into my kernel I > got this message > *Verifying Checksum ... Bad Data CRC* > what could be the root cause ? Try to run "saveenv",
Re: [PATCH] Kconfig: distro: Use imply instead of select for CMD_FAT
Hi Tom, On Wed, 12 Oct 2022 at 06:50, Tom Rini wrote: > > On Fri, Sep 02, 2022 at 11:28:49AM +0800, Jit Loon Lim wrote: > > > From: Tien Fong Chee > > > > Using imply instead of select for CMD_FAT so overwritten is allowed in > > later configuration. > > > > Signed-off-by: Tien Fong Chee > > --- > > Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/Kconfig b/Kconfig > > index 991b260182..71374980e9 100644 > > --- a/Kconfig > > +++ b/Kconfig > > @@ -201,7 +201,7 @@ config DISTRO_DEFAULTS > > select CMD_ENV_EXISTS > > select CMD_EXT2 > > select CMD_EXT4 > > - select CMD_FAT > > + imply CMD_FAT > > select CMD_FS_GENERIC > > select CMD_PART if PARTITIONS > > select CMD_PING if CMD_NET > > NAK, at least without explaining what the use case here is. A big part > of generic distro work is "oh, you have that FAT32 ESP to use". Isn't that just for EFI? In general I try to use 'imply' so it is possible for a board to disable the option. Regards, Simon
Re: [RESEND PATCH 2/2] splash: get devpart from environment variable
Hi Julien,
On Wed, 12 Oct 2022 at 05:38, Julien Masson wrote:
>
> By default several types of splash locations are supported and the
> user can select one of them through environment var (splashsource).
>
> However the devpart is still hardcoded and we cannot change it from
> the environment.
>
> This patch add the support of "splashdevpart" which allow the user to
> set the devpart though this environment variable.
>
> Example: image located in splashscreen partition (MMC as raw)
> ```
> splashsource=mmc_raw
> splashdevpart=0#splashscreen
> ```
>
> Signed-off-by: Julien Masson
> ---
> common/splash_source.c | 5 +
> 1 file changed, 5 insertions(+)
Reviewed-by: Simon Glass
>
> diff --git a/common/splash_source.c b/common/splash_source.c
> index b4bf6f1336..1f99f44f78 100644
> --- a/common/splash_source.c
> +++ b/common/splash_source.c
> @@ -451,6 +451,7 @@ int splash_source_load(struct splash_location *locations,
> uint size)
> {
> struct splash_location *splash_location;
> char *env_splashimage_value;
> + char *env_splashdevpart_value;
How about just 'devpar' as it is shorter and easier to read?
> u32 bmp_load_addr;
>
> env_splashimage_value = env_get("splashimage");
> @@ -467,6 +468,10 @@ int splash_source_load(struct splash_location
> *locations, uint size)
> if (!splash_location)
> return -EINVAL;
>
> + env_splashdevpart_value = env_get("splashdevpart");
> + if (env_splashdevpart_value)
> + splash_location->devpart = env_splashdevpart_value;
> +
> if (splash_location->flags == SPLASH_STORAGE_RAW)
> return splash_load_raw(splash_location, bmp_load_addr);
> else if (splash_location->flags == SPLASH_STORAGE_FS)
> --
> 2.37.3
>
Regards,
Simon
Re: [PATCH 1/3] timer-uclass: add timer_get_ops() macro
On Tue, 11 Oct 2022 at 23:37, Ovidiu Panait wrote: > > Align timer uclass with the other subsystems and provide a timer_get_ops() > convenience macro. > > Using this instead of the generic device_get_ops() also prevents > -Wdiscarded-qualifiers warnings when used with non-const variables. > > Signed-off-by: Ovidiu Panait > --- > > drivers/timer/timer-uclass.c | 2 +- > include/timer.h | 2 ++ > 2 files changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH] image: fit: Fix not verifying data configuration
Hi Sean,
On Tue, 11 Oct 2022 at 17:25, Sean Anderson wrote:
>
> When reading data from a FIT image, we must verify the configuration we
> get it from. This is because when we have a key with required = "conf",
> the image does not need any particular signature or hash. The
> configuration is the only required verification, so we must verify it.
>
> Users of fit_get_data_node are liable to load unsigned data unless the
> user has set required = "image". Even then, they are vulnerable to
> mix-and-match attacks. This also affects other callers of
> fit_image_verify which don't first call fit_config_verify, such as
> source and imxtract. I don't think there is a backwards-compatible way
> to fix these interfaces. Fundamentally, selecting data by image when
> images are not required to be verified is unsafe.
>
> Fixes: 37feaf2f727 ("image: fit: Add some helpers for getting data")
> Signed-off-by: Sean Anderson
> ---
>
> boot/image-fit.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/boot/image-fit.c b/boot/image-fit.c
> index 9c04ff78a15..632fd405e29 100644
> --- a/boot/image-fit.c
> +++ b/boot/image-fit.c
> @@ -1948,7 +1948,14 @@ int fit_get_data_node(const void *fit, const char
> *image_uname,
> int fit_get_data_conf_prop(const void *fit, const char *prop_name,
>const void **data, size_t *size)
> {
> - int noffset = fit_conf_get_node(fit, NULL);
> + int ret, noffset = fit_conf_get_node(fit, NULL);
> +
> + if (noffset < 0)
> + return noffset;
> +
> + ret = fit_config_verify(fit, noffset);
> + if (ret)
> + return ret;
>
> noffset = fit_conf_get_prop_node(fit, noffset, prop_name);
> return fit_get_data_tail(fit, noffset, data, size);
> --
> 2.35.1.1320.gc452695387.dirty
>
This is supposed to work by first verifying the configuration with
fit_config_verify(). After that, images in that configuration can be
freely loaded, verified by the hash that each image has.
So we need to make sure that first step is taken in all code paths,
rather than adding it willy nilly.
If people don't add hashes (or perhaps signature if they want to use
more CPU time) for the images, then there is no protection. We could
add warnings or errors to mkimage for this case?
Regards,
Simon
[PATCH v2 1/1] riscv: support building double-float modules
The riscv32 toolchain for GCC-12 provided by kernel.org contains libgcc.a compiled for double-float. To link to it we have to adjust how we build U-Boot. As U-Boot actually does not use floating point at all this should not make a significant difference for the produced binaries. Signed-off-by: Heinrich Schuchardt Reviewed-by: Rick Chen Reviewed-by: Leo Yu-Chi Liang --- v2: use ABI lp64d for riscv64 fix typos --- arch/riscv/Kconfig | 15 +++ arch/riscv/Makefile | 15 --- 2 files changed, 27 insertions(+), 3 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 32a90b83b5..8f9578171d 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -152,6 +152,21 @@ config RISCV_ISA_C when building U-Boot, which results in compressed instructions in the U-Boot binary. +config RISCV_ISA_F + bool "Standard extension for Single-Precision Floating Point" + default y + help + Adds "F" to the ISA string passed to the compiler. + +config RISCV_ISA_D + bool "Standard extension for Double-Precision Floating Point" + depends on RISCV_ISA_F + default y + help + Adds "D" to the ISA string passed to the compiler and changes the + riscv32 ABI from ilp32 to ilp32d and the riscv64 ABI from lp64 to + lp64d. + config RISCV_ISA_A def_bool y diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 53d1194ffb..4963b5109b 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -5,15 +5,22 @@ ifeq ($(CONFIG_ARCH_RV64I),y) ARCH_BASE = rv64im - ABI = lp64 + ABI_BASE = lp64 endif ifeq ($(CONFIG_ARCH_RV32I),y) ARCH_BASE = rv32im - ABI = ilp32 + ABI_BASE = ilp32 endif ifeq ($(CONFIG_RISCV_ISA_A),y) ARCH_A = a endif +ifeq ($(CONFIG_RISCV_ISA_F),y) + ARCH_F = f +endif +ifeq ($(CONFIG_RISCV_ISA_D),y) + ARCH_D = d + ABI_D = d +endif ifeq ($(CONFIG_RISCV_ISA_C),y) ARCH_C = c endif @@ -24,7 +31,9 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) CMODEL = medany endif -RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_C) + +RISCV_MARCH = $(ARCH_BASE)$(ARCH_A)$(ARCH_F)$(ARCH_D)$(ARCH_C) +ABI = $(ABI_BASE)$(ABI_D) # Newer binutils versions default to ISA spec version 20191213 which moves some # instructions from the I extension to the Zicsr and Zifencei extensions. -- 2.37.2
Re: [PATCH 2/2] buildman: Add --allow-missing-binaries flag to build with BINMAN_ALLOW_MISSING=1
Hi Tom,
On Tue, 11 Oct 2022 at 10:22, Tom Rini wrote:
>
> On Mon, Oct 10, 2022 at 05:48:55PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 10 Oct 2022 at 09:18, Tom Rini wrote:
> > >
> > > Add a new flag to buildman so that we will in turn pass
> > > BINMAN_ALLOW_MISSING=1 to 'make'. Make use of this flag in CI.
> > >
> > > Cc: Rasmus Villemoes
> > > Cc: Simon Glass
> > > Signed-off-by: Tom Rini
> > > ---
> > > .azure-pipelines.yml| 2 +-
> > > .gitlab-ci.yml | 6 +++---
> > > tools/buildman/builder.py | 5 -
> > > tools/buildman/builderthread.py | 2 ++
> > > tools/buildman/cmdline.py | 3 +++
> > > tools/buildman/control.py | 3 ++-
> > > 6 files changed, 15 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > index f200b40dbb24..c932c2b3c619 100644
> > > --- a/.azure-pipelines.yml
> > > +++ b/.azure-pipelines.yml
> > > @@ -553,7 +553,7 @@ stages:
> > >cat << "EOF" >> build.sh
> > >if [[ "${BUILDMAN}" != "" ]]; then
> > >ret=0;
> > > - tools/buildman/buildman -o /tmp -P -E -W ${BUILDMAN}
> > > ${OVERRIDE} || ret=$?;
> > > + tools/buildman/buildman -o /tmp -P -E -W
> > > --allow-missing-binaries ${BUILDMAN} ${OVERRIDE} || ret=$?;
> >
> > This is fine for CI.
>
> I think one of the issues here is we need to agree on the common use
> cases. I don't think most people use buildman to build, they use make.
OK. With the new -I/--ide flag I use buildman directly for single
builds on some machines at least.
> Of the people that do use buildman, how many aren't already using a
> wrapper script? I know I always do.
I don't know, but I always use buildman directly for build-testing
multiple boards.
> Can we also not just deal with
> setting this flag in ~/.buildman ? Would it Just Work as:
> [builder]
> allow-missing-binaries = True
>
> Or is more code needed?
Yes I think that would work, although I think we would need two flags,
one for building current source (where people might want it off) and
another for building multiple boards (when presumably you want it on).
...although I don't see the advantage of this approach over the series
I sent. Basically, the build should fail if there are missing blobs.
The only question is whether we want to handle missing blobs by:
1. failing immediately when we see the first missing blob (your approach)
2. failing at the end after all binman processing is done (my approach)
The nice thing about 2 is that the build does complete and the exit
code lets buildman decide what to do afterwards (i.e. we can make
missing blobs be an error or a warning).
Option 1 has the benefit that we don't do any of the blob handling, so
it just dies right away. Perhaps this is a philosophical question, but
it is a little subtle and I'm not actually sure people would notice
the difference so long as they get the errors as expected.
BTW we need a one-character flag if we do this as it will be a very
common requirement.
>
> > But having to provide a flag to do build testing seems like the tail
> > is wagging the dog. Boards should be discouraged to use blobs and we
> > don't want to make it hard for everyone else (who doesn't have the
> > blobs) to test whether their patch breaks a build.
>
> I'm not sure this ends up being a common case. If someone is build
> testing for something they can't run test, the error is going to be
> after whatever they compile-tested was compiled/linked, and if they're
> testing everything it's via CI.
I don't think people will be able to tell that. The 'make' fails with
an error so it looks like a failure. It happens to be at the end in
the binman step, but it is still a build failure.
My overall concern is constantly having to rerun a build because I
forgot to add a flag, when I don't have the blobs for the boards
anyway. Like the LTO thing that cost 4 seconds on every build, that
could get really annoying. Blobs should not get in the way of
development.
Regards,
Simon
Re: [RESEND PATCH 1/2] splash: support raw image from MMC
HI Julien,
On Wed, 12 Oct 2022 at 05:38, Julien Masson wrote:
>
> The user has now the choice to specify the splash location in the MMC
> as a raw storage.
>
> Signed-off-by: Julien Masson
> ---
> common/splash.c| 6 ++
> common/splash_source.c | 29 +
> 2 files changed, 35 insertions(+)
>
> diff --git a/common/splash.c b/common/splash.c
> index 0e520cc103..5206e35f74 100644
> --- a/common/splash.c
> +++ b/common/splash.c
> @@ -39,6 +39,12 @@ static struct splash_location default_splash_locations[] =
> {
> .flags = SPLASH_STORAGE_FS,
> .devpart = "0:1",
> },
> + {
> + .name = "mmc_raw",
> + .storage = SPLASH_STORAGE_MMC,
> + .flags = SPLASH_STORAGE_RAW,
> + .devpart = "0:1",
> + },
> {
> .name = "usb_fs",
> .storage = SPLASH_STORAGE_USB,
> diff --git a/common/splash_source.c b/common/splash_source.c
> index 87e55a54f8..b4bf6f1336 100644
> --- a/common/splash_source.c
> +++ b/common/splash_source.c
> @@ -65,6 +65,33 @@ static int splash_nand_read_raw(u32 bmp_load_addr, int
> offset, size_t read_size)
> }
> #endif
>
> +#ifdef CONFIG_CMD_MMC
> +static int splash_mmc_read_raw(u32 bmp_load_addr, struct splash_location
> *location,
> + size_t read_size)
> +{
> + struct disk_partition partition;
> + struct blk_desc *desc;
> + lbaint_t blkcnt;
> + int ret, n;
> +
> + ret = part_get_info_by_dev_and_name_or_num("mmc", location->devpart,
> &desc,
> + &partition, 1);
> + if (ret < 0)
> + return ret;
> +
> + blkcnt = DIV_ROUND_UP(read_size, partition.blksz);
> + n = blk_dread(desc, partition.start, blkcnt, (void
> *)(uintptr_t)bmp_load_addr);
> +
> + return (n == blkcnt) ? 0 : -EINVAL;
-EIO would be better
> +}
> +#else
> +static int splash_mmc_read_raw(u32 bmp_load_addr, int offset, size_t
> read_size)
> +{
> + debug("%s: mmc support not available\n", __func__);
> + return -ENOSYS;
Rather than the #ifdef you should be able to put these two lines in
the first function. Does patman not warn you about this sort of thing?
> +}
> +#endif
> +
> static int splash_storage_read_raw(struct splash_location *location,
>u32 bmp_load_addr, size_t read_size)
> {
> @@ -75,6 +102,8 @@ static int splash_storage_read_raw(struct splash_location
> *location,
>
> offset = location->offset;
> switch (location->storage) {
> + case SPLASH_STORAGE_MMC:
> + return splash_mmc_read_raw(bmp_load_addr, location,
> read_size);
> case SPLASH_STORAGE_NAND:
> return splash_nand_read_raw(bmp_load_addr, offset, read_size);
> case SPLASH_STORAGE_SF:
> --
> 2.37.3
>
Regards,
SImon
Re: [PATCH] mkimage: fit: Fix signing of configs with external data
Hi Sean,
On Tue, 11 Oct 2022 at 15:52, Sean Anderson wrote:
>
> Just like we exclude data-size, data-position, and data-offset from
> fit_config_check_sig, we must exclude them while signing as well.
>
> Fixes: 8edecd3110e ("fit: Fix verification of images with external data")
> Fixes: c522949a29d ("rsa: sig: fix config signature check for fit with
> padding")
> Signed-off-by: Sean Anderson
> ---
>
> tools/image-host.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/image-host.c b/tools/image-host.c
> index 698adfb3e1d..5ba6e3bbce0 100644
> --- a/tools/image-host.c
> +++ b/tools/image-host.c
> @@ -917,7 +917,12 @@ static int fit_config_get_regions(const void *fit, int
> conf_noffset,
> int *region_countp, char **region_propp,
> int *region_proplen)
> {
> - char * const exc_prop[] = {"data"};
> + char * const exc_prop[] = {
> + "data",
> + "data-size",
> + "data-position",
> + "data-offset"
> + };
> struct strlist node_inc;
> struct image_region *region;
> struct fdt_region fdt_regions[100];
> --
> 2.35.1.1320.gc452695387.dirty
>
It looks like we should be able to use FIT_DATA_POSITION_PROP (etc.) here?
Regards,
Simon
Re: [PATCH 2/3] timer-uclass: relocate ops pointers for CONFIG_NEEDS_MANUAL_RELOC
On Tue, 11 Oct 2022 at 23:37, Ovidiu Panait wrote: > > Relocate timer_ops pointers when CONFIG_NEEDS_MANUAL_RELOC is enabled. > > The (gd->flags & GD_FLG_RELOC) check was added to make sure the reloc_done > logic works for drivers that use DM_FLAG_PRE_RELOC. > > Signed-off-by: Ovidiu Panait > --- > > drivers/timer/timer-uclass.c | 14 ++ > 1 file changed, 14 insertions(+) Reviewed-by: Simon Glass Which (broken) toolchain are you using?
Re: Bad Data CRC
Hi Momo, On Tue, 11 Oct 2022 at 00:13, momo aubin wrote: > > Hi Simon > > > On 11 Oct 2022, at 12:33 AM, Simon Glass wrote: > > > > Hi Momo, > > > >> On Mon, 10 Oct 2022 at 15:31, momo aubin wrote: > >> > >> Hello Simon, > >> > >> My board boots well . When I added the second partition into my kernel I > >> got this message > >> Verifying Checksum ... Bad Data CRC > >> what could be the root cause ? > >> > >> Which data is talking about ? u boot data or kernel data ? > > > > Sorry, I don't know what you are referring to here. Can you reply to > > the original thread? > > > > Regards, > > Simon > > Sorry this is the new thread. Should I create a new thread ? OK, I just wondered why you were asking me :-) Can you post the full boot log? Regards, Simon
Re: [PATCH 4/5] binman: Use an exit code when blobs are missing
Hi Tom, On Tue, 11 Oct 2022 at 15:05, Tom Rini wrote: > > On Mon, Oct 10, 2022 at 04:25:36PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 10 Oct 2022 at 14:41, Tom Rini wrote: > > > > > > On Mon, Oct 10, 2022 at 02:00:31PM -0600, Simon Glass wrote: > > > > > > > At present binman returns success when told to handle missing blobs. > > > > This is confusing this in fact the resulting image cannot work. > > > > > > > > Use exit code 103 to signal this problem, with a -W option to convert > > > > it to a warning. > > > > > > > > Signed-off-by: Simon Glass > > > > > > I'm still not sure I like this, rather than changing the default "make" > > > behavior. > > > > I did change that, in the sense that 'make' now fails if there are > > missing blobs. > > > > > And then it gets me a bit worried that we have CI not doing > > > some other things "right" as we don't want to ignore warnings in CI, we > > > want warnings to become errors so that new warnings don't make it > > > in-tree. > > > > That would be quite a big effort, and unrelated to this series. Here > > are some warning types I'm aware of: > > > > - migration > > - device tree > > - compiler > > - missing blobs > > > > Do we need a per-board whitelist for warnings? It seems pretty tricky to me. > > > > It is true that warnings are ignored in CI and this does create > > problems...I'd love to make them into errors if we can. > > This is I guess also a related concern. When I say warnings, I mean > C compiler warnings. That we have flags to suppress "warnings" that are > other kinds of valid warnings is at least a little confusing. Yes. But of course binman doesn't have any other kind of warning, so so long as we don't propagate that flag further, it makes sense I think. The warnings in U-Boot are at least somewhat out of control IMO, as per my list above. Regards, Simon
Re: [PATCH] Kconfig: distro: Use imply instead of select for CMD_FAT
On Fri, Sep 02, 2022 at 11:28:49AM +0800, Jit Loon Lim wrote: > From: Tien Fong Chee > > Using imply instead of select for CMD_FAT so overwritten is allowed in > later configuration. > > Signed-off-by: Tien Fong Chee > --- > Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Kconfig b/Kconfig > index 991b260182..71374980e9 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -201,7 +201,7 @@ config DISTRO_DEFAULTS > select CMD_ENV_EXISTS > select CMD_EXT2 > select CMD_EXT4 > - select CMD_FAT > + imply CMD_FAT > select CMD_FS_GENERIC > select CMD_PART if PARTITIONS > select CMD_PING if CMD_NET NAK, at least without explaining what the use case here is. A big part of generic distro work is "oh, you have that FAT32 ESP to use". -- Tom signature.asc Description: PGP signature
Re: [PATCH] avb: Extend support to non-eMMC interfaces
On mar., oct. 11, 2022 at 13:40, Alistair Delva wrote:
> On Mon, Oct 10, 2022 at 7:53 AM Mattijs Korpershoek
> wrote:
>>
>> Hi Alistair,
>>
>> Thank you for your patch.
>>
>> On lun., sept. 26, 2022 at 22:02, Alistair Delva wrote:
>>
>> > From: Jiyong Park
>> >
>> > Previously Android AVB supported block devices only on eMMC. This change
>> > eliminates the restriction by using the generic block driver model.
>> >
>> > The `avb init' command is modified to accept another parameter which
>> > specifies the interface type. e.g., `avb init virtio 0' initializes
>> > avb for the first (0) disk that is accessible via the virtio interface.
>> >
>> > [adelva: The "avb init" command is updated directly, as this is
>> > considered a "debug command" that can't be usefully used in u-boot
>> > scripts.]
>>
>> It seems that:
>> * include/configs/ti_omap5_common.h
>> * include/configs/meson64_android.h
>> * configs/total_compute_defconfig
>>
>> All call "avb init"
>>
>> Aren't we breaking these boot scripts with this change?
>>
>> Since all of them used mmc before, it should be trivial to patch these
>> environments as well.
>> If you do so, please cc me in next version so I can give this a try on
>> the khadas vim3l board.
>
> Sure, I'll do that and send a v2.
>
>> Maybe those devices are doing the wrong thing though. since this is
>> considered a debug command I imagine we should not be calling this at
>> all.
>> If so, do you have any alternatives in mind?
>
> Yes, sorry. My rationale was confusing. We have more patches to
> upstream which will explain the reasoning better:
>
> "data from boot and vendor_boot partitions are loaded only once for
> the verification. After the verification is done, the read data is
> directly copied to the load addresses instead of doing the I/O again
> from the disk. This is to prevent a TOCTOU issue where attacker provides
> different data for verification and actual booting."
Indeed. Thank you for the details. I understand now.
>
> So yes, what these env files do for now isn't safe, but there isn't a
> good upstream alternative. Anyway, this problem isn't related to what
> this patch is doing. So, I should update them for now.
ACK.
>
>> >
>> > Signed-off-by: Alistair Delva
>> > Cc: Igor Opaniuk
>> > Cc: Ram Muthiah
>> > Cc: Jiyong Park
>> > Cc: Simon Glass
>> > ---
>> > cmd/avb.c| 16 ---
>> > common/Kconfig | 1 -
>> > common/avb_verify.c | 105 +--
>> > include/avb_verify.h | 31 -
>>
>> Should we also update the documentation in doc/android/avb2.rst ?
>
> Will do.
>
>> I also think this might break:
>> test/py/tests/test_android/test_avb.py
>
> I'll update it.
>
>> > 4 files changed, 69 insertions(+), 84 deletions(-)
>> >
>> > diff --git a/cmd/avb.c b/cmd/avb.c
>> > index 783f51b816..8bffe49011 100644
>> > --- a/cmd/avb.c
>> > +++ b/cmd/avb.c
>> > @@ -10,24 +10,25 @@
>> > #include
>> > #include
>> > #include
>> > -#include
>> >
>> > #define AVB_BOOTARGS "avb_bootargs"
>> > static struct AvbOps *avb_ops;
>> >
>> > int do_avb_init(struct cmd_tbl *cmdtp, int flag, int argc, char *const
>> > argv[])
>> > {
>> > - unsigned long mmc_dev;
>> > + const char *iface;
>> > + const char *devnum;
>> >
>> > - if (argc != 2)
>> > + if (argc != 3)
>> > return CMD_RET_USAGE;
>> >
>> > - mmc_dev = hextoul(argv[1], NULL);
>> > + iface = argv[1];
>> > + devnum = argv[2];
>> >
>> > if (avb_ops)
>> > avb_ops_free(avb_ops);
>> >
>> > - avb_ops = avb_ops_alloc(mmc_dev);
>> > + avb_ops = avb_ops_alloc(iface, devnum);
>> > if (avb_ops)
>> > return CMD_RET_SUCCESS;
>> >
>> > @@ -419,7 +420,7 @@ int do_avb_write_pvalue(struct cmd_tbl *cmdtp, int
>> > flag, int argc,
>> > }
>> >
>> > static struct cmd_tbl cmd_avb[] = {
>> > - U_BOOT_CMD_MKENT(init, 2, 0, do_avb_init, "", ""),
>> > + U_BOOT_CMD_MKENT(init, 3, 0, do_avb_init, "", ""),
>> > U_BOOT_CMD_MKENT(read_rb, 2, 0, do_avb_read_rb, "", ""),
>> > U_BOOT_CMD_MKENT(write_rb, 3, 0, do_avb_write_rb, "", ""),
>> > U_BOOT_CMD_MKENT(is_unlocked, 1, 0, do_avb_is_unlocked, "", ""),
>> > @@ -455,7 +456,8 @@ static int do_avb(struct cmd_tbl *cmdtp, int flag, int
>> > argc, char *const argv[])
>> > U_BOOT_CMD(
>> > avb, 29, 0, do_avb,
>> > "Provides commands for testing Android Verified Boot 2.0
>> > functionality",
>> > - "init - initialize avb2 for \n"
>> > + "init - initialize avb2 for the disk
>> > which\n"
>> > + "is on the interface \n"
>> > "avb read_rb - read rollback index at location \n"
>> > "avb write_rb - write rollback index to \n"
>> > "avb is_unlocked - returns unlock status of the device\n"
>> > diff --git a/common/Kconfig b/common/Kconfig
>> > index ebee856e56..a66060767c 100644
>> > --- a/common/Kconfig
>> > +++ b/common/Kconfig
>> > @@ -703,7 +703,6 @@ config HASH
>>
[PATCH 2/3] clk: stm32mp13: introduce STM32MP13 RCC driver
Introduce STM32MP13 RCC driver using Common Clock Framework.
Signed-off-by: Gabriel Fernandez
---
drivers/clk/stm32/Kconfig | 15 +
drivers/clk/stm32/Makefile |2 +
drivers/clk/stm32/clk-stm32-core.c | 349 ++
drivers/clk/stm32/clk-stm32-core.h | 154 +++
drivers/clk/stm32/clk-stm32mp13.c | 839 +
drivers/clk/stm32/stm32mp13_rcc.h | 1751
6 files changed, 3110 insertions(+)
create mode 100644 drivers/clk/stm32/clk-stm32-core.c
create mode 100644 drivers/clk/stm32/clk-stm32-core.h
create mode 100644 drivers/clk/stm32/clk-stm32mp13.c
create mode 100644 drivers/clk/stm32/stm32mp13_rcc.h
diff --git a/drivers/clk/stm32/Kconfig b/drivers/clk/stm32/Kconfig
index eac3fc1e9d..7a34ea23c3 100644
--- a/drivers/clk/stm32/Kconfig
+++ b/drivers/clk/stm32/Kconfig
@@ -14,6 +14,12 @@ config CLK_STM32H7
This clock driver adds support for RCC clock management
for STM32H7 SoCs.
+config CLK_STM32_CORE
+ bool "Enable RCC clock core driver for STM32MP"
+ depends on ARCH_STM32MP && CLK
+ select CLK_CCF
+ select CLK_COMPOSITE_CCF
+
config CLK_STM32MP1
bool "Enable RCC clock driver for STM32MP15"
depends on ARCH_STM32MP && CLK
@@ -21,3 +27,12 @@ config CLK_STM32MP1
help
Enable the STM32 clock (RCC) driver. Enable support for
manipulating STM32MP15's on-SoC clocks.
+
+config CLK_STM32MP13
+ bool "Enable RCC clock driver for STM32MP13"
+ depends on ARCH_STM32MP && CLK
+ default y if STM32MP13x
+ select CLK_STM32_CORE
+ help
+ Enable the STM32 clock (RCC) driver. Enable support for
+ manipulating STM32MP13's on-SoC clocks.
diff --git a/drivers/clk/stm32/Makefile b/drivers/clk/stm32/Makefile
index f66f295403..20afbc3cfc 100644
--- a/drivers/clk/stm32/Makefile
+++ b/drivers/clk/stm32/Makefile
@@ -2,6 +2,8 @@
#
# Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+obj-$(CONFIG_CLK_STM32_CORE) += clk-stm32-core.o
obj-$(CONFIG_CLK_STM32F) += clk-stm32f.o
obj-$(CONFIG_CLK_STM32H7) += clk-stm32h7.o
obj-$(CONFIG_CLK_STM32MP1) += clk-stm32mp1.o
+obj-$(CONFIG_CLK_STM32MP13) += clk-stm32mp13.o
diff --git a/drivers/clk/stm32/clk-stm32-core.c
b/drivers/clk/stm32/clk-stm32-core.c
new file mode 100644
index 00..5e02807c1e
--- /dev/null
+++ b/drivers/clk/stm32/clk-stm32-core.c
@@ -0,0 +1,349 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (C) 2022, STMicroelectronics - All Rights Reserved
+ * Author: Gabriel Fernandez for
STMicroelectronics.
+ */
+
+#define LOG_CATEGORY UCLASS_CLK
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "clk-stm32-core.h"
+
+int stm32_rcc_init(struct device *dev,
+ const struct stm32_clock_match_data *data,
+ void __iomem *base)
+{
+ int i;
+
+ for (i = 0; i < data->num_clocks; i++) {
+ const struct clock_config *cfg = &data->tab_clocks[i];
+ struct clk *clk = ERR_PTR(-ENOENT);
+
+ if (data->check_security) {
+ if ((*data->check_security)(base, cfg))
+ continue;
+ }
+
+ if (cfg->func)
+ clk = (*cfg->func)(NULL, data, base, NULL, cfg);
+
+ if (IS_ERR(clk)) {
+ log_err("%s: failed to register clock %s\n", __func__,
+ cfg->name);
+
+ return PTR_ERR(clk);
+ }
+
+ clk->id = cfg->id;
+ }
+
+ return 0;
+}
+
+static const struct clk_ops *clk_dev_ops(struct udevice *dev)
+{
+ return (const struct clk_ops *)dev->driver->ops;
+}
+
+static int stm32_clk_enable(struct clk *clk)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id || clk_get_by_id(clk->id, &clkp))
+ return -ENOENT;
+
+ ops = clk_dev_ops(clkp->dev);
+ if (!ops->enable)
+ return 0;
+
+ return ops->enable(clkp);
+}
+
+static int stm32_clk_disable(struct clk *clk)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id || clk_get_by_id(clk->id, &clkp))
+ return -ENOENT;
+
+ ops = clk_dev_ops(clkp->dev);
+ if (!ops->disable)
+ return 0;
+
+ return ops->disable(clkp);
+}
+
+static ulong stm32_clk_get_rate(struct clk *clk)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id || clk_get_by_id(clk->id, &clkp))
+ return -ENOENT;
+
+ ops = clk_dev_ops(clkp->dev);
+ if (!ops->get_rate)
+ return -ENOSYS;
+
+ return ops->get_rate(clkp);
+}
+
+static ulong stm32_clk_set_rate(struct clk *clk, unsigned long clk_rate)
+{
+ const struct clk_ops *ops;
+ struct clk *clkp = NULL;
+
+ if (!clk->id ||
[PATCH 3/3] arm: dts: stm32mp13: add support of RCC driver
Adds support of Clock and Reset drivers for STM32MP13 platform.
Signed-off-by: Gabriel Fernandez
---
arch/arm/dts/stm32mp13-u-boot.dtsi | 4 +
arch/arm/dts/stm32mp131.dtsi | 119 +++--
arch/arm/dts/stm32mp133.dtsi | 4 +-
arch/arm/dts/stm32mp13xf.dtsi | 3 +-
4 files changed, 52 insertions(+), 78 deletions(-)
diff --git a/arch/arm/dts/stm32mp13-u-boot.dtsi
b/arch/arm/dts/stm32mp13-u-boot.dtsi
index 47a43649bb..3730f474b2 100644
--- a/arch/arm/dts/stm32mp13-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp13-u-boot.dtsi
@@ -92,6 +92,10 @@
u-boot,dm-pre-reloc;
};
+&rcc {
+ u-boot,dm-pre-reloc;
+};
+
&scmi {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/stm32mp131.dtsi b/arch/arm/dts/stm32mp131.dtsi
index a1c6d0d00b..d893bc24b4 100644
--- a/arch/arm/dts/stm32mp131.dtsi
+++ b/arch/arm/dts/stm32mp131.dtsi
@@ -4,6 +4,8 @@
* Author: Alexandre Torgue for
STMicroelectronics.
*/
#include
+#include
+#include
/ {
#address-cells = <1>;
@@ -52,62 +54,6 @@
};
};
- clocks {
- clk_axi: clk-axi {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <26650>;
- };
-
- clk_hse: clk-hse {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <2400>;
- };
-
- clk_hsi: clk-hsi {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <6400>;
- };
-
- clk_lsi: clk-lsi {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <32000>;
- };
-
- clk_pclk3: clk-pclk3 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <104438965>;
- };
-
- clk_pclk4: clk-pclk4 {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <13325>;
- };
-
- clk_pll4_p: clk-pll4_p {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <5000>;
- };
-
- clk_pll4_r: clk-pll4_r {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <9900>;
- };
-
- clk_rtc_k: clk-rtc-k {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <32768>;
- };
- };
-
intc: interrupt-controller@a0021000 {
compatible = "arm,cortex-a7-gic";
#interrupt-cells = <3>;
@@ -155,7 +101,8 @@
compatible = "st,stm32h7-uart";
reg = <0x4001 0x400>;
interrupts = ;
- clocks = <&clk_hsi>;
+ clocks = <&rcc UART4_K>;
+ resets = <&rcc UART4_R>;
status = "disabled";
};
@@ -170,7 +117,8 @@
,
,
;
- clocks = <&clk_pclk4>;
+ clocks = <&rcc DMA1>;
+ resets = <&rcc DMA1_R>;
#dma-cells = <4>;
st,mem2mem;
dma-requests = <8>;
@@ -187,7 +135,8 @@
,
,
;
- clocks = <&clk_pclk4>;
+ clocks = <&rcc DMA2>;
+ resets = <&rcc DMA2_R>;
#dma-cells = <4>;
st,mem2mem;
dma-requests = <8>;
@@ -196,13 +145,29 @@
dmamux1: dma-router@48002000 {
compatible = "st,stm32h7-dmamux";
reg = <0x48002000 0x40>;
- clocks = <&clk_pclk4>;
+ clocks = <&rcc DMAMUX1>;
+ resets = <&rcc DMAMUX1_R>;
#dma-cells = <3>;
dma-masters = <&dma1 &dma2>;
dma-requests = <128>;
dma-channels = <16>;
};
+ rcc: rcc@5000 {
+ compatible = "st,stm32mp13-rcc", "syscon";
+ reg = <0x5000 0x1000>;
+
[PATCH 1/3] dt-bindings: stm32mp13: add clock & reset support for STM32MP13
Add support of stm32mp13 DT bindings of clock and reset. Signed-off-by: Gabriel Fernandez --- MAINTAINERS | 2 + include/dt-bindings/clock/stm32mp13-clks.h | 229 +++ include/dt-bindings/reset/stm32mp13-resets.h | 100 3 files changed, 331 insertions(+) create mode 100644 include/dt-bindings/clock/stm32mp13-clks.h create mode 100644 include/dt-bindings/reset/stm32mp13-resets.h diff --git a/MAINTAINERS b/MAINTAINERS index cb4d44584d..475194207b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -538,9 +538,11 @@ F: drivers/video/stm32/stm32_ltdc.c F: drivers/watchdog/stm32mp_wdt.c F: include/dt-bindings/clock/stm32fx-clock.h F: include/dt-bindings/clock/stm32mp1-clks.h +F: include/dt-bindings/clock/stm32mp13-clks.h F: include/dt-bindings/clock/stm32mp1-clksrc.h F: include/dt-bindings/pinctrl/stm32-pinfunc.h F: include/dt-bindings/reset/stm32mp1-resets.h +F: include/dt-bindings/reset/stm32mp13-resets.h F: include/stm32_rcc.h F: tools/stm32image.c N: stm diff --git a/include/dt-bindings/clock/stm32mp13-clks.h b/include/dt-bindings/clock/stm32mp13-clks.h new file mode 100644 index 00..799dee5b80 --- /dev/null +++ b/include/dt-bindings/clock/stm32mp13-clks.h @@ -0,0 +1,229 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later or BSD-3-Clause */ +/* + * Copyright (C) STMicroelectronics 2022 - All Rights Reserved + * Author: Gabriel Fernandez for STMicroelectronics. + */ + +#ifndef _DT_BINDINGS_STM32MP13_CLKS_H_ +#define _DT_BINDINGS_STM32MP13_CLKS_H_ + +/* OSCILLATOR clocks */ +#define CK_HSE 0 +#define CK_CSI 1 +#define CK_LSI 2 +#define CK_LSE 3 +#define CK_HSI 4 +#define CK_HSE_DIV25 + +/* PLL */ +#define PLL1 6 +#define PLL2 7 +#define PLL3 8 +#define PLL4 9 + +/* ODF */ +#define PLL1_P 10 +#define PLL1_Q 11 +#define PLL1_R 12 +#define PLL2_P 13 +#define PLL2_Q 14 +#define PLL2_R 15 +#define PLL3_P 16 +#define PLL3_Q 17 +#define PLL3_R 18 +#define PLL4_P 19 +#define PLL4_Q 20 +#define PLL4_R 21 + +#define PCLK1 22 +#define PCLK2 23 +#define PCLK3 24 +#define PCLK4 25 +#define PCLK5 26 +#define PCLK6 27 + +/* SYSTEM CLOCK */ +#define CK_PER 28 +#define CK_MPU 29 +#define CK_AXI 30 +#define CK_MLAHB 31 + +/* BASE TIMER */ +#define CK_TIMG1 32 +#define CK_TIMG2 33 +#define CK_TIMG3 34 + +/* AUX */ +#define RTC35 + +/* TRACE & DEBUG clocks */ +#define CK_DBG 36 +#define CK_TRACE 37 + +/* MCO clocks */ +#define CK_MCO138 +#define CK_MCO239 + +/* IP clocks */ +#define SYSCFG 40 +#define VREF 41 +#define DTS42 +#define PMBCTRL43 +#define HDP44 +#define IWDG2 45 +#define STGENRO46 +#define USART1 47 +#define RTCAPB 48 +#define TZC49 +#define TZPC 50 +#define IWDG1 51 +#define BSEC 52 +#define DMA1 53 +#define DMA2 54 +#define DMAMUX155 +#define DMAMUX256 +#define GPIOA 57 +#define GPIOB 58 +#define GPIOC 59 +#define GPIOD 60 +#define GPIOE 61 +#define GPIOF 62 +#define GPIOG 63 +#define GPIOH 64 +#define GPIOI 65 +#define CRYP1 66 +#define HASH1 67 +#define BKPSRAM68 +#define MDMA 69 +#define CRC1 70 +#define USBH 71 +#define DMA3 72 +#define TSC73 +#define PKA74 +#define AXIMC 75 +#define MCE76 +#define ETH1TX 77 +#define ETH2TX 78 +#define ETH1RX 79 +#define ETH2RX 80 +#define ETH1MAC81 +#define ETH2MAC82 +#define ETH1STP83 +#define ETH2STP84 + +/* IP clocks with parents */ +#define SDMMC1_K 85 +#define SDMMC2_K 86 +#define ADC1_K 87 +#define ADC2_K 88 +#define FMC_K 89 +#define QSPI_K 90 +#define RNG1_K 91 +#define USBPHY_K 92 +#define STGEN_K93 +#define SPDIF_K94 +#define SPI1_K 95 +#define SPI2_K 96 +#define SPI3_K 97 +#define SPI4_K 98 +#define SPI5_K 99 +#define I2C1_K 100 +#define I2C2_K 101 +#define I2C3_K 102 +#define I2C4_K 103 +#define I2C5_K 104 +#define TIM2_K 105 +#define TIM3_K 106 +#define TIM4_K 107 +#define TIM5_K 108 +#define TIM6_K 109 +#define TIM7_K 110 +#define TIM12_K111 +#define TIM13_K112 +#define TIM14_K
[PATCH 0/3] Introduce STM32MP13 RCC driver
This serie adds support of clock and reset for STM32MP13. Gabriel Fernandez (3): dt-bindings: stm32mp13: add clock & reset support for STM32MP13 clk: stm32mp13: introduce STM32MP13 RCC driver arm: dts: stm32mp13: add support of RCC driver MAINTAINERS |2 + arch/arm/dts/stm32mp13-u-boot.dtsi |4 + arch/arm/dts/stm32mp131.dtsi | 119 +- arch/arm/dts/stm32mp133.dtsi |4 +- arch/arm/dts/stm32mp13xf.dtsi|3 +- drivers/clk/stm32/Kconfig| 15 + drivers/clk/stm32/Makefile |2 + drivers/clk/stm32/clk-stm32-core.c | 349 drivers/clk/stm32/clk-stm32-core.h | 154 ++ drivers/clk/stm32/clk-stm32mp13.c| 839 + drivers/clk/stm32/stm32mp13_rcc.h| 1751 ++ include/dt-bindings/clock/stm32mp13-clks.h | 229 +++ include/dt-bindings/reset/stm32mp13-resets.h | 100 + 13 files changed, 3493 insertions(+), 78 deletions(-) create mode 100644 drivers/clk/stm32/clk-stm32-core.c create mode 100644 drivers/clk/stm32/clk-stm32-core.h create mode 100644 drivers/clk/stm32/clk-stm32mp13.c create mode 100644 drivers/clk/stm32/stm32mp13_rcc.h create mode 100644 include/dt-bindings/clock/stm32mp13-clks.h create mode 100644 include/dt-bindings/reset/stm32mp13-resets.h -- 2.25.1
Re: [u-boot][PATCH 10/14] mtd: rawnand: omap_gpmc: support u-boot driver model
On Wed, Oct 12, 2022 at 6:57 AM Ladislav Michl wrote: > > Hi Adam, > > On Wed, Oct 12, 2022 at 06:42:22AM -0500, Adam Ford wrote: > [snip] > > On my board the GPMC runs more than just NAND. I am hoping to get the > > GPMC driver working in U-Boot first then in SPL (assuming it fits). I > > have LTO enabled on my DM3730, so I am hoping it might help make some > > room. I am hoping that once the NAND is working that the GPMC driver > > can be used in U-Boot to handle the configuration of the bus for > > handling Ethernet, so some of the quirks and manual board file > > configuration can be removed. > > Any estimate on that? I moved IGEP to use DM for ethernet, but for reasons > you mentioned quirk in DT is still there. Reposting that patch would > currently add one more quirk into codebase, so I'd better avoid that. I won't know until I have a chance to sit down and try out the code framework that's proposed. I'll be doing it as a side project, so I can't guarantee speed, but since Roger is trying to get NAND working, my work will start there with the hope of evolving it to do more as I get time. adam > > Thank you, > L.
Re: [u-boot][PATCH 10/14] mtd: rawnand: omap_gpmc: support u-boot driver model
Hi Adam, On Wed, Oct 12, 2022 at 06:42:22AM -0500, Adam Ford wrote: [snip] > On my board the GPMC runs more than just NAND. I am hoping to get the > GPMC driver working in U-Boot first then in SPL (assuming it fits). I > have LTO enabled on my DM3730, so I am hoping it might help make some > room. I am hoping that once the NAND is working that the GPMC driver > can be used in U-Boot to handle the configuration of the bus for > handling Ethernet, so some of the quirks and manual board file > configuration can be removed. Any estimate on that? I moved IGEP to use DM for ethernet, but for reasons you mentioned quirk in DT is still there. Reposting that patch would currently add one more quirk into codebase, so I'd better avoid that. Thank you, L.
Re: [u-boot][PATCH 02/14] mtd: rawnand: omap_gpmc: Enable build for K2/K3 platforms
Hi On Tue, Oct 11, 2022 at 1:50 PM Roger Quadros wrote: > > The GPMC module is present on some K2 and K3 SoCs. > Enable building GPMC NAND driver for K2/K3 platforms. > > Signed-off-by: Roger Quadros > --- > drivers/mtd/nand/raw/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig > index ce67d1abde..bc5cabdfc2 100644 > --- a/drivers/mtd/nand/raw/Kconfig > +++ b/drivers/mtd/nand/raw/Kconfig > @@ -189,7 +189,7 @@ config NAND_LPC32XX_SLC > > config NAND_OMAP_GPMC > bool "Support OMAP GPMC NAND controller" > - depends on ARCH_OMAP2PLUS > + depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3 > help > Enables omap_gpmc.c driver for OMAPx and AM platforms. > GPMC controller is used for parallel NAND flash devices, and can > -- > 2.17.1 > Reviewed-By: Michael Trimarchi -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
Re: [u-boot][PATCH 10/14] mtd: rawnand: omap_gpmc: support u-boot driver model
On Wed, Oct 12, 2022 at 1:22 AM Roger Quadros wrote:
>
> Hi Adam,
>
> On 11/10/2022 18:01, Adam Ford wrote:
> > On Tue, Oct 11, 2022 at 6:52 AM Roger Quadros wrote:
> >>
> >> Adds driver model support.
> >>
> >> We need to be able to self initialize the NAND controller/chip
> >> at probe and so enable CONFIG_SYS_NAND_SELF_INIT.
> >>
> >> Doing so requires nand_register() API which is provided by nand.c
> >> and needs to be enabled during SPL build via CONFIG_SPL_NAND_INIT.
> >> But nand.c also provides nand_init() so we need to get rid of nand_init()
> >> in omap_gpmc driver if CONFIG_SPL_NAND_INIT is set.
> >>
> >> Signed-off-by: Roger Quadros
> >> ---
> >> drivers/mtd/nand/raw/Kconfig | 1 +
> >> drivers/mtd/nand/raw/omap_gpmc.c | 55 +++-
> >> 2 files changed, 55 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> >> index bc5cabdfc2..1d23144ce4 100644
> >> --- a/drivers/mtd/nand/raw/Kconfig
> >> +++ b/drivers/mtd/nand/raw/Kconfig
> >> @@ -190,6 +190,7 @@ config NAND_LPC32XX_SLC
> >> config NAND_OMAP_GPMC
> >> bool "Support OMAP GPMC NAND controller"
> >> depends on ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3
> >> + select SYS_NAND_SELF_INIT if ARCH_K3
> >
> > I have a question about this down below.
> >
> >> help
> >> Enables omap_gpmc.c driver for OMAPx and AM platforms.
> >> GPMC controller is used for parallel NAND flash devices, and can
> >> diff --git a/drivers/mtd/nand/raw/omap_gpmc.c
> >> b/drivers/mtd/nand/raw/omap_gpmc.c
> >> index e772a914c8..7192ca9e5a 100644
> >> --- a/drivers/mtd/nand/raw/omap_gpmc.c
> >> +++ b/drivers/mtd/nand/raw/omap_gpmc.c
> >> @@ -7,6 +7,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> #ifdef CONFIG_ARCH_OMAP2PLUS
> >> @@ -1121,7 +1122,7 @@ int __maybe_unused omap_nand_switch_ecc(uint32_t
> >> hardware, uint32_t eccstrength)
> >> * nand_scan about special functionality. See the defines for further
> >> * explanation
> >> */
> >> -int board_nand_init(struct nand_chip *nand)
> >> +int gpmc_nand_init(struct nand_chip *nand)
> >> {
> >> int32_t gpmc_config = 0;
> >> int cs = cs_next++;
> >> @@ -1201,3 +1202,55 @@ int board_nand_init(struct nand_chip *nand)
> >>
> >> return 0;
> >> }
> >> +
> >> +static struct nand_chip *nand_chip;/* First NAND chip for SPL use
> >> only */
> >> +
> >> +#if CONFIG_IS_ENABLED(SYS_NAND_SELF_INIT)
> >> +
> >> +static int gpmc_nand_probe(struct udevice *dev)
> >> +{
> >> + struct nand_chip *nand = dev_get_priv(dev);
> >> + struct mtd_info *mtd = nand_to_mtd(nand);
> >> + int ret;
> >> +
> >> + gpmc_nand_init(nand);
> >> +
> >> + ret = nand_scan(mtd, CONFIG_SYS_NAND_MAX_CHIPS);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ret = nand_register(0, mtd);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + if (!nand_chip)
> >> + nand_chip = nand;
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static const struct udevice_id gpmc_nand_ids[] = {
> >> + { .compatible = "ti,am64-nand" },
> >> + { .compatible = "ti,omap2-nand" },
> >
> > The gpmc_nand_ids reference to omap2, but it's encapsulated inside the
> > SYS_NAND_SELF_INIT ifdef which appears to only be set if K3. Should
> > this code be expected to work on OMAP2? I don't think K3 is set for
> > OMAP2+. If so, should the SYS_NAND_SELF_INIT be selected if OMAP2 is
> > selected?
>
> We want to eventually get this working using driver model and
> SYS_NAND_SELF_INIT
> for OMAP2 as well but just that I didn't work on it yet or test it.
>
> One challenge is that OMAP2 boards tend to either select nand_spl_simple.c
> or am335x_spl_bch.c for NAND support at SPL.
>
> We will need to figure out if it is possible to use CONFIG_SPL_NAND_INIT
> and this driver instead.
> One issue might be that everything doesn't fit in resources available at SPL?
On my board the GPMC runs more than just NAND. I am hoping to get the
GPMC driver working in U-Boot first then in SPL (assuming it fits). I
have LTO enabled on my DM3730, so I am hoping it might help make some
room. I am hoping that once the NAND is working that the GPMC driver
can be used in U-Boot to handle the configuration of the bus for
handling Ethernet, so some of the quirks and manual board file
configuration can be removed.
>
> >
> > I have a DM3730 that I can test with this. Do you have a repo I can
>
> That would be great. Thanks!
>
> > point to to test? If not, I'll pull the series from patchwork, but I
> > need to know what branch to use as a starting point.
>
> You can use this Repo as reference.
> https://github.com/rogerq/u-boot/commits/for-v2023.01/am64-nand-base-1.0-test
>
Thanks!
> It has a few patches on top consisting of device tree and u-boot configuration
> for AM64 platform. You can
[RESEND PATCH 2/2] splash: get devpart from environment variable
By default several types of splash locations are supported and the
user can select one of them through environment var (splashsource).
However the devpart is still hardcoded and we cannot change it from
the environment.
This patch add the support of "splashdevpart" which allow the user to
set the devpart though this environment variable.
Example: image located in splashscreen partition (MMC as raw)
```
splashsource=mmc_raw
splashdevpart=0#splashscreen
```
Signed-off-by: Julien Masson
---
common/splash_source.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/common/splash_source.c b/common/splash_source.c
index b4bf6f1336..1f99f44f78 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -451,6 +451,7 @@ int splash_source_load(struct splash_location *locations,
uint size)
{
struct splash_location *splash_location;
char *env_splashimage_value;
+ char *env_splashdevpart_value;
u32 bmp_load_addr;
env_splashimage_value = env_get("splashimage");
@@ -467,6 +468,10 @@ int splash_source_load(struct splash_location *locations,
uint size)
if (!splash_location)
return -EINVAL;
+ env_splashdevpart_value = env_get("splashdevpart");
+ if (env_splashdevpart_value)
+ splash_location->devpart = env_splashdevpart_value;
+
if (splash_location->flags == SPLASH_STORAGE_RAW)
return splash_load_raw(splash_location, bmp_load_addr);
else if (splash_location->flags == SPLASH_STORAGE_FS)
--
2.37.3
[RESEND PATCH 1/2] splash: support raw image from MMC
The user has now the choice to specify the splash location in the MMC
as a raw storage.
Signed-off-by: Julien Masson
---
common/splash.c| 6 ++
common/splash_source.c | 29 +
2 files changed, 35 insertions(+)
diff --git a/common/splash.c b/common/splash.c
index 0e520cc103..5206e35f74 100644
--- a/common/splash.c
+++ b/common/splash.c
@@ -39,6 +39,12 @@ static struct splash_location default_splash_locations[] = {
.flags = SPLASH_STORAGE_FS,
.devpart = "0:1",
},
+ {
+ .name = "mmc_raw",
+ .storage = SPLASH_STORAGE_MMC,
+ .flags = SPLASH_STORAGE_RAW,
+ .devpart = "0:1",
+ },
{
.name = "usb_fs",
.storage = SPLASH_STORAGE_USB,
diff --git a/common/splash_source.c b/common/splash_source.c
index 87e55a54f8..b4bf6f1336 100644
--- a/common/splash_source.c
+++ b/common/splash_source.c
@@ -65,6 +65,33 @@ static int splash_nand_read_raw(u32 bmp_load_addr, int
offset, size_t read_size)
}
#endif
+#ifdef CONFIG_CMD_MMC
+static int splash_mmc_read_raw(u32 bmp_load_addr, struct splash_location
*location,
+ size_t read_size)
+{
+ struct disk_partition partition;
+ struct blk_desc *desc;
+ lbaint_t blkcnt;
+ int ret, n;
+
+ ret = part_get_info_by_dev_and_name_or_num("mmc", location->devpart,
&desc,
+ &partition, 1);
+ if (ret < 0)
+ return ret;
+
+ blkcnt = DIV_ROUND_UP(read_size, partition.blksz);
+ n = blk_dread(desc, partition.start, blkcnt, (void
*)(uintptr_t)bmp_load_addr);
+
+ return (n == blkcnt) ? 0 : -EINVAL;
+}
+#else
+static int splash_mmc_read_raw(u32 bmp_load_addr, int offset, size_t read_size)
+{
+ debug("%s: mmc support not available\n", __func__);
+ return -ENOSYS;
+}
+#endif
+
static int splash_storage_read_raw(struct splash_location *location,
u32 bmp_load_addr, size_t read_size)
{
@@ -75,6 +102,8 @@ static int splash_storage_read_raw(struct splash_location
*location,
offset = location->offset;
switch (location->storage) {
+ case SPLASH_STORAGE_MMC:
+ return splash_mmc_read_raw(bmp_load_addr, location, read_size);
case SPLASH_STORAGE_NAND:
return splash_nand_read_raw(bmp_load_addr, offset, read_size);
case SPLASH_STORAGE_SF:
--
2.37.3
[RESEND PATCH 0/2] splash: add more options/support
This patch series add several options/support for splashscreen feature: - support raw image from MMC - get devpart from environment variable With these changes the user has now more options and can change default configurations through environment variables. Example: image located in splashscreen partition (MMC as raw) ``` splashsource=mmc_raw splashdevpart=0#splashscreen ``` Julien Masson (2): splash: support raw image from MMC splash: get devpart from environment variable common/splash.c| 6 ++ common/splash_source.c | 34 ++ 2 files changed, 40 insertions(+) -- 2.37.3
RE: [PATCH 1/3] mmc: zynq_sdhci: Change node_id prototype to u32
Hi Jaehoon,
> -Original Message-
> From: 정재훈
> Sent: Wednesday, October 12, 2022 3:09 PM
> To: Soma, Ashok Reddy ; 'Jaehoon Chung'
> ; u-boot@lists.denx.de
> Cc: Simek, Michal ; peng@nxp.com; Halder,
> Ayan Kumar ; Mehta, Piyush
> ; lakshmi.sai.krishna.potth...@amd.com;
> shravya.kumb...@amd.com
> Subject: RE: [PATCH 1/3] mmc: zynq_sdhci: Change node_id prototype to u32
>
> Hi,
>
> > -Original Message-
> > From: Soma, Ashok Reddy [mailto:ashok.reddy.s...@amd.com]
> > Sent: Wednesday, October 12, 2022 3:27 PM
> > To: Jaehoon Chung ; u-boot@lists.denx.de
> > Cc: Simek, Michal ; peng@nxp.com;
> > jh80.ch...@samsung.com; Halder, Ayan Kumar
> > ; Mehta, Piyush
> ;
> > lakshmi.sai.krishna.potth...@amd.com; shravya.kumb...@amd.com
> > Subject: RE: [PATCH 1/3] mmc: zynq_sdhci: Change node_id prototype to
> > u32
> >
> > Hi Jaehoon,
> >
> > >-Original Message-
> > >From: Jaehoon Chung
> > >Sent: Friday, October 7, 2022 6:16 PM
> > >To: Soma, Ashok Reddy ;
> > >u-boot@lists.denx.de
> > >Cc: Simek, Michal ; peng@nxp.com;
> > >jh80.ch...@samsung.com; Halder, Ayan
> > Kumar ; Mehta, Piyush
> > ; lakshmi.sai.krishna.potth...@amd.com;
> > shravya.kumb...@amd.com
> > >Subject: Re: [PATCH 1/3] mmc: zynq_sdhci: Change node_id prototype to
> > >u32
> > >
> > >
> > >
> > >On 9/30/22 18:25, Ashok Reddy Soma wrote:
> > >> In Versal platform power domain node_id is bigger than u8, hence
> > >> change prototype to u32 to accommodate. Change u8 to u32 in the
> > >> function prototypes that use node_id and remove casting to u32 from
> > >> xilinx_pm_request() call parameters.
> > >>
> > >> Signed-off-by: Ashok Reddy Soma
> > >> ---
> > >>
> > >> drivers/mmc/zynq_sdhci.c | 14 +++---
> > >> 1 file changed, 7 insertions(+), 7 deletions(-)
> > >>
> > >> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
> > >> index 8f4071c8c2..3a4194452c 100644
> > >> --- a/drivers/mmc/zynq_sdhci.c
> > >> +++ b/drivers/mmc/zynq_sdhci.c
> > >> @@ -111,7 +111,7 @@ static const u8 mode2timing[] = {
> > >> [MMC_HS_200] = MMC_TIMING_MMC_HS200, };
> > >>
> > >> -static inline int arasan_zynqmp_set_in_tapdelay(u8 node_id, u32
> > >> itap_delay)
> > >> +static inline int arasan_zynqmp_set_in_tapdelay(u32 node_id, u32
> > >> +itap_delay)
> > >
> > >Is it passed by u8 from sdhci_zynqmp_sampleclk_set_pahse()?
> >
> > Seems like I missed to change the type to u32 from where these
> > functions are called. But those lines are removed in patch 2/3.
> > Should I send V2 or is it okay ?
>
> I think that it doesn't need to resend V2. As you mentioned, it's removed on
> patch 2/3.
> And it was already applied. Sorry for reviewed too late.
Never mind about the timing, it was a good catch. thanks for the review.
Thanks,
Ashok
>
> Thanks!
>
> Best Regards,
> Jaehoon Chung
>
> >
> > Thanks,
> > Ashok
> > >
> > >
> > >Best Regards,
> > >Jaehoon Chung
> > >
> > >> {
> > >> int ret;
> > >>
> > >> @@ -155,7 +155,7 @@ static inline int
> arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
> > >> if (ret)
> > >> return ret;
> > >> } else {
> > >> -return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> > >> +return xilinx_pm_request(PM_IOCTL, node_id,
> > >> IOCTL_SET_SD_TAPDELAY,
> > >> PM_TAPDELAY_INPUT, itap_delay,
> NULL);
> > >> }
> > >> @@ -163,7 +163,7 @@ static inline int
> arasan_zynqmp_set_in_tapdelay(u8 node_id, u32 itap_delay)
> > >> return 0;
> > >> }
> > >>
> > >> -static inline int arasan_zynqmp_set_out_tapdelay(u8 node_id, u32
> > >> otap_delay)
> > >> +static inline int arasan_zynqmp_set_out_tapdelay(u32 node_id, u32
> > >> +otap_delay)
> > >> {
> > >> if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> > >> if (node_id == NODE_SD_0)
> > >> @@ -174,13 +174,13 @@ static inline int
> > >> arasan_zynqmp_set_out_tapdelay(u8 node_id, u32
> > otap_delay)
> > >> return zynqmp_mmio_write(SD_OTAP_DLY,
> SD1_OTAPDLYSEL_MASK,
> > >> (otap_delay << 16));
> > >> } else {
> > >> -return xilinx_pm_request(PM_IOCTL, (u32)node_id,
> > >> +return xilinx_pm_request(PM_IOCTL, node_id,
> > >> IOCTL_SET_SD_TAPDELAY,
> > >> PM_TAPDELAY_OUTPUT, otap_delay,
> NULL);
> > >> }
> > >> }
> > >>
> > >> -static inline int zynqmp_dll_reset(u8 node_id, u32 type)
> > >> +static inline int zynqmp_dll_reset(u32 node_id, u32 type)
> > >> {
> > >> if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
> > >> if (node_id == NODE_SD_0)
> > >> @@ -192,12 +192,12 @@ static inline int zynqmp_dll_reset(u8 node_id,
> u32 type)
> > >> ty
