Re: [PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

Hi Simon,

On Tue, 5 Dec 2023 at 06:22, Simon Glass  wrote:
>
> Hi Sumit,
>
> On Tue, 21 Nov 2023 at 23:21, Sumit Garg  wrote:
> >
> > Hi Caleb,
> >
> > On Tue, 21 Nov 2023 at 22:39, Caleb Connolly  
> > wrote:
> > >
> > > Historically, Qualcomm boards in U-Boot have all had their own
> > > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> > > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > > devicetree with little/no compatibility with upstream DT.
> > >
> > > This series makes a few final prepatory changes, and then replaces
> > > almost all of the board specific code with generic alternatives. The end
> > > result is that all Qualcomm boards both current and future (with the
> > > exception of the db410c and db820c) can be supported by a single U-Boot
> > > binary by just providing the correct DT. New boards can be added without
> > > introducing any addition mach/ or board/ code or config options.
> > >
> > > Due to the nature of this change, the patch ("mach-snapdragon:
> > > generalise board support") has become pretty big, I tried a few
> > > different ways to represent this in git history, but the other methods
> > > (e.g. adding a stub "generic" target and removing it again) were more
> > > confusing and made for much messier git history. The current patch is
> > > mostly atomic, but requires regenerating the config.
> > >
> > > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > > this is dropped in favour of a adding a new vbus-supply property to the
> > > dwc3-generic driver. This will also be used by the dragonboard845c in a
> > > future patch. This handles the common case of a board requiring some
> > > regulator be enabled for USB host mode.
> > >
> >
> > Thanks for your work. It is a good step towards a generalized u-boot
> > on Qcom platforms. Although I would like to give it an in-depth
> > review, I have a common discussion point about DT, see below.
> >
> > > A more detailed description of the changes is below.
> > >
> > > == Memory map ==
> > >
> > > The memory map was historically hardcoded into U-Boot, this meant that
> > > U-Boot had to be built for a specific variant of a device. This is
> > > changed to instead read the memory map from the DT /memory node.
> > >
> > > Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> > > null pointer access happens then it will cause a bus stall (and board
> > > hang). This is fixed so that null pointer accesses will now correctly
> > > throw an exception.
> > >
> > > == DT loading ==
> > >
> > > Previously, boards used the FDT blob embedded into U-Boot (via
> > > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> > > bootloader, so we can instead rely on the first-stage bootloader to
> > > populate some useful FDT properties for us (notably the /memory node and
> > > KASLR seed) and fetch the DTB that it provides. Combined with the memory
> > > map changes above, this let's us entirely avoid configuring the memory
> > > map explicitly.
> >
> > Since with this change, we don't need to embed FDT blob in the u-boot
> > binary, so I was thinking if we really need to import DTs from Linux
> > for different platforms and then play a catchup game?
> >
> > IMO, the build command would look like following if we import
> > pre-built FDT blob from Linux:
> >
> > - Build u-boot::
> >
> >$ export CROSS_COMPILE=
> >$ make qcom_defconfig
> >$ make
> >
> > - gzip u-boot::
> >
> >gzip u-boot-nodtb.bin
> >
> > - Append dtb to gzipped u-boot::
> >
> > cat u-boot-nodtb.bin.gz
> > /arch/arm64/boot/dts/qcom/your-board.dtb >
> > u-boot-nodtb.bin.gz-dtb
>
> What is this?? Who or what uses a gzipped image with a single DT attached?

The gzipped image is loaded by Qcom proprietary bootloaders (ABL or
LK). It is the usual way Linux is booted on these platforms. U-boot is
being brought into this chain to leverage standardized EFI boot
processes.

>
> >
> > This would avoid the maintenance burden to keep DT in sync with that
> > of Linux. And since DT bindings in Linux are backwards compatible, we
> > can say u-boot should work with DTB picked up from any Linux kernel
> > stable release.
>
> That is not the current situation, unfortunately.
>

Hopefully with efforts from Caleb and team we can reach that point soon.

> U-Boot is moving to using Binman to package the firmware. There needs
> to be a description of the firmware image for each U-Boot boot. To my
> way of thinking, rpi is a degenerate form, not something to be copied,
> due to the closed-source nature of the firmware and its inability to
> be changed. We do have (in the works) a way to pass a DT using a
> standard firmware handoff. Perhaps that can be adopted by these
> closed-source projects?

Why should we really need firmware handoff if the DT can be passed in
one of the u-boot boot arguments? Linux kernel does support this
method to retrieve DT as well.

>
> BTW 

Re: [PATCH 00/21] Qualcomm generic board support

[Krzysztof Kozlowski]

On 05/12/2023 08:13, Sumit Garg wrote:
>>> @DT bindings maintainers,
>>>
>>> Given the ease of maintenance of DT bindings within Linux kernel
>>> source tree, I don't have a specific objection there. But can we ease
>>> DTS testing for firmware/bootloader projects by providing a versioned
>>> release package for DT bindings? Or if someone else has a better idea
>>> here please feel free to chime in.
>>
>> This doesn't work for you?:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
> 
> Thanks, this is certainly a good step which I wasn't aware of. Further
> simplification can be done to decouple devicetree source files from DT
> bindings. 

Why?

> AFAIK, DT bindings should be forwards and backwards
> compatible. 

The same with DTS.

> So if you pick up DTS or DTB from any project tree
> (upstream kernel or stable kernel or u-boot) then DT schema validation
> would ensure that corresponding DTS or DTB doesn't regress the DT
> bindings.

And why is this argument to decouple DTS from bindings?

> 
> Ideally, it should be more user/CI friendly if DT bindings can be
> easily installed alongside devicetree schema tools [1].
> 
> [1] https://github.com/devicetree-org/dt-schema

Does it mean you will work on this?

Best regards,
Krzysztof

Re: [PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Mon, 4 Dec 2023 at 22:31, Rob Herring  wrote:
>
> On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg  wrote:
> >
> > + Linux kernel DT bindings maintainers, EBBR ML
> >
> > On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
> > >
> > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong 
> > > >  wrote:
> > > > >
> > > > > On 29/11/2023 16:34, Caleb Connolly wrote:
> > > > > >
> > > > > >
> > > > > > On 23/11/2023 07:04, Sumit Garg wrote:
> > > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly 
> > > > > >>  wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>>
> > > > > >>> On 22/11/2023 14:27, Tom Rini wrote:
> > > > >  On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote:
> > > > > > On Wed, 22 Nov 2023 at 19:31, Tom Rini  
> > > > > > wrote:
> > > > > >>
> > > > > >> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote:
> > > > > >>> Hi Caleb,
> > > > > >>>
> > > > > >>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly 
> > > > > >>>  wrote:
> > > > > >> [snip]
> > > > >  == DT loading ==
> > > > > 
> > > > >  Previously, boards used the FDT blob embedded into U-Boot 
> > > > >  (via
> > > > >  OF_SEPARATE). However, most Qualcomm boards run U-Boot as a 
> > > > >  secondary
> > > > >  bootloader, so we can instead rely on the first-stage 
> > > > >  bootloader to
> > > > >  populate some useful FDT properties for us (notably the 
> > > > >  /memory node and
> > > > >  KASLR seed) and fetch the DTB that it provides. Combined 
> > > > >  with the memory
> > > > >  map changes above, this let's us entirely avoid configuring 
> > > > >  the memory
> > > > >  map explicitly.
> > > > > >>>
> > > > > >>> Since with this change, we don't need to embed FDT blob in 
> > > > > >>> the u-boot
> > > > > >>> binary, so I was thinking if we really need to import DTs 
> > > > > >>> from Linux
> > > > > >>> for different platforms and then play a catchup game?
> > > > > >>>
> > > > > >>> For now, yes.
> > > > > >>
> > > > > >> But why? Is there any value added by larger u-boot specific DT 
> > > > > >> (most
> > > > > >> of the nodes being unused by u-boot) than what currently u-boot
> > > > > >> supports? The more important part is to get alignment with Linux DT
> > > > > >> bindings. If you need to have memory/reserved-memory nodes in 
> > > > > >> u-boot
> > > > > >> DT for generalization purposes then you should import those 
> > > > > >> particular
> > > > > >> nodes only.
> > > > > >
> > > > > > I've been thinking about and hacking on this for the last week or 
> > > > > > so,
> > > > > > sorry for the delayed reply here.
> > > > > >
> > > > > > The value is in preventing any of the existing bindings from 
> > > > > > regressing,
> > > >
> > > > That is actually best addressed in Linux by checking the DTS against
> > > > yaml DT bindings. We don't have that testing available in u-boot and
> > > > only depend on careful reviews.
> > >
> > > I would absolutely love for someone to make another attempt at updating
> > > our kbuild infrastucture so that we can run the validation targets.
> > >
> >
> > Given that EBBR requires [1] the platform (firmware/bootloader) and
> > not OS to supply the devicetree, it becomes evident that
> > firmware/bootloaders import DTS from Linux kernel (where it is
> > maintained).
> >
> > But currently u-boot doesn't have a proper way to validate those DTS
> > against DT bindings (maintained in Linux kernel). Although there are
> > Devicetree schema tools available here [2], there isn't a versioned
> > release package of DT bindings which one should use to validate DTS
> > files.
> >
> > @DT bindings maintainers,
> >
> > Given the ease of maintenance of DT bindings within Linux kernel
> > source tree, I don't have a specific objection there. But can we ease
> > DTS testing for firmware/bootloader projects by providing a versioned
> > release package for DT bindings? Or if someone else has a better idea
> > here please feel free to chime in.
>
> This doesn't work for you?:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Thanks, this is certainly a good step which I wasn't aware of. Further
simplification can be done to decouple devicetree source files from DT
bindings. AFAIK, DT bindings should be forwards and backwards
compatible. So if you pick up DTS or DTB from any project tree
(upstream kernel or stable kernel or u-boot) then DT schema validation
would ensure that corresponding DTS or DTB doesn't regress the DT
bindings.

Ideally, it should be more user/CI friendly if DT bindings can be
easily installed alongside devicetree schema tools [1].

[1] https://github.com/devicetree-org/dt-schema

>
> Note that I would like to revamp this repo to use some modern CI job,
> use git_filter_repo python module rather 

Re: [PATCH 1/1] efi_loader: boot options should relate to the ESP

[Masahisa Kojima]

Hi Heinrich,

On Tue, 5 Dec 2023 at 11:38, Heinrich Schuchardt
 wrote:
>
> * Only generate removable media entries for EFI system partitions.
> * Only offer EFI system partitions for boot options in the eficonfig
>   command.
>
> Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
> Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  cmd/eficonfig.c  | 6 --
>  lib/efi_loader/efi_bootmgr.c | 3 ++-
>  2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> index 34a59cb15d..c066b28b6b 100644
> --- a/cmd/eficonfig.c
> +++ b/cmd/eficonfig.c
> @@ -626,8 +626,10 @@ static efi_status_t eficonfig_select_volume(struct 
> eficonfig_select_file_info *f
> efi_handle_t *volume_handles = NULL;
> struct efi_simple_file_system_protocol *v;
>
> -   ret = efi_locate_handle_buffer_int(BY_PROTOCOL, 
> _simple_file_system_protocol_guid,
> -  NULL, , (efi_handle_t 
> **)_handles);
> +   /* Find all EFI system partitions */
> +   ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> +  _system_partition_guid,
> +  NULL, , _handles);

UEFI specification v2.10 section '3.5 Boot Mechanisms' says
"EFI can boot from a device using the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or the
EFI_LOAD_FILE_PROTOCOL."

So in my understanding of the UEFI spec, I think
efi_simple_file_system_protocol_guid
is correct here.

> if (ret != EFI_SUCCESS) {
> eficonfig_print_msg("No block device found!");
> return ret;
> diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
> index 48153bd5ff..9e84391186 100644
> --- a/lib/efi_loader/efi_bootmgr.c
> +++ b/lib/efi_loader/efi_bootmgr.c
> @@ -1047,8 +1047,9 @@ efi_status_t 
> efi_bootmgr_update_media_device_boot_option(void)
> efi_handle_t *volume_handles = NULL;
> struct eficonfig_media_boot_option *opt = NULL;
>
> +   /* Find all EFI system partitions */
> ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
> -  
> _simple_file_system_protocol_guid,
> +  _system_partition_guid,

In EDK II reference implementation[0], it enumerates all
block_io_protocol devices
and eliminates logical partitions.
Should we do the same? If yes, I can prepare the patch on this.

[0] 
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L2220

Regards,
Masahisa Kojima

>NULL, ,
>(efi_handle_t **)_handles);
> if (ret != EFI_SUCCESS)
> --
> 2.40.1
>

Re: [PATCH v2 15/18] fdt: Allow the devicetree to come from a bloblist

[Ilias Apalodimas]

Hi Simon,

We did discuss this in OSFC but perhaps you forgot.  The discussion
was based on the mail here [0].

On Tue, 5 Dec 2023 at 02:52, Simon Glass  wrote:
>
> Hi Raymond,
>
> On Mon, 4 Dec 2023 at 12:25, Raymond Mao  wrote:
> >
> > Hi Simon,
> >
> > When `OF_BOARD` is defined, the FDT should be from one of  the 
> > board-specific mechanisms:
> > 1. FDT from a bloblist via boot args
> > 2. FDT in memory
> > I don't think we need a new build option to distinguish these two, since it 
> > can be done in runtime by checking whether the boot args follow the FW 
> > Handoff spec conventions and the FDT exists in the bloblist.
>
> No, I would really like this to be deterministic, so we can fail if
> something goes wrong. The bloblist should be 'declared' as the way to
> boot, for a board.

We *are* deterministic. I am just going to repeat what we discussed in
OSFC for completeness.
OF_BLOBLIST makes little sense because we are not going to add a
Kconfig per blolblist entry.
I haven't looked at what the patch does yet but the idea was really simple.
- Under OF_BOARD (which can arguably be renamed to OF_PREVIOUS_STAGE
or something like that)  if CONFIG_BLOB is enabled we scan for a
bloblist
- If CONFIG_BLOB is enabled but no bloblist is provided we fail the boot
- If CONFIG_BLOB is not enabled we do what we did up to now, maybe
with a message that this is going to be obsoleted once enough boards
migrate to a bloblist

IOW if support for a bloblist is enabled we expect to find one from
the previous bootloader. I've lost count of how many times I repeated
this, but here it goes again
The device tree can come
- From u-boot
- From a previous stage loader *somehow* (eg. passed on a bloblist,
passed on a register, read from an EEPROM etc)

We should keep that distinction and create subcategories for the
'comes from a previous stage loader', rather than adding arbitrary
config options which only confuse people

Regards
/Ilias
>
> If in the future all boards a reusing bloblist for this feature, then
> sure, we can drop it. But we have things like rpi which do their own
> thing.
>
> > If it fulfills the above conditions, we can take the FDT from bloblist, 
> > otherwise from the predefined memory address.
> > This is fully backward compatible without adding a new build option.
>
> Again, we need to obtain the FDT from the bloblist if and only if the
> board requires it. It creates a lot of confusion to have it as an
> optional feature, when we know which way it should be.
>
> Ultimately OF_BOARD should go away. We just need to push bloblist to
> other projects and closed-source firmware as the correct way to pass a
> DT.
>
> Regards,
> Simon
> [.]

[0] 
https://lore.kernel.org/u-boot/capnjgz0sqvyj_drleqrp21zpycco3hop-ryd+nkjma0bvyp...@mail.gmail.com/

Re: [PATCH] common: usb-hub: Reset hub port before scanning

[Marek Vasut]

On 12/4/23 13:10, Shantur Rathore wrote:

On Mon, Dec 4, 2023 at 11:05 AM Marek Vasut  wrote:


On 12/4/23 11:59, Shantur Rathore wrote:

Hi Marek,

On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut  wrote:


On 12/3/23 22:42, Shantur Rathore wrote:

Hi Marek,

On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut  wrote:


On 11/24/23 01:37, Shantur Rathore wrote:

Hi Marek,


Hi,

sorry for the late reply.


In my case RockPro64, the power to usb ports onboard is controlled by
a regulator.
This regulator is enabled as part of init  as here
https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177

On init, the usb devices connected to the port are powered up, in my
case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS.
But the usb controller is only enabled at 'usb start' and by this time
the device is in some state that it doesn't get detected.

One way to make sure the devices connected to the ports are in an
initialising state is by issuing a port reset before scanning the
port.


Why not remove this regulator-always-on and let the PHY driver turn the
VBUS ON only when it is needed ?

Wouldn't that solve the problem too AND remove unnecessarily enabled
regulator ?

[...]


Removing the regulator-always-on does make it work but there are few issues

1. regulator is used to control power to multiple ports ( USB3.0 and
USB2.0 in RockPro64 ),
so this could lead to all ports turning off if a phy resets / turns off power


I vaguely recall seeing some refcounting patch for regulator subsystem,
would that help ?


I don't think this would be a problem for u-boot, but linux maybe.


How so ?


Actually, I am wrong. I wasn't sure if there is refcounting for the
regulator subsystem
in linux. just found it has so this is null and void.




2. Even with regulator-always-on and without this reset port patch,
linux was always
able to detect the drive on the port, so there is something missing in u-boot.
3. Looking at usb hub code in Linux, I found that for USB3.0 it tries
to reset the port before
scanning. The comment says

/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
  * Port warm reset is required to recover
  */

i. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736
ii. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836

I believe this isn't implemented in u-boot and hence explicit reset of
a port fixes the issue.


I feel this is separate issue and what needs to be fixed first is the
hard-wired VBus control.


I beg to differ on this, couple of reasons for this

1. The same drive works fine without being reset on the USB2.0 ports - this
confirms that the issue is related to USB3.0 only.


This is a separate issue from the hard-wired VBus control. I agree the
issue does exist, I would simply like to avoid conflating the hard-wired
VBus control with device reset.


2. Linux is able to detect the same drive on USB3.0 when u-boot fails - this
confirms issue doesn't lie with regulator-always-on


See above


3. The links I pasted earlier mentions that in USB3.0 the ports need reset
and this is done before the port is scanned. Adding the similar reset in u-boot
fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle
this special USB3.0 case and maybe this is why I was finding a few posts
around the drive not being detected in the USB3.0 port in u-boot but works in
a USB2.0 port.


I am not disputing the need for USB 3.0 device reset, I believe there
are two issues here -- one is the hard-wired VBus regulator -- the other
is this USB 3.0 reset. They should both be fixed.


Sure, agreed 100%.
Do we need to fix both at the same time?
Both patches seem to be independent.


Separate patch for the regulator please .


Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but
there seems to be a bug in the rk3399-rockpro64.dtsi from linux where
the typec phy
is configure with wrong regulator and if I do the patch as below

--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -22,6 +22,23 @@
  };
   };

+_host {
+   /delete-property/ regulator-always-on;
+};
+
+_typec {
+   /delete-property/ regulator-always-on;
+};
+
+_usb {
+   /delete-property/ regulator-always-on;
+   /delete-property/ regulator-boot-on;
+};

The typec port won't work until I correct the issue with

+_host {
+   phy-supply = <_typec>;
+};
+

What would be acceptable here?
1. Leave regulator for typec as it was
2. disable regulator-always-on and fix phy here.


Is there going to be a matching Linux kernel patch with a Linux side fix ?

If so, include a link to that patch in lore.k.o in the commit message,
and either temporarily fix it up in u-boot.dtsi or backport that patch
to U-Boot DT, either works.


So there is no patch in lore.k.o for this and the more I looked the more
dts needed fixing related  usb. I would rather do it in one go and submit
proper 

Re: [PATCH 0/2] docs: AM62x: Remove SW_PRNG Flag for OPTEE

[Dhruva Gole]

Hi Nishanth,

On 05/12/23 01:00, Nishanth Menon wrote:

On 15:59-20231201, Dhruva Gole wrote:

The CFG_WITH_SOFTWARE_PRNG option was needed once when there were some
issues with system crashes/ hangs after a suspend-resume cycle. However
this seems to no longer be the case with newer firmwares, and this
config is not needed for basic boot support of the SoC either, hence
remove it from the docs.

Cc: Kamlesh 
Cc: Vibhore Vardhan 
Cc: Wadim Egorov >
Dhruva Gole (2):
   doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE
   doc: board: ti: am62x_sk: Remove SW_PRNG Flag for OPTEE

  doc/board/beagle/am62x_beagleplay.rst | 1 -
  doc/board/ti/am62x_sk.rst | 1 -
  2 files changed, 2 deletions(-)



NAK to the series. RNG seed is needed for KASLR. either enable h/w RNG


@Wadim: Please take note and ignore my previous suggestion to you to
remove this line, keep this line as is.


or at least enable S/W RNG in OPTEE.



Agreed, I will send a patch to use HWRNG later on then. For now let's
just keep the PRNG enabled in these docs.


--
Thanks and Regards,
Dhruva Gole

Re: [PATCH v2] riscv: Add support for AMD/Xilinx MicroBlaze V

[Padmarao.Begari]

On Mon, 2023-11-06 at 12:56 +0100, Michal Simek wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you
> know the content is safe
> 
> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> It is hardware compatible with classic MicroBlaze processor.
> 
> The patch contains initial wiring and configuration for initial HW
> design
> with memory, cpu, interrupt controller, timers and uartlite console
> (interrupt controller is listed but U-Boot is not using it).
> 
> Provided DT is just describing one configuration and should be taken
> only
> as example.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Extend commit message
> - DT changes, add interrupt controller, check agains dt schema
> - The patch for amd,mbv32 compatible string is here
> https://lore.kernel.org/r/d442d916204d26f82c1c3a924a4cdfb117960e1b.1699270661.git.michal.si...@amd.com
> - The patch for board compatibility is here
> https://lore.kernel.org/r/50c277c92c41a582ef171fb75efc6a6a4f860be2.1699271616.git.michal.si...@amd.com
> 
> xlnx,xps-intc-1.00.a driver exists in the Linux kernel but DT binding
> is
> missing. That's something what we need to work on.
> arch/arm64/boot/dts/xilinx/xilinx-mbv32.dtb: 
> /axi/interrupt-controller@4120: failed to match any schema with
> compatible: ['xlnx,xps-intc-1.00.a']
> 
> Public annoucement is available here if someone is interested.
> https://www.xilinx.com/products/design-tools/microblaze-v.html?utm_source=marketo_medium=email_campaign=EN-EM-2023-11-02-New-MicroBlaze-V-Processor_term=btn_tok=NDA5LVdZWC03MjQAAAGPMMJYuPPscCags7WdvOeUSWy-_mC9aOwrobFaZRf5ok_eHoQUvTLBzJdHrkcBId9tQ4a-odfnU91WjUkIxx-iSG4OKGofjK5iZcAiK_VN8_xK
> 
> ---
>  arch/riscv/Kconfig   |   4 +
>  arch/riscv/dts/Makefile  |   2 +
>  arch/riscv/dts/xilinx-mbv32.dts  | 106
> +++
>  board/xilinx/Kconfig |   3 +-
>  board/xilinx/common/board.c  |   5 ++
>  board/xilinx/mbv/Kconfig |  28 +++
>  board/xilinx/mbv/MAINTAINERS |   7 ++
>  board/xilinx/mbv/Makefile|   5 ++
>  board/xilinx/mbv/board.c |  11 +++
>  configs/xilinx_mbv32_defconfig   |  30 
>  configs/xilinx_mbv32_smode_defconfig |  32 
>  include/configs/xilinx_mbv.h |   6 ++
>  12 files changed, 238 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/dts/xilinx-mbv32.dts
>  create mode 100644 board/xilinx/mbv/Kconfig
>  create mode 100644 board/xilinx/mbv/MAINTAINERS
>  create mode 100644 board/xilinx/mbv/Makefile
>  create mode 100644 board/xilinx/mbv/board.c
>  create mode 100644 configs/xilinx_mbv32_defconfig
>  create mode 100644 configs/xilinx_mbv32_smode_defconfig
>  create mode 100644 include/configs/xilinx_mbv.h
> 
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 6d0d812ddb55..67126d96af89 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -39,6 +39,9 @@ config TARGET_TH1520_LPI4A
> bool "Support Sipeed's TH1520 Lichee PI 4A Board"
> select SYS_CACHE_SHIFT_6
> 
> +config TARGET_XILINX_MBV
> +   bool "Support AMD/Xilinx MicroBlaze V"
> +
>  endchoice
> 
>  config SYS_ICACHE_OFF
> @@ -82,6 +85,7 @@ source "board/sifive/unmatched/Kconfig"
>  source "board/sipeed/maix/Kconfig"
>  source "board/starfive/visionfive2/Kconfig"
>  source "board/thead/th1520_lpi4a/Kconfig"
> +source "board/xilinx/mbv/Kconfig"
> 
>  # platform-specific options below
>  source "arch/riscv/cpu/andesv5/Kconfig"
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index be6c8a422729..b05bb5607f06 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -9,6 +9,8 @@ dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-
> unmatched-a00.dtb
>  dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
>  dtb-$(CONFIG_TARGET_STARFIVE_VISIONFIVE2) += jh7110-starfive-
> visionfive-2.dtb
>  dtb-$(CONFIG_TARGET_TH1520_LPI4A) += th1520-lichee-pi-4a.dtb
> +dtb-$(CONFIG_TARGET_XILINX_MBV) += xilinx-mbv32.dtb
> +
>  include $(srctree)/scripts/Makefile.dts
> 
>  targets += $(dtb-y)
> diff --git a/arch/riscv/dts/xilinx-mbv32.dts b/arch/riscv/dts/xilinx-
> mbv32.dts
> new file mode 100644
> index ..6a6b8b694bd1
> --- /dev/null
> +++ b/arch/riscv/dts/xilinx-mbv32.dts
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * dts file for AMD MicroBlaze V
> + *
> + * (C) Copyright 2023, Advanced Micro Devices, Inc.
> + *
> + * Michal Simek 
> + */
> +
> +/dts-v1/;
> +/ {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   model = "AMD MicroBlaze V 32bit";
> +   compatible = "amd,mbv";
> +
> +   cpus: cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   timebase-frequency = <10200>;
> +   cpu_0: cpu@0 {
> +   compatible = "amd,mbv32", "riscv";
> +   device_type = "cpu";
> +   

Re: [PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument

[Neha Malcom Francis]

Hi Andrew

On 04/12/23 20:36, Andrew Davis wrote:

On 12/4/23 5:21 AM, Neha Malcom Francis wrote:

Mention TI_DM argument can be used to fetch a custom DM binary in the
A72 build instructions for K3 devices.

Signed-off-by: Neha Malcom Francis 
---
  doc/board/ti/k3.rst | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index a127215ce5..15916b088f 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -320,6 +320,13 @@ use the `lite` option.
   make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
  BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
  TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin
+
+.. note::
+   It is also possible to pick up a custom DM binary by adding TI_DM argument
+   pointing to the file. If not provided, it defaults to picking up the DM
+   binary from ti-linux-firmware. This is only applicable to devices that


It would only be "ti-linux-firmware" if that is what you had set as 
BINMAN_INDIRS.

s/ti-linux-firmware/BINMAN_INDIRS



Thanks for catching that, will make the change.


Otherwise whole series LGTM,

Reviewed-by: Andrew Davis 


+   utilize split firmware.
+
  .. k3_rst_include_end_build_steps_uboot
  At this point you should have every binary needed initialize both the


--
Thanking You
Neha Malcom Francis

Re: [PATCH 2/2] arm: dts: k3-j7200-r5-common-proc-board: Set parent clock for clock ID 323

[Kumar, Udit]

On 12/2/2023 3:03 AM, Reid Tonking wrote:

From: Apurva Nandan 

This virtual clock mux configuration enables the use of dynamic frequency
scaling on A72 clock ID 202 by setting up the required register.


IMO, dynamic frequency scaling should be supported without this patch.
But this patch allows to set freq at different rates other than fixed division.
I request to update commit message.
Rest LGTM


Signed-off-by: Apurva Nandan 
Signed-off-by: Reid Tonking 
---
  arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts 
b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
index f0a73605020..018faaa13b6 100644
--- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
+++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
@@ -24,7 +24,8 @@
<_pds 4 TI_SCI_PD_EXCLUSIVE>;
resets = <_reset 202 0>;
clocks = <_clks 61 1>;
-   assigned-clocks = <_clks 202 2>, <_clks 61 1>;
+   assigned-clocks = <_clks 202 2>, <_clks 61 1>, <_clks 323 
0>;
+   assigned-clock-parents= <0>, <0>, <_clks 323 2>;
assigned-clock-rates = <20>, <2>;
ti,sci = <>;
ti,sci-proc-id = <32>;

Re: [PATCH 1/2] arm: mach-k3: j72xx: add new 'virtual' mux

[Kumar, Udit]

On 12/2/2023 3:03 AM, Reid Tonking wrote:

From: Bryan Brattlof 

In order for the Cortex-A72s to operate at different frequencies other
than the default 2GHz, add in a new 'virtual' mux (a mux that does not
physically exist in the clock tree) that can be selected.

CC: Vishal Mahaveer 
Signed-off-by: Bryan Brattlof 
Signed-off-by: Apurva Nandan 
Signed-off-by: Reid Tonking 
---
  arch/arm/mach-k3/j7200/clk-data.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-k3/j7200/clk-data.c 
b/arch/arm/mach-k3/j7200/clk-data.c
index 9b45786a2d4..126627fff47 100644
--- a/arch/arm/mach-k3/j7200/clk-data.c
+++ b/arch/arm/mach-k3/j7200/clk-data.c
@@ -141,6 +141,11 @@ static const char * const 
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] = {
"hsdiv4_16fft_main_0_hsdivout0_clk",
  };
  
+static const char * const main_pll8_sel_extwave_out0_parents[] = {

+   "pllfracf_ssmod_16fft_main_8_foutvcop_clk",
+   "hsdiv0_16fft_main_8_hsdivout0_clk",
+};
+
  static const char * const mcu_obsclk_outmux_out0_parents[] = {
"mcu_obsclk_div_out0",
"gluelogic_hfosc0_clkout",
@@ -396,6 +401,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_3_hsdivout2_clk", 
"pllfracf_ssmod_16fft_main_3_foutvcop_clk", 0x683088, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("k3_pll_ctrl_wrap_main_0_sysclkout_clk", 
k3_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
CLK_DIV("k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk", 
"k3_pll_ctrl_wrap_main_0_sysclkout_clk", 0x410118, 0, 5, 0, 0),
+   CLK_MUX("main_pll8_sel_extwave_out0", 
main_pll8_sel_extwave_out0_parents, 2, 0x688040, 0, 1, 0),
CLK_DIV("mcu_obsclk_div_out0", "wkup_obsclk_mux_out0", 0x43008000, 8, 
4, 0, 0),
CLK_MUX("mcu_obsclk_outmux_out0", mcu_obsclk_outmux_out0_parents, 2, 
0x43008000, 24, 1, 0),
CLK_PLL("pllfracf_ssmod_16fft_main_4_foutvcop_clk", 
"main_pll4_xref_sel_out0", 0x684000, 0),
@@ -545,11 +551,14 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(288, 14, "board_0_hfosc1_clk_out"),
DEV_CLK(288, 15, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(288, 17, "k3_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
+   DEV_CLK(323, 0, "main_pll8_sel_extwave_out0"),
+   DEV_CLK(323, 1, "pllfracf_ssmod_16fft_main_8_foutvcop_clk"),
+   DEV_CLK(323, 2, "hsdiv0_16fft_main_8_hsdivout0_clk"),
  };
  
  const struct ti_k3_clk_platdata j7200_clk_platdata = {

.clk_list = clk_list,
-   .clk_list_cnt = 109,
+   .clk_list_cnt = 110,
.soc_dev_clk_data = soc_dev_clk_data,
-   .soc_dev_clk_data_cnt = 129,
+   .soc_dev_clk_data_cnt = 132,
Can we think of using ARRAY_SIZE for these number clk_list_cnt and 
soc_dev_clk_data_cnt

  };

Re: [PATCH 06/14] fastboot: Change fastboot_buf_addr to an address

[Dmitrii Merkurev]

Verified this change with AOSP u-boot fastboot flashing tests and it works
as expected.

Reviewed-by: Dmitrii Merkurev 

On Mon, Dec 4, 2023 at 12:32 AM Simon Glass  wrote:

> Given the name of this variable, it should be an address, not a
> pointer. Update this, to make it easier to use with sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/fastboot.c|  2 +-
>  drivers/fastboot/fb_command.c | 13 -
>  drivers/fastboot/fb_common.c  | 15 ---
>  include/fastboot-internal.h   |  2 +-
>  include/fastboot.h|  6 +++---
>  5 files changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> index c3c19231c988..792e83d372c3 100644
> --- a/cmd/fastboot.c
> +++ b/cmd/fastboot.c
> @@ -159,7 +159,7 @@ NXTARG:
> return CMD_RET_USAGE;
> }
>
> -   fastboot_init((void *)buf_addr, buf_size);
> +   fastboot_init(buf_addr, buf_size);
>
> if (!strcmp(argv[1], "udp"))
> return do_fastboot_udp(argc, argv, buf_addr, buf_size);
> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
> index 5fcadcdf503d..ec030886dbb8 100644
> --- a/drivers/fastboot/fb_command.c
> +++ b/drivers/fastboot/fb_command.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -252,7 +253,7 @@ void fastboot_data_download(const void *fastboot_data,
> return;
> }
> /* Download data to fastboot_buf_addr */
> -   memcpy(fastboot_buf_addr + fastboot_bytes_received,
> +   memcpy(map_sysmem(fastboot_buf_addr, 0) + fastboot_bytes_received,
>fastboot_data, fastboot_data_len);
>
> pre_dot_num = fastboot_bytes_received / BYTES_PER_DOT;
> @@ -296,13 +297,15 @@ void fastboot_data_complete(char *response)
>   */
>  static void __maybe_unused flash(char *cmd_parameter, char *response)
>  {
> +   void *buf = map_sysmem(fastboot_buf_addr, 0);
> +
> if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_MMC))
> -   fastboot_mmc_flash_write(cmd_parameter, fastboot_buf_addr,
> -image_size, response);
> +   fastboot_mmc_flash_write(cmd_parameter, buf, image_size,
> +response);
>
> if (IS_ENABLED(CONFIG_FASTBOOT_FLASH_NAND))
> -   fastboot_nand_flash_write(cmd_parameter, fastboot_buf_addr,
> - image_size, response);
> +   fastboot_nand_flash_write(cmd_parameter, buf, image_size,
> + response);
>  }
>
>  /**
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 3576b0677299..07f5946d9ed1 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -20,7 +20,7 @@
>  /**
>   * fastboot_buf_addr - base address of the fastboot download buffer
>   */
> -void *fastboot_buf_addr;
> +ulong fastboot_buf_addr;
>
>  /**
>   * fastboot_buf_size - size of the fastboot download buffer
> @@ -154,7 +154,7 @@ void fastboot_boot(void)
> };
>
> snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
> -"0x%p", fastboot_buf_addr);
> +"%lx", fastboot_buf_addr);
> printf("Booting kernel at %s...\n\n\n", boot_addr_start);
>
> do_bootm(NULL, 0, 2, bootm_args);
> @@ -214,16 +214,9 @@ void fastboot_set_progress_callback(void
> (*progress)(const char *msg))
> fastboot_progress_callback = progress;
>  }
>
> -/*
> - * fastboot_init() - initialise new fastboot protocol session
> - *
> - * @buf_addr: Pointer to download buffer, or NULL for default
> - * @buf_size: Size of download buffer, or zero for default
> - */
> -void fastboot_init(void *buf_addr, u32 buf_size)
> +void fastboot_init(ulong buf_addr, u32 buf_size)
>  {
> -   fastboot_buf_addr = buf_addr ? buf_addr :
> -  (void *)CONFIG_FASTBOOT_BUF_ADDR;
> +   fastboot_buf_addr = buf_addr ? buf_addr : CONFIG_FASTBOOT_BUF_ADDR;
> fastboot_buf_size = buf_size ? buf_size : CONFIG_FASTBOOT_BUF_SIZE;
> fastboot_set_progress_callback(NULL);
>  }
> diff --git a/include/fastboot-internal.h b/include/fastboot-internal.h
> index bf2f2b3c8914..d3e1c106e23f 100644
> --- a/include/fastboot-internal.h
> +++ b/include/fastboot-internal.h
> @@ -6,7 +6,7 @@
>  /**
>   * fastboot_buf_addr - base address of the fastboot download buffer
>   */
> -extern void *fastboot_buf_addr;
> +extern ulong fastboot_buf_addr;
>
>  /**
>   * fastboot_buf_size - size of the fastboot download buffer
> diff --git a/include/fastboot.h b/include/fastboot.h
> index 296451f89d44..744ab61cc18a 100644
> --- a/include/fastboot.h
> +++ b/include/fastboot.h
> @@ -103,13 +103,13 @@ int fastboot_set_reboot_flag(enum
> fastboot_reboot_reason reason);
>   */
>  void 

Pull request efi-2024-01-rc5

[Heinrich Schuchardt]

Dear Tom,

The following changes since commit 2f0282922b2c458eea7f85c500a948a587437b63:

  Prepare v2024.01-rc4 (2023-12-04 13:46:56 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git 
tags/efi-2024-01-rc5


for you to fetch changes up to 6805b4dbad72a6e9180426c50f6db6e2681430c0:

  efi_loader: Make DisconnectController follow the EFI spec (2023-12-05 
01:38:56 +0100)


Gitlab CI did now show any issues:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/18800


Pull request efi-2024-01-rc5

Documentation:

* Update and correct support notes on clang
* sandbox: Fix VPL instructions

UEFI:

* Fix a bug in DisconnectController
* Provide better error messages for missing CONFIG_EFI_CAPSULE_ESL_FILE
* Create EFI memory reservations when booting via ACPI
* Make ACPI tables accessible in EFI app


Heinrich Schuchardt (1):
  efi_loader: create memory reservations in ACPI case

Ilias Apalodimas (1):
  efi_loader: Make DisconnectController follow the EFI spec

Masahisa Kojima (1):
  scripts/Makefile.lib: print error when no public key is specified

Mattijs Korpershoek (1):
  doc: sending_patches.rst: s/Superseeded/Superseded

Simon Glass (3):
  sandbox: Fix VPL instructions
  efi: Collect the ACPI tables in the app
  efi: Correct display of table GUIDs

Tom Rini (1):
  doc: clang: Update and correct support notes

 cmd/bootefi.c   | 25 +
 cmd/efi_common.c|  4 +---
 doc/arch/sandbox/sandbox.rst| 50 
++---

 doc/build/clang.rst | 22 +-
 doc/develop/sending_patches.rst |  4 ++--
 lib/efi/efi_app.c   | 24 +---
 lib/efi_loader/Makefile |  2 --
 lib/efi_loader/efi_boottime.c   | 27 +-
 scripts/Makefile.lib|  5 +
 9 files changed, 106 insertions(+), 57 deletions(-)The following changes since commit 2f0282922b2c458eea7f85c500a948a587437b63:

  Prepare v2024.01-rc4 (2023-12-04 13:46:56 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2024-01-rc5

for you to fetch changes up to 6805b4dbad72a6e9180426c50f6db6e2681430c0:

  efi_loader: Make DisconnectController follow the EFI spec (2023-12-05 
01:38:56 +0100)


Pull request efi-2024-01-rc5

Documentation:

* Update and correct support notes on clang
* sandbox: Fix VPL instructions

UEFI:

* Fix a bug in DisconnectController
* Provide better error messages for missing CONFIG_EFI_CAPSULE_ESL_FILE
* Create EFI memory reservations when booting via ACPI
* Make ACPI tables accessible in EFI app


Heinrich Schuchardt (1):
  efi_loader: create memory reservations in ACPI case

Ilias Apalodimas (1):
  efi_loader: Make DisconnectController follow the EFI spec

Masahisa Kojima (1):
  scripts/Makefile.lib: print error when no public key is specified

Mattijs Korpershoek (1):
  doc: sending_patches.rst: s/Superseeded/Superseded

Simon Glass (3):
  sandbox: Fix VPL instructions
  efi: Collect the ACPI tables in the app
  efi: Correct display of table GUIDs

Tom Rini (1):
  doc: clang: Update and correct support notes

 cmd/bootefi.c   | 25 +
 cmd/efi_common.c|  4 +---
 doc/arch/sandbox/sandbox.rst| 50 ++---
 doc/build/clang.rst | 22 +-
 doc/develop/sending_patches.rst |  4 ++--
 lib/efi/efi_app.c   | 24 +---
 lib/efi_loader/Makefile |  2 --
 lib/efi_loader/efi_boottime.c   | 27 +-
 scripts/Makefile.lib|  5 +
 9 files changed, 106 insertions(+), 57 deletions(-)

[PATCH 1/1] efi_loader: boot options should relate to the ESP

[Heinrich Schuchardt]

* Only generate removable media entries for EFI system partitions.
* Only offer EFI system partitions for boot options in the eficonfig
  command.

Fixes: c416f1c0bcab ("bootmenu: add removable media entries")
Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
Signed-off-by: Heinrich Schuchardt 
---
 cmd/eficonfig.c  | 6 --
 lib/efi_loader/efi_bootmgr.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 34a59cb15d..c066b28b6b 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -626,8 +626,10 @@ static efi_status_t eficonfig_select_volume(struct 
eficonfig_select_file_info *f
efi_handle_t *volume_handles = NULL;
struct efi_simple_file_system_protocol *v;
 
-   ret = efi_locate_handle_buffer_int(BY_PROTOCOL, 
_simple_file_system_protocol_guid,
-  NULL, , (efi_handle_t 
**)_handles);
+   /* Find all EFI system partitions */
+   ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
+  _system_partition_guid,
+  NULL, , _handles);
if (ret != EFI_SUCCESS) {
eficonfig_print_msg("No block device found!");
return ret;
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 48153bd5ff..9e84391186 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -1047,8 +1047,9 @@ efi_status_t 
efi_bootmgr_update_media_device_boot_option(void)
efi_handle_t *volume_handles = NULL;
struct eficonfig_media_boot_option *opt = NULL;
 
+   /* Find all EFI system partitions */
ret = efi_locate_handle_buffer_int(BY_PROTOCOL,
-  
_simple_file_system_protocol_guid,
+  _system_partition_guid,
   NULL, ,
   (efi_handle_t **)_handles);
if (ret != EFI_SUCCESS)
-- 
2.40.1

[PATCH] sunxi: dts: arm64: update emac for Orange Pi Zero 3

[Andre Przywara]

From: Chukun Pan 

The current emac setting is not suitable for Orange Pi Zero 3,
move it back to Orange Pi Zero 2 DT. Also update phy mode and
delay values for emac on Orange Pi Zero 3.
With these changes, Ethernet now looks stable.

Fixes: 95c3b0635ea4 ("sunxi: dts: arm64: update devicetree files from 
Linux-v6.6-rc6")
Signed-off-by: Chukun Pan 
Reviewed-by: Jernej Skrabec 
---
Hi,

this is a port of the corresponding Linux patch, that fixes Ethernet
on that board. The patch is in Linux' sunxi/fixes-for-6.7 queue,
awaiting a merge anytime soon.
For me this indeed fixes Ethernet operation in U-Boot on that board.

Cheers,
Andre

 arch/arm/dts/sun50i-h616-orangepi-zero.dtsi | 3 ---
 arch/arm/dts/sun50i-h616-orangepi-zero2.dts | 3 +++
 arch/arm/dts/sun50i-h618-orangepi-zero3.dts | 2 ++
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/sun50i-h616-orangepi-zero.dtsi 
b/arch/arm/dts/sun50i-h616-orangepi-zero.dtsi
index 15290e6892f..fc7315b9440 100644
--- a/arch/arm/dts/sun50i-h616-orangepi-zero.dtsi
+++ b/arch/arm/dts/sun50i-h616-orangepi-zero.dtsi
@@ -68,10 +68,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_rgmii_pins>;
-   phy-mode = "rgmii";
phy-handle = <_rgmii_phy>;
-   allwinner,rx-delay-ps = <3100>;
-   allwinner,tx-delay-ps = <700>;
status = "okay";
 };
 
diff --git a/arch/arm/dts/sun50i-h616-orangepi-zero2.dts 
b/arch/arm/dts/sun50i-h616-orangepi-zero2.dts
index d83852e72f0..b5d713926a3 100644
--- a/arch/arm/dts/sun50i-h616-orangepi-zero2.dts
+++ b/arch/arm/dts/sun50i-h616-orangepi-zero2.dts
@@ -13,6 +13,9 @@
 };
 
  {
+   allwinner,rx-delay-ps = <3100>;
+   allwinner,tx-delay-ps = <700>;
+   phy-mode = "rgmii";
phy-supply = <_dcdce>;
 };
 
diff --git a/arch/arm/dts/sun50i-h618-orangepi-zero3.dts 
b/arch/arm/dts/sun50i-h618-orangepi-zero3.dts
index 00fe28caac9..b3b1b869212 100644
--- a/arch/arm/dts/sun50i-h618-orangepi-zero3.dts
+++ b/arch/arm/dts/sun50i-h618-orangepi-zero3.dts
@@ -13,6 +13,8 @@
 };
 
  {
+   allwinner,tx-delay-ps = <700>;
+   phy-mode = "rgmii-rxid";
phy-supply = <_dldo1>;
 };
 
-- 
2.35.8

Re: [PATCH v2 17/18] qemu-arm: Get bloblist from boot arguments

[Simon Glass]

Hi Raymond,

On Mon, 4 Dec 2023 at 13:06, Raymond Mao  wrote:
>
> Hi Simon
>
> On Sat, 2 Dec 2023 at 16:16, Simon Glass  wrote:
>>
>> Hi Raymond,
>>
>> On Mon, 27 Nov 2023 at 12:53, Raymond Mao  wrote:
>> >
>> > Add platform custom function to get bloblist from boot arguments.
>>
>> This should be the same for all ARM platforms. The ultimate goal is
>> something like [1]
>
> Yes, I agree. The current series just focuses on Qemu but ultimately should 
> be adapted
> to all Arm platforms.
>
>> >  #include 
>> > +#if IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST)
>> > +#include 
>> > +#endif
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -102,6 +105,16 @@ static struct mm_region qemu_arm64_mem_map[] = {
>> >  struct mm_region *mem_map = qemu_arm64_mem_map;
>> >  #endif
>> >
>> > +#if IS_ENABLED(CONFIG_OF_BOARD)
>>
>> OF_BLOBLIST and please avoid #if
>
> I will remove the build option for argument copying, as they don't really 
> depend on OF_BOARD
> or _BLOBLIST.
>
>>
>> > +   /* Check the register conventions */
>> > +   fdt = (unsigned long)bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
>>
>> This should happen in fdtdec.c automatically. See [2]
>
> The reason I have to call `bloblist_find()` here is to get the fdt address 
> and compare with
> arg0 and arg2 (see below few lines of code) to check if it is compliant to 
> the register conventions
> for AARCH64/32 defined by the FW Handoff spec.
> This is better to be placed here instead of fdtdec.c

We should first sort out what we are doing with my patch...as
mentioned elsewhere Ilias and I did discuss it, but perhaps not for
long enough.

Regards,
Simon

Re: [PATCH v2 18/18] bloblist: Load the bloblist from the previous loader

[Simon Glass]

Hi Raymond,

On Mon, 4 Dec 2023 at 13:21, Raymond Mao  wrote:
>
> Hi Simon,
>
> On Sat, 2 Dec 2023 at 13:32, Simon Glass  wrote:
>>
>> Hi Raymond,
>>
>> On Mon, 27 Nov 2023 at 12:53, Raymond Mao  wrote:
>> >
>> > During bloblist initialization, when CONFIG_OF_BOARD is defined,
>> > invoke the platform custom function to load the bloblist via boot
>> > arguments from the previous loader.
>> > If the bloblist exists, copy it into the fixed bloblist memory region.
>> >
>> > Signed-off-by: Raymond Mao 
>> > ---
>> > Changes in v2
>> > - New patch file created for v2.
>> >
>> >  common/bloblist.c  | 29 +
>> >  include/bloblist.h | 14 ++
>> >  2 files changed, 27 insertions(+), 16 deletions(-)
>> >
>>
>> This should already work so I am hoping that this patch is not
>> needed...these changes seem to break sandbox_spl
>
> By "already work", do you mean any existing patches already done for loading 
> the
> bloblist from the boot args?

No it doesn't have that. But we need to figure out [1]. I have marked
in 'new' in patchwork.

Regards,
Simon

[1] 
https://patchwork.ozlabs.org/project/uboot/patch/20230926141514.2101787-40-...@chromium.org/

Re: EFI memory allocation

[Simon Glass]

Hi Ilias,

On Mon, 4 Dec 2023 at 05:05, Ilias Apalodimas
 wrote:
>
> Hi Simon
>
> On Sun, 3 Dec 2023 at 19:44, Simon Glass  wrote:
> >
> > Hi Heinrich, Ilias,
> >
> > I had a bit of a look at how memory is allocated in EFI.
> >
> > I see that efi_memory_init() is called quite early in U-Boot. It
> > sometimes allocates memory for a bounce buffer, placing it somewhere
> > in memory. How do we know that that memory is free and not being used
> > by U-Boot?
> >
> > To answer my own question, it excludes U-Boot's malloc() region from
> > the map, so that it cannot overwrite that.
> >
> > But then, what if we use lmb and start loading images into memory.
> > Won't that conflict with EFI?
>
> Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and

OK, that looks very odd to me.

> we have a 'todo' in the efi subsystem for a few years now [0]
> Michal (+cc'ed) has also pinged me for similar issues in the past.
>
> >
> > I also see that efi_allocate_pages() is called to allocate memory in
> > the EFI code. But this just grabs memory from 'anywhere'...it doesn't
> > respect the U-Boot malloc region.
> >
> > It seems to me that most of the memory allocation in EFI should be
> > done using malloc(). Of course the boot services need to
> > efi_allocate_pages(), etc., but I am not sure that the internal tables
> > should be skipping malloc()?
> >
> > What do you think?
>
> I think that LMB, EFI and the whole memory reservations is a bit of a
> mess. Tom and I discussed this a bit in the past but I'll start
> working on it.
> It needs fixing, but without looking at the code first, I can't
> provide any useful feedback
>
> [0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2

OK I mad a comment there. We should figure out a design before going ahead.

Regards,
Simon

Re: [PATCH 00/21] Qualcomm generic board support

[Simon Glass]

Hi Sumit,

On Tue, 21 Nov 2023 at 23:21, Sumit Garg  wrote:
>
> Hi Caleb,
>
> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly  
> wrote:
> >
> > Historically, Qualcomm boards in U-Boot have all had their own
> > board/qualcomm/xyz directory, their own CONFIG_TARGET_XYZ option, their
> > own hardcoded sysmap-xyz.c file, and their own U-Boot specific
> > devicetree with little/no compatibility with upstream DT.
> >
> > This series makes a few final prepatory changes, and then replaces
> > almost all of the board specific code with generic alternatives. The end
> > result is that all Qualcomm boards both current and future (with the
> > exception of the db410c and db820c) can be supported by a single U-Boot
> > binary by just providing the correct DT. New boards can be added without
> > introducing any addition mach/ or board/ code or config options.
> >
> > Due to the nature of this change, the patch ("mach-snapdragon:
> > generalise board support") has become pretty big, I tried a few
> > different ways to represent this in git history, but the other methods
> > (e.g. adding a stub "generic" target and removing it again) were more
> > confusing and made for much messier git history. The current patch is
> > mostly atomic, but requires regenerating the config.
> >
> > The QCS404 EVB board had some code to enable the USB VBUS regulator,
> > this is dropped in favour of a adding a new vbus-supply property to the
> > dwc3-generic driver. This will also be used by the dragonboard845c in a
> > future patch. This handles the common case of a board requiring some
> > regulator be enabled for USB host mode.
> >
>
> Thanks for your work. It is a good step towards a generalized u-boot
> on Qcom platforms. Although I would like to give it an in-depth
> review, I have a common discussion point about DT, see below.
>
> > A more detailed description of the changes is below.
> >
> > == Memory map ==
> >
> > The memory map was historically hardcoded into U-Boot, this meant that
> > U-Boot had to be built for a specific variant of a device. This is
> > changed to instead read the memory map from the DT /memory node.
> >
> > Additionally, most boards mapped addresss 0x0 as valid, as a result if a
> > null pointer access happens then it will cause a bus stall (and board
> > hang). This is fixed so that null pointer accesses will now correctly
> > throw an exception.
> >
> > == DT loading ==
> >
> > Previously, boards used the FDT blob embedded into U-Boot (via
> > OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
> > bootloader, so we can instead rely on the first-stage bootloader to
> > populate some useful FDT properties for us (notably the /memory node and
> > KASLR seed) and fetch the DTB that it provides. Combined with the memory
> > map changes above, this let's us entirely avoid configuring the memory
> > map explicitly.
>
> Since with this change, we don't need to embed FDT blob in the u-boot
> binary, so I was thinking if we really need to import DTs from Linux
> for different platforms and then play a catchup game?
>
> IMO, the build command would look like following if we import
> pre-built FDT blob from Linux:
>
> - Build u-boot::
>
>$ export CROSS_COMPILE=
>$ make qcom_defconfig
>$ make
>
> - gzip u-boot::
>
>gzip u-boot-nodtb.bin
>
> - Append dtb to gzipped u-boot::
>
> cat u-boot-nodtb.bin.gz
> /arch/arm64/boot/dts/qcom/your-board.dtb >
> u-boot-nodtb.bin.gz-dtb

What is this?? Who or what uses a gzipped image with a single DT attached?

>
> This would avoid the maintenance burden to keep DT in sync with that
> of Linux. And since DT bindings in Linux are backwards compatible, we
> can say u-boot should work with DTB picked up from any Linux kernel
> stable release.

That is not the current situation, unfortunately.

U-Boot is moving to using Binman to package the firmware. There needs
to be a description of the firmware image for each U-Boot boot. To my
way of thinking, rpi is a degenerate form, not something to be copied,
due to the closed-source nature of the firmware and its inability to
be changed. We do have (in the works) a way to pass a DT using a
standard firmware handoff. Perhaps that can be adopted by these
closed-source projects?

BTW I am very pleased to see this series and I hope that Qualcomm (via
Linaro) can continue to improve its U-Boot support.

[..]

Regards,
Simon

Re: [PATCH v2 15/18] fdt: Allow the devicetree to come from a bloblist

[Simon Glass]

Hi Raymond,

On Mon, 4 Dec 2023 at 12:25, Raymond Mao  wrote:
>
> Hi Simon,
>
> When `OF_BOARD` is defined, the FDT should be from one of  the board-specific 
> mechanisms:
> 1. FDT from a bloblist via boot args
> 2. FDT in memory
> I don't think we need a new build option to distinguish these two, since it 
> can be done in runtime by checking whether the boot args follow the FW 
> Handoff spec conventions and the FDT exists in the bloblist.

No, I would really like this to be deterministic, so we can fail if
something goes wrong. The bloblist should be 'declared' as the way to
boot, for a board.

If in the future all boards a reusing bloblist for this feature, then
sure, we can drop it. But we have things like rpi which do their own
thing.

> If it fulfills the above conditions, we can take the FDT from bloblist, 
> otherwise from the predefined memory address.
> This is fully backward compatible without adding a new build option.

Again, we need to obtain the FDT from the bloblist if and only if the
board requires it. It creates a lot of confusion to have it as an
optional feature, when we know which way it should be.

Ultimately OF_BOARD should go away. We just need to push bloblist to
other projects and closed-source firmware as the correct way to pass a
DT.

Regards,
Simon
[.]

Re: [PATCH v2 12/18] bloblist: Reduce bloblist header size

[Simon Glass]

Hi,

On Mon, 4 Dec 2023 at 01:39, Ilias Apalodimas
 wrote:
>
> Ah I guess this fixes my concerns on patch #6
>
> On Mon, 27 Nov 2023 at 21:53, Raymond Mao  wrote:
> >
> > From: Simon Glass 
> >
> > The v0.9 spec provides for a 16-byte header with fewer fields. Update
> > the implementation to match this.
> >
> > This also adds an alignment field.
> >
> > Signed-off-by: Simon Glass 
> > Signed-off-by: Raymond Mao 
> > ---
> >  include/bloblist.h | 26 +-
> >  test/bloblist.c|  6 +++---
> >  2 files changed, 16 insertions(+), 16 deletions(-)
>
>
>
>
> >
> > diff --git a/include/bloblist.h b/include/bloblist.h
> > index 745bcdd227..57625ea004 100644
> > --- a/include/bloblist.h
> > +++ b/include/bloblist.h
> > @@ -164,30 +164,30 @@ enum bloblist_tag_t {
> >   * from the last.
> >   *
> >   * @magic: BLOBLIST_MAGIC
> > + * @chksum: checksum for the entire bloblist allocated area. Since any of 
> > the
> > + * blobs can be altered after being created, this checksum is only 
> > valid
> > + * when the bloblist is finalised before jumping to the next stage of 
> > boot.
> > + * This is the value needed to make all chechksummed bytes sum to 0
>
> typos checksummed and finalized

finalised is correct

>
> [...]
>
> With the typos fixed
>
> Reviewed-by: Ilias Apalodimas 

REgards,
Simon

Re: [PATCH 05/18] treewide: bootm: Drop command-line args to boot_os_fn

[Simon Glass]

Hi Angelo,

On Tue, 5 Dec 2023 at 08:01, Angelo Dureghello  wrote:
>
> Hi Simon,
>
> looks like i cannot apply this patch:
>
>      ~/dev-k/u-boot-coldfire  on   master *2  git am
> Complete-decoupling-of-bootm-logic-from-commands.patch
> Applying: bootm: netbds: Drop passing of arguments
> Applying: bootm: plan: Drop passing of arguments
> Applying: bootm: qnxelf: Drop passing of arguments
> Applying: nios2: Drop separate parsing of bootm args
> Applying: treewide: bootm: Drop command-line args to boot_os_fn
> error: patch failed: boot/bootm_os.c:441
> error: boot/bootm_os.c: patch does not apply
> Patch failed at 0005 treewide: bootm: Drop command-line args to boot_os_fn
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
>
> And getting similar issues for the "pxe: Allow extlinux booting without
> CMDLINE enabled"
>
> Am i doing something wrong ?

Could you please check the cover letter? There are several series here
and I put the -dm tree links in as well.

I was keeping these to send in sequence, but it would likely take
several releases that way, so I elected to send everything at once and
get feedback.

Regards,
SmIon

Re: [PATCH v4 0/4] bootflow: bootmeth_efi: Fix network efi boot.

[Simon Glass]

Hi Shantur,

On Mon, 4 Dec 2023 at 05:38, Shantur Rathore  wrote:
>
> Hi Simon,
>
> On Sun, Nov 19, 2023 at 4:56 PM Shantur Rathore  wrote:
> >
> >
> > Currently bootmeth_efi crashes while doing a network (dhcp) boot.
> > This patch series fixes issues and both network and disk boot works.
> >
> How can I help to get this patch series merged in?

You can check patchwork [1] to see who it is assigned to. I don't see
it in my queue though.

Regards,
Simon

[1]

Re: [PATCH v4 4/5] lib: membuff: fix readline not returning line in case of overflow

[Simon Glass]

Hi Svyatoslav,

On Thu, 23 Nov 2023 at 04:02, Svyatoslav Ryhel  wrote:
>
> From: Ion Agorria 
>
> If a line overflows readline's maxlen it won't advance the membuffer
> and will return 0 as read amount which isn't even documented.
> Fix by removing this behavior alltogether.

spelling

But then how does one know the whole line has been read?

I don't think this is a good idea. We need to return some sort of
error condition.

I suggest either:

1. Add a new function which reads a line up to maxlen and discards
anything after that
2. returning -1 in the case that the line was too long, then having
the caller call a new membuff_skipline() function to skip it (which
supports any length)


>
> Signed-off-by: Ion Agorria 
> Signed-off-by: Svyatoslav Ryhel 
> Reviewed-by: Mattijs Korpershoek 
> ---
>  lib/membuff.c | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/lib/membuff.c b/lib/membuff.c
> index 36dc43a523..f582193dcd 100644
> --- a/lib/membuff.c
> +++ b/lib/membuff.c
> @@ -292,15 +292,12 @@ int membuff_readline(struct membuff *mb, char *str, int 
> maxlen, int minch)
>  {
> int len;  /* number of bytes read (!= string length) */
> char *s, *end;
> -   bool ok = false;
> -   char *orig = str;
>
> end = mb->head >= mb->tail ? mb->head : mb->end;
> for (len = 0, s = mb->tail; s < end && len < maxlen - 1; str++) {
> *str = *s++;
> len++;
> if (*str == '\n' || *str < minch) {
> -   ok = true;
> break;
> }
> if (s == end && mb->tail > mb->head) {
> @@ -309,13 +306,6 @@ int membuff_readline(struct membuff *mb, char *str, int 
> maxlen, int minch)
> }
> }
>
> -   /* couldn't get the whole string */
> -   if (!ok) {
> -   if (maxlen)
> -   *orig = '\0';
> -   return 0;
> -   }
> -
> /* terminate the string, update the membuff and return success */
> *str = '\0';
> mb->tail = s == mb->end ? mb->start : s;
> --
> 2.40.1
>

[PATCH 3/4] mailbox: zynqmp: support mulitple mboxes via device-tree

[Tanmay Shah]

As of now only one mailbox agent is supported by mailbox driver.
On zynqmp platform there are about 7 mailbox agents which can communicate
over same IPI channel to U-Boot. This patch series introduces new
"zynqmp_ipi_dest" driver which adds one to multi-channel mailbox
support.

Following format in device-tree is expected as per latest bindings:
zynqmp-ipi {
compatible = "xlnx,zynqmp-ipi-mailbox";

mbox_1: mailbox@1 {
/* New compatible for child node */
compatible = "xlnx,zynqmp-ipi-dest-mailbox";
...
};

...

mbox_n: mailbox@n {
compatible = "xlnx,zynqmp-ipi-dest-mailbox";
...
}
};

Then mailbox client uses child mailbox node as following:

ipi-dest-1 {
...
mboxes = , ;
mbox-names = "tx", "rx";
...
};

New "zynqmp_ipi_dest" driver is for devices with
"xlnx,zynqmp-ipi-dest-mailbox" compatible string. This driver will take care
of mailbox send recv ops and it replaces previous "zynqmp_ipi" driver.
Now "zynqmp_ipi" driver simply binds each child device with "zynqmp_ipi_dest"
driver.

However, its important to maintain backward comaptibility with previous
bindings where child node does not have compatible string. In such case, new
driver isn't probed by U-Boot during boot and system fails to boot. To
resolve this issue firmware-zynqmp.c driver probes all the IPI parent node
driver which binds each child node device with "zynqmp_ipi_dest" driver.

This makes sure corresponding child driver will be
probed when requested using mbox_get_by_name or mbox_get_by_idx
framework calls.

This way multiple mailbox agents are supported in device-tree without breaking
previous binding support.

Signed-off-by: Tanmay Shah 
---
 drivers/firmware/firmware-zynqmp.c | 22 ++
 drivers/mailbox/zynqmp-ipi.c   | 65 --
 2 files changed, 74 insertions(+), 13 deletions(-)

diff --git a/drivers/firmware/firmware-zynqmp.c 
b/drivers/firmware/firmware-zynqmp.c
index 8ea15c7ed3..dfad798a2e 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -290,10 +291,31 @@ int zynqmp_pmufw_load_config_object(const void *cfg_obj, 
size_t size)
 
 static int zynqmp_power_probe(struct udevice *dev)
 {
+   struct udevice *ipi_dev;
+   ofnode ipi_node;
int ret;
 
debug("%s, (dev=%p)\n", __func__, dev);
 
+   /*
+* Probe all IPI parent node driver. It is important to have IPI
+* devices available when requested by mbox_get_by* API.
+* If IPI device isn't available, then mailbox request fails and
+* that causes system boot failure.
+* To avoid this make sure all IPI parent drivers are probed here,
+* and IPI parent driver binds each child node to mailbox driver.
+* This way mbox_get_by_* API will have correct mailbox device
+* driver probed.
+*/
+   ofnode_for_each_compatible_node(ipi_node, "xlnx,zynqmp-ipi-mailbox") {
+   ret = uclass_get_device_by_ofnode(UCLASS_NOP, ipi_node, 
_dev);
+   if (ret) {
+   dev_err(dev, "failed to get IPI device from node %s\n",
+   ofnode_get_name(ipi_node));
+   return ret;
+   }
+   }
+
ret = mbox_get_by_name(dev, "tx", _power.tx_chan);
if (ret) {
debug("%s: Cannot find tx mailbox\n", __func__);
diff --git a/drivers/mailbox/zynqmp-ipi.c b/drivers/mailbox/zynqmp-ipi.c
index e76561f310..eb86847bbe 100644
--- a/drivers/mailbox/zynqmp-ipi.c
+++ b/drivers/mailbox/zynqmp-ipi.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -157,7 +158,7 @@ static int zynqmp_ipi_recv(struct mbox_chan *chan, void 
*data)
return ret;
 };
 
-static int zynqmp_ipi_probe(struct udevice *dev)
+static int zynqmp_ipi_dest_probe(struct udevice *dev)
 {
struct zynqmp_ipi *zynqmp = dev_get_priv(dev);
struct resource res;
@@ -166,14 +167,12 @@ static int zynqmp_ipi_probe(struct udevice *dev)
 
debug("%s(dev=%p)\n", __func__, dev);
 
+   node = dev_ofnode(dev);
+
if (IS_ENABLED(CONFIG_SPL_BUILD) || 
of_machine_is_compatible("xlnx,zynqmp"))
zynqmp->el3_supported = true;
 
-   /* Get subnode where the regs are defined */
-   /* Note IPI mailbox node needs to be the first one in DT */
-   node = ofnode_first_subnode(dev_ofnode(dev));
-
-   ret = dev_read_u32(dev, "xlnx,ipi-id", >local_id);
+   ret = dev_read_u32(dev->parent, "xlnx,ipi-id", >local_id);
if (ret) {
dev_err(dev, "can't get local ipi id\n");
return ret;
@@ -191,6 +190,8 @@ static int zynqmp_ipi_probe(struct udevice *dev)
};
zynqmp->local_req_regs = 

[PATCH 4/4] dts: zynqmp: add missing destination mailbox compatible

[Tanmay Shah]

The commit in linux kernel 81186dc16101 ("dt-bindings: zynqmp: add
destination mailbox compatible") make compatible string for child nodes
mandatory that's why add it.

Signed-off-by: Tanmay Shah 
---
 arch/arm/dts/zynqmp.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 58a56bc1bd..21be909b1a 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -148,6 +148,7 @@
 
ipi_mailbox_pmu1: mailbox@ff9905c0 {
bootph-all;
+   compatible = "xlnx,zynqmp-ipi-dest-mailbox";
reg = <0x0 0xff9905c0 0x0 0x20>,
  <0x0 0xff9905e0 0x0 0x20>,
  <0x0 0xff990e80 0x0 0x20>,
-- 
2.25.1

[PATCH 2/4] mailbox: add el3 support only for zynqmp platform

[Tanmay Shah]

If U-Boot is running in Exception Level 3 then use hardcode
register values for mailbox message passing with PMU.
This is only supported for zynqmp platform.

Signed-off-by: Tanmay Shah 
---
 drivers/mailbox/zynqmp-ipi.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mailbox/zynqmp-ipi.c b/drivers/mailbox/zynqmp-ipi.c
index acd0b287db..e76561f310 100644
--- a/drivers/mailbox/zynqmp-ipi.c
+++ b/drivers/mailbox/zynqmp-ipi.c
@@ -81,6 +81,7 @@ struct zynqmp_ipi {
void __iomem *remote_res_regs;
u32 remote_id;
u32 local_id;
+   bool el3_supported;
 };
 
 static int zynqmp_ipi_fw_call(struct zynqmp_ipi *ipi_mbox,
@@ -115,6 +116,12 @@ static int zynqmp_ipi_send(struct mbox_chan *chan, const 
void *data)
return ret;
}
 
+   /* Return if EL3 is not supported */
+   if (!zynqmp->el3_supported) {
+   dev_err(chan->dev, "mailbox in EL3 only supported for zynqmp");
+   return -EOPNOTSUPP;
+   }
+
/* Write trigger interrupt */
writel(IPI_BIT_MASK_PMU0, _int_apu->trig);
 
@@ -159,6 +166,9 @@ static int zynqmp_ipi_probe(struct udevice *dev)
 
debug("%s(dev=%p)\n", __func__, dev);
 
+   if (IS_ENABLED(CONFIG_SPL_BUILD) || 
of_machine_is_compatible("xlnx,zynqmp"))
+   zynqmp->el3_supported = true;
+
/* Get subnode where the regs are defined */
/* Note IPI mailbox node needs to be the first one in DT */
node = ofnode_first_subnode(dev_ofnode(dev));
-- 
2.25.1

[PATCH 0/4] mailbox: zynqmp: support multiple child nodes

[Tanmay Shah]

Current zynqmp_ipi driver is hardcoded to work with only PMU
mailbox node.

This patch series adds new driver "zynqmp_ipi_dest" to support
multiple child node of current "zynqmp-ipi-mailbox" node. It
also adds support of SMC calls to TF-A to configure IPI
register address space.

New driver uses compatible property recently introduced for each
child mailbox node. However it is important to maintain backward
compatibility for old dts. Previous driver now binds each child
node to "zynqmp_ipi_dest" driver which is needed to maintain
backward compatibility.

Tanmay Shah (4):
  mailbox: zynqmp: support smc calls to TF-A
  mailbox: add el3 support only for zynqmp platform
  mailbox: zynqmp: support mulitple mboxes via device-tree
  dts: zynqmp: add missing destination mailbox compatible

 arch/arm/dts/zynqmp.dtsi   |   1 +
 drivers/firmware/firmware-zynqmp.c |  22 
 drivers/mailbox/zynqmp-ipi.c   | 159 ++---
 3 files changed, 169 insertions(+), 13 deletions(-)

base-commit: 5c4e9d0c74a8c2f8d0f4e0ab9cf44959298c2bad
-- 
2.25.1

[PATCH 1/4] mailbox: zynqmp: support smc calls to TF-A

[Tanmay Shah]

Use SMC calls to TF-A to operate IPI for execution level below 3. For
EL3 use hardcode IPI registers as TF-A isn't available in EL3.
Hence, in EL3 remote and local IPI ids retrieved using xlnx,ipi-id
property are unused.

Signed-off-by: Tanmay Shah 
---
 drivers/mailbox/zynqmp-ipi.c | 88 +++-
 1 file changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/mailbox/zynqmp-ipi.c b/drivers/mailbox/zynqmp-ipi.c
index 3e4ec47389..acd0b287db 100644
--- a/drivers/mailbox/zynqmp-ipi.c
+++ b/drivers/mailbox/zynqmp-ipi.c
@@ -8,9 +8,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +24,43 @@
 #define IPI_BIT_MASK_PMU0 0x1
 #define IPI_INT_REG_BASE_APU  0xFF30
 
+/* IPI agent ID any */
+#define IPI_ID_ANY 0xFFUL
+
+/* indicate if ZynqMP IPI mailbox driver uses SMC calls or HVC calls */
+#define USE_SMC 0
+
+/* Default IPI SMC function IDs */
+#define SMC_IPI_MAILBOX_OPEN   0x82001000U
+#define SMC_IPI_MAILBOX_RELEASE0x82001001U
+#define SMC_IPI_MAILBOX_STATUS_ENQUIRY 0x82001002U
+#define SMC_IPI_MAILBOX_NOTIFY 0x82001003U
+#define SMC_IPI_MAILBOX_ACK0x82001004U
+#define SMC_IPI_MAILBOX_ENABLE_IRQ 0x82001005U
+#define SMC_IPI_MAILBOX_DISABLE_IRQ0x82001006U
+
+/* IPI SMC Macros */
+
+/*
+ * Flag to indicate if notification interrupt
+ * to be disabled.
+ */
+#define IPI_SMC_ENQUIRY_DIRQ_MASK  BIT(0)
+
+/*
+ * Flag to indicate if notification interrupt
+ * to be enabled.
+ */
+#define IPI_SMC_ACK_EIRQ_MASK  BIT(0)
+
+/* IPI mailbox status */
+#define IPI_MB_STATUS_IDLE 0
+#define IPI_MB_STATUS_SEND_PENDING 1
+#define IPI_MB_STATUS_RECV_PENDING 2
+
+#define IPI_MB_CHNL_TX 0 /* IPI mailbox TX channel */
+#define IPI_MB_CHNL_RX 1 /* IPI mailbox RX channel */
+
 struct ipi_int_regs {
u32 trig; /* 0x0  */
u32 obs;  /* 0x4  */
@@ -39,8 +79,23 @@ struct zynqmp_ipi {
void __iomem *local_res_regs;
void __iomem *remote_req_regs;
void __iomem *remote_res_regs;
+   u32 remote_id;
+   u32 local_id;
 };
 
+static int zynqmp_ipi_fw_call(struct zynqmp_ipi *ipi_mbox,
+ unsigned long a0, unsigned long a3)
+{
+   struct arm_smccc_res res = {0};
+   unsigned long a1, a2;
+
+   a1 = ipi_mbox->local_id;
+   a2 = ipi_mbox->remote_id;
+   arm_smccc_smc(a0, a1, a2, a3, 0, 0, 0, 0, );
+
+   return (int)res.a0;
+}
+
 static int zynqmp_ipi_send(struct mbox_chan *chan, const void *data)
 {
const struct zynqmp_ipi_msg *msg = (struct zynqmp_ipi_msg *)data;
@@ -51,6 +106,15 @@ static int zynqmp_ipi_send(struct mbox_chan *chan, const 
void *data)
for (size_t i = 0; i < msg->len; i++)
writel(msg->buf[i], [i]);
 
+   /* Use SMC calls for Exception Level less than 3 where TF-A is 
available */
+   if (!IS_ENABLED(CONFIG_SPL_BUILD) && current_el() < 3) {
+   ret = zynqmp_ipi_fw_call(zynqmp, SMC_IPI_MAILBOX_NOTIFY, 0);
+
+   debug("%s, send %ld bytes\n", __func__, msg->len);
+
+   return ret;
+   }
+
/* Write trigger interrupt */
writel(IPI_BIT_MASK_PMU0, _int_apu->trig);
 
@@ -67,16 +131,23 @@ static int zynqmp_ipi_recv(struct mbox_chan *chan, void 
*data)
struct zynqmp_ipi_msg *msg = (struct zynqmp_ipi_msg *)data;
struct zynqmp_ipi *zynqmp = dev_get_priv(chan->dev);
u32 *mbx = (u32 *)zynqmp->local_res_regs;
+   int ret = 0;
 
/*
 * PMU Firmware does not trigger IPI interrupt for API call responses so
-* there is no need to check ISR flags
+* there is no need to check ISR flags for EL3.
 */
for (size_t i = 0; i < msg->len; i++)
msg->buf[i] = readl([i]);
 
+   /* Ack to remote if EL is not 3 */
+   if (!IS_ENABLED(CONFIG_SPL_BUILD) && current_el() < 3) {
+   ret = zynqmp_ipi_fw_call(zynqmp, SMC_IPI_MAILBOX_ACK,
+IPI_SMC_ACK_EIRQ_MASK);
+   }
+
debug("%s, recv %ld bytes\n", __func__, msg->len);
-   return 0;
+   return ret;
 };
 
 static int zynqmp_ipi_probe(struct udevice *dev)
@@ -84,6 +155,7 @@ static int zynqmp_ipi_probe(struct udevice *dev)
struct zynqmp_ipi *zynqmp = dev_get_priv(dev);
struct resource res;
ofnode node;
+   int ret;
 
debug("%s(dev=%p)\n", __func__, dev);
 
@@ -91,6 +163,18 @@ static int zynqmp_ipi_probe(struct udevice *dev)
/* Note IPI mailbox node needs to be the first one in DT */
node = ofnode_first_subnode(dev_ofnode(dev));
 
+   ret = dev_read_u32(dev, "xlnx,ipi-id", >local_id);
+   if (ret) {
+   dev_err(dev, "can't get local ipi id\n");
+   return ret;
+   }
+
+   ret = ofnode_read_u32(node, "xlnx,ipi-id", >remote_id);
+   if (ret) {
+

Re: [PATCH v1] mtd: rawnand: Meson NAND controller support

[Michael Nazzareno Trimarchi]

Hi Arseniy

Il lun 4 dic 2023, 20:31 Arseniy Krasnov  ha
scritto:

> cc: Miquel Raynal
>
> On 30.11.2023 14:21, Arseniy Krasnov wrote:
> > Basic support for Amlogic Meson NAND controller on AXG.
> >
> > Signed-off-by: Arseniy Krasnov 
> > ---
>


We are going to review your patches. It will be done this week

Michael

>  drivers/mtd/nand/raw/Kconfig  |9 +
> >  drivers/mtd/nand/raw/Makefile |1 +
> >  drivers/mtd/nand/raw/meson_nand.c | 1231 +
> >  3 files changed, 1241 insertions(+)
> >  create mode 100644 drivers/mtd/nand/raw/meson_nand.c
> >
> > diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> > index d624589a89..7b7b0226ab 100644
> > --- a/drivers/mtd/nand/raw/Kconfig
> > +++ b/drivers/mtd/nand/raw/Kconfig
> > @@ -488,6 +488,15 @@ config NAND_ARASAN
> > controller. This uses the hardware ECC for read and
> > write operations.
> >
> > +config NAND_MESON
> > + bool "Meson NAND support"
> > + select SYS_NAND_SELF_INIT
> > + depends on DM_MTD && ARCH_MESON
> > + imply CMD_NAND
> > + help
> > +   This enables Nand driver support for Meson raw NAND flash
> > +   controller.
> > +
> >  config NAND_MXC
> >   bool "MXC NAND support"
> >   depends on CPU_ARM926EJS || CPU_ARM1136 || MX5
> > diff --git a/drivers/mtd/nand/raw/Makefile
> b/drivers/mtd/nand/raw/Makefile
> > index add2b4cf65..5b4efd52c9 100644
> > --- a/drivers/mtd/nand/raw/Makefile
> > +++ b/drivers/mtd/nand/raw/Makefile
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
> >  obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o
> >  obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o
> >  obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o
> > +obj-$(CONFIG_NAND_MESON) += meson_nand.o
> >  obj-$(CONFIG_NAND_MXC) += mxc_nand.o
> >  obj-$(CONFIG_NAND_MXS) += mxs_nand.o
> >  obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o
> > diff --git a/drivers/mtd/nand/raw/meson_nand.c
> b/drivers/mtd/nand/raw/meson_nand.c
> > new file mode 100644
> > index 00..f1d49887ee
> > --- /dev/null
> > +++ b/drivers/mtd/nand/raw/meson_nand.c
> > @@ -0,0 +1,1231 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Amlogic Meson Nand Flash Controller Driver
> > + *
> > + * Copyright (c) 2023 SaluteDevices, Inc.
> > + * Author: Arseniy Krasnov 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define NFC_CMD_IDLE (0xc << 14)
> > +#define NFC_CMD_CLE  (0x5 << 14)
> > +#define NFC_CMD_ALE  (0x6 << 14)
> > +#define NFC_CMD_DWR  (0x4 << 14)
> > +#define NFC_CMD_DRD  (0x8 << 14)
> > +#define NFC_CMD_ADL  ((0 << 16) | (3 << 20))
> > +#define NFC_CMD_ADH  ((1 << 16) | (3 << 20))
> > +#define NFC_CMD_AIL  ((2 << 16) | (3 << 20))
> > +#define NFC_CMD_AIH  ((3 << 16) | (3 << 20))
> > +#define NFC_CMD_SEED ((8 << 16) | (3 << 20))
> > +#define NFC_CMD_M2N  ((0 << 17) | (2 << 20))
> > +#define NFC_CMD_N2M  ((1 << 17) | (2 << 20))
> > +#define NFC_CMD_RB   BIT(20)
> > +#define NFC_CMD_SCRAMBLER_ENABLE BIT(19)
> > +#define NFC_CMD_SCRAMBLER_DISABLE0
> > +#define NFC_CMD_SHORTMODE_DISABLE0
> > +#define NFC_CMD_RB_INT   BIT(14)
> > +#define NFC_CMD_RB_INT_NO_PIN((0xb << 10) | BIT(18) |
> BIT(16))
> > +
> > +#define NFC_CMD_GET_SIZE(x)  (((x) >> 22) & GENMASK(4, 0))
> > +
> > +#define NFC_REG_CMD  0x00
> > +#define NFC_REG_CFG  0x04
> > +#define NFC_REG_DADR 0x08
> > +#define NFC_REG_IADR 0x0c
> > +#define NFC_REG_BUF  0x10
> > +#define NFC_REG_INFO 0x14
> > +#define NFC_REG_DC   0x18
> > +#define NFC_REG_ADR  0x1c
> > +#define NFC_REG_DL   0x20
> > +#define NFC_REG_DH   0x24
> > +#define NFC_REG_CADR 0x28
> > +#define NFC_REG_SADR 0x2c
> > +#define NFC_REG_PINS 0x30
> > +#define NFC_REG_VER  0x38
> > +
> > +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\
> > + (   \
> > + (cmd_dir)   |   \
> > + ((ran) << 19)   |   \
> > + ((bch) << 14)   |   \
> > + ((short_mode) << 13)|   \
> > + (((page_size) & 0x7f) << 6) |   \
> > + ((pages) & 0x3f)\
> > + )
> > +
> > +#define GENCMDDADDRL(adl, addr)  ((adl) | ((addr) & 

Re: [PATCH 00/21] Qualcomm generic board support

[ff]

> Le 4 déc. 2023 à 14:25, Sumit Garg  a écrit :
> 
> On Mon, 4 Dec 2023 at 16:30, Daniel Thompson  
> wrote:
>> 
>>> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
>>> + Linux kernel DT bindings maintainers, EBBR ML
>>> 
>>> On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
 On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
> wrote:
>>> I've been thinking about and hacking on this for the last week or so,
>>> sorry for the delayed reply here.
>>> 
>>> The value is in preventing any of the existing bindings from regressing,
> 
> That is actually best addressed in Linux by checking the DTS against
> yaml DT bindings. We don't have that testing available in u-boot and
> only depend on careful reviews.
 
 I would absolutely love for someone to make another attempt at updating
 our kbuild infrastucture so that we can run the validation targets.
 
>>> 
>>> Given that EBBR requires [1] the platform (firmware/bootloader) and
>>> not OS to supply the devicetree, it becomes evident that
>>> firmware/bootloaders import DTS from Linux kernel (where it is
>>> maintained).
>>> 
>>> But currently u-boot doesn't have a proper way to validate those DTS
>>> against DT bindings (maintained in Linux kernel). Although there are
>>> Devicetree schema tools available here [2], there isn't a versioned
>>> release package of DT bindings which one should use to validate DTS
>>> files.
>> 
>> The kernel is regularly released in multiple forms (including git
>> tags and tarball). Why isn't the kernel itself sufficient to be a
>> versioned release of the DT bindings directory?
>> 
> 
> The Linux kernel may come in various forms (upstream vs stable vs
> vendor). It's difficult to decide from where the DT bindings should
> come from. Should they come from upstream or should they come from the
> kernel which is actually booted onto a particular device?
> 
Looks bad from organizing forward portability standpoint .

> IOW, as of now which kernel version should u-boot pick up for DT
> validation checks?
> 
> If we can have a separate release cadence for DT bindings then the
> platform (firmware/bootloader) can attest the DTB against that. Later
> one should be able to boot any kernel with the DTB provided by
> platform.
> 
That seems a very good step!
> -Sumit
> 
>> 
>> Daniel.
> ___
> boot-architecture mailing list -- boot-architect...@lists.linaro.org
> To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: [PATCH v2 18/18] bloblist: Load the bloblist from the previous loader

[Raymond Mao]

Hi Simon,

On Sat, 2 Dec 2023 at 13:32, Simon Glass  wrote:

> Hi Raymond,
>
> On Mon, 27 Nov 2023 at 12:53, Raymond Mao  wrote:
> >
> > During bloblist initialization, when CONFIG_OF_BOARD is defined,
> > invoke the platform custom function to load the bloblist via boot
> > arguments from the previous loader.
> > If the bloblist exists, copy it into the fixed bloblist memory region.
> >
> > Signed-off-by: Raymond Mao 
> > ---
> > Changes in v2
> > - New patch file created for v2.
> >
> >  common/bloblist.c  | 29 +
> >  include/bloblist.h | 14 ++
> >  2 files changed, 27 insertions(+), 16 deletions(-)
> >
>
> This should already work so I am hoping that this patch is not
> needed...these changes seem to break sandbox_spl
>
By "already work", do you mean any existing patches already done for
loading the
bloblist from the boot args?

Thanks and regards,
Raymond

Re: [PATCH v2 17/18] qemu-arm: Get bloblist from boot arguments

[Raymond Mao]

Hi Simon

On Sat, 2 Dec 2023 at 16:16, Simon Glass  wrote:

> Hi Raymond,
>
> On Mon, 27 Nov 2023 at 12:53, Raymond Mao  wrote:
> >
> > Add platform custom function to get bloblist from boot arguments.
>
> This should be the same for all ARM platforms. The ultimate goal is
> something like [1]
>
Yes, I agree. The current series just focuses on Qemu but ultimately
should be adapted
to all Arm platforms.

>  #include 
> > +#if IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST)
> > +#include 
> > +#endif
> >  #include 
> >  #include 
> >  #include 
> > @@ -102,6 +105,16 @@ static struct mm_region qemu_arm64_mem_map[] = {
> >  struct mm_region *mem_map = qemu_arm64_mem_map;
> >  #endif
> >
> > +#if IS_ENABLED(CONFIG_OF_BOARD)
>
> OF_BLOBLIST and please avoid #if
>
I will remove the build option for argument copying, as they don't
really depend on OF_BOARD
or _BLOBLIST.


> > +   /* Check the register conventions */
> > +   fdt = (unsigned long)bloblist_find(BLOBLISTT_CONTROL_FDT, 0);
>
> This should happen in fdtdec.c automatically. See [2]
>
The reason I have to call `bloblist_find()` here is to get the fdt address
and compare with
arg0 and arg2 (see below few lines of code) to check if it is compliant to
the register conventions
for AARCH64/32 defined by the FW Handoff spec.
This is better to be placed here instead of fdtdec.c

> +   if (IS_ENABLED(CONFIG_ARM64)) {
> > +   if (fdt != qemu_saved_args.arg0 || qemu_saved_args.arg2
> != 0)
> > +   ret = -EIO;
> > +   } else {
> > +   if (fdt != qemu_saved_args.arg2 || qemu_saved_args.arg0
> != 0)
> > +   ret = -EIO;
> > +   }
> > +
> > +   if (ret)
> > +   gd->bloblist = NULL;  /* Reset the gd bloblist pointer */
> > +   else
> > +   memmove((void *)addr,  (void *)qemu_saved_args.arg3,
> > +   gd->bloblist->total_size);
> > +#endif
> > +
> > +   return ret;
> > +}
> > +
>
> Thanks and regards,
Raymond

Re: [PATCH v1] mtd: rawnand: Meson NAND controller support

[Arseniy Krasnov]

On 04.12.2023 22:53, Michael Nazzareno Trimarchi wrote:
> Hi Arseniy
> 
> Il lun 4 dic 2023, 20:31 Arseniy Krasnov  ha
> scritto:
> 
>> cc: Miquel Raynal
>>
>> On 30.11.2023 14:21, Arseniy Krasnov wrote:
>>> Basic support for Amlogic Meson NAND controller on AXG.
>>>
>>> Signed-off-by: Arseniy Krasnov 
>>> ---
>>
> 
> 
> We are going to review your patches. It will be done this week
> 
> Michael

Hello! Thanks!

Thanks, Arseniy

> 
>>  drivers/mtd/nand/raw/Kconfig  |9 +
>>>  drivers/mtd/nand/raw/Makefile |1 +
>>>  drivers/mtd/nand/raw/meson_nand.c | 1231 +
>>>  3 files changed, 1241 insertions(+)
>>>  create mode 100644 drivers/mtd/nand/raw/meson_nand.c
>>>
>>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
>>> index d624589a89..7b7b0226ab 100644
>>> --- a/drivers/mtd/nand/raw/Kconfig
>>> +++ b/drivers/mtd/nand/raw/Kconfig
>>> @@ -488,6 +488,15 @@ config NAND_ARASAN
>>> controller. This uses the hardware ECC for read and
>>> write operations.
>>>
>>> +config NAND_MESON
>>> + bool "Meson NAND support"
>>> + select SYS_NAND_SELF_INIT
>>> + depends on DM_MTD && ARCH_MESON
>>> + imply CMD_NAND
>>> + help
>>> +   This enables Nand driver support for Meson raw NAND flash
>>> +   controller.
>>> +
>>>  config NAND_MXC
>>>   bool "MXC NAND support"
>>>   depends on CPU_ARM926EJS || CPU_ARM1136 || MX5
>>> diff --git a/drivers/mtd/nand/raw/Makefile
>> b/drivers/mtd/nand/raw/Makefile
>>> index add2b4cf65..5b4efd52c9 100644
>>> --- a/drivers/mtd/nand/raw/Makefile
>>> +++ b/drivers/mtd/nand/raw/Makefile
>>> @@ -61,6 +61,7 @@ obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
>>>  obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o
>>>  obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o
>>>  obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o
>>> +obj-$(CONFIG_NAND_MESON) += meson_nand.o
>>>  obj-$(CONFIG_NAND_MXC) += mxc_nand.o
>>>  obj-$(CONFIG_NAND_MXS) += mxs_nand.o
>>>  obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o
>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c
>> b/drivers/mtd/nand/raw/meson_nand.c
>>> new file mode 100644
>>> index 00..f1d49887ee
>>> --- /dev/null
>>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>>> @@ -0,0 +1,1231 @@
>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>> +/*
>>> + * Amlogic Meson Nand Flash Controller Driver
>>> + *
>>> + * Copyright (c) 2023 SaluteDevices, Inc.
>>> + * Author: Arseniy Krasnov 
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define NFC_CMD_IDLE (0xc << 14)
>>> +#define NFC_CMD_CLE  (0x5 << 14)
>>> +#define NFC_CMD_ALE  (0x6 << 14)
>>> +#define NFC_CMD_DWR  (0x4 << 14)
>>> +#define NFC_CMD_DRD  (0x8 << 14)
>>> +#define NFC_CMD_ADL  ((0 << 16) | (3 << 20))
>>> +#define NFC_CMD_ADH  ((1 << 16) | (3 << 20))
>>> +#define NFC_CMD_AIL  ((2 << 16) | (3 << 20))
>>> +#define NFC_CMD_AIH  ((3 << 16) | (3 << 20))
>>> +#define NFC_CMD_SEED ((8 << 16) | (3 << 20))
>>> +#define NFC_CMD_M2N  ((0 << 17) | (2 << 20))
>>> +#define NFC_CMD_N2M  ((1 << 17) | (2 << 20))
>>> +#define NFC_CMD_RB   BIT(20)
>>> +#define NFC_CMD_SCRAMBLER_ENABLE BIT(19)
>>> +#define NFC_CMD_SCRAMBLER_DISABLE0
>>> +#define NFC_CMD_SHORTMODE_DISABLE0
>>> +#define NFC_CMD_RB_INT   BIT(14)
>>> +#define NFC_CMD_RB_INT_NO_PIN((0xb << 10) | BIT(18) |
>> BIT(16))
>>> +
>>> +#define NFC_CMD_GET_SIZE(x)  (((x) >> 22) & GENMASK(4, 0))
>>> +
>>> +#define NFC_REG_CMD  0x00
>>> +#define NFC_REG_CFG  0x04
>>> +#define NFC_REG_DADR 0x08
>>> +#define NFC_REG_IADR 0x0c
>>> +#define NFC_REG_BUF  0x10
>>> +#define NFC_REG_INFO 0x14
>>> +#define NFC_REG_DC   0x18
>>> +#define NFC_REG_ADR  0x1c
>>> +#define NFC_REG_DL   0x20
>>> +#define NFC_REG_DH   0x24
>>> +#define NFC_REG_CADR 0x28
>>> +#define NFC_REG_SADR 0x2c
>>> +#define NFC_REG_PINS 0x30
>>> +#define NFC_REG_VER  0x38
>>> +
>>> +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\
>>> + (   \
>>> + (cmd_dir)   |   \
>>> + ((ran) << 19)   |   \
>>> + ((bch) << 14)   |   \
>>> + ((short_mode) << 13)|   \
>>> + (((page_size) & 0x7f) << 6) |   \
>>> + ((pages) & 0x3f)

Re: [PATCH v2 17/18] qemu-arm: Get bloblist from boot arguments

[Raymond Mao]

Hi Michal,

I will remove "#if IS_ENABLED(CONFIG_OF_BOARD)" from below:

>+#if IS_ENABLED(CONFIG_OF_BOARD)
>+/* Boot parameters saved from lowlevel_init.S */
>+struct {
>+ unsigned long arg0;
>+ unsigned long arg1;
>+ unsigned long arg2;
>+ unsigned long arg3;
>+} qemu_saved_args __section(".data");
>+#endif

Saving the args does not really dependent on OF_BOARD or BLOBLIST

Thanks and regards,
Raymond

On Mon, 4 Dec 2023 at 02:54, Michal Simek  wrote:

>
>
> On 11/27/23 20:50, Raymond Mao wrote:
> > Add platform custom function to get bloblist from boot arguments.
> > Check whether boot arguments aligns with the register conventions
> > defined in FW Handoff spec v0.9.
> > Add bloblist related options into qemu default config.
> >
> > Signed-off-by: Raymond Mao 
> > ---
> > Changes in v2
> > - New patch file created for v2.
> >
> >   board/emulation/qemu-arm/Makefile|  1 +
> >   board/emulation/qemu-arm/lowlevel_init.S | 19 +
> >   board/emulation/qemu-arm/qemu-arm.c  | 54 
> >   configs/qemu_arm64_defconfig |  3 ++
> >   configs/qemu_arm_defconfig   |  3 ++
> >   5 files changed, 80 insertions(+)
> >   create mode 100644 board/emulation/qemu-arm/lowlevel_init.S
> >
> > diff --git a/board/emulation/qemu-arm/Makefile
> b/board/emulation/qemu-arm/Makefile
> > index a22d1237ff..12821e7083 100644
> > --- a/board/emulation/qemu-arm/Makefile
> > +++ b/board/emulation/qemu-arm/Makefile
> > @@ -1,3 +1,4 @@
> >   # SPDX-License-Identifier: GPL-2.0+
> >
> >   obj-y   += qemu-arm.o
> > +obj-$(CONFIG_OF_BOARD)   += lowlevel_init.o
> > diff --git a/board/emulation/qemu-arm/lowlevel_init.S
> b/board/emulation/qemu-arm/lowlevel_init.S
> > new file mode 100644
> > index 00..d72d7c938a
> > --- /dev/null
> > +++ b/board/emulation/qemu-arm/lowlevel_init.S
> > @@ -0,0 +1,19 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +/*
> > + * Copyright (c) 2023, Linaro Limited
> > + */
> > +
> > +#include 
> > +
> > +.global save_boot_params
> > +save_boot_params:
> > +#ifdef CONFIG_ARM64
> > + adr x9, qemu_saved_args
>
> Based on logic below this is available only when CONFIG_OF_BOARD is
> enabled.
> Please look below.
>
> > + stp x0, x1, [x9]
> > + /* Increment the address by 16 bytes for the next pair of values */
> > + stp x2, x3, [x9, #16]
> > +#else
> > + ldr r12, =qemu_saved_args
> > + stm r12, {r0, r1, r2, r3}
> > +#endif
> > + b   save_boot_params_ret
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> b/board/emulation/qemu-arm/qemu-arm.c
> > index 942f1fff57..a3892630d8 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -4,6 +4,9 @@
> >*/
> >
> >   #include 
> > +#if IS_ENABLED(CONFIG_OF_BOARD) && IS_ENABLED(CONFIG_BLOBLIST)
> > +#include 
> > +#endif
>
> you have dependency on OF_BOARD and BLOBLIST.
>
> >   #include 
> >   #include 
> >   #include 
> > @@ -102,6 +105,16 @@ static struct mm_region qemu_arm64_mem_map[] = {
> >   struct mm_region *mem_map = qemu_arm64_mem_map;
> >   #endif
> >
> > +#if IS_ENABLED(CONFIG_OF_BOARD)
>
> And here OF_BOARD.
>
> Not all should be aligned but I don't think current #if
>
>
> Thanks,
> Michal
>

Re: [PATCH v1] mtd: rawnand: macronix: OTP access for MX30LFxG18AC

[Arseniy Krasnov]

cc: Miquel Raynal

On 30.11.2023 14:24, Arseniy Krasnov wrote:
> Support for OTP area access on MX30LFxG18AC chip series.
> 
> Signed-off-by: Arseniy Krasnov 
> ---
>  drivers/mtd/nand/raw/nand_macronix.c | 170 +++
>  1 file changed, 170 insertions(+)
> 
> diff --git a/drivers/mtd/nand/raw/nand_macronix.c 
> b/drivers/mtd/nand/raw/nand_macronix.c
> index dc972e5909..4c6ddd9233 100644
> --- a/drivers/mtd/nand/raw/nand_macronix.c
> +++ b/drivers/mtd/nand/raw/nand_macronix.c
> @@ -16,13 +16,183 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
>  #include 
>  
> +#define ONFI_FEATURE_ADDR_30LFXG18AC_OTP 0x90
> +#define MACRONIX_30LFXG18AC_OTP_START_PAGE   2
> +#define MACRONIX_30LFXG18AC_OTP_PAGES30
> +#define MACRONIX_30LFXG18AC_OTP_PAGE_SIZE2112
> +#define MACRONIX_30LFXG18AC_OTP_SIZE_BYTES   \
> + (MACRONIX_30LFXG18AC_OTP_PAGES *\
> +  MACRONIX_30LFXG18AC_OTP_PAGE_SIZE)
> +
> +#define MACRONIX_30LFXG18AC_OTP_EN   BIT(0)
> +
> +static int macronix_30lfxg18ac_get_otp_info(struct mtd_info *mtd, size_t len,
> + size_t *retlen,
> + struct otp_info *buf)
> +{
> + if (len < sizeof(*buf))
> + return -EINVAL;
> +
> + /* Always report that OTP is unlocked. Reason is that this
> +  * type of flash chip doesn't provide way to check that OTP
> +  * is locked or not: subfeature parameter is implemented as
> +  * volatile register. Technically OTP region could be locked
> +  * and become readonly, but as there is no way to check it,
> +  * don't allow to lock it ('_lock_user_prot_reg' callback
> +  * always returns -EOPNOTSUPP) and thus we report that OTP
> +  * is unlocked.
> +  */
> + buf->locked = 0;
> + buf->start = 0;
> + buf->length = MACRONIX_30LFXG18AC_OTP_SIZE_BYTES;
> +
> + *retlen = sizeof(*buf);
> +
> + return 0;
> +}
> +
> +static int macronix_30lfxg18ac_otp_enable(struct nand_chip *nand)
> +{
> + u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> + struct mtd_info *mtd;
> +
> + mtd = nand_to_mtd(nand);
> + feature_buf[0] = MACRONIX_30LFXG18AC_OTP_EN;
> +
> + return nand->onfi_set_features(mtd, nand, 
> ONFI_FEATURE_ADDR_30LFXG18AC_OTP, feature_buf);
> +}
> +
> +static int macronix_30lfxg18ac_otp_disable(struct nand_chip *nand)
> +{
> + u8 feature_buf[ONFI_SUBFEATURE_PARAM_LEN] = { 0 };
> + struct mtd_info *mtd;
> +
> + mtd = nand_to_mtd(nand);
> + return nand->onfi_set_features(mtd, nand, 
> ONFI_FEATURE_ADDR_30LFXG18AC_OTP, feature_buf);
> +}
> +
> +static int __macronix_30lfxg18ac_rw_otp(struct mtd_info *mtd,
> + loff_t offs_in_flash,
> + size_t len, size_t *retlen,
> + u_char *buf, bool write)
> +{
> + struct nand_chip *nand;
> + size_t bytes_handled;
> + off_t offs_in_page;
> + u64 page;
> + int ret;
> +
> + nand = mtd_to_nand(mtd);
> + nand->select_chip(mtd, 0);
> +
> + ret = macronix_30lfxg18ac_otp_enable(nand);
> + if (ret)
> + goto out_otp;
> +
> + page = offs_in_flash;
> + /* 'page' will be result of division. */
> + offs_in_page = do_div(page, MACRONIX_30LFXG18AC_OTP_PAGE_SIZE);
> + bytes_handled = 0;
> +
> + while (bytes_handled < len &&
> +page < MACRONIX_30LFXG18AC_OTP_PAGES) {
> + size_t bytes_to_handle;
> + u64 phys_page = page + MACRONIX_30LFXG18AC_OTP_START_PAGE;
> +
> + bytes_to_handle = min_t(size_t, len - bytes_handled,
> + MACRONIX_30LFXG18AC_OTP_PAGE_SIZE -
> + offs_in_page);
> +
> + if (write)
> + ret = nand_prog_page_op(nand, phys_page, offs_in_page,
> + [bytes_handled], 
> bytes_to_handle);
> + else
> + ret = nand_read_page_op(nand, phys_page, offs_in_page,
> + [bytes_handled], 
> bytes_to_handle);
> + if (ret)
> + goto out_otp;
> +
> + bytes_handled += bytes_to_handle;
> + offs_in_page = 0;
> + page++;
> + }
> +
> + *retlen = bytes_handled;
> +
> +out_otp:
> + if (ret)
> + dev_err(mtd->dev, "failed to perform OTP IO: %i\n", ret);
> +
> + ret = macronix_30lfxg18ac_otp_disable(nand);
> + if (ret)
> + dev_err(mtd->dev, "failed to leave OTP mode after %s\n",
> + write ? "write" : "read");
> +
> + nand->select_chip(mtd, -1);
> +
> + return ret;
> +}
> +
> +static int macronix_30lfxg18ac_write_otp(struct mtd_info *mtd, loff_t to,
> +  size_t len, size_t *rlen,
> +

Re: [PATCH v1] mtd: rawnand: Meson NAND controller support

[Arseniy Krasnov]

cc: Miquel Raynal

On 30.11.2023 14:21, Arseniy Krasnov wrote:
> Basic support for Amlogic Meson NAND controller on AXG.
> 
> Signed-off-by: Arseniy Krasnov 
> ---
>  drivers/mtd/nand/raw/Kconfig  |9 +
>  drivers/mtd/nand/raw/Makefile |1 +
>  drivers/mtd/nand/raw/meson_nand.c | 1231 +
>  3 files changed, 1241 insertions(+)
>  create mode 100644 drivers/mtd/nand/raw/meson_nand.c
> 
> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
> index d624589a89..7b7b0226ab 100644
> --- a/drivers/mtd/nand/raw/Kconfig
> +++ b/drivers/mtd/nand/raw/Kconfig
> @@ -488,6 +488,15 @@ config NAND_ARASAN
> controller. This uses the hardware ECC for read and
> write operations.
>  
> +config NAND_MESON
> + bool "Meson NAND support"
> + select SYS_NAND_SELF_INIT
> + depends on DM_MTD && ARCH_MESON
> + imply CMD_NAND
> + help
> +   This enables Nand driver support for Meson raw NAND flash
> +   controller.
> +
>  config NAND_MXC
>   bool "MXC NAND support"
>   depends on CPU_ARM926EJS || CPU_ARM1136 || MX5
> diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
> index add2b4cf65..5b4efd52c9 100644
> --- a/drivers/mtd/nand/raw/Makefile
> +++ b/drivers/mtd/nand/raw/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o
>  obj-$(CONFIG_NAND_LPC32XX_MLC) += lpc32xx_nand_mlc.o
>  obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o
>  obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o
> +obj-$(CONFIG_NAND_MESON) += meson_nand.o
>  obj-$(CONFIG_NAND_MXC) += mxc_nand.o
>  obj-$(CONFIG_NAND_MXS) += mxs_nand.o
>  obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o
> diff --git a/drivers/mtd/nand/raw/meson_nand.c 
> b/drivers/mtd/nand/raw/meson_nand.c
> new file mode 100644
> index 00..f1d49887ee
> --- /dev/null
> +++ b/drivers/mtd/nand/raw/meson_nand.c
> @@ -0,0 +1,1231 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Amlogic Meson Nand Flash Controller Driver
> + *
> + * Copyright (c) 2023 SaluteDevices, Inc.
> + * Author: Arseniy Krasnov 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define NFC_CMD_IDLE (0xc << 14)
> +#define NFC_CMD_CLE  (0x5 << 14)
> +#define NFC_CMD_ALE  (0x6 << 14)
> +#define NFC_CMD_DWR  (0x4 << 14)
> +#define NFC_CMD_DRD  (0x8 << 14)
> +#define NFC_CMD_ADL  ((0 << 16) | (3 << 20))
> +#define NFC_CMD_ADH  ((1 << 16) | (3 << 20))
> +#define NFC_CMD_AIL  ((2 << 16) | (3 << 20))
> +#define NFC_CMD_AIH  ((3 << 16) | (3 << 20))
> +#define NFC_CMD_SEED ((8 << 16) | (3 << 20))
> +#define NFC_CMD_M2N  ((0 << 17) | (2 << 20))
> +#define NFC_CMD_N2M  ((1 << 17) | (2 << 20))
> +#define NFC_CMD_RB   BIT(20)
> +#define NFC_CMD_SCRAMBLER_ENABLE BIT(19)
> +#define NFC_CMD_SCRAMBLER_DISABLE0
> +#define NFC_CMD_SHORTMODE_DISABLE0
> +#define NFC_CMD_RB_INT   BIT(14)
> +#define NFC_CMD_RB_INT_NO_PIN((0xb << 10) | BIT(18) | 
> BIT(16))
> +
> +#define NFC_CMD_GET_SIZE(x)  (((x) >> 22) & GENMASK(4, 0))
> +
> +#define NFC_REG_CMD  0x00
> +#define NFC_REG_CFG  0x04
> +#define NFC_REG_DADR 0x08
> +#define NFC_REG_IADR 0x0c
> +#define NFC_REG_BUF  0x10
> +#define NFC_REG_INFO 0x14
> +#define NFC_REG_DC   0x18
> +#define NFC_REG_ADR  0x1c
> +#define NFC_REG_DL   0x20
> +#define NFC_REG_DH   0x24
> +#define NFC_REG_CADR 0x28
> +#define NFC_REG_SADR 0x2c
> +#define NFC_REG_PINS 0x30
> +#define NFC_REG_VER  0x38
> +
> +#define CMDRWGEN(cmd_dir, ran, bch, short_mode, page_size, pages)\
> + (   \
> + (cmd_dir)   |   \
> + ((ran) << 19)   |   \
> + ((bch) << 14)   |   \
> + ((short_mode) << 13)|   \
> + (((page_size) & 0x7f) << 6) |   \
> + ((pages) & 0x3f)\
> + )
> +
> +#define GENCMDDADDRL(adl, addr)  ((adl) | ((addr) & 0x))
> +#define GENCMDDADDRH(adh, addr)  ((adh) | (((addr) >> 16) & 
> 0x))
> +#define GENCMDIADDRL(ail, addr)  ((ail) | ((addr) & 0x))
> +#define GENCMDIADDRH(aih, addr)  ((aih) | (((addr) >> 16) & 
> 0x))
> +
> +#define DMA_DIR(dir) ((dir) ? NFC_CMD_N2M : NFC_CMD_M2N)
> +
> +#define ECC_CHECK_RETURN_FF  -1
> +
> +#define 

Re: [PATCH 0/2] docs: AM62x: Remove SW_PRNG Flag for OPTEE

[Nishanth Menon]

On 15:59-20231201, Dhruva Gole wrote:
> The CFG_WITH_SOFTWARE_PRNG option was needed once when there were some
> issues with system crashes/ hangs after a suspend-resume cycle. However
> this seems to no longer be the case with newer firmwares, and this
> config is not needed for basic boot support of the SoC either, hence
> remove it from the docs.
> 
> Cc: Kamlesh 
> Cc: Vibhore Vardhan 
> Cc: Wadim Egorov 
> 
> Dhruva Gole (2):
>   doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE
>   doc: board: ti: am62x_sk: Remove SW_PRNG Flag for OPTEE
> 
>  doc/board/beagle/am62x_beagleplay.rst | 1 -
>  doc/board/ti/am62x_sk.rst | 1 -
>  2 files changed, 2 deletions(-)
> 

NAK to the series. RNG seed is needed for KASLR. either enable h/w RNG
or at least enable S/W RNG in OPTEE.

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH 1/2] doc: board: beagle: am62x_beagleplay: Delete SW_PRNG flag for OPTEE

[Nishanth Menon]

On 15:59-20231201, Dhruva Gole wrote:
> Delete the flag CFG_WITH_SOFTWARE_PRNG as it's not necessary/ boot
> requirement for this SoC
> 
> Signed-off-by: Dhruva Gole 
> ---
>  doc/board/beagle/am62x_beagleplay.rst | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/doc/board/beagle/am62x_beagleplay.rst 
> b/doc/board/beagle/am62x_beagleplay.rst
> index 7784e62b0b71..50d7d3c620d7 100644
> --- a/doc/board/beagle/am62x_beagleplay.rst
> +++ b/doc/board/beagle/am62x_beagleplay.rst
> @@ -63,7 +63,6 @@ Set the variables corresponding to this platform:
># 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::  ../ti/am62x_sk.rst
>  :start-after: .. am62x_evm_rst_include_start_build_steps
> -- 
> 2.34.1
> 
NAK. RNG is needed to seed standard distros.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH v2 15/18] fdt: Allow the devicetree to come from a bloblist

[Raymond Mao]

Hi Simon,

When `OF_BOARD` is defined, the FDT should be from one of
the board-specific mechanisms:
1. FDT from a bloblist via boot args
2. FDT in memory
I don't think we need a new build option to distinguish these two, since it
can be done in runtime by checking whether the boot args follow the FW
Handoff spec conventions and the FDT exists in the bloblist.
If it fulfills the above conditions, we can take the FDT from bloblist,
otherwise from the predefined memory address.
This is fully backward compatible without adding a new build option.

Regards,
Raymond

On Sat, 2 Dec 2023 at 13:32, Simon Glass  wrote:

> Hi Raymond,
>
> On Mon, 27 Nov 2023 at 12:53, Raymond Mao  wrote:
> >
> > From: Simon Glass 
> >
> > Standard passage provides for a bloblist to be passed from one firmware
> > phase to the next. That can be used to pass the devicetree along as well.
> > If CONFIG_OF_BOARD is defined, a board custom routine will provide a
> > bloblist or a specified memory address to retrieve the devicetree at
> > runtime.
> > A devicetree from a bloblist is prioritized than the one from specified
> > memory region.
> >
> > Tests for this will be added as part of the Universal Payload work.
> >
> > Signed-off-by: Simon Glass 
> > Co-developed-by: Raymond Mao 
> > Signed-off-by: Raymond Mao 
> > ---
> > Changes in v2
> > - New patch file created for v2.
> >   Amended from the original patch
> >   "[v2,30/32] fdt: Allow the devicetree to come from a bloblist".
> >   Remove CONFIG_OF_BLOBLIST and FDTSRC_BLOBLIST, a DTB from a previous
> >   loader is defined by CONFIG_OF_BOARD. The DTB can be located either in
> the
> >   bloblist or from a specified memory address.
> >
> >  doc/develop/devicetree/control.rst |  8 +++--
> >  dts/Kconfig|  9 --
> >  include/fdtdec.h   |  3 +-
> >  lib/fdtdec.c   | 52 +++---
> >  4 files changed, 53 insertions(+), 19 deletions(-)
>
> This is a bit mangled. I spoke to Ilias about this as osfc and thought
> we had it figured out, but it was a bit rushed so perhaps not.
>
> OF_BOARD refers to a board-specific mechanism
>
> We should have OF_BLOBLIST to reference to this, a standard mechanism
> and not board-specific.
>
> Ideally all boards should use a bloblist to send their DT to U-Boot.
> E.g. Raspberry Pi.
>
> So I believe my original patch was closer to what we want.
>
> Regards,
> SImon
>

Re: [PATCH 05/18] treewide: bootm: Drop command-line args to boot_os_fn

[Angelo Dureghello]

Hi Simon,

looks like i cannot apply this patch:

    ~/dev-k/u-boot-coldfire  on   master *2  git am 
Complete-decoupling-of-bootm-logic-from-commands.patch

Applying: bootm: netbds: Drop passing of arguments
Applying: bootm: plan: Drop passing of arguments
Applying: bootm: qnxelf: Drop passing of arguments
Applying: nios2: Drop separate parsing of bootm args
Applying: treewide: bootm: Drop command-line args to boot_os_fn
error: patch failed: boot/bootm_os.c:441
error: boot/bootm_os.c: patch does not apply
Patch failed at 0005 treewide: bootm: Drop command-line args to boot_os_fn
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


And getting similar issues for the "pxe: Allow extlinux booting without 
CMDLINE enabled"


Am i doing something wrong ?

Thanks,

Regards
angelo

On 04/12/23 1:26 AM, Simon Glass wrote:

These arguments are not used now. They cannot be provided when there is
no bootm command invoked to provide arguments. Drop the argc and argv
parameters.

Signed-off-by: Simon Glass 
---

  arch/arc/lib/bootm.c|  2 +-
  arch/arm/lib/bootm.c|  3 +--
  arch/m68k/lib/bootm.c   |  3 +--
  arch/microblaze/lib/bootm.c |  3 +--
  arch/mips/lib/bootm.c   |  3 +--
  arch/nios2/lib/bootm.c  |  3 +--
  arch/powerpc/lib/bootm.c|  3 +--
  arch/riscv/lib/bootm.c  |  5 ++--
  arch/sandbox/lib/bootm.c|  2 +-
  arch/sh/lib/bootm.c |  3 +--
  arch/x86/lib/bootm.c|  3 +--
  arch/xtensa/lib/bootm.c |  2 +-
  boot/bootm.c|  6 ++---
  boot/bootm_os.c | 46 ++---
  include/bootm.h |  7 +-
  15 files changed, 34 insertions(+), 60 deletions(-)

diff --git a/arch/arc/lib/bootm.c b/arch/arc/lib/bootm.c
index 44ec5864a1c6..0ae7a21b24b6 100644
--- a/arch/arc/lib/bootm.c
+++ b/arch/arc/lib/bootm.c
@@ -78,7 +78,7 @@ static void boot_jump_linux(struct bootm_headers *images, int 
flag)
board_jump_and_run(kernel_entry, r0, 0, r2);
  }
  
-int do_bootm_linux(int flag, int argc, char *argv[], struct bootm_headers *images)

+int do_bootm_linux(int flag, struct bootm_headers *images)
  {
/* No need for those on ARC */
if ((flag & BOOTM_STATE_OS_BD_T) || (flag & BOOTM_STATE_OS_CMDLINE))
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index c56285738a26..ebaac029e094 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -378,8 +378,7 @@ static void boot_jump_linux(struct bootm_headers *images, 
int flag)
   * DIFFERENCE: Instead of calling prep and go at the end
   * they are called if subcommand is equal 0.
   */
-int do_bootm_linux(int flag, int argc, char *const argv[],
-  struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
  {
/* No need for those on ARM */
if (flag & BOOTM_STATE_OS_BD_T || flag & BOOTM_STATE_OS_CMDLINE)
diff --git a/arch/m68k/lib/bootm.c b/arch/m68k/lib/bootm.c
index 79d8b34c0d56..0720861ae9cc 100644
--- a/arch/m68k/lib/bootm.c
+++ b/arch/m68k/lib/bootm.c
@@ -34,8 +34,7 @@ void arch_lmb_reserve(struct lmb *lmb)
arch_lmb_reserve_generic(lmb, get_sp(), gd->ram_top, 1024);
  }
  
-int do_bootm_linux(int flag, int argc, char *const argv[],

-  struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
  {
int ret;
struct bd_info  *kbd;
diff --git a/arch/microblaze/lib/bootm.c b/arch/microblaze/lib/bootm.c
index f3ec4b741b88..93cdf62e18cf 100644
--- a/arch/microblaze/lib/bootm.c
+++ b/arch/microblaze/lib/bootm.c
@@ -81,8 +81,7 @@ static void boot_prep_linux(struct bootm_headers *images)
}
  }
  
-int do_bootm_linux(int flag, int argc, char *const argv[],

-  struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
  {
images->cmdline_start = (ulong)env_get("bootargs");
  
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c

index d6d2f7d9d031..05dbe6131728 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -300,8 +300,7 @@ static void boot_jump_linux(struct bootm_headers *images)
linux_extra);
  }
  
-int do_bootm_linux(int flag, int argc, char *const argv[],

-  struct bootm_headers *images)
+int do_bootm_linux(int flag, struct bootm_headers *images)
  {
/* No need for those on MIPS */
if (flag & BOOTM_STATE_OS_BD_T)
diff --git a/arch/nios2/lib/bootm.c b/arch/nios2/lib/bootm.c
index 823d524c9a2d..040a806bc75e 100644
--- a/arch/nios2/lib/bootm.c
+++ b/arch/nios2/lib/bootm.c
@@ -16,8 +16,7 @@ DECLARE_GLOBAL_DATA_PTR;
  
  #define NIOS_MAGIC 0x534f494e /* enable command line and initrd passing */
  
-int do_bootm_linux(int flag, int 

Re: [PATCH v2 06/18] bloblist: Drop the flags value

[Raymond Mao]

Hi Ilias and Simon,
I just realized that the latest FW Handoff spec introduced 'flags'.
I will remove this patch from the series of next rev.
Regards,
Raymond

On Mon, 4 Dec 2023 at 03:40, Ilias Apalodimas 
wrote:

> I just noticed that's fixed in path #12
>
>
> On Mon, 4 Dec 2023 at 10:36, Ilias Apalodimas
>  wrote:
> >
> > On Mon, 27 Nov 2023 at 21:52, Raymond Mao 
> wrote:
> > >
> > > From: Simon Glass 
> > >
> > > There is no flags value in spec v0.9 so drop it.
> > >
> > > For now it is still present in the header, with an underscore, so that
> > > tests continue to pass.
> >
> > Why? Can't we drop it overall?
> >
> > Thanks
> > /Ilias
> >
>
> Reviewed-by: Ilias Apalodimas 
>
>
> > >
> > > Signed-off-by: Simon Glass 
> > > Signed-off-by: Raymond Mao 
> > > ---
> > >  common/bloblist.c  |  5 ++---
> > >  include/bloblist.h |  6 ++
> > >  test/bloblist.c| 45 +++--
> > >  3 files changed, 23 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/common/bloblist.c b/common/bloblist.c
> > > index f084a32cfc..4d01772c3b 100644
> > > --- a/common/bloblist.c
> > > +++ b/common/bloblist.c
> > > @@ -331,7 +331,7 @@ static u32 bloblist_calc_chksum(struct
> bloblist_hdr *hdr)
> > > return chksum;
> > >  }
> > >
> > > -int bloblist_new(ulong addr, uint size, uint flags)
> > > +int bloblist_new(ulong addr, uint size)
> > >  {
> > > struct bloblist_hdr *hdr;
> > >
> > > @@ -343,7 +343,6 @@ int bloblist_new(ulong addr, uint size, uint flags)
> > > memset(hdr, '\0', sizeof(*hdr));
> > > hdr->version = BLOBLIST_VERSION;
> > > hdr->hdr_size = sizeof(*hdr);
> > > -   hdr->flags = flags;
> > > hdr->magic = BLOBLIST_MAGIC;
> > > hdr->size = size;
> > > hdr->alloced = hdr->hdr_size;
> > > @@ -490,7 +489,7 @@ int bloblist_init(void)
> > > }
> > > log_debug("Creating new bloblist size %lx at %lx\n",
> size,
> > >   addr);
> > > -   ret = bloblist_new(addr, size, 0);
> > > +   ret = bloblist_new(addr, size);
> > > } else {
> > > log_debug("Found existing bloblist size %lx at %lx\n",
> size,
> > >   addr);
> > > diff --git a/include/bloblist.h b/include/bloblist.h
> > > index d70a7bad2e..2b898d0c55 100644
> > > --- a/include/bloblist.h
> > > +++ b/include/bloblist.h
> > > @@ -164,7 +164,6 @@ enum bloblist_tag_t {
> > >   * @version: BLOBLIST_VERSION
> > >   * @hdr_size: Size of this header, normally sizeof(struct
> bloblist_hdr). The
> > >   * first bloblist_rec starts at this offset from the start of the
> header
> > > - * @flags: Space for BLOBLISTF... flags (none yet)
> > >   * @size: Total size of the bloblist (non-zero if valid) including
> this header.
> > >   * The bloblist extends for this many bytes from the start of
> this header.
> > >   * When adding new records, the bloblist can grow up to this size.
> > > @@ -182,7 +181,7 @@ struct bloblist_hdr {
> > > u32 magic;
> > > u32 version;
> > > u32 hdr_size;
> > > -   u32 flags;
> > > +   u32 _flags;
> > >
> > > u32 size;
> > > u32 alloced;
> > > @@ -317,11 +316,10 @@ int bloblist_resize(uint tag, int new_size);
> > >   *
> > >   * @addr: Address of bloblist
> > >   * @size: Initial size for bloblist
> > > - * @flags: Flags to use for bloblist
> > >   * Return: 0 if OK, -EFAULT if addr is not aligned correctly, -ENOSPC
> is the
> > >   * area is not large enough
> > >   */
> > > -int bloblist_new(ulong addr, uint size, uint flags);
> > > +int bloblist_new(ulong addr, uint size);
> > >
> > >  /**
> > >   * bloblist_check() - Check if a bloblist exists
> > > diff --git a/test/bloblist.c b/test/bloblist.c
> > > index 8b435e27ca..36994c3dd4 100644
> > > --- a/test/bloblist.c
> > > +++ b/test/bloblist.c
> > > @@ -72,15 +72,15 @@ static int bloblist_test_init(struct
> unit_test_state *uts)
> > > hdr = clear_bloblist();
> > > ut_asserteq(-ENOENT, bloblist_check(TEST_ADDR,
> TEST_BLOBLIST_SIZE));
> > > ut_asserteq_ptr(NULL, bloblist_check_magic(TEST_ADDR));
> > > -   ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> > > +   ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > > ut_asserteq_ptr(hdr, bloblist_check_magic(TEST_ADDR));
> > > hdr->version++;
> > > ut_asserteq(-EPROTONOSUPPORT, bloblist_check(TEST_ADDR,
> > >
> TEST_BLOBLIST_SIZE));
> > >
> > > -   ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10, 0));
> > > -   ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE, 0));
> > > -   ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE, 0));
> > > +   ut_asserteq(-ENOSPC, bloblist_new(TEST_ADDR, 0x10));
> > > +   ut_asserteq(-EFAULT, bloblist_new(1, TEST_BLOBLIST_SIZE));
> > > +   ut_assertok(bloblist_new(TEST_ADDR, TEST_BLOBLIST_SIZE));
> > >
> > > 

Re: [PATCH v2 01/18] bloblist: Update the tag numbering

[Raymond Mao]

Hi Ilias,

What is the difference between the new added XFERLIST_EVLOG and the
existing BLOBLISTT_TPM2_TCG_LOG and BLOBLISTT_TCPA_LOG in U-Boot?

Thanks and regards,
Raymond

On Mon, 4 Dec 2023 at 12:52, Ilias Apalodimas 
wrote:

> On Mon, 4 Dec 2023 at 18:25, Raymond Mao  wrote:
> >
> > Hi Ilias,
> >
> > BLOBLISTT_AREA_ARM is now holding the ones we already defined in the FW
> Handoff spec for TF-A project only.
> > The TPM eventlog related ones are undefined in the spec yet, they stay
> in the group BLOBLISTT_AREA_FIRMWARE.
>
> We did define them past 0.9 [0]. So I think we should add them regardless.
> They are part of the main doc now [1]
>
> [0] https://github.com/FirmwareHandoff/firmware_handoff/pull/16/files
> [1]
> https://github.com/FirmwareHandoff/firmware_handoff/blob/main/source/transfer_list.rst#tpm-event-log-table-entry-layout-xferlist_evlog
>
> Regards
> /Ilias
>
> >
> > >  /* BLOBLISTT_AREA_FIRMWARE */
> > >- { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> > >- { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> > >  { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> > >  { BLOBLISTT_TCPA_LOG, "TPM log space" },
> > >- { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> > >+ { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >
> > Thanks and regards,
> > Raymond
> >
> > On Mon, 4 Dec 2023 at 03:25, Ilias Apalodimas <
> ilias.apalodi...@linaro.org> wrote:
> >>
> >> Hi all,
> >>
> >> [...]
> >>
> >> >  common/bloblist.c  | 16 +---
> >> >  include/bloblist.h | 65
> --
> >> >  test/bloblist.c|  4 +--
> >> >  3 files changed, 48 insertions(+), 37 deletions(-)
> >> >
> >> > diff --git a/common/bloblist.c b/common/bloblist.c
> >> > index a22f6c12b0..349ceddea5 100644
> >> > --- a/common/bloblist.c
> >> > +++ b/common/bloblist.c
> >> > @@ -36,16 +36,24 @@ static struct tag_name {
> >> > enum bloblist_tag_t tag;
> >> > const char *name;
> >> >  } tag_name[] = {
> >> > -   { BLOBLISTT_NONE, "(none)" },
> >> > +   { BLOBLISTT_VOID, "(void)" },
> >> >
> >> > /* BLOBLISTT_AREA_FIRMWARE_TOP */
> >> > +   { BLOBLISTT_CONTROL_FDT, "Control FDT" },
> >> > +   { BLOBLISTT_HOB_BLOCK, "HOB block" },
> >> > +   { BLOBLISTT_HOB_LIST, "HOB list" },
> >> > +   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >> >
> >> > /* BLOBLISTT_AREA_FIRMWARE */
> >> > -   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >> > -   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> >> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> >> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
> >> > -   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >>
> >> There are some TPM Eventlog related entries that are missing here.
> >> Can we add them?
> >>
> >> > +   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >> > +
> >> > +   /* BLOBLISTT_AREA_ARM */
> >> > +   { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
> >> > +
> >> > +   /* BLOBLISTT_AREA_OTHER */
> >> > +   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> >> [...]
> >>
> >> Thanks
> >> /Ilias
>

[ANN] U-Boot v2024.01-rc4 released

[Tom Rini]

Hey all,

It's release day and here is -rc4. There's just a few fixes I know of
outstanding at this point, and only one of them (NAND for AM335x
platforms) I think isn't something that can be said to be provably
correct, to try and borrow mathematical terms.

In terms of a changelog, 
git log --merges v2024.01-rc3..v2024.01-rc4
contains what I've pulled but as always, better PR messages and tags
will provide better results here.

I hope to remain on schedule and that means the rest of the rcs every
other Monday, and with final release on January 8th, 2024.  Thanks all!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] efi_loader: generated SMBIOS table below 4 GiB

[Tom Rini]

On Mon, 20 Nov 2023 23:25:58 +0100, Heinrich Schuchardt wrote:

> We currently use an outdated format 32-bit format for SMBIOS tables.
> So we must allocate SMBIOS tables below 4 GiB.
> 
> 

As this is reflects what has been done the longest, applied to u-boot/master,
thanks! And we shall revisit all of these topics for v2024.04 or later.

-- 
Tom

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Simon Glass]

Hi Laurent,

On Sun, 3 Dec 2023 at 08:33, Laurent Pinchart
 wrote:
>
> Hi Simon,
>
> Thank you for the patch.
>
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
>
> FIT images are very useful, so I think this is a very welcome addition
> to the kernel build system. It can get tricky though: given the
> versatile nature of FIT images, there can't be any
> one-size-fits-them-all solution to build them, and striking the right
> balance between what makes sense for the kernel and the features that
> users may request will probably lead to bikeshedding. As we all love
> bikeshedding, I thought I would start selfishly, with a personal use
> case :-) This isn't a yak-shaving request though, I don't see any reason
> to delay merging this series.

OK, sounds good!

>
> Have you envisioned building FIT images with a subset of DTBs, or adding
> DTBOs ? Both would be fairly trivial extensions to this script by
> extending the supported command line arguments. It would perhaps be more
> difficult to integrate in the kernel build system though. This leads me
> to a second question: would you consider merging extensions to this
> script if they are not used by the kernel build system, but meant for
> users who manually invoke the script ? More generally, is the script
> meant to be used stand-alone as well, in which case its command line
> arguments need to remain backward-compatible, or do you see it as being
> internal to the kernel ?

The script as written is internal to the kernel, but I am sure it
could be expanded in some ways. I am waiting to see it merged before
worrying too much about what might happen in the future!

[..]

Regards,
Simon

Re: [PATCH v7 2/2] arm64: boot: Support Flat Image Tree

[Doug Anderson]

Hi,

On Sat, Dec 2, 2023 at 8:37 AM Simon Glass  wrote:
>
> Hi Ahmad,
>
> On Thu, 30 Nov 2023 at 19:04, Ahmad Fatoum  wrote:
> >
> > Hello Simon,
> >
> > On 30.11.23 21:30, Simon Glass wrote:
> > > On Wed, 29 Nov 2023 at 12:54, Ahmad Fatoum  
> > > wrote:
> > >> On 29.11.23 20:44, Simon Glass wrote:
> > >>> On Wed, 29 Nov 2023 at 12:33, Ahmad Fatoum  
> > >>> wrote:
> > 
> >  On 29.11.23 20:27, Simon Glass wrote:
> > > On Wed, 29 Nov 2023 at 12:15, Ahmad Fatoum  
> > > wrote:
> > >> On 29.11.23 20:02, Simon Glass wrote:
> > >>> On Wed, 29 Nov 2023 at 11:59, Ahmad Fatoum 
> > >>>  wrote:
> >  The specification says that this is the root U-Boot compatible,
> >  which I presume to mean the top-level compatible, which makes 
> >  sense to me.
> > 
> >  The code here though adds all compatible strings from the device 
> >  tree though,
> >  is this intended?
> > >>>
> > >>> Yes, since it saves needing to read in each DT just to get the
> > >>> compatible stringlist.
> > >>
> > >> The spec reads as if only one string (root) is supposed to be in the 
> > >> list.
> > >> The script adds all compatibles though. This is not really useful as 
> > >> a bootloader
> > >> that's compatible with e.g. fsl,imx8mm would just take the first 
> > >> device tree
> > >> with that SoC, which is most likely to be wrong. It would be better 
> > >> to just
> > >> specify the top-level compatible, so the bootloader fails instead of 
> > >> taking
> > >> the first DT it finds.
> > >
> > > We do need to have a list, since we have to support different board 
> > > revs, etc.
> > 
> >  Can you give me an example? The way I see it, a bootloader with
> >  compatible "vendor,board" and a FIT with configuration with 
> >  compatibles:
> > 
> >    "vendor,board-rev-a", "vendor,board"
> >    "vendor,board-rev-b", "vendor,board"
> > 
> >  would just result in the bootloader booting the first configuration, 
> >  even if
> >  the device is actually rev-b.
> > >>>
> > >>> You need to find the best match, not just any match. This is
> > >>> documented in the function comment for fit_conf_find_compat().
> > >>
> > >> In my above example, both configuration are equally good.
> > >> Can you give me an example where it makes sense to have multiple
> > >> compatibles automatically extracted from the device tree compatible?
> > >>
> > >> The way I see it having more than one compatible here just has
> > >> downsides.
> > >
> > > I don't have an example to hand, but this is the required mechanism of
> > > FIT. This feature has been in place for many years and is used by
> > > ChromeOS, at least.
> >
> > I see the utility of a FIT configuration with
> >
> > compatible = "vendor,board-rev-a", "vendor,board-rev-b";
> >
> > I fail to see a utility for a configuration with
> >
> > compatible = "vendor,board", "vendor,SoM", "vendor,SoC";
> >
> > Any configuration that ends up being booted because "vendor,SoC" was 
> > matched is
> > most likely doomed to fail. Therefore, I would suggest that only the top 
> > level
> > configuration is written into the FIT configurations automatically.
>
> Firstly, I am not an expert on this.
>
> Say you have a board with variants. The compatible string in U-Boot
> may be something like:
>
> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
>
> If you then have several FIT configurations, they may be something like:
>
> "google,veyron-brain-rev0", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
> "google,veyron-brain-rev1", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
> "google,veyron-brain-rev2", "google,veyron-brain", "google,veyron",
> "rockchip,rk3288";
>
> You want to choose the second one, since it is a better match than the others.
>
> +Doug Anderson who knows a lot more about this than me.

Hopefully this is all explained by:

https://docs.kernel.org/arch/arm/google/chromebook-boot-flow.html

Re: [PATCH v2 01/18] bloblist: Update the tag numbering

[Ilias Apalodimas]

On Mon, 4 Dec 2023 at 18:25, Raymond Mao  wrote:
>
> Hi Ilias,
>
> BLOBLISTT_AREA_ARM is now holding the ones we already defined in the FW 
> Handoff spec for TF-A project only.
> The TPM eventlog related ones are undefined in the spec yet, they stay in the 
> group BLOBLISTT_AREA_FIRMWARE.

We did define them past 0.9 [0]. So I think we should add them regardless.
They are part of the main doc now [1]

[0] https://github.com/FirmwareHandoff/firmware_handoff/pull/16/files
[1] 
https://github.com/FirmwareHandoff/firmware_handoff/blob/main/source/transfer_list.rst#tpm-event-log-table-entry-layout-xferlist_evlog

Regards
/Ilias

>
> >  /* BLOBLISTT_AREA_FIRMWARE */
> >- { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> >- { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> >  { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> >  { BLOBLISTT_TCPA_LOG, "TPM log space" },
> >- { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >+ { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>
> Thanks and regards,
> Raymond
>
> On Mon, 4 Dec 2023 at 03:25, Ilias Apalodimas  
> wrote:
>>
>> Hi all,
>>
>> [...]
>>
>> >  common/bloblist.c  | 16 +---
>> >  include/bloblist.h | 65 --
>> >  test/bloblist.c|  4 +--
>> >  3 files changed, 48 insertions(+), 37 deletions(-)
>> >
>> > diff --git a/common/bloblist.c b/common/bloblist.c
>> > index a22f6c12b0..349ceddea5 100644
>> > --- a/common/bloblist.c
>> > +++ b/common/bloblist.c
>> > @@ -36,16 +36,24 @@ static struct tag_name {
>> > enum bloblist_tag_t tag;
>> > const char *name;
>> >  } tag_name[] = {
>> > -   { BLOBLISTT_NONE, "(none)" },
>> > +   { BLOBLISTT_VOID, "(void)" },
>> >
>> > /* BLOBLISTT_AREA_FIRMWARE_TOP */
>> > +   { BLOBLISTT_CONTROL_FDT, "Control FDT" },
>> > +   { BLOBLISTT_HOB_BLOCK, "HOB block" },
>> > +   { BLOBLISTT_HOB_LIST, "HOB list" },
>> > +   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>> >
>> > /* BLOBLISTT_AREA_FIRMWARE */
>> > -   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>> > -   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
>> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
>> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
>> > -   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>>
>> There are some TPM Eventlog related entries that are missing here.
>> Can we add them?
>>
>> > +   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>> > +
>> > +   /* BLOBLISTT_AREA_ARM */
>> > +   { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
>> > +
>> > +   /* BLOBLISTT_AREA_OTHER */
>> > +   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
>> [...]
>>
>> Thanks
>> /Ilias

Re: [PATCH 00/21] Qualcomm generic board support

[Rob Herring]

On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg  wrote:
>
> + Linux kernel DT bindings maintainers, EBBR ML
>
> On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
> >
> > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
> > > wrote:
> > > >
> > > > On 29/11/2023 16:34, Caleb Connolly wrote:
> > > > >
> > > > >
> > > > > On 23/11/2023 07:04, Sumit Garg wrote:
> > > > >> On Wed, 22 Nov 2023 at 21:34, Caleb Connolly 
> > > > >>  wrote:
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> On 22/11/2023 14:27, Tom Rini wrote:
> > > >  On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote:
> > > > > On Wed, 22 Nov 2023 at 19:31, Tom Rini  wrote:
> > > > >>
> > > > >> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote:
> > > > >>> Hi Caleb,
> > > > >>>
> > > > >>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly 
> > > > >>>  wrote:
> > > > >> [snip]
> > > >  == DT loading ==
> > > > 
> > > >  Previously, boards used the FDT blob embedded into U-Boot (via
> > > >  OF_SEPARATE). However, most Qualcomm boards run U-Boot as a 
> > > >  secondary
> > > >  bootloader, so we can instead rely on the first-stage 
> > > >  bootloader to
> > > >  populate some useful FDT properties for us (notably the 
> > > >  /memory node and
> > > >  KASLR seed) and fetch the DTB that it provides. Combined with 
> > > >  the memory
> > > >  map changes above, this let's us entirely avoid configuring 
> > > >  the memory
> > > >  map explicitly.
> > > > >>>
> > > > >>> Since with this change, we don't need to embed FDT blob in the 
> > > > >>> u-boot
> > > > >>> binary, so I was thinking if we really need to import DTs from 
> > > > >>> Linux
> > > > >>> for different platforms and then play a catchup game?
> > > > >>>
> > > > >>> For now, yes.
> > > > >>
> > > > >> But why? Is there any value added by larger u-boot specific DT (most
> > > > >> of the nodes being unused by u-boot) than what currently u-boot
> > > > >> supports? The more important part is to get alignment with Linux DT
> > > > >> bindings. If you need to have memory/reserved-memory nodes in u-boot
> > > > >> DT for generalization purposes then you should import those 
> > > > >> particular
> > > > >> nodes only.
> > > > >
> > > > > I've been thinking about and hacking on this for the last week or so,
> > > > > sorry for the delayed reply here.
> > > > >
> > > > > The value is in preventing any of the existing bindings from 
> > > > > regressing,
> > >
> > > That is actually best addressed in Linux by checking the DTS against
> > > yaml DT bindings. We don't have that testing available in u-boot and
> > > only depend on careful reviews.
> >
> > I would absolutely love for someone to make another attempt at updating
> > our kbuild infrastucture so that we can run the validation targets.
> >
>
> Given that EBBR requires [1] the platform (firmware/bootloader) and
> not OS to supply the devicetree, it becomes evident that
> firmware/bootloaders import DTS from Linux kernel (where it is
> maintained).
>
> But currently u-boot doesn't have a proper way to validate those DTS
> against DT bindings (maintained in Linux kernel). Although there are
> Devicetree schema tools available here [2], there isn't a versioned
> release package of DT bindings which one should use to validate DTS
> files.
>
> @DT bindings maintainers,
>
> Given the ease of maintenance of DT bindings within Linux kernel
> source tree, I don't have a specific objection there. But can we ease
> DTS testing for firmware/bootloader projects by providing a versioned
> release package for DT bindings? Or if someone else has a better idea
> here please feel free to chime in.

This doesn't work for you?:

https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/

Note that I would like to revamp this repo to use some modern CI job,
use git_filter_repo python module rather than git-filter-branch, and
move to devicetree.org GH, but if projects aren't relying on this
repo, I'm not motivated to do that work.

Rob

Re: [PATCH v2 05/18] bloblist: Access record hdr_size and tag via a function

[Raymond Mao]

Hi Ilias,

This patch is for later grouping the tag and hdr_size in
'0011-bloblist-Reduce-blob-header-size.patch'.
I can update the commit message.

Thanks and regards,
Raymond

On Mon, 4 Dec 2023 at 03:31, Ilias Apalodimas 
wrote:

> On Mon, 27 Nov 2023 at 21:52, Raymond Mao  wrote:
> >
> > From: Simon Glass 
> >
> > These values currently use a simple field. With spec v0.9 they have moved
> > to a packed format. Convert most accesses to use functions, so this
> change
> > can be accommodated.
>
> I don't really understand how the commit message is related to the changes.
> What did the packed format affect that we need a function?
>
> Thanks
> /Ilias
> >
> > Signed-off-by: Simon Glass 
> > Signed-off-by: Raymond Mao 
> > ---
> >  common/bloblist.c | 38 +-
> >  1 file changed, 25 insertions(+), 13 deletions(-)
> >
> > diff --git a/common/bloblist.c b/common/bloblist.c
> > index e744c2b0c0..f084a32cfc 100644
> > --- a/common/bloblist.c
> > +++ b/common/bloblist.c
> > @@ -82,13 +82,23 @@ static struct bloblist_rec
> *bloblist_first_blob(struct bloblist_hdr *hdr)
> > return (struct bloblist_rec *)((void *)hdr + hdr->hdr_size);
> >  }
> >
> > +static inline uint rec_hdr_size(struct bloblist_rec *rec)
> > +{
> > +   return rec->hdr_size;
> > +}
> > +
> > +static inline uint rec_tag(struct bloblist_rec *rec)
> > +{
> > +   return rec->tag;
> > +}
> > +
> >  static ulong bloblist_blob_end_ofs(struct bloblist_hdr *hdr,
> >struct bloblist_rec *rec)
> >  {
> > ulong offset;
> >
> > offset = (void *)rec - (void *)hdr;
> > -   offset += rec->hdr_size + ALIGN(rec->size, BLOBLIST_ALIGN);
> > +   offset += rec_hdr_size(rec) + ALIGN(rec->size, BLOBLIST_ALIGN);
> >
> > return offset;
> >  }
> > @@ -117,7 +127,7 @@ static struct bloblist_rec *bloblist_findrec(uint
> tag)
> > return NULL;
> >
> > foreach_rec(rec, hdr) {
> > -   if (rec->tag == tag)
> > +   if (rec_tag(rec) == tag)
> > return rec;
> > }
> >
> > @@ -156,7 +166,7 @@ static int bloblist_addrec(uint tag, int size, int
> align_log2,
> > rec->spare = 0;
> >
> > /* Zero the record data */
> > -   memset((void *)rec + rec->hdr_size, '\0', rec->size);
> > +   memset((void *)rec + rec_hdr_size(rec), '\0', rec->size);
> >
> > hdr->alloced = new_alloced;
> > *recp = rec;
> > @@ -197,7 +207,7 @@ void *bloblist_find(uint tag, int size)
> > if (size && size != rec->size)
> > return NULL;
> >
> > -   return (void *)rec + rec->hdr_size;
> > +   return (void *)rec + rec_hdr_size(rec);
> >  }
> >
> >  void *bloblist_add(uint tag, int size, int align_log2)
> > @@ -207,7 +217,7 @@ void *bloblist_add(uint tag, int size, int
> align_log2)
> > if (bloblist_addrec(tag, size, align_log2, ))
> > return NULL;
> >
> > -   return (void *)rec + rec->hdr_size;
> > +   return (void *)rec + rec_hdr_size(rec);
> >  }
> >
> >  int bloblist_ensure_size(uint tag, int size, int align_log2, void
> **blobp)
> > @@ -218,7 +228,7 @@ int bloblist_ensure_size(uint tag, int size, int
> align_log2, void **blobp)
> > ret = bloblist_ensurerec(tag, , size, align_log2);
> > if (ret)
> > return ret;
> > -   *blobp = (void *)rec + rec->hdr_size;
> > +   *blobp = (void *)rec + rec_hdr_size(rec);
> >
> > return 0;
> >  }
> > @@ -230,7 +240,7 @@ void *bloblist_ensure(uint tag, int size)
> > if (bloblist_ensurerec(tag, , size, 0))
> > return NULL;
> >
> > -   return (void *)rec + rec->hdr_size;
> > +   return (void *)rec + rec_hdr_size(rec);
> >  }
> >
> >  int bloblist_ensure_size_ret(uint tag, int *sizep, void **blobp)
> > @@ -243,7 +253,7 @@ int bloblist_ensure_size_ret(uint tag, int *sizep,
> void **blobp)
> > *sizep = rec->size;
> > else if (ret)
> > return ret;
> > -   *blobp = (void *)rec + rec->hdr_size;
> > +   *blobp = (void *)rec + rec_hdr_size(rec);
> >
> > return 0;
> >  }
> > @@ -279,7 +289,7 @@ static int bloblist_resize_rec(struct bloblist_hdr
> *hdr,
> >
> > /* Zero the new part of the blob */
> > if (expand_by > 0) {
> > -   memset((void *)rec + rec->hdr_size + rec->size, '\0',
> > +   memset((void *)rec + rec_hdr_size(rec) + rec->size, '\0',
> >new_size - rec->size);
> > }
> >
> > @@ -313,8 +323,9 @@ static u32 bloblist_calc_chksum(struct bloblist_hdr
> *hdr)
> > chksum = crc32(0, (unsigned char *)hdr,
> >offsetof(struct bloblist_hdr, chksum));
> > foreach_rec(rec, hdr) {
> > -   chksum = crc32(chksum, (void *)rec, rec->hdr_size);
> > -   chksum = crc32(chksum, (void *)rec + rec->hdr_size,
> rec->size);
> > +   chksum 

Re: [PATCH v2 01/18] bloblist: Update the tag numbering

[Raymond Mao]

Hi Ilias,

BLOBLISTT_AREA_ARM is now holding the ones we already defined in the FW
Handoff spec for TF-A project only.
The TPM eventlog related ones are undefined in the spec yet, they stay in
the group BLOBLISTT_AREA_FIRMWARE.

>  /* BLOBLISTT_AREA_FIRMWARE */
>- { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
>- { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
>  { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
>  { BLOBLISTT_TCPA_LOG, "TPM log space" },
>- { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>+ { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },

Thanks and regards,
Raymond

On Mon, 4 Dec 2023 at 03:25, Ilias Apalodimas 
wrote:

> Hi all,
>
> [...]
>
> >  common/bloblist.c  | 16 +---
> >  include/bloblist.h | 65 --
> >  test/bloblist.c|  4 +--
> >  3 files changed, 48 insertions(+), 37 deletions(-)
> >
> > diff --git a/common/bloblist.c b/common/bloblist.c
> > index a22f6c12b0..349ceddea5 100644
> > --- a/common/bloblist.c
> > +++ b/common/bloblist.c
> > @@ -36,16 +36,24 @@ static struct tag_name {
> > enum bloblist_tag_t tag;
> > const char *name;
> >  } tag_name[] = {
> > -   { BLOBLISTT_NONE, "(none)" },
> > +   { BLOBLISTT_VOID, "(void)" },
> >
> > /* BLOBLISTT_AREA_FIRMWARE_TOP */
> > +   { BLOBLISTT_CONTROL_FDT, "Control FDT" },
> > +   { BLOBLISTT_HOB_BLOCK, "HOB block" },
> > +   { BLOBLISTT_HOB_LIST, "HOB list" },
> > +   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
> >
> > /* BLOBLISTT_AREA_FIRMWARE */
> > -   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> > -   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> > { BLOBLISTT_TPM2_TCG_LOG, "TPM v2 log space" },
> > { BLOBLISTT_TCPA_LOG, "TPM log space" },
> > -   { BLOBLISTT_ACPI_TABLES, "ACPI tables for x86" },
>
> There are some TPM Eventlog related entries that are missing here.
> Can we add them?
>
> > +   { BLOBLISTT_ACPI_GNVS, "ACPI GNVS" },
> > +
> > +   /* BLOBLISTT_AREA_ARM */
> > +   { BLOBLISTT_OPTEE_PAGABLE_PART, "OP-TEE pagable part" },
> > +
> > +   /* BLOBLISTT_AREA_OTHER */
> > +   { BLOBLISTT_INTEL_VBT, "Intel Video-BIOS table" },
> [...]
>
> Thanks
> /Ilias
>

Re: [PATCH 0/2] serial: msm-geni: rework oversampling and fix clk API bug

[Caleb Connolly]

On Tue, 14 Nov 2023 12:51:10 +, Caleb Connolly wrote:
> These patches improve GENI UART support during init by implementing the
> parent property read directly rather than via a misc device, and fixing
> the error path when the clock can't be found.
> 
> In my testing, the first few lines of UART output on platforms with
> non-default oversampling values is often garbled, this is because the
> parent misc device hasn't yet probed and so the clock rate is incorrect.
> 
> [...]

Applied, thanks!

[1/2] serial: msm-geni: don't rely on parent misc device
  commit: 393825c304411c6483dbfbc45ea09c577365ddb9
[2/2] serial: msm-geni: handle devm_clk_get() errors
  commit: afd9dcf23cb232dd5f352336c6b389691682be47

Best regards,
-- 
// Caleb (they/them)

Re: [PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument

[Andrew Davis]

On 12/4/23 5:21 AM, Neha Malcom Francis wrote:

Mention TI_DM argument can be used to fetch a custom DM binary in the
A72 build instructions for K3 devices.

Signed-off-by: Neha Malcom Francis 
---
  doc/board/ti/k3.rst | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index a127215ce5..15916b088f 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -320,6 +320,13 @@ use the `lite` option.
   make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
  BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
  TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin
+
+.. note::
+   It is also possible to pick up a custom DM binary by adding TI_DM argument
+   pointing to the file. If not provided, it defaults to picking up the DM
+   binary from ti-linux-firmware. This is only applicable to devices that


It would only be "ti-linux-firmware" if that is what you had set as 
BINMAN_INDIRS.

s/ti-linux-firmware/BINMAN_INDIRS

Otherwise whole series LGTM,

Reviewed-by: Andrew Davis 


+   utilize split firmware.
+
  .. k3_rst_include_end_build_steps_uboot
  
  At this point you should have every binary needed initialize both the

Re: [PATCH v1 0/8] Convert Tegra pinctrl to DM

[Svyatoslav Ryhel]

пн, 4 груд. 2023 р. о 12:26 Thierry Reding  пише:
>
> On Mon, Dec 04, 2023 at 10:20:46AM +0200, Svyatoslav Ryhel wrote:
> > Create a DM supported wrapper arround existing Tegra pinmux logic.
> > This implementation is backwards compatible with all existing board
> > setups and early stages of setup. All new boards must be device tree
> > based. Linux dts pinmux nodes are fully compatible with this driver.
> >
> > As an example I have converted recently merged T30 boards to this
> > layout (I have those devices and was able to test them properly) and
> > Paz00 T20 board which was tested as well by owner.
> >
> > Svyatoslav Ryhel (8):
> >   ARM: mach-tegra: rearrange SPL configs
> >   drivers: pinctrl: create Tegra DM pinctrl driver
> >   drivers: pinctrl: tegra: incorporate existing code
> >   board: asus: grouper: switch to DM pinmux
> >   board: lg: x3-t30: switch to DM pinmux
> >   board: asus: transformer: switch to DM pinmux
> >   board: htc: endeavoru: switch to DM pinmux
> >   board: compal: paz00: clean up the board
> >
> >  arch/arm/dts/tegra20-paz00.dts|4 +-
> >  arch/arm/dts/tegra30-asus-grouper-common.dtsi |  712 ++
> >  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |  113 ++
> >  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |  113 ++
> >  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |  149 +++
> >  arch/arm/dts/tegra30-asus-p1801-t.dts |  982 ++
> >  arch/arm/dts/tegra30-asus-tf201.dts   |   45 +
> >  arch/arm/dts/tegra30-asus-tf300t.dts  |   45 +
> >  arch/arm/dts/tegra30-asus-tf300tg.dts |  128 ++
> >  arch/arm/dts/tegra30-asus-tf300tl.dts |  163 +++
> >  arch/arm/dts/tegra30-asus-tf600t.dts  |  889 +
> >  arch/arm/dts/tegra30-asus-tf700t.dts  |   53 +
> >  arch/arm/dts/tegra30-asus-transformer.dtsi|  984 ++
> >  arch/arm/dts/tegra30-htc-endeavoru.dts| 1147 +
> >  arch/arm/dts/tegra30-lg-p880.dts  |   90 ++
> >  arch/arm/dts/tegra30-lg-p895.dts  |   93 ++
> >  arch/arm/dts/tegra30-lg-x3.dtsi   |  845 
> >  arch/arm/include/asm/arch-tegra114/pinmux.h   |  303 +
> >  arch/arm/include/asm/arch-tegra124/pinmux.h   |  327 +
> >  arch/arm/include/asm/arch-tegra20/pinmux.h|  291 +
> >  arch/arm/include/asm/arch-tegra210/pinmux.h   |  394 ++
> >  arch/arm/include/asm/arch-tegra30/pinmux.h|  381 ++
> >  arch/arm/mach-tegra/Kconfig   |   16 +-
> >  arch/arm/mach-tegra/Makefile  |1 -
> >  arch/arm/mach-tegra/board.c   |6 +-
> >  arch/arm/mach-tegra/board2.c  |2 +-
> >  arch/arm/mach-tegra/tegra114/Makefile |2 +-
> >  arch/arm/mach-tegra/tegra124/Makefile |2 -
> >  arch/arm/mach-tegra/tegra20/Makefile  |2 +-
> >  arch/arm/mach-tegra/tegra210/Makefile |1 -
> >  arch/arm/mach-tegra/tegra30/Makefile  |2 +-
> >  board/asus/grouper/grouper.c  |   18 -
> >  board/asus/grouper/pinmux-config-grouper.h|  362 --
> >  .../pinmux-config-transformer.h   |  365 --
> >  board/asus/transformer-t30/transformer-t30.c  |   23 -
> >  board/compal/paz00/Makefile   |8 -
> >  board/compal/paz00/paz00.c|   53 -
> >  board/htc/endeavoru/endeavoru.c   |   14 -
> >  board/htc/endeavoru/pinmux-config-endeavoru.h |  362 --
> >  board/lg/x3-t30/Kconfig   |   12 -
> >  board/lg/x3-t30/configs/p880.config   |1 -
> >  board/lg/x3-t30/configs/p895.config   |1 -
> >  board/lg/x3-t30/pinmux-config-x3.h|  449 ---
> >  board/lg/x3-t30/x3-t30.c  |   23 -
> >  configs/paz00_defconfig   |3 +
> >  drivers/pinctrl/Kconfig   |1 +
> >  drivers/pinctrl/Makefile  |1 +
> >  drivers/pinctrl/tegra/Kconfig |   18 +
> >  drivers/pinctrl/tegra/Makefile|   16 +
> >  .../pinctrl/tegra/funcmux-tegra114.c  |0
> >  .../pinctrl/tegra/funcmux-tegra124.c  |0
> >  .../pinctrl/tegra/funcmux-tegra20.c   |0
> >  .../pinctrl/tegra/funcmux-tegra210.c  |0
> >  .../pinctrl/tegra/funcmux-tegra30.c   |0
> >  drivers/pinctrl/tegra/pinctrl-tegra.c |  248 
> >  drivers/pinctrl/tegra/pinctrl-tegra20.c   |  177 +++
> >  .../pinctrl/tegra}/pinmux-common.c|0
> >  .../pinctrl/tegra/pinmux-tegra114.c   |0
> >  .../pinctrl/tegra/pinmux-tegra124.c   |0
> >  .../pinctrl/tegra/pinmux-tegra20.c|0
> >  drivers/pinctrl/tegra/pinmux-tegra210.c   |  190 +++
> >  .../pinctrl/tegra/pinmux-tegra30.c|0
> >  include/configs/x3-t30.h  |   13 +-
> >  63 files changed, 8920 insertions(+), 1723 

Re: [PATCH 00/21] Qualcomm generic board support

[Krzysztof Kozlowski]

On 04/12/2023 15:38, ff wrote:
> 
> 
>> Le 4 déc. 2023 à 12:00, Daniel Thompson  a écrit 
>> :
>>
>> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
>>> + Linux kernel DT bindings maintainers, EBBR ML
>>>
 On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
 On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
> wrote:
>>> I've been thinking about and hacking on this for the last week or so,
>>> sorry for the delayed reply here.
>>>
>>> The value is in preventing any of the existing bindings from regressing,
>
> That is actually best addressed in Linux by checking the DTS against
> yaml DT bindings. We don't have that testing available in u-boot and
> only depend on careful reviews.

 I would absolutely love for someone to make another attempt at updating
 our kbuild infrastucture so that we can run the validation targets.

>>>
>>> Given that EBBR requires [1] the platform (firmware/bootloader) and
>>> not OS to supply the devicetree, it becomes evident that
>>> firmware/bootloaders import DTS from Linux kernel (where it is
>>> maintained).
>>>
>>> But currently u-boot doesn't have a proper way to validate those DTS
>>> against DT bindings (maintained in Linux kernel). Although there are
>>> Devicetree schema tools available here [2], there isn't a versioned
>>> release package of DT bindings which one should use to validate DTS
>>> files.
>>
>> The kernel is regularly released in multiple forms (including git
>> tags and tarball). Why isn't the kernel itself sufficient to be a
>> versioned release of the DT bindings directory?
>>
> The Linux kernel may not see all devices. For instance it could see a PCI 
> port while the firmware sees a SERDES that is configured to match the board 
> implementation and touting. The firmware shall be responsible to, statically 
> or dynamically make those things available to the kernel. 
> An OS distribution  (not necessarily Linux) should not embedded all possible 
> combinations and know all derived boards. 

Which is nothing related to the discussion here: bindings. The bindings
*MUST* cover PCI port and serdes.

P.S. Please wrap your replies to match mailing list style / netiquette.

Best regards,
Krzysztof

Re: [PATCH 00/21] Qualcomm generic board support

[ff]

> Le 4 déc. 2023 à 12:00, Daniel Thompson  a écrit :
> 
> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
>> + Linux kernel DT bindings maintainers, EBBR ML
>> 
>>> On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
>>> On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
 On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
 wrote:
>> I've been thinking about and hacking on this for the last week or so,
>> sorry for the delayed reply here.
>> 
>> The value is in preventing any of the existing bindings from regressing,
 
 That is actually best addressed in Linux by checking the DTS against
 yaml DT bindings. We don't have that testing available in u-boot and
 only depend on careful reviews.
>>> 
>>> I would absolutely love for someone to make another attempt at updating
>>> our kbuild infrastucture so that we can run the validation targets.
>>> 
>> 
>> Given that EBBR requires [1] the platform (firmware/bootloader) and
>> not OS to supply the devicetree, it becomes evident that
>> firmware/bootloaders import DTS from Linux kernel (where it is
>> maintained).
>> 
>> But currently u-boot doesn't have a proper way to validate those DTS
>> against DT bindings (maintained in Linux kernel). Although there are
>> Devicetree schema tools available here [2], there isn't a versioned
>> release package of DT bindings which one should use to validate DTS
>> files.
> 
> The kernel is regularly released in multiple forms (including git
> tags and tarball). Why isn't the kernel itself sufficient to be a
> versioned release of the DT bindings directory?
> 
The Linux kernel may not see all devices. For instance it could see a PCI port 
while the firmware sees a SERDES that is configured to match the board 
implementation and touting. The firmware shall be responsible to, statically or 
dynamically make those things available to the kernel. 
An OS distribution  (not necessarily Linux) should not embedded all possible 
combinations and know all derived boards. 


> 
> Daniel.
> ___
> boot-architecture mailing list -- boot-architect...@lists.linaro.org
> To unsubscribe send an email to boot-architecture-le...@lists.linaro.org

Re: [PATCH 00/21] Qualcomm generic board support

[ff]

Hi Summit,

Here are additional elements that you may want to consider.

This topic should be thought of with « who provides what » question in mind.

For quite a long time, one single entity was providing secure firmware, 
firmware, boot loader (I think of Grub when I use this overloaded term), and OS.
This explains why the Linux kernel community has been maintaining DT (not 
justifying it is now still a good model).

For Software Defined Vehicle and many other scenarios this supply chain is not 
working.
In the context of this separation, OS/Hypervisor supplying any DTB is a 
non-sense.
(Translated in real life: as a French driver, my DTB description of a car is 
that the steering wheel is on the left hand side. If I get on a UK car, I will 
complain that my hardware description does not match reality. Conclusion: 
better use DTB given from the platform!).
If I am not mistaken Fedora IOT 39 does not come with any DTBs: that was a 
theme hinted by Peter Robinson a while ago (Peter you may want to comment on 
this).

My understanding is that SystemReady was proposed and developed to address such 
a different supply chain where:
- the OS may be supplied by a party not controlling the underlying layers
- have standard contract between OS and previous entities
- The entity controlling the hardware is not an OS but a type-1 hypervisor

In all this context, the DT should be consumed by OSes (Linux, Zephyr, Eclipse 
ThreadX (donated by Microsoft), commercial ones…) and hypervisors.
The "DT » passed to a Linux (be it equivalent to Dom0) may not be the 
definitive vision of the whole platform. You may want to talk with the System 
Device Tree folks.
So there is no such a thing as « THE » device tree of the platform.
There can be a DT for BL33 firmware, a DT for OS/Hypervisor, a DT for TrustZone 
(highly decorated with clocks and power nodes that are often irrelevant to BL33 
and OS/Hypervisor).

The BL33 and OS/Hypervisor DTs location is not defined by EBBR but my view is 
that the OS/Hypervisor DT can be located in the HW_CONFIG section of a FIP 
(this section is made for holding the OS DT).
The FIP can come from the SoC vendor, later updated by the Board vendor:

fiptool --hw-config 

With a separate signing key.

So, you should take into account which markets are targeted by the SoC for 
which you posted your message.
If it is traditional embedded, one-entity provides all. You can surely choose 
any scheme you want.
If it is automotive and other markets where there will be separation in the 
firmware/OS/Hypervisor supply chain, then you should clearly attach the DT to 
Secure Firmware.


Cheers

FF

PS1: I see an analogy with Google project Trebble which set clear 
responsibilities in who can provide/modify what. Before it, it was the jungle 
and pushing a security fix required months of delays. Now a Google security fix 
can make its way to smartphones in matter of days. Constraining a little bit 
the Linux driver developers to what should they focus on (nice drivers and not 
hardware description) will just make things better. Failure to do so will just 
push for ACPI and its horrible complex, fragile virtual machine to push out DT 
from those markets...
PS2: By « nice" drivers I mean, for instance,  drivers that do not assume they 
are alone in the world and can do whatever they want with clocks that feed the 
device: they should use proper clock control such as SCMI (trouble for device 
assignment to a VM for instance).


Le 4 déc. 2023 à 06:32, Sumit Garg  a écrit :

+ Linux kernel DT bindings maintainers, EBBR ML

On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:

On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  wrote:

On 29/11/2023 16:34, Caleb Connolly wrote:


On 23/11/2023 07:04, Sumit Garg wrote:
On Wed, 22 Nov 2023 at 21:34, Caleb Connolly  wrote:



On 22/11/2023 14:27, Tom Rini wrote:
On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote:
On Wed, 22 Nov 2023 at 19:31, Tom Rini  wrote:

On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote:
Hi Caleb,

On Tue, 21 Nov 2023 at 22:39, Caleb Connolly  wrote:
[snip]
== DT loading ==

Previously, boards used the FDT blob embedded into U-Boot (via
OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary
bootloader, so we can instead rely on the first-stage bootloader to
populate some useful FDT properties for us (notably the /memory node and
KASLR seed) and fetch the DTB that it provides. Combined with the memory
map changes above, this let's us entirely avoid configuring the memory
map explicitly.

Since with this change, we don't need to embed FDT blob in the u-boot
binary, so I was thinking if we really need to import DTs from Linux
for different platforms and then play a catchup game?

For now, yes.

But why? Is there any value added by larger u-boot specific DT (most
of the nodes being unused by u-boot) than what currently u-boot
supports? The more important part is to get 

Re: Setting up boot chain ACPI on ARM with STM32MPU

[Ba Gia Bao Phan]

>
> Sort-of...the refactoring to allow ACPI tables on ARM is completed,
> but I don't think any U-Boot board uses this.

Hello, could you tell me more details about this topic? Which platform ARM
are ACPI tables enabled for?

Le mer. 29 nov. 2023 à 20:28, Simon Glass  a écrit :

> +Heinrich Schuchardt
>
> Hi,
>
> On Wed, 29 Nov 2023 at 08:29, Ba Gia Bao Phan
>  wrote:
> >
> > Hello everyone,
> >
> > I am a trainee at STMicroelectronics France. I am working on a project
> "Setting up a boot chain ACPI" for STM32MPU, which is based on ARM Cortex-A
> . The objective of my project is to add a way of booting (with ACPI)
> besides Device Tree available on STM32MPU.
> >
> > I found that ACPI was enabled on some x86 platforms but I don't know
> whether it was set up on ARM or not. I found a PATCH that discussed
> Enabling ACPI booting on ARM with Raspberry Pi 4 but I don't know if it
> functioned or not. Did anyone here succeed in setting up ACPI on ARM by
> U-boot?
>
> Sort-of...the refactoring to allow ACPI tables on ARM is completed,
> but I don't think any U-Boot board uses this.
>
> >
> > What are the differences between x86 and ARM platforms when enabling
> ACPI? The architecture of my board STM32PMU is ARM so can I apply the
> technique used on platform x86 for my board?
>
> Firstly I wonder why you want ACPI?
>
> Secondly, if you have the tables somewhere it should be easy enough to
> build them, building on the series you pointed to. Heinrich is
> interested in this, I think. I can help with advice. I have been
> toying with going back to that rpi series but have not done so yet.
>
> Regards,
> Simon
>


-- 
PHAN Ba Gia Bao
Etudiant en 5A STI - INSA Centre Val de Loire

Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0

[Alessandro Rubini]

> But what about the bad block markers , do they get erased when you write 
> this U-Boot image into the NAND ?

The image includes OOB data, because the rom-mandated map is different
from normal standards. If OOB is zeroed, blocks appear as bad (correctly!).

By memsetting to 0xff, before filling data structures and checksums, we
get a binary that written with "nand write.raw" works properly (the rom
is happy with the format and boots) but doesn't mark blocks as bad.

[actually, only the first half-a-meg is with-oob, the trailing part is not,
and the image is partly written with "nand write.raw" and partly with
"nand write". Hairy things based on hairy vendor choices in hw/rom]

But tools/mxsboot works fine, and saved my day (or more).

thanks
/alessandro

[PATCH v1 6/8] board: asus: transformer: switch to DM pinmux

[Svyatoslav Ryhel]

Drop the pinmux setup in the board in favor of setting it up in
the device tree. Device tree nodes match nodes used in the Linux
device tree. 

Signed-off-by: Svyatoslav Ryhel 
---
 arch/arm/dts/tegra30-asus-p1801-t.dts | 982 +
 arch/arm/dts/tegra30-asus-tf201.dts   |  45 +
 arch/arm/dts/tegra30-asus-tf300t.dts  |  45 +
 arch/arm/dts/tegra30-asus-tf300tg.dts | 128 +++
 arch/arm/dts/tegra30-asus-tf300tl.dts | 163 +++
 arch/arm/dts/tegra30-asus-tf600t.dts  | 889 
 arch/arm/dts/tegra30-asus-tf700t.dts  |  53 +
 arch/arm/dts/tegra30-asus-transformer.dtsi| 984 ++
 .../pinmux-config-transformer.h   | 365 ---
 board/asus/transformer-t30/transformer-t30.c  |  23 -
 10 files changed, 3289 insertions(+), 388 deletions(-)
 delete mode 100644 board/asus/transformer-t30/pinmux-config-transformer.h

diff --git a/arch/arm/dts/tegra30-asus-p1801-t.dts 
b/arch/arm/dts/tegra30-asus-p1801-t.dts
index 19de984d5f..350443d55e 100644
--- a/arch/arm/dts/tegra30-asus-p1801-t.dts
+++ b/arch/arm/dts/tegra30-asus-p1801-t.dts
@@ -60,6 +60,988 @@
};
};
 
+   pinmux@7868 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_default>;
+
+   state_default: pinmux {
+   /* SDMMC1 pinmux */
+   sdmmc1_clk {
+   nvidia,pins = "sdmmc1_clk_pz0";
+   nvidia,function = "sdmmc1";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   };
+   sdmmc1_cmd {
+   nvidia,pins = "sdmmc1_dat3_py4",
+   "sdmmc1_dat2_py5",
+   "sdmmc1_dat1_py6",
+   "sdmmc1_dat0_py7",
+   "sdmmc1_cmd_pz1";
+   nvidia,function = "sdmmc1";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   };
+   sdmmc1_cd {
+   nvidia,pins = "gmi_iordy_pi5";
+   nvidia,function = "rsvd1";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   };
+   sdmmc1_wp {
+   nvidia,pins = "vi_d11_pt3";
+   nvidia,function = "rsvd2";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   };
+
+   /* SDMMC2 pinmux */
+   vi_d1_pd5 {
+   nvidia,pins = "vi_d1_pd5",
+   "vi_d2_pl0",
+   "vi_d3_pl1",
+   "vi_d5_pl3",
+   "vi_d7_pl5";
+   nvidia,function = "sdmmc2";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   };
+   vi_d8_pl6 {
+   nvidia,pins = "vi_d8_pl6",
+   "vi_d9_pl7";
+   nvidia,function = "sdmmc2";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   nvidia,lock = <0>;
+   nvidia,ioreset = <0>;
+   };
+
+   /* SDMMC3 pinmux */
+   sdmmc3_clk {
+   nvidia,pins = "sdmmc3_clk_pa6";
+   nvidia,function = "sdmmc3";
+   nvidia,pull = ;
+   nvidia,tristate = ;
+   nvidia,enable-input = ;
+   };
+   sdmmc3_cmd {
+   nvidia,pins = "sdmmc3_cmd_pa7",
+   "sdmmc3_dat0_pb7",
+   "sdmmc3_dat1_pb6",
+   "sdmmc3_dat2_pb5",
+   "sdmmc3_dat3_pb4",
+   "sdmmc3_dat4_pd1",
+ 

Re: [PATCH] tools: mxsboot: pre-fill buffer with 0xff, not 0

[Alessandro Rubini]

Hello.

>>> pre-filling with 0xff creates a proper boot loader image, but no
>>> bad-block marker is there when written to flash.

> Isn't there some kobs-ng or whatever tool it was to properly initialize 
> the NAND on MXS ?

I didn't know. I used what u-boot offers, which works for me without
vendor tools -- and dare I say I trust u-boot tools more than vendor
tools?.

The default environment even has the rule to reflash from any
u-boot.nand you manage to put into RAM. The only issue is that
u-boot.nand, as created, marks good blocks as bad by prefilling with
zeores.

thanks
/alessandro

[PATCH] mmc: mediatek: set b_max according CONFIG_SYS_MMC_MAX_BLK_COUNT

[Julien Masson]

The block count limit on MMC based devices should be set according to
CONFIG_SYS_MMC_MAX_BLK_COUNT instead of hardcoding value.

Signed-off-by: Julien Masson 
---
 drivers/mmc/mtk-sd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
index d21a30c954..5a0c61daed 100644
--- a/drivers/mmc/mtk-sd.c
+++ b/drivers/mmc/mtk-sd.c
@@ -1665,7 +1665,7 @@ static int msdc_drv_probe(struct udevice *dev)
if (cfg->f_max < cfg->f_min || cfg->f_max > host->src_clk_freq)
cfg->f_max = host->src_clk_freq;
 
-   cfg->b_max = 1024;
+   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
 
host->mmc = >mmc;
-- 
2.43.0

Re: [PATCH 00/21] Qualcomm generic board support

[Krzysztof Kozlowski]

On 04/12/2023 14:24, Sumit Garg wrote:
> On Mon, 4 Dec 2023 at 16:30, Daniel Thompson  
> wrote:
>>
>> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
>>> + Linux kernel DT bindings maintainers, EBBR ML
>>>
>>> On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
 On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
> wrote:
>>> I've been thinking about and hacking on this for the last week or so,
>>> sorry for the delayed reply here.
>>>
>>> The value is in preventing any of the existing bindings from regressing,
>
> That is actually best addressed in Linux by checking the DTS against
> yaml DT bindings. We don't have that testing available in u-boot and
> only depend on careful reviews.

 I would absolutely love for someone to make another attempt at updating
 our kbuild infrastucture so that we can run the validation targets.

>>>
>>> Given that EBBR requires [1] the platform (firmware/bootloader) and
>>> not OS to supply the devicetree, it becomes evident that
>>> firmware/bootloaders import DTS from Linux kernel (where it is
>>> maintained).
>>>
>>> But currently u-boot doesn't have a proper way to validate those DTS
>>> against DT bindings (maintained in Linux kernel). Although there are
>>> Devicetree schema tools available here [2], there isn't a versioned
>>> release package of DT bindings which one should use to validate DTS
>>> files.
>>
>> The kernel is regularly released in multiple forms (including git
>> tags and tarball). Why isn't the kernel itself sufficient to be a
>> versioned release of the DT bindings directory?
>>
> 
> The Linux kernel may come in various forms (upstream vs stable vs
> vendor). It's difficult to decide from where the DT bindings should
> come from. Should they come from upstream or should they come from the
> kernel which is actually booted onto a particular device?
> 
> IOW, as of now which kernel version should u-boot pick up for DT
> validation checks?

The same version as in case of release from separate DT bindings repo.

> 
> If we can have a separate release cadence for DT bindings then the
> platform (firmware/bootloader) can attest the DTB against that. Later
> one should be able to boot any kernel with the DTB provided by
> platform.

Separate releases of DT bindings change nothing here - you are going to
ask the same question: "which release shall I take"?

So the answer could be the same for both: take latest mainline kernel
release.

You really don't need separate repo just to know which release to take.

Best regards,
Krzysztof

Re: [PATCH 00/21] Qualcomm generic board support

[Sumit Garg]

On Mon, 4 Dec 2023 at 16:30, Daniel Thompson  wrote:
>
> On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
> > + Linux kernel DT bindings maintainers, EBBR ML
> >
> > On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
> > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong 
> > > >  wrote:
> > > > > > I've been thinking about and hacking on this for the last week or 
> > > > > > so,
> > > > > > sorry for the delayed reply here.
> > > > > >
> > > > > > The value is in preventing any of the existing bindings from 
> > > > > > regressing,
> > > >
> > > > That is actually best addressed in Linux by checking the DTS against
> > > > yaml DT bindings. We don't have that testing available in u-boot and
> > > > only depend on careful reviews.
> > >
> > > I would absolutely love for someone to make another attempt at updating
> > > our kbuild infrastucture so that we can run the validation targets.
> > >
> >
> > Given that EBBR requires [1] the platform (firmware/bootloader) and
> > not OS to supply the devicetree, it becomes evident that
> > firmware/bootloaders import DTS from Linux kernel (where it is
> > maintained).
> >
> > But currently u-boot doesn't have a proper way to validate those DTS
> > against DT bindings (maintained in Linux kernel). Although there are
> > Devicetree schema tools available here [2], there isn't a versioned
> > release package of DT bindings which one should use to validate DTS
> > files.
>
> The kernel is regularly released in multiple forms (including git
> tags and tarball). Why isn't the kernel itself sufficient to be a
> versioned release of the DT bindings directory?
>

The Linux kernel may come in various forms (upstream vs stable vs
vendor). It's difficult to decide from where the DT bindings should
come from. Should they come from upstream or should they come from the
kernel which is actually booted onto a particular device?

IOW, as of now which kernel version should u-boot pick up for DT
validation checks?

If we can have a separate release cadence for DT bindings then the
platform (firmware/bootloader) can attest the DTB against that. Later
one should be able to boot any kernel with the DTB provided by
platform.

-Sumit

>
> Daniel.

Re: [PATCH 2/4] watchdog: Add StarFive Watchdog driver

[Stefan Roese]

On 11/6/23 00:13, Chanho Park wrote:

Add to support StarFive watchdog driver. The driver is imported from
linux kernel's drivers/watchdog/starfive-wdt.c without jh7100 support
because there is no support of jh7100 SoC in u-boot yet.
Howver, this patch has been kept the variant coding style because JH7100
can be added later and have a consistency with the linux driver.

Signed-off-by: Chanho Park 


Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/watchdog/Kconfig|   7 +
  drivers/watchdog/Makefile   |   1 +
  drivers/watchdog/starfive_wdt.c | 329 
  3 files changed, 337 insertions(+)
  create mode 100644 drivers/watchdog/starfive_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 07fc4940e918..569726119ca1 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -344,6 +344,13 @@ config WDT_STM32MP
  Enable the STM32 watchdog (IWDG) driver. Enable support to
  configure STM32's on-SoC watchdog.
  
+config WDT_STARFIVE

+   bool "StarFive watchdog timer support"
+   depends on WDT
+   imply WATCHDOG
+   help
+ Enable support for the watchdog timer of StarFive JH7110 SoC.
+
  config WDT_SUNXI
bool "Allwinner sunxi watchdog timer support"
depends on WDT && ARCH_SUNXI
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index eef786f5e74e..5520d3d9ae8a 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -44,6 +44,7 @@ obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
  obj-$(CONFIG_WDT_K3_RTI) += rti_wdt.o
  obj-$(CONFIG_WDT_SL28CPLD) += sl28cpld-wdt.o
  obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
+obj-$(CONFIG_WDT_STARFIVE) += starfive_wdt.o
  obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
  obj-$(CONFIG_WDT_SUNXI) += sunxi_wdt.o
  obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/starfive_wdt.c b/drivers/watchdog/starfive_wdt.c
new file mode 100644
index ..ee9ec4cdc3a4
--- /dev/null
+++ b/drivers/watchdog/starfive_wdt.c
@@ -0,0 +1,329 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Starfive Watchdog driver
+ *
+ * Copyright (C) 2022 StarFive Technology Co., Ltd.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* JH7110 Watchdog register define */
+#define STARFIVE_WDT_JH7110_LOAD   0x000
+#define STARFIVE_WDT_JH7110_VALUE  0x004
+#define STARFIVE_WDT_JH7110_CONTROL0x008   /*
+* [0]: reset enable;
+* [1]: interrupt enable && 
watchdog enable
+* [31:2]: reserved.
+*/
+#define STARFIVE_WDT_JH7110_INTCLR 0x00c   /* clear intterupt and reload 
the counter */
+#define STARFIVE_WDT_JH7110_IMS0x014
+#define STARFIVE_WDT_JH7110_LOCK   0xc00   /* write 0x1ACCE551 to unlock */
+
+/* WDOGCONTROL */
+#define STARFIVE_WDT_ENABLE0x1
+#define STARFIVE_WDT_EN_SHIFT  0
+#define STARFIVE_WDT_RESET_EN  0x1
+#define STARFIVE_WDT_JH7110_RST_EN_SHIFT   1
+
+/* WDOGLOCK */
+#define STARFIVE_WDT_JH7110_UNLOCK_KEY 0x1acce551
+
+/* WDOGINTCLR */
+#define STARFIVE_WDT_INTCLR0x1
+#define STARFIVE_WDT_JH7100_INTCLR_AVA_SHIFT   1   /* Watchdog can clear 
interrupt when 0 */
+
+#define STARFIVE_WDT_MAXCNT0x
+#define STARFIVE_WDT_DEFAULT_TIME  (15)
+#define STARFIVE_WDT_DELAY_US  0
+#define STARFIVE_WDT_TIMEOUT_US1
+
+/* module parameter */
+#define STARFIVE_WDT_EARLY_ENA 0
+
+struct starfive_wdt_variant {
+   unsigned int control;   /* Watchdog Control Resgister for reset 
enable */
+   unsigned int load;  /* Watchdog Load register */
+   unsigned int reload;/* Watchdog Reload Control register */
+   unsigned int enable;/* Watchdog Enable Register */
+   unsigned int value; /* Watchdog Counter Value Register */
+   unsigned int int_clr;   /* Watchdog Interrupt Clear Register */
+   unsigned int unlock;/* Watchdog Lock Register */
+   unsigned int int_status;/* Watchdog Interrupt Status Register */
+
+   u32 unlock_key;
+   char enrst_shift;
+   char en_shift;
+   bool intclr_check;  /*  whether need to check it before 
clearing interrupt */
+   char intclr_ava_shift;
+   bool double_timeout;/* The watchdog need twice timeout to 
reboot */
+};
+
+struct starfive_wdt_priv {
+   void __iomem *base;
+   struct clk *core_clk;
+   struct clk *apb_clk;
+   struct reset_ctl_bulk *rst;
+   const struct starfive_wdt_variant *variant;
+   unsigned long freq;
+   u32 count;  /* count of timeout */
+   u32 reload;  

Re: [PATCH V3 3/3] configs: andes: add the fdt blob address for SPL copy to

[Leo Liang]

On Thu, Nov 16, 2023 at 09:01:36PM +0800, Randolph wrote:
> Add the address where the FDT blob should be moved.
> 
> Signed-off-by: Randolph 
> ---
>  configs/ae350_rv32_falcon_defconfig | 1 +
>  configs/ae350_rv32_falcon_xip_defconfig | 1 +
>  configs/ae350_rv64_falcon_defconfig | 1 +
>  configs/ae350_rv64_falcon_xip_defconfig | 1 +
>  4 files changed, 4 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH V3 2/3] spl: riscv: falcon: move fdt blob to specified address

[Leo Liang]

On Thu, Nov 16, 2023 at 09:01:35PM +0800, Randolph wrote:
> In Falcon Boot mode, the fdt blob should be move to the RAM from
> kernel BSS section. To avoid being cleared by BSS initialisation.
> SPL_PAYLOAD_ARGS_ADDR is the address where SPL copies.
> 
> Signed-off-by: Randolph 
> ---
>  board/AndesTech/ae350/ae350.c | 25 -
>  common/spl/Kconfig|  2 +-
>  common/spl/spl_opensbi.c  | 16 
>  3 files changed, 17 insertions(+), 26 deletions(-)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH V3 1/3] doc: falcon: riscv: Falcon Mode boot on RISC-V

[Leo Liang]

On Thu, Nov 16, 2023 at 09:01:34PM +0800, Randolph wrote:
> Add documentation to introduce the Falcon Mode on RISC-V.
> In this mode, the boot sequence is SPL -> OpenSBI -> Linux kernel.
> 
> Signed-off-by: Randolph 
> ---
>  doc/develop/falcon.rst | 171 +
>  1 file changed, 171 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH] starfive: visionfive2: add device tree overlay support

[Leo Liang]

On Mon, Nov 20, 2023 at 02:35:31AM +, John Clark wrote:
> device tree overlay support requires fdtoverlay_addr_r to be set
> 
> before
> ~~
> Invalid fdtoverlay_addr_r for loading overlays
> 
> after
> ~
> Retrieving file: /boot/overlay/rtc-ds3231.dtbo
> 
> Signed-off-by: John Clark 
> ---
> 
>  include/configs/starfive-visionfive2.h | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH v4 0/4] bootflow: bootmeth_efi: Fix network efi boot.

[Shantur Rathore]

Hi Simon,

On Sun, Nov 19, 2023 at 4:56 PM Shantur Rathore  wrote:
>
>
> Currently bootmeth_efi crashes while doing a network (dhcp) boot.
> This patch series fixes issues and both network and disk boot works.
>
How can I help to get this patch series merged in?

Kind Regards
Shantur

Re: [PATCH] common: usb-hub: Reset hub port before scanning

[Shantur Rathore]

On Mon, Dec 4, 2023 at 11:05 AM Marek Vasut  wrote:
>
> On 12/4/23 11:59, Shantur Rathore wrote:
> > Hi Marek,
> >
> > On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut  wrote:
> >>
> >> On 12/3/23 22:42, Shantur Rathore wrote:
> >>> Hi Marek,
> >>>
> >>> On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut  wrote:
> 
>  On 11/24/23 01:37, Shantur Rathore wrote:
> > Hi Marek,
> 
>  Hi,
> 
>  sorry for the late reply.
> 
> > In my case RockPro64, the power to usb ports onboard is controlled 
> > by
> > a regulator.
> > This regulator is enabled as part of init  as here
> > https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177
> >
> > On init, the usb devices connected to the port are powered up, in my
> > case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS.
> > But the usb controller is only enabled at 'usb start' and by this 
> > time
> > the device is in some state that it doesn't get detected.
> >
> > One way to make sure the devices connected to the ports are in an
> > initialising state is by issuing a port reset before scanning the
> > port.
> 
>  Why not remove this regulator-always-on and let the PHY driver turn 
>  the
>  VBUS ON only when it is needed ?
> 
>  Wouldn't that solve the problem too AND remove unnecessarily enabled
>  regulator ?
> 
>  [...]
> >>>
> >>> Removing the regulator-always-on does make it work but there are few 
> >>> issues
> >>>
> >>> 1. regulator is used to control power to multiple ports ( USB3.0 and
> >>> USB2.0 in RockPro64 ),
> >>> so this could lead to all ports turning off if a phy resets / turns 
> >>> off power
> >>
> >> I vaguely recall seeing some refcounting patch for regulator subsystem,
> >> would that help ?
> >
> > I don't think this would be a problem for u-boot, but linux maybe.
> 
>  How so ?
> >>>
> >>> Actually, I am wrong. I wasn't sure if there is refcounting for the
> >>> regulator subsystem
> >>> in linux. just found it has so this is null and void.
> >>>
> 
> >>> 2. Even with regulator-always-on and without this reset port patch,
> >>> linux was always
> >>> able to detect the drive on the port, so there is something missing 
> >>> in u-boot.
> >>> 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries
> >>> to reset the port before
> >>> scanning. The comment says
> >>>
> >>> /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
> >>>  * Port warm reset is required to recover
> >>>  */
> >>>
> >>> i. 
> >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736
> >>> ii. 
> >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836
> >>>
> >>> I believe this isn't implemented in u-boot and hence explicit reset of
> >>> a port fixes the issue.
> >>
> >> I feel this is separate issue and what needs to be fixed first is the
> >> hard-wired VBus control.
> >
> > I beg to differ on this, couple of reasons for this
> >
> > 1. The same drive works fine without being reset on the USB2.0 ports - 
> > this
> > confirms that the issue is related to USB3.0 only.
> 
>  This is a separate issue from the hard-wired VBus control. I agree the
>  issue does exist, I would simply like to avoid conflating the hard-wired
>  VBus control with device reset.
> 
> > 2. Linux is able to detect the same drive on USB3.0 when u-boot fails - 
> > this
> > confirms issue doesn't lie with regulator-always-on
> 
>  See above
> 
> > 3. The links I pasted earlier mentions that in USB3.0 the ports need 
> > reset
> > and this is done before the port is scanned. Adding the similar reset 
> > in u-boot
> > fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle
> > this special USB3.0 case and maybe this is why I was finding a few posts
> > around the drive not being detected in the USB3.0 port in u-boot but 
> > works in
> > a USB2.0 port.
> 
>  I am not disputing the need for USB 3.0 device reset, I believe there
>  are two issues here -- one is the hard-wired VBus regulator -- the other
>  is this USB 3.0 reset. They should both be fixed.
> >>>
> >>> Sure, agreed 100%.
> >>> Do we need to fix both at the same time?
> >>> Both patches seem to be independent.
> >>
> >> Separate patch for the regulator please .
> >
> > Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but
> > there seems to be a bug in the rk3399-rockpro64.dtsi from linux where
> > the typec phy
> > is configure with wrong regulator and if I do the patch as below
> >
> > --- 

[PATHv1 9/9] Makefile: add dtbs to clean

[Maxim Uvarov]

CI test checks that generated dtb has to be cleaned up.

Signed-off-by: Maxim Uvarov 
---
 Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 08604ed3c7..8dd6990584 100644
--- a/Makefile
+++ b/Makefile
@@ -2165,7 +2165,8 @@ CLEAN_FILES += include/autoconf.mk* include/bmp_logo.h 
include/bmp_logo_data.h \
   mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
   itb.fit.fit itb.fit.itb itb.map spl.map mkimage-out.rom.mkimage \
   mkimage.rom.mkimage mkimage-in-simple-bin* rom.map simple-bin* \
-  idbloader-spi.img lib/efi_loader/helloworld_efi.S *.itb
+  idbloader-spi.img lib/efi_loader/helloworld_efi.S *.itb \
+  ./*/*.dtb *.dtb
 
 # Directories & files removed with 'make mrproper'
 MRPROPER_DIRS  += include/config include/generated spl tpl vpl \
-- 
2.30.2

[PATHv1 8/9] omap3: rename mem_init

[Maxim Uvarov]

Rename mem_init to solve following compilation error with lwip
integrated code:
+arm-linux-gnueabi-ld.bfd: net/lwip/lwip-external/src/core/mem.o: in
  function `mem_init':
+net/lwip/lwip-external/src/core/mem.c:162: multiple definition
  of `mem_init';
  arch/arm/mach-omap2/omap3/sdrc.o:arch/arm/mach-omap2/omap3/
  sdrc.c:240: first defined here
+make[1]: *** [Makefile:1764: u-boot] Error 1
+/opt/gcc-13.1.0-nolibc/arm-linux-gnueabi/bin/../lib/gcc/arm-linux-
  gnueabi/13.1.0/../../
../../arm-linux-gnueabi/bin/ld: net/lwip/lwip-external/src/core/
  mem.o (symbol from
  plugin): in function `mem_init':
+(.text+0x0): multiple definition of `mem_init'; arch/arm/mach-omap2/
  omap3/emif4.o
  (symbol from plugin):(.text+0x0): first defined here
+collect2: error: ld returned 1 exit status
+(.text+0x0): multiple definition of `mem_init'; arch/arm/mach-omap2/
  omap3/sdrc.o
  (symbol from plugin):(.text+0x0): first defined here
+Image 'simple-bin' is missing external blobs and is non-functional:
   tee-os
+/binman/simple-bin/fit/images/op-tee/tee-os (tee-os):

Signed-off-by: Maxim Uvarov 
Reviewed-by: Tom Rini 
---
 arch/arm/include/asm/arch-omap3/mem.h | 2 +-
 arch/arm/mach-omap2/omap3/board.c | 2 +-
 arch/arm/mach-omap2/omap3/emif4.c | 4 ++--
 arch/arm/mach-omap2/omap3/sdrc.c  | 6 +++---
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap3/mem.h 
b/arch/arm/include/asm/arch-omap3/mem.h
index 569779c55e..fce3568eca 100644
--- a/arch/arm/include/asm/arch-omap3/mem.h
+++ b/arch/arm/include/asm/arch-omap3/mem.h
@@ -475,7 +475,7 @@ enum {
 #ifndef __ASSEMBLY__
 
 /* Function prototypes */
-void mem_init(void);
+void omap3_mem_init(void);
 
 u32 is_mem_sdr(void);
 u32 mem_ok(u32 cs);
diff --git a/arch/arm/mach-omap2/omap3/board.c 
b/arch/arm/mach-omap2/omap3/board.c
index 8b70251457..c76a95dd5d 100644
--- a/arch/arm/mach-omap2/omap3/board.c
+++ b/arch/arm/mach-omap2/omap3/board.c
@@ -216,7 +216,7 @@ void s_init(void)
 void board_init_f(ulong dummy)
 {
early_system_init();
-   mem_init();
+   omap3_mem_init();
/*
* Save the boot parameters passed from romcode.
* We cannot delay the saving further than this,
diff --git a/arch/arm/mach-omap2/omap3/emif4.c 
b/arch/arm/mach-omap2/omap3/emif4.c
index 7e5a281922..4fbfb387ab 100644
--- a/arch/arm/mach-omap2/omap3/emif4.c
+++ b/arch/arm/mach-omap2/omap3/emif4.c
@@ -159,10 +159,10 @@ int dram_init_banksize(void)
 }
 
 /*
- * mem_init() -
+ * omap3_mem_init() -
  *  - Initialize memory subsystem
  */
-void mem_init(void)
+void omap3_mem_init(void)
 {
do_emif4_init();
 }
diff --git a/arch/arm/mach-omap2/omap3/sdrc.c b/arch/arm/mach-omap2/omap3/sdrc.c
index 5d43e7c9cf..f2a0769b9d 100644
--- a/arch/arm/mach-omap2/omap3/sdrc.c
+++ b/arch/arm/mach-omap2/omap3/sdrc.c
@@ -4,7 +4,7 @@
  *
  * This file has been created after exctracting and consolidating
  * the SDRC related content from mem.c and board.c, also created
- * generic init function (mem_init).
+ * generic init function (omap3_mem_init).
  *
  * Copyright (C) 2004-2010
  * Texas Instruments Incorporated - https://www.ti.com/
@@ -232,11 +232,11 @@ int dram_init_banksize(void)
 }
 
 /*
- * mem_init -
+ * map3_mem_init -
  *  - Init the sdrc chip,
  *  - Selects CS0 and CS1,
  */
-void mem_init(void)
+void omap3_mem_init(void)
 {
/* only init up first bank here */
do_sdrc_init(CS0, EARLY_INIT);
-- 
2.30.2

[PATHv1 7/9] bcm_ns3: fix overlap define with lwip

[Maxim Uvarov]

Rename declaration to not overlap with lwip.

aarch64:  +   bcm_ns3
+In file included from net/lwip/lwip-external/src/include/lwip/etharp.h:53,
+ from net/lwip/lwip-external/src/core/init.c:55:
+net/lwip/lwip-external/src/include/lwip/prot/ethernet.h:69:
  error: "ETH_ADDR" redefined [-Werror]
+   69 | #define ETH_ADDR(b0, b1, b2, b3, b4, b5) {{b0, b1, b2, b3, b4, b5}}
+  |
+In file included from include/config.h:3,
+ from arch/arm/include/asm/string.h:4,
+ from include/linux/string.h:21,
+ from include/malloc.h:369,
+ from include/stdlib.h:9,
+ from net/lwip/lwip-external/src/include/lwip/arch.h:83,
+ from net/lwip/lwip-external/src/include/lwip/debug.h:40,
+ from net/lwip/lwipopts.h:93,
+ from net/lwip/lwip-external/src/include/lwip/opt.h:51,
+ from net/lwip/lwip-external/src/core/init.c:38:
+include/configs/bcm_ns3.h:52: note: this is the location of the previous 
definition
+   52 | #define ETH_ADDR

Signed-off-by: Maxim Uvarov 
Reviewed-by: Tom Rini 
---
 include/configs/bcm_ns3.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/bcm_ns3.h b/include/configs/bcm_ns3.h
index 47de4bc201..7c6e0725a6 100644
--- a/include/configs/bcm_ns3.h
+++ b/include/configs/bcm_ns3.h
@@ -45,11 +45,11 @@
 #define PCIE_ARGS "pcie_args=pci=pcie_bus_safe pcie_ports=native 
vfio_pci.disable_idle_d3=1\0"
 
 #ifdef CONFIG_BCM_SF2_ETH
-#define ETH_ADDR "ethaddr=00:0A:F7:95:65:A4\0"
+#define BCM_ETH_ADDR "ethaddr=00:0A:F7:95:65:A4\0"
 #define NET_ARGS "bgmac_platform.ethaddr=${ethaddr} " \
"ip=${ipaddr}::${gatewayip}:${netmask}::${ethif}:off"
 #else
-#define ETH_ADDR
+#define BMC_ETH_ADDR
 #define NET_ARGS
 #endif
 
@@ -749,7 +749,7 @@
OS_LOG_LEVEL \
EXTRA_ARGS \
PCIE_ARGS \
-   ETH_ADDR \
+   BMC_ETH_ADDR \
RESERVED_MEM \
SETBOOTARGS \
UPDATEME_FLASH_PARAMS \
-- 
2.30.2

[PATHv1 6/9] mach-socfpga: do not overlap defines with lwip

[Maxim Uvarov]

Fix compilation issue with overlapping lwip and march defines.

Signed-off-by: Maxim Uvarov 
---
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 6 --
 arch/arm/mach-socfpga/wrap_handoff_soc64.c | 9 +
 2 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h 
b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
index 902fc6bfb5..9b85e5865b 100644
--- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
@@ -78,12 +78,6 @@
 
 #ifndef __ASSEMBLY__
 #include 
-enum endianness {
-   LITTLE_ENDIAN = 0,
-   BIG_ENDIAN,
-   UNKNOWN_ENDIANNESS
-};
-
 int socfpga_get_handoff_size(void *handoff_address);
 int socfpga_handoff_read(void *handoff_address, void *table, u32 table_len);
 #endif
diff --git a/arch/arm/mach-socfpga/wrap_handoff_soc64.c 
b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
index e7cb5ea89c..df0701ec85 100644
--- a/arch/arm/mach-socfpga/wrap_handoff_soc64.c
+++ b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
@@ -10,6 +10,15 @@
 #include 
 #include "log.h"
 
+#ifndef __ASSEMBLY__
+#include 
+enum endianness {
+   LITTLE_ENDIAN = 0,
+   BIG_ENDIAN,
+   UNKNOWN_ENDIANNESS
+};
+#endif
+
 static enum endianness check_endianness(u32 handoff)
 {
switch (handoff) {
-- 
2.30.2

[PATHv1 5/9] driver/net/rtl8139: remove debug print

[Maxim Uvarov]

debug print delays reset of the driver. Finally I see
bunch of "rx error " errors in the screen. CI can
not handle many prints. While network works fine there

Reproduced with:
make CROSS_COMPILE=sh2-linux- r2dplus_defconfig all
qemu-system-sh4 -M r2d -nographic -serial null \
-serial mon:stdio -net user,tftp=`pwd` \
-net nic,model=rtl8139 -kernel ./u-boot.bin

Signed-off-by: Maxim Uvarov 
---
 drivers/net/rtl8139.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/rtl8139.c b/drivers/net/rtl8139.c
index 106bc1c7ae..d8f24ec81a 100644
--- a/drivers/net/rtl8139.c
+++ b/drivers/net/rtl8139.c
@@ -453,7 +453,7 @@ static int rtl8139_recv_common(struct rtl8139_priv *priv, 
unsigned char *rxdata,
  RTL_STS_RXBADALIGN)) ||
(rx_size < ETH_ZLEN) ||
(rx_size > ETH_FRAME_LEN + 4)) {
-   printf("rx error %hX\n", rx_status);
+   debug("rx error %hX\n", rx_status);
/* this clears all interrupts still pending */
rtl8139_reset(priv);
return 0;
-- 
2.30.2

[PATHv1 4/9] sandbox: eth-raw-os: successful return code is 0

[Maxim Uvarov]

all network drivers return 0 on the successful
transmission.

Signed-off-by: Maxim Uvarov 
Reviewed-by: Simon Glass 
---
 arch/sandbox/cpu/eth-raw-os.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sandbox/cpu/eth-raw-os.c b/arch/sandbox/cpu/eth-raw-os.c
index e59b96be5f..92c35aed95 100644
--- a/arch/sandbox/cpu/eth-raw-os.c
+++ b/arch/sandbox/cpu/eth-raw-os.c
@@ -256,7 +256,7 @@ int sandbox_eth_raw_os_send(void *packet, int length,
   strerror(errno));
return -errno;
}
-   return retval;
+   return 0;
 }
 
 int sandbox_eth_raw_os_recv(void *packet, int *length,
-- 
2.30.2

[PATHv1 3/9] net/smc911x: fix return from smc911x_send

[Maxim Uvarov]

return value of smc911x_send is ignored, but on sucesseful
send we need return 0 and or error -ETIMEOUT, not opposite.

Signed-off-by: Maxim Uvarov 
Reviewed-by: Tom Rini 
---
 drivers/net/smc911x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 5c5ad8b84a..616b7ce174 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -403,7 +403,7 @@ static int smc911x_send(struct udevice *dev, void *packet, 
int length)
 
ret = smc911x_send_common(priv, packet, length);
 
-   return ret ? 0 : -ETIMEDOUT;
+   return ret ? -ETIMEDOUT : 0;
 }
 
 static int smc911x_recv(struct udevice *dev, int flags, uchar **packetp)
-- 
2.30.2

[PATHv1 2/9] net: sandbox: fix NULL pointer derefences

[Maxim Uvarov]

Add additional checks for NULL pointers.

Signed-off-by: Maxim Uvarov 
---
 drivers/net/sandbox.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/sandbox.c b/drivers/net/sandbox.c
index 13022addb6..d91935e032 100644
--- a/drivers/net/sandbox.c
+++ b/drivers/net/sandbox.c
@@ -65,6 +65,9 @@ int sandbox_eth_arp_req_to_reply(struct udevice *dev, void 
*packet,
struct ethernet_hdr *eth_recv;
struct arp_hdr *arp_recv;
 
+   if (!priv)
+   return -EAGAIN;
+
if (ntohs(eth->et_protlen) != PROT_ARP)
return -EAGAIN;
 
-- 
2.30.2

[PATHv1 1/9] test_net: print out net list

[Maxim Uvarov]

Printing net list is useful in CI log files.

Signed-off-by: Maxim Uvarov 
---
 test/py/tests/test_net.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/test/py/tests/test_net.py b/test/py/tests/test_net.py
index b2241ae6a4..cd5b791a6a 100644
--- a/test/py/tests/test_net.py
+++ b/test/py/tests/test_net.py
@@ -96,6 +96,8 @@ def test_net_pre_commands(u_boot_console):
 if init_pci:
 u_boot_console.run_command('pci enum')
 
+u_boot_console.run_command('net list')
+
 @pytest.mark.buildconfigspec('cmd_dhcp')
 def test_net_dhcp(u_boot_console):
 """Test the dhcp command.
-- 
2.30.2

[PATHv1 0/9] net fixes prior lwip

[Maxim Uvarov]

Add small net fixes prior lwip patch.

CI for this patch set:
https://dev.azure.com/u-boot/u-boot/_build/results?buildId=7460=results

Maxim Uvarov (9):
  test_net: print out net list
  net: sandbox: fix NULL pointer derefences
  net/smc911x: fix return from smc911x_send
  sandbox: eth-raw-os: successful return code is 0
  driver/net/rtl8139: remove debug print
  mach-socfpga: do not overlap defines with lwip
  bcm_ns3: fix overlap define with lwip
  omap3: rename mem_init
  Makefile: add dtbs to clean

 Makefile   | 3 ++-
 arch/arm/include/asm/arch-omap3/mem.h  | 2 +-
 arch/arm/mach-omap2/omap3/board.c  | 2 +-
 arch/arm/mach-omap2/omap3/emif4.c  | 4 ++--
 arch/arm/mach-omap2/omap3/sdrc.c   | 6 +++---
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 6 --
 arch/arm/mach-socfpga/wrap_handoff_soc64.c | 9 +
 arch/sandbox/cpu/eth-raw-os.c  | 2 +-
 drivers/net/rtl8139.c  | 2 +-
 drivers/net/sandbox.c  | 3 +++
 drivers/net/smc911x.c  | 2 +-
 include/configs/bcm_ns3.h  | 6 +++---
 test/py/tests/test_net.py  | 2 ++
 13 files changed, 29 insertions(+), 20 deletions(-)

-- 
2.30.2

Re: EFI memory allocation

[Ilias Apalodimas]

Hi Simon

On Sun, 3 Dec 2023 at 19:44, Simon Glass  wrote:
>
> Hi Heinrich, Ilias,
>
> I had a bit of a look at how memory is allocated in EFI.
>
> I see that efi_memory_init() is called quite early in U-Boot. It
> sometimes allocates memory for a bounce buffer, placing it somewhere
> in memory. How do we know that that memory is free and not being used
> by U-Boot?
>
> To answer my own question, it excludes U-Boot's malloc() region from
> the map, so that it cannot overwrite that.
>
> But then, what if we use lmb and start loading images into memory.
> Won't that conflict with EFI?

Yes, Heinrich tried to fix parts of this with commit 06d514d77c37 and
we have a 'todo' in the efi subsystem for a few years now [0]
Michal (+cc'ed) has also pinged me for similar issues in the past.

>
> I also see that efi_allocate_pages() is called to allocate memory in
> the EFI code. But this just grabs memory from 'anywhere'...it doesn't
> respect the U-Boot malloc region.
>
> It seems to me that most of the memory allocation in EFI should be
> done using malloc(). Of course the boot services need to
> efi_allocate_pages(), etc., but I am not sure that the internal tables
> should be skipping malloc()?
>
> What do you think?

I think that LMB, EFI and the whole memory reservations is a bit of a
mess. Tom and I discussed this a bit in the past but I'll start
working on it.
It needs fixing, but without looking at the code first, I can't
provide any useful feedback

[0] https://source.denx.de/u-boot/custodians/u-boot-efi/-/issues/2

Thanks
/Ilias
>
> Regards,
> Simon

Re: [PATCH] efi_loader: use event callback for initrd deregistration

[Ilias Apalodimas]

Thanks for cleaning this up!

On Mon, 4 Dec 2023 at 06:31, Masahisa Kojima  wrote:
>
> Currently efi_initrd_deregister() is called in bootefi.c
> when the image started from bootefi command returns.
> Since efi_guid_event_group_return_to_efibootmgr event is
> implemented, so let's use this event for invoking
> initrd deregistration.
>
> Signed-off-by: Masahisa Kojima 
> ---
> Note that this patch can be applied to u-boot/next.
> This patch requires the patch e0d1a1ea68("efi_loader: add return to 
> efibootmgr event group")
>
>  cmd/bootefi.c|  5 --
>  lib/efi_loader/efi_load_initrd.c | 82 +---
>  2 files changed, 55 insertions(+), 32 deletions(-)

Reviewed-by: Ilias Apalodimas 
Tested-by: Ilias Apalodimas 

>
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 4d74969ad6..e52bd3f743 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -390,11 +390,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t handle, 
> void *load_options)
>  out:
> free(load_options);
>
> -   if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD)) {
> -   if (efi_initrd_deregister() != EFI_SUCCESS)
> -   log_err("Failed to remove loadfile2 for initrd\n");
> -   }
> -
> /* Notify EFI_EVENT_GROUP_RETURN_TO_EFIBOOTMGR event group. */
> list_for_each_entry(evt, _events, link) {
> if (evt->group &&
> diff --git a/lib/efi_loader/efi_load_initrd.c 
> b/lib/efi_loader/efi_load_initrd.c
> index 193433782c..7ca7785c04 100644
> --- a/lib/efi_loader/efi_load_initrd.c
> +++ b/lib/efi_loader/efi_load_initrd.c
> @@ -184,6 +184,50 @@ out:
> return ret;
>  }
>
> +/**
> + * efi_initrd_deregister() - delete the handle for loading initial RAM disk
> + *
> + * This will delete the handle containing the Linux specific vendor device
> + * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
> + *
> + * Return: status code
> + */
> +efi_status_t efi_initrd_deregister(void)
> +{
> +   efi_status_t ret;
> +
> +   if (!efi_initrd_handle)
> +   return EFI_SUCCESS;
> +
> +   ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
> +/* initramfs */
> +
> _guid_device_path,
> +_lf2_handle,
> +/* LOAD_FILE2 */
> +
> _guid_load_file2_protocol,
> +_lf2_protocol,
> +NULL);
> +   efi_initrd_handle = NULL;
> +
> +   return ret;
> +}
> +
> +/**
> + * efi_initrd_return_notify() - return to efibootmgr callback
> + *
> + * @event: the event for which this notification function is registered
> + * @context:   event context
> + */
> +static void EFIAPI efi_initrd_return_notify(struct efi_event *event,
> + void *context)
> +{
> +   efi_status_t ret;
> +
> +   EFI_ENTRY("%p, %p", event, context);
> +   ret = efi_initrd_deregister();
> +   EFI_EXIT(ret);
> +}
> +
>  /**
>   * efi_initrd_register() - create handle for loading initial RAM disk
>   *
> @@ -197,6 +241,7 @@ out:
>  efi_status_t efi_initrd_register(void)
>  {
> efi_status_t ret;
> +   struct efi_event *event;
>
> /*
>  * Allow the user to continue if Boot file path is not set for
> @@ -215,34 +260,17 @@ efi_status_t efi_initrd_register(void)
>
> _guid_load_file2_protocol,
>_lf2_protocol,
>NULL);
> +   if (ret != EFI_SUCCESS) {
> +   log_err("installing EFI_LOAD_FILE2_PROTOCOL failed\n");
> +   return ret;
> +   }
>
> -   return ret;
> -}
> -
> -/**
> - * efi_initrd_deregister() - delete the handle for loading initial RAM disk
> - *
> - * This will delete the handle containing the Linux specific vendor device
> - * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
> - *
> - * Return: status code
> - */
> -efi_status_t efi_initrd_deregister(void)
> -{
> -   efi_status_t ret;
> -
> -   if (!efi_initrd_handle)
> -   return EFI_SUCCESS;
> -
> -   ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
> -/* initramfs */
> -
> _guid_device_path,
> -_lf2_handle,
> -/* LOAD_FILE2 */
> -
> _guid_load_file2_protocol,
> -  

Re: [PATCH v2] riscv: Add support for AMD/Xilinx MicroBlaze V

[Leo Liang]

On Mon, Nov 06, 2023 at 12:56:47PM +0100, Michal Simek wrote:
> MicroBlaze V is new AMD/Xilinx soft-core 32bit RISC-V processor IP.
> It is hardware compatible with classic MicroBlaze processor.
> 
> The patch contains initial wiring and configuration for initial HW design
> with memory, cpu, interrupt controller, timers and uartlite console
> (interrupt controller is listed but U-Boot is not using it).
> 
> Provided DT is just describing one configuration and should be taken only
> as example.
> 
> Signed-off-by: Michal Simek 
> ---
> 
> Changes in v2:
> - Extend commit message
> - DT changes, add interrupt controller, check agains dt schema
> - The patch for amd,mbv32 compatible string is here
> https://lore.kernel.org/r/d442d916204d26f82c1c3a924a4cdfb117960e1b.1699270661.git.michal.si...@amd.com
> - The patch for board compatibility is here
> https://lore.kernel.org/r/50c277c92c41a582ef171fb75efc6a6a4f860be2.1699271616.git.michal.si...@amd.com
> 
> xlnx,xps-intc-1.00.a driver exists in the Linux kernel but DT binding is
> missing. That's something what we need to work on.
> arch/arm64/boot/dts/xilinx/xilinx-mbv32.dtb: 
> /axi/interrupt-controller@4120: failed to match any schema with 
> compatible: ['xlnx,xps-intc-1.00.a']
> 
> Public annoucement is available here if someone is interested.
> https://www.xilinx.com/products/design-tools/microblaze-v.html?utm_source=marketo_medium=email_campaign=EN-EM-2023-11-02-New-MicroBlaze-V-Processor_term=btn_tok=NDA5LVdZWC03MjQAAAGPMMJYuPPscCags7WdvOeUSWy-_mC9aOwrobFaZRf5ok_eHoQUvTLBzJdHrkcBId9tQ4a-odfnU91WjUkIxx-iSG4OKGofjK5iZcAiK_VN8_xK
> 
> ---
>  arch/riscv/Kconfig   |   4 +
>  arch/riscv/dts/Makefile  |   2 +
>  arch/riscv/dts/xilinx-mbv32.dts  | 106 +++
>  board/xilinx/Kconfig |   3 +-
>  board/xilinx/common/board.c  |   5 ++
>  board/xilinx/mbv/Kconfig |  28 +++
>  board/xilinx/mbv/MAINTAINERS |   7 ++
>  board/xilinx/mbv/Makefile|   5 ++
>  board/xilinx/mbv/board.c |  11 +++
>  configs/xilinx_mbv32_defconfig   |  30 
>  configs/xilinx_mbv32_smode_defconfig |  32 
>  include/configs/xilinx_mbv.h |   6 ++
>  12 files changed, 238 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/dts/xilinx-mbv32.dts
>  create mode 100644 board/xilinx/mbv/Kconfig
>  create mode 100644 board/xilinx/mbv/MAINTAINERS
>  create mode 100644 board/xilinx/mbv/Makefile
>  create mode 100644 board/xilinx/mbv/board.c
>  create mode 100644 configs/xilinx_mbv32_defconfig
>  create mode 100644 configs/xilinx_mbv32_smode_defconfig
>  create mode 100644 include/configs/xilinx_mbv.h
 
Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 4/4] configs: visionfive2: Enable watchdog driver

[Leo Liang]

On Mon, Nov 06, 2023 at 08:13:18AM +0900, Chanho Park wrote:
> Enables StarFive Watchdog driver and WDT command.
> 
> Signed-off-by: Chanho Park 
> ---
>  configs/starfive_visionfive2_defconfig | 5 +
>  1 file changed, 5 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 3/4] riscv: dts: jh7110: Add watchdog device tree node

[Leo Liang]

On Mon, Nov 06, 2023 at 08:13:17AM +0900, Chanho Park wrote:
> Adds jh7110 watchdog device tree node.
> 
> Signed-off-by: Chanho Park 
> ---
>  arch/riscv/dts/jh7110.dtsi | 10 ++
>  1 file changed, 10 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [u-boot-gitdm PATCH 2/2] Add some more employers

[Quentin Schulz]

Hi Simon,

On 12/3/23 05:46, Simon Glass wrote:

This looks at the top unknowns:

git log --pretty=%ae v2023.01.. |sed 's/.*@//' |sort |uniq -c |
   sort -nr |
(while read count email; do
if ! grep -q $email u-boot-config/domain-map; then
   echo "$count $email";
fi; done )

It reduces the (Unknown) count from a third to a fifth.

Signed-off-by: Simon Glass 
---

  u-boot-config/domain-map | 38 ++
  1 file changed, 38 insertions(+)

diff --git a/u-boot-config/domain-map b/u-boot-config/domain-map
index 63cb60f..27f1a7e 100644
--- a/u-boot-config/domain-map
+++ b/u-boot-config/domain-map
@@ -18,6 +18,7 @@ amd.com   AMD
  anagramm.de   Anagramm GmbH
  analog.comAnalog Devices
  android.com   Google LLC
+andestech.com  Andes Technology
  arastra.com   Arastra Inc
  areca.com.tw  Areca
  argos-messtechnik.de  Argos Meßtechnik GmbH
@@ -44,6 +45,7 @@ bluewatersys.com  Bluewater Systems
  boeing.comBoeing
  bootlin.com   Bootlin
  boundarydevices.com   Boundary Devices
+bp.renesas.com Renesas Electronics Corporation
  broadcom.com  Broadcom
  brontes3d.com Brontes Technologies
  bt.comBT Group
@@ -51,6 +53,7 @@ bull.net  Bull SAS
  bus-elektronik.de BuS Elektronik
  calxeda.com   Calxeda
  cam.ac.uk University of Cambridge
+canonical.com  Canonical Ltd.
  ccur.com  Concurrent Computer Corporation
  cdi.czCDI.CZ
  celestrius.comCelestrius
@@ -58,6 +61,7 @@ celunite.com  Azingo
  centtech.com  Centaur Technology
  cesa.opbu.xerox.com   Xerox
  chelsio.com   Chelsio
+chromium.org   Google LLC
  cideas.comCustom IDEAS
  cisco.com Cisco
  citi.umich.eduUniv. of Michigan CITI
@@ -78,6 +82,7 @@ cosmosbay.com Cosmosbay Vectis
  cozybit.com   cozybit
  cray.com  Cray
  cse-semaphore.com CSE Semaphore, Inc.
+csgroup.eu CS Group
  csr.com   CSR
  cyberguard.comSecure Computing
  cybernetics.com   Cybernetics
@@ -89,11 +94,13 @@ dell.comDell
  denx.de   DENX Software Engineering
  devicescape.com   Devicescape
  digi.com  Digi International
+dimonoff.com   Dimonoff inc.
  doredevelopment.dkDore Development
  dti2.net  DTI2 - Desarrollo de la tecnologia de las comunicaciones
  e-coninfotech.com e-con Infotech
  ecitele.com   ECI Telecom
  edesix.comEdesix Ltd
+edgeble.ai Edgeble AI
  einstruction.com  eInstruction
  eke.fiEKE-Electronics
  elandigitalsystems.comElan Digital Systems
@@ -119,10 +126,13 @@ feig.de   Feig Electronic
  fixstars.com  Fixstars Technologies
  free-electrons.comBootlin
  freescale.com NXP
+foss.st.comST Microelectronics
+foundries.io   Foundries.io
  fujitsu.com   Fujitsu
  gaisler.com   Gaisler Research
  ganssloser.comIngenieurbuero Ganssloser
  garzik.orgRed Hat
+gateworks.com  Gateworks Corporation
  gdsys.cc  Guntermann & Drunck
  gdsys.de  Guntermann & Drunck
  ge.comGeneral Electric
@@ -140,6 +150,7 @@ hevs.ch HES-SO Valais Wallis
  highpoint-tech.comHighPoint Technologies
  hitachi.co.jp Hitachi
  hitachi.com   Hitachi
+hitachienergy.com  Hitachi
  hitachisoft.jpHitachi
  hp.comHP
  huawei.comHuawei Technologies
@@ -164,10 +175,13 @@ jmicron.com   jmicron.com
  jp.fujitsu.comFujitsu
  juniper.net   Juniper Networks
  katalix.com   Katalix Systems
+kernel-space.org   kernelspace
  keymile.com   Keymile
  keyspan.com   InnoSys
+kwiboo.se  Kwiboo
  kiethp.comIntel
  konsulko.com  Konsulko Group
+kontron.de Kontron
  labxtechnologies.com  Lab X Technologies
  laptop.orgOLPC
  laurelnetworks.comECI Telecom
@@ -176,9 +190,11 @@ linaro.org Linaro
  linutronix.de linutronix
  linux-foundation.org  Linux Foundation
  linuxant.com  Linuxant
+linux.microsoft.comMicrosoft Corporation
  linx.net  London Internet Exchange
  lippert-at.de LiPPERT Embedded Computers GmbH
  lippertembedded.deLiPPERT Embedded Computers GmbH
+lionizers.com  Lionizers
  llnl.gov  Lawrence Livermore National Laboratory
  lnxi.com  Linux Networx
  logitech.com  Logitech
@@ -194,10 +210,14 @@ mandriva.com.br   Mandriva
  marvell.com   

Re: [PATCH 2/4] watchdog: Add StarFive Watchdog driver

[Leo Liang]

On Mon, Nov 06, 2023 at 08:13:16AM +0900, Chanho Park wrote:
> Add to support StarFive watchdog driver. The driver is imported from
> linux kernel's drivers/watchdog/starfive-wdt.c without jh7100 support
> because there is no support of jh7100 SoC in u-boot yet.
> Howver, this patch has been kept the variant coding style because JH7100
> can be added later and have a consistency with the linux driver.
> 
> Signed-off-by: Chanho Park 
> ---
>  drivers/watchdog/Kconfig|   7 +
>  drivers/watchdog/Makefile   |   1 +
>  drivers/watchdog/starfive_wdt.c | 329 
>  3 files changed, 337 insertions(+)
>  create mode 100644 drivers/watchdog/starfive_wdt.c

Reviewed-by: Leo Yu-Chi Liang 

[PATCH 3/3] doc: board: ti: k3: Mention TI_DM argument

[Neha Malcom Francis]

Mention TI_DM argument can be used to fetch a custom DM binary in the
A72 build instructions for K3 devices.

Signed-off-by: Neha Malcom Francis 
---
 doc/board/ti/k3.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/doc/board/ti/k3.rst b/doc/board/ti/k3.rst
index a127215ce5..15916b088f 100644
--- a/doc/board/ti/k3.rst
+++ b/doc/board/ti/k3.rst
@@ -320,6 +320,13 @@ use the `lite` option.
  make CROSS_COMPILE=$CC64 BINMAN_INDIRS=$LNX_FW_PATH \
 BL31=$TFA_PATH/build/k3/$TFA_BOARD/release/bl31.bin \
 TEE=$OPTEE_PATH/out/arm-plat-k3/core/tee-raw.bin
+
+.. note::
+   It is also possible to pick up a custom DM binary by adding TI_DM argument
+   pointing to the file. If not provided, it defaults to picking up the DM
+   binary from ti-linux-firmware. This is only applicable to devices that
+   utilize split firmware.
+
 .. k3_rst_include_end_build_steps_uboot
 
 At this point you should have every binary needed initialize both the
-- 
2.34.1

[PATCH 2/3] arm: dts: k3-*-binman: Move to using ti-dm entry type

[Neha Malcom Francis]

Move the DM entry in tispl.bin FIT image from default fetching an
external blob entry to fetching using ti-dm entry type. This way, the
DM entry will be populated by the TI_DM pathname if provided. Else it
will resort to the ti-dm.bin file.

Signed-off-by: Neha Malcom Francis 
---
 arch/arm/dts/k3-am625-sk-binman.dtsi  | 4 ++--
 arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi | 4 ++--
 arch/arm/dts/k3-am62a-sk-binman.dtsi  | 4 ++--
 arch/arm/dts/k3-j7200-binman.dtsi | 4 ++--
 arch/arm/dts/k3-j721e-binman.dtsi | 4 ++--
 arch/arm/dts/k3-j721s2-binman.dtsi| 4 ++--
 6 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi 
b/arch/arm/dts/k3-am625-sk-binman.dtsi
index b7b5368886..5b058bd03a 100644
--- a/arch/arm/dts/k3-am625-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -161,7 +161,7 @@
content = <>;
keyfile = "custMpk.pem";
};
-   dm: blob-ext {
+   dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -248,7 +248,7 @@
images {
 
dm {
-   blob-ext {
+   ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi 
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
index ed2c4482ef..78c371529a 100644
--- a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -227,7 +227,7 @@
content = <>;
keyfile = "custMpk.pem";
};
-   dm: blob-ext {
+   dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -310,7 +310,7 @@
fit {
images {
dm {
-   blob-ext {
+   ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi 
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
index c5e027d44d..ec3bf7ce91 100644
--- a/arch/arm/dts/k3-am62a-sk-binman.dtsi
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -164,7 +164,7 @@
content = <>;
keyfile = "custMpk.pem";
};
-   dm: blob-ext {
+   dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -250,7 +250,7 @@
fit {
images {
dm {
-   blob-ext {
+   ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi 
b/arch/arm/dts/k3-j7200-binman.dtsi
index 10c9d6cba7..38cccabaa7 100644
--- a/arch/arm/dts/k3-j7200-binman.dtsi
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -200,7 +200,7 @@
content = <>;
keyfile = "custMpk.pem";
};
-   dm: blob-ext {
+   dm: ti-dm {
filename = "ti-dm.bin";
};
};
@@ -285,7 +285,7 @@
fit {
images {
dm {
-   blob-ext {
+   ti-dm {
filename = "ti-dm.bin";
};
};
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi 
b/arch/arm/dts/k3-j721e-binman.dtsi
index 5ddb474e3a..dbc385a852 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ 

[PATCH 1/3] binman: etype: dm: Add entry type for TI DM

[Neha Malcom Francis]

K3 devices introduces the concept of centralized power, resource and
security management to System Firmware. This is to overcome challenges
by the traditional approach that implements system control functions on
each of the processing units.

The software interface for System Firmware is split into TIFS and DM. DM
(Device Manager) is responsible for resource and power management from
secure and non-secure hosts. This additional binary is necessary for
specific platforms' ROM boot images and is to be packaged into tispl.bin

Add an entry for DM. The entry can be used for the packaging of
tispl.bin by binman along with ATF and TEE.

Signed-off-by: Neha Malcom Francis 
---
 Makefile|  1 +
 tools/binman/entries.rst| 14 ++
 tools/binman/etype/ti_dm.py | 22 ++
 tools/binman/ftest.py   |  7 +++
 tools/binman/test/225_ti_dm.dts | 13 +
 5 files changed, 57 insertions(+)
 create mode 100644 tools/binman/etype/ti_dm.py
 create mode 100644 tools/binman/test/225_ti_dm.dts

diff --git a/Makefile b/Makefile
index 1b347f4dfd..7b599ca130 100644
--- a/Makefile
+++ b/Makefile
@@ -1349,6 +1349,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
$(foreach f,$(BINMAN_INDIRS),-I $(f)) \
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
+   -a ti-dm-path=${TI_DM} \
-a opensbi-path=${OPENSBI} \
-a default-dt=$(default_dt) \
-a scp-path=$(SCP) \
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index 61de7f1f4a..254afe7607 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1906,6 +1906,20 @@ the included board config binaries. Example::
 
 
 
+.. _etype_ti_dm:
+
+Entry: ti-dm: TI Device Manager (DM) blob
+-
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically ti-dm.bin
+
+This entry holds the device manager responsible for resource and power 
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more 
information
+about TI DM.
+
+
+
 .. _etype_ti_secure:
 
 Entry: ti-secure: Entry containing a TI x509 certificate binary
diff --git a/tools/binman/etype/ti_dm.py b/tools/binman/etype/ti_dm.py
new file mode 100644
index 00..0faa0bf0ca
--- /dev/null
+++ b/tools/binman/etype/ti_dm.py
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
+# Written by Neha Malcom Francis 
+#
+# Entry-type module for TI Device Manager (DM)
+#
+
+from binman.etype.blob_named_by_arg import Entry_blob_named_by_arg
+
+class Entry_ti_dm(Entry_blob_named_by_arg):
+"""TI Device Manager (DM) blob
+
+Properties / Entry arguments:
+- ti-dm-path: Filename of file to read into the entry, typically 
ti-dm.bin
+
+This entry holds the device manager responsible for resource and power 
management
+in K3 devices. See https://software-dl.ti.com/tisci/esd/latest/ for more 
information
+about TI DM.
+"""
+def __init__(self, section, etype, node):
+super().__init__(section, etype, node, 'ti-dm')
+self.external = True
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 5ace2a825d..a273120d9f 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -88,6 +88,7 @@ FSP_S_DATA= b'fsp_s'
 FSP_T_DATA= b'fsp_t'
 ATF_BL31_DATA = b'bl31'
 TEE_OS_DATA   = b'this is some tee OS data'
+TI_DM_DATA= b'tidmtidm'
 ATF_BL2U_DATA = b'bl2u'
 OPENSBI_DATA  = b'opensbi'
 SCP_DATA  = b'scp'
@@ -221,6 +222,7 @@ class TestFunctional(unittest.TestCase):
 TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
 TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
 TestFunctional._MakeInputFile('tee-pager.bin', TEE_OS_DATA)
+TestFunctional._MakeInputFile('dm.bin', TI_DM_DATA)
 TestFunctional._MakeInputFile('bl2u.bin', ATF_BL2U_DATA)
 TestFunctional._MakeInputFile('fw_dynamic.bin', OPENSBI_DATA)
 TestFunctional._MakeInputFile('scp.bin', SCP_DATA)
@@ -5455,6 +5457,11 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 data = self._DoReadFile('222_tee_os.dts')
 self.assertEqual(TEE_OS_DATA, data[:len(TEE_OS_DATA)])
 
+def testPackTiDm(self):
+"""Test that an image with a TI DM binary can be created"""
+data = self._DoReadFile('225_ti_dm.dts')
+self.assertEqual(TI_DM_DATA, data[:len(TI_DM_DATA)])
+
 def testFitFdtOper(self):
 """Check handling of a specified FIT operation"""
 entry_args = {
diff --git a/tools/binman/test/225_ti_dm.dts b/tools/binman/test/225_ti_dm.dts
new file mode 100644
index 00..3ab754131e
--- /dev/null
+++ 

[PATCH 0/3] binman: Add support for TI_DM entry

[Neha Malcom Francis]

This series adds support for the TI_DM entry and moves all K3 platforms
to using the same. With this feature introduced, if TI_DM argument is
provided binman picks the pathname it provides; else, it defaults to
picking up the ti-dm.bin file. This makes it flexible for users to build
tispl.bin with custom DM binaries.

Boot logs:
https://gist.github.com/nehamalcom/37ce8a32e37ddf3e1afcc4c8bd941159

Neha Malcom Francis (3):
  binman: etype: dm: Add entry type for TI DM
  arm: dts: k3-*-binman: Move to using ti-dm entry type
  doc: board: ti: k3: Mention TI_DM argument

 Makefile  |  1 +
 arch/arm/dts/k3-am625-sk-binman.dtsi  |  4 ++--
 .../dts/k3-am625-verdin-wifi-dev-binman.dtsi  |  4 ++--
 arch/arm/dts/k3-am62a-sk-binman.dtsi  |  4 ++--
 arch/arm/dts/k3-j7200-binman.dtsi |  4 ++--
 arch/arm/dts/k3-j721e-binman.dtsi |  4 ++--
 arch/arm/dts/k3-j721s2-binman.dtsi|  4 ++--
 doc/board/ti/k3.rst   |  7 ++
 tools/binman/entries.rst  | 14 
 tools/binman/etype/ti_dm.py   | 22 +++
 tools/binman/ftest.py |  7 ++
 tools/binman/test/225_ti_dm.dts   | 13 +++
 12 files changed, 76 insertions(+), 12 deletions(-)
 create mode 100644 tools/binman/etype/ti_dm.py
 create mode 100644 tools/binman/test/225_ti_dm.dts

-- 
2.34.1

Re: [PATCH 1/4] clk: starfive: jh7110: Add watchdog clocks

[Leo Liang]

On Mon, Nov 06, 2023 at 08:13:15AM +0900, Chanho Park wrote:
> Add JH7110_SYSCLK_WDT_APB and JH7110_SYSCLK_WDT_CORE clocks for JH7110
> watchdog device.
> 
> Signed-off-by: Chanho Park 
> ---
>  drivers/clk/starfive/clk-jh7110.c | 9 +
>  1 file changed, 9 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH] arm: vexpress64: juno: Allow boot from VirtIO

[Andre Przywara]

On Thu, 23 Nov 2023 18:22:58 +
robert.cather...@foss.arm.com wrote:

Hi Robert,

> From: Robert Catherall 
> 
> The AEM and Juno FVPs (Fixed Virtual Platforms) support a VirtIO

I find it odd that the Juno FVP *adds* something on top of the Juno
hardware devices, as this kind of defeats the purpose of having an
as-close-as-possible software model, but well...
Are there more differences than this one?

> disc interface. Adding VIRTIO to the list of boot devices allows
> these FastModel platforms to boot from 'disc' in the same way
> the hardware counterpart can boot from SATA or USB.
> 
> This is a NOP if CONFIG_CMD_VIRTIO is not enabled, so no impact
> on Juno hardware (which is built with vexpress_aemv8a_juno_defconfig)

So indeed I can confirm that with the vexpress_aemv8a_juno_defconfig there
is no difference in the environment, so if that patch helps you:

> Signed-off-by: Robert Catherall 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  include/configs/vexpress_aemv8.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/vexpress_aemv8.h 
> b/include/configs/vexpress_aemv8.h
> index 24d8ca0866..8020689e39 100644
> --- a/include/configs/vexpress_aemv8.h
> +++ b/include/configs/vexpress_aemv8.h
> @@ -187,6 +187,7 @@
>   func(USB, usb, 0)   \
>   func(SATA, sata, 0) \
>   func(SATA, sata, 1) \
> + FUNC_VIRTIO(func)   \
>   func(PXE, pxe, na)  \
>   func(DHCP, dhcp, na)\
>   func(AFS, afs, na)

Re: [PATCH] common: usb-hub: Reset hub port before scanning

[Marek Vasut]

On 12/4/23 11:59, Shantur Rathore wrote:

Hi Marek,

On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut  wrote:


On 12/3/23 22:42, Shantur Rathore wrote:

Hi Marek,

On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut  wrote:


On 11/24/23 01:37, Shantur Rathore wrote:

Hi Marek,


Hi,

sorry for the late reply.


In my case RockPro64, the power to usb ports onboard is controlled by
a regulator.
This regulator is enabled as part of init  as here
https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177

On init, the usb devices connected to the port are powered up, in my
case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS.
But the usb controller is only enabled at 'usb start' and by this time
the device is in some state that it doesn't get detected.

One way to make sure the devices connected to the ports are in an
initialising state is by issuing a port reset before scanning the
port.


Why not remove this regulator-always-on and let the PHY driver turn the
VBUS ON only when it is needed ?

Wouldn't that solve the problem too AND remove unnecessarily enabled
regulator ?

[...]


Removing the regulator-always-on does make it work but there are few issues

1. regulator is used to control power to multiple ports ( USB3.0 and
USB2.0 in RockPro64 ),
so this could lead to all ports turning off if a phy resets / turns off power


I vaguely recall seeing some refcounting patch for regulator subsystem,
would that help ?


I don't think this would be a problem for u-boot, but linux maybe.


How so ?


Actually, I am wrong. I wasn't sure if there is refcounting for the
regulator subsystem
in linux. just found it has so this is null and void.




2. Even with regulator-always-on and without this reset port patch,
linux was always
able to detect the drive on the port, so there is something missing in u-boot.
3. Looking at usb hub code in Linux, I found that for USB3.0 it tries
to reset the port before
scanning. The comment says

/* Is a USB 3.0 port in the Inactive or Compliance Mode state?
 * Port warm reset is required to recover
 */

i. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736
ii. https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836

I believe this isn't implemented in u-boot and hence explicit reset of
a port fixes the issue.


I feel this is separate issue and what needs to be fixed first is the
hard-wired VBus control.


I beg to differ on this, couple of reasons for this

1. The same drive works fine without being reset on the USB2.0 ports - this
confirms that the issue is related to USB3.0 only.


This is a separate issue from the hard-wired VBus control. I agree the
issue does exist, I would simply like to avoid conflating the hard-wired
VBus control with device reset.


2. Linux is able to detect the same drive on USB3.0 when u-boot fails - this
confirms issue doesn't lie with regulator-always-on


See above


3. The links I pasted earlier mentions that in USB3.0 the ports need reset
and this is done before the port is scanned. Adding the similar reset in u-boot
fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle
this special USB3.0 case and maybe this is why I was finding a few posts
around the drive not being detected in the USB3.0 port in u-boot but works in
a USB2.0 port.


I am not disputing the need for USB 3.0 device reset, I believe there
are two issues here -- one is the hard-wired VBus regulator -- the other
is this USB 3.0 reset. They should both be fixed.


Sure, agreed 100%.
Do we need to fix both at the same time?
Both patches seem to be independent.


Separate patch for the regulator please .


Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but
there seems to be a bug in the rk3399-rockpro64.dtsi from linux where
the typec phy
is configure with wrong regulator and if I do the patch as below

--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -22,6 +22,23 @@
 };
  };

+_host {
+   /delete-property/ regulator-always-on;
+};
+
+_typec {
+   /delete-property/ regulator-always-on;
+};
+
+_usb {
+   /delete-property/ regulator-always-on;
+   /delete-property/ regulator-boot-on;
+};

The typec port won't work until I correct the issue with

+_host {
+   phy-supply = <_typec>;
+};
+

What would be acceptable here?
1. Leave regulator for typec as it was
2. disable regulator-always-on and fix phy here.


Is there going to be a matching Linux kernel patch with a Linux side fix ?

If so, include a link to that patch in lore.k.o in the commit message, 
and either temporarily fix it up in u-boot.dtsi or backport that patch 
to U-Boot DT, either works.

Re: [PATCH 00/21] Qualcomm generic board support

[Daniel Thompson]

On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
> + Linux kernel DT bindings maintainers, EBBR ML
>
> On Thu, 30 Nov 2023 at 20:05, Tom Rini  wrote:
> > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
> > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong  
> > > wrote:
> > > > > I've been thinking about and hacking on this for the last week or so,
> > > > > sorry for the delayed reply here.
> > > > >
> > > > > The value is in preventing any of the existing bindings from 
> > > > > regressing,
> > >
> > > That is actually best addressed in Linux by checking the DTS against
> > > yaml DT bindings. We don't have that testing available in u-boot and
> > > only depend on careful reviews.
> >
> > I would absolutely love for someone to make another attempt at updating
> > our kbuild infrastucture so that we can run the validation targets.
> >
>
> Given that EBBR requires [1] the platform (firmware/bootloader) and
> not OS to supply the devicetree, it becomes evident that
> firmware/bootloaders import DTS from Linux kernel (where it is
> maintained).
>
> But currently u-boot doesn't have a proper way to validate those DTS
> against DT bindings (maintained in Linux kernel). Although there are
> Devicetree schema tools available here [2], there isn't a versioned
> release package of DT bindings which one should use to validate DTS
> files.

The kernel is regularly released in multiple forms (including git
tags and tarball). Why isn't the kernel itself sufficient to be a
versioned release of the DT bindings directory?


Daniel.

Re: [PATCH] common: usb-hub: Reset hub port before scanning

[Shantur Rathore]

Hi Marek,

On Sun, Dec 3, 2023 at 10:37 PM Marek Vasut  wrote:
>
> On 12/3/23 22:42, Shantur Rathore wrote:
> > Hi Marek,
> >
> > On Sun, Dec 3, 2023 at 8:42 PM Marek Vasut  wrote:
> >>
> >> On 11/24/23 01:37, Shantur Rathore wrote:
> >>> Hi Marek,
> >>
> >> Hi,
> >>
> >> sorry for the late reply.
> >>
> >>> In my case RockPro64, the power to usb ports onboard is controlled by
> >>> a regulator.
> >>> This regulator is enabled as part of init  as here
> >>> https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3399-rockpro64.dtsi#L177
> >>>
> >>> On init, the usb devices connected to the port are powered up, in my
> >>> case AM8180 (a RTL9210 based ) NVMe to USB enclosure with UAS.
> >>> But the usb controller is only enabled at 'usb start' and by this time
> >>> the device is in some state that it doesn't get detected.
> >>>
> >>> One way to make sure the devices connected to the ports are in an
> >>> initialising state is by issuing a port reset before scanning the
> >>> port.
> >>
> >> Why not remove this regulator-always-on and let the PHY driver turn the
> >> VBUS ON only when it is needed ?
> >>
> >> Wouldn't that solve the problem too AND remove unnecessarily enabled
> >> regulator ?
> >>
> >> [...]
> >
> > Removing the regulator-always-on does make it work but there are few 
> > issues
> >
> > 1. regulator is used to control power to multiple ports ( USB3.0 and
> > USB2.0 in RockPro64 ),
> > so this could lead to all ports turning off if a phy resets / turns off 
> > power
> 
>  I vaguely recall seeing some refcounting patch for regulator subsystem,
>  would that help ?
> >>>
> >>> I don't think this would be a problem for u-boot, but linux maybe.
> >>
> >> How so ?
> >
> > Actually, I am wrong. I wasn't sure if there is refcounting for the
> > regulator subsystem
> > in linux. just found it has so this is null and void.
> >
> >>
> > 2. Even with regulator-always-on and without this reset port patch,
> > linux was always
> > able to detect the drive on the port, so there is something missing in 
> > u-boot.
> > 3. Looking at usb hub code in Linux, I found that for USB3.0 it tries
> > to reset the port before
> > scanning. The comment says
> >
> > /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
> > * Port warm reset is required to recover
> > */
> >
> > i. 
> > https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L5736
> > ii. 
> > https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2836
> >
> > I believe this isn't implemented in u-boot and hence explicit reset of
> > a port fixes the issue.
> 
>  I feel this is separate issue and what needs to be fixed first is the
>  hard-wired VBus control.
> >>>
> >>> I beg to differ on this, couple of reasons for this
> >>>
> >>> 1. The same drive works fine without being reset on the USB2.0 ports - 
> >>> this
> >>> confirms that the issue is related to USB3.0 only.
> >>
> >> This is a separate issue from the hard-wired VBus control. I agree the
> >> issue does exist, I would simply like to avoid conflating the hard-wired
> >> VBus control with device reset.
> >>
> >>> 2. Linux is able to detect the same drive on USB3.0 when u-boot fails - 
> >>> this
> >>> confirms issue doesn't lie with regulator-always-on
> >>
> >> See above
> >>
> >>> 3. The links I pasted earlier mentions that in USB3.0 the ports need reset
> >>> and this is done before the port is scanned. Adding the similar reset in 
> >>> u-boot
> >>> fixes all with the same regulator-always-on. AFAIK u-boot doesn't handle
> >>> this special USB3.0 case and maybe this is why I was finding a few posts
> >>> around the drive not being detected in the USB3.0 port in u-boot but 
> >>> works in
> >>> a USB2.0 port.
> >>
> >> I am not disputing the need for USB 3.0 device reset, I believe there
> >> are two issues here -- one is the hard-wired VBus regulator -- the other
> >> is this USB 3.0 reset. They should both be fixed.
> >
> > Sure, agreed 100%.
> > Do we need to fix both at the same time?
> > Both patches seem to be independent.
>
> Separate patch for the regulator please .

Thanks, I am working on the regulator patch for rk3399-rockpro64-u-boot but
there seems to be a bug in the rk3399-rockpro64.dtsi from linux where
the typec phy
is configure with wrong regulator and if I do the patch as below

--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -22,6 +22,23 @@
};
 };

+_host {
+   /delete-property/ regulator-always-on;
+};
+
+_typec {
+   /delete-property/ regulator-always-on;
+};
+
+_usb {
+   /delete-property/ regulator-always-on;
+   /delete-property/ regulator-boot-on;
+};

The typec port won't work until I correct the issue with

+_host {
+   

Re: [PATCH 01/18] bootm: netbds: Drop passing of arguments

[Martin Husemann]

On Mon, Dec 04, 2023 at 11:48:17AM +0100, Mark Kettenis wrote:
> That said, I'm not sure to what extent the bootm command is used to
> boot NetBSD these days.  So this may not really matter.

It is used on most 32bit ARM platforms.

Martin

[PATCH 6/6] board: mediatek: add MT8365 EVK board support

[Julien Masson]

This adds support for the MT8365 EVK board with the following
features enabled/tested: Boot, UART, Watchdog and MMC.

Signed-off-by: Julien Masson 
---
 arch/arm/dts/mt6357.dtsi   | 282 +
 arch/arm/dts/mt8365-evk.dts| 418 +
 board/mediatek/mt8365_evk/MAINTAINERS  |   6 +
 board/mediatek/mt8365_evk/Makefile |   3 +
 board/mediatek/mt8365_evk/mt8365_evk.c |  33 ++
 configs/mt8365_evk_defconfig   |  19 ++
 6 files changed, 761 insertions(+)
 create mode 100644 arch/arm/dts/mt6357.dtsi
 create mode 100644 arch/arm/dts/mt8365-evk.dts
 create mode 100644 board/mediatek/mt8365_evk/MAINTAINERS
 create mode 100644 board/mediatek/mt8365_evk/Makefile
 create mode 100644 board/mediatek/mt8365_evk/mt8365_evk.c
 create mode 100644 configs/mt8365_evk_defconfig

diff --git a/arch/arm/dts/mt6357.dtsi b/arch/arm/dts/mt6357.dtsi
new file mode 100644
index 00..3330a03c2f
--- /dev/null
+++ b/arch/arm/dts/mt6357.dtsi
@@ -0,0 +1,282 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ * Copyright (c) 2023 BayLibre Inc.
+ */
+
+#include 
+
+ {
+   mt6357_pmic: pmic {
+   compatible = "mediatek,mt6357";
+
+   regulators {
+   mt6357_vproc_reg: buck-vproc {
+   regulator-name = "vproc";
+   regulator-min-microvolt = <518750>;
+   regulator-max-microvolt = <1312500>;
+   regulator-ramp-delay = <6250>;
+   regulator-enable-ramp-delay = <220>;
+   regulator-always-on;
+   };
+
+   mt6357_vcore_reg: buck-vcore {
+   regulator-name = "vcore";
+   regulator-min-microvolt = <518750>;
+   regulator-max-microvolt = <1312500>;
+   regulator-ramp-delay = <6250>;
+   regulator-enable-ramp-delay = <220>;
+   regulator-always-on;
+   };
+
+   mt6357_vmodem_reg: buck-vmodem {
+   regulator-name = "vmodem";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <1193750>;
+   regulator-ramp-delay = <6250>;
+   regulator-enable-ramp-delay = <220>;
+   };
+
+   mt6357_vs1_reg: buck-vs1 {
+   regulator-name = "vs1";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <220>;
+   regulator-ramp-delay = <12500>;
+   regulator-enable-ramp-delay = <220>;
+   regulator-always-on;
+   };
+
+   mt6357_vpa_reg: buck-vpa {
+   regulator-name = "vpa";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <365>;
+   regulator-ramp-delay = <5>;
+   regulator-enable-ramp-delay = <220>;
+   };
+
+   mt6357_vfe28_reg: ldo-vfe28 {
+   compatible = "regulator-fixed";
+   regulator-name = "vfe28";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-enable-ramp-delay = <264>;
+   };
+
+   mt6357_vxo22_reg: ldo-vxo22 {
+   regulator-name = "vxo22";
+   regulator-min-microvolt = <220>;
+   regulator-max-microvolt = <240>;
+   regulator-enable-ramp-delay = <110>;
+   };
+
+   mt6357_vrf18_reg: ldo-vrf18 {
+   compatible = "regulator-fixed";
+   regulator-name = "vrf18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-enable-ramp-delay = <110>;
+   };
+
+   mt6357_vrf12_reg: ldo-vrf12 {
+   compatible = "regulator-fixed";
+   regulator-name = "vrf12";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   

[PATCH 5/6] dt-bindings: clock: add Mediatek MT8365 pinctrl bindings

[Julien Masson]

This adds the pinctrl bindings for Mediatek MT8365 SoC based on the
dt-bindings in Linux tag v6.7-rc2.
(commit 8b4c397d88d97d4fd9c3f3527aa66688b1a3387a)

Signed-off-by: Julien Masson 
---
 include/dt-bindings/pinctrl/mt8365-pinfunc.h | 858 +++
 1 file changed, 858 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/mt8365-pinfunc.h

diff --git a/include/dt-bindings/pinctrl/mt8365-pinfunc.h 
b/include/dt-bindings/pinctrl/mt8365-pinfunc.h
new file mode 100644
index 00..e2ec8af57d
--- /dev/null
+++ b/include/dt-bindings/pinctrl/mt8365-pinfunc.h
@@ -0,0 +1,858 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2021 MediaTek Inc.
+ */
+#ifndef __MT8365_PINFUNC_H
+#define __MT8365_PINFUNC_H
+
+#include 
+
+#define MT8365_PIN_0_GPIO0__FUNC_GPIO0 (MTK_PIN_NO(0) | 0)
+#define MT8365_PIN_0_GPIO0__FUNC_DPI_D0 (MTK_PIN_NO(0) | 1)
+#define MT8365_PIN_0_GPIO0__FUNC_PWM_A (MTK_PIN_NO(0) | 2)
+#define MT8365_PIN_0_GPIO0__FUNC_I2S2_BCK (MTK_PIN_NO(0) | 3)
+#define MT8365_PIN_0_GPIO0__FUNC_EXT_TXD0 (MTK_PIN_NO(0) | 4)
+#define MT8365_PIN_0_GPIO0__FUNC_CONN_MCU_TDO (MTK_PIN_NO(0) | 5)
+#define MT8365_PIN_0_GPIO0__FUNC_DBG_MON_A0 (MTK_PIN_NO(0) | 7)
+
+#define MT8365_PIN_1_GPIO1__FUNC_GPIO1 (MTK_PIN_NO(1) | 0)
+#define MT8365_PIN_1_GPIO1__FUNC_DPI_D1 (MTK_PIN_NO(1) | 1)
+#define MT8365_PIN_1_GPIO1__FUNC_PWM_B (MTK_PIN_NO(1) | 2)
+#define MT8365_PIN_1_GPIO1__FUNC_I2S2_LRCK (MTK_PIN_NO(1) | 3)
+#define MT8365_PIN_1_GPIO1__FUNC_EXT_TXD1 (MTK_PIN_NO(1) | 4)
+#define MT8365_PIN_1_GPIO1__FUNC_CONN_MCU_DBGACK_N (MTK_PIN_NO(1) | 5)
+#define MT8365_PIN_1_GPIO1__FUNC_DBG_MON_A1 (MTK_PIN_NO(1) | 7)
+
+#define MT8365_PIN_2_GPIO2__FUNC_GPIO2 (MTK_PIN_NO(2) | 0)
+#define MT8365_PIN_2_GPIO2__FUNC_DPI_D2 (MTK_PIN_NO(2) | 1)
+#define MT8365_PIN_2_GPIO2__FUNC_PWM_C (MTK_PIN_NO(2) | 2)
+#define MT8365_PIN_2_GPIO2__FUNC_I2S2_MCK (MTK_PIN_NO(2) | 3)
+#define MT8365_PIN_2_GPIO2__FUNC_EXT_TXD2 (MTK_PIN_NO(2) | 4)
+#define MT8365_PIN_2_GPIO2__FUNC_CONN_MCU_DBGI_N (MTK_PIN_NO(2) | 5)
+#define MT8365_PIN_2_GPIO2__FUNC_DBG_MON_A2 (MTK_PIN_NO(2) | 7)
+
+#define MT8365_PIN_3_GPIO3__FUNC_GPIO3 (MTK_PIN_NO(3) | 0)
+#define MT8365_PIN_3_GPIO3__FUNC_DPI_D3 (MTK_PIN_NO(3) | 1)
+#define MT8365_PIN_3_GPIO3__FUNC_CLKM0 (MTK_PIN_NO(3) | 2)
+#define MT8365_PIN_3_GPIO3__FUNC_I2S2_DI (MTK_PIN_NO(3) | 3)
+#define MT8365_PIN_3_GPIO3__FUNC_EXT_TXD3 (MTK_PIN_NO(3) | 4)
+#define MT8365_PIN_3_GPIO3__FUNC_CONN_MCU_TCK (MTK_PIN_NO(3) | 5)
+#define MT8365_PIN_3_GPIO3__FUNC_CONN_MCU_AICE_TCKC (MTK_PIN_NO(3) | 6)
+#define MT8365_PIN_3_GPIO3__FUNC_DBG_MON_A3 (MTK_PIN_NO(3) | 7)
+
+#define MT8365_PIN_4_GPIO4__FUNC_GPIO4 (MTK_PIN_NO(4) | 0)
+#define MT8365_PIN_4_GPIO4__FUNC_DPI_D4 (MTK_PIN_NO(4) | 1)
+#define MT8365_PIN_4_GPIO4__FUNC_CLKM1 (MTK_PIN_NO(4) | 2)
+#define MT8365_PIN_4_GPIO4__FUNC_I2S1_BCK (MTK_PIN_NO(4) | 3)
+#define MT8365_PIN_4_GPIO4__FUNC_EXT_TXC (MTK_PIN_NO(4) | 4)
+#define MT8365_PIN_4_GPIO4__FUNC_CONN_MCU_TDI (MTK_PIN_NO(4) | 5)
+#define MT8365_PIN_4_GPIO4__FUNC_VDEC_TEST_CK (MTK_PIN_NO(4) | 6)
+#define MT8365_PIN_4_GPIO4__FUNC_DBG_MON_A4 (MTK_PIN_NO(4) | 7)
+
+#define MT8365_PIN_5_GPIO5__FUNC_GPIO5 (MTK_PIN_NO(5) | 0)
+#define MT8365_PIN_5_GPIO5__FUNC_DPI_D5 (MTK_PIN_NO(5) | 1)
+#define MT8365_PIN_5_GPIO5__FUNC_CLKM2 (MTK_PIN_NO(5) | 2)
+#define MT8365_PIN_5_GPIO5__FUNC_I2S1_LRCK (MTK_PIN_NO(5) | 3)
+#define MT8365_PIN_5_GPIO5__FUNC_EXT_RXER (MTK_PIN_NO(5) | 4)
+#define MT8365_PIN_5_GPIO5__FUNC_CONN_MCU_TRST_B (MTK_PIN_NO(5) | 5)
+#define MT8365_PIN_5_GPIO5__FUNC_MM_TEST_CK (MTK_PIN_NO(5) | 6)
+#define MT8365_PIN_5_GPIO5__FUNC_DBG_MON_A5 (MTK_PIN_NO(5) | 7)
+
+#define MT8365_PIN_6_GPIO6__FUNC_GPIO6 (MTK_PIN_NO(6) | 0)
+#define MT8365_PIN_6_GPIO6__FUNC_DPI_D6 (MTK_PIN_NO(6) | 1)
+#define MT8365_PIN_6_GPIO6__FUNC_CLKM3 (MTK_PIN_NO(6) | 2)
+#define MT8365_PIN_6_GPIO6__FUNC_I2S1_MCK (MTK_PIN_NO(6) | 3)
+#define MT8365_PIN_6_GPIO6__FUNC_EXT_RXC (MTK_PIN_NO(6) | 4)
+#define MT8365_PIN_6_GPIO6__FUNC_CONN_MCU_TMS (MTK_PIN_NO(6) | 5)
+#define MT8365_PIN_6_GPIO6__FUNC_CONN_MCU_AICE_TMSC (MTK_PIN_NO(6) | 6)
+#define MT8365_PIN_6_GPIO6__FUNC_DBG_MON_A6 (MTK_PIN_NO(6) | 7)
+
+#define MT8365_PIN_7_GPIO7__FUNC_GPIO7 (MTK_PIN_NO(7) | 0)
+#define MT8365_PIN_7_GPIO7__FUNC_DPI_D7 (MTK_PIN_NO(7) | 1)
+#define MT8365_PIN_7_GPIO7__FUNC_I2S1_DO (MTK_PIN_NO(7) | 3)
+#define MT8365_PIN_7_GPIO7__FUNC_EXT_RXDV (MTK_PIN_NO(7) | 4)
+#define MT8365_PIN_7_GPIO7__FUNC_CONN_DSP_JCK (MTK_PIN_NO(7) | 5)
+#define MT8365_PIN_7_GPIO7__FUNC_DBG_MON_A7 (MTK_PIN_NO(7) | 7)
+
+#define MT8365_PIN_8_GPIO8__FUNC_GPIO8 (MTK_PIN_NO(8) | 0)
+#define MT8365_PIN_8_GPIO8__FUNC_DPI_D8 (MTK_PIN_NO(8) | 1)
+#define MT8365_PIN_8_GPIO8__FUNC_SPI_CLK (MTK_PIN_NO(8) | 2)
+#define MT8365_PIN_8_GPIO8__FUNC_I2S0_BCK (MTK_PIN_NO(8) | 3)
+#define MT8365_PIN_8_GPIO8__FUNC_EXT_RXD0 (MTK_PIN_NO(8) | 4)
+#define MT8365_PIN_8_GPIO8__FUNC_CONN_DSP_JINTP (MTK_PIN_NO(8) | 5)
+#define MT8365_PIN_8_GPIO8__FUNC_DBG_MON_A8 (MTK_PIN_NO(8) | 7)
+
+#define MT8365_PIN_9_GPIO9__FUNC_GPIO9