Re: [PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb

[Sughosh Ganu]

hi Tom,

On Wed, 16 Aug 2023 at 01:54, Tom Rini  wrote:
>
> On Tue, Aug 15, 2023 at 09:56:20PM +0530, Sughosh Ganu wrote:
>
> > The EFI capsule authentication logic in u-boot expects the public key
> > in the form of an EFI Signature List(ESL) to be provided as part of
> > the platform's dtb. Currently, the embedding of the ESL file into the
> > dtb needs to be done manually.
> >
> > Add a target for generating a dtsi file which contains the signature
> > node with the ESL file included as a property under the signature
> > node. Include the dtsi file in the dtb. This brings the embedding of
> > the ESL in the dtb into the U-Boot build flow.
> >
> > The path to the ESL file is specified through the
> > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> > Signed-off-by: Sughosh Ganu 
> [snip]
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index 368b5a3e28..2e71f190bc 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -334,7 +334,23 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> >   ; \
> >   sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > 
> > $(depfile)
> >
> > -$(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
> > +ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > +quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
> > +cmd_capsule_esl_gen = \
> > + $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" 
> > $(capsule_esl_input_file) > $@)
> > +
> > +$(obj)/.capsule_esl.dtsi:
> > + $(call cmd_capsule_esl_gen)
> > +
> > +capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
> > +capsule_esl_dtsi = .capsule_esl.dtsi
> > +capsule_esl_path=$(abspath $(srctree)/$(subst 
> > $(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
> > +dtsi_include_list += $(capsule_esl_dtsi)
> > +endif
>
> We should only need to ifdef around appending to dtsi_include_list.  The
> rest we can / should just leave always there, that's cleaner reading.

Okay

>
> > +
> > +dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
> > $(quote),,$(dtsi_include_list)))
> > +
> > +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
>
> This part here is a separate bugfix and we should do that as patch 2,
> and the rest of the changes here as patch 3.

Will put this in a separate patch. Thanks.

-sughosh

Re: [PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb

[Sughosh Ganu]

hi Simon,

On Wed, 16 Aug 2023 at 00:09, Simon Glass  wrote:
>
> Hi Sughosh,
>
> On Tue, 15 Aug 2023 at 10:26, Sughosh Ganu  wrote:
> >
> > The EFI capsule authentication logic in u-boot expects the public key
> > in the form of an EFI Signature List(ESL) to be provided as part of
> > the platform's dtb. Currently, the embedding of the ESL file into the
> > dtb needs to be done manually.
> >
> > Add a target for generating a dtsi file which contains the signature
> > node with the ESL file included as a property under the signature
> > node. Include the dtsi file in the dtb. This brings the embedding of
> > the ESL in the dtb into the U-Boot build flow.
> >
> > The path to the ESL file is specified through the
> > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> > Signed-off-by: Sughosh Ganu 
> > ---
> > Changes since RFC series:
> > * Remove the default value of the config symbol.
> > * s/include_files/dtsi_include_list
> > * Add all the dtsi files being included as dependency for the dtb
> >   target.
> >
> >  lib/efi_loader/Kconfig |  8 
> >  lib/efi_loader/capsule_esl.dtsi.in | 11 +++
> >  scripts/Makefile.lib   | 18 +-
> >  3 files changed, 36 insertions(+), 1 deletion(-)
> >  create mode 100644 lib/efi_loader/capsule_esl.dtsi.in
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 9989e3f384..d20aaab6db 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -272,6 +272,14 @@ config EFI_CAPSULE_MAX
> >   Select the max capsule index value used for capsule report
> >   variables. This value is used to create CapsuleMax variable.
> >
> > +config EFI_CAPSULE_ESL_FILE
> > +   string "Path to the EFI Signature List File"
>
> Do we need this, or could we name it as we do with the .env file? It
> seems confusing to have to set this for each board - it might be
> better to have it in a defined location.

The reason I put this is because I thought this gave the user the
flexibility to provide the location and name of the ESL. But I suppose
that the board directory would be a good location to expect this file.
Then this file can have a name like capsule_pub_key,esl. Tom, what are
your thoughts on this?

>
> Another idea is that we could use binman to pull this in, e.g. with an
> option to insert the capsule key during the build. Then it can be
> anywhere on the binman path.

So, if I understand you right, I believe you are suggesting using
binman for this task? Which, just to make it clear, I pretty much
understand what would be needed to be done to get this working in
binman. A typical binman image for for this task would look like

 {
u-boot-capsule-esl {
u-boot-no-dtb {
};
fdt-esl {
u-boot-dtb {
};
};
};
};

The fdt-esl entry type would then call the fdt_add_pubkey tool to do
the needful. We also support capsule update for FIT images, and that
would mean adding some logic to call the fdt_add_pubkey for the
fdt_list. So implementing this is not a difficult thing at all.

But the main issue, or rather the only issue with this is that we are
getting an image with a different name, like u-boot-capsule-esl.bin as
the resulting image. But like I had mentioned earlier in our
discussions, we have platforms which boot the u-boot.bin binary. We
also have the ST boards which generate the fip image and use the
u-boot.dtb as the BL33_CFG. So generating a new image binary, or a new
DTB would break these boards. Not to mention that these platforms
would not be interested in using a different image just because they
are enabling some functionality on the platform.

>
> As you know I am not a fan of these opaque binaries when we have a
> nice self-describing format like devicetre. But we can worry about
> that problem another time.

I know, but this is what we have when we follow the UEFI
specification. It is not our design.

-sughosh

>
> > +   depends on EFI_CAPSULE_AUTHENTICATE
> > +   help
> > + Provides the path to the EFI Signature List file which will
> > + be embedded in the platform's device tree and used for
> > + capsule authentication at the time of capsule update.
> > +
> >  config EFI_DEVICE_PATH_TO_TEXT
> > bool "Device path to text protocol"
> > default y
> > diff --git a/lib/efi_loader/capsule_esl.dtsi.in 
> > b/lib/efi_loader/capsule_esl.dtsi.in
> > new file mode 100644
> > index 00..61a9f2b25e
> > --- /dev/null
> > +++ b/lib/efi_loader/capsule_esl.dtsi.in
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/**
> > + * Devicetree file with the public key EFI Signature List(ESL)
> > + * node. This file is used to generate the dtsi file to be
> > + * included into the DTB.
> > +*/
> > +/ {
> > +   signature {
> > +   capsule-key = /incbin/("ESL_BIN_FILE");
> > +   };
> > +};

Re: [PATCH v2 0/6] Add SGMII support for MAIN CPSW on TI's J7200 SoC

[Tom Rini]

On Wed, 02 Aug 2023 13:47:23 +0530, Siddharth Vadapalli wrote:

> This series adds support for SGMII mode to the CPSW driver to enable the
> functionality on TI's J7200 SoC.
> 
> Supporting SGMII mode also requires changes to the WIZ driver which acts
> as a wrapper for the SerDes used by the CPSW MAC to transmit data to the
> Ethernet PHY daughtercard mounted on the I2C GPIO Expander 2 connector on
> the J7200 EVM.
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH 3/3] sunxi: psci: implement PSCI on R528

[Sam Edwards]

On 8/15/23 15:59, Andre Przywara wrote:

Hi Sam,


Hi Andre,


So that's a bit more nasty indeed. I don't even know if R_CPUCFG really
makes sense here, as the _R_ term typically refers to the management
processor, which the D1/R528 don't have. Or at least the always-on power
domain, but then again this hardly relates to the secondary entry
point. I think the name was just used because the address matches the
one used in the H6.


Oh, no. That was my doing (and my reasoning) by suggesting that for 
inclusion in your series. Yours is good reasoning to be rid of it.



So taking a step back, I wonder if we should actually just define a
CONFIG_SUNXI_CPU_SOFT_ENTRY (or so) *Kconfig* symbol, which holds that
address, and let the per-SoC definition be solved in Kconfig instead.
Because SUNXI_R_CPUCFG_BASE and also SUNXI_RTC_BASE seem to be just
used as the base address for that purpose, with some magic offset
added, across all of U-Boot (ARMv8 FEL and v7 PSCI).


Mmh, since this is a block of soft registers for managing several 
functions of both cores, I think I'd rather point to the base of the 
block and still use an offset to get to the specific soft register. 
Allwinner may keep this layout for a 4-core chip in the near future or 
U-Boot may want to add code that sets the CPU0 hotplug flag, for example.


I'm not unwilling to do the Kconfig route, but just out of curiosity, 
what would your fallback plan be?



So can you try to work on that base? I will take care of
armv8/fel_utils.S, which uses some post-increment assembly trick to
keep the code small, which wouldn't work anymore. But I have an idea
how to solve this.


Before that, I think now might be a good time for me to send in the v2 
that I have so far; I doubt the final patch of my v2 series will pass 
review, but I'd like to keep us synced up (and clear away any patches in 
that series that do pass review off from my mental desktop).



Cheers,
Andre


Likewise,
Sam

Re: [PATCH] x86: Update cbmem driver

[Nable]

On 15.08.2023 01:42, Simon Glass:
> I believe the original intent was to indicate that the buffer had
> overflowed. But prompted by your review I took a look at the coreboot
> implementation and it now has an overflow flag.
>
> So I will send a v2 incorporating this.
Thank you for this investigation, v2 approach definitely makes sense.
Btw, is there any reason to mark 'struct cbmem_console' as packed?

Booting Windows 11

[Simon Glass]

Hi Heinrich,

I thought I would try booting Windows on U-Boot but it does not get
very far. Have you tried that? I note a ew odd things below. Is there
a validation suite for it?

https://github.com/sjg20/u-boot/tree/efi2

qemu-system-x86_64  -smp 4 -m 8G -serial mon:stdio -bios
/tmp/b/qemu-x86_64/u-boot.rom -drive
id=fisk,file=root.img,if=virtio,driver=raw -drive
id=disk,if=virtio,file=/vid/software/win/Win11_22H2_English_x64v2.iso

Scanning bootdev 'virtio-blk#0.bootdev':
efi_install_multiple_protocol_interfaces_int() EFI: Call:
efi_locate_device_path(protocol, , _handle)
efi_locate_device_path()   EFI: Entry efi_locate_device_path(Device
Path, becf6848, becf6840)
efi_locate_device_path() EFI: Call:
efi_locate_handle_buffer(BY_PROTOCOL, protocol, NULL, _handles,
)
efi_locate_handle_buffer()   EFI: Entry
efi_locate_handle_buffer(2, Device Path, ,
becf67b8, becf67b0)
efi_locate_handle_buffer()   EFI: Exit: efi_locate_handle_buffer: 0
efi_locate_device_path() EFI: 0 returned by
efi_locate_handle_buffer(BY_PROTOCOL, protocol, NULL, _handles,
)
efi_locate_device_path()   EFI: Exit: efi_locate_device_path: 14
efi_install_multiple_protocol_interfaces_int() EFI: 14 returned by


^ This seems unhappy because it is a virtio device?

 efi_locate_device_path(protocol, , _handle)
efi_install_multiple_protocol_interfaces_int() EFI: Call:
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
efi_install_protocol_interface()   EFI: Entry
efi_install_protocol_interface(becf6948, Device Path, 0,
bdcf2040)
efi_install_protocol_interface() EFI: handle bed1f820
efi_add_protocol() EFI: installed device path
'/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,5400)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,8200)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008200)'
efi_install_protocol_interface()   EFI: Exit: efi_install_protocol_interface: 0
efi_install_multiple_protocol_interfaces_int() EFI: 0 returned by
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
efi_install_multiple_protocol_interfaces_int() EFI: Call:
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
efi_install_protocol_interface()   EFI: Entry
efi_install_protocol_interface(becf6948, Block IO, 0,
bed1f850)
efi_install_protocol_interface() EFI: handle bed1f820
efi_install_protocol_interface()   EFI: Exit: efi_install_protocol_interface: 0
efi_install_multiple_protocol_interfaces_int() EFI: 0 returned by
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
Scanning bootdev 'virtio-blk#1.bootdev':
efi_install_multiple_protocol_interfaces_int() EFI: Call:
efi_locate_device_path(protocol, , _handle)
efi_locate_device_path()   EFI: Entry efi_locate_device_path(Device
Path, becf6848, becf6840)
efi_locate_device_path() EFI: Call:
efi_locate_handle_buffer(BY_PROTOCOL, protocol, NULL, _handles,
)
efi_locate_handle_buffer()   EFI: Entry
efi_locate_handle_buffer(2, Device Path, ,
becf67b8, becf67b0)
efi_locate_handle_buffer()   EFI: Exit: efi_locate_handle_buffer: 0
efi_locate_device_path() EFI: 0 returned by
efi_locate_handle_buffer(BY_PROTOCOL, protocol, NULL, _handles,
)
efi_locate_device_path()   EFI: Exit: efi_locate_device_path: 14
efi_install_multiple_protocol_interfaces_int() EFI: 14 returned by
efi_locate_device_path(protocol, , _handle)
efi_install_multiple_protocol_interfaces_int() EFI: Call:
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
efi_install_protocol_interface()   EFI: Entry
efi_install_protocol_interface(becf6948, Device Path, 0,
bdcf0040)
efi_install_protocol_interface() EFI: handle bed24ef0
efi_add_protocol() EFI: installed device path
'/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,5400)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,82000100)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,160082000100)'
efi_install_protocol_interface()   EFI: Exit: efi_install_protocol_interface: 0
efi_install_multiple_protocol_interfaces_int() EFI: 0 returned by
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
efi_install_multiple_protocol_interfaces_int() EFI: Call:
efi_install_protocol_interface(handle, protocol, EFI_NATIVE_INTERFACE,
protocol_interface)
efi_install_protocol_interface()   EFI: Entry
efi_install_protocol_interface(becf6948, Block IO, 0,
bed24f20)
efi_install_protocol_interface() EFI: handle bed24ef0
efi_install_protocol_interface()   EFI: Exit: efi_install_protocol_interface: 0

Re: [PATCH 3/3] sunxi: psci: implement PSCI on R528

[Andre Przywara]

On Tue, 15 Aug 2023 13:17:33 -0600
Sam Edwards  wrote:

Hi Sam,

> On 8/14/23 08:16, Andre Przywara wrote:
> > Hi Sam,
> >   
> >> This patch adds the necessary code to make nonsec booting and PSCI
> >> secondary core management functional on the R528/T113.  
> > 
> > Unfortunately this patch breaks the build on older 32-bit SoCs, as
> > SUNXI_CPUX_BASE is not defined there. That's a typical problem of the
> > "C-if" approach, but typically there is a clean, albeit not trivial,
> > solution:
> > 
> > It seems like SUNXI_CPUX_BASE and SUNXI_CPUCFG_BASE are mutually
> > exclusive, and I actually carry a "#define SUNXI_CPUCFG_BASE 0" hack in my
> > patches already.
> > So I wonder if we should unify those two into SUNXI_CPUCFG_BASE, with the
> > following rework:  
> 
> The SUNXI_CPUX_BASE -> SUNXI_CPUCFG_BASE rename worked excellently. 
> We're having the same problem with SUNXI_R_CPUCFG_BASE as well, though. 
> How do you want to handle that?

So that's a bit more nasty indeed. I don't even know if R_CPUCFG really
makes sense here, as the _R_ term typically refers to the management
processor, which the D1/R528 don't have. Or at least the always-on power
domain, but then again this hardly relates to the secondary entry
point. I think the name was just used because the address matches the
one used in the H6. Anyway, I got the impression that Allwinner just
uses registers wherever they find them, and that they don't care too
much about logical grouping or compatibility.

So taking a step back, I wonder if we should actually just define a
CONFIG_SUNXI_CPU_SOFT_ENTRY (or so) *Kconfig* symbol, which holds that
address, and let the per-SoC definition be solved in Kconfig instead.
Because SUNXI_R_CPUCFG_BASE and also SUNXI_RTC_BASE seem to be just
used as the base address for that purpose, with some magic offset
added, across all of U-Boot (ARMv8 FEL and v7 PSCI).

So can you try to work on that base? I will take care of
armv8/fel_utils.S, which uses some post-increment assembly trick to
keep the code small, which wouldn't work anymore. But I have an idea
how to solve this.

Cheers,
Andre

Re: [PATCH 1/6] ufs: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS

[Bhupesh Sharma]

On Wed, 16 Aug 2023 at 03:10, Marek Vasut  wrote:
>
> On 8/15/23 23:08, Bhupesh Sharma wrote:
> > On Wed, 16 Aug 2023 at 02:31, Marek Vasut  wrote:
> >>
> >> On 8/15/23 22:04, Bhupesh Sharma wrote:
> >>> Hi Marek,
> >>>
> >>> On 8/14/23 5:22 AM, Marek Vasut wrote:
>  Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
>  support 64-bit addressing.
> 
>  Ported from Linux kernel commit
>  6554400d6f66 ("scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS")
>  with ufs_scsi_buffer_aligned() based on U-Boot generic bounce buffer.
> 
>  Signed-off-by: Marek Vasut 
>  ---
>  Cc: Faiz Abbas 
>  ---
> drivers/ufs/ufs.c | 26 ++
> drivers/ufs/ufs.h |  6 ++
> 2 files changed, 32 insertions(+)
> 
>  diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
>  index 3bf1a95e7f2..da0550d98c6 100644
>  --- a/drivers/ufs/ufs.c
>  +++ b/drivers/ufs/ufs.c
>  @@ -8,6 +8,7 @@
>  * Copyright (C) 2019 Texas Instruments Incorporated -
>  http://www.ti.com
>  */
>  +#include 
> #include 
> #include 
> #include 
>  @@ -1889,6 +1890,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
>  ufs_hba_ops *hba_ops)
> /* Read capabilties registers */
> hba->capabilities = ufshcd_readl(hba, 
>  REG_CONTROLLER_CAPABILITIES);
>  +if (hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS)
>  +hba->capabilities &= ~MASK_64_ADDRESSING_SUPPORT;
> /* Get UFS version supported by the controller */
> hba->version = ufshcd_get_ufs_version(hba);
>  @@ -1942,8 +1945,31 @@ int ufs_scsi_bind(struct udevice *ufs_dev,
>  struct udevice **scsi_devp)
> return ret;
> }
>  +#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
>  +static int ufs_scsi_buffer_aligned(struct udevice *scsi_dev, struct
>  bounce_buffer *state)
>  +{
>  +#ifdef CONFIG_PHYS_64BIT
>  +struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
>  +uintptr_t ubuf = (uintptr_t)state->user_buffer;
>  +size_t len = state->len_aligned;
>  +
>  +/* Check if below 32bit boundary */
>  +if ((hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS) &&
>  +((ubuf >> 32) || (ubuf + len) >> 32)) {
>  +dev_dbg(scsi_dev, "Buffer above 32bit boundary %lx-%lx\n",
>  +ubuf, ubuf + len);
>  +return 0;
>  +}
>  +#endif
>  +return 1;
>  +}
>  +#endif/* CONFIG_BOUNCE_BUFFER */
>  +
> static struct scsi_ops ufs_ops = {
> .exec= ufs_scsi_exec,
>  +#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
>  +.buffer_aligned= ufs_scsi_buffer_aligned,
>  +#endif/* CONFIG_BOUNCE_BUFFER */
> };
> int ufs_probe_dev(int index)
>  diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
>  index 8a38832b05f..070db0dce68 100644
>  --- a/drivers/ufs/ufs.h
>  +++ b/drivers/ufs/ufs.h
>  @@ -719,6 +719,12 @@ struct ufs_hba {
>  */
> #define UFSHCD_QUIRK_BROKEN_LCC0x1
>  +/*
>  + * This quirk needs to be enabled if the host controller has
>  + * 64-bit addressing supported capability but it doesn't work.
>  + */
>  +#define UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS0x2
>  +
> /* Virtual memory reference */
> struct utp_transfer_cmd_desc *ucdl;
> struct utp_transfer_req_desc *utrdl;
> >>>
> >>> For this and the follow-up patch, I think implementing or at least
> >>> supporting all the quirks currently supported by the Linux UFS driver
> >>> makes sense as newer controllers do support these quirks.
> >>
> >> I disagree. There is no point in implementing quirks which cannot be
> >> tested or may not even be relevant to U-Boot. Quirks which are needed
> >> should be added one by one.
>
> I assume you agree we should not add all quirks at once ?
>
> > But the format you use for adding new quiks in u-boot is still in sync
> > with Linux version 3.10. Can we atleast use the newer ( 1<< 7) kind of
> > format for consistency.
>
> Feel free to update quirks to BIT() macro.
>
> We should enumerate the quirks in order instead of starting with BIT(7)
> however.

Qualcomm UFS controllers support a few quirks from the list so the
numbering can be taken care of in my patch.

But since 'include/ufs/ufs_quirks.h' in Linux already uses the (1 <<7)
kind of format we can use the same as it would make future backporting
from Linux easier.

Thanks.

[PATCH 6/6] board: gateworks: venice: updates for imx8mp-venice-gw74xx revB PCB

[Tim Harvey]

Update the imx8mp-venice-gw74xx for revB:
 - add CAN1
 - add TIS-TPM on SPI2
 - add FAN controller
 - fix PMIC I2C bus (revA PMIC I2C was non-functional so no need for
   backward compatible option)
 - M2 socket GPIO's moved

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi |  70 +++--
 arch/arm/dts/imx8mp-venice-gw74xx.dts | 263 +++---
 arch/arm/dts/imx8mp-venice-u-boot.dtsi|   8 +
 arch/arm/dts/imx8mp-venice.dts|  14 +
 board/gateworks/venice/spl.c  |   4 +-
 5 files changed, 227 insertions(+), 132 deletions(-)

diff --git a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
index c3fb040080b6..501bc0ce200e 100644
--- a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
@@ -53,67 +53,81 @@
  {
bootph-pre-ram;
 
-   pcie1_wdis_hog {
+   m2_pin20 {
+   gpio-hog;
+   input;
+   gpios = <6 GPIO_ACTIVE_HIGH>;
+   line-name = "m2_pin20";
+   };
+
+   m2_pin22 {
+   gpio-hog;
+   input;
+   gpios = <11 GPIO_ACTIVE_HIGH>;
+   line-name = "m2_pin22";
+   };
+
+   tpm_rst_hog {
gpio-hog;
-   gpios = <17 GPIO_ACTIVE_HIGH>;
output-high;
-   line-name = "pcie1_wdis#";
+   gpios = <12 GPIO_ACTIVE_HIGH>;
+   line-name = "tpm_rst#";
};
 
-   pcie2_wdis_hog {
+   pcie1_wdis_hog {
gpio-hog;
-   gpios = <18 GPIO_ACTIVE_HIGH>;
output-high;
-   line-name = "pcie2_wdis#";
+   gpios = <13 GPIO_ACTIVE_HIGH>;
+   line-name = "pcie1_wdis#";
};
 
pcie3_wdis_hog {
gpio-hog;
-   gpios = <14 GPIO_ACTIVE_HIGH>;
output-high;
+   gpios = <14 GPIO_ACTIVE_HIGH>;
line-name = "pcie3_wdis#";
};
-};
 
- {
-   bootph-pre-ram;
-
-   m2_dis2_hog {
+   pcie2_wdis_hog {
gpio-hog;
-   gpios = <0 GPIO_ACTIVE_HIGH>;
output-high;
-   line-name = "m2_gdis#";
+   gpios = <18 GPIO_ACTIVE_HIGH>;
+   line-name = "pcie2_wdis#";
};
+};
+
+ {
+   bootph-pre-ram;
 
-   m2rst_hog {
+   m2_rst {
gpio-hog;
+   output-low;
gpios = <6 GPIO_ACTIVE_HIGH>;
-   output-high;
-   line-name = "m2_rst#";
+   line-name = "m2_rst";
};
+};
+
+ {
+   bootph-pre-ram;
 
-   m2_off_hog {
+   m2_off {
gpio-hog;
-   gpios = <14 GPIO_ACTIVE_HIGH>;
output-high;
+   gpios = <2 GPIO_ACTIVE_HIGH>;
line-name = "m2_off#";
};
-};
-
- {
-   bootph-pre-ram;
 
-   m2_dis1_hog {
+   m2_wdis {
gpio-hog;
-   gpios = <18 GPIO_ACTIVE_HIGH>;
output-high;
+   gpios = <18 GPIO_ACTIVE_HIGH>;
line-name = "m2_wdis#";
};
 
rs485_en {
gpio-hog;
-   gpios = <31 GPIO_ACTIVE_HIGH>;
output-low;
+   gpios = <31 GPIO_ACTIVE_HIGH>;
line-name = "rs485_en";
};
 };
@@ -123,15 +137,15 @@
 
rs485_half {
gpio-hog;
-   gpios = <0 GPIO_ACTIVE_HIGH>;
output-low;
+   gpios = <0 GPIO_ACTIVE_HIGH>;
line-name = "rs485_hd";
};
 
rs485_term {
gpio-hog;
-   gpios = <1 GPIO_ACTIVE_HIGH>;
output-low;
+   gpios = <1 GPIO_ACTIVE_HIGH>;
line-name = "rs485_term";
};
 };
diff --git a/arch/arm/dts/imx8mp-venice-gw74xx.dts 
b/arch/arm/dts/imx8mp-venice-gw74xx.dts
index ceeca4966fc5..7eb285315739 100644
--- a/arch/arm/dts/imx8mp-venice-gw74xx.dts
+++ b/arch/arm/dts/imx8mp-venice-gw74xx.dts
@@ -125,12 +125,22 @@
regulator-max-microvolt = <500>;
};
 
+   reg_can1_stby: regulator-can1-stby {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 = <_reg_can1>;
+   regulator-name = "can1_stby";
+   gpio = < 19 GPIO_ACTIVE_LOW>;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
reg_can2_stby: regulator-can2-stby {
compatible = "regulator-fixed";
pinctrl-names = "default";
-   pinctrl-0 = <_reg_can>;
+   pinctrl-0 = <_reg_can2>;
regulator-name = "can2_stby";
-   gpio = < 19 GPIO_ACTIVE_LOW>;
+   gpio = < 5 GPIO_ACTIVE_LOW>;

[PATCH 5/6] board: gateworks: venice: add imx8mm-gw7905-0x support

[Tim Harvey]

The Gateworks imx8mm-venice-gw7905-0x consists of a SOM + baseboard.

The GW700x SOM contains the following:
 - i.MX8M Mini SoC
 - LPDDR4 memory
 - eMMC Boot device
 - Gateworks System Controller (GSC) with integrated EEPROM, button
   controller, and ADC's
 - RGMII PHY
 - PMIC
 - SOM connector providing:
  - FEC GbE MII
  - 1x SPI
  - 2x I2C
  - 4x UART
  - 2x USB 2.0
  - 1x PCI
  - 1x SDIO (4-bit 3.3V)
  - 1x SDIO (4-bit 3.3V/1.8V)
  - GPIO

The GW7905 Baseboard contains the following:
 - GPS
 - microSD
 - off-board I/O connector with I2C, SPI, GPIO
 - EERPOM
 - PCIe clock generator
 - 1x full-length miniPCIe socket with PCI/USB3 (via mux) and USB2.0
 - 1x half-length miniPCIe socket with USB2.0 and USB3.0
 - USB 3.0 HUB
 - USB Type-C with USB PD Sink capability and peripheral support
 - USB Type-C with USB 3.0 host support

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mm-venice-gw7905-0x-u-boot.dtsi   |  58 
 arch/arm/dts/imx8mm-venice-gw7905-0x.dts  |  28 ++
 arch/arm/dts/imx8mm-venice-gw7905.dtsi| 303 ++
 configs/imx8mm_venice_defconfig   |   2 +-
 5 files changed, 391 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx8mm-venice-gw7905-0x-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-venice-gw7905-0x.dts
 create mode 100644 arch/arm/dts/imx8mm-venice-gw7905.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9b29c809dfd7..7d5f3efa04cc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1011,6 +1011,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-venice-gw7902.dtb \
imx8mm-venice-gw7903.dtb \
imx8mm-venice-gw7904.dtb \
+   imx8mm-venice-gw7905-0x.dtb \
imx8mm-verdin-wifi-dev.dtb \
phycore-imx8mm.dtb \
imx8mn-bsh-smm-s2.dtb \
diff --git a/arch/arm/dts/imx8mm-venice-gw7905-0x-u-boot.dtsi 
b/arch/arm/dts/imx8mm-venice-gw7905-0x-u-boot.dtsi
new file mode 100644
index ..c259026d1a8f
--- /dev/null
+++ b/arch/arm/dts/imx8mm-venice-gw7905-0x-u-boot.dtsi
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+#include "imx8mm-venice-gw700x-u-boot.dtsi"
+
+ {
+   app_gpioa {
+   gpio-hog;
+   input;
+   gpios = <13 GPIO_ACTIVE_HIGH>;
+   line-name = "gpioa";
+   };
+
+   app_gpiob {
+   gpio-hog;
+   input;
+   gpios = <14 GPIO_ACTIVE_HIGH>;
+   line-name = "gpiob";
+   };
+};
+
+ {
+   pci_usb_sel {
+   gpio-hog;
+   output-low;
+   gpios = <3 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_usb_sel";
+   };
+
+   pci_wdis {
+   gpio-hog;
+   output-high;
+   gpios = <7 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_wdis#";
+   };
+};
+
+ {
+   app_gpioc {
+   gpio-hog;
+   input;
+   gpios = <4 GPIO_ACTIVE_HIGH>;
+   line-name = "gpioc";
+   };
+
+   app_gpiod {
+   gpio-hog;
+   input;
+   gpios = <5 GPIO_ACTIVE_HIGH>;
+   line-name = "gpiod";
+   };
+};
+
+/* Disable SOM interfaces not used on baseboard */
+ {
+   status = "disabled";
+};
diff --git a/arch/arm/dts/imx8mm-venice-gw7905-0x.dts 
b/arch/arm/dts/imx8mm-venice-gw7905-0x.dts
new file mode 100644
index ..914753f062cd
--- /dev/null
+++ b/arch/arm/dts/imx8mm-venice-gw7905-0x.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include "imx8mm.dtsi"
+#include "imx8mm-venice-gw700x.dtsi"
+#include "imx8mm-venice-gw7905.dtsi"
+
+/ {
+   model = "Gateworks Venice GW7905-0x i.MX8MM Development Kit";
+   compatible = "gateworks,imx8mm-gw7905-0x", "fsl,imx8mm";
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+/* Disable SOM interfaces not used on baseboard */
+ {
+   status = "disabled";
+};
+
+ {
+   status = "disabled";
+};
diff --git a/arch/arm/dts/imx8mm-venice-gw7905.dtsi 
b/arch/arm/dts/imx8mm-venice-gw7905.dtsi
new file mode 100644
index ..9646eb9e4928
--- /dev/null
+++ b/arch/arm/dts/imx8mm-venice-gw7905.dtsi
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   led-controller {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_leds>;
+
+   led-0 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 0 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   linux,default-trigger = "heartbeat";
+   };
+
+   led-1 {
+

[PATCH 3/6] board: gateworks: venice: add imx8mp-gw72xx-2x support

[Tim Harvey]

The Gateworks imx8mp-venice-gw72xx-2x consists of a SOM + baseboard.

The GW702x SOM contains the following:
 - i.MX8M Plus SoC
 - LPDDR4 memory
 - eMMC Boot device
 - Gateworks System Controller (GSC) with integrated EEPROM, button
   controller, and ADC's
 - PMIC
 - SOM connector providing:
  - eQoS GbE MII
  - 1x SPI
  - 2x I2C
  - 4x UART
  - 2x USB 3.0
  - 1x PCI
  - 1x SDIO (4-bit 3.3V)
  - 1x SDIO (4-bit 3.3V/1.8V)
  - GPIO

The GW72xx Baseboard contains the following:
 - 1x RJ45 GbE (eQoS from SOM)
 - 1x RJ45 GbE (PCI)
 - off-board I/O connector with MIPI-CSI (3-lane), MIPI-DSI (4-lane),
 - off-board I/O connector with RS232/RS485
 - off-board I/O connector with SPI
 - off-board I/O connector with I2C, UART, and GPIO
   I2C, I2S and GPIO
 - microSD (1.8V/3.3V)
 - GPS
 - Accelerometer
 - EERPOM
 - USB 3.0 Hub
 - Front Panel bi-color LED
 - re-chargeable battery (for RTC)
 - PCIe clock generator
 - PCIe switch
 - 1x USB Type-A host socket with USB 3.0 support
 - 1x USB OTG with USB 2.0 support
 - 1x MiniPCIe socket with PCI and USB 2.0
 - 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
 - Wide range DC input supply

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mp-venice-gw72xx-2x-u-boot.dtsi   |  89 +
 arch/arm/dts/imx8mp-venice-gw72xx-2x.dts  |  19 +
 arch/arm/dts/imx8mp-venice-gw72xx.dtsi| 371 ++
 configs/imx8mp_venice_defconfig   |   2 +-
 5 files changed, 481 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx8mp-venice-gw72xx-2x-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-venice-gw72xx-2x.dts
 create mode 100644 arch/arm/dts/imx8mp-venice-gw72xx.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6a2ec7c88b88..6e8ed1255580 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1036,6 +1036,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mp-phyboard-pollux-rdk.dtb \
imx8mp-venice.dtb \
imx8mp-venice-gw71xx-2x.dtb \
+   imx8mp-venice-gw72xx-2x.dtb \
imx8mp-venice-gw74xx.dtb \
imx8mp-venice-gw7905-2x.dtb \
imx8mp-verdin-wifi-dev.dtb \
diff --git a/arch/arm/dts/imx8mp-venice-gw72xx-2x-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw72xx-2x-u-boot.dtsi
new file mode 100644
index ..7f2609ab5469
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw72xx-2x-u-boot.dtsi
@@ -0,0 +1,89 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+#include "imx8mp-venice-gw702x-u-boot.dtsi"
+
+ {
+   dio_1 {
+   gpio-hog;
+   input;
+   gpios = <8 GPIO_ACTIVE_HIGH>;
+   line-name = "dio1";
+   };
+
+   dio_0 {
+   gpio-hog;
+   input;
+   gpios = <11 GPIO_ACTIVE_HIGH>;
+   line-name = "dio0";
+   };
+
+   pci_usb_sel {
+   gpio-hog;
+   output-low;
+   gpios = <14 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_usb_sel";
+   };
+
+   mipi_gpio4 {
+   gpio-hog;
+   input;
+   gpios = <17 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio4";
+   };
+
+   rs485_en {
+   gpio-hog;
+   output-low;
+   gpios = <22 GPIO_ACTIVE_HIGH>;
+   line-name = "rs485_en";
+   };
+
+   rs485_term {
+   gpio-hog;
+   output-low;
+   gpios = <23 GPIO_ACTIVE_HIGH>;
+   line-name = "rs485_term";
+   };
+
+   mipi_gpio1 {
+   gpio-hog;
+   input;
+   gpios = <24 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio1";
+   };
+
+   mipi_gpio3 {
+   gpio-hog;
+   input;
+   gpios = <25 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio3";
+   };
+
+   mipi_gpio2 {
+   gpio-hog;
+   input;
+   gpios = <26 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio2";
+   };
+
+   rs485_hd {
+   gpio-hog;
+   output-low;
+   gpios = <27 GPIO_ACTIVE_HIGH>;
+   line-name = "rs485_hd";
+   };
+
+   pci_wdis {
+   gpio-hog;
+   output-high;
+   gpios = <28 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_wdis#";
+   };
+};
+
+/* gpio-usb-con not supported yet in U-Boot so make this a host for now */
+_dwc3_0 {
+   dr_mode = "host";
+};
diff --git a/arch/arm/dts/imx8mp-venice-gw72xx-2x.dts 
b/arch/arm/dts/imx8mp-venice-gw72xx-2x.dts
new file mode 100644
index ..255e36f66b00
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw72xx-2x.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+#include "imx8mp-venice-gw702x.dtsi"
+#include 

[PATCH 4/6] board: gateworks: venice: add imx8mp-gw73xx-2x support

[Tim Harvey]

The Gateworks imx8mp-venice-gw73xx-2x consists of a SOM + baseboard.

The GW702x SOM contains the following:
 - i.MX8M Plus SoC
 - LPDDR4 memory
 - eMMC Boot device
 - Gateworks System Controller (GSC) with integrated EEPROM, button
   controller, and ADC's
 - PMIC
 - SOM connector providing:
  - eQoS GbE MII
  - 1x SPI
  - 2x I2C
  - 4x UART
  - 2x USB 3.0
  - 1x PCI
  - 1x SDIO (4-bit 3.3V)
  - 1x SDIO (4-bit 3.3V/1.8V)
  - GPIO

The GW73xx Baseboard contains the following:
 - 1x RJ45 GbE (eQoS from SOM)
 - 1x RJ45 GbE (PCI)
 - off-board I/O connector with MIPI-CSI (3-lane), MIPI-DSI (4-lane),
 - off-board I/O connector with RS232/RS485
 - off-board I/O connector with SPI
 - off-board I/O connector with I2C, UART, and GPIO
   I2C, I2S and GPIO
 - microSD (1.8V/3.3V)
 - GPS
 - Accelerometer
 - EERPOM
 - USB 3.0 Hub
 - Front Panel bi-color LED
 - re-chargeable battery (for RTC)
 - PCIe clock generator
 - PCIe switch
 - on-board 802.11abgnac 1x1 WiFi and Bluetooth 5.2
 - 1x USB Type-A host socket with USB 3.0 support
 - 1x USB OTG with USB 2.0 support
 - 2x MiniPCIe socket with PCI and USB 2.0
 - 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
 - Wide range DC input supply

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi   |  95 
 arch/arm/dts/imx8mp-venice-gw73xx-2x.dts  |  19 +
 arch/arm/dts/imx8mp-venice-gw73xx.dtsi| 414 ++
 configs/imx8mp_venice_defconfig   |   2 +-
 5 files changed, 530 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-venice-gw73xx-2x.dts
 create mode 100644 arch/arm/dts/imx8mp-venice-gw73xx.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6e8ed1255580..9b29c809dfd7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1037,6 +1037,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mp-venice.dtb \
imx8mp-venice-gw71xx-2x.dtb \
imx8mp-venice-gw72xx-2x.dtb \
+   imx8mp-venice-gw73xx-2x.dtb \
imx8mp-venice-gw74xx.dtb \
imx8mp-venice-gw7905-2x.dtb \
imx8mp-verdin-wifi-dev.dtb \
diff --git a/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
new file mode 100644
index ..70433c073293
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw73xx-2x-u-boot.dtsi
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+#include "imx8mp-venice-gw702x-u-boot.dtsi"
+
+ {
+   reset-gpios = < 14 GPIO_ACTIVE_LOW>;
+   reset-delay-us = <1000>;
+   reset-post-delay-us = <30>;
+};
+
+ {
+   dio_1 {
+   gpio-hog;
+   input;
+   gpios = <8 GPIO_ACTIVE_HIGH>;
+   line-name = "dio1";
+   };
+
+   dio_0 {
+   gpio-hog;
+   input;
+   gpios = <11 GPIO_ACTIVE_HIGH>;
+   line-name = "dio0";
+   };
+
+   pci_usb_sel {
+   gpio-hog;
+   output-low;
+   gpios = <14 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_usb_sel";
+   };
+
+   mipi_gpio4 {
+   gpio-hog;
+   input;
+   gpios = <17 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio4";
+   };
+
+   rs485_en {
+   gpio-hog;
+   output-low;
+   gpios = <22 GPIO_ACTIVE_HIGH>;
+   line-name = "rs485_en";
+   };
+
+   rs485_term {
+   gpio-hog;
+   output-low;
+   gpios = <23 GPIO_ACTIVE_HIGH>;
+   line-name = "rs485_term";
+   };
+
+   mipi_gpio1 {
+   gpio-hog;
+   input;
+   gpios = <24 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio1";
+   };
+
+   mipi_gpio3 {
+   gpio-hog;
+   input;
+   gpios = <25 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio3";
+   };
+
+   mipi_gpio2 {
+   gpio-hog;
+   input;
+   gpios = <26 GPIO_ACTIVE_HIGH>;
+   line-name = "mipi_gpio2";
+   };
+
+   rs485_hd {
+   gpio-hog;
+   output-low;
+   gpios = <27 GPIO_ACTIVE_HIGH>;
+   line-name = "rs485_hd";
+   };
+
+   pci_wdis {
+   gpio-hog;
+   output-high;
+   gpios = <28 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_wdis#";
+   };
+};
+
+/* gpio-usb-con not supported yet in U-Boot so make this a host for now */
+_dwc3_0 {
+   dr_mode = "host";
+};
diff --git a/arch/arm/dts/imx8mp-venice-gw73xx-2x.dts 
b/arch/arm/dts/imx8mp-venice-gw73xx-2x.dts
new file mode 100644
index ..000fd15e0c07
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw73xx-2x.dts
@@ -0,0 +1,19 @@
+// 

[PATCH 2/6] board: gateworks: venice: add imx8mp-gw71xx-2x support

[Tim Harvey]

The Gateworks imx8mp-venice-gw71xx-2x consists of a SOM + baseboard.

The GW702x SOM contains the following:
 - i.MX8M Plus SoC
 - LPDDR4 memory
 - eMMC Boot device
 - Gateworks System Controller (GSC) with integrated EEPROM, button
   controller, and ADC's
 - PMIC
 - SOM connector providing:
  - eQoS GbE MII
  - 1x SPI
  - 2x I2C
  - 4x UART
  - 2x USB 3.0
  - 1x PCI
  - 1x SDIO (4-bit 3.3V)
  - 1x SDIO (4-bit 3.3V/1.8V)
  - GPIO

The GW71xx Baseboard contains the following:
 - 1x RJ45 GbE (eQoS from SOM)
 - off-board I/O connector with I2C, SPI, UART, and GPIO
 - Front Panel bi-color LED
 - re-chargeable battery (for RTC)
 - PCIe clock generator
 - 1x USB Type-C connector supporting USB 2.0 host mode with VBUS
 - 1x MiniPCIe socket with SIM, PCI/USB 3.0 (mux), and USB 2.0
 - GPS
 - Accelerometer
 - EERPOM
 - Wide range DC input supply

Signed-off-by: Tim Harvey 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi   |  54 
 arch/arm/dts/imx8mp-venice-gw71xx-2x.dts  |  19 ++
 arch/arm/dts/imx8mp-venice-gw71xx.dtsi| 236 ++
 configs/imx8mp_venice_defconfig   |   2 +-
 5 files changed, 311 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mp-venice-gw71xx-2x.dts
 create mode 100644 arch/arm/dts/imx8mp-venice-gw71xx.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bd518064f35f..6a2ec7c88b88 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1035,6 +1035,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mp-msc-sm2s.dtb \
imx8mp-phyboard-pollux-rdk.dtb \
imx8mp-venice.dtb \
+   imx8mp-venice-gw71xx-2x.dtb \
imx8mp-venice-gw74xx.dtb \
imx8mp-venice-gw7905-2x.dtb \
imx8mp-verdin-wifi-dev.dtb \
diff --git a/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi 
b/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
new file mode 100644
index ..5c33f8c9cdcf
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw71xx-2x-u-boot.dtsi
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+#include "imx8mp-venice-gw702x-u-boot.dtsi"
+
+ {
+   dio_1 {
+   gpio-hog;
+   input;
+   gpios = <8 GPIO_ACTIVE_HIGH>;
+   line-name = "dio1";
+   };
+
+   dio_0 {
+   gpio-hog;
+   input;
+   gpios = <11 GPIO_ACTIVE_HIGH>;
+   line-name = "dio0";
+   };
+
+   pci_usb_sel {
+   gpio-hog;
+   output-low;
+   gpios = <14 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_usb_sel";
+   };
+
+   dio_3 {
+   gpio-hog;
+   input;
+   gpios = <24 GPIO_ACTIVE_HIGH>;
+   line-name = "dio3";
+   };
+
+   dio_2 {
+   gpio-hog;
+   input;
+   gpios = <26 GPIO_ACTIVE_HIGH>;
+   line-name = "dio2";
+   };
+
+   pci_wdis {
+   gpio-hog;
+   output-high;
+   gpios = <28 GPIO_ACTIVE_HIGH>;
+   line-name = "pci_wdis#";
+   };
+};
+
+/* gpio-usb-con not supported yet in U-Boot so make this a host for now */
+_dwc3_0 {
+   dr_mode = "host";
+};
diff --git a/arch/arm/dts/imx8mp-venice-gw71xx-2x.dts 
b/arch/arm/dts/imx8mp-venice-gw71xx-2x.dts
new file mode 100644
index ..53120fc9cd7f
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw71xx-2x.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include "imx8mp.dtsi"
+#include "imx8mp-venice-gw702x.dtsi"
+#include "imx8mp-venice-gw71xx.dtsi"
+
+/ {
+   model = "Gateworks Venice GW71xx-2x i.MX8MP Development Kit";
+   compatible = "gateworks,imx8mp-gw71xx-2x", "fsl,imx8mp";
+
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/imx8mp-venice-gw71xx.dtsi 
b/arch/arm/dts/imx8mp-venice-gw71xx.dtsi
new file mode 100644
index ..86999f52d4b2
--- /dev/null
+++ b/arch/arm/dts/imx8mp-venice-gw71xx.dtsi
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2023 Gateworks Corporation
+ */
+
+#include 
+#include 
+#include 
+
+/ {
+   led-controller {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_leds>;
+
+   led-0 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   linux,default-trigger = "heartbeat";
+   };
+
+   led-1 {
+   function = LED_FUNCTION_STATUS;
+   color = ;
+   gpios = < 5 

[PATCH 1/6] board: gateworks: venice: fix gw7904

[Tim Harvey]

Add missing imx8mm-venice-gw7904 to CONFIG_OF_LIST

Fixes commit 61e7f9732565 ("board: gateworks: venice: add imx8mm-gw7904 
support")
Signed-off-by: Tim Harvey 
---
 configs/imx8mm_venice_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig
index a485910a5299..4fba8eb2438b 100644
--- a/configs/imx8mm_venice_defconfig
+++ b/configs/imx8mm_venice_defconfig
@@ -75,7 +75,7 @@ CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="imx8mm-venice imx8mm-venice-gw71xx-0x imx8mm-venice-gw72xx-0x 
imx8mm-venice-gw73xx-0x imx8mm-venice-gw7901 imx8mm-venice-gw7902 
imx8mm-venice-gw7903"
+CONFIG_OF_LIST="imx8mm-venice imx8mm-venice-gw71xx-0x imx8mm-venice-gw72xx-0x 
imx8mm-venice-gw73xx-0x imx8mm-venice-gw7901 imx8mm-venice-gw7902 
imx8mm-venice-gw7903 imx8mm-venice-gw7904"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
 CONFIG_SYS_MMC_ENV_DEV=2
-- 
2.25.1

Re: [PATCH 3/6] ufs: Handle UFS 3.0 controllers

[Marek Vasut]

On 8/15/23 23:05, Bhupesh Sharma wrote:

On Wed, 16 Aug 2023 at 02:31, Marek Vasut  wrote:


On 8/15/23 19:14, Bhupesh Sharma wrote:

On Mon, 14 Aug 2023 at 05:23, Marek Vasut
 wrote:


Extend the version check to handle UFS 3.0 controllers as well.
Tested on R-Car S4 UFS 3.0 controller.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
   drivers/ufs/ufs.c | 3 ++-
   drivers/ufs/ufs.h | 1 +
   2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 261ae2843c2..58830c8ddca 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -1903,7 +1903,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct 
ufs_hba_ops *hba_ops)
  if (hba->version != UFSHCI_VERSION_10 &&
  hba->version != UFSHCI_VERSION_11 &&
  hba->version != UFSHCI_VERSION_20 &&
-   hba->version != UFSHCI_VERSION_21)
+   hba->version != UFSHCI_VERSION_21 &&
+   hba->version != UFSHCI_VERSION_30)
  dev_err(hba->dev, "invalid UFS version 0x%x\n",
  hba->version);

diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 33ca5f29812..ef7728fc39e 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -781,6 +781,7 @@ enum {
  UFSHCI_VERSION_11 = 0x00010100, /* 1.1 */
  UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
  UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
+   UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
   };

   /* Interrupt disable masks */
--
2.40.1


SInce the Qualcomm UFS HC controllers are even newer / greater version
values, we can drop this patch in favour of my UFS patch here:
https://lists.denx.de/pipermail/u-boot/2023-August/527215.html


Why not keep validating the version ?


How many versions would one want to validate when the newer versions
are 4.1 or greater?


I'd say the ones which are known and tested.

Re: [PATCH 1/6] ufs: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS

[Marek Vasut]

On 8/15/23 23:08, Bhupesh Sharma wrote:

On Wed, 16 Aug 2023 at 02:31, Marek Vasut  wrote:


On 8/15/23 22:04, Bhupesh Sharma wrote:

Hi Marek,

On 8/14/23 5:22 AM, Marek Vasut wrote:

Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
support 64-bit addressing.

Ported from Linux kernel commit
6554400d6f66 ("scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS")
with ufs_scsi_buffer_aligned() based on U-Boot generic bounce buffer.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
   drivers/ufs/ufs.c | 26 ++
   drivers/ufs/ufs.h |  6 ++
   2 files changed, 32 insertions(+)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 3bf1a95e7f2..da0550d98c6 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -8,6 +8,7 @@
* Copyright (C) 2019 Texas Instruments Incorporated -
http://www.ti.com
*/
+#include 
   #include 
   #include 
   #include 
@@ -1889,6 +1890,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
ufs_hba_ops *hba_ops)
   /* Read capabilties registers */
   hba->capabilities = ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES);
+if (hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS)
+hba->capabilities &= ~MASK_64_ADDRESSING_SUPPORT;
   /* Get UFS version supported by the controller */
   hba->version = ufshcd_get_ufs_version(hba);
@@ -1942,8 +1945,31 @@ int ufs_scsi_bind(struct udevice *ufs_dev,
struct udevice **scsi_devp)
   return ret;
   }
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+static int ufs_scsi_buffer_aligned(struct udevice *scsi_dev, struct
bounce_buffer *state)
+{
+#ifdef CONFIG_PHYS_64BIT
+struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
+uintptr_t ubuf = (uintptr_t)state->user_buffer;
+size_t len = state->len_aligned;
+
+/* Check if below 32bit boundary */
+if ((hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS) &&
+((ubuf >> 32) || (ubuf + len) >> 32)) {
+dev_dbg(scsi_dev, "Buffer above 32bit boundary %lx-%lx\n",
+ubuf, ubuf + len);
+return 0;
+}
+#endif
+return 1;
+}
+#endif/* CONFIG_BOUNCE_BUFFER */
+
   static struct scsi_ops ufs_ops = {
   .exec= ufs_scsi_exec,
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+.buffer_aligned= ufs_scsi_buffer_aligned,
+#endif/* CONFIG_BOUNCE_BUFFER */
   };
   int ufs_probe_dev(int index)
diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 8a38832b05f..070db0dce68 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -719,6 +719,12 @@ struct ufs_hba {
*/
   #define UFSHCD_QUIRK_BROKEN_LCC0x1
+/*
+ * This quirk needs to be enabled if the host controller has
+ * 64-bit addressing supported capability but it doesn't work.
+ */
+#define UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS0x2
+
   /* Virtual memory reference */
   struct utp_transfer_cmd_desc *ucdl;
   struct utp_transfer_req_desc *utrdl;


For this and the follow-up patch, I think implementing or at least
supporting all the quirks currently supported by the Linux UFS driver
makes sense as newer controllers do support these quirks.


I disagree. There is no point in implementing quirks which cannot be
tested or may not even be relevant to U-Boot. Quirks which are needed
should be added one by one.


I assume you agree we should not add all quirks at once ?


But the format you use for adding new quiks in u-boot is still in sync
with Linux version 3.10. Can we atleast use the newer ( 1<< 7) kind of
format for consistency.


Feel free to update quirks to BIT() macro.

We should enumerate the quirks in order instead of starting with BIT(7) 
however.

Re: [PATCH 1/6] ufs: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS

[Bhupesh Sharma]

On Wed, 16 Aug 2023 at 02:31, Marek Vasut  wrote:
>
> On 8/15/23 22:04, Bhupesh Sharma wrote:
> > Hi Marek,
> >
> > On 8/14/23 5:22 AM, Marek Vasut wrote:
> >> Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
> >> support 64-bit addressing.
> >>
> >> Ported from Linux kernel commit
> >> 6554400d6f66 ("scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS")
> >> with ufs_scsi_buffer_aligned() based on U-Boot generic bounce buffer.
> >>
> >> Signed-off-by: Marek Vasut 
> >> ---
> >> Cc: Faiz Abbas 
> >> ---
> >>   drivers/ufs/ufs.c | 26 ++
> >>   drivers/ufs/ufs.h |  6 ++
> >>   2 files changed, 32 insertions(+)
> >>
> >> diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
> >> index 3bf1a95e7f2..da0550d98c6 100644
> >> --- a/drivers/ufs/ufs.c
> >> +++ b/drivers/ufs/ufs.c
> >> @@ -8,6 +8,7 @@
> >>* Copyright (C) 2019 Texas Instruments Incorporated -
> >> http://www.ti.com
> >>*/
> >> +#include 
> >>   #include 
> >>   #include 
> >>   #include 
> >> @@ -1889,6 +1890,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct
> >> ufs_hba_ops *hba_ops)
> >>   /* Read capabilties registers */
> >>   hba->capabilities = ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES);
> >> +if (hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS)
> >> +hba->capabilities &= ~MASK_64_ADDRESSING_SUPPORT;
> >>   /* Get UFS version supported by the controller */
> >>   hba->version = ufshcd_get_ufs_version(hba);
> >> @@ -1942,8 +1945,31 @@ int ufs_scsi_bind(struct udevice *ufs_dev,
> >> struct udevice **scsi_devp)
> >>   return ret;
> >>   }
> >> +#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
> >> +static int ufs_scsi_buffer_aligned(struct udevice *scsi_dev, struct
> >> bounce_buffer *state)
> >> +{
> >> +#ifdef CONFIG_PHYS_64BIT
> >> +struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
> >> +uintptr_t ubuf = (uintptr_t)state->user_buffer;
> >> +size_t len = state->len_aligned;
> >> +
> >> +/* Check if below 32bit boundary */
> >> +if ((hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS) &&
> >> +((ubuf >> 32) || (ubuf + len) >> 32)) {
> >> +dev_dbg(scsi_dev, "Buffer above 32bit boundary %lx-%lx\n",
> >> +ubuf, ubuf + len);
> >> +return 0;
> >> +}
> >> +#endif
> >> +return 1;
> >> +}
> >> +#endif/* CONFIG_BOUNCE_BUFFER */
> >> +
> >>   static struct scsi_ops ufs_ops = {
> >>   .exec= ufs_scsi_exec,
> >> +#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
> >> +.buffer_aligned= ufs_scsi_buffer_aligned,
> >> +#endif/* CONFIG_BOUNCE_BUFFER */
> >>   };
> >>   int ufs_probe_dev(int index)
> >> diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
> >> index 8a38832b05f..070db0dce68 100644
> >> --- a/drivers/ufs/ufs.h
> >> +++ b/drivers/ufs/ufs.h
> >> @@ -719,6 +719,12 @@ struct ufs_hba {
> >>*/
> >>   #define UFSHCD_QUIRK_BROKEN_LCC0x1
> >> +/*
> >> + * This quirk needs to be enabled if the host controller has
> >> + * 64-bit addressing supported capability but it doesn't work.
> >> + */
> >> +#define UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS0x2
> >> +
> >>   /* Virtual memory reference */
> >>   struct utp_transfer_cmd_desc *ucdl;
> >>   struct utp_transfer_req_desc *utrdl;
> >
> > For this and the follow-up patch, I think implementing or at least
> > supporting all the quirks currently supported by the Linux UFS driver
> > makes sense as newer controllers do support these quirks.
>
> I disagree. There is no point in implementing quirks which cannot be
> tested or may not even be relevant to U-Boot. Quirks which are needed
> should be added one by one.

But the format you use for adding new quiks in u-boot is still in sync
with Linux version 3.10. Can we atleast use the newer ( 1<< 7) kind of
format for consistency.

Thanks.

> > Accordingly I had sent:
> > https://lists.denx.de/pipermail/u-boot/2023-August/527217.html
> >
> > So, I would suggest that we pick these two patches and then I can send
> > my patches rebased on the same, but change the .h to support all the
> > possible UFS quirks currently supported in Linux so that subsequent
> > patches can utilize them in u-boot - which I plan to post next.
>
> See above.

Re: [PATCH 3/6] ufs: Handle UFS 3.0 controllers

[Bhupesh Sharma]

On Wed, 16 Aug 2023 at 02:31, Marek Vasut  wrote:
>
> On 8/15/23 19:14, Bhupesh Sharma wrote:
> > On Mon, 14 Aug 2023 at 05:23, Marek Vasut
> >  wrote:
> >>
> >> Extend the version check to handle UFS 3.0 controllers as well.
> >> Tested on R-Car S4 UFS 3.0 controller.
> >>
> >> Signed-off-by: Marek Vasut 
> >> ---
> >> Cc: Faiz Abbas 
> >> ---
> >>   drivers/ufs/ufs.c | 3 ++-
> >>   drivers/ufs/ufs.h | 1 +
> >>   2 files changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
> >> index 261ae2843c2..58830c8ddca 100644
> >> --- a/drivers/ufs/ufs.c
> >> +++ b/drivers/ufs/ufs.c
> >> @@ -1903,7 +1903,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct 
> >> ufs_hba_ops *hba_ops)
> >>  if (hba->version != UFSHCI_VERSION_10 &&
> >>  hba->version != UFSHCI_VERSION_11 &&
> >>  hba->version != UFSHCI_VERSION_20 &&
> >> -   hba->version != UFSHCI_VERSION_21)
> >> +   hba->version != UFSHCI_VERSION_21 &&
> >> +   hba->version != UFSHCI_VERSION_30)
> >>  dev_err(hba->dev, "invalid UFS version 0x%x\n",
> >>  hba->version);
> >>
> >> diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
> >> index 33ca5f29812..ef7728fc39e 100644
> >> --- a/drivers/ufs/ufs.h
> >> +++ b/drivers/ufs/ufs.h
> >> @@ -781,6 +781,7 @@ enum {
> >>  UFSHCI_VERSION_11 = 0x00010100, /* 1.1 */
> >>  UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
> >>  UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
> >> +   UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
> >>   };
> >>
> >>   /* Interrupt disable masks */
> >> --
> >> 2.40.1
> >
> > SInce the Qualcomm UFS HC controllers are even newer / greater version
> > values, we can drop this patch in favour of my UFS patch here:
> > https://lists.denx.de/pipermail/u-boot/2023-August/527215.html
>
> Why not keep validating the version ?

How many versions would one want to validate when the newer versions
are 4.1 or greater?

Re: [PATCH 4/6] ufs: Pass hba pointer to ufshcd_prepare_req_desc_hdr()

[Marek Vasut]

On 8/15/23 21:57, Bhupesh Sharma wrote:

On 8/14/23 5:22 AM, Marek Vasut wrote:

Pass the hba pointer itself to ufshcd_prepare_req_desc_hdr()
instead of duplicating utp_transfer_req_desc access at each
call site. No functional change.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 58830c8ddca..da1009e2c14 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -696,10 +696,11 @@ static inline u8 ufshcd_get_upmcrs(struct 
ufs_hba *hba)

   * ufshcd_prepare_req_desc_hdr() - Fills the requests header
   * descriptor according to request
   */
-static void ufshcd_prepare_req_desc_hdr(struct utp_transfer_req_desc 
*req_desc,

+static void ufshcd_prepare_req_desc_hdr(struct ufs_hba *hba,
  u32 *upiu_flags,
  enum dma_data_direction cmd_dir)
  {
+    struct utp_transfer_req_desc *req_desc = hba->utrdl;
  u32 data_direction;
  u32 dword_0;
@@ -793,11 +794,10 @@ static int ufshcd_comp_devman_upiu(struct 
ufs_hba *hba,

  {
  u32 upiu_flags;
  int ret = 0;
-    struct utp_transfer_req_desc *req_desc = hba->utrdl;
  hba->dev_cmd.type = cmd_type;
-    ufshcd_prepare_req_desc_hdr(req_desc, _flags, DMA_NONE);
+    ufshcd_prepare_req_desc_hdr(hba, _flags, DMA_NONE);
  switch (cmd_type) {
  case DEV_CMD_TYPE_QUERY:
  ufshcd_prepare_utp_query_req_upiu(hba, upiu_flags);
@@ -1449,12 +1449,11 @@ static void prepare_prdt_table(struct ufs_hba 
*hba, struct scsi_cmd *pccb)
  static int ufs_scsi_exec(struct udevice *scsi_dev, struct scsi_cmd 
*pccb)

  {
  struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
-    struct utp_transfer_req_desc *req_desc = hba->utrdl;
  u32 upiu_flags;
  int ocs, result = 0;
  u8 scsi_status;
-    ufshcd_prepare_req_desc_hdr(req_desc, _flags, pccb->dma_dir);
+    ufshcd_prepare_req_desc_hdr(hba, _flags, pccb->dma_dir);
  ufshcd_prepare_utp_scsi_cmd_upiu(hba, pccb, upiu_flags);
  prepare_prdt_table(hba, pccb);


Reviewed-and-Tested-by: Bhupesh Sharma 


Please use Reviewed-by: and Tested-by: tags separately, else patchwork 
won't pick those tags up.

Re: [PATCH 3/6] ufs: Handle UFS 3.0 controllers

[Marek Vasut]

On 8/15/23 19:14, Bhupesh Sharma wrote:

On Mon, 14 Aug 2023 at 05:23, Marek Vasut
 wrote:


Extend the version check to handle UFS 3.0 controllers as well.
Tested on R-Car S4 UFS 3.0 controller.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 3 ++-
  drivers/ufs/ufs.h | 1 +
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 261ae2843c2..58830c8ddca 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -1903,7 +1903,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct 
ufs_hba_ops *hba_ops)
 if (hba->version != UFSHCI_VERSION_10 &&
 hba->version != UFSHCI_VERSION_11 &&
 hba->version != UFSHCI_VERSION_20 &&
-   hba->version != UFSHCI_VERSION_21)
+   hba->version != UFSHCI_VERSION_21 &&
+   hba->version != UFSHCI_VERSION_30)
 dev_err(hba->dev, "invalid UFS version 0x%x\n",
 hba->version);

diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 33ca5f29812..ef7728fc39e 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -781,6 +781,7 @@ enum {
 UFSHCI_VERSION_11 = 0x00010100, /* 1.1 */
 UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
 UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
+   UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
  };

  /* Interrupt disable masks */
--
2.40.1


SInce the Qualcomm UFS HC controllers are even newer / greater version
values, we can drop this patch in favour of my UFS patch here:
https://lists.denx.de/pipermail/u-boot/2023-August/527215.html


Why not keep validating the version ?

Re: [PATCH 1/6] ufs: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS

[Marek Vasut]

On 8/15/23 22:04, Bhupesh Sharma wrote:

Hi Marek,

On 8/14/23 5:22 AM, Marek Vasut wrote:

Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
support 64-bit addressing.

Ported from Linux kernel commit
6554400d6f66 ("scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS")
with ufs_scsi_buffer_aligned() based on U-Boot generic bounce buffer.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 26 ++
  drivers/ufs/ufs.h |  6 ++
  2 files changed, 32 insertions(+)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 3bf1a95e7f2..da0550d98c6 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -8,6 +8,7 @@
   * Copyright (C) 2019 Texas Instruments Incorporated - 
http://www.ti.com

   */
+#include 
  #include 
  #include 
  #include 
@@ -1889,6 +1890,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct 
ufs_hba_ops *hba_ops)

  /* Read capabilties registers */
  hba->capabilities = ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES);
+    if (hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS)
+    hba->capabilities &= ~MASK_64_ADDRESSING_SUPPORT;
  /* Get UFS version supported by the controller */
  hba->version = ufshcd_get_ufs_version(hba);
@@ -1942,8 +1945,31 @@ int ufs_scsi_bind(struct udevice *ufs_dev, 
struct udevice **scsi_devp)

  return ret;
  }
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+static int ufs_scsi_buffer_aligned(struct udevice *scsi_dev, struct 
bounce_buffer *state)

+{
+#ifdef CONFIG_PHYS_64BIT
+    struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
+    uintptr_t ubuf = (uintptr_t)state->user_buffer;
+    size_t len = state->len_aligned;
+
+    /* Check if below 32bit boundary */
+    if ((hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS) &&
+    ((ubuf >> 32) || (ubuf + len) >> 32)) {
+    dev_dbg(scsi_dev, "Buffer above 32bit boundary %lx-%lx\n",
+    ubuf, ubuf + len);
+    return 0;
+    }
+#endif
+    return 1;
+}
+#endif    /* CONFIG_BOUNCE_BUFFER */
+
  static struct scsi_ops ufs_ops = {
  .exec    = ufs_scsi_exec,
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+    .buffer_aligned    = ufs_scsi_buffer_aligned,
+#endif    /* CONFIG_BOUNCE_BUFFER */
  };
  int ufs_probe_dev(int index)
diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 8a38832b05f..070db0dce68 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -719,6 +719,12 @@ struct ufs_hba {
   */
  #define UFSHCD_QUIRK_BROKEN_LCC    0x1
+/*
+ * This quirk needs to be enabled if the host controller has
+ * 64-bit addressing supported capability but it doesn't work.
+ */
+#define UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS    0x2
+
  /* Virtual memory reference */
  struct utp_transfer_cmd_desc *ucdl;
  struct utp_transfer_req_desc *utrdl;


For this and the follow-up patch, I think implementing or at least 
supporting all the quirks currently supported by the Linux UFS driver 
makes sense as newer controllers do support these quirks.


I disagree. There is no point in implementing quirks which cannot be 
tested or may not even be relevant to U-Boot. Quirks which are needed 
should be added one by one.


Accordingly I had sent: 
https://lists.denx.de/pipermail/u-boot/2023-August/527217.html


So, I would suggest that we pick these two patches and then I can send 
my patches rebased on the same, but change the .h to support all the
possible UFS quirks currently supported in Linux so that subsequent 
patches can utilize them in u-boot - which I plan to post next.


See above.

Re: [PATCH 17/17] MAINTAINERS: Update UFS maintainer

[Marek Vasut]

On 8/15/23 19:48, Bhupesh Sharma wrote:

On Tue, 15 Aug 2023 at 04:01, Marek Vasut  wrote:


On 8/14/23 23:54, Bhupesh Sharma wrote:

Since Faiz Abbas's email ID is no longer valid,
drop him from UFS Maintainer list.

Since I am using the UFS framework now extensively
on Qualcomm Snapdragon SoCs, so proposing myself as
the new UFS maintainer.

I have also been sending out u-boot UFS fixes in the
recent past.

Signed-off-by: Bhupesh Sharma 


I believe TI is working on something here, so please coordinate with them.


Ok, well I haven't seen any reply to my earlier UFS fix related emails
from TI, so I thought maybe no one is actively looking into this area.
But I would love to hear from TI on the same..


This is why I CCed Vignesh and Nishanth , coordinate with them.


Anyways since I will be working on the Qualcomm UFS glue layer going
forward, I can propose to either be a UFS maintainer or a reviewer for
now to make sure that the subsystem patches are reviewed and tested .

Re: [PATCH] nvmxip: add sandbox support

[Marek Vasut]

On 8/15/23 18:43, Abdellatif El Khlifi wrote:

enable the 32-bit version of sandbox

Initially NVMXIP came with sandbox64 support.
Let's enable sandbox support as well.

Signed-off-by: Abdellatif El Khlifi 
Cc: Tom Rini 
Cc: Simon Glass 


Can you please split this into multiple patches and add proper commit 
message description to each one ? Thanks.

Re: [PATCH] buildman: Allow more results while building

[Tom Rini]

On Tue, Aug 15, 2023 at 12:39:37PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 15 Aug 2023 at 08:42, Tom Rini  wrote:
> >
> > On Thu, Aug 03, 2023 at 12:59:55PM -0600, Simon Glass wrote:
> >
> > > The -v option enables display of build results while building, instead of
> > > needing to do a separate summary step later (or in another terminal). But
> > > this resets the build results after each commit, so that all errors are
> > > reported fresh, without trying to diff them against previous errors
> > > already shown.
> > >
> > > Drop this reset, as an experiment, so see if this is useful.
> > >
> > > Signed-off-by: Simon Glass 
> > > ---
> > >
> > >  tools/buildman/builder.py | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
> > > index ecbd368c47a..5ee2b5959b2 100644
> > > --- a/tools/buildman/builder.py
> > > +++ b/tools/buildman/builder.py
> > > @@ -536,7 +536,6 @@ class Builder:
> > >  if self._verbose:
> > >  terminal.print_clear()
> > >  boards_selected = {target : result.brd}
> > > -self.reset_result_summary(boards_selected)
> > >  self.produce_result_summary(result.commit_upto, 
> > > self.commits,
> > >boards_selected)
> > >  else:
> >
> > Nope, this doesn't change any of the output I see in how I usually do my
> > world builds.
> 
> For me it allows using -S and -B during the build phase, and seeing some 
> output.
> 
> However, the patch is not correct...it is just a concept. I should
> have marked it as RFC.

Well, take a look at
https://gist.github.com/trini/2e88e94743821586ef742a936c45c389 and if
you can think of things that'll make the output between lines 53 and 458
clearer / smaller that's what I'm looking for.

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request for efi-2023-10-rc3

[Tom Rini]

On Tue, Aug 15, 2023 at 06:31:39PM +0200, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 832148f675e427060be074c276956962fa9b5cb6:
> 
>   Merge tag 'u-boot-rockchip-20230814' of
> https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-08-14
> 09:11:09 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2023-10-rc3
> 
> for you to fetch changes up to d768dd88552df18d4a0527cf3d6ddd05dc072f02:
> 
>   common: return type board_get_usable_ram_top (2023-08-15 18:21:17 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb

[Tom Rini]

On Tue, Aug 15, 2023 at 09:56:20PM +0530, Sughosh Ganu wrote:

> The EFI capsule authentication logic in u-boot expects the public key
> in the form of an EFI Signature List(ESL) to be provided as part of
> the platform's dtb. Currently, the embedding of the ESL file into the
> dtb needs to be done manually.
> 
> Add a target for generating a dtsi file which contains the signature
> node with the ESL file included as a property under the signature
> node. Include the dtsi file in the dtb. This brings the embedding of
> the ESL in the dtb into the U-Boot build flow.
> 
> The path to the ESL file is specified through the
> CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> 
> Signed-off-by: Sughosh Ganu 
[snip]
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 368b5a3e28..2e71f190bc 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -334,7 +334,23 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
>   ; \
>   sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > 
> $(depfile)
>  
> -$(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
> +ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> +quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
> +cmd_capsule_esl_gen = \
> + $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" 
> $(capsule_esl_input_file) > $@)
> +
> +$(obj)/.capsule_esl.dtsi:
> + $(call cmd_capsule_esl_gen)
> +
> +capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
> +capsule_esl_dtsi = .capsule_esl.dtsi
> +capsule_esl_path=$(abspath $(srctree)/$(subst 
> $(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
> +dtsi_include_list += $(capsule_esl_dtsi)
> +endif

We should only need to ifdef around appending to dtsi_include_list.  The
rest we can / should just leave always there, that's cleaner reading.

> +
> +dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
> $(quote),,$(dtsi_include_list)))
> +
> +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE

This part here is a separate bugfix and we should do that as patch 2,
and the rest of the changes here as patch 3.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/5] scripts/Makefile.lib: Collate all dtsi files for inclusion

[Tom Rini]

On Tue, Aug 15, 2023 at 09:56:19PM +0530, Sughosh Ganu wrote:

> At the time of building a device-tree file, all the *u-boot.dtsi files
> are looked for, in a particular order, and the first file found is
> included. Then, the list of files specified in the
> CONFIG_DEVICE_TREE_INCLUDES symbol are included.
> 
> Combine these files that are to be included into a variable, and then
> include all these files in one go.
> 
> Signed-off-by: Sughosh Ganu 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] spl: don't assume NVMe partition 1 exists

[Tom Rini]

On Tue, Aug 15, 2023 at 06:07:36PM +0200, Heinrich Schuchardt wrote:

> There is no requirement that a partition 1 exists in a partition table.
> We should not try to retrieve information about it.
> 
> We should not even try reading with partition number
> CONFIG_SYS_NVME_BOOT_PARTITION here as this is done in the fs_set_blk_dev()
> call anyway.
> 
> Fixes: 8ce6a2e17577 ("spl: blk: Support loading images from fs")
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/6] ufs: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS

[Bhupesh Sharma]

Hi Marek,

On 8/14/23 5:22 AM, Marek Vasut wrote:

Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS for host controllers which do not
support 64-bit addressing.

Ported from Linux kernel commit
6554400d6f66 ("scsi: ufs: core: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS")
with ufs_scsi_buffer_aligned() based on U-Boot generic bounce buffer.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 26 ++
  drivers/ufs/ufs.h |  6 ++
  2 files changed, 32 insertions(+)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 3bf1a95e7f2..da0550d98c6 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -8,6 +8,7 @@
   * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -1889,6 +1890,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct 
ufs_hba_ops *hba_ops)
  
  	/* Read capabilties registers */

hba->capabilities = ufshcd_readl(hba, REG_CONTROLLER_CAPABILITIES);
+   if (hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS)
+   hba->capabilities &= ~MASK_64_ADDRESSING_SUPPORT;
  
  	/* Get UFS version supported by the controller */

hba->version = ufshcd_get_ufs_version(hba);
@@ -1942,8 +1945,31 @@ int ufs_scsi_bind(struct udevice *ufs_dev, struct 
udevice **scsi_devp)
return ret;
  }
  
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)

+static int ufs_scsi_buffer_aligned(struct udevice *scsi_dev, struct 
bounce_buffer *state)
+{
+#ifdef CONFIG_PHYS_64BIT
+   struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
+   uintptr_t ubuf = (uintptr_t)state->user_buffer;
+   size_t len = state->len_aligned;
+
+   /* Check if below 32bit boundary */
+   if ((hba->quirks & UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS) &&
+   ((ubuf >> 32) || (ubuf + len) >> 32)) {
+   dev_dbg(scsi_dev, "Buffer above 32bit boundary %lx-%lx\n",
+   ubuf, ubuf + len);
+   return 0;
+   }
+#endif
+   return 1;
+}
+#endif /* CONFIG_BOUNCE_BUFFER */
+
  static struct scsi_ops ufs_ops = {
.exec   = ufs_scsi_exec,
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+   .buffer_aligned = ufs_scsi_buffer_aligned,
+#endif /* CONFIG_BOUNCE_BUFFER */
  };
  
  int ufs_probe_dev(int index)

diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
index 8a38832b05f..070db0dce68 100644
--- a/drivers/ufs/ufs.h
+++ b/drivers/ufs/ufs.h
@@ -719,6 +719,12 @@ struct ufs_hba {
   */
  #define UFSHCD_QUIRK_BROKEN_LCC   0x1
  
+/*

+ * This quirk needs to be enabled if the host controller has
+ * 64-bit addressing supported capability but it doesn't work.
+ */
+#define UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS  0x2
+
/* Virtual memory reference */
struct utp_transfer_cmd_desc *ucdl;
struct utp_transfer_req_desc *utrdl;


For this and the follow-up patch, I think implementing or at least 
supporting all the quirks currently supported by the Linux UFS driver 
makes sense as newer controllers do support these quirks.


Accordingly I had sent: 
https://lists.denx.de/pipermail/u-boot/2023-August/527217.html


So, I would suggest that we pick these two patches and then I can send 
my patches rebased on the same, but change the .h to support all the
possible UFS quirks currently supported in Linux so that subsequent 
patches can utilize them in u-boot - which I plan to post next.


Thanks,
Bhupesh

Re: [PATCH 4/6] ufs: Pass hba pointer to ufshcd_prepare_req_desc_hdr()

[Bhupesh Sharma]

On 8/14/23 5:22 AM, Marek Vasut wrote:

Pass the hba pointer itself to ufshcd_prepare_req_desc_hdr()
instead of duplicating utp_transfer_req_desc access at each
call site. No functional change.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 9 -
  1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 58830c8ddca..da1009e2c14 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -696,10 +696,11 @@ static inline u8 ufshcd_get_upmcrs(struct ufs_hba *hba)
   * ufshcd_prepare_req_desc_hdr() - Fills the requests header
   * descriptor according to request
   */
-static void ufshcd_prepare_req_desc_hdr(struct utp_transfer_req_desc *req_desc,
+static void ufshcd_prepare_req_desc_hdr(struct ufs_hba *hba,
u32 *upiu_flags,
enum dma_data_direction cmd_dir)
  {
+   struct utp_transfer_req_desc *req_desc = hba->utrdl;
u32 data_direction;
u32 dword_0;
  
@@ -793,11 +794,10 @@ static int ufshcd_comp_devman_upiu(struct ufs_hba *hba,

  {
u32 upiu_flags;
int ret = 0;
-   struct utp_transfer_req_desc *req_desc = hba->utrdl;
  
  	hba->dev_cmd.type = cmd_type;
  
-	ufshcd_prepare_req_desc_hdr(req_desc, _flags, DMA_NONE);

+   ufshcd_prepare_req_desc_hdr(hba, _flags, DMA_NONE);
switch (cmd_type) {
case DEV_CMD_TYPE_QUERY:
ufshcd_prepare_utp_query_req_upiu(hba, upiu_flags);
@@ -1449,12 +1449,11 @@ static void prepare_prdt_table(struct ufs_hba *hba, 
struct scsi_cmd *pccb)
  static int ufs_scsi_exec(struct udevice *scsi_dev, struct scsi_cmd *pccb)
  {
struct ufs_hba *hba = dev_get_uclass_priv(scsi_dev->parent);
-   struct utp_transfer_req_desc *req_desc = hba->utrdl;
u32 upiu_flags;
int ocs, result = 0;
u8 scsi_status;
  
-	ufshcd_prepare_req_desc_hdr(req_desc, _flags, pccb->dma_dir);

+   ufshcd_prepare_req_desc_hdr(hba, _flags, pccb->dma_dir);
ufshcd_prepare_utp_scsi_cmd_upiu(hba, pccb, upiu_flags);
prepare_prdt_table(hba, pccb);
  


Reviewed-and-Tested-by: Bhupesh Sharma 

Thanks.

Re: [PATCH 5/6] ufs: Use utp_transfer_req_desc pointer in ufshcd_get_tr_ocs

[Bhupesh Sharma]

On 8/14/23 5:22 AM, Marek Vasut wrote:

Use utp_transfer_req_desc pointer to reference to utrdl queue
instead of referencing the queue directly. This makes the code
more consistent. No functional change.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index da1009e2c14..041caee714f 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -858,7 +858,9 @@ static inline int ufshcd_get_req_rsp(struct utp_upiu_rsp 
*ucd_rsp_ptr)
   */
  static inline int ufshcd_get_tr_ocs(struct ufs_hba *hba)
  {
-   return le32_to_cpu(hba->utrdl->header.dword_2) & MASK_OCS;
+   struct utp_transfer_req_desc *req_desc = hba->utrdl;
+
+   return le32_to_cpu(req_desc->header.dword_2) & MASK_OCS;
  }
  
  static inline int ufshcd_get_rsp_upiu_result(struct utp_upiu_rsp *ucd_rsp_ptr)


LGTM, so:
Reviewed-and-Tested-by: Bhupesh Sharma 

Thanks.

Re: [PATCH 6/6] ufs: Implement cache management

[Bhupesh Sharma]

On 8/14/23 5:22 AM, Marek Vasut wrote:

Add function to flush and invalidate cache over request and response
queue entries, and perform flush and optional invalidate over block
layer data that are passed into the UFS layer. This makes it possible
to use UFS with caches enabled.

Signed-off-by: Marek Vasut 
---
Cc: Faiz Abbas 
---
  drivers/ufs/ufs.c | 42 +-
  1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
index 041caee714f..7c48d57f99d 100644
--- a/drivers/ufs/ufs.c
+++ b/drivers/ufs/ufs.c
@@ -692,6 +692,21 @@ static inline u8 ufshcd_get_upmcrs(struct ufs_hba *hba)
return (ufshcd_readl(hba, REG_CONTROLLER_STATUS) >> 8) & 0x7;
  }
  
+/**

+ * ufshcd_cache_flush_and_invalidate - Flush and invalidate cache
+ *
+ * Flush and invalidate cache in aligned address..address+size range.
+ * The invalidation is in place to avoid stale data in cache.
+ */
+static void ufshcd_cache_flush_and_invalidate(void *addr, unsigned long size)
+{
+   uintptr_t aaddr = (uintptr_t)addr & ~(ARCH_DMA_MINALIGN - 1);
+   unsigned long asize = ALIGN(size, ARCH_DMA_MINALIGN);
+
+   flush_dcache_range(aaddr, aaddr + asize);
+   invalidate_dcache_range(aaddr, aaddr + asize);
+}
+
  /**
   * ufshcd_prepare_req_desc_hdr() - Fills the requests header
   * descriptor according to request
@@ -735,6 +750,8 @@ static void ufshcd_prepare_req_desc_hdr(struct ufs_hba *hba,
req_desc->header.dword_3 = 0;
  
  	req_desc->prd_table_length = 0;

+
+   ufshcd_cache_flush_and_invalidate(req_desc, sizeof(*req_desc));
  }
  
  static void ufshcd_prepare_utp_query_req_upiu(struct ufs_hba *hba,

@@ -763,10 +780,15 @@ static void ufshcd_prepare_utp_query_req_upiu(struct 
ufs_hba *hba,
memcpy(_req_ptr->qr, >request.upiu_req, QUERY_OSF_SIZE);
  
  	/* Copy the Descriptor */

-   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
+   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC) {
memcpy(ucd_req_ptr + 1, query->descriptor, len);
+   ufshcd_cache_flush_and_invalidate(ucd_req_ptr, 2 * 
sizeof(*ucd_req_ptr));
+   } else {
+   ufshcd_cache_flush_and_invalidate(ucd_req_ptr, 
sizeof(*ucd_req_ptr));
+   }
  
  	memset(hba->ucd_rsp_ptr, 0, sizeof(struct utp_upiu_rsp));

+   ufshcd_cache_flush_and_invalidate(hba->ucd_rsp_ptr, 
sizeof(*hba->ucd_rsp_ptr));
  }
  
  static inline void ufshcd_prepare_utp_nop_upiu(struct ufs_hba *hba)

@@ -783,6 +805,9 @@ static inline void ufshcd_prepare_utp_nop_upiu(struct 
ufs_hba *hba)
ucd_req_ptr->header.dword_2 = 0;
  
  	memset(hba->ucd_rsp_ptr, 0, sizeof(struct utp_upiu_rsp));

+
+   ufshcd_cache_flush_and_invalidate(ucd_req_ptr, sizeof(*ucd_req_ptr));
+   ufshcd_cache_flush_and_invalidate(hba->ucd_rsp_ptr, 
sizeof(*hba->ucd_rsp_ptr));
  }
  
  /**

@@ -1409,6 +1434,8 @@ void ufshcd_prepare_utp_scsi_cmd_upiu(struct ufs_hba *hba,
memcpy(ucd_req_ptr->sc.cdb, pccb->cmd, cdb_len);
  
  	memset(hba->ucd_rsp_ptr, 0, sizeof(struct utp_upiu_rsp));

+   ufshcd_cache_flush_and_invalidate(ucd_req_ptr, sizeof(*ucd_req_ptr));
+   ufshcd_cache_flush_and_invalidate(hba->ucd_rsp_ptr, 
sizeof(*hba->ucd_rsp_ptr));
  }
  
  static inline void prepare_prdt_desc(struct ufshcd_sg_entry *entry,

@@ -1423,6 +1450,7 @@ static void prepare_prdt_table(struct ufs_hba *hba, 
struct scsi_cmd *pccb)
  {
struct utp_transfer_req_desc *req_desc = hba->utrdl;
struct ufshcd_sg_entry *prd_table = hba->ucd_prdt_ptr;
+   uintptr_t aaddr = (uintptr_t)(pccb->pdata) & ~(ARCH_DMA_MINALIGN - 1);
ulong datalen = pccb->datalen;
int table_length;
u8 *buf;
@@ -1430,9 +1458,19 @@ static void prepare_prdt_table(struct ufs_hba *hba, 
struct scsi_cmd *pccb)
  
  	if (!datalen) {

req_desc->prd_table_length = 0;
+   ufshcd_cache_flush_and_invalidate(req_desc, sizeof(*req_desc));
return;
}
  
+	if (pccb->dma_dir == DMA_TO_DEVICE) {	/* Write to device */

+   flush_dcache_range(aaddr, aaddr +
+  ALIGN(datalen, ARCH_DMA_MINALIGN));
+   }
+
+   /* In any case, invalidate cache to avoid stale data in it. */
+   invalidate_dcache_range(aaddr, aaddr +
+   ALIGN(datalen, ARCH_DMA_MINALIGN));
+
table_length = DIV_ROUND_UP(pccb->datalen, MAX_PRDT_ENTRY);
buf = pccb->pdata;
i = table_length;
@@ -1446,6 +1484,8 @@ static void prepare_prdt_table(struct ufs_hba *hba, 
struct scsi_cmd *pccb)
prepare_prdt_desc(_table[table_length - i - 1], buf, datalen - 1);
  
  	req_desc->prd_table_length = table_length;

+   ufshcd_cache_flush_and_invalidate(prd_table, sizeof(*prd_table) * 
table_length);
+   ufshcd_cache_flush_and_invalidate(req_desc, sizeof(*req_desc));
  }
  
  static int ufs_scsi_exec(struct udevice *scsi_dev, 

Re: [PATCH 3/3] sunxi: psci: implement PSCI on R528

[Sam Edwards]

On 8/14/23 08:16, Andre Przywara wrote:

Hi Sam,


This patch adds the necessary code to make nonsec booting and PSCI
secondary core management functional on the R528/T113.


Unfortunately this patch breaks the build on older 32-bit SoCs, as
SUNXI_CPUX_BASE is not defined there. That's a typical problem of the
"C-if" approach, but typically there is a clean, albeit not trivial,
solution:

It seems like SUNXI_CPUX_BASE and SUNXI_CPUCFG_BASE are mutually
exclusive, and I actually carry a "#define SUNXI_CPUCFG_BASE 0" hack in my
patches already.
So I wonder if we should unify those two into SUNXI_CPUCFG_BASE, with the
following rework:


The SUNXI_CPUX_BASE -> SUNXI_CPUCFG_BASE rename worked excellently. 
We're having the same problem with SUNXI_R_CPUCFG_BASE as well, though. 
How do you want to handle that?


Thanks,
Sam

Re: [PATCH] schemas: Add a schema for memory map

[Simon Glass]

+linux-a...@vger.kernel.org
+lk

Since there was a related discussion here:
https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyun...@bytedance.com/

On Fri, 11 Aug 2023 at 15:57, Simon Glass  wrote:
>
> The Devicespec specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.
>
> It is common to split firmware into 'Platform Init', which does the
> initial hardware setup and a "Payload" which selects the OS to be booted.
> Thus an handover interface is required between these two pieces.
>
> Where UEFI boot-time services are not available, but UEFI firmware is
> present on either side of this interface, information about memory usage
> and attributes must be presented to the "Payload" in some form.
>
> This aims to provide an initial schema for this mapping.
>
> Note that this is separate from the existing /memory and /reserved-memory
> nodes, since it is mostly concerned with what the memory is used for. It
> may cover only a small fraction of available memory, although it could be
> used to signal which area of memory has ECC.
>
> For now, no attempt is made to create an exhaustive binding, but this can
> be completed once this has passed initial review.
>
> Signed-off-by: Simon Glass 
> ---
>
>  dtschema/schemas/memory-map.yaml | 51 
>  1 file changed, 51 insertions(+)
>  create mode 100644 dtschema/schemas/memory-map.yaml
>
> diff --git a/dtschema/schemas/memory-map.yaml 
> b/dtschema/schemas/memory-map.yaml
> new file mode 100644
> index 000..97e531e
> --- /dev/null
> +++ b/dtschema/schemas/memory-map.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: BSD-2-Clause
> +# Copyright 2023 Google LLC
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-map.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: /memory-map nodes
> +description: |
> +  Common properties always required in /memory-map nodes. These nodes are
> +  intended to resolve the nonchalant clause 3.4.1 ("/memory node and UEFI")
> +  in the Devicetree Specification.
> +
> +maintainers:
> +  - Simon Glass 
> +
> +properties:
> +  $nodename:
> +const: '/'
> +  usage:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: |
> +  Describes the usage of the memory region, e.g.:
> +
> +"acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
> +"runtime-code", "runtime-data"
> +  attr:
> +$ref: /schemas/types.yaml#/definitions/string-array
> +description: |
> +  Attributes possessed by this memory region:
> +
> +"single-bit-ecc" - supports single-bit ECC
> +"multi-bit-ecc" - supports multiple-bit ECC
> +"no-ecc" - non-ECC memory
> +
> +patternProperties:
> +  "^([a-z][a-z0-9\\-]+@[0-9a-f]+)?$":
> +type: object
> +additionalProperties: false
> +
> +properties:
> +  reg:
> +minItems: 1
> +maxItems: 1024
> +
> +required:
> +  - reg
> +
> +additionalProperties: true
> +
> +...
> --
> 2.41.0.694.ge786442a9b-goog
>

U-Boot logging

[Massimo Pegorer]

Hi

I had a trip into U-Boot logging and I am quite confused. I read the
documentation at doc/develop/logging.rst and had a look at source code
in log.h log.c printk.h Kconfig and other files, but the picture is
still quite foggy and, let's say, 'complicated'.

The documentation does not mention at all CONFIG_LOGLEVEL, but pr_xxx
macros rely on its value (and then on log_xxx macros). While log_xxx
definitions, instead, depends on CONFIG_LOG and other CONFIG_LOG_XXX
values.

It is not clear when/if pr_xxx and/or log/log_xxx should be used. Is
any preferred and why? Is there a specific reason to keep both?

Neither the constrains and relations between Kconfig variables are
clear. CONFIG_LOGLEVEL and CONFIG_LOG are in different section
of menuconfig: Console and Logging. The semantic is also a little
bit different: for LOGLEVEL, values smaller than the console loglevel
will be compiled in; for LOG_MAX_LEVEL, instead, any value higher
than this will be ignored.

The doc states that 'If CONFIG_LOG is not set, then no logging will
be available'. But a few lines below 'If logging is disabled, the
default behaviour is to output any message at level LOGL_INFO and
below'. This sounds inconsistent to me.

I see a lot of To Do tasks listed in logging.rst, like converting
some other logging statements like debug() and error(). I wonder if
something can be improved, and in case how: I could commit some of
my spare time.

Thanks. Regards.

Massimo

Re: [PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb

[Simon Glass]

Hi Sughosh,

On Tue, 15 Aug 2023 at 10:26, Sughosh Ganu  wrote:
>
> The EFI capsule authentication logic in u-boot expects the public key
> in the form of an EFI Signature List(ESL) to be provided as part of
> the platform's dtb. Currently, the embedding of the ESL file into the
> dtb needs to be done manually.
>
> Add a target for generating a dtsi file which contains the signature
> node with the ESL file included as a property under the signature
> node. Include the dtsi file in the dtb. This brings the embedding of
> the ESL in the dtb into the U-Boot build flow.
>
> The path to the ESL file is specified through the
> CONFIG_EFI_CAPSULE_ESL_FILE symbol.
>
> Signed-off-by: Sughosh Ganu 
> ---
> Changes since RFC series:
> * Remove the default value of the config symbol.
> * s/include_files/dtsi_include_list
> * Add all the dtsi files being included as dependency for the dtb
>   target.
>
>  lib/efi_loader/Kconfig |  8 
>  lib/efi_loader/capsule_esl.dtsi.in | 11 +++
>  scripts/Makefile.lib   | 18 +-
>  3 files changed, 36 insertions(+), 1 deletion(-)
>  create mode 100644 lib/efi_loader/capsule_esl.dtsi.in
>
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 9989e3f384..d20aaab6db 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -272,6 +272,14 @@ config EFI_CAPSULE_MAX
>   Select the max capsule index value used for capsule report
>   variables. This value is used to create CapsuleMax variable.
>
> +config EFI_CAPSULE_ESL_FILE
> +   string "Path to the EFI Signature List File"

Do we need this, or could we name it as we do with the .env file? It
seems confusing to have to set this for each board - it might be
better to have it in a defined location.

Another idea is that we could use binman to pull this in, e.g. with an
option to insert the capsule key during the build. Then it can be
anywhere on the binman path.

As you know I am not a fan of these opaque binaries when we have a
nice self-describing format like devicetre. But we can worry about
that problem another time.

> +   depends on EFI_CAPSULE_AUTHENTICATE
> +   help
> + Provides the path to the EFI Signature List file which will
> + be embedded in the platform's device tree and used for
> + capsule authentication at the time of capsule update.
> +
>  config EFI_DEVICE_PATH_TO_TEXT
> bool "Device path to text protocol"
> default y
> diff --git a/lib/efi_loader/capsule_esl.dtsi.in 
> b/lib/efi_loader/capsule_esl.dtsi.in
> new file mode 100644
> index 00..61a9f2b25e
> --- /dev/null
> +++ b/lib/efi_loader/capsule_esl.dtsi.in
> @@ -0,0 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/**
> + * Devicetree file with the public key EFI Signature List(ESL)
> + * node. This file is used to generate the dtsi file to be
> + * included into the DTB.
> +*/
> +/ {
> +   signature {
> +   capsule-key = /incbin/("ESL_BIN_FILE");
> +   };
> +};
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 368b5a3e28..2e71f190bc 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -334,7 +334,23 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> ; \
> sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > 
> $(depfile)
>
> -$(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
> +ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> +quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
> +cmd_capsule_esl_gen = \
> +   $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" 
> $(capsule_esl_input_file) > $@)
> +
> +$(obj)/.capsule_esl.dtsi:
> +   $(call cmd_capsule_esl_gen)
> +
> +capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
> +capsule_esl_dtsi = .capsule_esl.dtsi
> +capsule_esl_path=$(abspath $(srctree)/$(subst 
> $(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
> +dtsi_include_list += $(capsule_esl_dtsi)
> +endif
> +
> +dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
> $(quote),,$(dtsi_include_list)))
> +
> +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
> $(call if_changed_dep,dtc)
>
>  pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
> --
> 2.34.1
>

Regards,
Simon

Re: [PATCH] nvmxip: add sandbox support

[Simon Glass]

On Tue, 15 Aug 2023 at 10:43, Abdellatif El Khlifi
 wrote:
>
> enable the 32-bit version of sandbox
>
> Initially NVMXIP came with sandbox64 support.
> Let's enable sandbox support as well.
>
> Signed-off-by: Abdellatif El Khlifi 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
>  arch/sandbox/dts/sandbox.dts   | 14 ++
>  configs/sandbox_defconfig  |  4 ++--
>  drivers/mtd/nvmxip/nvmxip-uclass.c |  6 +++---
>  drivers/mtd/nvmxip/nvmxip.c| 13 +++--
>  drivers/mtd/nvmxip/nvmxip_qspi.c   | 10 +-
>  test/dm/Makefile   |  2 +-
>  6 files changed, 40 insertions(+), 9 deletions(-)


Reviewed-by: Simon Glass 
>
> diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
> index 12d3eff5fa..1d38a939c4 100644
> --- a/arch/sandbox/dts/sandbox.dts
> +++ b/arch/sandbox/dts/sandbox.dts
> @@ -97,6 +97,20 @@
> compatible = "sandbox,spi";
> cs-gpios = <0>, <_a 0>;
> };
> +
> +   nvmxip-qspi1@0800 {
> +   compatible = "nvmxip,qspi";
> +   reg = <0x0800 0x0020>;
> +   lba_shift = <9>;
> +   lba = <4096>;
> +   };
> +
> +   nvmxip-qspi2@0820 {
> +   compatible = "nvmxip,qspi";
> +   reg = <0x0820 0x0010>;
> +   lba_shift = <9>;
> +   lba = <2048>;
> +   };
>  };
>
>  #include "sandbox.dtsi"
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 1cd1c2ed7c..296f9d7326 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
> @@ -145,7 +145,6 @@ CONFIG_IP_DEFRAG=y
>  CONFIG_BOOTP_SERVERIP=y
>  CONFIG_IPV6=y
>  CONFIG_DM_DMA=y
> -CONFIG_DEVRES=y
>  CONFIG_DEBUG_DEVRES=y
>  CONFIG_SIMPLE_PM_BUS=y
>  CONFIG_ADC=y
> @@ -184,6 +183,7 @@ CONFIG_DMA_CHANNELS=y
>  CONFIG_SANDBOX_DMA=y
>  CONFIG_FASTBOOT_FLASH=y
>  CONFIG_FASTBOOT_FLASH_MMC_DEV=0
> +CONFIG_ARM_FFA_TRANSPORT=y
>  CONFIG_GPIO_HOG=y
>  CONFIG_DM_GPIO_LOOKUP_LABEL=y
>  CONFIG_QCOM_PMIC_GPIO=y
> @@ -227,6 +227,7 @@ CONFIG_SPI_FLASH_SPANSION=y
>  CONFIG_SPI_FLASH_STMICRO=y
>  CONFIG_SPI_FLASH_SST=y
>  CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_NVMXIP_QSPI=y
>  CONFIG_MULTIPLEXER=y
>  CONFIG_MUX_MMIO=y
>  CONFIG_NVME_PCI=y
> @@ -345,4 +346,3 @@ CONFIG_TEST_FDTDEC=y
>  CONFIG_UNIT_TEST=y
>  CONFIG_UT_TIME=y
>  CONFIG_UT_DM=y
> -CONFIG_ARM_FFA_TRANSPORT=y
> diff --git a/drivers/mtd/nvmxip/nvmxip-uclass.c 
> b/drivers/mtd/nvmxip/nvmxip-uclass.c
> index 6d8eb177b5..7177f8f314 100644
> --- a/drivers/mtd/nvmxip/nvmxip-uclass.c
> +++ b/drivers/mtd/nvmxip/nvmxip-uclass.c
> @@ -9,7 +9,7 @@
>  #include 
>  #include 
>  #include 
> -#if CONFIG_IS_ENABLED(SANDBOX64)
> +#if CONFIG_IS_ENABLED(SANDBOX)
>  #include 
>  #endif
>  #include 
> @@ -39,7 +39,7 @@ static int nvmxip_post_bind(struct udevice *udev)
> char bdev_name[NVMXIP_BLKDEV_NAME_SZ + 1];
> int devnum;
>
> -#if CONFIG_IS_ENABLED(SANDBOX64)
> +#if CONFIG_IS_ENABLED(SANDBOX)
> sandbox_set_enable_memio(true);
>  #endif
>
> @@ -62,7 +62,7 @@ static int nvmxip_post_bind(struct udevice *udev)
> return ret;
> }
>
> -   log_info("[%s]: the block device %s ready for use\n", udev->name, 
> bdev_name);
> +   log_debug("[%s]: the block device %s ready for use\n", udev->name, 
> bdev_name);
>
> return 0;
>  }
> diff --git a/drivers/mtd/nvmxip/nvmxip.c b/drivers/mtd/nvmxip/nvmxip.c
> index a359e3b482..9191e69a40 100644
> --- a/drivers/mtd/nvmxip/nvmxip.c
> +++ b/drivers/mtd/nvmxip/nvmxip.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "nvmxip.h"
> @@ -26,9 +27,17 @@
>   *
>   * Always return 0.
>   */
> -static int nvmxip_mmio_rawread(const phys_addr_t address, u64 *value)
> +static int nvmxip_mmio_rawread(const u64 *address, u64 *value)
>  {
> +#if CONFIG_IS_ENABLED(PHYS_64BIT)
> *value = readq(address);
> +#else
> +   u32 h_word, l_word;
> +
> +   l_word = readl(address);
> +   h_word = readl((u8 *)address + sizeof(u32));
> +   *value = FIELD_PREP(GENMASK_ULL(63, 32), h_word) | l_word;
> +#endif
> return 0;
>  }
>
> @@ -67,7 +76,7 @@ static ulong nvmxip_blk_read(struct udevice *dev, lbaint_t 
> blknr, lbaint_t blkcn
> /* assumption: the data is virtually contiguous */
>
> for (qdata_idx = 0 ; qdata_idx < qwords ; qdata_idx++)
> -   nvmxip_mmio_rawread((phys_addr_t)(virt_blkaddr + qdata_idx), 
> pdst++);
> +   nvmxip_mmio_rawread(virt_blkaddr + qdata_idx, pdst++);
>
> log_debug("[%s]: src[0]: 0x%llx , dst[0]: 0x%llx , src[-1]: 
> 0x%llx , dst[-1]: 0x%llx\n",
>   dev->name,
> diff --git a/drivers/mtd/nvmxip/nvmxip_qspi.c 
> b/drivers/mtd/nvmxip/nvmxip_qspi.c
> index 7221fd1cb4..b6b94ca57f 100644
> --- a/drivers/mtd/nvmxip/nvmxip_qspi.c
> +++ b/drivers/mtd/nvmxip/nvmxip_qspi.c
> @@ -17,6 +17,14 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  #define 

Re: [PATCH 2/6] cmd: gpt: Add command to set bootable flags

[Simon Glass]

Hi Joshua,

On Tue, 15 Aug 2023 at 10:28, Joshua Watt  wrote:
>
> Adds a command that can be used to modify the GPT partition table to
> indicate which partitions should have the bootable flag set
>
> Signed-off-by: Joshua Watt 
> ---
>  cmd/gpt.c | 80 +++
>  1 file changed, 80 insertions(+)

Can you add doc/usage/gpt.rst and a test?

Regards,
Simon

Re: [PATCH] buildman: Allow more results while building

[Simon Glass]

Hi Tom,

On Tue, 15 Aug 2023 at 08:42, Tom Rini  wrote:
>
> On Thu, Aug 03, 2023 at 12:59:55PM -0600, Simon Glass wrote:
>
> > The -v option enables display of build results while building, instead of
> > needing to do a separate summary step later (or in another terminal). But
> > this resets the build results after each commit, so that all errors are
> > reported fresh, without trying to diff them against previous errors
> > already shown.
> >
> > Drop this reset, as an experiment, so see if this is useful.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> >  tools/buildman/builder.py | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
> > index ecbd368c47a..5ee2b5959b2 100644
> > --- a/tools/buildman/builder.py
> > +++ b/tools/buildman/builder.py
> > @@ -536,7 +536,6 @@ class Builder:
> >  if self._verbose:
> >  terminal.print_clear()
> >  boards_selected = {target : result.brd}
> > -self.reset_result_summary(boards_selected)
> >  self.produce_result_summary(result.commit_upto, 
> > self.commits,
> >boards_selected)
> >  else:
>
> Nope, this doesn't change any of the output I see in how I usually do my
> world builds.

For me it allows using -S and -B during the build phase, and seeing some output.

However, the patch is not correct...it is just a concept. I should
have marked it as RFC.

Regards,
Simon

Re: [PATCH 17/17] MAINTAINERS: Update UFS maintainer

[Bhupesh Sharma]

On Tue, 15 Aug 2023 at 04:01, Marek Vasut  wrote:
>
> On 8/14/23 23:54, Bhupesh Sharma wrote:
> > Since Faiz Abbas's email ID is no longer valid,
> > drop him from UFS Maintainer list.
> >
> > Since I am using the UFS framework now extensively
> > on Qualcomm Snapdragon SoCs, so proposing myself as
> > the new UFS maintainer.
> >
> > I have also been sending out u-boot UFS fixes in the
> > recent past.
> >
> > Signed-off-by: Bhupesh Sharma 
>
> I believe TI is working on something here, so please coordinate with them.

Ok, well I haven't seen any reply to my earlier UFS fix related emails
from TI, so I thought maybe no one is actively looking into this area.
But I would love to hear from TI on the same..

Anyways since I will be working on the Qualcomm UFS glue layer going
forward, I can propose to either be a UFS maintainer or a reviewer for
now to make sure that the subsystem patches are reviewed and tested .

Thanks,
Bhupesh

Re: [PATCH 1/3] fdt: common API to populate kaslr seed

[Sean Edmond]

On 2023-08-15 7:44 a.m., Simon Glass wrote:

Hi Sean,

On Mon, 14 Aug 2023 at 13:12, Sean Edmond
 wrote:


On 2023-08-12 6:09 a.m., Simon Glass wrote:

Hi Sean,

On Fri, 11 Aug 2023 at 11:14, Sean Edmond 
wrote:

On 2023-08-09 6:49 p.m., Simon Glass wrote:

Hi Sean,

On Wed, 9 Aug 2023 at 16:35, Sean Edmond 

wrote:

On 2023-08-08 7:03 p.m., Simon Glass wrote:

Hi,

On Fri, 4 Aug 2023 at 17:34,  wrote:

From: Dhananjay Phadke 

fdt_fixup_kaslr_seed() will update given FDT with random seed value.
Source for random seed can be TPM or RNG driver in u-boot or sec
firmware (ARM).

Signed-off-by: Dhananjay Phadke 
---
 arch/arm/cpu/armv8/sec_firmware.c | 32

+++

 common/fdt_support.c  | 31

++

 include/fdt_support.h |  3 +++
 3 files changed, 41 insertions(+), 25 deletions(-)

We need to find a way to use the ofnode API here.


diff --git a/arch/arm/cpu/armv8/sec_firmware.c

b/arch/arm/cpu/armv8/sec_firmware.c

index c0e8726346..84ba49924e 100644
--- a/arch/arm/cpu/armv8/sec_firmware.c
+++ b/arch/arm/cpu/armv8/sec_firmware.c
@@ -411,46 +411,28 @@ int sec_firmware_init(const void

*sec_firmware_img,

 /*
  * fdt_fix_kaslr - Add kalsr-seed node in Device tree
  * @fdt:   Device tree
- * @eret:  0 in case of error, 1 for success
+ * @eret:  0 for success
  */
 int fdt_fixup_kaslr(void *fdt)

You could pass an oftree to this function, e.g. obtained with:

oftree_from_fdt(fdt)

The common API I added is fdt_fixup_kaslr_seed(), which was added to
"common/fdt_support.c".

There are 3 callers:
sec_firmware_init()->fdt_fixup_kaslr_seed()
do_kaslr_seed()->fdt_fixup_kaslr_seed()
image_setup_libfdt()->fdt_tpm_kaslr_seed->fdt_fixup_kaslr_seed()

I think the ask is to create a common API that uses the ofnode API.

So,

instead of fdt_fixup_kaslr_seed() I can create
ofnode_fixup_kaslr_seed()?  Where should it live?

If you like you could add common/ofnode_support.c ?

But it is OK to have it in the same file, I think.


Are you also wanting
the callers (eg. fdt_tpm_kaslr_seed, fdt_fixup_kaslr) to take oftree as
input too?

So far as you can go, yes. Also you may want to pass an ofnode (the
root node) so that things can deal with adding their stuff to any
node.

Regards,
Simon

I re-worked the API to use the ofnode API and tested it on our board.  I
was required to explicitly enable CONFIG_OFNODE_MULTI_TREE in order for
it to work.

I have concerns this will create a breaking change for users of the
kaslr fdt touch up.  In our case, if CONFIG_OFNODE_MULTI_TREE isn't set,
the control FDT gets touched up, not the kernel FDT as required.
Everything runs to completion, but "/proc/device-tree/chosen/kaslr-seed"
isn't present after boot.

Am I missing something?  Perhaps there's a way to modify the default
value for CONFIG_OFNODE_MULTI_TREE to ensure this works out-of-the-box?


Yes, perhaps we should enable this when fixups are used? Is there a way to
tell?

I don't think there's a way to tell unfortunately.  Fixups are always
called if OF_LIBFDT is enabled, and if an FDT is found during bootm.

I'm having trouble understanding the intention of the current default
for OFNODE_MULTI_TREE:
  default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE
Could we simplify to this?
  default y if !OF_LIVE

I don't think it will build if inlining is used, but I can't remember...
I wasn't able to break this by turning off DM_DEV_READ_INLINE, and 
enabling OFNODE_MULTI_TREE/SPL_DM_INLINE_OFNODE/TPL_DM_INLINE_OFNODE. 
Perhaps things have changes since this was created.

The EVENT thing is because there is an of-fixup event, which was the
original thing using ofnode fixups.

I wonder what sort of size increment this will create with !OF_LIVE ?


With default (OFNODE_MULTI_TREE is not set):

textdatabssdechex filename

9380135536846752 1040133fdf05 u-boot/u-boot/u-boot


With !OF_LIVE (OFNODE_MULTI_TREE is set with OFNODE_MULTI_TREE_MAX=4):

seanedmond@ovlvm106:~/code/QEMU/qemu_uboot$ sizeu-boot/u-boot/u-boot

textdatabssdechex filename

9390165536846752 1041136fe2f0 u-boot/u-boot/u-boot




Also, we should make it return an error when attempting to use a tree
without that option enabled. I would expect oftree_ensure() to provide that?

I'll add a check.

OK thanks.

Regards,
Simon

Re: [PATCH 00/17] Enable UFS on DragonBoard845c

[Bhupesh Sharma]

On Tue, 15 Aug 2023 at 04:03, Marek Vasut  wrote:
>
> On 8/14/23 23:54, Bhupesh Sharma wrote:
> > This patchset enables the UFS controller on DragonBoard845c
> > board which houses Qualcomm SDM845 Snapdragon SoC.
> >
> > In addition to enabling the UFS HC and UFS QMP PHY found
> > on this SoC this patchset also contains:
> >   * Patches to add 'reset' controller support for SDM845 SoC.
> >   * Minor UFS core framework fixes.
> >   * Patches to sync u-boot UFS driver flow with Linux UFS driver.
> >   * Patches which enable RESET, UFS and SCSI config options for
> > DragonBoard845c.
>
> I submitted a couple of UFS related patches yesterday, they add handling
> for controllers which cannot handle 64bit memory and add support for
> cache management. Please rebase on top of those, otherwise there will be
> hard to resolve conflicts.
>
> [PATCH 1/6] ufs: Add UFSHCD_QUIRK_BROKEN_64BIT_ADDRESS
> [PATCH 1/2] blk: Add bounce buffer support to read/write operations

Ok, let me rebase, do a quick check and resend the patchset.

Thanks,
Bhupesh

Re: [PATCH 3/6] ufs: Handle UFS 3.0 controllers

[Bhupesh Sharma]

On Mon, 14 Aug 2023 at 05:23, Marek Vasut
 wrote:
>
> Extend the version check to handle UFS 3.0 controllers as well.
> Tested on R-Car S4 UFS 3.0 controller.
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Faiz Abbas 
> ---
>  drivers/ufs/ufs.c | 3 ++-
>  drivers/ufs/ufs.h | 1 +
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ufs/ufs.c b/drivers/ufs/ufs.c
> index 261ae2843c2..58830c8ddca 100644
> --- a/drivers/ufs/ufs.c
> +++ b/drivers/ufs/ufs.c
> @@ -1903,7 +1903,8 @@ int ufshcd_probe(struct udevice *ufs_dev, struct 
> ufs_hba_ops *hba_ops)
> if (hba->version != UFSHCI_VERSION_10 &&
> hba->version != UFSHCI_VERSION_11 &&
> hba->version != UFSHCI_VERSION_20 &&
> -   hba->version != UFSHCI_VERSION_21)
> +   hba->version != UFSHCI_VERSION_21 &&
> +   hba->version != UFSHCI_VERSION_30)
> dev_err(hba->dev, "invalid UFS version 0x%x\n",
> hba->version);
>
> diff --git a/drivers/ufs/ufs.h b/drivers/ufs/ufs.h
> index 33ca5f29812..ef7728fc39e 100644
> --- a/drivers/ufs/ufs.h
> +++ b/drivers/ufs/ufs.h
> @@ -781,6 +781,7 @@ enum {
> UFSHCI_VERSION_11 = 0x00010100, /* 1.1 */
> UFSHCI_VERSION_20 = 0x0200, /* 2.0 */
> UFSHCI_VERSION_21 = 0x0210, /* 2.1 */
> +   UFSHCI_VERSION_30 = 0x0300, /* 3.0 */
>  };
>
>  /* Interrupt disable masks */
> --
> 2.40.1

SInce the Qualcomm UFS HC controllers are even newer / greater version
values, we can drop this patch in favour of my UFS patch here:
https://lists.denx.de/pipermail/u-boot/2023-August/527215.html

Thanks,
Bhupesh

Re: [PATCH 2/2] configs: sandbox: test: dm: blk: Enable NVMXIP QSPI and update test

[Abdellatif El Khlifi]

Hi,

On Tue, Aug 15, 2023 at 12:45:57AM +0200, Marek Vasut wrote:
> On 8/15/23 00:42, Simon Glass wrote:
> > On Sun, 13 Aug 2023 at 15:47, Marek Vasut
> >  wrote:
> > > 
> > > Enable NVMXIP QSPI driver on sandbox, since it is already enabled
> > > on sandbox64. Update blk tests to match.
> > > 
> > > Signed-off-by: Marek Vasut 
> > > ---
> > > Cc: Abdellatif El Khlifi 
> > > Cc: Simon Glass 
> > > ---
> > >   configs/sandbox_defconfig |  1 +
> > >   test/dm/blk.c | 63 +++
> > >   2 files changed, 52 insertions(+), 12 deletions(-)
> > > 
> > 
> > Reviewed-by: Simon Glass 
> 
> NAK, this one has to wait. All of this NVMXIP stuff needs closer look, I
> think it is really weirdly broken and doesn't even pass sandbox and
> sandbox64 tests. Can Abdellatif try and check whether ALL sandbox and
> sandbox64 tests pass with this enabled ?

Initially the NVMXIP feature has been introduced with sandbox64 support.

The test case runs fine on sandbox64.

I've just sent a commit enabling NVMXIP for sandbox [1].

Tested on both sandbox and sandbox64.

I hope this helps.

[1]: 
https://lore.kernel.org/all/20230815164300.444701-1-abdellatif.elkhl...@arm.com/

Cheers
Abdellatif

Re: Please pull u-boot-ubi

[Tom Rini]

On Tue, Aug 15, 2023 at 02:26:06PM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-ubi.git master
> 
> The following changes since commit 832148f675e427060be074c276956962fa9b5cb6:
> 
>   Merge tag 'u-boot-rockchip-20230814' of 
> https://source.denx.de/u-boot/custodians/u-boot-rockchip
> (2023-08-14 09:11:09 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-ubi.git 
> tags/ubi-updates-for-v2023.10-rc3
> 
> for you to fetch changes up to 34031e9cce91de323ed711d7e8614c0d12fada1c:
> 
>   cmd: ubi: Fix 'ubi list' command arguments parsing (2023-08-15 07:32:13 
> +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-i2c

[Tom Rini]

On Tue, Aug 15, 2023 at 09:53:55AM +0200, Heiko Schocher wrote:

> Hello Tom,
> 
> please pull from u-boot-i2c:
> 
> The following changes since commit 832148f675e427060be074c276956962fa9b5cb6:
> 
>   Merge tag 'u-boot-rockchip-20230814' of 
> https://source.denx.de/u-boot/custodians/u-boot-rockchip
> (2023-08-14 09:11:09 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-i2c.git 
> tags/i2c-updates-for-v2023.10-rc3
> 
> for you to fetch changes up to 250454c59b1b056d47cbb0c6d8d09a68416c9776:
> 
>   i2c: mvtwsi: reset controller if stuck in "bus error" state (2023-08-15 
> 06:52:04 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH V3 2/4] arm: dts: Add k3-am625-beagleplay

[Nishanth Menon]

From: Robert Nelson 

BeagleBoard.org BeaglePlay is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM625
SoC that allows you to create connected devices that work even at long
distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
Expansion is provided over open standards based mikroBUS, Grove and
QWIIC headers among other interfaces.

This board family can be identified by the 24c32 eeprom:

[aa 55 33 ee 01 37 00 10  2e 00 42 45 41 47 4c 45  |.U3..7BEAGLE|]
[50 4c 41 59 2d 41 30 2d  00 00 30 32 30 30 37 38  |PLAY-A0-..020078|]

https://beagleplay.org/
https://git.beagleboard.org/beagleplay/beagleplay

baseline of base device tree is v6.5-rc1.

Reviewed-by: Tom Rini 
Signed-off-by: Robert Nelson 
Co-developed-by: Nishanth Menon 
Signed-off-by: Nishanth Menon 
---
Changes since V2:
* Add to MAINTAINERS file

V2: https://lore.kernel.org/u-boot/20230727234446.3651836-3...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-5...@ti.com/

 arch/arm/dts/Makefile |2 +
 .../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 +
 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  |  172 ++
 arch/arm/dts/k3-am625-beagleplay.dts  |  758 ++
 arch/arm/dts/k3-am625-r5-beagleplay.dts   |   87 +
 board/ti/am62x/MAINTAINERS|7 +
 6 files changed, 3221 insertions(+)
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
 create mode 100644 arch/arm/dts/k3-am625-r5-beagleplay.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index bd518064f35f..a19457c0d99b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1320,6 +1320,8 @@ dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
 
 dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
  k3-am625-r5-sk.dtb \
+ k3-am625-beagleplay.dtb \
+ k3-am625-r5-beagleplay.dtb \
  k3-am625-verdin-wifi-dev.dtb \
  k3-am625-verdin-r5.dtb
 
diff --git a/arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi 
b/arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
new file mode 100644
index ..3d7a41c27d7e
--- /dev/null
+++ b/arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
@@ -0,0 +1,2195 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * https://beagleboard.org/play
+ *
+ * Copyright (C) 2022-2023 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation
+ *
+ * This file was generated with the
+ * AM62x SysConfig DDR Subsystem Register Configuration Tool v0.09.06
+ * Thu Feb 09 2023 11:57:18 GMT-0600 (Central Standard Time)
+ * DDR Part number: K4AAG165WA-BCWE K4A4G165WF-BCTD
+ * DDR Type: DDR4
+ * Frequency = 800MHz (1600MTs)
+ * Density: 16Gb
+ * Number of Ranks: 1
+ */
+
+#define DDRSS_PLL_FHS_CNT 6
+#define DDRSS_PLL_FREQUENCY_1 4
+#define DDRSS_PLL_FREQUENCY_2 4
+
+#define DDRSS_CTL_0_DATA 0x0A00
+#define DDRSS_CTL_1_DATA 0x
+#define DDRSS_CTL_2_DATA 0x
+#define DDRSS_CTL_3_DATA 0x
+#define DDRSS_CTL_4_DATA 0x
+#define DDRSS_CTL_5_DATA 0x
+#define DDRSS_CTL_6_DATA 0x
+#define DDRSS_CTL_7_DATA 0x000890B8
+#define DDRSS_CTL_8_DATA 0x
+#define DDRSS_CTL_9_DATA 0x
+#define DDRSS_CTL_10_DATA 0x
+#define DDRSS_CTL_11_DATA 0x000890B8
+#define DDRSS_CTL_12_DATA 0x
+#define DDRSS_CTL_13_DATA 0x
+#define DDRSS_CTL_14_DATA 0x
+#define DDRSS_CTL_15_DATA 0x000890B8
+#define DDRSS_CTL_16_DATA 0x
+#define DDRSS_CTL_17_DATA 0x
+#define DDRSS_CTL_18_DATA 0x
+#define DDRSS_CTL_19_DATA 0x01010100
+#define DDRSS_CTL_20_DATA 0x01000100
+#define DDRSS_CTL_21_DATA 0x01000110
+#define DDRSS_CTL_22_DATA 0x02010002
+#define DDRSS_CTL_23_DATA 0x00027100
+#define DDRSS_CTL_24_DATA 0x00061A80
+#define DDRSS_CTL_25_DATA 0x04000400
+#define DDRSS_CTL_26_DATA 0x0400
+#define DDRSS_CTL_27_DATA 0x
+#define DDRSS_CTL_28_DATA 0x
+#define DDRSS_CTL_29_DATA 0x
+#define DDRSS_CTL_30_DATA 0x
+#define DDRSS_CTL_31_DATA 0x
+#define DDRSS_CTL_32_DATA 0x
+#define DDRSS_CTL_33_DATA 0x
+#define DDRSS_CTL_34_DATA 0x
+#define DDRSS_CTL_35_DATA 0x
+#define DDRSS_CTL_36_DATA 0x
+#define DDRSS_CTL_37_DATA 0x
+#define DDRSS_CTL_38_DATA 0x0400091C
+#define DDRSS_CTL_39_DATA 0x1C1C1C1C
+#define DDRSS_CTL_40_DATA 0x0400091C
+#define DDRSS_CTL_41_DATA 0x1C1C1C1C
+#define DDRSS_CTL_42_DATA 0x0400091C
+#define DDRSS_CTL_43_DATA 0x1C1C1C1C
+#define DDRSS_CTL_44_DATA 0x05050404
+#define DDRSS_CTL_45_DATA 0x2706
+#define DDRSS_CTL_46_DATA 0x0602001D
+#define DDRSS_CTL_47_DATA 0x05001D0B
+#define 

[PATCH V3 4/4] doc: board: ti: Add BeaglePlay documentation

[Nishanth Menon]

Add base documentation for BeaglePlay

Signed-off-by: Nishanth Menon 
---
Changes since V2:
* Update build instructions for config fragments
* Minor link look and feel fixups.

V2: https://lore.kernel.org/u-boot/20230727234446.3651836-5...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-7...@ti.com/
 doc/board/ti/am62x_beagleplay.rst | 121 ++
 doc/board/ti/k3.rst   |   1 +
 2 files changed, 122 insertions(+)
 create mode 100644 doc/board/ti/am62x_beagleplay.rst

diff --git a/doc/board/ti/am62x_beagleplay.rst 
b/doc/board/ti/am62x_beagleplay.rst
new file mode 100644
index ..d87f98b89acc
--- /dev/null
+++ b/doc/board/ti/am62x_beagleplay.rst
@@ -0,0 +1,121 @@
+.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+.. sectionauthor:: Nishanth Menon 
+
+AM62x Beagleboard.org Beagleplay
+
+
+Introduction:
+-
+
+BeagleBoard.org BeaglePlay is an easy to use, affordable open source
+hardware single board computer based on the Texas Instruments AM625
+SoC that allows you to create connected devices that work even at long
+distances using IEEE 802.15.4g LR-WPAN and IEEE 802.3cg 10Base-T1L.
+Expansion is provided over open standards based mikroBUS, Grove and
+QWIIC headers among other interfaces.
+
+Further information can be found at:
+
+* Product Page: https://beagleplay.org/
+* Hardware documentation: https://git.beagleboard.org/beagleplay/beagleplay
+
+Boot Flow:
+--
+Below is the pictorial representation of boot flow:
+
+.. image:: img/boot_diagram_k3_current.svg
+
+- On this platform, 'TI Foundational Security' (TIFS) functions as the
+  security enclave master while 'Device Manager' (DM), also known as the
+  'TISCI server' in "TI terminology", offers all the essential services.
+  The A53/M4F (Aux core) sends requests to TIFS/DM to accomplish these
+  services, as illustrated in the diagram above.
+
+Sources:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure:
+
+0. Setup the environment variables:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR="am62x_evm_r5_defconfig beagleplay_r5.config"
+ $ export UBOOT_CFG_CORTEXA="am62x_evm_a53_defconfig beagleplay_a53.config"
+ $ export TFA_BOARD=lite
+ $ # we dont use any extra TFA parameters
+ $ unset TFA_EXTRA_ARGS
+ $ export OPTEE_PLATFORM=k3-am62x
+ $ export OPTEE_EXTRA_ARGS="CFG_WITH_SOFTWARE_PRNG=y"
+
+.. include::  am62x_sk.rst
+:start-after: .. am62x_evm_rst_include_start_build_steps
+:end-before: .. am62x_evm_rst_include_end_build_steps
+
+Target Images
+--
+Copy the below images to an SD card and boot:
+
+* tiboot3-am62x-gp-evm.bin from R5 build as tiboot3.bin
+* tispl.bin_unsigned from Cortex-A build as tispl.bin
+* u-boot.img_unsigned from Cortex-A build as uboot.img
+
+Image formats:
+--
+
+- tiboot3.bin
+
+.. image:: img/multi_cert_tiboot3.bin.svg
+
+- tispl.bin
+
+.. image:: img/dm_tispl.bin.svg
+
+A53 SPL DDR Memory Layout
+-
+
+.. include::  am62x_sk.rst
+:start-after: .. am62x_evm_rst_include_start_ddr_mem_layout
+:end-before: .. am62x_evm_rst_include_end_ddr_mem_layout
+
+Switch Setting for Boot Mode
+
+
+The boot time option is configured via "USR" button on the board.
+See `Beagleplay Schematics 
`_
+for details.
+
+.. list-table:: Boot Modes
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - USR Switch Position
+ - Primary Boot
+ - Secondary Boot
+
+   * - Not Pressed
+ - eMMC
+ - UART
+
+   * - Pressed
+ - SD/MMC File System (FS) mode
+ - USB Device Firmware Upgrade (DFU) mode
+
+To switch to SD card boot mode, hold the USR button while powering on
+with Type-C power supply, then release when power LED lights up.
diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index d2f86b0a11a7..d041610f53b3 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -30,6 +30,7 @@ K3 Based SoCs
 .. toctree::
:maxdepth: 1
 
+   am62x_beagleplay
am62x_sk
../toradex/verdin-am62
am65x_evm
-- 
2.40.0

[PATCH V3 1/4] arm: dts: k3-am625-sk-binman: Add labels for unsigned binary

[Nishanth Menon]

Add labels for unsigned binary to permit over-ride.

Cc: Simon Glass 
Signed-off-by: Nishanth Menon 
---
NOTE: We can refactor this once the template solution comes online later on

Changes since V2: None
V2: https://lore.kernel.org/u-boot/20230727234446.3651836-2...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-3...@ti.com/

 arch/arm/dts/k3-am625-sk-binman.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi 
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index a35d6418c25f..41277bf4bfdb 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -389,7 +389,7 @@
type = "flat_dt";
arch = "arm";
compression = "none";
-   blob {
+   spl_am625_sk_dtb_unsigned: blob {
filename = SPL_AM625_SK_DTB;
};
};
@@ -438,7 +438,7 @@
type = "flat_dt";
arch = "arm";
compression = "none";
-   blob {
+   am625_sk_dtb_unsigned: blob {
filename = AM625_SK_DTB;
};
hash {
-- 
2.40.0

[PATCH V3 0/4] board: ti: Add support for BeaglePlay

[Nishanth Menon]

Add support for BeaglePlay - rev 3

Boot log: https://gist.github.com/nmenon/3e99b44380873263e39ba4d84788db89

Full series(including dependencies) can be found at:
https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3

Caveats:
* I have kept networking out of picture for now as it is still in debug
 (See
  https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3-enet-debug
  if anyone is interested)

Changes since V2:
* I have rebased to latest next branch
  bdc682437a67 (origin/next) Merge branch '2023-08-14-assorted-general-updates' 
into next
* Uses config fragments by default.
* Updated MAINTAINER file as well

V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/

Nishanth Menon (3):
  arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
  board: ti: am62x: Add am62x_beagleplay_* defconfigs
  doc: board: ti: Add BeaglePlay documentation

Robert Nelson (1):
  arm: dts: Add k3-am625-beagleplay

 arch/arm/dts/Makefile |2 +
 .../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 +
 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi  |  172 ++
 arch/arm/dts/k3-am625-beagleplay.dts  |  758 ++
 arch/arm/dts/k3-am625-r5-beagleplay.dts   |   87 +
 arch/arm/dts/k3-am625-sk-binman.dtsi  |4 +-
 board/ti/am62x/MAINTAINERS|7 +
 board/ti/am62x/beagleplay_a53.config  |   20 +
 board/ti/am62x/beagleplay_r5.config   |   11 +
 doc/board/ti/am62x_beagleplay.rst |  121 +
 doc/board/ti/k3.rst   |1 +
 11 files changed, 3376 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
 create mode 100644 arch/arm/dts/k3-am625-r5-beagleplay.dts
 create mode 100644 board/ti/am62x/beagleplay_a53.config
 create mode 100644 board/ti/am62x/beagleplay_r5.config
 create mode 100644 doc/board/ti/am62x_beagleplay.rst

-- 
2.40.0

[PATCH V3 3/4] board: ti: am62x: Add am62x_beagleplay_* defconfigs

[Nishanth Menon]

Add defconfig fragments for am625 based beagleplay

Signed-off-by: Nishanth Menon 
---
Changes since V2:
* Switch entirely to config fragments.

V2: https://lore.kernel.org/u-boot/20230727234446.3651836-4...@ti.com/
V1: https://lore.kernel.org/all/20230725185253.2123433-6...@ti.com/
 board/ti/am62x/beagleplay_a53.config | 20 
 board/ti/am62x/beagleplay_r5.config  | 11 +++
 2 files changed, 31 insertions(+)
 create mode 100644 board/ti/am62x/beagleplay_a53.config
 create mode 100644 board/ti/am62x/beagleplay_r5.config

diff --git a/board/ti/am62x/beagleplay_a53.config 
b/board/ti/am62x/beagleplay_a53.config
new file mode 100644
index ..4889e1bc6f2b
--- /dev/null
+++ b/board/ti/am62x/beagleplay_a53.config
@@ -0,0 +1,20 @@
+# Defconfig fragment to apply on top of am62x_evm_a53_defconfig
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-beagleplay"
+CONFIG_OF_LIST="k3-am625-beagleplay"
+CONFIG_SPL_OF_LIST="k3-am625-beagleplay"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run distro_bootcmd"
+CONFIG_EXT4_WRITE=y
+CONFIG_LZO=y
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
+CONFIG_AUTOBOOT_DELAY_STR="d"
+CONFIG_AUTOBOOT_STOP_STR=" "
+# Uses Realtek phy rather than TI phy
+CONFIG_PHY_TI_DP83867=n
+CONFIG_PHY_REALTEK=y
+# No SPI flash on Beagleplay
+CONFIG_SPI=n
+CONFIG_SPI_FLASH=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
diff --git a/board/ti/am62x/beagleplay_r5.config 
b/board/ti/am62x/beagleplay_r5.config
new file mode 100644
index ..ce64561bee92
--- /dev/null
+++ b/board/ti/am62x/beagleplay_r5.config
@@ -0,0 +1,11 @@
+# Defconfig fragment to apply on top of:
+# am62x_evm_r5_defconfig
+#
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-beagleplay"
+CONFIG_OF_LIST="k3-am625-r5-beagleplay"
+CONFIG_SPL_OF_LIST="k3-am625-r5-beagleplay"
+# No SPI flash on Beagleplay
+CONFIG_SPI=n
+CONFIG_SPI_FLASH=n
+CONFIG_SPL_DM_SPI_FLASH=n
+CONFIG_SPL_SPI_FLASH_SUPPORT=n
-- 
2.40.0

[PATCH] nvmxip: add sandbox support

[Abdellatif El Khlifi]

enable the 32-bit version of sandbox

Initially NVMXIP came with sandbox64 support.
Let's enable sandbox support as well.

Signed-off-by: Abdellatif El Khlifi 
Cc: Tom Rini 
Cc: Simon Glass 
---
 arch/sandbox/dts/sandbox.dts   | 14 ++
 configs/sandbox_defconfig  |  4 ++--
 drivers/mtd/nvmxip/nvmxip-uclass.c |  6 +++---
 drivers/mtd/nvmxip/nvmxip.c| 13 +++--
 drivers/mtd/nvmxip/nvmxip_qspi.c   | 10 +-
 test/dm/Makefile   |  2 +-
 6 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 12d3eff5fa..1d38a939c4 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -97,6 +97,20 @@
compatible = "sandbox,spi";
cs-gpios = <0>, <_a 0>;
};
+
+   nvmxip-qspi1@0800 {
+   compatible = "nvmxip,qspi";
+   reg = <0x0800 0x0020>;
+   lba_shift = <9>;
+   lba = <4096>;
+   };
+
+   nvmxip-qspi2@0820 {
+   compatible = "nvmxip,qspi";
+   reg = <0x0820 0x0010>;
+   lba_shift = <9>;
+   lba = <2048>;
+   };
 };
 
 #include "sandbox.dtsi"
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1cd1c2ed7c..296f9d7326 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -145,7 +145,6 @@ CONFIG_IP_DEFRAG=y
 CONFIG_BOOTP_SERVERIP=y
 CONFIG_IPV6=y
 CONFIG_DM_DMA=y
-CONFIG_DEVRES=y
 CONFIG_DEBUG_DEVRES=y
 CONFIG_SIMPLE_PM_BUS=y
 CONFIG_ADC=y
@@ -184,6 +183,7 @@ CONFIG_DMA_CHANNELS=y
 CONFIG_SANDBOX_DMA=y
 CONFIG_FASTBOOT_FLASH=y
 CONFIG_FASTBOOT_FLASH_MMC_DEV=0
+CONFIG_ARM_FFA_TRANSPORT=y
 CONFIG_GPIO_HOG=y
 CONFIG_DM_GPIO_LOOKUP_LABEL=y
 CONFIG_QCOM_PMIC_GPIO=y
@@ -227,6 +227,7 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_NVMXIP_QSPI=y
 CONFIG_MULTIPLEXER=y
 CONFIG_MUX_MMIO=y
 CONFIG_NVME_PCI=y
@@ -345,4 +346,3 @@ CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
-CONFIG_ARM_FFA_TRANSPORT=y
diff --git a/drivers/mtd/nvmxip/nvmxip-uclass.c 
b/drivers/mtd/nvmxip/nvmxip-uclass.c
index 6d8eb177b5..7177f8f314 100644
--- a/drivers/mtd/nvmxip/nvmxip-uclass.c
+++ b/drivers/mtd/nvmxip/nvmxip-uclass.c
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#if CONFIG_IS_ENABLED(SANDBOX64)
+#if CONFIG_IS_ENABLED(SANDBOX)
 #include 
 #endif
 #include 
@@ -39,7 +39,7 @@ static int nvmxip_post_bind(struct udevice *udev)
char bdev_name[NVMXIP_BLKDEV_NAME_SZ + 1];
int devnum;
 
-#if CONFIG_IS_ENABLED(SANDBOX64)
+#if CONFIG_IS_ENABLED(SANDBOX)
sandbox_set_enable_memio(true);
 #endif
 
@@ -62,7 +62,7 @@ static int nvmxip_post_bind(struct udevice *udev)
return ret;
}
 
-   log_info("[%s]: the block device %s ready for use\n", udev->name, 
bdev_name);
+   log_debug("[%s]: the block device %s ready for use\n", udev->name, 
bdev_name);
 
return 0;
 }
diff --git a/drivers/mtd/nvmxip/nvmxip.c b/drivers/mtd/nvmxip/nvmxip.c
index a359e3b482..9191e69a40 100644
--- a/drivers/mtd/nvmxip/nvmxip.c
+++ b/drivers/mtd/nvmxip/nvmxip.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "nvmxip.h"
@@ -26,9 +27,17 @@
  *
  * Always return 0.
  */
-static int nvmxip_mmio_rawread(const phys_addr_t address, u64 *value)
+static int nvmxip_mmio_rawread(const u64 *address, u64 *value)
 {
+#if CONFIG_IS_ENABLED(PHYS_64BIT)
*value = readq(address);
+#else
+   u32 h_word, l_word;
+
+   l_word = readl(address);
+   h_word = readl((u8 *)address + sizeof(u32));
+   *value = FIELD_PREP(GENMASK_ULL(63, 32), h_word) | l_word;
+#endif
return 0;
 }
 
@@ -67,7 +76,7 @@ static ulong nvmxip_blk_read(struct udevice *dev, lbaint_t 
blknr, lbaint_t blkcn
/* assumption: the data is virtually contiguous */
 
for (qdata_idx = 0 ; qdata_idx < qwords ; qdata_idx++)
-   nvmxip_mmio_rawread((phys_addr_t)(virt_blkaddr + qdata_idx), 
pdst++);
+   nvmxip_mmio_rawread(virt_blkaddr + qdata_idx, pdst++);
 
log_debug("[%s]: src[0]: 0x%llx , dst[0]: 0x%llx , src[-1]: 0x%llx 
, dst[-1]: 0x%llx\n",
  dev->name,
diff --git a/drivers/mtd/nvmxip/nvmxip_qspi.c b/drivers/mtd/nvmxip/nvmxip_qspi.c
index 7221fd1cb4..b6b94ca57f 100644
--- a/drivers/mtd/nvmxip/nvmxip_qspi.c
+++ b/drivers/mtd/nvmxip/nvmxip_qspi.c
@@ -17,6 +17,14 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define NVMXIP_QSPI_DRV_NAME "nvmxip_qspi"
 
+/* Select the right physical address formatting according to the platform */
+#ifdef CONFIG_PHYS_64BIT
+#define PhysAddrLength "ll"
+#else
+#define PhysAddrLength ""
+#endif
+#define PHYS_ADDR_LN "%" PhysAddrLength "x"
+
 /**
  * nvmxip_qspi_of_to_plat() -read from DT
  * @dev:   the NVMXIP device
@@ -50,7 +58,7 @@ static int 

Pull request for efi-2023-10-rc3

[Heinrich Schuchardt]

Dear Tom,

The following changes since commit 832148f675e427060be074c276956962fa9b5cb6:

  Merge tag 'u-boot-rockchip-20230814' of
https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-08-14
09:11:09 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2023-10-rc3

for you to fetch changes up to d768dd88552df18d4a0527cf3d6ddd05dc072f02:

  common: return type board_get_usable_ram_top (2023-08-15 18:21:17 +0200)


Pull request for efi-2023-10-rc3

Documentation:

* Correct description of board_get_usable_ram_top
* Add partition API to HTML documentation
* Describe  lmb_is_reserved
* doc/sphinx/requirements.txt: Bump certifi up

UEFI:

* Fix  efi_add_known_memory
* Make distro_efi_boot() static

Other:

* Correct return type board_get_usable_ram_top


Bin Meng (1):
  bootmeth: efi: Make distro_efi_boot() static

Heinrich Schuchardt (5):
  lmb: description lmb_is_reserved, lmb_is_reserved_flags
  doc: description of board_get_usable_ram_top()
  doc: add partition API to HTML documentation
  efi_loader: fix efi_add_known_memory()
  common: return type board_get_usable_ram_top

Tom Rini (1):
  doc/sphinx/requirements.txt: Bump certifi up

 arch/arm/mach-imx/imx8m/soc.c   |   2 +-
 arch/arm/mach-mvebu/arm64-common.c  |   2 +-
 arch/arm/mach-rockchip/sdram.c  |   2 +-
 arch/arm/mach-stm32mp/dram_init.c   |   2 +-
 arch/arm/mach-sunxi/board.c |   2 +-
 arch/arm/mach-tegra/board2.c|   2 +-
 arch/mips/mach-jz47xx/jz4780/jz4780.c   |   2 +-
 arch/mips/mach-octeon/dram.c|   2 +-
 arch/riscv/cpu/fu540/dram.c |   2 +-
 arch/riscv/cpu/fu740/dram.c |   2 +-
 arch/riscv/cpu/generic/dram.c   |   2 +-
 arch/riscv/cpu/jh7110/dram.c|   2 +-
 arch/x86/cpu/broadwell/sdram.c  |   2 +-
 arch/x86/cpu/coreboot/sdram.c   |   2 +-
 arch/x86/cpu/efi/payload.c  |   2 +-
 arch/x86/cpu/efi/sdram.c|   2 +-
 arch/x86/cpu/ivybridge/sdram.c  |   2 +-
 arch/x86/cpu/qemu/dram.c|   2 +-
 arch/x86/cpu/quark/dram.c   |   2 +-
 arch/x86/cpu/slimbootloader/sdram.c |   2 +-
 arch/x86/cpu/tangier/sdram.c|   2 +-
 arch/x86/include/asm/u-boot-x86.h   |   2 +-
 arch/x86/lib/fsp1/fsp_dram.c|   2 +-
 arch/x86/lib/fsp2/fsp_dram.c|   2 +-
 board/broadcom/bcmns3/ns3.c |   2 +-
 board/imgtec/boston/ddr.c   |   2 +-
 board/menlo/m53menlo/m53menlo.c |   2 +-
 board/raspberrypi/rpi/rpi.c |   2 +-
 board/ti/am65x/evm.c|   2 +-
 board/ti/j721e/evm.c|   2 +-
 board/ti/j721s2/evm.c   |   2 +-
 board/toradex/verdin-am62/verdin-am62.c |   2 +-
 board/xilinx/common/board.c |   2 +-
 boot/bootmeth_efi.c |   2 +-
 common/board_f.c|   2 +-
 doc/api/index.rst   |   1 +
 doc/api/part.rst|   6 +
 doc/sphinx/requirements.txt |   2 +-
 include/init.h  |  17 ++-
 include/lmb.h   |  21 +++-
 include/part.h  | 210
+---
 lib/efi_loader/efi_memory.c |   2 +-
 42 files changed, 185 insertions(+), 144 deletions(-)
 create mode 100644 doc/api/part.rst

[PATCH 5/6] cmd: gpt: Preserve bootable flag

[Joshua Watt]

Sets the bootable flag when constructing the partition string from the
current partition configuration. This ensures that when the partitions
are written back (for example, when renaming a partition), the flag is
preserved.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index c6fbd94ba2..58564436d3 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -176,6 +176,7 @@ static int calc_parts_list_len(int numparts)
 #ifdef CONFIG_PARTITION_TYPE_GUID
partlistlen += numparts * (strlen("type=,") + UUID_STR_LEN + 1);
 #endif
+   partlistlen += numparts * strlen("bootable,");
partlistlen += numparts * (strlen("uuid=;") + UUID_STR_LEN + 1);
/* for the terminating null */
partlistlen++;
@@ -318,6 +319,8 @@ static int create_gpt_partitions_list(int numparts, const 
char *guid,
strcat(partitions_list, ",uuid=");
strncat(partitions_list, curr->gpt_part_info.uuid,
UUID_STR_LEN + 1);
+   if (curr->gpt_part_info.bootable & PART_BOOTABLE)
+   strcat(partitions_list, ",bootable");
strcat(partitions_list, ";");
}
return 0;
-- 
2.33.0

[PATCH 6/6] cmd: gpt: Add command to swap partition order

[Joshua Watt]

Adds a command called "gpt swap-postition" which will swap the order two
partitions are listed in the GPT partition table (but leaves them
pointing to the same locations on disk).

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 50 --
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 58564436d3..c8a2b5ae7b 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -859,7 +859,7 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
int partlistlen, ret, numparts = 0, partnum, i = 1, ctr1 = 0, ctr2 = 0;
 
if ((subcomm == NULL) || (name1 == NULL) || (name2 == NULL) ||
-   (strcmp(subcomm, "swap") && (strcmp(subcomm, "rename"
+   (strcmp(subcomm, "swap") && strcmp(subcomm, "rename") && 
strcmp(subcomm, "swap-position")))
return -EINVAL;
 
ret = get_disk_guid(dev_desc, disk_guid);
@@ -920,6 +920,48 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
ret = -EINVAL;
goto out;
}
+   } else if(!strcmp(subcomm, "swap-position")) {
+   int idx1, idx2;
+   struct disk_partition first, second;
+   idx1 = simple_strtoul(name1, NULL, 10);
+   if (idx1 <= 0 || idx1 > numparts) {
+   printf("Illegal partition number %s\n", name1);
+   ret = -EINVAL;
+   goto out;
+   }
+   idx2 = simple_strtoul(name2, NULL, 10);
+   if (idx2 <= 0 || idx2 > numparts) {
+   printf("Illegal partition number %s\n", name2);
+   ret = -EINVAL;
+   goto out;
+   }
+   if (idx1 == idx2) {
+   printf("Cannot swap partition with itself\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
+   i = 1;
+   list_for_each(pos, _partitions) {
+   curr = list_entry(pos, struct disk_part, list);
+   if (i == idx1) {
+   first = curr->gpt_part_info;
+   } else if (i == idx2) {
+   second = curr->gpt_part_info;
+   }
+   i++;
+   }
+
+   i = 1;
+   list_for_each(pos, _partitions) {
+   curr = list_entry(pos, struct disk_part, list);
+   if (i == idx1) {
+   curr->gpt_part_info = second;
+   } else if (i == idx2) {
+   curr->gpt_part_info = first;
+   }
+   i++;
+   }
} else { /* rename */
if (strlen(name2) > PART_NAME_LEN) {
printf("Names longer than %d characters are 
truncated.\n", PART_NAME_LEN);
@@ -1122,7 +1164,8 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
} else if (strcmp(argv[1], "read") == 0) {
ret = do_get_gpt_info(blk_dev_desc, (argc == 5) ? argv[4] : 
NULL);
} else if ((strcmp(argv[1], "swap") == 0) ||
-  (strcmp(argv[1], "rename") == 0)) {
+  (strcmp(argv[1], "rename") == 0) ||
+  (strcmp(argv[1], "swap-position") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
argv[5]);
 #endif
} else if ((strcmp(argv[1], "set-bootable") == 0)) {
@@ -1175,11 +1218,14 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt swap\n"
"- change all partitions named name1 to name2\n"
"  and vice-versa\n"
+   " gpt swap-position\n"
+   "- Swap the order of name1 with name2 in the partition table\n"
" gpt rename\n"
"- rename the specified partition\n"
" Example usage:\n"
" gpt swap mmc 0 foo bar\n"
" gpt rename mmc 0 3 foo\n"
+   " gpt swap-partitions mmc 0 1 2\n"
 #endif
" gpt set-bootable   \n"
"- make partition names in list bootable\n"
-- 
2.33.0

[PATCH 4/6] cmd: gpt: Preserve type GUID if enabled

[Joshua Watt]

If CONFIG_PARTITION_TYPE_GUID is enabled, the type GUID will be
preserved when writing out the partition string. It was already
respected when writing out partitions; this ensures that if you capture
the current partition layout and write it back (such as when renaming),
the type GUIDs are preserved.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index bc08799512..c6fbd94ba2 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -173,6 +173,9 @@ static int calc_parts_list_len(int numparts)
/* see part.h for definition of struct disk_partition */
partlistlen += numparts * (strlen("start=MiB,") + sizeof(lbaint_t) + 1);
partlistlen += numparts * (strlen("size=MiB,") + sizeof(lbaint_t) + 1);
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   partlistlen += numparts * (strlen("type=,") + UUID_STR_LEN + 1);
+#endif
partlistlen += numparts * (strlen("uuid=;") + UUID_STR_LEN + 1);
/* for the terminating null */
partlistlen++;
@@ -211,6 +214,11 @@ static struct disk_part *allocate_disk_part(struct 
disk_partition *info,
PART_TYPE_LEN);
newpart->gpt_part_info.type[PART_TYPE_LEN - 1] = '\0';
newpart->gpt_part_info.bootable = info->bootable;
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   strncpy(newpart->gpt_part_info.type_guid, (const char *)info->type_guid,
+   UUID_STR_LEN);
+   newpart->gpt_part_info.type_guid[UUID_STR_LEN] = '\0';
+#endif
 #ifdef CONFIG_PARTITION_UUIDS
strncpy(newpart->gpt_part_info.uuid, (const char *)info->uuid,
UUID_STR_LEN);
@@ -252,6 +260,9 @@ static void print_gpt_info(void)
   curr->gpt_part_info.name);
printf("Type %s, bootable %d\n", curr->gpt_part_info.type,
   curr->gpt_part_info.bootable & PART_BOOTABLE);
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   printf("Type GUID %s\n", curr->gpt_part_info.type_guid);
+#endif
 #ifdef CONFIG_PARTITION_UUIDS
printf("UUID %s\n", curr->gpt_part_info.uuid);
 #endif
@@ -299,6 +310,11 @@ static int create_gpt_partitions_list(int numparts, const 
char *guid,
curr->gpt_part_info.blksz);
strncat(partitions_list, partstr, PART_NAME_LEN + 1);
 
+#ifdef CONFIG_PARTITION_TYPE_GUID
+   strcat(partitions_list, ",type=");
+   strncat(partitions_list, curr->gpt_part_info.type_guid,
+   UUID_STR_LEN + 1);
+#endif
strcat(partitions_list, ",uuid=");
strncat(partitions_list, curr->gpt_part_info.uuid,
UUID_STR_LEN + 1);
-- 
2.33.0

[PATCH 3/6] cmd: gpt: Add gpt_partition_bootable variable

[Joshua Watt]

Adds an additional variable called gpt_partition_bootable that indicates
if the given partition is bootable or not.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index a4b8b2b286..bc08799512 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -723,7 +723,7 @@ static int gpt_enumerate(struct blk_desc *desc)
  * gpt_setenv_part_variables() - setup partition environmental variables
  *
  * Setup the gpt_partition_name, gpt_partition_entry, gpt_partition_addr
- * and gpt_partition_size environment variables.
+ * and gpt_partition_size, gpt_partition_bootable environment variables.
  *
  * @pinfo: pointer to disk partition
  * @i: partition entry
@@ -750,6 +750,10 @@ static int gpt_setenv_part_variables(struct disk_partition 
*pinfo, int i)
if (ret)
goto fail;
 
+   ret = env_set_ulong("gpt_partition_bootable", !!(pinfo->bootable & 
PART_BOOTABLE));
+   if (ret)
+   goto fail;
+
return 0;
 
 fail:
@@ -1133,7 +1137,8 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt setenv mmc 0 $name\n"
"- setup environment variables for partition $name:\n"
"  gpt_partition_addr, gpt_partition_size,\n"
-   "  gpt_partition_name, gpt_partition_entry\n"
+   "  gpt_partition_name, gpt_partition_entry,\n"
+   "  gpt_partition_bootable\n"
" gpt enumerate mmc 0\n"
"- store list of partitions to gpt_partition_list environment 
variable\n"
" gpt guid  \n"
-- 
2.33.0

[PATCH 2/6] cmd: gpt: Add command to set bootable flags

[Joshua Watt]

Adds a command that can be used to modify the GPT partition table to
indicate which partitions should have the bootable flag set

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 80 +++
 1 file changed, 80 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index e6f7b0319a..a4b8b2b286 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -970,6 +970,80 @@ static int do_rename_gpt_parts(struct blk_desc *dev_desc, 
char *subcomm,
 }
 #endif
 
+/**
+ * gpt_set_bootable() - Set bootable flags for partitions
+ *
+ * Sets the bootable flag for any partition names in the comma separated list 
of
+ * partition names. Any partitions not in the list have their bootable flag
+ * cleared
+ *
+ * @desc: block device descriptor
+ * @name: Comma separated list of partition names
+ *
+ * @Return: '0' on success and -ve error on failure
+ */
+static int gpt_set_bootable(struct blk_desc *blk_dev_desc, char *const 
part_list)
+{
+   char *name;
+   char disk_guid[UUID_STR_LEN + 1];
+   struct list_head *pos;
+   struct disk_part *curr;
+   struct disk_partition *partitions = NULL;
+   int part_count = 0;
+
+   int ret = get_disk_guid(blk_dev_desc, disk_guid);
+   if (ret < 0)
+   return ret;
+
+   ret = get_gpt_info(blk_dev_desc);
+   if (ret <= 0)
+   goto out;
+
+   part_count = ret;
+   partitions = malloc(sizeof(*partitions) * part_count);
+   if (!partitions) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   /* Copy partitions and clear bootable flag */
+   part_count = 0;
+   list_for_each(pos, _partitions) {
+   curr = list_entry(pos, struct disk_part, list);
+   partitions[part_count] = curr->gpt_part_info;
+   partitions[part_count].bootable &= ~PART_BOOTABLE;
+   part_count++;
+   }
+
+   name = strtok(part_list, ",");
+   while (name) {
+   bool found = false;
+   for (int i = 0; i < part_count; i++) {
+   if (strcmp((char *)partitions[i].name, name) == 0) {
+   partitions[i].bootable |= PART_BOOTABLE;
+   found = true;
+   }
+   }
+
+   if (!found) {
+   printf("Warning: No partition matching '%s' found\n",
+  name);
+   }
+
+   name = strtok(NULL, ",");
+   }
+
+   ret = gpt_restore(blk_dev_desc, disk_guid, partitions, part_count);
+
+out:
+   del_gpt_info();
+
+   if (partitions)
+   free(partitions);
+
+   return ret;
+}
+
 /**
  * do_gpt(): Perform GPT operations
  *
@@ -1028,6 +1102,8 @@ static int do_gpt(struct cmd_tbl *cmdtp, int flag, int 
argc, char *const argv[])
   (strcmp(argv[1], "rename") == 0)) {
ret = do_rename_gpt_parts(blk_dev_desc, argv[1], argv[4], 
argv[5]);
 #endif
+   } else if ((strcmp(argv[1], "set-bootable") == 0)) {
+   ret = gpt_set_bootable(blk_dev_desc, argv[4]);
} else {
return CMD_RET_USAGE;
}
@@ -1081,4 +1157,8 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" gpt swap mmc 0 foo bar\n"
" gpt rename mmc 0 3 foo\n"
 #endif
+   " gpt set-bootable   \n"
+   "- make partition names in list bootable\n"
+   " Example usage:\n"
+   " gpt set-bootable mmc 0 boot_a,boot_b\n"
 );
-- 
2.33.0

[PATCH 1/6] cmd: gpt: Remove confusing help text

[Joshua Watt]

This help text appears to be a fragment of the text shown when
CONFIG_CMD_GPT_RENAME is enabled, but is confusing so remove it.

Signed-off-by: Joshua Watt 
---
 cmd/gpt.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index 007a68eaa7..e6f7b0319a 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -1060,8 +1060,6 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
"  gpt_partition_name, gpt_partition_entry\n"
" gpt enumerate mmc 0\n"
"- store list of partitions to gpt_partition_list environment 
variable\n"
-   " read  \n"
-   "- read GPT into a data structure for manipulation\n"
" gpt guid  \n"
"- print disk GUID\n"
" gpt guid   \n"
-- 
2.33.0

[PATCH 0/6] cmd: gpt: GPT manipulation improvements

[Joshua Watt]

Adds several improvements and additions to the gpt command processing,
specifically (although not exclusively) for the purpose of supporting
"ping-pong" booting when doing A/B boot partitions with u-boot itself.

In this mechanism, u-boot must boot up, and then check if the correct
boot partition is active, and if not switch the GPT partition table to
the other boot partition and reboot to activate the other u-boot.

In order to facilitate this, the gpt command needs to be better at
preserving entry attributes when manipulating the partition table. It
also learns two new commands, one which can swap the order of partitions
in the table, and another that lets it change which partitions have the
bootable flag.

Joshua Watt (6):
  cmd: gpt: Remove confusing help text
  cmd: gpt: Add command to set bootable flags
  cmd: gpt: Add gpt_partition_bootable variable
  cmd: gpt: Preserve type GUID if enabled
  cmd: gpt: Preserve bootable flag
  cmd: gpt: Add command to swap partition order

 cmd/gpt.c | 160 --
 1 file changed, 154 insertions(+), 6 deletions(-)

-- 
2.33.0

[PATCH 5/5] test: capsule: Remove logic to add public key ESL

[Sughosh Ganu]

The public key EFI Signature List(ESL) needed for capsule
authentication is now embedded into the platform's DTB as part of the
build. Remove the superfluous logic from the test setup.

Signed-off-by: Sughosh Ganu 
---
Changes since RFC series:
* New patch

 test/py/tests/test_efi_capsule/conftest.py   | 28 +---
 test/py/tests/test_efi_capsule/signature.dts | 10 ---
 2 files changed, 7 insertions(+), 31 deletions(-)
 delete mode 100644 test/py/tests/test_efi_capsule/signature.dts

diff --git a/test/py/tests/test_efi_capsule/conftest.py 
b/test/py/tests/test_efi_capsule/conftest.py
index 7eead9bc64..67761a9708 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -49,33 +49,19 @@ def efi_capsule_data(request, u_boot_config):
 check_call('cp %s/capsule_pub_key_bad.crt %s/SIGNER2.crt'
% (key_dir, data_dir), shell=True)
 
-# Update dtb adding capsule certificate
-check_call('cd %s; '
-   'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
-   % (data_dir, u_boot_config.source_dir), shell=True)
+if capsule_auth_enabled:
 check_call('cd %s; '
-   'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
-   'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_sig.dtb signature.dtbo'
+   'cp %s/arch/sandbox/dts/test.dtb test_sig.dtb'
% (data_dir, u_boot_config.build_dir), shell=True)
-
 # Update dtb to add the version information
 check_call('cd %s; '
'cp %s/test/py/tests/test_efi_capsule/version.dts .'
% (data_dir, u_boot_config.source_dir), shell=True)
-if capsule_auth_enabled:
-check_call('cd %s; '
-   'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
-   'fdtoverlay -i test_sig.dtb '
-'-o test_ver.dtb version.dtbo'
-   % (data_dir), shell=True)
-else:
-check_call('cd %s; '
-   'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
-   'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_ver.dtb version.dtbo'
-   % (data_dir, u_boot_config.build_dir), shell=True)
-
+check_call('cd %s; '
+   'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
+   'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
+   '-o test_ver.dtb version.dtbo'
+   % (data_dir, u_boot_config.build_dir), shell=True)
 
 check_call('cp %s/u-boot_bin_env.itb %s ' % (u_boot_config.build_dir, 
data_dir), shell=True)
 check_call('cp %s/Test* %s ' % (u_boot_config.build_dir, data_dir), 
shell=True)
diff --git a/test/py/tests/test_efi_capsule/signature.dts 
b/test/py/tests/test_efi_capsule/signature.dts
deleted file mode 100644
index 078cfc76c9..00
--- a/test/py/tests/test_efi_capsule/signature.dts
+++ /dev/null
@@ -1,10 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-
-/dts-v1/;
-/plugin/;
-
-&{/} {
-   signature {
-   capsule-key = /incbin/("SIGNER.esl");
-   };
-};
-- 
2.34.1

[PATCH 4/5] doc: capsule: Document the new mechanism to embed ESL file into dtb

[Sughosh Ganu]

Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the U-Boot build.

Signed-off-by: Sughosh Ganu 
---
Changes since RFC series:
* s/u-boot/U-Boot in the commit message.

 doc/develop/uefi/uefi.rst | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 3ce579d46e..950f4d1a5a 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -539,20 +539,11 @@ and used by the steps highlighted below.
 ...
 }
 
-You can do step-4 manually with
-
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. This symbol defines the path to the esl
+file generated in step-2. Once the symbol has been populated with the
+path to the esl file, the esl file will automatically get embedded
+into the platform's dtb as part of U-Boot build.
 
 Anti-rollback Protection
 
-- 
2.34.1

[PATCH 3/5] sandbox: capsule: Add path to the public key ESL file

[Sughosh Ganu]

Add the path to the public key EFI Signature List(ESL) file for the
sandbox variants which enable capsule authentication. This ESL file
gets embedded into the platform's device-tree as part of the build.

Signed-off-by: Sughosh Ganu 
---
Changes since RFC series: None

 configs/sandbox_defconfig  | 1 +
 configs/sandbox_flattree_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 1cd1c2ed7c..9f349d482b 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -340,6 +340,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
 CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="board/sandbox/capsule_pub_esl_good.esl"
 CONFIG_EFI_SECURE_BOOT=y
 CONFIG_TEST_FDTDEC=y
 CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index 8aa295686d..2a24b38cfb 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -227,6 +227,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
 CONFIG_EFI_CAPSULE_ON_DISK=y
 CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
 CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="board/sandbox/capsule_pub_esl_good.esl"
 CONFIG_UNIT_TEST=y
 CONFIG_UT_TIME=y
 CONFIG_UT_DM=y
-- 
2.34.1

[PATCH 2/5] scripts/Makefile.lib: Embed capsule public key in platform's dtb

[Sughosh Ganu]

The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.

Add a target for generating a dtsi file which contains the signature
node with the ESL file included as a property under the signature
node. Include the dtsi file in the dtb. This brings the embedding of
the ESL in the dtb into the U-Boot build flow.

The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.

Signed-off-by: Sughosh Ganu 
---
Changes since RFC series:
* Remove the default value of the config symbol.
* s/include_files/dtsi_include_list
* Add all the dtsi files being included as dependency for the dtb
  target.

 lib/efi_loader/Kconfig |  8 
 lib/efi_loader/capsule_esl.dtsi.in | 11 +++
 scripts/Makefile.lib   | 18 +-
 3 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 lib/efi_loader/capsule_esl.dtsi.in

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 9989e3f384..d20aaab6db 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -272,6 +272,14 @@ config EFI_CAPSULE_MAX
  Select the max capsule index value used for capsule report
  variables. This value is used to create CapsuleMax variable.
 
+config EFI_CAPSULE_ESL_FILE
+   string "Path to the EFI Signature List File"
+   depends on EFI_CAPSULE_AUTHENTICATE
+   help
+ Provides the path to the EFI Signature List file which will
+ be embedded in the platform's device tree and used for
+ capsule authentication at the time of capsule update.
+
 config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
diff --git a/lib/efi_loader/capsule_esl.dtsi.in 
b/lib/efi_loader/capsule_esl.dtsi.in
new file mode 100644
index 00..61a9f2b25e
--- /dev/null
+++ b/lib/efi_loader/capsule_esl.dtsi.in
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Devicetree file with the public key EFI Signature List(ESL)
+ * node. This file is used to generate the dtsi file to be
+ * included into the DTB.
+*/
+/ {
+   signature {
+   capsule-key = /incbin/("ESL_BIN_FILE");
+   };
+};
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 368b5a3e28..2e71f190bc 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -334,7 +334,23 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
; \
sed "s:$(pre-tmp):$(<):" $(depfile).pre.tmp $(depfile).dtc.tmp > 
$(depfile)
 
-$(obj)/%.dtb: $(src)/%.dts $(DTC) FORCE
+ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+quiet_cmd_capsule_esl_gen = CAPSULE_ESL_GEN $@
+cmd_capsule_esl_gen = \
+   $(shell sed "s:ESL_BIN_FILE:$(capsule_esl_path):" 
$(capsule_esl_input_file) > $@)
+
+$(obj)/.capsule_esl.dtsi:
+   $(call cmd_capsule_esl_gen)
+
+capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
+capsule_esl_dtsi = .capsule_esl.dtsi
+capsule_esl_path=$(abspath $(srctree)/$(subst 
$(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
+dtsi_include_list += $(capsule_esl_dtsi)
+endif
+
+dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
$(quote),,$(dtsi_include_list)))
+
+$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
$(call if_changed_dep,dtc)
 
 pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
-- 
2.34.1

[PATCH 1/5] scripts/Makefile.lib: Collate all dtsi files for inclusion

[Sughosh Ganu]

At the time of building a device-tree file, all the *u-boot.dtsi files
are looked for, in a particular order, and the first file found is
included. Then, the list of files specified in the
CONFIG_DEVICE_TREE_INCLUDES symbol are included.

Combine these files that are to be included into a variable, and then
include all these files in one go.

Signed-off-by: Sughosh Ganu 
---
Changes since RFC series:
* s/include_files/dtsi_include_list

 scripts/Makefile.lib | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index f5ab7af0f4..368b5a3e28 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -179,10 +179,13 @@ ifdef DEVICE_TREE_DEBUG
 u_boot_dtsi_options_debug = $(warning $(u_boot_dtsi_options_raw))
 endif
 
-# We use the first match
-u_boot_dtsi = $(strip $(u_boot_dtsi_options_debug) \
+# We use the first match to be included
+dtsi_include_list = $(strip $(u_boot_dtsi_options_debug) \
$(notdir $(firstword $(u_boot_dtsi_options
 
+# The CONFIG_DEVICE_TREE_INCLUDES also need to be included
+dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
+
 # Modified for U-Boot
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc\
 $(UBOOTINCLUDE) \
@@ -320,8 +323,8 @@ quiet_cmd_dtc = DTC $@
 # Bring in any U-Boot-specific include at the end of the file
 # And finally any custom .dtsi fragments specified with 
CONFIG_DEVICE_TREE_INCLUDES
 cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
-   (cat $<; $(if $(u_boot_dtsi),echo '$(pound)include "$(u_boot_dtsi)"')) 
> $(pre-tmp); \
-   $(foreach f,$(subst $(quote),,$(CONFIG_DEVICE_TREE_INCLUDES)), \
+   (cat $< > $(pre-tmp)); \
+   $(foreach f,$(subst $(quote),,$(dtsi_include_list)), \
  echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
$(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) 
$(pre-tmp) ; \
$(DTC) -O dtb -o $@ -b 0 \
-- 
2.34.1

[PATCH 0/5] capsule: Embed the public key ESL as part of build

[Sughosh Ganu]

This series takes a different approach to embedding the public key EFI
Signature List(ESL) needed for capsule authentication into the
platform's DTB.

The earlier approach [1] was using a u-boot.dtsi file to embed the
key. But this approach has a few issues. 1) The path of the incbin file
is not relative to $(srctree), but relative to the directory of the
dts file which is including the dtsi -- this causes problems when the
dts file are located in different directories. 2) The u-boot.dtsi file
only gets included in the DTB if there are no other *u-boot.dtsi files
being included. 3) A separate u-boot.dtsi is needed per arch.

To get around these issues, this approach generates a dtsi
file(.capsule_esl.dtsi) with the public key node during build. This
generated dtsi file contains the resolved path to the ESL and is then
included for the DTB generation.

The first patch of the series also cleans up the logic to include the
dtsi files, by collating all the dtsi files to be included into a
single variable.

These patches need to be applied on top of the series for generating
the capsules as part of the build [2].

[1] - https://lists.denx.de/pipermail/u-boot/2023-August/526323.html
[2] - 
https://lore.kernel.org/u-boot/20230812153024.334563-1-sughosh.g...@linaro.org/T/#m85a50079007acf8943cfe8efcc7d78d23a40db7c

Changes since RFC series:

* s/include_files/dtsi_include_list
* Remove the default value of the config symbol.
* s/include_files/dtsi_include_list
* Add all the dtsi files being included as dependency for the dtb
  target.
* s/u-boot/U-Boot in the commit message.
* New patch for removing superfluous logic from efi capsule update
  test setup.

Sughosh Ganu (5):
  scripts/Makefile.lib: Collate all dtsi files for inclusion
  scripts/Makefile.lib: Embed capsule public key in platform's dtb
  sandbox: capsule: Add path to the public key ESL file
  doc: capsule: Document the new mechanism to embed ESL file into dtb
  test: capsule: Remove logic to add public key ESL

 configs/sandbox_defconfig|  1 +
 configs/sandbox_flattree_defconfig   |  1 +
 doc/develop/uefi/uefi.rst| 19 -
 lib/efi_loader/Kconfig   |  8 ++
 lib/efi_loader/capsule_esl.dtsi.in   | 11 
 scripts/Makefile.lib | 29 
 test/py/tests/test_efi_capsule/conftest.py   | 28 +--
 test/py/tests/test_efi_capsule/signature.dts | 10 ---
 8 files changed, 57 insertions(+), 50 deletions(-)
 create mode 100644 lib/efi_loader/capsule_esl.dtsi.in
 delete mode 100644 test/py/tests/test_efi_capsule/signature.dts

-- 
2.34.1

[PATCH 1/1] spl: don't assume NVMe partition 1 exists

[Heinrich Schuchardt]

There is no requirement that a partition 1 exists in a partition table.
We should not try to retrieve information about it.

We should not even try reading with partition number
CONFIG_SYS_NVME_BOOT_PARTITION here as this is done in the fs_set_blk_dev()
call anyway.

Fixes: 8ce6a2e17577 ("spl: blk: Support loading images from fs")
Signed-off-by: Heinrich Schuchardt 
---
 common/spl/spl_blk_fs.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/common/spl/spl_blk_fs.c b/common/spl/spl_blk_fs.c
index 16ecece702..eb6f526689 100644
--- a/common/spl/spl_blk_fs.c
+++ b/common/spl/spl_blk_fs.c
@@ -44,7 +44,6 @@ int spl_blk_load_image(struct spl_image_info *spl_image,
   enum uclass_id uclass_id, int devnum, int partnum)
 {
const char *filename = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME;
-   struct disk_partition part_info = {};
struct legacy_img_hdr *header;
struct blk_desc *blk_desc;
loff_t actlen, filesize;
@@ -59,11 +58,6 @@ int spl_blk_load_image(struct spl_image_info *spl_image,
 
blk_show_device(uclass_id, devnum);
header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
-   ret = part_get_info(blk_desc, 1, _info);
-   if (ret) {
-   printf("spl: no partition table found. Err - %d\n", ret);
-   goto out;
-   }
 
dev.ifname = blk_get_uclass_name(uclass_id);
snprintf(dev.dev_part_str, sizeof(dev.dev_part_str) - 1, "%x:%x",
-- 
2.40.1

Re: [PATCH 1/1] lib/vsprintf.c: fix integer overflow in vsprintf

[Paul Liu]

Hi Tom,

Yes, I think Rasmus is correct. I didn't have any real cases that can
trigger the bug.
So let's don't include this patch. I'll see if I can revert this in
AOSP's branch.

Yours,
Paul



Y

On Tue, 15 Aug 2023 at 22:42, Tom Rini  wrote:

> On Thu, Mar 09, 2023 at 10:12:21AM +0800, Ying-Chun Liu (PaulLiu) wrote:
>
> > From: Tom Cherry 
> >
> > vsnprintf_internal() adds 'size' to 'buf' and vsprintf() sets 'size'
> > to 'INT_MAX' which can overflow.  This causes sprintf() to fail when
> > initializing the environment on 8GB.
> >
> > Instead of using 'INT_MAX', we use SIZE_MAX - buf, which is the
> > largest possible string that could fit without overflowing 'size'.
> >
> > Signed-off-by: Tom Cherry 
> > [ Paul: pick from the Android tree. Rebase to the upstream ]
> > Signed-off-by: Ying-Chun Liu (PaulLiu) 
> > Cc: Tom Rini 
> > Link:
> https://android.googlesource.com/platform/external/u-boot/+/43aae5d4415e0f9d744fb798acd52429d09957ce
>
> So, this link here leads back to
> https://issuetracker.google.com/issues/200479053 which isn't public.
>
> Rasmus followed up and asked pointed questions, that weren't followed up
> on.
>
> --
> Tom
>

Re: [PATCH 1/1] doc: add partition API to HTML documentation

[Heinrich Schuchardt]

On 8/15/23 16:44, Simon Glass wrote:

Hi Heinrich,

On Tue, 15 Aug 2023 at 04:32, Heinrich Schuchardt
 wrote:


* Convert comments in part.h to Sphinx style.
* Create documentation page for the partition API.
* Add the partition API page to the API index page.

Signed-off-by: Heinrich Schuchardt 
---
  doc/api/index.rst |   1 +
  doc/api/part.rst  |   6 ++
  include/part.h| 210 --
  3 files changed, 119 insertions(+), 98 deletions(-)
  create mode 100644 doc/api/part.rst


Reviewed-by: Simon Glass 

Q below



diff --git a/doc/api/index.rst b/doc/api/index.rst
index a9338cfef9..3a80ae0635 100644
--- a/doc/api/index.rst
+++ b/doc/api/index.rst
@@ -15,6 +15,7 @@ U-Boot API documentation
 lmb
 logging
 nvmem
+   part
 pinctrl
 rng
 sandbox
diff --git a/doc/api/part.rst b/doc/api/part.rst
new file mode 100644
index 00..d1df1d8494
--- /dev/null
+++ b/doc/api/part.rst
@@ -0,0 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Partition API
+=
+[..]



+/**
+ * struct part_driver - partition driver
+ */
  struct part_driver {
+   /** @name:  partition name */
 const char *name;
+   /** @part_type: (MBR) partition type */
 int part_type;
-   const int max_entries;  /* maximum number of entries to search */
-
+   /** @max_entries:   maximum number of partition table entries */
+   const int max_entries;
 /**
-* get_info() - Get information about a partition
+* @get_info:   Get information about a partition


Are we not allowed the () at end? I much prefer brackets as they show
it is a function.


Thanks for reviewing.

'make htmldocs' does not like parentheses here:

Incorrect use of kernel-doc format:
* @get_info(): Get ...
Incorrect use of kernel-doc format:
* @get_info() - Get ...

We are using code from the kernel.org. We would have to change that 
upstream first:


scripts/kernel-doc:2325:
print STDERR "Incorrect use of kernel-doc format: $_";

Best regards

Heinrich




  *
-* @dev_desc:   Block device descriptor
-* @part:   Partition number (1 = first)
-* @info:   Returns partition information
+* @get_info.dev_desc:  Block device descriptor
+* @get_info.part:  Partition number (1 = first)
+* @get_info.info:  Returns partition information
  */
 int (*get_info)(struct blk_desc *dev_desc, int part,
 struct disk_partition *info);

[..]

Regards,
Simon

Re: Strange gitlab idea

[Tom Rini]

On Tue, Aug 15, 2023 at 08:44:20AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 13 Aug 2023 at 09:52, Tom Rini  wrote:
> >
> > On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > I notice that the runners are not utilised much by the QEMU jobs,
> > > since we only run one at a time.
> > >
> > > I wonder if we could improve this, perhaps by using a different tag
> > > for the QEMU ones and then having a machine that only runs those (and
> > > runs 40 in parallel)?
> > >
> > > In general our use of the runners seems a bit primitive, since the
> > > main use of parallelism is in the world builds.
> >
> > I'm honestly not sure. I think there's a few tweaks that we should do,
> > like putting the opensbi and coreboot files in to the Dockerfile logic
> > instead.  And maybe seeing if just like we can have a docker registry
> > cache, if we can setup local pypi cache too?  I'm not otherwise sure
> > what's taking 23 seconds or so of
> > https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the build
> > and run parts aren't much.
> >
> > My first big worry about running 2 or 3 qemu jobs at the same time on a
> > host is that any wins get from a shorter queue will be lost to buildman
> > doing "make -j$(nproc)" 2 or 3 times at once and so we build slower.
> 
> Yes, perhaps.
> 
> >
> > My second big worry is that getting the right tags on runners will be a
> > little tricky.
> 
> Yes, and error-prone. Also it makes it harder to deal with broken machines.
> 
> >
> > My third big worry (but this is something you can test easy enough at
> > least) is that running the big sandbox tests, 2 or 3 times at once on
> > the same host will get much slower. I think, but profiling would be
> > helpful, that those get slow due to I/O and not CPU.
> 
> I suspect it would be fast enough.
> 
> But actually the other problem is that I am not sure whether the jobs
> would have their own filesystem?

Yes, they should be properly sandboxed.  If you want to test some of
these ideas, I think the best path is to just un-register temproarily
(comment out the token in config.toml) some of your runners and then
register them with just the DM tree and experiment.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v8 4/9] sandbox: Build the mkeficapsule tool for the sandbox variants

[Simon Glass]

Hi Tom,

On Tue, 15 Aug 2023 at 08:46, Tom Rini  wrote:
>
> On Tue, Aug 15, 2023 at 08:44:18AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 13 Aug 2023 at 08:43, Tom Rini  wrote:
> > >
> > > On Sun, Aug 13, 2023 at 07:36:45AM -0600, Simon Glass wrote:
> [snip]
> > > > I see what you are saying, but from my side I am trying to enumerate
> > > > the boards, since generally I (like) build things without explicitly
> > > > specifying each board defconfig.
> > >
> > > Yes, but that's not possible in this case I think.  And I'm really just
> > > trying to figure out how we can make CI a little easier.  But maybe we
> > > can't / don't bother in this case and keep fixing up the sandbox
> > > defconfig files as needed.
> >
> > Maybe...it sounds like you are really just wanting a way for buildman
> > to manually build a single board with some config added, rather than
> > having it detect and build everything that is in-tree?
>
> What I'm trying to do really, is since you didn't seem to see the value
> in config fragments before, showcase how it would be beneficial to
> sandbox (and CI) if we used them there.

Yes, don't worry, I am past that stage and I see their value.

But I think for this to be more broadly useful we need a way to
enumerate the combinations permissible for a board and give them
names. Things like qconfig and buildman need to know what is going on
and cannot infer it from the filesystem...?

Regards,
Simon

Re: [PATCH v8 4/9] sandbox: Build the mkeficapsule tool for the sandbox variants

[Tom Rini]

On Tue, Aug 15, 2023 at 08:44:18AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Sun, 13 Aug 2023 at 08:43, Tom Rini  wrote:
> >
> > On Sun, Aug 13, 2023 at 07:36:45AM -0600, Simon Glass wrote:
[snip]
> > > I see what you are saying, but from my side I am trying to enumerate
> > > the boards, since generally I (like) build things without explicitly
> > > specifying each board defconfig.
> >
> > Yes, but that's not possible in this case I think.  And I'm really just
> > trying to figure out how we can make CI a little easier.  But maybe we
> > can't / don't bother in this case and keep fixing up the sandbox
> > defconfig files as needed.
> 
> Maybe...it sounds like you are really just wanting a way for buildman
> to manually build a single board with some config added, rather than
> having it detect and build everything that is in-tree?

What I'm trying to do really, is since you didn't seem to see the value
in config fragments before, showcase how it would be beneficial to
sandbox (and CI) if we used them there.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr

[Simon Glass]

Hi Devarsh,

On Tue, 15 Aug 2023 at 03:23, Devarsh Thakkar  wrote:
>
> Hi Simon, Tom,
>
> On 15/08/23 04:13, Simon Glass wrote:
> > Hi Devarsh, Nikhil, Tom,
> >
> > On Wed, 9 Aug 2023 at 09:29, Bin Meng  wrote:
> >>
> >> On Thu, Aug 3, 2023 at 7:03 PM Bin Meng  wrote:
> >>>
> >>> On Thu, Aug 3, 2023 at 6:37 PM Bin Meng  wrote:
> 
>  On Tue, Aug 1, 2023 at 12:00 AM Simon Glass  wrote:
> >
> > When the video framebuffer comes from the bloblist, we should not change
> > relocaddr to this address, since it interfers with the normal memory
> 
>  typo: interferes
> 
> > allocation.
> >
> > This fixes a boot loop in qemu-x86_64
> >
> > Signed-off-by: Simon Glass 
> > Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL 
> > to u-boot")
> > Suggested-by: Nikhil M Jain 
> > ---
> >
> > Changes in v3:
> > - Reword the Kconfig help as suggested
> >
> > Changes in v2:
> > - Add a Kconfig as the suggested conditional did not work
> >
> >   common/board_f.c  | 3 ++-
> >   drivers/video/Kconfig | 9 +
> >   2 files changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/common/board_f.c b/common/board_f.c
> > index 7d2c380e91e..5173d0a0c2d 100644
> > --- a/common/board_f.c
> > +++ b/common/board_f.c
> > @@ -419,7 +419,8 @@ static int reserve_video(void)
> >  if (!ho)
> >  return log_msg_ret("blf", -ENOENT);
> >  video_reserve_from_bloblist(ho);
> > -   gd->relocaddr = ho->fb;
> > +   if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
> > +   gd->relocaddr = ho->fb;
> >  } else if (CONFIG_IS_ENABLED(VIDEO)) {
> >  ulong addr;
> >  int ret;
> > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > index b41dc60cec5..f2e56204d52 100644
> > --- a/drivers/video/Kconfig
> > +++ b/drivers/video/Kconfig
> > @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
> >if this  option is enabled video driver will be removed at 
> > the end of
> >SPL stage, beforeloading the next stage.
> >
> > +config VIDEO_RESERVE_SPL
> > +   bool
> > +   help
> > + This adjusts reserve_video() to redirect memory reservation 
> > when it
> > + sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This 
> > avoids the
> > + memory used for framebuffer from being allocated by U-Boot 
> > proper,
> > + thus preventing any further memory reservations done by 
> > U-Boot proper
> > + from overwriting the framebuffer.
> > +
> >   if SPL_SPLASH_SCREEN
> >
> >   config SPL_SPLASH_SCREEN_ALIGN
> 
>  Reviewed-by: Bin Meng 
> >>>
> >>> applied to u-boot-x86, thanks!
> >>
> >> Dropped this one from the x86 queue per the discussion.
> >
> > I just wanted to come back to this discussion.
> >
> > Do we have an agreed way forward? Who is waiting for who?
> >
>
> I was waiting on feedback on
> https://lore.kernel.org/all/3b1e8005-f161-8058-13e7-3de2316aa...@ti.com/
> but per my opinion, I would prefer to go with "Approach 2" with a
> Kconfig as it looks simpler to me. It would look something like below :
>
> if (gd->relocaddr > (unsigned long)ho->fb) {
>   ulong fb_reloc_gap = gd->relocaddr - gd->ho->fb;
>
>   /* Relocate after framebuffer area if nearing too close to it */
>   if (fb_reloc_gap < CONFIG_BLOBLIST_FB_RELOC_MIN_GAP)
>  gd->relocaddr = ho->fb;
> }
>
> Regarding CONFIG_BLOBLIST_FB_RELOC_MIN_GAP
> -> This describes minimum gap to keep between framebuffer address and
> relocation address to avoid overlap when framebuffer address used by
> blob is below the current relocation address
>
> -> It would be selected as default when CONFIG_BLOBLIST is selected with
>   default value set to 100Mb
>
> -> SoC specific Vendors can override this in their defconfigs to a
> custom value if they feel 100Mb is not enough
>
> Also probably we can have some debug/error prints in the code to show
> overlap happened (or is going happen) so that users can fine tune this
> Kconfig if they got it wrong at first place.
>
> I can re-spin updated patch if we are aligned on this,
> Kindly let me know your opinion.

I'm just nervous about the whole idea, TBH. Perhaps I am missing some
documentation on how people are supposed to lay out memory in SPL and
U-Boot properr, but I'm not really aware of any guidance we give.

Perhaps we should say that the SPL frame buffer should be at the top
of memory, and U-Boot's reserve area should start below that?

Regards,
Simon

Re: [PATCH 1/1] doc: add partition API to HTML documentation

[Simon Glass]

Hi Heinrich,

On Tue, 15 Aug 2023 at 04:32, Heinrich Schuchardt
 wrote:
>
> * Convert comments in part.h to Sphinx style.
> * Create documentation page for the partition API.
> * Add the partition API page to the API index page.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  doc/api/index.rst |   1 +
>  doc/api/part.rst  |   6 ++
>  include/part.h| 210 --
>  3 files changed, 119 insertions(+), 98 deletions(-)
>  create mode 100644 doc/api/part.rst

Reviewed-by: Simon Glass 

Q below

>
> diff --git a/doc/api/index.rst b/doc/api/index.rst
> index a9338cfef9..3a80ae0635 100644
> --- a/doc/api/index.rst
> +++ b/doc/api/index.rst
> @@ -15,6 +15,7 @@ U-Boot API documentation
> lmb
> logging
> nvmem
> +   part
> pinctrl
> rng
> sandbox
> diff --git a/doc/api/part.rst b/doc/api/part.rst
> new file mode 100644
> index 00..d1df1d8494
> --- /dev/null
> +++ b/doc/api/part.rst
> @@ -0,0 +1,6 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Partition API
> +=
> +[..]

> +/**
> + * struct part_driver - partition driver
> + */
>  struct part_driver {
> +   /** @name:  partition name */
> const char *name;
> +   /** @part_type: (MBR) partition type */
> int part_type;
> -   const int max_entries;  /* maximum number of entries to search */
> -
> +   /** @max_entries:   maximum number of partition table entries */
> +   const int max_entries;
> /**
> -* get_info() - Get information about a partition
> +* @get_info:   Get information about a partition

Are we not allowed the () at end? I much prefer brackets as they show
it is a function.

>  *
> -* @dev_desc:   Block device descriptor
> -* @part:   Partition number (1 = first)
> -* @info:   Returns partition information
> +* @get_info.dev_desc:  Block device descriptor
> +* @get_info.part:  Partition number (1 = first)
> +* @get_info.info:  Returns partition information
>  */
> int (*get_info)(struct blk_desc *dev_desc, int part,
> struct disk_partition *info);
[..]

Regards,
Simon

Re: [PATCH 1/3] fdt: common API to populate kaslr seed

[Simon Glass]

Hi Sean,

On Mon, 14 Aug 2023 at 13:12, Sean Edmond
 wrote:
>
>
> On 2023-08-12 6:09 a.m., Simon Glass wrote:
> > Hi Sean,
> >
> > On Fri, 11 Aug 2023 at 11:14, Sean Edmond 
> > wrote:
> >>
> >> On 2023-08-09 6:49 p.m., Simon Glass wrote:
> >>> Hi Sean,
> >>>
> >>> On Wed, 9 Aug 2023 at 16:35, Sean Edmond 
> > wrote:
>  On 2023-08-08 7:03 p.m., Simon Glass wrote:
> > Hi,
> >
> > On Fri, 4 Aug 2023 at 17:34,  wrote:
> >> From: Dhananjay Phadke 
> >>
> >> fdt_fixup_kaslr_seed() will update given FDT with random seed value.
> >> Source for random seed can be TPM or RNG driver in u-boot or sec
> >> firmware (ARM).
> >>
> >> Signed-off-by: Dhananjay Phadke 
> >> ---
> >> arch/arm/cpu/armv8/sec_firmware.c | 32
> > +++
> >> common/fdt_support.c  | 31
> > ++
> >> include/fdt_support.h |  3 +++
> >> 3 files changed, 41 insertions(+), 25 deletions(-)
> > We need to find a way to use the ofnode API here.
> >
> >> diff --git a/arch/arm/cpu/armv8/sec_firmware.c
> > b/arch/arm/cpu/armv8/sec_firmware.c
> >> index c0e8726346..84ba49924e 100644
> >> --- a/arch/arm/cpu/armv8/sec_firmware.c
> >> +++ b/arch/arm/cpu/armv8/sec_firmware.c
> >> @@ -411,46 +411,28 @@ int sec_firmware_init(const void
> > *sec_firmware_img,
> >> /*
> >>  * fdt_fix_kaslr - Add kalsr-seed node in Device tree
> >>  * @fdt:   Device tree
> >> - * @eret:  0 in case of error, 1 for success
> >> + * @eret:  0 for success
> >>  */
> >> int fdt_fixup_kaslr(void *fdt)
> > You could pass an oftree to this function, e.g. obtained with:
> >
> > oftree_from_fdt(fdt)
>  The common API I added is fdt_fixup_kaslr_seed(), which was added to
>  "common/fdt_support.c".
> 
>  There are 3 callers:
>  sec_firmware_init()->fdt_fixup_kaslr_seed()
>  do_kaslr_seed()->fdt_fixup_kaslr_seed()
>  image_setup_libfdt()->fdt_tpm_kaslr_seed->fdt_fixup_kaslr_seed()
> 
>  I think the ask is to create a common API that uses the ofnode API.
> > So,
>  instead of fdt_fixup_kaslr_seed() I can create
>  ofnode_fixup_kaslr_seed()?  Where should it live?
> >>> If you like you could add common/ofnode_support.c ?
> >>>
> >>> But it is OK to have it in the same file, I think.
> >>>
>  Are you also wanting
>  the callers (eg. fdt_tpm_kaslr_seed, fdt_fixup_kaslr) to take oftree as
>  input too?
> >>> So far as you can go, yes. Also you may want to pass an ofnode (the
> >>> root node) so that things can deal with adding their stuff to any
> >>> node.
> >>>
> >>> Regards,
> >>> Simon
> >>
> >> I re-worked the API to use the ofnode API and tested it on our board.  I
> >> was required to explicitly enable CONFIG_OFNODE_MULTI_TREE in order for
> >> it to work.
> >>
> >> I have concerns this will create a breaking change for users of the
> >> kaslr fdt touch up.  In our case, if CONFIG_OFNODE_MULTI_TREE isn't set,
> >> the control FDT gets touched up, not the kernel FDT as required.
> >> Everything runs to completion, but "/proc/device-tree/chosen/kaslr-seed"
> >> isn't present after boot.
> >>
> >> Am I missing something?  Perhaps there's a way to modify the default
> >> value for CONFIG_OFNODE_MULTI_TREE to ensure this works out-of-the-box?
> >>
> > Yes, perhaps we should enable this when fixups are used? Is there a way to
> > tell?
> I don't think there's a way to tell unfortunately.  Fixups are always
> called if OF_LIBFDT is enabled, and if an FDT is found during bootm.
>
> I'm having trouble understanding the intention of the current default
> for OFNODE_MULTI_TREE:
>  default y if EVENT && !DM_DEV_READ_INLINE && !DM_INLINE_OFNODE
> Could we simplify to this?
>  default y if !OF_LIVE

I don't think it will build if inlining is used, but I can't remember...

The EVENT thing is because there is an of-fixup event, which was the
original thing using ofnode fixups.

I wonder what sort of size increment this will create with !OF_LlIVE ?

> >
> > Also, we should make it return an error when attempting to use a tree
> > without that option enabled. I would expect oftree_ensure() to provide that?
> I'll add a check.

OK thanks.

Regards,
Simon

Re: Strange gitlab idea

[Simon Glass]

Hi Tom,

On Sun, 13 Aug 2023 at 09:52, Tom Rini  wrote:
>
> On Sat, Aug 12, 2023 at 09:14:45PM -0600, Simon Glass wrote:
>
> > Hi Tom,
> >
> > I notice that the runners are not utilised much by the QEMU jobs,
> > since we only run one at a time.
> >
> > I wonder if we could improve this, perhaps by using a different tag
> > for the QEMU ones and then having a machine that only runs those (and
> > runs 40 in parallel)?
> >
> > In general our use of the runners seems a bit primitive, since the
> > main use of parallelism is in the world builds.
>
> I'm honestly not sure. I think there's a few tweaks that we should do,
> like putting the opensbi and coreboot files in to the Dockerfile logic
> instead.  And maybe seeing if just like we can have a docker registry
> cache, if we can setup local pypi cache too?  I'm not otherwise sure
> what's taking 23 seconds or so of
> https://source.denx.de/u-boot/u-boot/-/jobs/673565#L34 since the build
> and run parts aren't much.
>
> My first big worry about running 2 or 3 qemu jobs at the same time on a
> host is that any wins get from a shorter queue will be lost to buildman
> doing "make -j$(nproc)" 2 or 3 times at once and so we build slower.

Yes, perhaps.

>
> My second big worry is that getting the right tags on runners will be a
> little tricky.

Yes, and error-prone. Also it makes it harder to deal with broken machines.

>
> My third big worry (but this is something you can test easy enough at
> least) is that running the big sandbox tests, 2 or 3 times at once on
> the same host will get much slower. I think, but profiling would be
> helpful, that those get slow due to I/O and not CPU.

I suspect it would be fast enough.

But actually the other problem is that I am not sure whether the jobs
would have their own filesystem?

Regards,
Simon

Re: [PATCH v8 4/9] sandbox: Build the mkeficapsule tool for the sandbox variants

[Simon Glass]

Hi Tom,

On Sun, 13 Aug 2023 at 08:43, Tom Rini  wrote:
>
> On Sun, Aug 13, 2023 at 07:36:45AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 13 Aug 2023 at 06:40, Tom Rini  wrote:
> > >
> > > On Sat, Aug 12, 2023 at 06:14:45PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Sat, 12 Aug 2023 at 16:38, Tom Rini  wrote:
> > > > >
> > > > > On Sat, Aug 12, 2023 at 11:03:36AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Sat, 12 Aug 2023 at 08:28, Tom Rini  wrote:
> > > > > > >
> > > > > > > On Sat, Aug 12, 2023 at 08:24:59AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Sat, 12 Aug 2023 at 08:22, Tom Rini  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Sat, Aug 12, 2023 at 07:08:44AM -0600, Simon Glass wrote:
> > > > > > > > > > Hi Tom,
> > > > > > > > > >
> > > > > > > > > > On Fri, 11 Aug 2023 at 09:56, Tom Rini  
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Aug 11, 2023 at 08:26:36AM -0600, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Hi Sughosh,
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 11 Aug 2023 at 08:23, Sughosh Ganu 
> > > > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 11 Aug 2023 at 19:28, Tom Rini 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Aug 11, 2023 at 04:29:37PM +0530, Sughosh 
> > > > > > > > > > > > > > Ganu wrote:
> > > > > > > > > > > > > > > On Thu, 10 Aug 2023 at 22:47, Tom Rini 
> > > > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Aug 10, 2023 at 10:39:06PM +0530, 
> > > > > > > > > > > > > > > > Sughosh Ganu wrote:
> > > > > > > > > > > > > > > > > On Thu, 10 Aug 2023 at 21:22, Tom Rini 
> > > > > > > > > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, Aug 10, 2023 at 07:53:33PM +0530, 
> > > > > > > > > > > > > > > > > > Sughosh Ganu
> > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Build the mkeficapsule tool for all the 
> > > > > > > > > > > > > > > > > > > sandbox variants.
> > > > > > > > > > This tool
> > > > > > > > > > > > > > > > > > > will be used subsequently for testing 
> > > > > > > > > > > > > > > > > > > capsule generation
> > > > > > > > > > in binman.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > > > > > ---
> > > > > > > > > > > > > > > > > > > Changes since V7: None
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >  tools/Kconfig | 6 +++---
> > > > > > > > > > > > > > > > > > >  1 file changed, 3 insertions(+), 3 
> > > > > > > > > > > > > > > > > > > deletions(-)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > > > > > > > > > > > > > > > > > index 6e23f44d55..353a855243 100644
> > > > > > > > > > > > > > > > > > > --- a/tools/Kconfig
> > > > > > > > > > > > > > > > > > > +++ b/tools/Kconfig
> > > > > > > > > > > > > > > > > > > @@ -91,10 +91,10 @@ config TOOLS_SHA512
> > > > > > > > > > > > > > > > > > > Enable SHA512 support in the 
> > > > > > > > > > > > > > > > > > > tools builds
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >  config TOOLS_MKEFICAPSULE
> > > > > > > > > > > > > > > > > > > - bool "Build efimkcapsule command"
> > > > > > > > > > > > > > > > > > > - default y if EFI_CAPSULE_ON_DISK
> > > > > > > > > > > > > > > > > > > + bool "Build mkeficapsule tool"
> > > > > > > > > > > > > > > > > > > + default y if EFI_CAPSULE_ON_DISK || 
> > > > > > > > > > > > > > > > > > > SANDBOX
> > > > > > > > > > > > > > > > > > >   help
> > > > > > > > > > > > > > > > > > > -   This command allows users to 
> > > > > > > > > > > > > > > > > > > create a UEFI
> > > > > > > > > > capsule file and,
> > > > > > > > > > > > > > > > > > > +   This tool allows users to create 
> > > > > > > > > > > > > > > > > > > a UEFI capsule
> > > > > > > > > > file and,
> > > > > > > > > > > > > > > > > > > optionally sign that file. If you 
> > > > > > > > > > > > > > > > > > > want to enable
> > > > > > > > > > UEFI capsule
> > > > > > > > > > > > > > > > > > > update feature on your target, 
> > > > > > > > > > > > > > > > > > > you certainly need
> > > > > > > > > > this.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Sorry, what is this fixing exactly?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The tool is required to be supported on the 
> > > > > > > > > > > > > > > > > sandbox_spl
> > > > > > > > > > variant, since
> > > > > > > > > > > > > > > > > that is used 

Re: [PATCH v3] gpio: Use separate bitfield array to indicate GPIO is claimed

[Tom Rini]

On Wed, Aug 02, 2023 at 01:26:02AM +0200, Marek Vasut wrote:

> The current gpio-uclass design uses name field in struct gpio_dev_priv as
> an indicator that GPIO is claimed by consumer. This overloads the function
> of name field and does not work well for named pins not configured as GPIO
> pins.
> 
> Introduce separate bitfield array as the claim indicator.
> 
> This unbreaks dual-purpose AF and GPIO operation on STM32MP since commit
> 2c38f7c31806 ("pinctrl: pinctrl_stm32: Populate uc_priv->name[] with pinmux 
> node's name")
> where any pin which has already been configured as AF could no longer be
> claimed as dual-purpose GPIO. This is important for pins like STM32 MMCI
> st,cmd-gpios .
> 
> Signed-off-by: Marek Vasut 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] cmd: pxe: Update the command help

[Tom Rini]

On Mon, Jul 31, 2023 at 04:33:23PM +0800, Bin Meng wrote:

> Currently the "help" displays pxe command help text like this:
> 
>   => help
>   ...
>   printenv  - print environment variables
>   pxe   - commands to get and boot from pxe files
>   To use IPv6 add -ipv6 parameter
>   qfw   - QEMU firmware interface
>   ...
> 
> This does not read clearly. Remove the IPv6 stuff as it is in
> the detailed help text so that it fits just a single line.
> 
> Signed-off-by: Bin Meng 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] fs: fat: avoid multiplication overflow

[Tom Rini]

On Sun, Jul 30, 2023 at 04:44:04PM +0200, Heinrich Schuchardt wrote:

> The product of two 32 bit integers is a 32 bit integer. Hence
> clustcount * bytesperclust may overflow on > 4 GiB devices.
> 
> Change the type of clustcount.
> 
> Fixes: cb8af8af5ba0 ("fs: fat: support write with non-zero offset")
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] test: unit test for semihosting

[Tom Rini]

On Mon, Jul 31, 2023 at 10:01:21PM +0200, Heinrich Schuchardt wrote:

> Provide a unit test for semihosting testing reading and writing a file.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Sean Anderson 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] configs: enable SEMIHOSTING on qemu_arm64_defconfig

[Tom Rini]

On Mon, Jul 31, 2023 at 10:01:20PM +0200, Heinrich Schuchardt wrote:

> We need a platform on which we can test our semihosting code.
> 
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: Sean Anderson 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] spl: add FIT support to semihosting boot method

[Tom Rini]

On Sat, Jul 22, 2023 at 09:27:48PM +0200, Heinrich Schuchardt wrote:

> Allow loading a FIT image via semihosting in SPL.
> 
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] phy: Add support for the Apple Type-C PHY

[Tom Rini]

On Fri, Jul 14, 2023 at 10:21:42PM +0200, Mark Kettenis wrote:

> This is merely a dummy driver that makes sure the DWC3 XHCI driver
> finds its reset and PHY controllers.  We rely on iBoot to set up
> the PHY for us.
> 
> Signed-off-by: Mark Kettenis 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] pci: ftpci100: add new driver implementation

[Tom Rini]

On Sun, Jul 30, 2023 at 09:17:09PM +0300, Sergei Antonov wrote:

> Add a new DM driver supporting FTPCI100 IP used in SoC designs.
> This implementation is not based on the old non-DM ftpci100 code
> dropped from U-Boot.
> 
> Enable the driver in sandbox_defconfig to test compilability.
> 
> Signed-off-by: Sergei Antonov 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] pci: Fix device_find_first_child() return value handling

[Tom Rini]

On Sun, Jul 16, 2023 at 05:53:24PM +0200, Marek Vasut wrote:

> This function only ever returns 0, but may not assign the second
> parameter. Same thing for device_find_next_child(). Do not assign
> ret to stop proliferation of this misuse.
> 
> Reported-by: Jonas Karlman 
> Signed-off-by: Marek Vasut 
> Reviewed-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] pci: apple: Enable CONFIG_SYS_PCI_64BIT

[Tom Rini]

On Fri, Jul 14, 2023 at 09:15:16PM +0200, Mark Kettenis wrote:

> The Apple hardware supports 64-bit prefetchable memory windows so
> enable CONFIG_SYS_PCI_64BIT. This fixes BAR assignments for the
> Broadcom Ethernet controller used in some of the desktop machines.
> 
> Signed-off-by: Mark Kettenis 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCHv6 03/14] net/lwip: implement dns cmd

[Tom Rini]

On Tue, Aug 15, 2023 at 06:42:14PM +0600, Maxim Uvarov wrote:
> On Mon, 14 Aug 2023 at 20:19, Ilias Apalodimas 
> wrote:
> 
> [...]
> 
> 
> > > +/*
> > > +* This function creates the DNS request to resolve a domain host name.
> > Function
> >
> > You need the name of the function as well.  Please have a look at how the
> > rest of the code is documented.
> >
> > > +* can return immediately if previous request was cached or it might
> > require
> > > +* entering the polling loop for a request to a remote server.
> > > +*
> > > +* @name  dns name to resolve
> >
> > @name: etc
> >
> > > +* @varname (optional) U-Boot variable name to store the result
> > > +* Return: ERR_OK(0) for fetching entry from the cache
> > > +* ERR_INPROGRESS(-5) success, can go to the polling loop
> > > +* Other value < 0, if error
> > > +*/
> > >
> >
> 
> Is there any command to check all the files for the comments style?

I suspect if you included them in docs, htmldocs/etc would note
problems, Heinrich?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v9 08/10] sandbox: capsule: Generate capsule related files through binman

[Tom Rini]

On Mon, Aug 14, 2023 at 04:51:13PM -0600, Simon Glass wrote:
> Hi Sughosh,
> 
> On Mon, 14 Aug 2023 at 02:17, Sughosh Ganu  wrote:
> >
> > hi Simon,
> >
> > On Sat, 12 Aug 2023 at 22:33, Simon Glass  wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Sat, 12 Aug 2023 at 09:40, Sughosh Ganu  
> > > wrote:
> > > >
> > > > hi Simon,
> > > >
> > > > On Sat, 12 Aug 2023 at 19:55, Simon Glass  wrote:
> > > > >
> > > > > On Fri, 11 Aug 2023 at 23:58, Sughosh Ganu  
> > > > > wrote:
> > > > > >
> > > > > > The EFI capsule files can now be generated as part of u-boot
> > > > > > build through binman. Add capsule entry nodes for the sandbox
> > > > > > architecture for generating the capsules. These capsules are then 
> > > > > > used
> > > > > > for testing the EFI capsule update functionality on the sandbox
> > > > > > platforms.
> > > > > >
> > > > > > Remove the corresponding logic in the test setup which was used for
> > > > > > generation of these capsule which is now superfluous.
> > > > > >
> > > > > > Signed-off-by: Sughosh Ganu 
> > > > > > ---
> > > > > > Changes since V8:
> > > > > > * Build the capsules for all sandbox variants.
> > > > > > * Remove the type property by renaming the capsule nodes as
> > > > > >   'efi-capsule'.
> > > > > >
> > > > > >  arch/sandbox/dts/sandbox.dts  |   2 +
> > > > > >  arch/sandbox/dts/sandbox_capsule.dtsi | 315 
> > > > > > ++
> > > > > >  arch/sandbox/dts/test.dts |   2 +
> > > > > >  include/sandbox_efi_capsule.h |  21 ++
> > > > > >  test/py/tests/test_efi_capsule/conftest.py| 155 +
> > > > > >  .../tests/test_efi_capsule/uboot_bin_env.its  |  36 --
> > > > > >  6 files changed, 356 insertions(+), 175 deletions(-)
> > > > > >  create mode 100644 arch/sandbox/dts/sandbox_capsule.dtsi
> > > > > >  create mode 100644 include/sandbox_efi_capsule.h
> > > > > >  delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> > > > >
> > > > > Reviewed-by: Simon Glass 
> > > > >
> > > > > One way to reduce the files is to put all the capsules in the same
> > > > > binman image. You could have 'size = <0x1000>' so they are all the
> > > > > same size.
> > > > >
> > > > > Then your test could check each one by iterating through the (single) 
> > > > > file.
> > > >
> > > > This won't work, as the UEFI specification defines a particular format
> > > > of the capsule file. For multiple capsules, the individual capsule
> > > > files need to be present under the /EFI/UpdateCapsule/ directory on
> > > > the EFI System Partition. The spec does define a format in which a
> > > > single capsule file can have multiple payloads(input binaries). This
> > > > is planned to be supported once support has been added for generating
> > > > capsules through the config file.
> > >
> > > We continue to have challenges getting confused between testing and real 
> > > world.
> > >
> > > For testing, we can do all sorts of things to make things simpler. We
> > > don't even need an EFI partition, etc. We can have a test which checks
> > > that U-Boot can decode an update and apply it, The current tests rely
> > > far too much on an end-to-end, black-box approach, as I might have
> > > mentioned.
> >
> > Okay, but I am stating the constraints on using a single combined file
> > based on the way the tests work today. So if we were to generate a
> > single file consisting of all the individual capsule files, that would
> > break the tests. That was my point.
> 
> Sure...my point is that the tests could use a bit of rework to make
> them easier and faster to run.

We also need to test them how they're functionally used. At some level
I'd be "fine" if we had "test individual parts of the framework" tests
in sandbox and "test as they're used" tests in QEMU.

-- 
Tom


signature.asc
Description: PGP signature

Re: Please pull u-boot-dm/next

[Tom Rini]

On Mon, Aug 14, 2023 at 04:48:28PM -0600, Simon Glass wrote:

> Hi Tom,
> 
> This is for the -next branch
> 
> 
> The following changes since commit 321d7b4d875a77552a969dd6ea5bbed2644fcb0c:
> 
>   Merge branch '2023-08-09-misc-cleanups' into next (2023-08-09 13:15:51 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-next-14aug23
> 
> for you to fetch changes up to daffb0be2c839f3abe431cd68c772fae0e7e49ca:
> 
>   bootstd: cros: Add ARM support (2023-08-11 07:33:40 -0600)
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] buildman: Allow more results while building

[Tom Rini]

On Thu, Aug 03, 2023 at 12:59:55PM -0600, Simon Glass wrote:

> The -v option enables display of build results while building, instead of
> needing to do a separate summary step later (or in another terminal). But
> this resets the build results after each commit, so that all errors are
> reported fresh, without trying to diff them against previous errors
> already shown.
> 
> Drop this reset, as an experiment, so see if this is useful.
> 
> Signed-off-by: Simon Glass 
> ---
> 
>  tools/buildman/builder.py | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
> index ecbd368c47a..5ee2b5959b2 100644
> --- a/tools/buildman/builder.py
> +++ b/tools/buildman/builder.py
> @@ -536,7 +536,6 @@ class Builder:
>  if self._verbose:
>  terminal.print_clear()
>  boards_selected = {target : result.brd}
> -self.reset_result_summary(boards_selected)
>  self.produce_result_summary(result.commit_upto, self.commits,
>boards_selected)
>  else:

Nope, this doesn't change any of the output I see in how I usually do my
world builds.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] lib/vsprintf.c: fix integer overflow in vsprintf

[Tom Rini]

On Thu, Mar 09, 2023 at 10:12:21AM +0800, Ying-Chun Liu (PaulLiu) wrote:

> From: Tom Cherry 
> 
> vsnprintf_internal() adds 'size' to 'buf' and vsprintf() sets 'size'
> to 'INT_MAX' which can overflow.  This causes sprintf() to fail when
> initializing the environment on 8GB.
> 
> Instead of using 'INT_MAX', we use SIZE_MAX - buf, which is the
> largest possible string that could fit without overflowing 'size'.
> 
> Signed-off-by: Tom Cherry 
> [ Paul: pick from the Android tree. Rebase to the upstream ]
> Signed-off-by: Ying-Chun Liu (PaulLiu) 
> Cc: Tom Rini 
> Link: 
> https://android.googlesource.com/platform/external/u-boot/+/43aae5d4415e0f9d744fb798acd52429d09957ce

So, this link here leads back to
https://issuetracker.google.com/issues/200479053 which isn't public.

Rasmus followed up and asked pointed questions, that weren't followed up
on.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] doc: csf_examples: csf.sh: Remove unneeded export ATF_LOAD_ADDR line

[Fabio Estevam]

From: Fabio Estevam 

Originally, exporting the ATF_LOAD_ADDR was required, but since binman has
been used to generate the flash.bin, it is no longer needed to do
such manual export.

The ATF address is now passed via binman.

Remove the unneeded export ATF_LOAD_ADDR line.

Signed-off-by: Fabio Estevam 
---
 doc/imx/habv4/csf_examples/mx8m/csf.sh | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/imx/habv4/csf_examples/mx8m/csf.sh 
b/doc/imx/habv4/csf_examples/mx8m/csf.sh
index d87015f6c4e2..65c143073cbe 100644
--- a/doc/imx/habv4/csf_examples/mx8m/csf.sh
+++ b/doc/imx/habv4/csf_examples/mx8m/csf.sh
@@ -11,7 +11,6 @@
 
 # 1) Build U-Boot (e.g. for i.MX8MM)
 #
-# export ATF_LOAD_ADDR=0x92
 # cp -Lv /path/to/arm-trusted-firmware/build/imx8mm/release/bl31.bin .
 # cp -Lv /path/to/firmware-imx-8.14/firmware/ddr/synopsys/ddr3* .
 # make -j imx8mm_board_defconfig
-- 
2.34.1

Re: [PATCH 4/7] net: dwc_eth_qos: Add glue driver for GMAC on Rockchip RK3568

[David Wu]

Hi Jonas,

Thank you for your help.

在 2023/8/7 08:08, Jonas Karlman 写道:

Add a new glue driver for Rockchip SoCs, i.e RK3568, with a GMAC based
on Synopsys DWC Ethernet QoS IP.

rk_gmac_ops was ported from linux commit:
3bb3d6b1c195 ("net: stmmac: Add RK3566/RK3568 SoC support")

Signed-off-by: Jonas Karlman 
---
Cc: David Wu 
Cc: Ezequiel Garcia 
---
  drivers/net/Kconfig|   8 +
  drivers/net/Makefile   |   1 +
  drivers/net/dwc_eth_qos.c  |   8 +-
  drivers/net/dwc_eth_qos.h  |   2 +
  drivers/net/dwc_eth_qos_rockchip.c | 348 +
  5 files changed, 365 insertions(+), 2 deletions(-)
  create mode 100644 drivers/net/dwc_eth_qos_rockchip.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0ed39a61e4de..29304fd77759 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -225,6 +225,14 @@ config DWC_ETH_QOS_IMX
  The Synopsys Designware Ethernet QOS IP block with the specific
  configuration used in IMX soc.
  
+config DWC_ETH_QOS_ROCKCHIP

+   bool "Synopsys DWC Ethernet QOS device support for Rockchip SoCs"
+   depends on DWC_ETH_QOS
+   select DM_ETH_PHY
+   help
+ The Synopsys Designware Ethernet QOS IP block with specific
+ configuration used in Rockchip SoCs.
+
  config DWC_ETH_QOS_STM32
bool "Synopsys DWC Ethernet QOS device support for STM32"
depends on DWC_ETH_QOS
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d4af253b6f28..1d444f5b4a69 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_DRIVER_DM9000) += dm9000x.o
  obj-$(CONFIG_DSA_SANDBOX) += dsa_sandbox.o
  obj-$(CONFIG_DWC_ETH_QOS) += dwc_eth_qos.o
  obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
+obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
  obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
  obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
  obj-$(CONFIG_E1000) += e1000.o
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 24fb3fac1f12..9fb98a2c3c74 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1707,7 +1707,12 @@ static const struct udevice_id eqos_ids[] = {
.data = (ulong)_imx_config
},
  #endif
-
+#if IS_ENABLED(CONFIG_DWC_ETH_QOS_ROCKCHIP)
+   {
+   .compatible = "rockchip,rk3568-gmac",
+   .data = (ulong)_rockchip_config
+   },
+#endif


If this compatible could move to dwc_eth_qos_rockchip.c, it is better,
we have other SoCs  that also use this driver in the feature,  and it 
must increase

this array all the time for new SoCs later, it will be better only change
dwc_eth_qos_rockchip.c, we don't need to change the current file.


  #if IS_ENABLED(CONFIG_DWC_ETH_QOS_QCOM)
{
.compatible = "qcom,qcs404-ethqos",
@@ -1720,7 +1725,6 @@ static const struct udevice_id eqos_ids[] = {
.data = (ulong)_jh7110_config
},
  #endif
-
{ }
  };
  
diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h

index 06a082da72ef..e3222e1e17e5 100644
--- a/drivers/net/dwc_eth_qos.h
+++ b/drivers/net/dwc_eth_qos.h
@@ -82,6 +82,7 @@ struct eqos_mac_regs {
  #define EQOS_MAC_MDIO_ADDRESS_PA_SHIFT21
  #define EQOS_MAC_MDIO_ADDRESS_RDA_SHIFT   16
  #define EQOS_MAC_MDIO_ADDRESS_CR_SHIFT8
+#define EQOS_MAC_MDIO_ADDRESS_CR_100_150   1
  #define EQOS_MAC_MDIO_ADDRESS_CR_20_352
  #define EQOS_MAC_MDIO_ADDRESS_CR_250_300  5
  #define EQOS_MAC_MDIO_ADDRESS_SKAPBIT(4)
@@ -287,5 +288,6 @@ void eqos_flush_buffer_generic(void *buf, size_t size);
  int eqos_null_ops(struct udevice *dev);
  
  extern struct eqos_config eqos_imx_config;

+extern struct eqos_config eqos_rockchip_config;
  extern struct eqos_config eqos_qcom_config;
  extern struct eqos_config eqos_jh7110_config;
diff --git a/drivers/net/dwc_eth_qos_rockchip.c 
b/drivers/net/dwc_eth_qos_rockchip.c
new file mode 100644
index ..c8abe351fc3e
--- /dev/null
+++ b/drivers/net/dwc_eth_qos_rockchip.c
@@ -0,0 +1,348 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dwc_eth_qos.h"
+
+struct rk_gmac_ops {
+   const char *compatible;
+   int (*set_to_rgmii)(struct udevice *dev,
+   int tx_delay, int rx_delay);
+   int (*set_to_rmii)(struct udevice *dev);
+   int (*set_gmac_speed)(struct udevice *dev);
+   u32 regs[3];
+};
+
+struct rockchip_platform_data {
+   struct reset_ctl_bulk resets;
+   const struct rk_gmac_ops *ops;
+   int id;
+   struct regmap *grf;
+};
+
+#define HIWORD_UPDATE(val, mask, shift) \
+   ((val) << (shift) | (mask) << ((shift) + 16))
+
+#define 

Re: [PATCHv6 03/14] net/lwip: implement dns cmd

[Maxim Uvarov]

On Mon, 14 Aug 2023 at 20:19, Ilias Apalodimas 
wrote:

[...]


> > +/*
> > +* This function creates the DNS request to resolve a domain host name.
> Function
>
> You need the name of the function as well.  Please have a look at how the
> rest of the code is documented.
>
> > +* can return immediately if previous request was cached or it might
> require
> > +* entering the polling loop for a request to a remote server.
> > +*
> > +* @name  dns name to resolve
>
> @name: etc
>
> > +* @varname (optional) U-Boot variable name to store the result
> > +* Return: ERR_OK(0) for fetching entry from the cache
> > +* ERR_INPROGRESS(-5) success, can go to the polling loop
> > +* Other value < 0, if error
> > +*/
> >
>

Is there any command to check all the files for the comments style?

[...]

Please pull u-boot-ubi

[Heiko Schocher]

Hello Tom,

please pull from u-boot-ubi.git master

The following changes since commit 832148f675e427060be074c276956962fa9b5cb6:

  Merge tag 'u-boot-rockchip-20230814' of 
https://source.denx.de/u-boot/custodians/u-boot-rockchip
(2023-08-14 09:11:09 -0400)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-ubi.git 
tags/ubi-updates-for-v2023.10-rc3

for you to fetch changes up to 34031e9cce91de323ed711d7e8614c0d12fada1c:

  cmd: ubi: Fix 'ubi list' command arguments parsing (2023-08-15 07:32:13 +0200)


ubi changes for v2023.10-rc3

Fix:
- Fix 'ubi list' command arguments parsing
  from Dmitry


Dmitry Dunaev (1):
  cmd: ubi: Fix 'ubi list' command arguments parsing

 cmd/ubi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Azure build is fine:

https://dev.azure.com/hs0298/hs/_build/results?buildId=108=results

Thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: [PATCH] cmd: ubi: Fix 'ubi list' command arguments parsing

[Heiko Schocher]

Hello Dmitry,

On 12.07.23 14:58, Dmitry Dunaev wrote:
> This fixes allowed argc variable value for arguments parsing
> 
> Fixes: 6de1daf64b1 ("cmd: ubi: Add 'ubi list' command")
> Signed-off-by: Dmitry Dunaev 
> ---
>  cmd/ubi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-ubi master

thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,  Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

Re: Problem upon startup with halted USB device on RaspberryPi 4

[Massimo Pegorer]

Il giorno lun 14 ago 2023 alle ore 11:11 Harry Waschkeit <
harry.waschk...@conplement.de> ha scritto:

> Am 13.08.23 um 19:37 schrieb Michal Suchánek:
> > Hello,
>
> Hi again,
>
> thanks for your answers!
>
> > On Sat, Aug 12, 2023 at 08:31:56PM +0200, Massimo Pegorer wrote:
> >> Hi Harry,
> >>
> >> Il giorno lun 7 ago 2023 alle ore 11:02 Harry Waschkeit <
> >> harry.waschk...@conplement.de> ha scritto:
> >>
> >>> Hi,
> >>>
> >>> I have a RaspberryPi 4 where on one USB port a Sierra Wireless LTE
> >>> module (EM7455) is attached via an PCIe-to-USB adapter.
> >>> The boot image I use gets built by Yocto with the help of poky
> >>> (kirkstone) and meta-raspberry (beside a few other layers) which
> >>> incorporates U-Boot 22.01.
> >>>
> >>> When I apply power to the board it will come up until scanning USB
> >>> devices (for potential boot devices), but then throw a BUG end reset
> the
> >>> board.
> >>
> >>
> >> Do you need USB boot devices? If not, I would build U-Boot without USB
> >> support.
>
> Yeah, I am aware of that possibility, thanks for your hint anyway, but ...
>
> >
> > That would be great workaround, However, enabling a device should not
> > break the board. If that's the case the driver is clearly broken.
>

Of course, mine is just a workaround, nothing more. To make hardware combo
working, and just for specific use case (if I properly understood). Not for
typical
usage of rPi. About the driver: can be broken, or the root cause can be the
PCIe-to-USB bridge misbehaving, or both.

> Also rPi typically uses USB keyboard for boot-time input which makes the
> > workaround not so great.


For U-Boot booting phase, or later on for Linux or other OS boot phase? I do
not know too much about this specific board.


> ... but as Michal pointed out, the rpi - at least rpi 400 - should be
> considered to regularly use USB devices for normal operation, so
> completely disabling USB is not really an option here.
>

Disabling USB support in U-Boot (via defconfig) would not affect Linux (or
other OS) USB functions in any way, if this is what you are concerning about
with "completely disabling USB".

My USB knowledge is too little to point the finger on the problem but my
> guess still is that U-Boot is only using a part of Linux's USB driver
> for bringing up devices, thereby omitting some of the error handling
> which would be done in the Linux kernel in some (maybe concurrent) way.
>

I suggest to address this email also directly to maintainers:

./scripts/get_maintainer.pl drivers/usb/host/xhci-ring.c
Bin Meng  (maintainer:USB xHCI)
Marek Vasut  (maintainer:USB)
u-boot@lists.denx.de (open list)

Regards,
Massimo

And given the bunch of boot messages "WARN halted endpoint." with the
> patch I mentioned, chances are that the patch is either not the right
> one or at least incomplete.
> But the general approach to ignore halted endpoints appears completely
> reasonable to me when it avoids a hanging of boot looping system.
> I cannot tell whether there should instead be some cleverer treatment to
> get such a device running ("Reset Endpoint" from what I read), though.
>
> Regards,
> Harry
>
> > Thanks
> >
> > Michal
> >
> >>
> >> Massimo
> >>
> >>> This continues as long as the modem is unplugged.
> >>> The exact error message is:
> >>>
> >>> scanning bus xhci_pci for devices... WARN halted endpoint, queuing URB
> >>> anyway.
> >>> Unexpected XHCI event TRB, skipping... (3af519b0 0004 1300
> >>> 02008401)
> >>> BUG at drivers/usb/host/xhci-ring.c:503/abort_td()!
> >>> BUG!
> >>> resetting ...
> >>>
> >>> Some internet research brought up a patch (1) for
> >>> drivers/usb/host/xhci-ring.c where halted devices simply get ignored
> >>> during enumeration:
> >>>
> >>> diff --git a/drivers/usb/host/xhci-ring.c
> b/drivers/usb/host/xhci-ring.c
> >>> index acf437104a..6d995f446e 100644
> >>> --- a/drivers/usb/host/xhci-ring.c
> >>> +++ b/drivers/usb/host/xhci-ring.c
> >>> @@ -227,7 +227,8 @@ static int prepare_ring(struct xhci_ctrl *ctrl,
> >>> struct xhci_ring *ep_ring,
> >>> puts("WARN waiting for error on ep to be cleared\n");
> >>> return -EINVAL;
> >>> case EP_STATE_HALTED:
> >>> - puts("WARN halted endpoint, queueing URB anyway.\n");
> >>> + puts("WARN halted endpoint.\n");
> >>> + return -EPIPE;
> >>> case EP_STATE_STOPPED:
> >>> case EP_STATE_RUNNING:
> >>> debug("EP STATE RUNNING.\n");
> >>>
> >>> The driver file itself stems from the Linux sources, so I'm pretty sure
> >>> that it is correct in that context.
> >>> Even though I'm not really into USB stuff and therefore I cannot not
> >>> really follow the discussion for the proposed change, in my eyes the
> >>> patch could be reasonable for U-Boot nevertheless given that a) in my
> >>> experience driver code is often used in a simplified way in U-Boot
> >>> compared to Linux kernel, and b) it's all about board start-up only and
> >>> not about full OS use with all bells, whistles and full error handling.
> >>>
> >>> Of course, I might be wrong 

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Marc Zyngier]

On Mon, 14 Aug 2023 21:39:10 +0100,
Andre Przywara  wrote:
> 
> On Wed, 31 May 2023 14:15:20 -0600
> Sam Edwards  wrote:
> 
> Hi,
> 
> (CC:ing Marc and Chen-Yu as the original authors)
> 
> sorry for the delay, found that mouldering in my Drafts folder.
> 
> > The nonsec code overrides/handles these:
> > - Setting PMR to 0xFF happens earlier, in _nonsec_init, so this is
> >   redundant.
> > - The NS bit is not yet set: it gets set later in _secure_monitor.
> >   Trying to clear it here is pointless and misleading.
> 
> So superficially this looks alright, but I am still somewhat reluctant
> to apply this, see below ...
> 
> > Signed-off-by: Sam Edwards 
> > ---
> >  arch/arm/cpu/armv7/sunxi/psci.c | 4 
> >  1 file changed, 4 deletions(-)
> > 
> > diff --git a/arch/arm/cpu/armv7/sunxi/psci.c 
> > b/arch/arm/cpu/armv7/sunxi/psci.c
> > index e1d3638b5c..f866025c37 100644
> > --- a/arch/arm/cpu/armv7/sunxi/psci.c
> > +++ b/arch/arm/cpu/armv7/sunxi/psci.c
> > @@ -300,14 +300,10 @@ void __secure psci_arch_init(void)
> > /* Set SGI15 priority to 0 */
> > writeb(0, GICD_BASE + GICD_IPRIORITYRn + 15);
> >  
> > -   /* Be cool with non-secure */
> > -   writel(0xff, GICC_BASE + GICC_PMR);
> > -
> > /* Switch FIQEn on */
> > setbits_le32(GICC_BASE + GICC_CTLR, BIT(3));
> >  
> > reg = cp15_read_scr();
> > reg |= BIT(2);  /* Enable FIQ in monitor mode */
> > -   reg &= ~BIT(0); /* Secure mode */
> 
> I am scratching my head on this one: I see it deliberately being done in
> the original patch by Marc[1], and wonder why. If I read the code and
> the architecture correctly, this routine is called only(?) from the SMC
> handler, which means we are in monitor mode, that only exists in secure
> state. So the NS bit is irrelevant until we switch to another mode. And
> we indeed set the bit later, before dropping back to non-secure. So I
> agree that clearing the bit is pointless. Was it put in to be more
> robust, for other potential callers of this function, for instance in
> the boot path?
> 
> Does anyone remember?

I don't remember much about this, but setting PMR to include the NS
priorities (PMR[7]) is definitely significant when SCR.NS==0.
Otherwise, NS cannot write to PMR, which basically kills NS any use.

Now, and without the full context, it is hard to figure out what is
going on. But a lot of that crap was written with mandate to be able
to support the stupid old AW BSP which ran in secure mode, so there
were a number of convoluted paths to get there.

If this nonsense can now be dropped, I'm sure the whole thing can be
simplified. But someone who still care about 32bit platforms (i.e. not
me) should have a look.

Thanks,

M.

-- 
Without deviation from the norm, progress is not possible.

[PATCH 1/1] doc: add partition API to HTML documentation

[Heinrich Schuchardt]

* Convert comments in part.h to Sphinx style.
* Create documentation page for the partition API.
* Add the partition API page to the API index page.

Signed-off-by: Heinrich Schuchardt 
---
 doc/api/index.rst |   1 +
 doc/api/part.rst  |   6 ++
 include/part.h| 210 --
 3 files changed, 119 insertions(+), 98 deletions(-)
 create mode 100644 doc/api/part.rst

diff --git a/doc/api/index.rst b/doc/api/index.rst
index a9338cfef9..3a80ae0635 100644
--- a/doc/api/index.rst
+++ b/doc/api/index.rst
@@ -15,6 +15,7 @@ U-Boot API documentation
lmb
logging
nvmem
+   part
pinctrl
rng
sandbox
diff --git a/doc/api/part.rst b/doc/api/part.rst
new file mode 100644
index 00..d1df1d8494
--- /dev/null
+++ b/doc/api/part.rst
@@ -0,0 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Partition API
+=
+
+.. kernel-doc:: include/part.h
diff --git a/include/part.h b/include/part.h
index edc46f8dcb..8e451bbdff 100644
--- a/include/part.h
+++ b/include/part.h
@@ -98,8 +98,8 @@ struct disk_part {
  * @ifname:Interface name (e.g. "ide", "scsi")
  * @dev:   Device number (0 for first device on that interface, 1 for
  * second, etc.
- * Return: pointer to the block device, or NULL if not available, or an
- *error occurred.
+ * Return:
+ * pointer to the block device, or NULL if not available, or an error occurred.
  */
 struct blk_desc *blk_get_dev(const char *ifname, int dev);
 
@@ -128,6 +128,10 @@ int part_get_info(struct blk_desc *dev_desc, int part,
 /**
  * part_get_info_whole_disk() - get partition info for the special case of
  * a partition occupying the entire disk.
+ *
+ * @dev_desc:  block device descriptor
+ * @info:  returned partition information
+ * Return: 0 on success
  */
 int part_get_info_whole_disk(struct blk_desc *dev_desc,
 struct disk_partition *info);
@@ -170,15 +174,18 @@ int blk_get_device_by_str(const char *ifname, const char 
*dev_str,
  * This calls blk_get_device_by_str() to look up a device. It also looks up
  * a partition and returns information about it.
  *
- * @dev_part_str is in the format:
- * .: where  is the device number,
- *  is the optional hardware partition number and
- *  is the partition number
+ * @dev_part_str is in the format .: where
+ *
+ * *  is the device number,
+ *
+ * *  is the optional hardware partition number and
  *
- * If ifname is "hostfs" then this function returns the sandbox host block
+ * *  is the partition number.
+ *
+ * If @ifname is "hostfs", then this function returns the sandbox host block
  * device.
  *
- * If ifname is ubi, then this function returns 0, with @info set to a
+ * If @ifname is "ubi", then this function returns 0, with @info set to a
  * special UBI device.
  *
  * If @dev_part_str is NULL or empty or "-", then this function looks up
@@ -187,13 +194,13 @@ int blk_get_device_by_str(const char *ifname, const char 
*dev_str,
  * If the partition string is empty then the first partition is used. If the
  * partition string is "auto" then the first bootable partition is used.
  *
- * @ifname:Interface name (e.g. "ide", "scsi")
+ * @ifname:Interface name (e.g. "ide", "scsi")
  * @dev_part_str:  Device and partition string
- * @dev_desc:  Returns a pointer to the block device on success
- * @info:  Returns partition information
+ * @dev_desc:  Returns a pointer to the block device on success
+ * @info:  Returns partition information
  * @allow_whole_dev:   true to allow the user to select partition 0
- * (which means the whole device), false to require a valid
- * partition number >= 1
+ * (which means the whole device), false to require a valid
+ * partition number >= 1
  * Return: partition number, or -1 on error
  *
  */
@@ -205,18 +212,20 @@ int blk_get_device_part_str(const char *ifname, const 
char *dev_part_str,
  * part_get_info_by_name() - Search for a partition by name
  *   among all available registered partitions
  *
- * @param dev_desc - block device descriptor
- * @param gpt_name - the specified table entry name
- * @param info - returns the disk partition info
+ * @dev_desc:  block device descriptor
+ * @name:  the specified table entry name
+ * @info:  returns the disk partition info
  *
- * Return: - the partition number on match (starting on 1), -1 on no match,
+ * Return: the partition number on match (starting on 1), -1 on no match,
  * otherwise error
  */
 int part_get_info_by_name(struct blk_desc *dev_desc,
  const char *name, struct disk_partition *info);
 
 /**
- * Get partition info from dev number + part name, or dev number + part number.
+ * part_get_info_by_dev_and_name_or_num() - Get partition info from dev number
+ * and part name, or dev number and
+ *