Re: [PATCH] tpm: Make 'tpm init' to call tpm_auto_start()

[Ilias Apalodimas]

Hi Simon,

On Wed, May 31, 2023 at 09:28:04PM -0600, Simon Glass wrote:
> Hi Ilias,
>
> On Tue, 30 May 2023 at 00:18, Ilias Apalodimas
>  wrote:
> >
> > For a TPM device to be operational we need to initialize it and
> > perform its startup sequence.  The 'tpm init' command currently calls
> > tpm_init() which ends up calling the ->open() per-device callback and
> > performs the initial hardware configuration as well as requesting
> > locality 0 for the caller.  There no code that currently calls
> > tpm_init() without following up with a tpm_startup() and 
> > tpm_self_test_full()
> > or tpm_continue_self_test().
> >
> > So let's wire up the 'tpm init' command and call tpm_auto_start() which
> > leaves the device in an operational state and adjust any defconfigs
> > using 'tpm init'.
> >
> > It's worth noting that calling tpm_init() only, doesn't allow a someone
> > to use the TPM since the startup sequence is mandatory. We always
> > repeat the pattern of calling
> > - tpm_init()
> > - tpm_startup()
> > - tpm_self_test_full() or tpm_continue_self_test()
> > as a result we don't expect any regression or boot delays with the current
> > change.
> >
> > While at it fix the identation of test_tpm_autostart() comments as well.
> >
> > Signed-off-by: Ilias Apalodimas 
> > ---
> >
> > This is a split and resend of 
> > https://lore.kernel.org/u-boot/20230510074359.2837818-9-ilias.apalodi...@linaro.org/
> > Since Simon some had concerns I decided to split this off the series and 
> > send it
> > as a single patch for further discussion.
> >
> >  cmd/tpm-common.c   | 3 ++-
> >  configs/chromebook_coral_defconfig | 2 +-
> >  test/dm/tpm.c  | 9 +
> >  test/py/tests/test_tpm2.py | 9 -
> >  4 files changed, 8 insertions(+), 15 deletions(-)
>
> We've already discussed this before. Please can you:
>
> - Call tpm_autostart() instead
> - Add a new 'tpm autostart' command
>
> That way we can keep tpm_init() as it is.
>

We have discussed but I am not convinced on why we should ever keep
'tpm init' as is.  You mentioned the ability to not always boot with
Startup(Clear) but that makes little sense to be in a u-boot command.
If we ever want to resume a tpm we should do that automatically.

In any case the spec itself mentions that the _init function should put the
TPM in a state were the next command *must* be a startup one,  so I don't
mind adding a 'tpm autostart'.

Regards
/Ilias

> Regards,
> Simon

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Simon,

On Thu, 1 Jun 2023 at 14:10, Jonathan Liu  wrote:
> On Thu, 1 Jun 2023 at 11:27, Jonathan Liu  wrote:
> > On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
> > > On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I noticed that loading from squashfs with zstd compression is
> > > > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > > > filesystem is located on eMMC.
> > > >
> > > > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > > > command.
> > > >
> > > > ext4:
> > > > 15682578 bytes read in 366 ms (40.9 MiB/s)
> > > >
> > > > SquashFS with zstd compression:
> > > > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> > > >
> > > > Any suggestions on how to speed up loading from SquashFS with zstd 
> > > > compression?
> >
> > >
> > > Could it just be that zstd is slow? Have you tried lz4?
> > >
>
> >
> > I tried LZ4 but get "Error: unknown compression type."
> > It seems the SquashFS decompressor only supports lzo, gzip and zstd -
> > https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c
> >
> > ext4:
> > 15682578 bytes read in 366 ms (40.9 MiB/s)
> >
> > SquashFS with lzo compression (~129 MiB squashfs):
> > 15686657 bytes read in 1032 ms (14.5 MiB/s)
> >
> > SquashFS with gzip compression (~116 MiB squashfs):
> > 15686657 bytes read in 1494 ms (10 MiB/s)
> >
> > SquashFS with zstd compression (~107 MiB squashfs):
> > 15685001 bytes read in 2339 ms (6.4 MiB/s)
>
> SquashFS with zstd compression seems to be even slower after zstd was
> updated to 1.5.2 in U-Boot.
>
> SquashFS with zstd compression (~107 MiB squashfs), with zstd 1.5.2
> update cherry-picked from
> https://source.denx.de/u-boot/u-boot/-/commit/4b9b25d943ff95c7421cab261333fc29852fe3b1:
> 15686657 bytes read in 2726 ms (5.5 MiB/s)

If I use unsquashfs on the same board to decompress the same file
using a single processor, it is much faster:
# sync; echo 3 > /proc/sys/vm/drop_caches; time unsquashfs -p 1
/dev/mmcblk1p1 /boot/test-file
Parallel unsquashfs: Using 1 processor
1 inodes (120 blocks) to write

[=|]
120/120 100%

created 1 files
created 2 directories
created 0 symlinks
created 0 devices
created 0 fifos
real0m 0.19s
user0m 0.16s
sys 0m 0.12s

Regards,
Jonathan

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Simon,

On Thu, 1 Jun 2023 at 11:27, Jonathan Liu  wrote:
>
> Hi Simon,
>
> On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
> >
> > Hi Jonathan,
> >
> > On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> > >
> > > Hi All,
> > >
> > > I noticed that loading from squashfs with zstd compression is
> > > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > > filesystem is located on eMMC.
> > >
> > > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > > command.
> > >
> > > ext4:
> > > 15682578 bytes read in 366 ms (40.9 MiB/s)
> > >
> > > SquashFS with zstd compression:
> > > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> > >
> > > Any suggestions on how to speed up loading from SquashFS with zstd 
> > > compression?
>
> >
> > Could it just be that zstd is slow? Have you tried lz4?
> >

>
> I tried LZ4 but get "Error: unknown compression type."
> It seems the SquashFS decompressor only supports lzo, gzip and zstd -
> https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c
>
> ext4:
> 15682578 bytes read in 366 ms (40.9 MiB/s)
>
> SquashFS with lzo compression (~129 MiB squashfs):
> 15686657 bytes read in 1032 ms (14.5 MiB/s)
>
> SquashFS with gzip compression (~116 MiB squashfs):
> 15686657 bytes read in 1494 ms (10 MiB/s)
>
> SquashFS with zstd compression (~107 MiB squashfs):
> 15685001 bytes read in 2339 ms (6.4 MiB/s)

SquashFS with zstd compression seems to be even slower after zstd was
updated to 1.5.2 in U-Boot.

SquashFS with zstd compression (~107 MiB squashfs), with zstd 1.5.2
update cherry-picked from
https://source.denx.de/u-boot/u-boot/-/commit/4b9b25d943ff95c7421cab261333fc29852fe3b1:
15686657 bytes read in 2726 ms (5.5 MiB/s)

Regards,
Jonathan

Re: [PATCH 2/5] usb: dwc3-generic: Return early when there is no child node

[Jagan Teki]

On Tue, May 30, 2023 at 3:56 PM Jonas Karlman  wrote:
>
> The call to device_find_first_child always return 0, change to return
> early when there is no child node.

Can you explain a little more about this? Maybe adding device-tree
pipeline will give a better understanding of the issue.

Jagan.

Re: [PATCH v7 09/10] test: efi_capsule: refactor efi_capsule test

[Simon Glass]

On Tue, 30 May 2023 at 21:36, Masahisa Kojima
 wrote:
>
> Current efi capsule python tests have much code duplication.
> This commit creates the common function
> in test/py/tests/test_efi_capsule/capsule_common.py,
> aim to reduce the code size and improve maintainability.
>
> Signed-off-by: Masahisa Kojima 
> ---
> Newly created in v7
>
>  .../tests/test_efi_capsule/capsule_common.py  |  86 +++
>  .../test_capsule_firmware_fit.py  | 151 +++-
>  .../test_capsule_firmware_raw.py  | 224 +++---
>  .../test_capsule_firmware_signed_fit.py   | 198 +++-
>  .../test_capsule_firmware_signed_raw.py   | 210 +++-
>  5 files changed, 231 insertions(+), 638 deletions(-)
>  create mode 100644 test/py/tests/test_efi_capsule/capsule_common.py

Reviewed-by: Simon Glass 

Thank you.

Please do comment your function arguments.

Re: [PATCH] tpm: Make 'tpm init' to call tpm_auto_start()

[Simon Glass]

Hi Ilias,

On Tue, 30 May 2023 at 00:18, Ilias Apalodimas
 wrote:
>
> For a TPM device to be operational we need to initialize it and
> perform its startup sequence.  The 'tpm init' command currently calls
> tpm_init() which ends up calling the ->open() per-device callback and
> performs the initial hardware configuration as well as requesting
> locality 0 for the caller.  There no code that currently calls
> tpm_init() without following up with a tpm_startup() and tpm_self_test_full()
> or tpm_continue_self_test().
>
> So let's wire up the 'tpm init' command and call tpm_auto_start() which
> leaves the device in an operational state and adjust any defconfigs
> using 'tpm init'.
>
> It's worth noting that calling tpm_init() only, doesn't allow a someone
> to use the TPM since the startup sequence is mandatory. We always
> repeat the pattern of calling
> - tpm_init()
> - tpm_startup()
> - tpm_self_test_full() or tpm_continue_self_test()
> as a result we don't expect any regression or boot delays with the current
> change.
>
> While at it fix the identation of test_tpm_autostart() comments as well.
>
> Signed-off-by: Ilias Apalodimas 
> ---
>
> This is a split and resend of 
> https://lore.kernel.org/u-boot/20230510074359.2837818-9-ilias.apalodi...@linaro.org/
> Since Simon some had concerns I decided to split this off the series and send 
> it
> as a single patch for further discussion.
>
>  cmd/tpm-common.c   | 3 ++-
>  configs/chromebook_coral_defconfig | 2 +-
>  test/dm/tpm.c  | 9 +
>  test/py/tests/test_tpm2.py | 9 -
>  4 files changed, 8 insertions(+), 15 deletions(-)

We've already discussed this before. Please can you:

- Call tpm_autostart() instead
- Add a new 'tpm autostart' command

That way we can keep tpm_init() as it is.

Regards,
Simon

Re: [PATCH] scripts/Makefile.lib: change spelling of $(srctree)/arch/$(ARCH)/dts in dtc_cpp_flags

[Simon Glass]

On Tue, 16 May 2023 at 03:18, Rasmus Villemoes
 wrote:
>
> Currently, all in-tree .dts files (apart from some under test/ and
> tools/), reside in arch/$ARCH/dts. However, in the linux kernel tree,
> dts files for arm64 boards, and probably in the not too distant
> future [1], arm boards as well, live in subdirectories of that.
>
> For private forks, using a vendor or project subdirectory is also more
> convenient to clearly separate private code from upstream - in the
> same way that code under board/ is also split and easy to maintain.
>
> In order to prepare for us to follow suit and do the splitting of the
> in-tree .dts files, and to make life a little easier for private forks
> that already place dts files not directly in arch/$ARCH/dts, change
> the $(srctree)/arch/$(ARCH)/dts path to instead refer to the directory of
> the .dts file being compiled. This should be a no-op for all existing
> cases.
>
> [1] https://lore.kernel.org/lkml/20220328000915.15041-1-ansuels...@gmail.com/
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  scripts/Makefile.lib | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Simon Glass 

Re: CONFIG_SPL_BUILD seems to be not defined in my u-boot-spl program.. why?

[Simon Glass]

Hi Chan,

On Sun, 28 May 2023 at 06:40, Chan Kim  wrote:
>
> Dear u-boot experts,
>
> While analyzing u-boot-spl program on qemu arm64 virtual machine, I'm seems
> the program counter skips part of a code and it seems the reason is that
> CONFIG_SPL_BUILD is not defined. But I'm running spl/u-boot-spl and the
> spl/u-boot.cfg file contains 'CONFIG_SPL_BUILD=1'. In what case can this
> happen?
> Any comment will be deeply appreciated.

Which part of the code does it skip?

You really have not provided enough information for anyone to give you
an opinion. You could include a console log, what debugging you have
tried, which U-Boot board and version you are building, any local
patches you have.

> Thank you.
>
> Chan Kim
>
>
>
>

Regards,
Simon

Re: [PATCH v2 1/2] sandbox: Add a dummy dcache_status() function

[Simon Glass]

On Tue, 30 May 2023 at 07:33, Francesco Dolcini  wrote:
>
> From: Emanuele Ghidoli 
>
> This adds dcache_status() so that code using it can build
> without error on sandbox. This is required in preparation
> of adding cache handling into get_ram_size function.
>
> Signed-off-by: Emanuele Ghidoli 
> Signed-off-by: Francesco Dolcini 
> ---
>  arch/sandbox/cpu/cpu.c | 5 +
>  1 file changed, 5 insertions(+)
>

Reviewed-by: Simon Glass 

Re: Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi Simon,

On Thu, 1 Jun 2023 at 03:13, Simon Glass  wrote:
>
> Hi Jonathan,
>
> On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
> >
> > Hi All,
> >
> > I noticed that loading from squashfs with zstd compression is
> > significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> > filesystem is located on eMMC.
> >
> > I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load 
> > command.
> >
> > ext4:
> > 15682578 bytes read in 366 ms (40.9 MiB/s)
> >
> > SquashFS with zstd compression:
> > 15685001 bytes read in 2339 ms (6.4 MiB/s)
> >
> > Any suggestions on how to speed up loading from SquashFS with zstd 
> > compression?

>
> Could it just be that zstd is slow? Have you tried lz4?
>

I tried LZ4 but get "Error: unknown compression type."
It seems the SquashFS decompressor only supports lzo, gzip and zstd -
https://source.denx.de/u-boot/u-boot/-/blob/master/fs/squashfs/sqfs_decompressor.c

ext4:
15682578 bytes read in 366 ms (40.9 MiB/s)

SquashFS with lzo compression (~129 MiB squashfs):
15686657 bytes read in 1032 ms (14.5 MiB/s)

SquashFS with gzip compression (~116 MiB squashfs):
15686657 bytes read in 1494 ms (10 MiB/s)

SquashFS with zstd compression (~107 MiB squashfs):
15685001 bytes read in 2339 ms (6.4 MiB/s)

Regards,
Jonathan

Re: [PATCH v6 0/3] Add StarFive JH7110 PCIe drvier support

[Minda Chen]

Hi Rick and Leo
Could you review these series patches? Thanks.
Since patch 1 was acked by Pali， Does it mean patch 1 is accepted？

On 2023/5/9 16:26, Minda Chen wrote:
> These PCIe series patches are based on the JH7110 RISC-V SoC and VisionFive 
> V2 board.
> 
> The PCIe driver depends on gpio, pinctrl, clk and reset driver to do init.
> The PCIe dts configuation includes all these setting.
> 
> The PCIe drivers codes has been tested on the VisionFive V2 boards.
> The test devices includes M.2 NVMe SSD and Realtek 8169 Ethernet adapter.
> 
> previous patch version
> 
> v1: 
> https://patchwork.ozlabs.org/project/uboot/cover/20230223105240.15180-1-minda.c...@starfivetech.com/
> v2: 
> https://patchwork.ozlabs.org/project/uboot/cover/20230308054833.95730-1-minda.c...@starfivetech.com/
> v3: 
> https://patchwork.ozlabs.org/project/uboot/cover/20230329100143.10724-1-minda.c...@starfivetech.com/
> v4: 
> https://patchwork.ozlabs.org/project/uboot/cover/20230411010209.76561-1-minda.c...@starfivetech.com/
> v5: 
> https://patchwork.ozlabs.org/project/uboot/cover/20230423105859.125764-1-minda.c...@starfivetech.com/
> 
> changes
>   v6
>patch 2
> 1. Change one VisionFive2 config file.
>patch 3
> 1. remove the pcie interrupt-controller. interrupts setting revert to 
> origin.
> 
> setting.
>   v5
>patch 1
> 1. split PLDA controller driver codes to pcie_plda_common.c
> 2. correct the codes of record secondary number. 
>patch 3
> 1. change the pcie dtsi config. make them the same with kernel.
>  
>   v4
>patch 1
> 1. Remove the IDS_REVISION_ID macros.
> 2. Replace sec_busno to first_busno in starfive_pcie
> 3. Remove starfive_pcie_off_conf function.
> 4. Replace "imply" to "depends on" in PCIe Kconfig.
> 5 .Check sec_busno in starfive_pcie_addr_valid.
>  
>   v3
>patch 1
> 1. remove the read vendor ID delay
> 2. remove starfive_pcie_hide_rc_bar function. do not hide host
> bridge BAR write.
> 3. Using PCIE_ECAM_OFFSET and PCI_CLASS_BRIDGE_PCI_NORMAL macros.
> 4. Add comments for bus and address limitation reason in function
>starfive_pcie_addr_valid
> 5. Change the multiple line comments in Line 373
> 6. Using gpio_request_by_name to get PCIe reset gpio,and using
>dm_gpio_set_value set GPIO value.
>   patch 2
> 1. support PCIeboth 12a and 13b vf2 board.  
>   patch 3
> 1. reset dts change to reset-gpio.
> 
>   v2
>1. remove clock commit. The pcie clocks change has been includeded in [1].
>2. Using GENMASK marco1 in patch1.
>3. remove the syscon dts node in patch3. The syscon dts dts node has been
>   included in [1]. 
> 
> 
> Mason Huo (3):
>   starfive: pci: Add StarFive JH7110 pcie driver
>   configs: starfive-jh7110: Add support for PCIe host driver
>   riscv: dts: starfive: Enable PCIe host controller
> 
>  .../dts/jh7110-starfive-visionfive-2.dtsi |  11 +
>  arch/riscv/dts/jh7110.dtsi|  74 
>  configs/starfive_visionfive2_defconfig|  10 +
>  drivers/pci/Kconfig   |  13 +
>  drivers/pci/Makefile  |   2 +
>  drivers/pci/pcie_plda_common.c| 116 +++
>  drivers/pci/pcie_plda_common.h| 118 +++
>  drivers/pci/pcie_starfive_jh7110.c| 317 ++
>  8 files changed, 661 insertions(+)
>  create mode 100644 drivers/pci/pcie_plda_common.c
>  create mode 100644 drivers/pci/pcie_plda_common.h
>  create mode 100644 drivers/pci/pcie_starfive_jh7110.c
> 
> 
> base-commit: c9c2c95d4cd27fe0cd41fe13a863899d268f973c

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Stuart Yoder]

On 5/31/23 5:09 PM, Heinrich Schuchardt wrote:



Am 31. Mai 2023 22:40:23 MESZ schrieb Stuart Yoder :



On 5/31/23 3:10 PM, Heinrich Schuchardt wrote:

On 5/31/23 21:37, Stuart Yoder wrote:


Unfortunately, the TCG spec is very confusing in section 6.4.4 #2 and
#3.  They attempted to clarify in an errata:
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-Errata-v.5.pdf

...but it is still confusing.

Ilias and I had discussed the ambiguities, and back in March 2022 I
requested clarification from the TCG workgroup.  In cases of
ambiguity TCG frequently will defer to how EDK2 has implemented
a point in the spec.

Here are my notes following the call with TCG about the intent
of #2 and #3, which was based on their review of the EDK2
implementation:

a. If a client passes in a Size that is the full size including all
     fields including ActivePcrBanks, the return code is SUCCESS and
     all fields are populated. [This is a 1.1 client scenario]

b. If a client passes in a Size that includes all fields up to
     and including the vendor ID, the return code is SUCCESS and all
     fields up to including the vendor ID are populated. [This is a
     1.0 client scenario, so a populated 1.0 struct is returned]


This contradicts the TCG EFI Protocol Specifiction which knows of no 1.0
structure but requires:

If the input ProtocolCapability.Size <
sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) the function will initialize
the fields included in ProtocolCapability.Size. The values of the
remaining fields will be undefined.

We should stick with what is specified.

The above requirement is not yet implemented in U-Boot.

Could you, please, indicated where the 1.0 structure was ever defined. I
could not find any a document linked on
https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/


I can't find any public spec with the 1.0 struct.


If it does not exist in a specification, why care about it?


In theory there could be old clients from 6+ years ago that were
built to support the 1.0 struct.  But, this seems unlikely
given how much time has passed.

This is exactly why Ilias doesn't want to put support for the 1.0
struct in u-boot.  We don't care about 1.0 clients.





c. If a client passes in a Size that is less than the size up to
     and including the vendor ID, the return code is BUFFER_TOO_SMALL
     and the Size field is populated with the full size of the struct
     supported by the firmware. [This allows a client to determine
     whether it is talking to 1.0 or 1.1 firmware]


Yes, it is the client's task to check the protocol version and not the
firmware's task to guess what the client has in mind.

ARM should fix their tests that don't comply with the TCG EFI Protocol
Specification and then upstream them to edk-test. U-Boot should not try
to work around incorrect vendor tests.


The spec is not clear.  And the committee that owns the spec provided
the clarifications I outlined. They were supposed to provide an errata
update to publish those clarifications, but it seems somehow that
didn't happen.

I specifically defined the SCT test spec based on what the committee
told me:
https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md

The Arm created tests match what I've been told is the the _intent_ of
the spec.  What is missing is getting TCG to publish errata documenting
that.


As you wrote above the tests don't relate to a known specification.


I'm going to push TCG to publish the errata clarifying this.  Once that
is published the tests will match the spec.

Thanks,
Stuart

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Heinrich Schuchardt]

Am 31. Mai 2023 22:40:23 MESZ schrieb Stuart Yoder :
>
>
>On 5/31/23 3:10 PM, Heinrich Schuchardt wrote:
>> On 5/31/23 21:37, Stuart Yoder wrote:
>>> 
>>> Unfortunately, the TCG spec is very confusing in section 6.4.4 #2 and
>>> #3.  They attempted to clarify in an errata:
>>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-Errata-v.5.pdf
>>> 
>>> ...but it is still confusing.
>>> 
>>> Ilias and I had discussed the ambiguities, and back in March 2022 I
>>> requested clarification from the TCG workgroup.  In cases of
>>> ambiguity TCG frequently will defer to how EDK2 has implemented
>>> a point in the spec.
>>> 
>>> Here are my notes following the call with TCG about the intent
>>> of #2 and #3, which was based on their review of the EDK2
>>> implementation:
>>> 
>>> a. If a client passes in a Size that is the full size including all
>>>     fields including ActivePcrBanks, the return code is SUCCESS and
>>>     all fields are populated. [This is a 1.1 client scenario]
>>> 
>>> b. If a client passes in a Size that includes all fields up to
>>>     and including the vendor ID, the return code is SUCCESS and all
>>>     fields up to including the vendor ID are populated. [This is a
>>>     1.0 client scenario, so a populated 1.0 struct is returned]
>> 
>> This contradicts the TCG EFI Protocol Specifiction which knows of no 1.0
>> structure but requires:
>> 
>> If the input ProtocolCapability.Size <
>> sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) the function will initialize
>> the fields included in ProtocolCapability.Size. The values of the
>> remaining fields will be undefined.
>> 
>> We should stick with what is specified.
>> 
>> The above requirement is not yet implemented in U-Boot.
>> 
>> Could you, please, indicated where the 1.0 structure was ever defined. I
>> could not find any a document linked on
>> https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/
>
>I can't find any public spec with the 1.0 struct.

If it does not exist in a specification, why care about it?

>
>>> 
>>> c. If a client passes in a Size that is less than the size up to
>>>     and including the vendor ID, the return code is BUFFER_TOO_SMALL
>>>     and the Size field is populated with the full size of the struct
>>>     supported by the firmware. [This allows a client to determine
>>>     whether it is talking to 1.0 or 1.1 firmware]
>> 
>> Yes, it is the client's task to check the protocol version and not the
>> firmware's task to guess what the client has in mind.
>> 
>> ARM should fix their tests that don't comply with the TCG EFI Protocol
>> Specification and then upstream them to edk-test. U-Boot should not try
>> to work around incorrect vendor tests.
>
>The spec is not clear.  And the committee that owns the spec provided
>the clarifications I outlined. They were supposed to provide an errata
>update to publish those clarifications, but it seems somehow that
>didn't happen.
>
>I specifically defined the SCT test spec based on what the committee
>told me:
>https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md
>
>The Arm created tests match what I've been told is the the _intent_ of
>the spec.  What is missing is getting TCG to publish errata documenting
>that.

As you wrote above the tests don't relate to a known specification.

Best regards

Heinrich


>
>Thanks,
>Stuart

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Simon Glass]

Hi Heinrich,

On Wed, 31 May 2023 at 14:22, Heinrich Schuchardt
 wrote:
>
>
>
> On 5/31/23 21:52, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 31 May 2023 at 13:27, Heinrich Schuchardt
> >  wrote:
> >>
> >>
> >>
> >> On 5/31/23 20:24, Tom Rini wrote:
> >>> On Wed, May 31, 2023 at 08:05:18PM +0200, Heinrich Schuchardt wrote:
> 
> 
>  On 5/31/23 19:13, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:
> >>
> >> On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:
> >>> Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:
> >>>
>  On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:
> 
> > qemu_arm64_defconfig with UNIT_TEST=y does not build.
> >
> > CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without 
> > video we
> > must not enable unit tests invoking expo functions.
> >
> > Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all
>  uclasses")
> > Signed-off-by: Heinrich Schuchardt 
> > 
> > ---
> > test/boot/Makefile | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/test/boot/Makefile b/test/boot/Makefile
> > index 22ed61c8fa..665017ba3d 100644
> > --- a/test/boot/Makefile
> > +++ b/test/boot/Makefile
> > @@ -2,7 +2,10 @@
> > #
> > # Copyright 2021 Google LLC
> >
> > -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o
>  bootmeth.o
> > +ifdef CONFIG_BOOTSTD
> > +obj-y += bootstd_common.o bootmeth.o
> > +obj-$(VIDEO) += bootdev.o bootflow.o
> > +endif
> > obj-$(CONFIG_FIT) += image.o
> >
> > obj-$(CONFIG_EXPO) += expo.o
> 
>  OK, but the functionality itself doesn't depend on video, it looks 
>  like
>  maybe only the bootflow_menu_theme test itself, so lets try and solve
>  this differently.
> 
>  --
>  Tom
> 
> >>>
> >>> Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .
> >>
> >> Well no, at first glance it's 1 out of 15 tests in that file that 
> >> depend
> >> on CONFIG_EXPO, so we should just ifdef that test.
> 
>  Yes, there is only one test in bootflow.o depending on EXPO.
>  There are multiple tests in bootdev.o depending on CONFIG_DM_MMC.
> >>>
> >>> And the tests presumably check for DM_MMC, or should.
> >>>
> > You could put something like this at the top of bootflow_cmd_menu():
> >
> > /* 'bootflow menu' currently requires a video console */
> > if (!IS_ENABLED(CONFIG_VIDEO))
> >   return -EAGAIN;
> 
>  With this change I still get:
> 
>    aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function
>  `bootflow_menu_new':
> >>>
> >>> Looks like there's an extra line in boot/Makefile then, we already
> >>> include bootflow_menu.o on EXPO.
> >>>
> >>
> >> Hello Simon,
> >>
> >> the bootstd tests are in complete disarray
> >>
> >> On the sandbox invoked with
> >>
> >> ./u-boot -T
> >>
> >> => ut bootstd
> >> Can't map file 'mmc1.img': Invalid argument
> >> mmc1: Unable to map file 'mmc1.img'
> >> Failed to set up for bootstd tests (err=-5)
> >>
> >> It I create a file mmc1.img:
> >>
> >> test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL ==
> >> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> >> (-22), got 0xffa3 (-93)
> >> test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT ==
> >> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe
> >> (-2), got 0xffa3 (-93)
> >> test/boot/bootdev.c:466, bootdev_test_bootable(): 1 ==
> >> iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
> >> test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL ==
> >> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> >> (-22), got 0xffa3 (-93)
> >> Test: bootdev_test_bootable: bootdev.c (flat tree)
> >> test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL ==
> >> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> >> (-22), got 0xffa3 (-93)
> >> test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT ==
> >> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe
> >> (-2), got 0xffa3 (-93)
> >> test/boot/bootdev.c:466, bootdev_test_bootable(): 1 ==
> >> iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
> >> test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL ==
> >> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> >> (-22), got 0xffa3 (-93)
> >> Test  failed 8 times
> >
> > I normally run these tests with an alias:  pyt bootstd
> >
> > # Run a pytest on sandbox
> > # $1: Name of test to run (optional, else run all)
> >
> > function pyt {
> > local tests
> > local para
> >
> > if 

Re: [PATCH v2 0/8] Add DFU, emmc and usb boot for TI am62x

[Tom Rini]

On Thu, Apr 06, 2023 at 08:55:34PM +0200, Sjoerd Simons wrote:

> This series adds more boot sources for the TI am62x. For that the dts'
> are synced from the upstream ti-next git tree (to add usb nodes), some
> dwc3 glue is and finally the default configuration is tuned to add
> support for DFU and USB (host and gadget)
> 
> 
> Changes in v2:
> - Update dts sync to v6.3-rc5
> - Switch dwc3 glue to a seperate driver rather then in dwc-generic
> - Minimize config changes to just DFU configuration
> - Only enable usb port 0 DFU in SPL
> - Create a seperate defconfig for R5
> 
> Sjoerd Simons (8):
>   omap: timer: add ti,am654-timer compatibility
>   arm: mach-k3: am62: Add timer0 id to the dev list
>   arm: dts: k3-am62: Bump dtsi from linux
>   arm: dts: k3-am625-sk: Enable emmc in SPL
>   usb: dwc3: Add dwc3 glue driver for am62
>   configs: am62: Add configs for enabling USB in U-Boot
>   arm: dts: k3-am625-sk: Enable usb ports in u-boot
>   configs: am62x_evm_*: Enable USB and DFU support
> 
>  arch/arm/dts/k3-am62-main.dtsi| 259 +++---
>  arch/arm/dts/k3-am62-mcu.dtsi |  49 +
>  arch/arm/dts/k3-am62-wakeup.dtsi  |   4 +-
>  arch/arm/dts/k3-am625-r5-sk.dts   |   2 +-
>  arch/arm/dts/k3-am625-sk-u-boot.dtsi  |  27 ++-
>  arch/arm/dts/k3-am625-sk.dts  |  95 +-
>  arch/arm/dts/k3-am625.dtsi|  52 ++
>  arch/arm/mach-k3/am62x/dev-data.c |   1 +
>  configs/am62x_evm_a53_defconfig   |  35 +++-
>  configs/am62x_evm_r5_usbdfu_defconfig | 116 
>  drivers/timer/omap-timer.c|   1 +
>  drivers/usb/dwc3/Kconfig  |  14 ++
>  drivers/usb/dwc3/Makefile |   1 +
>  drivers/usb/dwc3/dwc3-am62.c  | 127 +
>  include/configs/am62x_evm.h   |  10 +-
>  15 files changed, 701 insertions(+), 92 deletions(-)
>  create mode 100644 configs/am62x_evm_r5_usbdfu_defconfig
>  create mode 100644 drivers/usb/dwc3/dwc3-am62.c
> Tested-by: Ravi Gunasekaran 
> Tested-by: Mattijs Korpershoek 

This seems, conceptually, fine.  But as we're getting the TI dts files
in sync with the kernel, I'm deferring this version and you'll want to
rebase and re-post once everything has settled.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 08/10] ARM: renesas: Add R8A77970 V3MSK board and CPLD code

[Marek Vasut]

From: Valentine Barshak 

Add board code for the R8A77970 V3MSK board.
Add CPLD sysreset driver to the R-Car V3M SK board.
Extracted from a larger patch by Valentine Barshak.

Reviewed-by: Marek Vasut 
Signed-off-by: Valentine Barshak 
Signed-off-by: Hai Pham 
Signed-off-by: Tam Nguyen 
Signed-off-by: Marek Vasut 
[Marek: Sync configs and board code with V3M Eagle, squash CPLD driver in]
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/r8a77970-v3msk-u-boot.dts |  65 +
 arch/arm/mach-rmobile/Kconfig.rcar3|   6 +
 board/renesas/v3msk/Kconfig|  15 +
 board/renesas/v3msk/MAINTAINERS|   6 +
 board/renesas/v3msk/Makefile   |  15 +
 board/renesas/v3msk/cpld.c | 368 +
 configs/r8a77970_v3msk_defconfig   |  87 ++
 doc/README.rmobile |   1 +
 9 files changed, 564 insertions(+)
 create mode 100644 arch/arm/dts/r8a77970-v3msk-u-boot.dts
 create mode 100644 board/renesas/v3msk/Kconfig
 create mode 100644 board/renesas/v3msk/MAINTAINERS
 create mode 100644 board/renesas/v3msk/Makefile
 create mode 100644 board/renesas/v3msk/cpld.c
 create mode 100644 configs/r8a77970_v3msk_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa606..95a7b234687 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1053,6 +1053,7 @@ dtb-$(CONFIG_RCAR_GEN3) += \
r8a77965-ulcb-u-boot.dtb \
r8a77965-salvator-x-u-boot.dtb \
r8a77970-eagle-u-boot.dtb \
+   r8a77970-v3msk-u-boot.dtb \
r8a77980-condor-u-boot.dtb \
r8a77990-ebisu-u-boot.dtb \
r8a77995-draak-u-boot.dtb
diff --git a/arch/arm/dts/r8a77970-v3msk-u-boot.dts 
b/arch/arm/dts/r8a77970-v3msk-u-boot.dts
new file mode 100644
index 000..6ee06d7c000
--- /dev/null
+++ b/arch/arm/dts/r8a77970-v3msk-u-boot.dts
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source extras for U-Boot for the V3MSK board
+ *
+ * Copyright (C) 2019 Cogent Embedded, Inc.
+ */
+
+#include "r8a77970-v3msk.dts"
+#include "r8a77970-u-boot.dtsi"
+#include 
+
+/ {
+   aliases {
+   spi0 = 
+   };
+
+   cpld {
+   compatible = "renesas,v3msk-cpld";
+   status = "okay";
+   gpio-mdc = < 21 0>;
+   gpio-mosi = < 22 0>;
+   gpio-miso = < 23 0>;
+   gpio-enablez = < 19 0>;
+   /* Disable V3MSK Videobox Mini CANFD PHY */
+   gpios = < 12 0>, < 14 0>;
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+};
+
+ {
+   reset-gpios = < 16 GPIO_ACTIVE_LOW>;
+};
+
+ {
+   avb0_pins: avb {
+   mux {
+   groups = "avb0_link", "avb0_mdio", "avb0_rgmii", 
"avb0_txcrefclk";
+   function = "avb0";
+   };
+   };
+};
+
+ {
+   num-cs = <1>;
+   status = "okay";
+   spi-max-frequency = <5000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   flash0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "s25fs512s", "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <5000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
+   reg = <0>;
+   status = "okay";
+   };
+};
diff --git a/arch/arm/mach-rmobile/Kconfig.rcar3 
b/arch/arm/mach-rmobile/Kconfig.rcar3
index 5f338219b45..46d274273af 100644
--- a/arch/arm/mach-rmobile/Kconfig.rcar3
+++ b/arch/arm/mach-rmobile/Kconfig.rcar3
@@ -111,6 +111,11 @@ config TARGET_EAGLE
help
   Support for Renesas R-Car Gen3 Eagle platform
 
+config TARGET_V3MSK
+   bool "V3MSK board"
+   help
+  Support for Renesas R-Car Gen3 V3MSK platform
+
 config TARGET_EBISU
bool "Ebisu board"
imply R8A77990
@@ -166,6 +171,7 @@ source "board/renesas/eagle/Kconfig"
 source "board/renesas/ebisu/Kconfig"
 source "board/renesas/salvator-x/Kconfig"
 source "board/renesas/ulcb/Kconfig"
+source "board/renesas/v3msk/Kconfig"
 source "board/beacon/beacon-rzg2m/Kconfig"
 source "board/hoperun/hihope-rzg2/Kconfig"
 source "board/silinux/ek874/Kconfig"
diff --git a/board/renesas/v3msk/Kconfig b/board/renesas/v3msk/Kconfig
new file mode 100644
index 000..fe037fd98f0
--- /dev/null
+++ b/board/renesas/v3msk/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_V3MSK
+
+config SYS_SOC
+   default "rmobile"
+
+config SYS_BOARD
+   default "v3msk"
+
+config SYS_VENDOR
+   default "renesas"
+
+config SYS_CONFIG_NAME
+   default "rcar-gen3-common"
+
+endif
diff --git a/board/renesas/v3msk/MAINTAINERS b/board/renesas/v3msk/MAINTAINERS
new file mode 100644
index 000..12822a4571a
--- /dev/null
+++ b/board/renesas/v3msk/MAINTAINERS
@@ -0,0 +1,6 @@
+V3MSK BOARD
+M: Cogent Embedded, Inc. 
+S: Maintained
+F: board/renesas/v3msk/
+F: 

[PATCH 09/10] ARM: dts: renesas: Add R8A77980 V3HSK DTs

[Marek Vasut]

From: Valentine Barshak 

Import R8A77980 V3HSK DTs from Linux 6.1.31,
commit d2869ace6eeb ("Linux 6.1.31").
Extracted from a larger patch by Valentine Barshak.

Reviewed-by: Marek Vasut 
Signed-off-by: Valentine Barshak 
Signed-off-by: Hai Pham 
Signed-off-by: Tam Nguyen 
Signed-off-by: Marek Vasut  # Sync with 6.1.31
---
 arch/arm/dts/r8a77980-v3hsk.dts | 292 
 1 file changed, 292 insertions(+)
 create mode 100644 arch/arm/dts/r8a77980-v3hsk.dts

diff --git a/arch/arm/dts/r8a77980-v3hsk.dts b/arch/arm/dts/r8a77980-v3hsk.dts
new file mode 100644
index 000..d168b0e7747
--- /dev/null
+++ b/arch/arm/dts/r8a77980-v3hsk.dts
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the V3H Starter Kit board
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ * Copyright (C) 2018 Cogent Embedded, Inc.
+ */
+
+/dts-v1/;
+#include "r8a77980.dtsi"
+#include 
+
+/ {
+   model = "Renesas V3H Starter Kit board";
+   compatible = "renesas,v3hsk", "renesas,r8a77980";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   i2c5 = 
+   serial0 = 
+   ethernet0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+   vcc-supply = <_d5>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   thc63lvd1024_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   thc63lvd1024_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0 0x4800 0 0x7800>;
+   };
+
+   osc1_clk: osc1-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+
+   vcc1v8_d4: regulator-0 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC1V8_D4";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc3v3_d5: regulator-1 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC3V3_D5";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
+ {
+   clocks = < CPG_MOD 724>,
+<_clk>;
+   clock-names = "du.0", "dclkin.0";
+   status = "okay";
+};
+
+_clk {
+   clock-frequency = <1666>;
+};
+
+_clk {
+   clock-frequency = <32768>;
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   phy-mode = "rgmii";
+   phy-handle = <>;
+   renesas,no-ether-link;
+   status = "okay";
+
+   phy0: ethernet-phy@0 {
+   compatible = "ethernet-phy-id0022.1622",
+"ethernet-phy-ieee802.3-c22";
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <23 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = < 22 GPIO_ACTIVE_LOW>;
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   hdmi@39 {
+   compatible = "adi,adv7511w";
+   #sound-dai-cells = <0>;
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   avdd-supply = <_d4>;
+   dvdd-supply = <_d4>;
+   pvdd-supply = <_d4>;
+   bgvdd-supply = <_d4>;
+   dvdd-3v-supply = <_d5>;
+
+   adi,input-depth = <8>;
+   adi,input-colorspace = "rgb";
+   adi,input-clock = "1x";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+  

[PATCH 10/10] ARM: renesas: Add R8A77980 V3HSK board and CPLD code

[Marek Vasut]

From: Valentine Barshak 

Add board code for the R8A77980 V3HSK board.
Add CPLD sysreset driver to the R-Car V3H SK board.
Extracted from a larger patch by Valentine Barshak.

Reviewed-by: Marek Vasut 
Signed-off-by: Valentine Barshak 
Signed-off-by: Hai Pham 
Signed-off-by: Tam Nguyen 
Signed-off-by: Marek Vasut 
[Marek: Sync configs and board code with V3H Condor, squash CPLD driver in]
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/r8a77980-v3hsk-u-boot.dts |  42 ++
 arch/arm/mach-rmobile/Kconfig.rcar3|   6 +
 board/renesas/v3hsk/Kconfig|  15 +++
 board/renesas/v3hsk/Makefile   |  15 +++
 board/renesas/v3hsk/cpld.c | 180 +
 configs/r8a77980_v3hsk_defconfig   |  83 
 include/configs/v3hsk.h|  28 
 8 files changed, 370 insertions(+)
 create mode 100644 arch/arm/dts/r8a77980-v3hsk-u-boot.dts
 create mode 100644 board/renesas/v3hsk/Kconfig
 create mode 100644 board/renesas/v3hsk/Makefile
 create mode 100644 board/renesas/v3hsk/cpld.c
 create mode 100644 configs/r8a77980_v3hsk_defconfig
 create mode 100644 include/configs/v3hsk.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 95a7b234687..7dcc7b1f994 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1055,6 +1055,7 @@ dtb-$(CONFIG_RCAR_GEN3) += \
r8a77970-eagle-u-boot.dtb \
r8a77970-v3msk-u-boot.dtb \
r8a77980-condor-u-boot.dtb \
+   r8a77980-v3hsk-u-boot.dtb \
r8a77990-ebisu-u-boot.dtb \
r8a77995-draak-u-boot.dtb
 
diff --git a/arch/arm/dts/r8a77980-v3hsk-u-boot.dts 
b/arch/arm/dts/r8a77980-v3hsk-u-boot.dts
new file mode 100644
index 000..d083df65f9a
--- /dev/null
+++ b/arch/arm/dts/r8a77980-v3hsk-u-boot.dts
@@ -0,0 +1,42 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source extras for U-Boot for the Eagle board
+ *
+ * Copyright (C) 2019 Cogent Embedded, Inc.
+ */
+
+#include "r8a77980-v3hsk.dts"
+#include "r8a77980-u-boot.dtsi"
+
+/ {
+   aliases {
+   spi0 = 
+   };
+};
+
+ {
+   num-cs = <1>;
+   status = "okay";
+   spi-max-frequency = <5000>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   flash0: spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "s25fs512s", "spi-flash", "jedec,spi-nor";
+   spi-max-frequency = <5000>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <1>;
+   reg = <0>;
+   status = "okay";
+   };
+};
+
+ {
+   cpld {
+   compatible = "renesas,v3hsk-cpld";
+   reg = <0x70>;
+   u-boot,i2c-offset-len = <2>;
+   };
+};
diff --git a/arch/arm/mach-rmobile/Kconfig.rcar3 
b/arch/arm/mach-rmobile/Kconfig.rcar3
index 46d274273af..ad35d1058f2 100644
--- a/arch/arm/mach-rmobile/Kconfig.rcar3
+++ b/arch/arm/mach-rmobile/Kconfig.rcar3
@@ -99,6 +99,11 @@ config TARGET_CONDOR
help
   Support for Renesas R-Car Gen3 Condor platform
 
+config TARGET_V3HSK
+   bool "V3HSK board"
+   help
+  Support for Renesas R-Car Gen3 V3HSK platform
+
 config TARGET_DRAAK
bool "Draak board"
imply R8A77995
@@ -171,6 +176,7 @@ source "board/renesas/eagle/Kconfig"
 source "board/renesas/ebisu/Kconfig"
 source "board/renesas/salvator-x/Kconfig"
 source "board/renesas/ulcb/Kconfig"
+source "board/renesas/v3hsk/Kconfig"
 source "board/renesas/v3msk/Kconfig"
 source "board/beacon/beacon-rzg2m/Kconfig"
 source "board/hoperun/hihope-rzg2/Kconfig"
diff --git a/board/renesas/v3hsk/Kconfig b/board/renesas/v3hsk/Kconfig
new file mode 100644
index 000..531ceb788f4
--- /dev/null
+++ b/board/renesas/v3hsk/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_V3HSK
+
+config SYS_SOC
+   default "rmobile"
+
+config SYS_BOARD
+   default "v3hsk"
+
+config SYS_VENDOR
+   default "renesas"
+
+config SYS_CONFIG_NAME
+   default "v3hsk"
+
+endif
diff --git a/board/renesas/v3hsk/Makefile b/board/renesas/v3hsk/Makefile
new file mode 100644
index 000..a9d597edd58
--- /dev/null
+++ b/board/renesas/v3hsk/Makefile
@@ -0,0 +1,15 @@
+#
+# board/renesas/v3hsk/Makefile
+#
+# Copyright (C) 2019 Renesas Electronics Corporation
+# Copyright (C) 2019 Cogent Embedded, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+ifdef CONFIG_SPL_BUILD
+obj-y  := ../rcar-common/gen3-spl.o
+else
+obj-y  := ../rcar-common/v3-common.o ../rcar-common/common.o
+obj-$(CONFIG_SYSRESET) += cpld.o
+endif
diff --git a/board/renesas/v3hsk/cpld.c b/board/renesas/v3hsk/cpld.c
new file mode 100644
index 000..6016f6daef9
--- /dev/null
+++ b/board/renesas/v3hsk/cpld.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * V3HSK board CPLD access support
+ *
+ * Copyright (C) 2019 Renesas Electronics Corporation
+ * Copyright (C) 2019 Cogent Embedded, Inc.
+ *
+ */
+
+#include 
+#include 
+#include 

[PATCH 07/10] ARM: dts: renesas: Add R8A77970 V3MSK DTs

[Marek Vasut]

From: Valentine Barshak 

Import R8A77970 V3MSK DTs from Linux 6.1.31,
commit d2869ace6eeb ("Linux 6.1.31").
Extracted from a larger patch by Valentine Barshak.

Reviewed-by: Marek Vasut 
Signed-off-by: Valentine Barshak 
Signed-off-by: Hai Pham 
Signed-off-by: Tam Nguyen 
Signed-off-by: Marek Vasut  # Sync with 6.1.31
---
 arch/arm/dts/r8a77970-v3msk.dts | 303 
 1 file changed, 303 insertions(+)
 create mode 100644 arch/arm/dts/r8a77970-v3msk.dts

diff --git a/arch/arm/dts/r8a77970-v3msk.dts b/arch/arm/dts/r8a77970-v3msk.dts
new file mode 100644
index 000..c2b65f8de54
--- /dev/null
+++ b/arch/arm/dts/r8a77970-v3msk.dts
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the V3M Starter Kit board
+ *
+ * Copyright (C) 2017 Renesas Electronics Corp.
+ * Copyright (C) 2017 Cogent Embedded, Inc.
+ */
+
+/dts-v1/;
+#include "r8a77970.dtsi"
+#include 
+
+/ {
+   model = "Renesas V3M Starter Kit board";
+   compatible = "renesas,v3msk", "renesas,r8a77970";
+
+   aliases {
+   i2c0 = 
+   i2c1 = 
+   i2c2 = 
+   i2c3 = 
+   i2c4 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   hdmi-out {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   lvds-decoder {
+   compatible = "thine,thc63lvd1024";
+   vcc-supply = <_d3_3v>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   thc63lvd1024_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   thc63lvd1024_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
+
+   memory@4800 {
+   device_type = "memory";
+   /* first 128MB is reserved for secure area. */
+   reg = <0x0 0x4800 0x0 0x7800>;
+   };
+
+   osc5_clk: osc5-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <14850>;
+   };
+
+   vcc_d1_8v: regulator-0 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_D1.8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc_d3_3v: regulator-1 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_D3.3V";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   vcc_vddq_vin0: regulator-2 {
+   compatible = "regulator-fixed";
+   regulator-name = "VCC_VDDQ_VIN0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   renesas,no-ether-link;
+   phy-handle = <>;
+   rx-internal-delay-ps = <1800>;
+   tx-internal-delay-ps = <2000>;
+   status = "okay";
+
+   phy0: ethernet-phy@0 {
+   compatible = "ethernet-phy-id0022.1622",
+"ethernet-phy-ieee802.3-c22";
+   rxc-skew-ps = <1500>;
+   reg = <0>;
+   interrupt-parent = <>;
+   interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+};
+
+ {
+   clocks = < CPG_MOD 724>,
+<_clk>;
+   clock-names = "du.0", "dclkin.0";
+   status = "okay";
+};
+
+_clk {
+   clock-frequency = <1666>;
+};
+
+_clk {
+   clock-frequency = <32768>;
+};
+
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+
+   status = "okay";
+   clock-frequency = <40>;
+
+   hdmi@39{
+   compatible = "adi,adv7511w";
+   #sound-dai-cells = <0>;
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
+   avdd-supply = <_d1_8v>;
+   dvdd-supply = <_d1_8v>;
+

[PATCH 05/10] ARM: rmobile: Drop eagle.h config of R8A77970 V3M Eagle board

[Marek Vasut]

The eagle.h is now empty and only includes rcar-gen3-common.h .
Use rcar-gen3-common.h directly instead and drop eagle.h .
No functional change.

Signed-off-by: Marek Vasut 
---
 board/renesas/eagle/Kconfig |  2 +-
 include/configs/eagle.h | 19 ---
 2 files changed, 1 insertion(+), 20 deletions(-)
 delete mode 100644 include/configs/eagle.h

diff --git a/board/renesas/eagle/Kconfig b/board/renesas/eagle/Kconfig
index 1e0710e73e1..4d12843b4e9 100644
--- a/board/renesas/eagle/Kconfig
+++ b/board/renesas/eagle/Kconfig
@@ -10,6 +10,6 @@ config SYS_VENDOR
default "renesas"
 
 config SYS_CONFIG_NAME
-   default "eagle"
+   default "rcar-gen3-common"
 
 endif
diff --git a/include/configs/eagle.h b/include/configs/eagle.h
deleted file mode 100644
index c751f75a7d0..000
--- a/include/configs/eagle.h
+++ /dev/null
@@ -1,19 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * include/configs/eagle.h
- * This file is Eagle board configuration.
- *
- * Copyright (C) 2015 Renesas Electronics Corporation
- */
-
-#ifndef __EAGLE_H
-#define __EAGLE_H
-
-#include "rcar-gen3-common.h"
-
-/* Environment compatibility */
-
-/* Board Clock */
-/* XTAL_CLK : 33.33MHz */
-
-#endif /* __EAGLE_H */
-- 
2.39.2

[PATCH 03/10] ARM: rmobile: Reduce R-Car V3H Condor header usage

[Marek Vasut]

There is no need to pull in all those headers as the board file is
basically empty. Drop them all.

Signed-off-by: Marek Vasut 
---
 board/renesas/condor/condor.c | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/board/renesas/condor/condor.c b/board/renesas/condor/condor.c
index fdb95ac1a59..e29c67b5094 100644
--- a/board/renesas/condor/condor.c
+++ b/board/renesas/condor/condor.c
@@ -7,17 +7,6 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
-- 
2.39.2

[PATCH 06/10] ARM: rmobile: Introduce weak default board_init()

[Marek Vasut]

Introduce weak default board_init() in rcar-common/common.c , which
allows complete removal of ebisu.c and condor.c at the same time .

Signed-off-by: Marek Vasut 
---
 board/renesas/condor/Makefile |  2 +-
 board/renesas/condor/condor.c | 14 --
 board/renesas/ebisu/Makefile  |  2 +-
 board/renesas/ebisu/ebisu.c   | 14 --
 board/renesas/rcar-common/common.c|  5 +
 board/renesas/rcar-common/v3-common.c |  5 -
 6 files changed, 7 insertions(+), 35 deletions(-)
 delete mode 100644 board/renesas/condor/condor.c
 delete mode 100644 board/renesas/ebisu/ebisu.c

diff --git a/board/renesas/condor/Makefile b/board/renesas/condor/Makefile
index cf6d566a9bb..19e6038430b 100644
--- a/board/renesas/condor/Makefile
+++ b/board/renesas/condor/Makefile
@@ -9,5 +9,5 @@
 ifdef CONFIG_SPL_BUILD
 obj-y  := ../rcar-common/gen3-spl.o
 else
-obj-y  := condor.o ../rcar-common/common.o
+obj-y  := ../rcar-common/common.o
 endif
diff --git a/board/renesas/condor/condor.c b/board/renesas/condor/condor.c
deleted file mode 100644
index e29c67b5094..000
--- a/board/renesas/condor/condor.c
+++ /dev/null
@@ -1,14 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * board/renesas/condor/condor.c
- * This file is Condor board support.
- *
- * Copyright (C) 2019 Marek Vasut 
- */
-
-#include 
-
-int board_init(void)
-{
-   return 0;
-}
diff --git a/board/renesas/ebisu/Makefile b/board/renesas/ebisu/Makefile
index 1fd9a03ecc9..956ce8a90fa 100644
--- a/board/renesas/ebisu/Makefile
+++ b/board/renesas/ebisu/Makefile
@@ -9,5 +9,5 @@
 ifdef CONFIG_SPL_BUILD
 obj-y  := ../rcar-common/gen3-spl.o
 else
-obj-y  := ebisu.o ../rcar-common/common.o
+obj-y  := ../rcar-common/common.o
 endif
diff --git a/board/renesas/ebisu/ebisu.c b/board/renesas/ebisu/ebisu.c
deleted file mode 100644
index 182e9800063..000
--- a/board/renesas/ebisu/ebisu.c
+++ /dev/null
@@ -1,14 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * board/renesas/ebisu/ebisu.c
- * This file is Ebisu board support.
- *
- * Copyright (C) 2018 Marek Vasut 
- */
-
-#include 
-
-int board_init(void)
-{
-   return 0;
-}
diff --git a/board/renesas/rcar-common/common.c 
b/board/renesas/rcar-common/common.c
index 17940aa9146..3a0e88b3919 100644
--- a/board/renesas/rcar-common/common.c
+++ b/board/renesas/rcar-common/common.c
@@ -49,6 +49,11 @@ int dram_init_banksize(void)
return 0;
 }
 
+int __weak board_init(void)
+{
+   return 0;
+}
+
 #if defined(CONFIG_RCAR_GEN3)
 #define RST_BASE   0xE616
 #define RST_CA57RESCNT (RST_BASE + 0x40)
diff --git a/board/renesas/rcar-common/v3-common.c 
b/board/renesas/rcar-common/v3-common.c
index be8be0cb16d..7c6202ea499 100644
--- a/board/renesas/rcar-common/v3-common.c
+++ b/board/renesas/rcar-common/v3-common.c
@@ -39,8 +39,3 @@ int board_early_init_f(void)
 
return 0;
 }
-
-int board_init(void)
-{
-   return 0;
-}
-- 
2.39.2

[PATCH 04/10] ARM: rmobile: Factor out common R-Car V3M/V3H board code

[Marek Vasut]

Pull common board initialization code from V3M Eagle board
into rcar-common/v3-common.c so it can be re-used by other
V3M/V3H boards.

Signed-off-by: Marek Vasut 
---
 board/renesas/eagle/Makefile  |  2 +-
 .../eagle.c => rcar-common/v3-common.c}   | 26 +--
 2 files changed, 2 insertions(+), 26 deletions(-)
 rename board/renesas/{eagle/eagle.c => rcar-common/v3-common.c} (57%)

diff --git a/board/renesas/eagle/Makefile b/board/renesas/eagle/Makefile
index 062c46ba24f..9fb6a7c0f0a 100644
--- a/board/renesas/eagle/Makefile
+++ b/board/renesas/eagle/Makefile
@@ -9,5 +9,5 @@
 ifdef CONFIG_SPL_BUILD
 obj-y  := ../rcar-common/gen3-spl.o
 else
-obj-y  := eagle.o ../rcar-common/common.o
+obj-y  := ../rcar-common/v3-common.o ../rcar-common/common.o
 endif
diff --git a/board/renesas/eagle/eagle.c b/board/renesas/rcar-common/v3-common.c
similarity index 57%
rename from board/renesas/eagle/eagle.c
rename to board/renesas/rcar-common/v3-common.c
index e9e8059ef6d..be8be0cb16d 100644
--- a/board/renesas/eagle/eagle.c
+++ b/board/renesas/rcar-common/v3-common.c
@@ -1,35 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * board/renesas/eagle/eagle.c
- * This file is Eagle board support.
- *
- * Copyright (C) 2017 Marek Vasut 
+ * Copyright (C) 2017-2023 Marek Vasut 
  */
 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
 
 #define CPGWPR  0xE6150900
 #define CPGWPCR0xE6150904
-- 
2.39.2

[PATCH 01/10] ARM: rmobile: Deduplicate R-Car Gen3/Gen4 reset_cpu()

[Marek Vasut]

The reset_cpu() implementation is basically the same across Gen3
SoCs and identical across Gen4 SoCs. Introduce weak default for
reset_cpu(), so that it does not have to be duplicated in every
board file again.

There is a slight difference for CA53 only systems, like E3 and D3,
which now check MIDR for CPU ID first just like the other systems,
but this is OK since the MIDR always returns CA53 core type and the
correct reset register is written.

Signed-off-by: Marek Vasut 
---
 board/renesas/condor/condor.c | 22 
 board/renesas/draak/draak.c   |  9 ---
 board/renesas/eagle/eagle.c   | 22 
 board/renesas/ebisu/ebisu.c   |  9 ---
 board/renesas/falcon/falcon.c |  7 -
 board/renesas/rcar-common/common.c| 37 +++
 board/renesas/salvator-x/salvator-x.c | 13 ++
 board/renesas/spider/spider.c |  5 
 board/renesas/whitehawk/whitehawk.c   |  5 
 9 files changed, 39 insertions(+), 90 deletions(-)

diff --git a/board/renesas/condor/condor.c b/board/renesas/condor/condor.c
index 2dd2c1534c1..fdb95ac1a59 100644
--- a/board/renesas/condor/condor.c
+++ b/board/renesas/condor/condor.c
@@ -23,25 +23,3 @@ int board_init(void)
 {
return 0;
 }
-
-#define RST_BASE   0xE616
-#define RST_CA57RESCNT (RST_BASE + 0x40)
-#define RST_CA53RESCNT (RST_BASE + 0x44)
-#define RST_RSTOUTCR   (RST_BASE + 0x58)
-#define RST_CA57_CODE  0xA5A5000F
-#define RST_CA53_CODE  0x5A5A000F
-
-void reset_cpu(void)
-{
-   unsigned long midr, cputype;
-
-   asm volatile("mrs %0, midr_el1" : "=r" (midr));
-   cputype = (midr >> 4) & 0xfff;
-
-   if (cputype == 0xd03)
-   writel(RST_CA53_CODE, RST_CA53RESCNT);
-   else if (cputype == 0xd07)
-   writel(RST_CA57_CODE, RST_CA57RESCNT);
-   else
-   hang();
-}
diff --git a/board/renesas/draak/draak.c b/board/renesas/draak/draak.c
index 71efeaf3131..1ed72d34a74 100644
--- a/board/renesas/draak/draak.c
+++ b/board/renesas/draak/draak.c
@@ -67,12 +67,3 @@ int board_init(void)
 
return 0;
 }
-
-#define RST_BASE   0xE616
-#define RST_CA53RESCNT (RST_BASE + 0x44)
-#define RST_CA53_CODE  0x5A5A000F
-
-void reset_cpu(void)
-{
-   writel(RST_CA53_CODE, RST_CA53RESCNT);
-}
diff --git a/board/renesas/eagle/eagle.c b/board/renesas/eagle/eagle.c
index 9af935c33f6..e9e8059ef6d 100644
--- a/board/renesas/eagle/eagle.c
+++ b/board/renesas/eagle/eagle.c
@@ -68,25 +68,3 @@ int board_init(void)
 {
return 0;
 }
-
-#define RST_BASE   0xE616
-#define RST_CA57RESCNT (RST_BASE + 0x40)
-#define RST_CA53RESCNT (RST_BASE + 0x44)
-#define RST_RSTOUTCR   (RST_BASE + 0x58)
-#define RST_CA57_CODE  0xA5A5000F
-#define RST_CA53_CODE  0x5A5A000F
-
-void reset_cpu(void)
-{
-   unsigned long midr, cputype;
-
-   asm volatile("mrs %0, midr_el1" : "=r" (midr));
-   cputype = (midr >> 4) & 0xfff;
-
-   if (cputype == 0xd03)
-   writel(RST_CA53_CODE, RST_CA53RESCNT);
-   else if (cputype == 0xd07)
-   writel(RST_CA57_CODE, RST_CA57RESCNT);
-   else
-   hang();
-}
diff --git a/board/renesas/ebisu/ebisu.c b/board/renesas/ebisu/ebisu.c
index 9a701925961..fd2d9906104 100644
--- a/board/renesas/ebisu/ebisu.c
+++ b/board/renesas/ebisu/ebisu.c
@@ -34,12 +34,3 @@ int board_init(void)
 {
return 0;
 }
-
-#define RST_BASE   0xE616
-#define RST_CA53RESCNT (RST_BASE + 0x44)
-#define RST_CA53_CODE  0x5A5A000F
-
-void reset_cpu(void)
-{
-   writel(RST_CA53_CODE, RST_CA53RESCNT);
-}
diff --git a/board/renesas/falcon/falcon.c b/board/renesas/falcon/falcon.c
index ab7464d0ee3..0aa0f1afcbf 100644
--- a/board/renesas/falcon/falcon.c
+++ b/board/renesas/falcon/falcon.c
@@ -84,8 +84,6 @@ int board_early_init_f(void)
 }
 
 #define RST_BASE   0xE616 /* Domain0 */
-#define RST_SRESCR0(RST_BASE + 0x18)
-#define RST_SPRES  0x5AA58000
 #define RST_WDTRSTCR   (RST_BASE + 0x10)
 #define RST_RWDT   0xA55A8002
 
@@ -103,8 +101,3 @@ int board_init(void)
 
return 0;
 }
-
-void reset_cpu(void)
-{
-   writel(RST_SPRES, RST_SRESCR0);
-}
diff --git a/board/renesas/rcar-common/common.c 
b/board/renesas/rcar-common/common.c
index f38453af82c..17940aa9146 100644
--- a/board/renesas/rcar-common/common.c
+++ b/board/renesas/rcar-common/common.c
@@ -10,8 +10,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -47,6 +49,41 @@ int dram_init_banksize(void)
return 0;
 }
 
+#if defined(CONFIG_RCAR_GEN3)
+#define RST_BASE   0xE616
+#define RST_CA57RESCNT (RST_BASE + 0x40)
+#define RST_CA53RESCNT (RST_BASE + 0x44)
+#define RST_RSTOUTCR   (RST_BASE + 0x58)
+#define RST_CA57_CODE  0xA5A5000F
+#define RST_CA53_CODE  0x5A5A000F
+
+void __weak reset_cpu(void)
+{
+   unsigned long midr, cputype;
+
+   asm volatile("mrs %0, midr_el1" : "=r" (midr));
+   

[PATCH 02/10] ARM: rmobile: Reduce R-Car E3 Ebisu header usage

[Marek Vasut]

There is no need to pull in all those headers as the board file is
basically empty. Drop them all.

Signed-off-by: Marek Vasut 
---
 board/renesas/ebisu/ebisu.c | 22 --
 1 file changed, 22 deletions(-)

diff --git a/board/renesas/ebisu/ebisu.c b/board/renesas/ebisu/ebisu.c
index fd2d9906104..182e9800063 100644
--- a/board/renesas/ebisu/ebisu.c
+++ b/board/renesas/ebisu/ebisu.c
@@ -7,28 +7,6 @@
  */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
 {
-- 
2.39.2

RE: [PATCH v4 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support

[Tom Warren]

Svyatoslav,

I'm still stuck with not being able to run buildman on my local dev laptop(s), 
both 18.04 and 20.04 Ubuntu. So without that, I can't really send TomR a PR.
I could try running 'make *defconfig; make' for each Tegra board and see if 
that works, I'll try to do that later today/tomorrow.

Perhaps someone else (Tom, Simon, or some other custodian) can take these in to 
their repo and get them merged to TOT u-boot/master.

Tom

-Original Message-
From: Svyatoslav Ryhel  
Sent: Wednesday, May 31, 2023 12:11 PM
To: Tom Warren 
Cc: Simon Glass ; Jonas Schwöbel ; 
Svyatoslav Ryhel ; u-boot@lists.denx.de
Subject: Re: [PATCH v4 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support

External email: Use caution opening links or attachments


So what should I do? Re-uploading patches will do nothing I suppose?

Best regards
Svyatoslav R.

вт, 25 квіт. 2023 р. о 11:23 Svyatoslav Ryhel  пише:
>
> This patchset adds support for native use of U-Boot on:
> - ASUS T30 Transformers (7 devices, all models);
> - ASUS/Google Nexus 7 (2012), both grouper and tilapia
> - LG Optimus 4X HD (P880) and Optimus Vu (P895)
> - HTC One X (endeavoru)
> as a replacement for the vendor bootloader.
>
> Current commits are designed to work on re-crypted devices but can be 
> used on clean unmodified devices with slight restrictions (like no 
> booting/mounting emmc and no self updating feature).
>
> All device setup commits fall under the same pattern. Alongside device 
> bringup tegra requires few small patches:
>  - add gpio keyboard as stdin device
>  - make networking boot options optional
>  - add a small tool to generate SoC UID
>
> Commits passed './tools/buildman/buildman tegra' (30 boards) without 
> errors.
>
> ---
> Changes from v3:
> - extended amount of devices supported
>
> Changes from v2:
>  - fuse build is excluded for T186 (it is not supported in it anyway)
>
> Changes from v1:
>  - fix fuse headers for newer Tegra generations
>  - allow grouper_common_defconfig to pass without fragments
> ---
>
> Jonas Schwöbel (1):
>   configs: tegra-common-post: make PXE and DHCP boot targets optional
>
> Svyatoslav Ryhel (6):
>   configs: tegra-common-post: add GPIO keyboard as STDIN device
>   ARM: tegra: add SoC UID calculation function
>   board: asus: transformer: add ASUS Transformer T30 family support
>   board: asus: grouper: add Google Nexus 7 (2012) support
>   board: lg: x3: add Optimus 4X HD and Optimus Vu support
>   board: htc: endeavoru: add One X support
>
>  arch/arm/dts/Makefile |  12 +
>  arch/arm/dts/tegra30-asus-grouper-common.dtsi | 157 ++  
> .../dts/tegra30-asus-nexus7-grouper-E1565.dts |  43 ++  
> .../dts/tegra30-asus-nexus7-grouper-PM269.dts |  36 ++  
> .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |  62 +++
>  arch/arm/dts/tegra30-asus-p1801-t.dts |  17 +
>  arch/arm/dts/tegra30-asus-tf201.dts   |   9 +
>  arch/arm/dts/tegra30-asus-tf300t.dts  |  18 +
>  arch/arm/dts/tegra30-asus-tf300tg.dts |   9 +
>  arch/arm/dts/tegra30-asus-tf300tl.dts |   9 +
>  arch/arm/dts/tegra30-asus-tf600t.dts  |  89 
>  arch/arm/dts/tegra30-asus-tf700t.dts  |  13 +
>  arch/arm/dts/tegra30-asus-transformer.dtsi| 211 
>  arch/arm/dts/tegra30-htc-endeavoru.dts| 166 +++
>  arch/arm/dts/tegra30-lg-p880.dts  |  40 ++
>  arch/arm/dts/tegra30-lg-p895.dts  |  50 ++
>  arch/arm/dts/tegra30-lg-x3.dtsi   | 180 +++
>  arch/arm/include/asm/arch-tegra/fuse.h|   7 +
>  arch/arm/mach-tegra/Makefile  |   4 +
>  arch/arm/mach-tegra/fuse.c| 151 ++
>  arch/arm/mach-tegra/tegra30/Kconfig   |  20 +
>  board/asus/grouper/Kconfig|  22 +
>  board/asus/grouper/MAINTAINERS|   6 +
>  board/asus/grouper/Makefile   |  14 +
>  board/asus/grouper/grouper-spl-max.c  |  45 ++
>  board/asus/grouper/grouper-spl-ti.c   |  41 ++
>  board/asus/grouper/grouper.c  | 202 
>  board/asus/grouper/pinmux-config-grouper.h| 362 ++
>  board/asus/transformer-t30/Kconfig|  35 ++
>  board/asus/transformer-t30/MAINTAINERS|   6 +
>  board/asus/transformer-t30/Makefile   |  11 +
>  .../pinmux-config-transformer.h   | 365 ++
>  .../transformer-t30/transformer-t30-spl.c |  41 ++
>  board/asus/transformer-t30/transformer-t30.c  | 201 
>  board/htc/endeavoru/Kconfig   |  12 +
>  board/htc/endeavoru/MAINTAINERS   |   6 +
>  board/htc/endeavoru/Makefile  |  11 +
>  board/htc/endeavoru/endeavoru-spl.c   |  47 ++
>  board/htc/endeavoru/endeavoru.c   | 116 +
>  board/htc/endeavoru/pinmux-config-endeavoru.h | 362 ++
>  board/lg/x3-t30/Kconfig   |  26 +
>  board/lg/x3-t30/MAINTAINERS   |   6 +

Re: [PATCH 1/2] arm: mach-k3: j721s2: dev-data.c: Add main_uart5 device data

[Bryan Brattlof]

On May 11, 2023 thus sayeth Bhavya Kapoor:
> Add device data for main_uart5 in dev-data.c for J721S2. Now,
> main_uart5 will be powered on while booting the J721S2 SoC.
> 
> Signed-off-by: Bhavya Kapoor 
> ---
>  arch/arm/mach-k3/j721s2/dev-data.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Bryan Brattlof 

~Bryan

Re: [PATCH 2/2] arm: mach-k3: j721s2: clk-data.c: Add main_uart5 clock data

[Bryan Brattlof]

On May 22, 2023 thus sayeth Bhavya Kapoor:
> 
> On 12/05/23 23:12, Bryan Brattlof wrote:
> > Hi Bhavya!
> >
> > On May 11, 2023 thus sayeth Bhavya Kapoor:
> >> Add main_uart5 clocks in clk-data.c for J721S2. Now,
> >> main_uart5 clocks will be set up while booting the J721S2 SoC.
> >>
> >> Signed-off-by: Bhavya Kapoor 
> >> ---
> >>  arch/arm/mach-k3/j721s2/clk-data.c | 7 +--
> >>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-k3/j721s2/clk-data.c 
> >> b/arch/arm/mach-k3/j721s2/clk-data.c
> >> index ad6bd991b7..0c5c321c1e 100644
> >> --- a/arch/arm/mach-k3/j721s2/clk-data.c
> >> +++ b/arch/arm/mach-k3/j721s2/clk-data.c
> >> @@ -247,6 +247,7 @@ static const struct clk_data clk_list[] = {
> >>CLK_MUX("emmcsd1_lb_clksel_out0", emmcsd1_lb_clksel_out0_parents, 2, 
> >> 0x1080b4, 16, 1, 0),
> >>CLK_MUX("mcu_clkout_mux_out0", mcu_clkout_mux_out0_parents, 2, 
> >> 0x40f08010, 0, 1, 0),
> >>CLK_DIV_DEFFREQ("usart_programmable_clock_divider_out0", 
> >> "hsdiv4_16fft_main_1_hsdivout0_clk", 0x1081c0, 0, 2, 0, 0, 4800),
> >> +  CLK_DIV("usart_programmable_clock_divider_out5", 
> >> "hsdiv4_16fft_main_1_hsdivout0_clk", 0x1081d4, 0, 2, 0, 0),
> >>
> > Is this being used as an alternate console? idk if it would be 
> > appropriate to use CLK_DIV_DEFFREQ macro here to setup the uart's 
> > divider here.
> 
> Hi Bryan, yes we will be using this as alternative console.
> 
> And CLK-DIV macro is appropriate here and tested and working fine as well
> 

Sounds good!

Reviewed-by: Bryan Brattlof 

~Bryan

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Stuart Yoder]

On 5/31/23 3:10 PM, Heinrich Schuchardt wrote:

On 5/31/23 21:37, Stuart Yoder wrote:


Unfortunately, the TCG spec is very confusing in section 6.4.4 #2 and
#3.  They attempted to clarify in an errata:
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-Errata-v.5.pdf

...but it is still confusing.

Ilias and I had discussed the ambiguities, and back in March 2022 I
requested clarification from the TCG workgroup.  In cases of
ambiguity TCG frequently will defer to how EDK2 has implemented
a point in the spec.

Here are my notes following the call with TCG about the intent
of #2 and #3, which was based on their review of the EDK2
implementation:

a. If a client passes in a Size that is the full size including all
    fields including ActivePcrBanks, the return code is SUCCESS and
    all fields are populated. [This is a 1.1 client scenario]

b. If a client passes in a Size that includes all fields up to
    and including the vendor ID, the return code is SUCCESS and all
    fields up to including the vendor ID are populated. [This is a
    1.0 client scenario, so a populated 1.0 struct is returned]


This contradicts the TCG EFI Protocol Specifiction which knows of no 1.0
structure but requires:

If the input ProtocolCapability.Size <
sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) the function will initialize
the fields included in ProtocolCapability.Size. The values of the
remaining fields will be undefined.

We should stick with what is specified.

The above requirement is not yet implemented in U-Boot.

Could you, please, indicated where the 1.0 structure was ever defined. I
could not find any a document linked on
https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/


I can't find any public spec with the 1.0 struct.



c. If a client passes in a Size that is less than the size up to
    and including the vendor ID, the return code is BUFFER_TOO_SMALL
    and the Size field is populated with the full size of the struct
    supported by the firmware. [This allows a client to determine
    whether it is talking to 1.0 or 1.1 firmware]


Yes, it is the client's task to check the protocol version and not the
firmware's task to guess what the client has in mind.

ARM should fix their tests that don't comply with the TCG EFI Protocol
Specification and then upstream them to edk-test. U-Boot should not try
to work around incorrect vendor tests.


The spec is not clear.  And the committee that owns the spec provided
the clarifications I outlined. They were supposed to provide an errata
update to publish those clarifications, but it seems somehow that
didn't happen.

I specifically defined the SCT test spec based on what the committee
told me:
https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md

The Arm created tests match what I've been told is the the _intent_ of
the spec.  What is missing is getting TCG to publish errata documenting
that.

Thanks,
Stuart

Re: [PATCH 0/8] Cleanup unaligned access macros

[Tom Rini]

On Mon, 22 May 2023 14:22:30 +0200, Jens Wiklander wrote:

> There are two versions of get/set_unaligned, get_unaligned_be64,
> put_unaligned_le64 etc in U-Boot causing confusion (and bugs).
> 
> In this patch-set, I'm trying to fix that with a single unified version of
> the access macros to be used across all archs. This work is inspired by
> similar changes in this Linux kernel by Arnd Bergman,
> https://lore.kernel.org/lkml/20210514100106.3404011-1-a...@kernel.org/
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Heinrich Schuchardt]

On 5/31/23 21:52, Simon Glass wrote:

Hi Heinrich,

On Wed, 31 May 2023 at 13:27, Heinrich Schuchardt
 wrote:




On 5/31/23 20:24, Tom Rini wrote:

On Wed, May 31, 2023 at 08:05:18PM +0200, Heinrich Schuchardt wrote:



On 5/31/23 19:13, Simon Glass wrote:

Hi Heinrich,

On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:


On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:

Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:


On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:


qemu_arm64_defconfig with UNIT_TEST=y does not build.

CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
must not enable unit tests invoking expo functions.

Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all

uclasses")

Signed-off-by: Heinrich Schuchardt 
---
test/boot/Makefile | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..665017ba3d 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -2,7 +2,10 @@
#
# Copyright 2021 Google LLC

-obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o

bootmeth.o

+ifdef CONFIG_BOOTSTD
+obj-y += bootstd_common.o bootmeth.o
+obj-$(VIDEO) += bootdev.o bootflow.o
+endif
obj-$(CONFIG_FIT) += image.o

obj-$(CONFIG_EXPO) += expo.o


OK, but the functionality itself doesn't depend on video, it looks like
maybe only the bootflow_menu_theme test itself, so lets try and solve
this differently.

--
Tom



Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .


Well no, at first glance it's 1 out of 15 tests in that file that depend
on CONFIG_EXPO, so we should just ifdef that test.


Yes, there is only one test in bootflow.o depending on EXPO.
There are multiple tests in bootdev.o depending on CONFIG_DM_MMC.


And the tests presumably check for DM_MMC, or should.


You could put something like this at the top of bootflow_cmd_menu():

/* 'bootflow menu' currently requires a video console */
if (!IS_ENABLED(CONFIG_VIDEO))
  return -EAGAIN;


With this change I still get:

  aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function
`bootflow_menu_new':


Looks like there's an extra line in boot/Makefile then, we already
include bootflow_menu.o on EXPO.



Hello Simon,

the bootstd tests are in complete disarray

On the sandbox invoked with

./u-boot -T

=> ut bootstd
Can't map file 'mmc1.img': Invalid argument
mmc1: Unable to map file 'mmc1.img'
Failed to set up for bootstd tests (err=-5)

It I create a file mmc1.img:

test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL ==
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
(-22), got 0xffa3 (-93)
test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT ==
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe
(-2), got 0xffa3 (-93)
test/boot/bootdev.c:466, bootdev_test_bootable(): 1 ==
iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL ==
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
(-22), got 0xffa3 (-93)
Test: bootdev_test_bootable: bootdev.c (flat tree)
test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL ==
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
(-22), got 0xffa3 (-93)
test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT ==
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe
(-2), got 0xffa3 (-93)
test/boot/bootdev.c:466, bootdev_test_bootable(): 1 ==
iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL ==
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
(-22), got 0xffa3 (-93)
Test  failed 8 times


I normally run these tests with an alias:  pyt bootstd

# Run a pytest on sandbox
# $1: Name of test to run (optional, else run all)

function pyt {
local tests
local para

if [ "$1" = "-b" ]; then
   crosfw $b || return 1
   shift
fi

if [ "$1" = "-p" ]; then
   para="-n$(nproc) -q"
   shift
fi
tests="$@"
echo $para $tests

shift
test/py/test.py -B sandbox --build-dir /tmp/b/sandbox ${para}
${tests:+"-k $tests"} $@
}

Once I do that once (for setup), I can then run individual tests
directly: rt bootdev_test_bootable


function rt_get_suite_and_name() {
local arg
#echo arg $arg
suite=
name=

if [ "$1" = "-f" ]; then
   force="-f"
   shift
fi
arg="$1"
rest="$2"

# The symbol is something like this:
#   _u_boot_list_2_ut_bootstd_test_2_vbe_simple_test_base
# Split it into the suite name (bootstd) and test name
# (vbe_simple_test_base)
read suite name < \
   <(nm /tmp/b/$exec/u-boot |grep "list_2_ut.*$arg.*" \
  | cut -d' ' -f3 \
  | head -1 \
  | sed -n 's/_u_boot_list_2_ut_\(.*\)_test_2_/\1 /p')
#echo suite $suite
#echo name $name
}

# Run a test
function rt() {
local exec=sandbox

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

[Sam Edwards]

The nonsec code overrides/handles these:
- Setting PMR to 0xFF happens earlier, in _nonsec_init, so this is
  redundant.
- The NS bit is not yet set: it gets set later in _secure_monitor.
  Trying to clear it here is pointless and misleading.

Signed-off-by: Sam Edwards 
---
 arch/arm/cpu/armv7/sunxi/psci.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index e1d3638b5c..f866025c37 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -300,14 +300,10 @@ void __secure psci_arch_init(void)
/* Set SGI15 priority to 0 */
writeb(0, GICD_BASE + GICD_IPRIORITYRn + 15);
 
-   /* Be cool with non-secure */
-   writel(0xff, GICC_BASE + GICC_PMR);
-
/* Switch FIQEn on */
setbits_le32(GICC_BASE + GICC_CTLR, BIT(3));
 
reg = cp15_read_scr();
reg |= BIT(2);  /* Enable FIQ in monitor mode */
-   reg &= ~BIT(0); /* Secure mode */
cp15_write_scr(reg);
 }
-- 
2.39.2

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Heinrich Schuchardt]

On 5/31/23 21:37, Stuart Yoder wrote:


Unfortunately, the TCG spec is very confusing in section 6.4.4 #2 and
#3.  They attempted to clarify in an errata:
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-Errata-v.5.pdf

...but it is still confusing.

Ilias and I had discussed the ambiguities, and back in March 2022 I
requested clarification from the TCG workgroup.  In cases of
ambiguity TCG frequently will defer to how EDK2 has implemented
a point in the spec.

Here are my notes following the call with TCG about the intent
of #2 and #3, which was based on their review of the EDK2
implementation:

a. If a client passes in a Size that is the full size including all
    fields including ActivePcrBanks, the return code is SUCCESS and
    all fields are populated. [This is a 1.1 client scenario]

b. If a client passes in a Size that includes all fields up to
    and including the vendor ID, the return code is SUCCESS and all
    fields up to including the vendor ID are populated. [This is a
    1.0 client scenario, so a populated 1.0 struct is returned]


This contradicts the TCG EFI Protocol Specifiction which knows of no 1.0
structure but requires:

If the input ProtocolCapability.Size <
sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) the function will initialize
the fields included in ProtocolCapability.Size. The values of the
remaining fields will be undefined.

We should stick with what is specified.

The above requirement is not yet implemented in U-Boot.

Could you, please, indicated where the 1.0 structure was ever defined. I
could not find any a document linked on
https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/



c. If a client passes in a Size that is less than the size up to
    and including the vendor ID, the return code is BUFFER_TOO_SMALL
    and the Size field is populated with the full size of the struct
    supported by the firmware. [This allows a client to determine
    whether it is talking to 1.0 or 1.1 firmware]


Yes, it is the client's task to check the protocol version and not the
firmware's task to guess what the client has in mind.

ARM should fix their tests that don't comply with the TCG EFI Protocol
Specification and then upstream them to edk-test. U-Boot should not try
to work around incorrect vendor tests.

Best regards

Heinrich



What Ilias wants to avoid is supporting #b above in u-boot, and
I agree that having u-boot support clients based on struct 1.0
seems unnecessary.


I took a look at the u-boot code.  What I think we want is this:

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index b1c3abd097..6a46d9e51c 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -126,7 +126,7 @@ struct efi_tcg2_boot_service_capability {
  };

  /* up to and including the vendor ID (manufacturer_id) field */
-#define BOOT_SERVICE_CAPABILITY_MIN \
+#define BOOT_SERVICE_CAPABILITY_1_0 \
 offsetof(struct efi_tcg2_boot_service_capability,
number_of_pcr_banks)

  #define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index a83ae7a46c..d37b896b7e 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -742,15 +742,15 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol
*this,
 goto out;
 }

-   if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
-   capability->size = BOOT_SERVICE_CAPABILITY_MIN;
+   if (capability->size < BOOT_SERVICE_CAPABILITY_1_0) {
+   capability->size = sizeof(*capability);
 efi_ret = EFI_BUFFER_TOO_SMALL;
 goto out;
 }

 if (capability->size < sizeof(*capability)) {
 capability->size = sizeof(*capability);
-   efi_ret = EFI_BUFFER_TOO_SMALL;
+   efi_ret = EFI_UNSUPPORTED;
 goto out;
 }

That is:

-if the passed in size is less than the 1.0 struct size
  then return sizeof() the full struct.  This allows
  client to query and determine the supported struct
  size

-to detect and reject 1.0 clients, if the passed in
  size is >= 1.0 struct size AND less than sizeof(*capability)
  then return EFI_UNSUPPORTED

Does that make sense?


No, this will not work. A 1.0 client may call with size = 0 and next
will call with whatever size was returned accompanied by
EFI_BUFFER_TOO_SMALL.


The spec defines the Size field as "Allocated size of the
structure.", so I don't see how a value of 0 makes sense.

If a client wants to just get the Size field populated, pass in
a buffer of Size=1 and firmware will return just the Size field
populated with the correct struct size.


It is the client's obligation to check the values of fields
StructureVersion and ProtocolVersion.


Yes, but what if the client fails to do that? What if a client
passes in a struct with a size corresponding to a 1.0 struct?
What should firmware do?

According to point #b above, firmware 

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Simon Glass]

Hi Heinrich,

On Wed, 31 May 2023 at 13:27, Heinrich Schuchardt
 wrote:
>
>
>
> On 5/31/23 20:24, Tom Rini wrote:
> > On Wed, May 31, 2023 at 08:05:18PM +0200, Heinrich Schuchardt wrote:
> >>
> >>
> >> On 5/31/23 19:13, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:
> 
>  On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:
> > Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:
> >
> >> On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:
> >>
> >>> qemu_arm64_defconfig with UNIT_TEST=y does not build.
> >>>
> >>> CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video 
> >>> we
> >>> must not enable unit tests invoking expo functions.
> >>>
> >>> Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all
> >> uclasses")
> >>> Signed-off-by: Heinrich Schuchardt 
> >>> ---
> >>>test/boot/Makefile | 5 -
> >>>1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/test/boot/Makefile b/test/boot/Makefile
> >>> index 22ed61c8fa..665017ba3d 100644
> >>> --- a/test/boot/Makefile
> >>> +++ b/test/boot/Makefile
> >>> @@ -2,7 +2,10 @@
> >>>#
> >>># Copyright 2021 Google LLC
> >>>
> >>> -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o
> >> bootmeth.o
> >>> +ifdef CONFIG_BOOTSTD
> >>> +obj-y += bootstd_common.o bootmeth.o
> >>> +obj-$(VIDEO) += bootdev.o bootflow.o
> >>> +endif
> >>>obj-$(CONFIG_FIT) += image.o
> >>>
> >>>obj-$(CONFIG_EXPO) += expo.o
> >>
> >> OK, but the functionality itself doesn't depend on video, it looks like
> >> maybe only the bootflow_menu_theme test itself, so lets try and solve
> >> this differently.
> >>
> >> --
> >> Tom
> >>
> >
> > Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .
> 
>  Well no, at first glance it's 1 out of 15 tests in that file that depend
>  on CONFIG_EXPO, so we should just ifdef that test.
> >>
> >> Yes, there is only one test in bootflow.o depending on EXPO.
> >> There are multiple tests in bootdev.o depending on CONFIG_DM_MMC.
> >
> > And the tests presumably check for DM_MMC, or should.
> >
> >>> You could put something like this at the top of bootflow_cmd_menu():
> >>>
> >>> /* 'bootflow menu' currently requires a video console */
> >>> if (!IS_ENABLED(CONFIG_VIDEO))
> >>>  return -EAGAIN;
> >>
> >> With this change I still get:
> >>
> >>  aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function
> >> `bootflow_menu_new':
> >
> > Looks like there's an extra line in boot/Makefile then, we already
> > include bootflow_menu.o on EXPO.
> >
>
> Hello Simon,
>
> the bootstd tests are in complete disarray
>
> On the sandbox invoked with
>
> ./u-boot -T
>
> => ut bootstd
> Can't map file 'mmc1.img': Invalid argument
> mmc1: Unable to map file 'mmc1.img'
> Failed to set up for bootstd tests (err=-5)
>
> It I create a file mmc1.img:
>
> test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL ==
> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> (-22), got 0xffa3 (-93)
> test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT ==
> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe
> (-2), got 0xffa3 (-93)
> test/boot/bootdev.c:466, bootdev_test_bootable(): 1 ==
> iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
> test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL ==
> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> (-22), got 0xffa3 (-93)
> Test: bootdev_test_bootable: bootdev.c (flat tree)
> test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL ==
> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> (-22), got 0xffa3 (-93)
> test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT ==
> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe
> (-2), got 0xffa3 (-93)
> test/boot/bootdev.c:466, bootdev_test_bootable(): 1 ==
> iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
> test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL ==
> bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea
> (-22), got 0xffa3 (-93)
> Test  failed 8 times

I normally run these tests with an alias:  pyt bootstd

# Run a pytest on sandbox
# $1: Name of test to run (optional, else run all)

function pyt {
   local tests
   local para

   if [ "$1" = "-b" ]; then
  crosfw $b || return 1
  shift
   fi

   if [ "$1" = "-p" ]; then
  para="-n$(nproc) -q"
  shift
   fi
   tests="$@"
   echo $para $tests

   shift
   test/py/test.py -B sandbox --build-dir /tmp/b/sandbox ${para}
${tests:+"-k $tests"} $@
}

Once I do that once (for setup), I can then run individual tests
directly: rt bootdev_test_bootable


function rt_get_suite_and_name() {
   local arg
   #echo arg $arg
   suite=
   name=

   if [ "$1" = "-f" ]; then
  

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Stuart Yoder]

Unfortunately, the TCG spec is very confusing in section 6.4.4 #2 and
#3.  They attempted to clarify in an errata:
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-Errata-v.5.pdf

...but it is still confusing.

Ilias and I had discussed the ambiguities, and back in March 2022 I
requested clarification from the TCG workgroup.  In cases of
ambiguity TCG frequently will defer to how EDK2 has implemented
a point in the spec.

Here are my notes following the call with TCG about the intent
of #2 and #3, which was based on their review of the EDK2
implementation:

a. If a client passes in a Size that is the full size including all
   fields including ActivePcrBanks, the return code is SUCCESS and
   all fields are populated. [This is a 1.1 client scenario]

b. If a client passes in a Size that includes all fields up to
   and including the vendor ID, the return code is SUCCESS and all
   fields up to including the vendor ID are populated. [This is a
   1.0 client scenario, so a populated 1.0 struct is returned]

c. If a client passes in a Size that is less than the size up to
   and including the vendor ID, the return code is BUFFER_TOO_SMALL
   and the Size field is populated with the full size of the struct
   supported by the firmware. [This allows a client to determine
   whether it is talking to 1.0 or 1.1 firmware]

What Ilias wants to avoid is supporting #b above in u-boot, and
I agree that having u-boot support clients based on struct 1.0
seems unnecessary.


I took a look at the u-boot code.  What I think we want is this:

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index b1c3abd097..6a46d9e51c 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -126,7 +126,7 @@ struct efi_tcg2_boot_service_capability {
  };

  /* up to and including the vendor ID (manufacturer_id) field */
-#define BOOT_SERVICE_CAPABILITY_MIN \
+#define BOOT_SERVICE_CAPABILITY_1_0 \
 offsetof(struct efi_tcg2_boot_service_capability,
number_of_pcr_banks)

  #define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index a83ae7a46c..d37b896b7e 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -742,15 +742,15 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol
*this,
 goto out;
 }

-   if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
-   capability->size = BOOT_SERVICE_CAPABILITY_MIN;
+   if (capability->size < BOOT_SERVICE_CAPABILITY_1_0) {
+   capability->size = sizeof(*capability);
 efi_ret = EFI_BUFFER_TOO_SMALL;
 goto out;
 }

 if (capability->size < sizeof(*capability)) {
 capability->size = sizeof(*capability);
-   efi_ret = EFI_BUFFER_TOO_SMALL;
+   efi_ret = EFI_UNSUPPORTED;
 goto out;
 }

That is:

-if the passed in size is less than the 1.0 struct size
  then return sizeof() the full struct.  This allows
  client to query and determine the supported struct
  size

-to detect and reject 1.0 clients, if the passed in
  size is >= 1.0 struct size AND less than sizeof(*capability)
  then return EFI_UNSUPPORTED

Does that make sense?


No, this will not work. A 1.0 client may call with size = 0 and next
will call with whatever size was returned accompanied by
EFI_BUFFER_TOO_SMALL.


The spec defines the Size field as "Allocated size of the
structure.", so I don't see how a value of 0 makes sense.

If a client wants to just get the Size field populated, pass in
a buffer of Size=1 and firmware will return just the Size field
populated with the correct struct size.


It is the client's obligation to check the values of fields
StructureVersion and ProtocolVersion.


Yes, but what if the client fails to do that? What if a client
passes in a struct with a size corresponding to a 1.0 struct?
What should firmware do?

According to point #b above, firmware should support the 1.0
client and populate only the 1.0 fields.  But, what we are
proposing is not supporting that in u-boot.  Instead return
EFI_UNSUPPORTED.  I can discuss this with the TCG WG.

Thanks,
Stuart

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Heinrich Schuchardt]

On 5/31/23 20:24, Tom Rini wrote:

On Wed, May 31, 2023 at 08:05:18PM +0200, Heinrich Schuchardt wrote:



On 5/31/23 19:13, Simon Glass wrote:

Hi Heinrich,

On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:


On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:

Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:


On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:


qemu_arm64_defconfig with UNIT_TEST=y does not build.

CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
must not enable unit tests invoking expo functions.

Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all

uclasses")

Signed-off-by: Heinrich Schuchardt 
---
   test/boot/Makefile | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..665017ba3d 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -2,7 +2,10 @@
   #
   # Copyright 2021 Google LLC

-obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o

bootmeth.o

+ifdef CONFIG_BOOTSTD
+obj-y += bootstd_common.o bootmeth.o
+obj-$(VIDEO) += bootdev.o bootflow.o
+endif
   obj-$(CONFIG_FIT) += image.o

   obj-$(CONFIG_EXPO) += expo.o


OK, but the functionality itself doesn't depend on video, it looks like
maybe only the bootflow_menu_theme test itself, so lets try and solve
this differently.

--
Tom



Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .


Well no, at first glance it's 1 out of 15 tests in that file that depend
on CONFIG_EXPO, so we should just ifdef that test.


Yes, there is only one test in bootflow.o depending on EXPO.
There are multiple tests in bootdev.o depending on CONFIG_DM_MMC.


And the tests presumably check for DM_MMC, or should.


You could put something like this at the top of bootflow_cmd_menu():

/* 'bootflow menu' currently requires a video console */
if (!IS_ENABLED(CONFIG_VIDEO))
 return -EAGAIN;


With this change I still get:

aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function
`bootflow_menu_new':


Looks like there's an extra line in boot/Makefile then, we already
include bootflow_menu.o on EXPO.



Hello Simon,

the bootstd tests are in complete disarray

On the sandbox invoked with

./u-boot -T

=> ut bootstd
Can't map file 'mmc1.img': Invalid argument
mmc1: Unable to map file 'mmc1.img'
Failed to set up for bootstd tests (err=-5)

It I create a file mmc1.img:

test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL == 
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea 
(-22), got 0xffa3 (-93)
test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT == 
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe 
(-2), got 0xffa3 (-93)
test/boot/bootdev.c:466, bootdev_test_bootable(): 1 == 
iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL == 
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea 
(-22), got 0xffa3 (-93)

Test: bootdev_test_bootable: bootdev.c (flat tree)
test/boot/bootdev.c:460, bootdev_test_bootable(): -EINVAL == 
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea 
(-22), got 0xffa3 (-93)
test/boot/bootdev.c:465, bootdev_test_bootable(): -ENOENT == 
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xfffe 
(-2), got 0xffa3 (-93)
test/boot/bootdev.c:466, bootdev_test_bootable(): 1 == 
iter.first_bootable: Expected 0x1 (1), got 0x0 (0)
test/boot/bootdev.c:470, bootdev_test_bootable(): -EINVAL == 
bootdev_find_in_blk(iter.dev, blk, , ): Expected 0xffea 
(-22), got 0xffa3 (-93)

Test  failed 8 times

As discussed previously:

The general expectation is that unit tests can be run successfully on 
any physical or emulated board. Should a test not comply with this 
requirement the test must be deactivated automatically upon build.


A test like
ut_assert_skip_to_line(
"sandbox: continuing, as we cannot run Linux");
will never succeed on other architectures.

Best regards

Heinrich

Re: [PATCH v4 0/7] Tegra: add ASUS/Google Nexus 7 (2012) support

[Svyatoslav Ryhel]

So what should I do? Re-uploading patches will do nothing I suppose?

Best regards
Svyatoslav R.

вт, 25 квіт. 2023 р. о 11:23 Svyatoslav Ryhel  пише:
>
> This patchset adds support for native use of U-Boot on:
> - ASUS T30 Transformers (7 devices, all models);
> - ASUS/Google Nexus 7 (2012), both grouper and tilapia
> - LG Optimus 4X HD (P880) and Optimus Vu (P895)
> - HTC One X (endeavoru)
> as a replacement for the vendor bootloader.
>
> Current commits are designed to work on re-crypted devices but can
> be used on clean unmodified devices with slight restrictions (like
> no booting/mounting emmc and no self updating feature).
>
> All device setup commits fall under the same pattern. Alongside device
> bringup tegra requires few small patches:
>  - add gpio keyboard as stdin device
>  - make networking boot options optional
>  - add a small tool to generate SoC UID
>
> Commits passed './tools/buildman/buildman tegra' (30 boards) without
> errors.
>
> ---
> Changes from v3:
> - extended amount of devices supported
>
> Changes from v2:
>  - fuse build is excluded for T186 (it is not supported in it anyway)
>
> Changes from v1:
>  - fix fuse headers for newer Tegra generations
>  - allow grouper_common_defconfig to pass without fragments
> ---
>
> Jonas Schwöbel (1):
>   configs: tegra-common-post: make PXE and DHCP boot targets optional
>
> Svyatoslav Ryhel (6):
>   configs: tegra-common-post: add GPIO keyboard as STDIN device
>   ARM: tegra: add SoC UID calculation function
>   board: asus: transformer: add ASUS Transformer T30 family support
>   board: asus: grouper: add Google Nexus 7 (2012) support
>   board: lg: x3: add Optimus 4X HD and Optimus Vu support
>   board: htc: endeavoru: add One X support
>
>  arch/arm/dts/Makefile |  12 +
>  arch/arm/dts/tegra30-asus-grouper-common.dtsi | 157 ++
>  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |  43 ++
>  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |  36 ++
>  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |  62 +++
>  arch/arm/dts/tegra30-asus-p1801-t.dts |  17 +
>  arch/arm/dts/tegra30-asus-tf201.dts   |   9 +
>  arch/arm/dts/tegra30-asus-tf300t.dts  |  18 +
>  arch/arm/dts/tegra30-asus-tf300tg.dts |   9 +
>  arch/arm/dts/tegra30-asus-tf300tl.dts |   9 +
>  arch/arm/dts/tegra30-asus-tf600t.dts  |  89 
>  arch/arm/dts/tegra30-asus-tf700t.dts  |  13 +
>  arch/arm/dts/tegra30-asus-transformer.dtsi| 211 
>  arch/arm/dts/tegra30-htc-endeavoru.dts| 166 +++
>  arch/arm/dts/tegra30-lg-p880.dts  |  40 ++
>  arch/arm/dts/tegra30-lg-p895.dts  |  50 ++
>  arch/arm/dts/tegra30-lg-x3.dtsi   | 180 +++
>  arch/arm/include/asm/arch-tegra/fuse.h|   7 +
>  arch/arm/mach-tegra/Makefile  |   4 +
>  arch/arm/mach-tegra/fuse.c| 151 ++
>  arch/arm/mach-tegra/tegra30/Kconfig   |  20 +
>  board/asus/grouper/Kconfig|  22 +
>  board/asus/grouper/MAINTAINERS|   6 +
>  board/asus/grouper/Makefile   |  14 +
>  board/asus/grouper/grouper-spl-max.c  |  45 ++
>  board/asus/grouper/grouper-spl-ti.c   |  41 ++
>  board/asus/grouper/grouper.c  | 202 
>  board/asus/grouper/pinmux-config-grouper.h| 362 ++
>  board/asus/transformer-t30/Kconfig|  35 ++
>  board/asus/transformer-t30/MAINTAINERS|   6 +
>  board/asus/transformer-t30/Makefile   |  11 +
>  .../pinmux-config-transformer.h   | 365 ++
>  .../transformer-t30/transformer-t30-spl.c |  41 ++
>  board/asus/transformer-t30/transformer-t30.c  | 201 
>  board/htc/endeavoru/Kconfig   |  12 +
>  board/htc/endeavoru/MAINTAINERS   |   6 +
>  board/htc/endeavoru/Makefile  |  11 +
>  board/htc/endeavoru/endeavoru-spl.c   |  47 ++
>  board/htc/endeavoru/endeavoru.c   | 116 +
>  board/htc/endeavoru/pinmux-config-endeavoru.h | 362 ++
>  board/lg/x3-t30/Kconfig   |  26 +
>  board/lg/x3-t30/MAINTAINERS   |   6 +
>  board/lg/x3-t30/Makefile  |  11 +
>  board/lg/x3-t30/pinmux-config-x3.h| 449 ++
>  board/lg/x3-t30/x3-t30-spl.c  |  48 ++
>  board/lg/x3-t30/x3-t30.c  | 176 +++
>  configs/endeavoru_defconfig   |  82 
>  configs/grouper_E1565.config  |   2 +
>  configs/grouper_PM269.config  |   2 +
>  configs/grouper_common_defconfig  |  82 
>  configs/p1801-t.config|   2 +
>  configs/p880.config   |   4 +
>  configs/p895.config   |   4 +
>  configs/tf201.config  |   2 +
>  configs/tf300t.config |  

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Tom Rini]

On Wed, May 31, 2023 at 08:05:18PM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 5/31/23 19:13, Simon Glass wrote:
> > Hi Heinrich,
> > 
> > On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:
> > > 
> > > On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:
> > > > Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:
> > > > 
> > > > > On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:
> > > > > 
> > > > > > qemu_arm64_defconfig with UNIT_TEST=y does not build.
> > > > > > 
> > > > > > CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without 
> > > > > > video we
> > > > > > must not enable unit tests invoking expo functions.
> > > > > > 
> > > > > > Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all
> > > > > uclasses")
> > > > > > Signed-off-by: Heinrich Schuchardt 
> > > > > > 
> > > > > > ---
> > > > > >   test/boot/Makefile | 5 -
> > > > > >   1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > > 
> > > > > > diff --git a/test/boot/Makefile b/test/boot/Makefile
> > > > > > index 22ed61c8fa..665017ba3d 100644
> > > > > > --- a/test/boot/Makefile
> > > > > > +++ b/test/boot/Makefile
> > > > > > @@ -2,7 +2,10 @@
> > > > > >   #
> > > > > >   # Copyright 2021 Google LLC
> > > > > > 
> > > > > > -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o
> > > > > bootmeth.o
> > > > > > +ifdef CONFIG_BOOTSTD
> > > > > > +obj-y += bootstd_common.o bootmeth.o
> > > > > > +obj-$(VIDEO) += bootdev.o bootflow.o
> > > > > > +endif
> > > > > >   obj-$(CONFIG_FIT) += image.o
> > > > > > 
> > > > > >   obj-$(CONFIG_EXPO) += expo.o
> > > > > 
> > > > > OK, but the functionality itself doesn't depend on video, it looks 
> > > > > like
> > > > > maybe only the bootflow_menu_theme test itself, so lets try and solve
> > > > > this differently.
> > > > > 
> > > > > --
> > > > > Tom
> > > > > 
> > > > 
> > > > Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .
> > > 
> > > Well no, at first glance it's 1 out of 15 tests in that file that depend
> > > on CONFIG_EXPO, so we should just ifdef that test.
> 
> Yes, there is only one test in bootflow.o depending on EXPO.
> There are multiple tests in bootdev.o depending on CONFIG_DM_MMC.

And the tests presumably check for DM_MMC, or should.

> > You could put something like this at the top of bootflow_cmd_menu():
> > 
> > /* 'bootflow menu' currently requires a video console */
> > if (!IS_ENABLED(CONFIG_VIDEO))
> > return -EAGAIN;
> 
> With this change I still get:
> 
>   aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function
> `bootflow_menu_new':

Looks like there's an extra line in boot/Makefile then, we already
include bootflow_menu.o on EXPO.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Heinrich Schuchardt]

On 5/31/23 19:13, Simon Glass wrote:

Hi Heinrich,

On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:


On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:

Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:


On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:


qemu_arm64_defconfig with UNIT_TEST=y does not build.

CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
must not enable unit tests invoking expo functions.

Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all

uclasses")

Signed-off-by: Heinrich Schuchardt 
---
  test/boot/Makefile | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..665017ba3d 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -2,7 +2,10 @@
  #
  # Copyright 2021 Google LLC

-obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o

bootmeth.o

+ifdef CONFIG_BOOTSTD
+obj-y += bootstd_common.o bootmeth.o
+obj-$(VIDEO) += bootdev.o bootflow.o
+endif
  obj-$(CONFIG_FIT) += image.o

  obj-$(CONFIG_EXPO) += expo.o


OK, but the functionality itself doesn't depend on video, it looks like
maybe only the bootflow_menu_theme test itself, so lets try and solve
this differently.

--
Tom



Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .


Well no, at first glance it's 1 out of 15 tests in that file that depend
on CONFIG_EXPO, so we should just ifdef that test.


Yes, there is only one test in bootflow.o depending on EXPO.
There are multiple tests in bootdev.o depending on CONFIG_DM_MMC.



You could put something like this at the top of bootflow_cmd_menu():

/* 'bootflow menu' currently requires a video console */
if (!IS_ENABLED(CONFIG_VIDEO))
return -EAGAIN;


With this change I still get:

	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function 
`bootflow_menu_new':

boot/bootflow_menu.c:48: undefined reference to `expo_new'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:52: undefined reference 
to `scene_new'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:56: undefined reference 
to `scene_txt_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:59: undefined reference 
to `scene_menu'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:60: undefined reference 
to `scene_obj_set_pos'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:61: undefined reference 
to `scene_txt_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:63: undefined reference 
to `scene_menu_set_title'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:65: undefined reference 
to `video_get_u_boot_logo'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:67: undefined reference 
to `scene_img'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:68: undefined reference 
to `scene_obj_set_pos'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:71: undefined reference 
to `scene_txt_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:73: undefined reference 
to `scene_menu_set_pointer'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:101: undefined reference 
to `expo_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:102: undefined reference 
to `scene_txt_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:104: undefined reference 
to `scene_txt_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:107: undefined reference 
to `scene_txt_str'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:112: undefined reference 
to `scene_img'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:115: undefined reference 
to `scene_menuitem'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.o: in function 
`bootflow_menu_apply_theme':

boot/bootflow_menu.c:140: undefined reference to `expo_lookup_scene_id'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:162: undefined reference 
to `scene_arrange'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:149: undefined reference 
to `scene_txt_set_font'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:150: undefined reference 
to `scene_txt_set_font'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:152: undefined reference 
to `scene_txt_set_font'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:156: undefined reference 
to `scene_txt_set_font'
	aarch64-linux-gnu-ld.bfd: boot/bootflow_menu.c:157: undefined reference 
to `scene_txt_set_font'
	aarch64-linux-gnu-ld.bfd: test/boot/bootstd_common.o: in function 
`bootstd_test_check_mmc_hunter':
	test/boot/bootstd_common.c:83: undefined reference to 
`_u_boot_list_2_bootdev_hunter_2_mmc_bootdev_hunter'
	aarch64-linux-gnu-ld.bfd: test/boot/bootstd_common.o: relocation 
R_AARCH64_ADR_PREL_PG_HI21 against symbol 
`_u_boot_list_2_bootdev_hunter_2_mmc_bootdev_hunter' which may bind 
externally can not be used when making a shared object; recompile with -fPIC


test/boot/bootstd_common.c:83:(.text.bootstd_test_check_mmc_hunter+0x5c): 
dangerous relocation: unsupported relocation
	aarch64-linux-gnu-ld.bfd: test/boot/bootstd_common.c:83: undefined 
reference to 

[PATCH v7 4/4] Load option with short device path for boot vars

[Raymond Mao]

The boot variables automatically generated for removable medias
should be with short form of device path without device nodes.
This is a requirement for the case that a removable media is
plugged into a different port but is still able to work with the
existing boot variables.

Signed-off-by: Raymond Mao 
Reviewed-by: Heinrich Schuchardt 
---
Changes in v2
- Ignore EFI_NOT_FOUND returned from
  efi_bootmgr_update_media_device_boot_option which means no boot
  options scanned.
Changes in v3
- Split the patch into moving and renaming functions and
  individual patches for each changed functionality
Changes in v4
- Revert v2 change of introducing a bool parameter when updating
  the boot option. Use short-form of device path by default
Changes in v5
- Add warning log when a short-form device path doesn't exist
Changes in v6
- Revert v5 change and use original device path if short-form does
  not exist

 lib/efi_loader/efi_bootmgr.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 95559ad6dd..90151f45d7 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -371,6 +371,7 @@ static efi_status_t 
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
struct efi_load_option lo;
char buf[BOOTMENU_DEVICE_NAME_MAX];
struct efi_device_path *device_path;
+   struct efi_device_path *short_dp;
 
ret = efi_search_protocol(volume_handles[i], 
_guid_device_path, );
if (ret != EFI_SUCCESS)
@@ -387,6 +388,11 @@ static efi_status_t 
efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
p = dev_name;
utf8_utf16_strncpy(, buf, strlen(buf));
 
+   /* prefer to short form device path */
+   short_dp = efi_dp_shorten(device_path);
+   if (short_dp)
+   device_path = short_dp;
+
lo.label = dev_name;
lo.attributes = LOAD_OPTION_ACTIVE;
lo.file_path = device_path;
-- 
2.25.1

[PATCH v7 3/4] Boot var automatic management for removable medias

[Raymond Mao]

Changes for complying to EFI spec §3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.

Signed-off-by: Raymond Mao 
---
Changes in v3
- Split the patch into moving and renaming functions and
  individual patches for each changed functionality
Changes in v5
- Move function call of efi_bootmgr_update_media_device_boot_option()
  from efi_init_variables() to efi_init_obj_list()
Changes in v6
- Revert unrelated changes
Changes in v7
- adapt the return code of function
  efi_bootmgr_update_media_device_boot_option()

 lib/efi_loader/efi_disk.c  | 7 +++
 lib/efi_loader/efi_setup.c | 5 +
 2 files changed, 12 insertions(+)

diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index d2256713a8..d9b48ecf64 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
return -1;
}
 
+   /* only do the boot option management when UEFI sub-system is 
initialized */
+   if (efi_obj_list_initialized == EFI_SUCCESS) {
+   ret = efi_bootmgr_update_media_device_boot_option();
+   if (ret != EFI_SUCCESS)
+   return -1;
+   }
+
return 0;
 }
 
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 58d4e13402..877f3878d6 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -245,6 +245,11 @@ efi_status_t efi_init_obj_list(void)
if (ret != EFI_SUCCESS)
goto out;
 
+   /* update boot option after variable service initialized */
+   ret = efi_bootmgr_update_media_device_boot_option();
+   if (ret != EFI_SUCCESS)
+   goto out;
+
/* Define supported languages */
ret = efi_init_platform_lang();
if (ret != EFI_SUCCESS)
-- 
2.25.1

[PATCH v7 2/4] Fix incorrect return code of boot option update

[Raymond Mao]

Correct the return code for out-of-memory and no boot option found

Signed-off-by: Raymond Mao 
---
Changes in v7
- new patch file created

 cmd/bootmenu.c   | 2 +-
 cmd/eficonfig.c  | 2 +-
 lib/efi_loader/efi_bootmgr.c | 8 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 01daddca7b..987b16889f 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -352,7 +352,7 @@ static struct bootmenu_data *bootmenu_create(int delay)
 * a architecture-specific default image name such as 
BOOTAA64.EFI.
 */
efi_ret = efi_bootmgr_update_media_device_boot_option();
-   if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
+   if (efi_ret != EFI_SUCCESS)
goto cleanup;
 
ret = prepare_uefi_bootorder_entry(menu, , );
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 82a80306f4..e6e8a0a488 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -2314,7 +2314,7 @@ static int do_eficonfig(struct cmd_tbl *cmdtp, int flag, 
int argc, char *const a
return CMD_RET_FAILURE;
 
ret = efi_bootmgr_update_media_device_boot_option();
-   if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
+   if (ret != EFI_SUCCESS)
return ret;
 
while (1) {
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 48cd5f0636..95559ad6dd 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -663,11 +663,13 @@ efi_status_t 
efi_bootmgr_update_media_device_boot_option(void)
   NULL, ,
   (efi_handle_t **)_handles);
if (ret != EFI_SUCCESS)
-   return ret;
+   goto out;
 
opt = calloc(count, sizeof(struct eficonfig_media_boot_option));
-   if (!opt)
+   if (!opt) {
+   ret = EFI_OUT_OF_RESOURCES;
goto out;
+   }
 
/* enumerate all devices supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL */
ret = efi_bootmgr_enumerate_boot_option(opt, volume_handles, count);
@@ -720,5 +722,7 @@ out:
free(opt);
efi_free_pool(volume_handles);
 
+   if (ret == EFI_NOT_FOUND)
+   return EFI_SUCCESS;
return ret;
 }
-- 
2.25.1

[PATCH v7 1/4] Move bootorder and bootoption apis to lib

[Raymond Mao]

Rename and move bootorder and bootoption apis from cmd to lib
for re-use between eficonfig and bootmgr

Signed-off-by: Raymond Mao 
Reviewed-by: Heinrich Schuchardt 
---
Changes in v3
- Split the patch into moving and renaming functions and
  individual patches for each changed functionality
Changes in v6
- Revert v3 changes in function
  efi_bootmgr_update_media_device_boot_option and
  efi_bootmgr_delete_invalid_boot_option

 cmd/bootmenu.c   |   2 +-
 cmd/eficonfig.c  | 408 +--
 include/efi_config.h |   5 -
 include/efi_loader.h |  11 +
 lib/efi_loader/efi_bootmgr.c | 375 
 lib/efi_loader/efi_helper.c  |  25 +++
 6 files changed, 418 insertions(+), 408 deletions(-)

diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 6baeedc69f..01daddca7b 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int delay)
 * UEFI specification requires booting from removal media using
 * a architecture-specific default image name such as 
BOOTAA64.EFI.
 */
-   efi_ret = eficonfig_generate_media_device_boot_option();
+   efi_ret = efi_bootmgr_update_media_device_boot_option();
if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
goto cleanup;
 
diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
index 720f52b48b..82a80306f4 100644
--- a/cmd/eficonfig.c
+++ b/cmd/eficonfig.c
@@ -1134,43 +1134,6 @@ out:
return ret;
 }
 
-/**
- * eficonfig_get_unused_bootoption() - get unused "Boot" index
- *
- * @buf:   pointer to the buffer to store boot option variable name
- * @buf_size:  buffer size
- * @index: pointer to store the index in the BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t buf_size,
-unsigned int *index)
-{
-   u32 i;
-   efi_status_t ret;
-   efi_uintn_t size;
-
-   if (buf_size < u16_strsize(u"Boot"))
-   return EFI_BUFFER_TOO_SMALL;
-
-   for (i = 0; i <= 0x; i++) {
-   size = 0;
-   efi_create_indexed_name(buf, buf_size, "Boot", i);
-   ret = efi_get_variable_int(buf, _global_variable_guid,
-  NULL, , NULL, NULL);
-   if (ret == EFI_BUFFER_TOO_SMALL)
-   continue;
-   else
-   break;
-   }
-
-   if (i > 0x)
-   return EFI_OUT_OF_RESOURCES;
-
-   *index = i;
-
-   return EFI_SUCCESS;
-}
-
 /**
  * eficonfig_set_boot_option() - set boot option
  *
@@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16 
*varname, struct efi_device_pa
return ret;
 }
 
-/**
- * eficonfig_append_bootorder() - append new boot option in BootOrder variable
- *
- * @index: "Boot" index to append to BootOrder variable
- * Return: status code
- */
-efi_status_t eficonfig_append_bootorder(u16 index)
-{
-   u16 *bootorder;
-   efi_status_t ret;
-   u16 *new_bootorder = NULL;
-   efi_uintn_t last, size, new_size;
-
-   /* append new boot option */
-   bootorder = efi_get_var(u"BootOrder", _global_variable_guid, );
-   last = size / sizeof(u16);
-   new_size = size + sizeof(u16);
-   new_bootorder = calloc(1, new_size);
-   if (!new_bootorder) {
-   ret = EFI_OUT_OF_RESOURCES;
-   goto out;
-   }
-   memcpy(new_bootorder, bootorder, size);
-   new_bootorder[last] = index;
-
-   ret = efi_set_variable_int(u"BootOrder", _global_variable_guid,
-  EFI_VARIABLE_NON_VOLATILE |
-  EFI_VARIABLE_BOOTSERVICE_ACCESS |
-  EFI_VARIABLE_RUNTIME_ACCESS,
-  new_size, new_bootorder, false);
-   if (ret != EFI_SUCCESS)
-   goto out;
-
-out:
-   free(bootorder);
-   free(new_bootorder);
-
-   return ret;
-}
-
 /**
  * create_boot_option_entry() - create boot option entry
  *
@@ -1619,7 +1542,7 @@ static efi_status_t 
eficonfig_process_add_boot_option(void *data)
if (!bo)
return EFI_OUT_OF_RESOURCES;
 
-   ret = eficonfig_get_unused_bootoption(varname, sizeof(varname), 
>boot_index);
+   ret = efi_bootmgr_get_unused_bootoption(varname, sizeof(varname), 
>boot_index);
if (ret != EFI_SUCCESS)
return ret;
 
@@ -1627,7 +1550,7 @@ static efi_status_t 
eficonfig_process_add_boot_option(void *data)
if (ret != EFI_SUCCESS)
goto out;
 
-   ret = eficonfig_append_bootorder((u16)bo->boot_index);
+   ret = efi_bootmgr_append_bootorder((u16)bo->boot_index);
if (ret != EFI_SUCCESS)
goto out;
 

[PATCH v7 0/4] Boot variables management for removable media

[Raymond Mao]

Major changes:
1.Rename and move bootorder and bootoption apis from cmd to lib
  for re-use between eficonfig and bootmgr
2.Fix incorrect return code of boot option update
  Correct the return code for out-of-memory and no boot option found
3.Changes for complying to EFI spec §3.5.1.1
  'Removable Media Boot Behavior'.
  Boot variables can be automatically generated during a removable
  media is probed. At the same time, unused boot variables will be
  detected and removed.
4.The boot variables automatically generated for removable medias
  should be with short form of device path without device nodes.
  This is a requirement for the case that a removable media is
  plugged into a different port but is still able to work with the
  existing boot variables.

Raymond Mao (4):
  Move bootorder and bootoption apis to lib
  Fix incorrect return code of boot option update
  Boot var automatic management for removable medias
  Load option with short device path for boot vars

 cmd/bootmenu.c   |   4 +-
 cmd/eficonfig.c  | 410 +--
 include/efi_config.h |   5 -
 include/efi_loader.h |  11 +
 lib/efi_loader/efi_bootmgr.c | 385 
 lib/efi_loader/efi_disk.c|   7 +
 lib/efi_loader/efi_helper.c  |  25 +++
 lib/efi_loader/efi_setup.c   |   5 +
 8 files changed, 442 insertions(+), 410 deletions(-)

-- 
2.25.1

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Heinrich Schuchardt]

On 5/31/23 18:41, Stuart Yoder wrote:



On 5/31/23 2:48 AM, Ilias Apalodimas wrote:

Hi Stuart,

On Wed, 31 May 2023 at 00:20, Stuart Yoder  wrote:




On 5/30/23 1:39 AM, Ilias Apalodimas wrote:

In the EFI TCG spec EFI_TCG2_BOOT_SERVICE_CAPABILITY struct is
versioned -- there are 1.0 and 1.1 versions of that struct.
The spec [0] describes:
"Version of the EFI_TCG2_BOOT_SERVICE_CAPABILITY
structure itself. For this version of the protocol, the Major version
SHALL be set to 1 and the Minor version SHALL be set to 1."
which is what we currently support.

The SCT tests perfromed By Arms SIE(Security interface extensions) [1]
perform a check for clients supporting the older 1.0 version of the
spec (Test 30.1.1.4). Given than this spec is 7 years old,  there
should
be no need for the older 1.0 version support.  Instead of returning
EFI_BUFFER_TOO_SMALLL switch to EFI_UNSUPPORTED which is more
appropriate.  It's worth noting that the spec doesn't explicitly
describe the return value at the moment.


Please, open a bug report for the SCT. It should check the value of
ProtocolCapability.ProtocolVersion returned by GetCapability() and
provide code paths for 1.0 and 1.1.



[0]
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
[1]
https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md

Signed-off-by: Ilias Apalodimas 
---

Heinrich,  Stuart is investigating the chance of the spec getting
updated
adding EFI_UNSUPPORTED.  In any case I think the patch should be
aplied since
the new return code makes more sense.  If for some reason the spec
change is
rejected, I can go back and add support for 1.0 structure versions.

   lib/efi_loader/efi_tcg2.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index a83ae7a46cf3..220c442bdf93 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -750,7 +750,7 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol
*this,

   if (capability->size < sizeof(*capability)) {
   capability->size = sizeof(*capability);
- efi_ret = EFI_BUFFER_TOO_SMALL;
+ efi_ret = EFI_UNSUPPORTED;


This is contradicts the standard. You MUST return EFI_BUFFER_TOO_SMALL.
It is the clients obligation to check StructureVersion and ProtocolVersion.


   goto out;
   }


Hi Ilias,

I don't think this is the right fix.

The struct looks like this:

struct tdEFI_TCG2_BOOT_SERVICE_CAPABILITY {
    UINT8 Size;
    EFI_TCG2_VERSION StructureVersion;
    EFI_TCG2_VERSION ProtocolVersion;
    EFI_TCG2_EVENT_ALGORITHM_BITMAP HashAlgorithmBitmap
    EFI_TCG2_EVENT_LOG_BITMAP SupportedEventLogs
    BOOLEAN TPMPresentFlag
    UINT16 MaxCommandSize
    UINT16 MaxResponseSize
    UINT32 ManufacturerID
    UINT32 NumberOfPcrBanks
    EFI_TCG2_EVENT_ALGORITHM_BITMAP ActivePcrBanks
};

The intent in the TCG spec is for the caller to be able to
determine the size of the struct by passing in a small
buffer (e.g. 1 byte buffer), and then the firmware
should return sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) in the
1-byte "Size" field.  And the return value should be
EFI_BUFFER_TOO_SMALL as per the spec.

In order to detect a 1.0 client, which you don't want to support,
I think you need a _new_ check that is something like this:

// detect 1.0 client
if (capability->size < sizeof(*capability) &&
  capability->size >= offsetof(EFI_TCG2_BOOT_SERVICE_CAPABILITY,
NumberOfPcrBanks)) {
  efi_ret = EFI_UNSUPPORTED;
  goto out;
}


This does not conform to the TCG standard. You MUST return
EFI_BUFFER_TO_SMALL in this case.



The last field in the 1.0 struct was ManufacturerID, so you should
be able to detect 1.0 clients that expect that based on the size they
pass in.


No, you cannot detect 1.0 clients this way.



The patch doesn't show the entire u-boot code there and is a bit
misleading.
There's another check that precedes the one I am patching, which if I
am reading it correctly does exactly what you describe

#define BOOT_SERVICE_CAPABILITY_MIN \
   offsetof(struct efi_tcg2_boot_service_capability,
number_of_pcr_banks)
if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
   capability->size = BOOT_SERVICE_CAPABILITY_MIN;
   efi_ret = EFI_BUFFER_TOO_SMALL;
   goto out;
}


I took a look at the u-boot code.  What I think we want is this:

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index b1c3abd097..6a46d9e51c 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -126,7 +126,7 @@ struct efi_tcg2_boot_service_capability {
  };

  /* up to and including the vendor ID (manufacturer_id) field */
-#define BOOT_SERVICE_CAPABILITY_MIN \
+#define BOOT_SERVICE_CAPABILITY_1_0 \
     offsetof(struct efi_tcg2_boot_service_capability,
number_of_pcr_banks)

  #define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
diff --git 

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Ilias Apalodimas]

Hi Stuart,


[...]

> >> EFI_TCG2_EVENT_ALGORITHM_BITMAP ActivePcrBanks
> >> };
> >>
> >> The intent in the TCG spec is for the caller to be able to
> >> determine the size of the struct by passing in a small
> >> buffer (e.g. 1 byte buffer), and then the firmware
> >> should return sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) in the
> >> 1-byte "Size" field.  And the return value should be
> >> EFI_BUFFER_TOO_SMALL as per the spec.
> >>
> >> In order to detect a 1.0 client, which you don't want to support,
> >> I think you need a _new_ check that is something like this:
> >>
> >> // detect 1.0 client
> >> if (capability->size < sizeof(*capability) &&
> >>   capability->size >= offsetof(EFI_TCG2_BOOT_SERVICE_CAPABILITY,
> >> NumberOfPcrBanks)) {
> >>   efi_ret = EFI_UNSUPPORTED;
> >>   goto out;
> >> }
> >>
> >> The last field in the 1.0 struct was ManufacturerID, so you should
> >> be able to detect 1.0 clients that expect that based on the size they
> >> pass in.
> >
> > The patch doesn't show the entire u-boot code there and is a bit misleading.
> > There's another check that precedes the one I am patching, which if I
> > am reading it correctly does exactly what you describe
> >
> > #define BOOT_SERVICE_CAPABILITY_MIN \
> >offsetof(struct efi_tcg2_boot_service_capability, 
> > number_of_pcr_banks)
> > if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
> >capability->size = BOOT_SERVICE_CAPABILITY_MIN;
> >efi_ret = EFI_BUFFER_TOO_SMALL;
> >goto out;
> > }
>
> I took a look at the u-boot code.  What I think we want is this:
>
> diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> index b1c3abd097..6a46d9e51c 100644
> --- a/include/efi_tcg2.h
> +++ b/include/efi_tcg2.h
> @@ -126,7 +126,7 @@ struct efi_tcg2_boot_service_capability {
>   };
>
>   /* up to and including the vendor ID (manufacturer_id) field */
> -#define BOOT_SERVICE_CAPABILITY_MIN \
> +#define BOOT_SERVICE_CAPABILITY_1_0 \
>  offsetof(struct efi_tcg2_boot_service_capability,
> number_of_pcr_banks)
>
>   #define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index a83ae7a46c..d37b896b7e 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -742,15 +742,15 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol
> *this,
>  goto out;
>  }
>
> -   if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
> -   capability->size = BOOT_SERVICE_CAPABILITY_MIN;
> +   if (capability->size < BOOT_SERVICE_CAPABILITY_1_0) {
> +   capability->size = sizeof(*capability);
>  efi_ret = EFI_BUFFER_TOO_SMALL;
>  goto out;
>  }
>
>  if (capability->size < sizeof(*capability)) {
>  capability->size = sizeof(*capability);
> -   efi_ret = EFI_BUFFER_TOO_SMALL;
> +   efi_ret = EFI_UNSUPPORTED;
>  goto out;
>  }
>
> That is:
>
> -if the passed in size is less than the 1.0 struct size
>   then return sizeof() the full struct.  This allows
>   client to query and determine the supported struct
>   size
>
> -to detect and reject 1.0 clients, if the passed in
>   size is >= 1.0 struct size AND less than sizeof(*capability)
>   then return EFI_UNSUPPORTED
>
> Does that make sense?

It does but that violates the spec once again.
The spec says that the firmware should return
BOOT_SERVICE_CAPABILITY_MIN if the size is less than the size of the
EFI_TCG2_BOOT_SERVICE_CAPABILITY.
The current logic is similar, the only thing that differs on your
patch is the size of the struct we return.

Thanks
/Ilias

>
> Thanks,
> Stuart

Re: [v2] include: Remove unused header files

[Tom Rini]

On Tue, May 16, 2023 at 12:34:47PM -0400, Tom Rini wrote:

> As part of various code clean-ups we have on occasion missed removing
> unused header files.  None of these files are referenced anywhere else
> at this point.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 5/5] faraday: remove orphaned header file

[Tom Rini]

On Mon, May 15, 2023 at 02:52:14PM +0100, Andre Przywara wrote:

> Commit 11232139e399 ("nds32: Remove the architecture") removed the nds32
> architecture, and with it the last user of the Faraday AHB controller
> header file.
> 
> Consequently remove that header file as well.
> 
> This was found because the inclusion guard was misspelled.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 4/5] exynos: fix header inclusion guard

[Tom Rini]

On Mon, May 15, 2023 at 02:52:13PM +0100, Andre Przywara wrote:

> It seems like the header inclusion guard for the Exynos pinctrl header
> was misspelled.
> 
> Make the preprocessor symbol for the #ifndef and #define lines the
> same, so that the double inclusion protection works as expected.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/5] freescale: vsc3316_3308: fix header inclusion guard

[Tom Rini]

On Mon, May 15, 2023 at 02:52:12PM +0100, Andre Przywara wrote:

> It seems like the header inclusion guard for some Freescale crosspoint
> switch header was misspelled.
> 
> Make the preprocessor symbol for the #ifndef and #define lines the
> same, so that the double inclusion protection works as expected.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/5] arm: uniphier: fix header inclusion guard

[Tom Rini]

On Mon, May 15, 2023 at 02:52:11PM +0100, Andre Przywara wrote:

> It seems like the header inclusion guard for some Uniphier DDR PHY
> header was misspelled.
> 
> Make the preprocessor symbol for the #ifndef and #define lines the
> same, so that the double inclusion protection works as expected.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/5] imx: fix header inclusion guards

[Tom Rini]

On Mon, May 15, 2023 at 02:52:10PM +0100, Andre Przywara wrote:

> It seems like the header inclusion guards for some IMX related headers
> were misspelled or got out of sync.
> 
> Make the preprocessor symbols for the #ifndef and #define lines the
> same, so that the double inclusion protection works as expected.
> 
> Signed-off-by: Andre Przywara 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: Remove ti816x_evm board and ti816x SoC support

[Tom Rini]

On Thu, May 11, 2023 at 02:07:24PM -0400, Tom Rini wrote:

> This platform is currently unmaintained and untested, so remove it.
> Further, as it is the only TI816X SoC example, remove related files as
> well.
> 
> Signed-off-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Simon Glass]

Hi Heinrich,

On Wed, 31 May 2023 at 09:52, Tom Rini  wrote:
>
> On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:
> > Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:
> >
> > > On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:
> > >
> > > > qemu_arm64_defconfig with UNIT_TEST=y does not build.
> > > >
> > > > CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
> > > > must not enable unit tests invoking expo functions.
> > > >
> > > > Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all
> > > uclasses")
> > > > Signed-off-by: Heinrich Schuchardt 
> > > > ---
> > > >  test/boot/Makefile | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/test/boot/Makefile b/test/boot/Makefile
> > > > index 22ed61c8fa..665017ba3d 100644
> > > > --- a/test/boot/Makefile
> > > > +++ b/test/boot/Makefile
> > > > @@ -2,7 +2,10 @@
> > > >  #
> > > >  # Copyright 2021 Google LLC
> > > >
> > > > -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o
> > > bootmeth.o
> > > > +ifdef CONFIG_BOOTSTD
> > > > +obj-y += bootstd_common.o bootmeth.o
> > > > +obj-$(VIDEO) += bootdev.o bootflow.o
> > > > +endif
> > > >  obj-$(CONFIG_FIT) += image.o
> > > >
> > > >  obj-$(CONFIG_EXPO) += expo.o
> > >
> > > OK, but the functionality itself doesn't depend on video, it looks like
> > > maybe only the bootflow_menu_theme test itself, so lets try and solve
> > > this differently.
> > >
> > > --
> > > Tom
> > >
> >
> > Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .
>
> Well no, at first glance it's 1 out of 15 tests in that file that depend
> on CONFIG_EXPO, so we should just ifdef that test.

You could put something like this at the top of bootflow_cmd_menu():

/* 'bootflow menu' currently requires a video console */
if (!IS_ENABLED(CONFIG_VIDEO))
   return -EAGAIN;

Regards,
Simon

Re: Loading from squashfs with zstd compression slower than ext4

[Simon Glass]

Hi Jonathan,

On Wed, 31 May 2023 at 06:52, Jonathan Liu  wrote:
>
> Hi All,
>
> I noticed that loading from squashfs with zstd compression is
> significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
> filesystem is located on eMMC.
>
> I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load command.
>
> ext4:
> 15682578 bytes read in 366 ms (40.9 MiB/s)
>
> SquashFS with zstd compression:
> 15685001 bytes read in 2339 ms (6.4 MiB/s)
>
> Any suggestions on how to speed up loading from SquashFS with zstd 
> compression?

Could it just be that zstd is slow? Have you tried lz4?

Regards,
Simon

Re: R: Fit Signature booting without public key

[Simon Glass]

Hi,

On Wed, 31 May 2023 at 07:37, Tom Rini  wrote:
>
> On Wed, May 31, 2023 at 10:00:34AM +0530, Manorit Chawdhry wrote:
> > Hi,
> >
> > On 16:51-20230530, Pegorer Massimo wrote:
> > > Hi,
> > >
> > > > Inviato: venerdì 26 maggio 2023 15:00
> > > > Oggetto: Re: Fit Signature booting without public key
> > > >
> > > > On Fri, May 26, 2023 at 02:22:38PM +0530, Manorit Chawdhry wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On 10:05-20230525, Tom Rini wrote:
> > > > > > On Thu, May 25, 2023 at 11:21:44AM +0530, Manorit Chawdhry wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On 11:30-20230516, Tom Rini wrote:
> > > > > > > > On Tue, May 16, 2023 at 12:11:24PM +0530, Manorit Chawdhry 
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi All,
> > > > > > > > >
> > > > > > > > > I recently came upon a discussion that had happened a while 
> > > > > > > > > back
> > > > [0].
> > > > > > > > > I want to continue the discussion as I believe the issue still
> > > > > > > > > persists and the checks around fit signature booting are still
> > > > > > > > > the same, that allows booting the fit without changing the 
> > > > > > > > > uboot
> > > > dtb.
> > > > > > > > >
> > > > > > > > > Allowing the signed fit image without this seems to be a
> > > > > > > > > bypass that is available and should not be allowed without any
> > > > > > > > > gate to it for people who'd like to enforce these signing
> > > > > > > > > checks. Let me know if there is a config already available for
> > > > > > > > > it and if not, are there any plans to enable such a config in
> > > > > > > > > future. Would like to hear your opinions on this as I believe 
> > > > > > > > > this
> > > > should be fixed as soon as possible.
> > > > > > > > >
> > > > > > > > > [0]:
> > > > > > > > > https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boot
> > > > > > > > > s-without-public-key
> > > > > > > >
> > > > > > > > Yes, can you please reproduce the issue in question on the
> > > > > > > > current tree, with a supported platform and provide the
> > > > > > > > defconfig and steps you used for this issue? Thanks.
> > > > > > > >
> > > > > > > > --
> > > > > > >
> > > > > > > I've created a branch with some custom patches to make the
> > > > > > > fitimage booting currently, please try with the branch and the
> > > > > > > fitimage that are also committed [0].
> > > > > > >
> > > > > > > The devices that I've tested this with is j721e-hs-evm, the
> > > > > > > defconfig to use for the builds are j721e_evm_r5_defconfig and
> > > > > > > j721e_evm_a72_defconfig. Although not synced up with the latest
> > > > > > > changes but for reference the SDK documentation can help if 
> > > > > > > required
> > > > [1].
> > > > > > >
> > > > > > > Attached the logs for reference with the signed fitimage and an
> > > > > > > unsigned uboot without any modifications[2].
> > > > > > >
> > > > > > > [0]: https://github.com/manorit2001/u-boot/tree/fit-image-poc
> > > > > > > [1]:
> > > > > > > https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacint
> > > > > > > o7/08_06_00_11/exports/docs/linux/Foundational_Components/U-
> > > > Boot/U
> > > > > > > G-General-Info.html
> > > > > > > [2]:
> > > > > > > https://gist.github.com/manorit2001/3c49cfc19bf937783efb75fd4cddc5
> > > > > > > 8f
> > > > > >
> > > > > > I don't see the problem there, but please go and investigate what
> > > > > > problem you're seeing.  The intention is that yes, with the
> > > > > > appropriate CONFIG settings, you can set U-Boot to only boot signed
> > > > > > FIT configurations and unsigned ones should not boot.
> > > > > >
> > > > >
> > > > > It boots with an unsigned fit too btw for reference [0]. The whole
> > > > > logic behind the authentication is that uboot stores the public key
> > > > > that is used for verification of the signed fit but apparantely if I
> > > > > haven't kept the public key in uboot dtb the fit images still boot
> > > > > whether signed or unsigned as that check is not guarded by anything if
> > > > > you see in the codebase[1].
> > >
> > > Which uboot behaviour would you expect? If uboot is missing of the public 
> > > key, it has no way to check signatures. Therefore either it boots 
> > > everything (signed and unsigned) or it boots nothing (signed and 
> > > unsigned). The second means it would be totally useless. So the first 
> > > seems the only reasonable behaviour, IMO.
> > >
> >
> > I would actually expect it to through some errors telling about all this
> > instead of silently booting it, if the configurations of the dtb and the
> > signing ain't proper I don't believe there is any way to know about any
> > of this as it just boots up without any hint about it whatsoever, I
> > believe if this is enabled then there should atleast be an optional
> > config that allows people to get their environment right for validating
> > all this.
>
> Right.  With the correct set of options you should be able to enforce
> only booting 

Re: [PATCH v2] test: bdinfo: Add test for command bdinfo

[Simon Glass]

On Tue, 30 May 2023 at 19:04, Marek Vasut
 wrote:
>
> Add test for command bdinfo .
>
> Signed-off-by: Marek Vasut 
> ---
> Cc: Jason Liu 
> Cc: Michal Simek 
> Cc: Ovidiu Panait 
> Cc: Simon Glass 
> ---
> V2: Fix build failure on snow, just iterate over all DRAM banks and test
> them, no more macro hardcoding
> ---
>  include/test/suites.h |   1 +
>  test/cmd/Makefile |   1 +
>  test/cmd/bdinfo.c | 188 ++
>  test/cmd_ut.c |   6 ++
>  4 files changed, 196 insertions(+)
>  create mode 100644 test/cmd/bdinfo.c
>

Reviewed-by: Simon Glass 

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Heinrich Schuchardt]

Am 30. Mai 2023 23:20:53 MESZ schrieb Stuart Yoder :
>
>
>On 5/30/23 1:39 AM, Ilias Apalodimas wrote:
>> In the EFI TCG spec EFI_TCG2_BOOT_SERVICE_CAPABILITY struct is
>> versioned -- there are 1.0 and 1.1 versions of that struct.
>> The spec [0] describes:
>> "Version of the EFI_TCG2_BOOT_SERVICE_CAPABILITY
>> structure itself. For this version of the protocol, the Major version
>> SHALL be set to 1 and the Minor version SHALL be set to 1."
>> which is what we currently support.
>> 
>> The SCT tests perfromed By Arms SIE(Security interface extensions) [1]
>> perform a check for clients supporting the older 1.0 version of the
>> spec (Test 30.1.1.4). Given than this spec is 7 years old,  there should
>> be no need for the older 1.0 version support.  Instead of returning
>> EFI_BUFFER_TOO_SMALLL switch to EFI_UNSUPPORTED which is more
>> appropriate.  It's worth noting that the spec doesn't explicitly
>> describe the return value at the moment.
>> 
>> [0] 
>> https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
>> [1] 
>> https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md
>> 
>> Signed-off-by: Ilias Apalodimas 
>> ---
>> 
>> Heinrich,  Stuart is investigating the chance of the spec getting updated
>> adding EFI_UNSUPPORTED.  In any case I think the patch should be aplied since
>> the new return code makes more sense.  If for some reason the spec change is
>> rejected, I can go back and add support for 1.0 structure versions.
>> 
>>   lib/efi_loader/efi_tcg2.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
>> index a83ae7a46cf3..220c442bdf93 100644
>> --- a/lib/efi_loader/efi_tcg2.c
>> +++ b/lib/efi_loader/efi_tcg2.c
>> @@ -750,7 +750,7 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol *this,
>> 
>>  if (capability->size < sizeof(*capability)) {
>>  capability->size = sizeof(*capability);
>> -efi_ret = EFI_BUFFER_TOO_SMALL;
>> +efi_ret = EFI_UNSUPPORTED;
>>  goto out;
>>  }
>
>Hi Ilias,
>
>I don't think this is the right fix.
>
>The struct looks like this:
>
>struct tdEFI_TCG2_BOOT_SERVICE_CAPABILITY {
>  UINT8 Size;
>  EFI_TCG2_VERSION StructureVersion;
>  EFI_TCG2_VERSION ProtocolVersion;
>  EFI_TCG2_EVENT_ALGORITHM_BITMAP HashAlgorithmBitmap
>  EFI_TCG2_EVENT_LOG_BITMAP SupportedEventLogs
>  BOOLEAN TPMPresentFlag
>  UINT16 MaxCommandSize
>  UINT16 MaxResponseSize
>  UINT32 ManufacturerID
>  UINT32 NumberOfPcrBanks
>  EFI_TCG2_EVENT_ALGORITHM_BITMAP ActivePcrBanks
>};
>
>The intent in the TCG spec is for the caller to be able to
>determine the size of the struct by passing in a small
>buffer (e.g. 1 byte buffer), and then the firmware
>should return sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) in the
>1-byte "Size" field.  And the return value should be
>EFI_BUFFER_TOO_SMALL as per the spec.
>
>In order to detect a 1.0 client, which you don't want to support,
>I think you need a _new_ check that is something like this:
>
>// detect 1.0 client
>if (capability->size < sizeof(*capability) &&
>capability->size >= offsetof(EFI_TCG2_BOOT_SERVICE_CAPABILITY, 
> NumberOfPcrBanks)) {
>efi_ret = EFI_UNSUPPORTED;
>goto out;
>}
>
>The last field in the 1.0 struct was ManufacturerID, so you should
>be able to detect 1.0 clients that expect that based on the size they
>pass in.

Typically clients will pass in 0 to retrieve the size.

Best regards

Heinrich

>
>Thanks,
>Stuart

[PATCH 2/2] ARM: rmobile: Identify R-Car D3 R8A77995 r1.1 SoC

[Marek Vasut]

From: Hai Pham 

Add support to identify R8A77995 r1.1 SoC.

Reviewed-by: Marek Vasut 
Signed-off-by: Hai Pham 
[Marek: Slight update to commit message, spell out the SoC model]
---
 arch/arm/mach-rmobile/cpu_info-rcar.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-rmobile/cpu_info-rcar.c 
b/arch/arm/mach-rmobile/cpu_info-rcar.c
index 62017f52c3b..8fc4cd7f9de 100644
--- a/arch/arm/mach-rmobile/cpu_info-rcar.c
+++ b/arch/arm/mach-rmobile/cpu_info-rcar.c
@@ -11,6 +11,7 @@
 #define R8A7796_REV_1_00x5200
 #define R8A7796_REV_1_10x5210
 #define R8A7796_REV_1_30x5211
+#define R8A77995_REV_1_1   0x5810
 
 static u32 rmobile_get_prr(void)
 {
@@ -30,7 +31,8 @@ u32 rmobile_get_cpu_rev_integer(void)
const u32 prr = rmobile_get_prr();
const u32 rev = prr & PRR_MASK;
 
-   if (rev == R8A7796_REV_1_1 || rev == R8A7796_REV_1_3)
+   if (rev == R8A7796_REV_1_1 || rev == R8A7796_REV_1_3 ||
+   rev == R8A77995_REV_1_1)
return 1;
else
return ((prr & 0x00F0) >> 4) + 1;
@@ -41,7 +43,7 @@ u32 rmobile_get_cpu_rev_fraction(void)
const u32 prr = rmobile_get_prr();
const u32 rev = prr & PRR_MASK;
 
-   if (rev == R8A7796_REV_1_1)
+   if (rev == R8A7796_REV_1_1 || rev == R8A77995_REV_1_1)
return 1;
else if (rev == R8A7796_REV_1_3)
return 3;
-- 
2.39.2

[PATCH 1/2] ARM: rmobile: Identify R-Car M3-W R8A7796 r1.1/1.2 SoC

[Marek Vasut]

From: Hiroyuki Yokoyama 

r8a7796 cpu revision v1.2 has the same information as revision v1.1.
This patch fixes revision display at startup to "rev 1.1/1.2".

Reviewed-by: Marek Vasut 
Signed-off-by: Hiroyuki Yokoyama 
Signed-off-by: Hai Pham 
[Marek: Slight update to commit message, spell out the SoC model]
---
 arch/arm/mach-rmobile/cpu_info.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-rmobile/cpu_info.c b/arch/arm/mach-rmobile/cpu_info.c
index 71a856ea879..1d33e2aa9da 100644
--- a/arch/arm/mach-rmobile/cpu_info.c
+++ b/arch/arm/mach-rmobile/cpu_info.c
@@ -120,6 +120,13 @@ int print_cpuinfo(void)
 {
int i = rmobile_cpuinfo_idx();
 
+   if (rmobile_cpuinfo[i].cpu_type == RMOBILE_CPU_TYPE_R8A7796 &&
+   rmobile_get_cpu_rev_integer() == 1 &&
+   rmobile_get_cpu_rev_fraction() == 1) {
+   printf("CPU:   Renesas Electronics %s rev 1.1/1.2\n", 
get_cpu_name(i));
+   return 0;
+   }
+
printf("CPU:   Renesas Electronics %s rev %d.%d\n",
get_cpu_name(i), rmobile_get_cpu_rev_integer(),
rmobile_get_cpu_rev_fraction());
-- 
2.39.2

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Stuart Yoder]

On 5/31/23 2:48 AM, Ilias Apalodimas wrote:

Hi Stuart,

On Wed, 31 May 2023 at 00:20, Stuart Yoder  wrote:




On 5/30/23 1:39 AM, Ilias Apalodimas wrote:

In the EFI TCG spec EFI_TCG2_BOOT_SERVICE_CAPABILITY struct is
versioned -- there are 1.0 and 1.1 versions of that struct.
The spec [0] describes:
"Version of the EFI_TCG2_BOOT_SERVICE_CAPABILITY
structure itself. For this version of the protocol, the Major version
SHALL be set to 1 and the Minor version SHALL be set to 1."
which is what we currently support.

The SCT tests perfromed By Arms SIE(Security interface extensions) [1]
perform a check for clients supporting the older 1.0 version of the
spec (Test 30.1.1.4). Given than this spec is 7 years old,  there should
be no need for the older 1.0 version support.  Instead of returning
EFI_BUFFER_TOO_SMALLL switch to EFI_UNSUPPORTED which is more
appropriate.  It's worth noting that the spec doesn't explicitly
describe the return value at the moment.

[0] 
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
[1] 
https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md

Signed-off-by: Ilias Apalodimas 
---

Heinrich,  Stuart is investigating the chance of the spec getting updated
adding EFI_UNSUPPORTED.  In any case I think the patch should be aplied since
the new return code makes more sense.  If for some reason the spec change is
rejected, I can go back and add support for 1.0 structure versions.

   lib/efi_loader/efi_tcg2.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index a83ae7a46cf3..220c442bdf93 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -750,7 +750,7 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol *this,

   if (capability->size < sizeof(*capability)) {
   capability->size = sizeof(*capability);
- efi_ret = EFI_BUFFER_TOO_SMALL;
+ efi_ret = EFI_UNSUPPORTED;
   goto out;
   }


Hi Ilias,

I don't think this is the right fix.

The struct looks like this:

struct tdEFI_TCG2_BOOT_SERVICE_CAPABILITY {
UINT8 Size;
EFI_TCG2_VERSION StructureVersion;
EFI_TCG2_VERSION ProtocolVersion;
EFI_TCG2_EVENT_ALGORITHM_BITMAP HashAlgorithmBitmap
EFI_TCG2_EVENT_LOG_BITMAP SupportedEventLogs
BOOLEAN TPMPresentFlag
UINT16 MaxCommandSize
UINT16 MaxResponseSize
UINT32 ManufacturerID
UINT32 NumberOfPcrBanks
EFI_TCG2_EVENT_ALGORITHM_BITMAP ActivePcrBanks
};

The intent in the TCG spec is for the caller to be able to
determine the size of the struct by passing in a small
buffer (e.g. 1 byte buffer), and then the firmware
should return sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) in the
1-byte "Size" field.  And the return value should be
EFI_BUFFER_TOO_SMALL as per the spec.

In order to detect a 1.0 client, which you don't want to support,
I think you need a _new_ check that is something like this:

// detect 1.0 client
if (capability->size < sizeof(*capability) &&
  capability->size >= offsetof(EFI_TCG2_BOOT_SERVICE_CAPABILITY,
NumberOfPcrBanks)) {
  efi_ret = EFI_UNSUPPORTED;
  goto out;
}

The last field in the 1.0 struct was ManufacturerID, so you should
be able to detect 1.0 clients that expect that based on the size they
pass in.


The patch doesn't show the entire u-boot code there and is a bit misleading.
There's another check that precedes the one I am patching, which if I
am reading it correctly does exactly what you describe

#define BOOT_SERVICE_CAPABILITY_MIN \
   offsetof(struct efi_tcg2_boot_service_capability, 
number_of_pcr_banks)
if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
   capability->size = BOOT_SERVICE_CAPABILITY_MIN;
   efi_ret = EFI_BUFFER_TOO_SMALL;
   goto out;
}


I took a look at the u-boot code.  What I think we want is this:

diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index b1c3abd097..6a46d9e51c 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -126,7 +126,7 @@ struct efi_tcg2_boot_service_capability {
 };

 /* up to and including the vendor ID (manufacturer_id) field */
-#define BOOT_SERVICE_CAPABILITY_MIN \
+#define BOOT_SERVICE_CAPABILITY_1_0 \
offsetof(struct efi_tcg2_boot_service_capability, 
number_of_pcr_banks)


 #define TCG_EFI_SPEC_ID_EVENT_SIGNATURE_03 "Spec ID Event03"
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index a83ae7a46c..d37b896b7e 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -742,15 +742,15 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol 
*this,

goto out;
}

-   if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
-   capability->size = BOOT_SERVICE_CAPABILITY_MIN;
+   if (capability->size < BOOT_SERVICE_CAPABILITY_1_0) {
+   capability->size = sizeof(*capability);

[PATCH 5/8] net: fsl-mc: sync DPNI MC APIs

[Ioana Ciornei]

Sync the Data Path Network Interface APIs to their latest form, this
means the layout of each command is created based on structures which
clearly describe the endianness of each field rather than some macros.

The command version is kept in place, meaning that the minimum MC
version accepted is not changed in any way.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpni.c |  582 +++
 drivers/net/fsl-mc/mc.c   |   14 +-
 drivers/net/ldpaa_eth/ldpaa_eth.c |   22 +-
 include/fsl-mc/fsl_dpni.h | 1101 ++---
 4 files changed, 990 insertions(+), 729 deletions(-)

diff --git a/drivers/net/fsl-mc/dpni.c b/drivers/net/fsl-mc/dpni.c
index d0596a8e38d9..5b815a45a99d 100644
--- a/drivers/net/fsl-mc/dpni.c
+++ b/drivers/net/fsl-mc/dpni.c
@@ -1,36 +1,43 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2013-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017, 2023 NXP
  */
 
 #include 
 #include 
 #include 
 
-int dpni_prepare_cfg(const struct dpni_cfg *cfg,
-uint8_t*cfg_buf)
-{
-   uint64_t *params = (uint64_t *)cfg_buf;
-
-   DPNI_PREP_CFG(params, cfg);
-
-   return 0;
-}
-
-int dpni_open(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- int dpni_id,
- uint16_t *token)
+/**
+ * dpni_open() - Open a control session for the specified object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpni_id:   DPNI unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpni_create() function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpni_open(struct fsl_mc_io *mc_io, u32 cmd_flags, int dpni_id, u16 *token)
 {
+   struct dpni_cmd_open *cmd_params;
struct mc_command cmd = { 0 };
+
int err;
 
/* prepare command */
cmd.header = mc_encode_cmd_header(DPNI_CMDID_OPEN,
  cmd_flags,
  0);
-   DPNI_CMD_OPEN(cmd, dpni_id);
+   cmd_params = (struct dpni_cmd_open *)cmd.params;
+   cmd_params->dpni_id = cpu_to_le32(dpni_id);
 
/* send command to mc*/
err = mc_send_command(mc_io, );
@@ -38,14 +45,23 @@ int dpni_open(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   *token = MC_CMD_HDR_READ_TOKEN(cmd.header);
+   *token = mc_cmd_hdr_read_token();
 
return 0;
 }
 
-int dpni_close(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
+/**
+ * dpni_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPNI object
+ *
+ * After this function is called, no further operations are
+ * allowed on the object without opening a new control session.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpni_close(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token)
 {
struct mc_command cmd = { 0 };
 
@@ -58,12 +74,32 @@ int dpni_close(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dpni_create(struct fsl_mc_io *mc_io,
-   uint16_t dprc_token,
-   uint32_t cmd_flags,
-   const struct dpni_cfg *cfg,
-   uint32_t *obj_id)
+/**
+ * dpni_create() - Create the DPNI object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @dprc_token:Parent container token; '0' for default container
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @cfg:   Configuration structure
+ * @obj_id:Returned object id
+ *
+ * Create the DPNI object, allocate required resources and
+ * perform required initialization.
+ *
+ * The object can be created either by declaring it in the
+ * DPL file, or by calling this function.
+ *
+ * The function accepts an authentication token of a parent
+ * container that this object should be assigned to. The token
+ * can be '0' so the object will be assigned to the default container.
+ * The newly created object can be opened with the returned
+ * object id and using the container's associated tokens and MC portals.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpni_create(struct fsl_mc_io *mc_io, u16 dprc_token, u32 cmd_flags,
+   const struct dpni_cfg *cfg, u32 *obj_id)
 {
+   struct dpni_cmd_create *cmd_params;
struct mc_command cmd = { 0 };

[PATCH 8/8] net: fsl-mc: sync remaining MC commands

[Ioana Ciornei]

This patch targets the last remaining commands left to sync to their
latest form - mainly the mc_get_version() API.

Besides this, remove any macro which is now of no help.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpmng.c | 20 
 drivers/net/fsl-mc/fsl_dpmng_cmd.h | 17 +
 drivers/net/fsl-mc/mc_sys.c| 13 +
 include/fsl-mc/fsl_dpmng.h | 13 +
 include/fsl-mc/fsl_mc_cmd.h| 23 ---
 5 files changed, 35 insertions(+), 51 deletions(-)

diff --git a/drivers/net/fsl-mc/dpmng.c b/drivers/net/fsl-mc/dpmng.c
index 8314243f3561..147ca6da9e1f 100644
--- a/drivers/net/fsl-mc/dpmng.c
+++ b/drivers/net/fsl-mc/dpmng.c
@@ -1,15 +1,24 @@
 // SPDX-License-Identifier: GPL-2.0+
 /* Copyright 2013-2015 Freescale Semiconductor Inc.
+ * Copyright 2023 NXP
  */
 #include 
 #include 
 #include 
 #include "fsl_dpmng_cmd.h"
 
-int mc_get_version(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  struct mc_version *mc_ver_info)
+/**
+ * mc_get_version() - Retrieves the Management Complex firmware
+ * version information
+ * @mc_io: Pointer to opaque I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @mc_ver_info:   Returned version information structure
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int mc_get_version(struct fsl_mc_io *mc_io, uint32_t cmd_flags, struct 
mc_version *mc_ver_info)
 {
+   struct dpmng_rsp_get_version *rsp_params;
struct mc_command cmd = { 0 };
int err;
 
@@ -24,7 +33,10 @@ int mc_get_version(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   DPMNG_RSP_GET_VERSION(cmd, mc_ver_info);
+   rsp_params = (struct dpmng_rsp_get_version *)cmd.params;
+   mc_ver_info->revision = le32_to_cpu(rsp_params->revision);
+   mc_ver_info->major = le32_to_cpu(rsp_params->version_major);
+   mc_ver_info->minor = le32_to_cpu(rsp_params->version_minor);
 
return 0;
 }
diff --git a/drivers/net/fsl-mc/fsl_dpmng_cmd.h 
b/drivers/net/fsl-mc/fsl_dpmng_cmd.h
index e18c88da0972..e6efceab7acc 100644
--- a/drivers/net/fsl-mc/fsl_dpmng_cmd.h
+++ b/drivers/net/fsl-mc/fsl_dpmng_cmd.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0+ */
 /* Copyright 2013-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017, 2023 NXP
  */
 #ifndef __FSL_DPMNG_CMD_H
 #define __FSL_DPMNG_CMD_H
@@ -8,12 +8,13 @@
 /* Command IDs */
 #define DPMNG_CMDID_GET_VERSION0x8311
 
-/*cmd, param, offset, width, type, arg_name */
-#define DPMNG_RSP_GET_VERSION(cmd, mc_ver_info) \
-do { \
-   MC_RSP_OP(cmd, 0, 0,  32, uint32_t, mc_ver_info->revision); \
-   MC_RSP_OP(cmd, 0, 32, 32, uint32_t, mc_ver_info->major); \
-   MC_RSP_OP(cmd, 1, 0,  32, uint32_t, mc_ver_info->minor); \
-} while (0)
+#pragma pack(push, 1)
+struct dpmng_rsp_get_version {
+   __le32 revision;
+   __le32 version_major;
+   __le32 version_minor;
+};
+
+#pragma pack(pop)
 
 #endif /* __FSL_DPMNG_CMD_H */
diff --git a/drivers/net/fsl-mc/mc_sys.c b/drivers/net/fsl-mc/mc_sys.c
index b5ae2ea3eb56..4d32516b0055 100644
--- a/drivers/net/fsl-mc/mc_sys.c
+++ b/drivers/net/fsl-mc/mc_sys.c
@@ -13,8 +13,13 @@
 #include 
 #include 
 
-#define MC_CMD_HDR_READ_CMDID(_hdr) \
-   ((uint16_t)mc_dec((_hdr), MC_CMD_HDR_CMDID_O, MC_CMD_HDR_CMDID_S))
+static u16 mc_cmd_hdr_read_cmdid(struct mc_command *cmd)
+{
+   struct mc_cmd_header *hdr = (struct mc_cmd_header *)>header;
+   u16 cmd_id = le16_to_cpu(hdr->cmd_id);
+
+   return cmd_id;
+}
 
 /**
  * mc_send_command - Send MC command and wait for response
@@ -52,8 +57,8 @@ int mc_send_command(struct fsl_mc_io *mc_io,
if (status != MC_CMD_STATUS_OK) {
printf("Error: MC command failed (portal: %p, obj handle: %#x, 
command: %#x, status: %#x)\n",
   mc_io->mmio_regs,
-   (unsigned int)MC_CMD_HDR_READ_TOKEN(cmd->header),
-  (unsigned int)MC_CMD_HDR_READ_CMDID(cmd->header),
+   (unsigned int)mc_cmd_hdr_read_token(cmd),
+  (unsigned int)mc_cmd_hdr_read_cmdid(cmd),
   (unsigned int)status);
 
return -EIO;
diff --git a/include/fsl-mc/fsl_dpmng.h b/include/fsl-mc/fsl_dpmng.h
index 2148601e8a12..5dfc9ecc4281 100644
--- a/include/fsl-mc/fsl_dpmng.h
+++ b/include/fsl-mc/fsl_dpmng.h
@@ -30,17 +30,6 @@ struct mc_version {
uint32_t revision;
 };
 
-/**
- * mc_get_version() - Retrieves the Management Complex firmware
- * version information
- * @mc_io: Pointer to opaque I/O object
- * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
- * @mc_ver_info:   Returned version information structure
- *
- * Return: '0' on Success; Error code 

[PATCH 7/8] net: fsl-mc: sync DPIO MC APIs

[Ioana Ciornei]

Sync the Data Path IO APIs to their latest form, this means the layout
of each command is created based on structures which clearly describe
the endianness of each field rather than some macros.

The command version is kept in place, meaning that the minimum MC
version accepted is not changed in any way.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpio/dpio.c | 179 +--
 include/fsl-mc/fsl_dpio.h  | 251 +++--
 2 files changed, 220 insertions(+), 210 deletions(-)

diff --git a/drivers/net/fsl-mc/dpio/dpio.c b/drivers/net/fsl-mc/dpio/dpio.c
index 30ecc9124b27..d17210bf451a 100644
--- a/drivers/net/fsl-mc/dpio/dpio.c
+++ b/drivers/net/fsl-mc/dpio/dpio.c
@@ -1,18 +1,34 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
  * Copyright 2013-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017, 2023 NXP
  */
 
 #include 
 #include 
 #include 
 
-int dpio_open(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- uint32_t dpio_id,
- uint16_t *token)
+/**
+ * dpio_open() - Open a control session for the specified object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpio_id:   DPIO unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpio_create() function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and any MC portals
+ * assigned to the parent container; this token must be used in
+ * all subsequent commands for this specific object.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpio_open(struct fsl_mc_io *mc_io, u32 cmd_flags, int dpio_id,
+ u16 *token)
 {
+   struct dpio_cmd_open *cmd_params;
struct mc_command cmd = { 0 };
int err;
 
@@ -20,7 +36,8 @@ int dpio_open(struct fsl_mc_io *mc_io,
cmd.header = mc_encode_cmd_header(DPIO_CMDID_OPEN,
  cmd_flags,
  0);
-   DPIO_CMD_OPEN(cmd, dpio_id);
+   cmd_params = (struct dpio_cmd_open *)cmd.params;
+   cmd_params->dpio_id = cpu_to_le32(dpio_id);
 
/* send command to mc*/
err = mc_send_command(mc_io, );
@@ -28,14 +45,20 @@ int dpio_open(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   *token = MC_CMD_HDR_READ_TOKEN(cmd.header);
+   *token = mc_cmd_hdr_read_token();
 
return 0;
 }
 
-int dpio_close(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
+/**
+ * dpio_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPIO object
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpio_close(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token)
 {
struct mc_command cmd = { 0 };
 
@@ -48,12 +71,32 @@ int dpio_close(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dpio_create(struct fsl_mc_io *mc_io,
-   uint16_t dprc_token,
-   uint32_t cmd_flags,
-   const struct dpio_cfg *cfg,
-   uint32_t *obj_id)
+/**
+ * dpio_create() - Create the DPIO object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @dprc_token:Parent container token; '0' for default container
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @cfg:   Configuration structure
+ * @obj_id:Returned object id
+ *
+ * Create the DPIO object, allocate required resources and
+ * perform required initialization.
+ *
+ * The object can be created either by declaring it in the
+ * DPL file, or by calling this function.
+ *
+ * The function accepts an authentication token of a parent
+ * container that this object should be assigned to. The token
+ * can be '0' so the object will be assigned to the default container.
+ * The newly created object can be opened with the returned
+ * object id and using the container's associated tokens and MC portals.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpio_create(struct fsl_mc_io *mc_io, u16 dprc_token, u32 cmd_flags,
+   const struct dpio_cfg *cfg, u32 *obj_id)
 {
+   struct dpio_cmd_create *cmd_params;
struct mc_command cmd = { 0 };
int err;
 
@@ -61,7 +104,11 @@ int dpio_create(struct fsl_mc_io *mc_io,
cmd.header = mc_encode_cmd_header(DPIO_CMDID_CREATE,
  cmd_flags,
  dprc_token);
-   DPIO_CMD_CREATE(cmd, cfg);
+   cmd_params = (struct dpio_cmd_create *)cmd.params;
+   

[PATCH 6/8] net: fsl-mc: sync DPSPARSER MC APIs

[Ioana Ciornei]

Sync the Data Path Soft Parser APIs to their latest form, this
means the layout of each command is created based on structures which
clearly describe the endianness of each field rather than some macros.

The command version is kept in place, meaning that the minimum MC
version accepted is not changed in any way.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpsparser.c | 124 ++---
 include/fsl-mc/fsl_dpsparser.h | 139 -
 2 files changed, 126 insertions(+), 137 deletions(-)

diff --git a/drivers/net/fsl-mc/dpsparser.c b/drivers/net/fsl-mc/dpsparser.c
index cfd1ba66a058..09dfb8f1fc02 100644
--- a/drivers/net/fsl-mc/dpsparser.c
+++ b/drivers/net/fsl-mc/dpsparser.c
@@ -2,15 +2,29 @@
 /*
  * Data Path Soft Parser
  *
- * Copyright 2018 NXP
+ * Copyright 2018, 2023 NXP
  */
 #include 
 #include 
 #include 
 
-int dpsparser_open(struct fsl_mc_io *mc_io,
-  u32 cmd_flags,
-  u16 *token)
+/**
+ * dpsparser_open() - Open a control session for the specified object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpsparser_create function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpsparser_open(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 *token)
 {
struct mc_command cmd = { 0 };
int err;
@@ -26,14 +40,23 @@ int dpsparser_open(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   *token = MC_CMD_HDR_READ_TOKEN(cmd.header);
+   *token = mc_cmd_hdr_read_token();
 
return err;
 }
 
-int dpsparser_close(struct fsl_mc_io *mc_io,
-   u32 cmd_flags,
-   u16 token)
+/**
+ * dpsparser_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSPARSER object
+ *
+ * After this function is called, no further operations are
+ * allowed on the object without opening a new control session.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpsparser_close(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token)
 {
struct mc_command cmd = { 0 };
 
@@ -45,9 +68,27 @@ int dpsparser_close(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dpsparser_create(struct fsl_mc_io *mc_io,
-u16 token,
-u32 cmd_flags,
+/**
+ * dpsparser_create() - Create the DPSPARSER object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Returned token; use in subsequent API calls
+ *
+ * Create the DPSPARSER object, allocate required resources and
+ * perform required initialization.
+ *
+ * The object can be created either by declaring it in the
+ * DPL file, or by calling this function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent calls to
+ * this specific object. For objects that are created using the
+ * DPL file, call dpsparser_open function to get an authentication
+ * token first.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpsparser_create(struct fsl_mc_io *mc_io, u16 token, u32 cmd_flags,
 u32 *obj_id)
 {
struct mc_command cmd = { 0 };
@@ -64,36 +105,51 @@ int dpsparser_create(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   MC_CMD_READ_OBJ_ID(cmd, *obj_id);
+   *obj_id = mc_cmd_read_object_id();
 
return 0;
 }
 
-int dpsparser_destroy(struct fsl_mc_io *mc_io,
- u16 token,
- u32 cmd_flags,
+/**
+ * dpsparser_destroy() - Destroy the DPSPARSER object and release all its 
resources.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPSPARSER object
+ *
+ * Return: '0' on Success; error code otherwise.
+ */
+int dpsparser_destroy(struct fsl_mc_io *mc_io, u16 token, u32 cmd_flags,
  u32 obj_id)
 {
+   struct dpsparser_cmd_destroy *cmd_params;
struct mc_command cmd = { 0 };
 
/* prepare command */
cmd.header = mc_encode_cmd_header(DPSPARSER_CMDID_DESTROY,
  cmd_flags,
 

[PATCH 3/8] net: fsl-mc: sync DPMAC MC APIs

[Ioana Ciornei]

Sync the Data Path MAC APIs to their latest form, this means the
layout of each command is created based on structures which clearly
describe the endianness of each field rather than some macros.

The command version is kept in place, meaning that the minimum MC
version accepted is not changed in any way.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpmac.c | 185 
 include/fsl-mc/fsl_dpmac.h | 240 +
 2 files changed, 215 insertions(+), 210 deletions(-)

diff --git a/drivers/net/fsl-mc/dpmac.c b/drivers/net/fsl-mc/dpmac.c
index f6def987c10b..5d4f6c67fd0b 100644
--- a/drivers/net/fsl-mc/dpmac.c
+++ b/drivers/net/fsl-mc/dpmac.c
@@ -11,19 +11,33 @@
 #include 
 #include 
 
-int dpmac_open(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  int dpmac_id,
-  uint16_t *token)
+/**
+ * dpmac_open() - Open a control session for the specified object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpmac_id:  DPMAC unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpmac_create function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpmac_open(struct fsl_mc_io *mc_io, u32 cmd_flags, int dpmac_id, u16 
*token)
 {
+   struct dpmac_cmd_open *cmd_params;
struct mc_command cmd = { 0 };
int err;
 
/* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_OPEN,
- cmd_flags,
- 0);
-   DPMAC_CMD_OPEN(cmd, dpmac_id);
+   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_OPEN, cmd_flags, 0);
+   cmd_params = (struct dpmac_cmd_open *)cmd.params;
+   cmd_params->dpmac_id = cpu_to_le32(dpmac_id);
 
/* send command to mc*/
err = mc_send_command(mc_io, );
@@ -31,39 +45,63 @@ int dpmac_open(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   *token = MC_CMD_HDR_READ_TOKEN(cmd.header);
+   *token = mc_cmd_hdr_read_token();
 
return err;
 }
 
-int dpmac_close(struct fsl_mc_io *mc_io,
-   uint32_t cmd_flags,
-   uint16_t token)
+/**
+ * dpmac_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPMAC object
+ *
+ * After this function is called, no further operations are
+ * allowed on the object without opening a new control session.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpmac_close(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token)
 {
struct mc_command cmd = { 0 };
 
/* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_CLOSE, cmd_flags,
- token);
+   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_CLOSE, cmd_flags, token);
 
/* send command to mc*/
return mc_send_command(mc_io, );
 }
 
-int dpmac_create(struct fsl_mc_io *mc_io,
-uint16_t dprc_token,
-uint32_t cmd_flags,
-const struct dpmac_cfg *cfg,
-uint32_t *obj_id)
+/**
+ * dpmac_create() - Create the DPMAC object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @dprc_token: Parent container token; '0' for default container
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @cfg:   Configuration structure
+ * @obj_id:Returned object id
+ *
+ * Create the DPMAC object, allocate required resources and
+ * perform required initialization.
+ *
+ * The function accepts an authentication token of a parent
+ * container that this object should be assigned to. The token
+ * can be '0' so the object will be assigned to the default container.
+ * The newly created object can be opened with the returned
+ * object id and using the container's associated tokens and MC portals.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpmac_create(struct fsl_mc_io *mc_io, u16 dprc_token, u32 cmd_flags,
+const struct dpmac_cfg *cfg, u32 *obj_id)
 {
+   struct dpmac_cmd_create *cmd_params;
struct mc_command cmd = { 0 };
int err;
 
/* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_CREATE,
- cmd_flags,
- dprc_token);
-   DPMAC_CMD_CREATE(cmd, cfg);
+   cmd.header = 

[PATCH 4/8] net: fsl-mc: sync DPRC MC APIs

[Ioana Ciornei]

Sync the Data Resource Container APIs to their latest form, this means
the layout of each command is created based on structures which clearly
describe the endianness of each field rather than some macros.

The command version is kept in place, meaning that the minimum MC
version accepted is not changed in any way.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dprc.c | 232 -
 include/fsl-mc/fsl_dprc.h | 424 +-
 2 files changed, 280 insertions(+), 376 deletions(-)

diff --git a/drivers/net/fsl-mc/dprc.c b/drivers/net/fsl-mc/dprc.c
index 2be56e24a186..d1a74ab47a98 100644
--- a/drivers/net/fsl-mc/dprc.c
+++ b/drivers/net/fsl-mc/dprc.c
@@ -3,16 +3,22 @@
  * Freescale Layerscape MC I/O wrapper
  *
  * Copyright 2013-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017, 2023 NXP
  */
 
 #include 
 #include 
 #include 
 
-int dprc_get_container_id(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- int *container_id)
+/**
+ * dprc_get_container_id - Get container ID associated with a given portal.
+ * @mc_io: Pointer to Mc portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @container_id:  Requested container id
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dprc_get_container_id(struct fsl_mc_io *mc_io, u32 cmd_flags, int 
*container_id)
 {
struct mc_command cmd = { 0 };
int err;
@@ -28,23 +34,33 @@ int dprc_get_container_id(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   DPRC_RSP_GET_CONTAINER_ID(cmd, *container_id);
+   *container_id = (int)mc_cmd_read_object_id();
 
return 0;
 }
 
-int dprc_open(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- int container_id,
- uint16_t *token)
+/**
+ * dprc_open() - Open DPRC object for use
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @container_id:  Container ID to open
+ * @token: Returned token of DPRC object
+ *
+ * Return: '0' on Success; Error code otherwise.
+ *
+ * @warningRequired before any operation on the object.
+ */
+int dprc_open(struct fsl_mc_io *mc_io, u32 cmd_flags, int container_id, u16 
*token)
 {
+   struct dprc_cmd_open *cmd_params;
struct mc_command cmd = { 0 };
int err;
 
/* prepare command */
cmd.header = mc_encode_cmd_header(DPRC_CMDID_OPEN, cmd_flags,
  0);
-   DPRC_CMD_OPEN(cmd, container_id);
+   cmd_params = (struct dprc_cmd_open *)cmd.params;
+   cmd_params->container_id = cpu_to_le32(container_id);
 
/* send command to mc*/
err = mc_send_command(mc_io, );
@@ -52,14 +68,23 @@ int dprc_open(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   *token = MC_CMD_HDR_READ_TOKEN(cmd.header);
+   *token = mc_cmd_hdr_read_token();
 
return 0;
 }
 
-int dprc_close(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
+/**
+ * dprc_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPRC object
+ *
+ * After this function is called, no further operations are
+ * allowed on the object without opening a new control session.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dprc_close(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token)
 {
struct mc_command cmd = { 0 };
 
@@ -71,22 +96,35 @@ int dprc_close(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dprc_create_container(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- uint16_t token,
- struct dprc_cfg *cfg,
- int *child_container_id,
- uint64_t *child_portal_paddr)
+/**
+ * dprc_create_container() - Create child container
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPRC object
+ * @cfg:   Child container configuration
+ * @child_container_id:Returned child container ID
+ * @child_portal_offset:Returned child portal offset from MC portal base
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dprc_create_container(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token,
+ struct dprc_cfg *cfg, int *child_container_id,
+ uint64_t *child_portal_offset)
 {
+   struct dprc_cmd_create_container *cmd_params;
+   struct dprc_rsp_create_container *rsp_params;

[PATCH 1/8] net: fsl-mc: remove unused MC APIs

[Ioana Ciornei]

There are multiple MC APIs which were added years ago but they are not
used at all in the u-boot source code. Remove all these APIs.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpio/dpio.c |  15 -
 drivers/net/fsl-mc/dpmac.c |  89 --
 drivers/net/fsl-mc/dpni.c  | 100 ---
 drivers/net/fsl-mc/dprc.c  | 173 ---
 include/fsl-mc/fsl_dpbp.h  |  14 -
 include/fsl-mc/fsl_dpio.h  |  13 -
 include/fsl-mc/fsl_dpmac.h | 120 
 include/fsl-mc/fsl_dpni.h  | 434 
 include/fsl-mc/fsl_dprc.h  | 513 -
 9 files changed, 1471 deletions(-)

diff --git a/drivers/net/fsl-mc/dpio/dpio.c b/drivers/net/fsl-mc/dpio/dpio.c
index 8884455963de..30ecc9124b27 100644
--- a/drivers/net/fsl-mc/dpio/dpio.c
+++ b/drivers/net/fsl-mc/dpio/dpio.c
@@ -123,21 +123,6 @@ int dpio_disable(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dpio_reset(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
-{
-   struct mc_command cmd = { 0 };
-
-   /* prepare command */
-   cmd.header = mc_encode_cmd_header(DPIO_CMDID_RESET,
- cmd_flags,
- token);
-
-   /* send command to mc*/
-   return mc_send_command(mc_io, );
-}
-
 int dpio_get_attributes(struct fsl_mc_io *mc_io,
uint32_t cmd_flags,
uint16_t token,
diff --git a/drivers/net/fsl-mc/dpmac.c b/drivers/net/fsl-mc/dpmac.c
index 43a2ff43f888..f6def987c10b 100644
--- a/drivers/net/fsl-mc/dpmac.c
+++ b/drivers/net/fsl-mc/dpmac.c
@@ -95,95 +95,6 @@ int dpmac_destroy(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dpmac_get_attributes(struct fsl_mc_io *mc_io,
-uint32_t cmd_flags,
-uint16_t token,
-struct dpmac_attr *attr)
-{
-   struct mc_command cmd = { 0 };
-   int err;
-
-   /* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_GET_ATTR,
- cmd_flags,
- token);
-
-   /* send command to mc*/
-   err = mc_send_command(mc_io, );
-   if (err)
-   return err;
-
-   /* retrieve response parameters */
-   DPMAC_RSP_GET_ATTRIBUTES(cmd, attr);
-
-   return 0;
-}
-
-int dpmac_mdio_read(struct fsl_mc_io *mc_io,
-   uint32_t cmd_flags,
-   uint16_t token,
-   struct dpmac_mdio_cfg *cfg)
-{
-   struct mc_command cmd = { 0 };
-   int err;
-
-   /* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_MDIO_READ,
- cmd_flags,
- token);
-   DPMAC_CMD_MDIO_READ(cmd, cfg);
-
-   /* send command to mc*/
-   err = mc_send_command(mc_io, );
-   if (err)
-   return err;
-
-   /* retrieve response parameters */
-   DPMAC_RSP_MDIO_READ(cmd, cfg->data);
-
-   return 0;
-}
-
-int dpmac_mdio_write(struct fsl_mc_io *mc_io,
-uint32_t cmd_flags,
-uint16_t token,
-struct dpmac_mdio_cfg *cfg)
-{
-   struct mc_command cmd = { 0 };
-
-   /* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_MDIO_WRITE,
- cmd_flags,
- token);
-   DPMAC_CMD_MDIO_WRITE(cmd, cfg);
-
-   /* send command to mc*/
-   return mc_send_command(mc_io, );
-}
-
-int dpmac_get_link_cfg(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token,
-  struct dpmac_link_cfg *cfg)
-{
-   struct mc_command cmd = { 0 };
-   int err = 0;
-
-   /* prepare command */
-   cmd.header = mc_encode_cmd_header(DPMAC_CMDID_GET_LINK_CFG,
- cmd_flags,
- token);
-
-   /* send command to mc*/
-   err = mc_send_command(mc_io, );
-   if (err)
-   return err;
-
-   DPMAC_RSP_GET_LINK_CFG(cmd, cfg);
-
-   return 0;
-}
-
 int dpmac_set_link_state(struct fsl_mc_io *mc_io,
 uint32_t cmd_flags,
 uint16_t token,
diff --git a/drivers/net/fsl-mc/dpni.c b/drivers/net/fsl-mc/dpni.c
index a31abbff71b9..d0596a8e38d9 100644
--- a/drivers/net/fsl-mc/dpni.c
+++ b/drivers/net/fsl-mc/dpni.c
@@ -18,16 +18,6 @@ int dpni_prepare_cfg(const struct dpni_cfg   *cfg,
return 0;
 }
 
-int dpni_extract_cfg(struct dpni_cfg   *cfg,
-const uint8_t  *cfg_buf)
-{
-   uint64_t *params = (uint64_t *)cfg_buf;
-
-   DPNI_EXT_CFG(params, cfg);
-
-   return 0;
-}
-
 int dpni_open(struct fsl_mc_io *mc_io,
  

[PATCH 2/8] net: fsl-mc: sync DPBP MC APIs

[Ioana Ciornei]

Sync the Data Path Buffer Pool APIs to their latest form, this means the
layout of each command is created based on structures which clearly
describe the endianness of each field rather than some macros.

The command version is kept in place, meaning that the minimum MC
version accepted is not changed in any way.

Signed-off-by: Ioana Ciornei 
---
 drivers/net/fsl-mc/dpbp.c   | 180 +++--
 include/fsl-mc/fsl_dpbp.h   | 193 +++-
 include/fsl-mc/fsl_mc_cmd.h |  24 +
 3 files changed, 188 insertions(+), 209 deletions(-)

diff --git a/drivers/net/fsl-mc/dpbp.c b/drivers/net/fsl-mc/dpbp.c
index c609efb9abcc..5e17ccf73d38 100644
--- a/drivers/net/fsl-mc/dpbp.c
+++ b/drivers/net/fsl-mc/dpbp.c
@@ -3,25 +3,40 @@
  * Freescale Layerscape MC I/O wrapper
  *
  * Copyright 2013-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017-2023 NXP
  */
 #include 
 #include 
 #include 
 
-int dpbp_open(struct fsl_mc_io *mc_io,
- uint32_t cmd_flags,
- int dpbp_id,
- uint16_t *token)
+/**
+ * dpbp_open() - Open a control session for the specified object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpbp_id:   DPBP unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpbp_create function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpbp_open(struct fsl_mc_io *mc_io, u32 cmd_flags, int dpbp_id, u16 *token)
 {
+   struct dpbp_cmd_open *cmd_params;
struct mc_command cmd = { 0 };
int err;
 
/* prepare command */
cmd.header = mc_encode_cmd_header(DPBP_CMDID_OPEN,
- cmd_flags,
- 0);
-   DPBP_CMD_OPEN(cmd, dpbp_id);
+ cmd_flags, 0);
+   cmd_params = (struct dpbp_cmd_open *)cmd.params;
+   cmd_params->dpbp_id = cpu_to_le32(dpbp_id);
 
/* send command to mc*/
err = mc_send_command(mc_io, );
@@ -29,14 +44,23 @@ int dpbp_open(struct fsl_mc_io *mc_io,
return err;
 
/* retrieve response parameters */
-   *token = MC_CMD_HDR_READ_TOKEN(cmd.header);
+   *token = mc_cmd_hdr_read_token();
 
return err;
 }
 
-int dpbp_close(struct fsl_mc_io *mc_io,
-  uint32_t cmd_flags,
-  uint16_t token)
+/**
+ * dpbp_close() - Close the control session of the object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @token: Token of DPBP object
+ *
+ * After this function is called, no further operations are
+ * allowed on the object without opening a new control session.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpbp_close(struct fsl_mc_io *mc_io, u32 cmd_flags, u16 token)
 {
struct mc_command cmd = { 0 };
 
@@ -48,11 +72,26 @@ int dpbp_close(struct fsl_mc_io *mc_io,
return mc_send_command(mc_io, );
 }
 
-int dpbp_create(struct fsl_mc_io *mc_io,
-   uint16_t dprc_token,
-   uint32_t cmd_flags,
-   const struct dpbp_cfg *cfg,
-   uint32_t *obj_id)
+/**
+ * dpbp_create() - Create the DPBP object.
+ * @mc_io: Pointer to MC portal's I/O object
+ * @dprc_token:Parent container token; '0' for default container
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @cfg:   Configuration structure
+ * @obj_id:Returned object id; use in subsequent API calls
+ *
+ * Create the DPBP object, allocate required resources and
+ * perform required initialization.
+ *
+ * This function accepts an authentication token of a parent
+ * container that this object should be assigned to and returns
+ * an object id. This object_id will be used in all subsequent calls to
+ * this specific object.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpbp_create(struct fsl_mc_io *mc_io, u16 dprc_token, u32 cmd_flags,
+   const struct dpbp_cfg *cfg, u32 *obj_id)
 {
struct mc_command cmd = { 0 };
int err;
@@ -61,8 +100,7 @@ int dpbp_create(struct fsl_mc_io *mc_io,
 
/* prepare command */
cmd.header = mc_encode_cmd_header(DPBP_CMDID_CREATE,
- cmd_flags,
- dprc_token);
+ cmd_flags, dprc_token);
 
/* send command to mc*/
err = mc_send_command(mc_io, );
@@ -70,33 +108,46 @@ int 

[PATCH 0/8] net: fsl-mc: sync to latest MC APIs

[Ioana Ciornei]

This patch set syncs all the MC APIs to their latest form using packed
structures to ilustrate each field and its endianness.
No change in the minimum MC version or the command's version is made.

The first patch removes any unused API so that we do not carry around
useless code.

Ioana Ciornei (8):
  net: fsl-mc: remove unused MC APIs
  net: fsl-mc: sync DPBP MC APIs
  net: fsl-mc: sync DPMAC MC APIs
  net: fsl-mc: sync DPRC MC APIs
  net: fsl-mc: sync DPNI MC APIs
  net: fsl-mc: sync DPSPARSER MC APIs
  net: fsl-mc: sync DPIO MC APIs
  net: fsl-mc: sync remaining MC commands

 drivers/net/fsl-mc/dpbp.c  |  180 +++-
 drivers/net/fsl-mc/dpio/dpio.c |  194 ++--
 drivers/net/fsl-mc/dpmac.c |  274 +++--
 drivers/net/fsl-mc/dpmng.c |   20 +-
 drivers/net/fsl-mc/dpni.c  |  680 +
 drivers/net/fsl-mc/dprc.c  |  405 
 drivers/net/fsl-mc/dpsparser.c |  124 ++-
 drivers/net/fsl-mc/fsl_dpmng_cmd.h |   17 +-
 drivers/net/fsl-mc/mc.c|   14 +-
 drivers/net/fsl-mc/mc_sys.c|   13 +-
 drivers/net/ldpaa_eth/ldpaa_eth.c  |   22 +-
 include/fsl-mc/fsl_dpbp.h  |  207 +---
 include/fsl-mc/fsl_dpio.h  |  266 ++---
 include/fsl-mc/fsl_dpmac.h |  360 ++-
 include/fsl-mc/fsl_dpmng.h |   13 +-
 include/fsl-mc/fsl_dpni.h  | 1529 ++--
 include/fsl-mc/fsl_dprc.h  |  935 ++---
 include/fsl-mc/fsl_dpsparser.h |  139 +--
 include/fsl-mc/fsl_mc_cmd.h|   47 +-
 19 files changed, 2050 insertions(+), 3389 deletions(-)

-- 
2.25.1

Re: [PATCH 1/2] clk: imx8mp: Update clocks based on kernel 6.4-RC4

[Tim Harvey]

On Wed, May 31, 2023 at 8:50 AM Adam Ford  wrote:
>
> On Wed, May 31, 2023 at 10:44 AM Tim Harvey  wrote:
> >
> > On Tue, May 30, 2023 at 3:46 PM Adam Ford  wrote:
> > >
> > > There are some newer clocks added to the kernel recently,
> > > so to fix prepare for resycing the device trees, update
> > > the clock list.  Since there are some minor changes to
> > > the USB clocks, update which USB clocks are enabled
> > > to match with the upstream kernel as well.
> > >
> > > Signed-off-by: Adam Ford 
> > >
> > > diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> > > index 09bef596f2..a21a3ce34b 100644
> > > --- a/drivers/clk/imx/clk-imx8mp.c
> > > +++ b/drivers/clk/imx/clk-imx8mp.c
> > > @@ -337,7 +337,8 @@ static int imx8mp_clk_probe(struct udevice *dev)
> > > clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk", 
> > > "uart2", base + 0x44a0, 0));
> > > clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk", 
> > > "uart3", base + 0x44b0, 0));
> > > clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk", 
> > > "uart4", base + 0x44c0, 0));
> > > -   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", 
> > > "usb_core_ref", base + 0x44d0, 0));
> > > +   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate2("usb_root_clk", 
> > > "hsio_axi", base + 0x44d0, 0));
> > > +   clk_dm(IMX8MP_CLK_USB_SUSP, imx_clk_gate2("usb_suspend_clk", 
> > > "clock-osc-24m", base + 0x44d0, 0));
> > > clk_dm(IMX8MP_CLK_USB_PHY_ROOT, imx_clk_gate4("usb_phy_root_clk", 
> > > "usb_phy_ref", base + 0x44f0, 0));
> > > clk_dm(IMX8MP_CLK_USDHC1_ROOT, imx_clk_gate4("usdhc1_root_clk", 
> > > "usdhc1", base + 0x4510, 0));
> > > clk_dm(IMX8MP_CLK_USDHC2_ROOT, imx_clk_gate4("usdhc2_root_clk", 
> > > "usdhc2", base + 0x4520, 0));
> > > diff --git a/include/dt-bindings/clock/imx8mp-clock.h 
> > > b/include/dt-bindings/clock/imx8mp-clock.h
> > > index 9d5cc2ddde..3f28ce685f 100644
> > > --- a/include/dt-bindings/clock/imx8mp-clock.h
> > > +++ b/include/dt-bindings/clock/imx8mp-clock.h
> > > @@ -324,8 +324,18 @@
> > >  #define IMX8MP_CLK_CLKOUT2_SEL 317
> > >  #define IMX8MP_CLK_CLKOUT2_DIV 318
> > >  #define IMX8MP_CLK_CLKOUT2 319
> > > -
> > > -#define IMX8MP_CLK_END 320
> > > +#define IMX8MP_CLK_USB_SUSP320
> > > +#define IMX8MP_CLK_AUDIO_AHB_ROOT  IMX8MP_CLK_AUDIO_ROOT
> > > +#define IMX8MP_CLK_AUDIO_AXI_ROOT  321
> > > +#define IMX8MP_CLK_SAI1_ROOT   322
> > > +#define IMX8MP_CLK_SAI2_ROOT   323
> > > +#define IMX8MP_CLK_SAI3_ROOT   324
> > > +#define IMX8MP_CLK_SAI5_ROOT   325
> > > +#define IMX8MP_CLK_SAI6_ROOT   326
> > > +#define IMX8MP_CLK_SAI7_ROOT   327
> > > +#define IMX8MP_CLK_PDM_ROOT328
> > > +#define IMX8MP_CLK_MEDIA_LDB_ROOT  329
> > > +#define IMX8MP_CLK_END 330
> > >
> > >  #define IMX8MP_CLK_AUDIOMIX_SAI1_IPG   0
> > >  #define IMX8MP_CLK_AUDIOMIX_SAI1_MCLK1 1
> > > --
> > > 2.39.2
> > >
> >
> > Adam,
> >
> > This series does update the imx8mp.dtsi as well as provide functioning
> > USB for me on imx8mp-venice-gw74xx.
> >
>
> Thanks for testing!
>
> > For both:
> > Tested-by: Tim Harvey  #imx8mp-venice-gw74xx
> >
> > I do still see a clk already disabled message on usb stop (which was
> > there before also but I believe the sync of the imx8mm.dtsi resolved
> > the one on imx8mm). I'm curious if you see this as well:
> > u-boot=> usb start && usb tree
> > starting USB...
> > Bus usb@3820: Register 2000140 NbrPorts 2
> > Starting the controller
> > USB XHCI 1.10
> > scanning bus usb@3820 for devices... 4 USB Device(s) found
> >scanning usb for storage devices... 0 Storage Device(s) found
> > USB device tree:
> >   1  Hub (5 Gb/s, 0mA)
> >   |  U-Boot XHCI Host Controller
> >   |
> >   +-2  Hub (480 Mb/s, 0mA)
> >   | |  Microchip Tech USB2744
> >   | |
> >   | +-4  Vendor specific (480 Mb/s, 0mA)
> >   |  Microchip Tech Hub Controller
> >   |
> >   +-3  Hub (5 Gb/s, 0mA)
> >Microchip Tech USB5744
> >
> > u-boot=> usb stop
> > stopping USB..
> > clk usb_phy_root_clk already disabled
>
> I didn't try the usb stop, but I can do that later today.
>
> >
> > Also, I assume your Type-C ports on the imx8mp-beacon-kit do not work
> > yet due to no U-Boot driver for usb-c-connector, nxp,ptn5110,
>
> I only tried the USB host-only port which is connected to a hub, but I
> can try the others as well.
>
> > ti,hd3ss3220?
>
> The HD3ss3220 does the muxing automatically without really needing a
> driver, and I haven't tried that either, but I can try that as a
> peripheral and as a host to see if/what happens.
>
> adam

For imx8mp-venice-gw74xx the above shows the same... the USB host-only
port connected to a hub.

The Type-C connector 

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Tom Rini]

On Wed, May 31, 2023 at 04:25:46PM +0200, Heinrich Schuchardt wrote:
> Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:
> 
> > On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:
> >
> > > qemu_arm64_defconfig with UNIT_TEST=y does not build.
> > >
> > > CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
> > > must not enable unit tests invoking expo functions.
> > >
> > > Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all
> > uclasses")
> > > Signed-off-by: Heinrich Schuchardt 
> > > ---
> > >  test/boot/Makefile | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/test/boot/Makefile b/test/boot/Makefile
> > > index 22ed61c8fa..665017ba3d 100644
> > > --- a/test/boot/Makefile
> > > +++ b/test/boot/Makefile
> > > @@ -2,7 +2,10 @@
> > >  #
> > >  # Copyright 2021 Google LLC
> > >
> > > -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o
> > bootmeth.o
> > > +ifdef CONFIG_BOOTSTD
> > > +obj-y += bootstd_common.o bootmeth.o
> > > +obj-$(VIDEO) += bootdev.o bootflow.o
> > > +endif
> > >  obj-$(CONFIG_FIT) += image.o
> > >
> > >  obj-$(CONFIG_EXPO) += expo.o
> >
> > OK, but the functionality itself doesn't depend on video, it looks like
> > maybe only the bootflow_menu_theme test itself, so lets try and solve
> > this differently.
> >
> > --
> > Tom
> >
> 
> Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .

Well no, at first glance it's 1 out of 15 tests in that file that depend
on CONFIG_EXPO, so we should just ifdef that test.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] clk: imx8mp: Update clocks based on kernel 6.4-RC4

[Adam Ford]

On Wed, May 31, 2023 at 10:44 AM Tim Harvey  wrote:
>
> On Tue, May 30, 2023 at 3:46 PM Adam Ford  wrote:
> >
> > There are some newer clocks added to the kernel recently,
> > so to fix prepare for resycing the device trees, update
> > the clock list.  Since there are some minor changes to
> > the USB clocks, update which USB clocks are enabled
> > to match with the upstream kernel as well.
> >
> > Signed-off-by: Adam Ford 
> >
> > diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> > index 09bef596f2..a21a3ce34b 100644
> > --- a/drivers/clk/imx/clk-imx8mp.c
> > +++ b/drivers/clk/imx/clk-imx8mp.c
> > @@ -337,7 +337,8 @@ static int imx8mp_clk_probe(struct udevice *dev)
> > clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk", 
> > "uart2", base + 0x44a0, 0));
> > clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk", 
> > "uart3", base + 0x44b0, 0));
> > clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk", 
> > "uart4", base + 0x44c0, 0));
> > -   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", 
> > "usb_core_ref", base + 0x44d0, 0));
> > +   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate2("usb_root_clk", 
> > "hsio_axi", base + 0x44d0, 0));
> > +   clk_dm(IMX8MP_CLK_USB_SUSP, imx_clk_gate2("usb_suspend_clk", 
> > "clock-osc-24m", base + 0x44d0, 0));
> > clk_dm(IMX8MP_CLK_USB_PHY_ROOT, imx_clk_gate4("usb_phy_root_clk", 
> > "usb_phy_ref", base + 0x44f0, 0));
> > clk_dm(IMX8MP_CLK_USDHC1_ROOT, imx_clk_gate4("usdhc1_root_clk", 
> > "usdhc1", base + 0x4510, 0));
> > clk_dm(IMX8MP_CLK_USDHC2_ROOT, imx_clk_gate4("usdhc2_root_clk", 
> > "usdhc2", base + 0x4520, 0));
> > diff --git a/include/dt-bindings/clock/imx8mp-clock.h 
> > b/include/dt-bindings/clock/imx8mp-clock.h
> > index 9d5cc2ddde..3f28ce685f 100644
> > --- a/include/dt-bindings/clock/imx8mp-clock.h
> > +++ b/include/dt-bindings/clock/imx8mp-clock.h
> > @@ -324,8 +324,18 @@
> >  #define IMX8MP_CLK_CLKOUT2_SEL 317
> >  #define IMX8MP_CLK_CLKOUT2_DIV 318
> >  #define IMX8MP_CLK_CLKOUT2 319
> > -
> > -#define IMX8MP_CLK_END 320
> > +#define IMX8MP_CLK_USB_SUSP320
> > +#define IMX8MP_CLK_AUDIO_AHB_ROOT  IMX8MP_CLK_AUDIO_ROOT
> > +#define IMX8MP_CLK_AUDIO_AXI_ROOT  321
> > +#define IMX8MP_CLK_SAI1_ROOT   322
> > +#define IMX8MP_CLK_SAI2_ROOT   323
> > +#define IMX8MP_CLK_SAI3_ROOT   324
> > +#define IMX8MP_CLK_SAI5_ROOT   325
> > +#define IMX8MP_CLK_SAI6_ROOT   326
> > +#define IMX8MP_CLK_SAI7_ROOT   327
> > +#define IMX8MP_CLK_PDM_ROOT328
> > +#define IMX8MP_CLK_MEDIA_LDB_ROOT  329
> > +#define IMX8MP_CLK_END 330
> >
> >  #define IMX8MP_CLK_AUDIOMIX_SAI1_IPG   0
> >  #define IMX8MP_CLK_AUDIOMIX_SAI1_MCLK1 1
> > --
> > 2.39.2
> >
>
> Adam,
>
> This series does update the imx8mp.dtsi as well as provide functioning
> USB for me on imx8mp-venice-gw74xx.
>

Thanks for testing!

> For both:
> Tested-by: Tim Harvey  #imx8mp-venice-gw74xx
>
> I do still see a clk already disabled message on usb stop (which was
> there before also but I believe the sync of the imx8mm.dtsi resolved
> the one on imx8mm). I'm curious if you see this as well:
> u-boot=> usb start && usb tree
> starting USB...
> Bus usb@3820: Register 2000140 NbrPorts 2
> Starting the controller
> USB XHCI 1.10
> scanning bus usb@3820 for devices... 4 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> USB device tree:
>   1  Hub (5 Gb/s, 0mA)
>   |  U-Boot XHCI Host Controller
>   |
>   +-2  Hub (480 Mb/s, 0mA)
>   | |  Microchip Tech USB2744
>   | |
>   | +-4  Vendor specific (480 Mb/s, 0mA)
>   |  Microchip Tech Hub Controller
>   |
>   +-3  Hub (5 Gb/s, 0mA)
>Microchip Tech USB5744
>
> u-boot=> usb stop
> stopping USB..
> clk usb_phy_root_clk already disabled

I didn't try the usb stop, but I can do that later today.

>
> Also, I assume your Type-C ports on the imx8mp-beacon-kit do not work
> yet due to no U-Boot driver for usb-c-connector, nxp,ptn5110,

I only tried the USB host-only port which is connected to a hub, but I
can try the others as well.

> ti,hd3ss3220?

The HD3ss3220 does the muxing automatically without really needing a
driver, and I haven't tried that either, but I can try that as a
peripheral and as a host to see if/what happens.

adam
>
> Best Regards,
>
> Tim

Re: [PATCH 1/2] clk: imx8mp: Update clocks based on kernel 6.4-RC4

[Tim Harvey]

On Tue, May 30, 2023 at 3:46 PM Adam Ford  wrote:
>
> There are some newer clocks added to the kernel recently,
> so to fix prepare for resycing the device trees, update
> the clock list.  Since there are some minor changes to
> the USB clocks, update which USB clocks are enabled
> to match with the upstream kernel as well.
>
> Signed-off-by: Adam Ford 
>
> diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
> index 09bef596f2..a21a3ce34b 100644
> --- a/drivers/clk/imx/clk-imx8mp.c
> +++ b/drivers/clk/imx/clk-imx8mp.c
> @@ -337,7 +337,8 @@ static int imx8mp_clk_probe(struct udevice *dev)
> clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk", 
> "uart2", base + 0x44a0, 0));
> clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk", 
> "uart3", base + 0x44b0, 0));
> clk_dm(IMX8MP_CLK_UART4_ROOT, imx_clk_gate4("uart4_root_clk", 
> "uart4", base + 0x44c0, 0));
> -   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate4("usb_root_clk", 
> "usb_core_ref", base + 0x44d0, 0));
> +   clk_dm(IMX8MP_CLK_USB_ROOT, imx_clk_gate2("usb_root_clk", "hsio_axi", 
> base + 0x44d0, 0));
> +   clk_dm(IMX8MP_CLK_USB_SUSP, imx_clk_gate2("usb_suspend_clk", 
> "clock-osc-24m", base + 0x44d0, 0));
> clk_dm(IMX8MP_CLK_USB_PHY_ROOT, imx_clk_gate4("usb_phy_root_clk", 
> "usb_phy_ref", base + 0x44f0, 0));
> clk_dm(IMX8MP_CLK_USDHC1_ROOT, imx_clk_gate4("usdhc1_root_clk", 
> "usdhc1", base + 0x4510, 0));
> clk_dm(IMX8MP_CLK_USDHC2_ROOT, imx_clk_gate4("usdhc2_root_clk", 
> "usdhc2", base + 0x4520, 0));
> diff --git a/include/dt-bindings/clock/imx8mp-clock.h 
> b/include/dt-bindings/clock/imx8mp-clock.h
> index 9d5cc2ddde..3f28ce685f 100644
> --- a/include/dt-bindings/clock/imx8mp-clock.h
> +++ b/include/dt-bindings/clock/imx8mp-clock.h
> @@ -324,8 +324,18 @@
>  #define IMX8MP_CLK_CLKOUT2_SEL 317
>  #define IMX8MP_CLK_CLKOUT2_DIV 318
>  #define IMX8MP_CLK_CLKOUT2 319
> -
> -#define IMX8MP_CLK_END 320
> +#define IMX8MP_CLK_USB_SUSP320
> +#define IMX8MP_CLK_AUDIO_AHB_ROOT  IMX8MP_CLK_AUDIO_ROOT
> +#define IMX8MP_CLK_AUDIO_AXI_ROOT  321
> +#define IMX8MP_CLK_SAI1_ROOT   322
> +#define IMX8MP_CLK_SAI2_ROOT   323
> +#define IMX8MP_CLK_SAI3_ROOT   324
> +#define IMX8MP_CLK_SAI5_ROOT   325
> +#define IMX8MP_CLK_SAI6_ROOT   326
> +#define IMX8MP_CLK_SAI7_ROOT   327
> +#define IMX8MP_CLK_PDM_ROOT328
> +#define IMX8MP_CLK_MEDIA_LDB_ROOT  329
> +#define IMX8MP_CLK_END 330
>
>  #define IMX8MP_CLK_AUDIOMIX_SAI1_IPG   0
>  #define IMX8MP_CLK_AUDIOMIX_SAI1_MCLK1 1
> --
> 2.39.2
>

Adam,

This series does update the imx8mp.dtsi as well as provide functioning
USB for me on imx8mp-venice-gw74xx.

For both:
Tested-by: Tim Harvey  #imx8mp-venice-gw74xx

I do still see a clk already disabled message on usb stop (which was
there before also but I believe the sync of the imx8mm.dtsi resolved
the one on imx8mm). I'm curious if you see this as well:
u-boot=> usb start && usb tree
starting USB...
Bus usb@3820: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@3820 for devices... 4 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
USB device tree:
  1  Hub (5 Gb/s, 0mA)
  |  U-Boot XHCI Host Controller
  |
  +-2  Hub (480 Mb/s, 0mA)
  | |  Microchip Tech USB2744
  | |
  | +-4  Vendor specific (480 Mb/s, 0mA)
  |  Microchip Tech Hub Controller
  |
  +-3  Hub (5 Gb/s, 0mA)
   Microchip Tech USB5744

u-boot=> usb stop
stopping USB..
clk usb_phy_root_clk already disabled

Also, I assume your Type-C ports on the imx8mp-beacon-kit do not work
yet due to no U-Boot driver for usb-c-connector, nxp,ptn5110,
ti,hd3ss3220?

Best Regards,

Tim

Re: [RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU

[Andre Przywara]

On Mon, 29 May 2023 18:58:54 -0600
Sam Edwards  wrote:

Hi Sam,

> On 5/26/23 20:15, Sam Edwards wrote:
> > My "no success" is Linux stalling indefinitely at:
> > [    0.123090] smp: Bringing up secondary CPUs ...  
> 
> OK, correction: my "no success" was Linux being unable to access the 
> GIC, so boot was getting stuck. This was because it was running in 
> nonsec mode and the GIC wasn't getting the interrupts moved over into 
> group1.
> 
> The root cause of THAT was that the T113's CBAR's PERIPHBASE is still 
> 0x01C8, where the GIC used to be on the older ARM sunxis. Allwinner 
> never updated their ARM cores when they moved the GIC to 0x0302!

Ah, good find! And yeah, I already noticed that on the H6 a few years
back, but nobody really cares, and other SoCs get CBAR wrong as well
(hence the existing workaround).

> Guess we need a `#define CFG_ARM_GIC_BASE_ADDRESS 0x0302`. Where do 
> you recommend I put that? :)

Meh, the reflex would be to put it in include/configs/sunxi-common.h.
Although I wonder if it really belongs into Kconfig, but that may be for
another time.

> I also think sunxi/psci.c:psci_arch_init needs some cleanup:
> - It sets GICC_PMR to 0xFF, which should probably be removed because 
> that was already done by `_nonsec_init`
> - It tries to clear the NS bit of SCR to enter secure mode, but the NS 
> bit is just enabled later in `_secure_monitor`. So that should also be 
> removed because it has no effect.
> 
> So, I'll have a few PSCI patches for you soon -- once I rest up from all 
> of that GIC debugging, that is!

Ah, sorry to hear that, the GIC can really be a beast ;-)

Cheers,
Andre

[PATCH 2/2] board: fsl: lx2160ardb: add dts fixup function for RevC and newer

[Ioana Ciornei]

From: Florin Chiculita 

Since the new RevC LX2160A-RDB board has its 10G Aquantia PHYs at
different MDIO bus addresses, we must update both the kernel DTS and
u-boot's DTS (in case of DM_ETH) in case the board is indeed RevC or
newer. Use the newly introduced get_board_rev() function to trigger a
fixup of the kernel DTS to properly match the actual PHY addresses.
All this is encapsulated in the fdt_fixup_board_phy_revc() function
which will be used in the next patch.

Use the newly fdt_fixup_board_phy_revc() function introduced to
update both kernel's DTS and u-boot's DTS.

Signed-off-by: Florin Chiculita 
Signed-off-by: Ioana Ciornei 
---
 board/freescale/lx2160a/eth_lx2160ardb.c | 107 +++
 board/freescale/lx2160a/lx2160a.c|   7 ++
 board/freescale/lx2160a/lx2160a.h|   1 +
 include/configs/lx2160ardb.h |   5 ++
 4 files changed, 120 insertions(+)

diff --git a/board/freescale/lx2160a/eth_lx2160ardb.c 
b/board/freescale/lx2160a/eth_lx2160ardb.c
index 533f606effa7..c5dfefe1f342 100644
--- a/board/freescale/lx2160a/eth_lx2160ardb.c
+++ b/board/freescale/lx2160a/eth_lx2160ardb.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include "lx2160a.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -36,3 +37,109 @@ void reset_phy(void)
 #endif
 }
 #endif /* CONFIG_RESET_PHY_R */
+
+static int fdt_get_dpmac_node(void *fdt, int dpmac_id)
+{
+   char dpmac_str[11] = "dpmacs@00";
+   int offset, dpmacs_offset;
+
+   /* get the dpmac offset */
+   dpmacs_offset = fdt_path_offset(fdt, "/soc/fsl-mc/dpmacs");
+   if (dpmacs_offset < 0)
+   dpmacs_offset = fdt_path_offset(fdt, "/fsl-mc/dpmacs");
+
+   if (dpmacs_offset < 0) {
+   printf("dpmacs node not found in device tree\n");
+   return dpmacs_offset;
+   }
+
+   sprintf(dpmac_str, "dpmac@%x", dpmac_id);
+   offset = fdt_subnode_offset(fdt, dpmacs_offset, dpmac_str);
+   if (offset < 0) {
+   sprintf(dpmac_str, "ethernet@%x", dpmac_id);
+   offset = fdt_subnode_offset(fdt, dpmacs_offset, dpmac_str);
+   if (offset < 0) {
+   printf("dpmac@%x/ethernet@%x node not found in device 
tree\n",
+  dpmac_id, dpmac_id);
+   return offset;
+   }
+   }
+
+   return offset;
+}
+
+static int fdt_update_phy_addr(void *fdt, int dpmac_id, int phy_addr)
+{
+   char dpmac_str[] = "dpmacs@00";
+   const u32 *phyhandle;
+   int offset;
+   int err;
+
+   /* get the dpmac offset */
+   offset = fdt_get_dpmac_node(fdt, dpmac_id);
+   if (offset < 0)
+   return offset;
+
+   /* get dpmac phy-handle */
+   sprintf(dpmac_str, "dpmac@%x", dpmac_id);
+   phyhandle = (u32 *)fdt_getprop(fdt, offset, "phy-handle", NULL);
+   if (!phyhandle) {
+   printf("%s node not found in device tree\n", dpmac_str);
+   return offset;
+   }
+
+   offset = fdt_node_offset_by_phandle(fdt, fdt32_to_cpu(*phyhandle));
+   if (offset < 0) {
+   printf("Could not get the ph node offset for dpmac %d\n",
+  dpmac_id);
+   return offset;
+   }
+
+   phy_addr = cpu_to_fdt32(phy_addr);
+   err = fdt_setprop(fdt, offset, "reg", _addr, sizeof(phy_addr));
+   if (err < 0) {
+   printf("Could not set phy node's reg for dpmac %d: %s.\n",
+  dpmac_id, fdt_strerror(err));
+   return err;
+   }
+
+   return 0;
+}
+
+static int fdt_delete_phy_handle(void *fdt, int dpmac_id)
+{
+   const u32 *phyhandle;
+   int offset;
+
+   /* get the dpmac offset */
+   offset = fdt_get_dpmac_node(fdt, dpmac_id);
+   if (offset < 0)
+   return offset;
+
+   /* verify if the node has a phy-handle */
+   phyhandle = (u32 *)fdt_getprop(fdt, offset, "phy-handle", NULL);
+   if (!phyhandle)
+   return 0;
+
+   return fdt_delprop(fdt, offset, "phy-handle");
+}
+
+int fdt_fixup_board_phy_revc(void *fdt)
+{
+   int ret;
+
+   if (get_board_rev() < 'C')
+   return 0;
+
+   /* DPMACs 3,4 have their Aquantia PHYs at new addresses */
+   ret = fdt_update_phy_addr(fdt, 3, AQR113C_PHY_ADDR1);
+   if (ret)
+   return ret;
+
+   ret = fdt_update_phy_addr(fdt, 4, AQR113C_PHY_ADDR2);
+   if (ret)
+   return ret;
+
+   /* There is no PHY for the DPMAC2, so remove the phy-handle */
+   return fdt_delete_phy_handle(fdt, 2);
+}
diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index 4d406ac8f1c6..d631a11ff667 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -133,6 +133,11 @@ int board_fix_fdt(void *fdt)
fdt_setprop(fdt, off, "reg-names", reg_names, names_len);
}
 
+   /* Fixup u-boot's DTS in case this is a 

[PATCH 1/2] board: fsl: lx2160ardb: add api for obtaining board revision

[Ioana Ciornei]

From: Florin Chiculita 

Add new API for obtaining board revision and trigger the i2c node
fixup with this new API.

Signed-off-by: Florin Chiculita 
Signed-off-by: Ioana Ciornei 
---
 board/freescale/lx2160a/lx2160a.c | 15 ++-
 board/freescale/lx2160a/lx2160a.h |  4 
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/board/freescale/lx2160a/lx2160a.c 
b/board/freescale/lx2160a/lx2160a.c
index 2a752054cd99..4d406ac8f1c6 100644
--- a/board/freescale/lx2160a/lx2160a.c
+++ b/board/freescale/lx2160a/lx2160a.c
@@ -487,6 +487,15 @@ int config_board_mux(void)
 }
 #endif
 
+#if IS_ENABLED(CONFIG_TARGET_LX2160ARDB)
+u8 get_board_rev(void)
+{
+   u8 board_rev = (QIXIS_READ(arch) & 0xf) - 1 + 'A';
+
+   return board_rev;
+}
+#endif
+
 unsigned long get_board_sys_clk(void)
 {
 #if defined(CONFIG_TARGET_LX2160AQDS) || defined(CONFIG_TARGET_LX2162AQDS)
@@ -760,9 +769,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
u64 mc_memory_size = 0;
u16 total_memory_banks;
int err;
-#if IS_ENABLED(CONFIG_TARGET_LX2160ARDB)
-   u8 board_rev;
-#endif
 
err = fdt_increase_size(blob, 512);
if (err) {
@@ -825,8 +831,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
fdt_fixup_icid(blob);
 
 #if IS_ENABLED(CONFIG_TARGET_LX2160ARDB)
-   board_rev = (QIXIS_READ(arch) & 0xf) - 1 + 'A';
-   if (board_rev == 'C')
+   if (get_board_rev() == 'C')
fdt_fixup_i2c_thermal_node(blob);
 #endif
 
diff --git a/board/freescale/lx2160a/lx2160a.h 
b/board/freescale/lx2160a/lx2160a.h
index 52b020765dc6..4aac99e576a4 100644
--- a/board/freescale/lx2160a/lx2160a.h
+++ b/board/freescale/lx2160a/lx2160a.h
@@ -58,4 +58,8 @@
 #endif
 #endif
 
+#if IS_ENABLED(CONFIG_TARGET_LX2160ARDB)
+u8 get_board_rev(void);
+#endif
+
 #endif /* __LX2160_H */
-- 
2.25.1

[PATCH 0/2] board: fsl: lx2160ardb: fixup PHY addresses for new board revisions

[Ioana Ciornei]

On the board revisions C and D,  the LX2160A-RDB has the two 10G copper
PHYs at different MDIO addresses. This patch set does the necessary
fixup to both u-boot's and Linux's DTS so that the PHYs are properly
described.

Florin Chiculita (2):
  board: fsl: lx2160ardb: add api for obtaining board revision
  board: fsl: lx2160ardb: add dts fixup function for RevC and newer

 board/freescale/lx2160a/eth_lx2160ardb.c | 107 +++
 board/freescale/lx2160a/lx2160a.c|  22 +++--
 board/freescale/lx2160a/lx2160a.h|   5 ++
 include/configs/lx2160ardb.h |   5 ++
 4 files changed, 134 insertions(+), 5 deletions(-)

-- 
2.25.1

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Heinrich Schuchardt]

Tom Rini  schrieb am Mi., 31. Mai 2023, 16:02:

> On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:
>
> > qemu_arm64_defconfig with UNIT_TEST=y does not build.
> >
> > CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
> > must not enable unit tests invoking expo functions.
> >
> > Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all
> uclasses")
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  test/boot/Makefile | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/test/boot/Makefile b/test/boot/Makefile
> > index 22ed61c8fa..665017ba3d 100644
> > --- a/test/boot/Makefile
> > +++ b/test/boot/Makefile
> > @@ -2,7 +2,10 @@
> >  #
> >  # Copyright 2021 Google LLC
> >
> > -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o
> bootmeth.o
> > +ifdef CONFIG_BOOTSTD
> > +obj-y += bootstd_common.o bootmeth.o
> > +obj-$(VIDEO) += bootdev.o bootflow.o
> > +endif
> >  obj-$(CONFIG_FIT) += image.o
> >
> >  obj-$(CONFIG_EXPO) += expo.o
>
> OK, but the functionality itself doesn't depend on video, it looks like
> maybe only the bootflow_menu_theme test itself, so lets try and solve
> this differently.
>
> --
> Tom
>

Yes I should have used CONFIG_EXPO not CONFIG_VIDEO .

Regards

Heinrich

>

Re: [PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Tom Rini]

On Wed, May 31, 2023 at 10:50:52AM +0200, Heinrich Schuchardt wrote:

> qemu_arm64_defconfig with UNIT_TEST=y does not build.
> 
> CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
> must not enable unit tests invoking expo functions.
> 
> Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all uclasses")
> Signed-off-by: Heinrich Schuchardt 
> ---
>  test/boot/Makefile | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/test/boot/Makefile b/test/boot/Makefile
> index 22ed61c8fa..665017ba3d 100644
> --- a/test/boot/Makefile
> +++ b/test/boot/Makefile
> @@ -2,7 +2,10 @@
>  #
>  # Copyright 2021 Google LLC
>  
> -obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
> +ifdef CONFIG_BOOTSTD
> +obj-y += bootstd_common.o bootmeth.o
> +obj-$(VIDEO) += bootdev.o bootflow.o
> +endif
>  obj-$(CONFIG_FIT) += image.o
>  
>  obj-$(CONFIG_EXPO) += expo.o

OK, but the functionality itself doesn't depend on video, it looks like
maybe only the bootflow_menu_theme test itself, so lets try and solve
this differently.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] config: stm32mp15: remove CONFIG_FASTBOOT_CMD_OEM_FORMAT

[Patrice CHOTARD]

On 5/30/23 14:26, Patrick Delaunay wrote:
> Remove the support of the fastboot "oem format" command for STM32MP15x
> boards and removed the associated env variable "partitions".
> This command is not required; with fastboot tool, the GPT partition can
> be handle with "flash" command in "gpt" target (=CONFIG_FASTBOOT_GPT_NAME),
> for example: fastboot flash gpt gpt.bin
> 
> This patch avoids to define the GPT partitioning in U-Boot environment,
> which is incompatible with planned modifications, for example to
> support TF-A firmware update.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  configs/stm32mp15_basic_defconfig |  1 -
>  configs/stm32mp15_defconfig   |  1 -
>  configs/stm32mp15_trusted_defconfig   |  1 -
>  include/configs/stm32mp15_common.h| 14 --
>  include/configs/stm32mp15_st_common.h |  1 -
>  5 files changed, 18 deletions(-)
> 
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 174eb42d6447..dc67873d3934 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -109,7 +109,6 @@ CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0"
>  CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1"
>  CONFIG_FASTBOOT_MMC_USER_SUPPORT=y
>  CONFIG_FASTBOOT_MMC_USER_NAME="mmc1"
> -CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y
>  CONFIG_FASTBOOT_CMD_OEM_BOOTBUS=y
>  CONFIG_GPIO_HOG=y
> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
> index b25477c64d03..fd8c9121762e 100644
> --- a/configs/stm32mp15_defconfig
> +++ b/configs/stm32mp15_defconfig
> @@ -82,7 +82,6 @@ CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0"
>  CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1"
>  CONFIG_FASTBOOT_MMC_USER_SUPPORT=y
>  CONFIG_FASTBOOT_MMC_USER_NAME="mmc1"
> -CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y
>  CONFIG_FASTBOOT_CMD_OEM_BOOTBUS=y
>  CONFIG_GPIO_HOG=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index e93a66f867cf..ec6298a0cb4a 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -83,7 +83,6 @@ CONFIG_FASTBOOT_MMC_BOOT1_NAME="mmc1boot0"
>  CONFIG_FASTBOOT_MMC_BOOT2_NAME="mmc1boot1"
>  CONFIG_FASTBOOT_MMC_USER_SUPPORT=y
>  CONFIG_FASTBOOT_MMC_USER_NAME="mmc1"
> -CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y
>  CONFIG_FASTBOOT_CMD_OEM_BOOTBUS=y
>  CONFIG_GPIO_HOG=y
> diff --git a/include/configs/stm32mp15_common.h 
> b/include/configs/stm32mp15_common.h
> index 7db72a19ed95..29a1197b5ae2 100644
> --- a/include/configs/stm32mp15_common.h
> +++ b/include/configs/stm32mp15_common.h
> @@ -92,19 +92,6 @@
>   "run distro_bootcmd;" \
>   "fi;\0"
>  
> -#ifdef CONFIG_FASTBOOT_CMD_OEM_FORMAT
> -/* eMMC default partitions for fastboot command: oem format */
> -#define STM32MP_PARTS_DEFAULT \
> - "partitions=" \
> - "name=ssbl,size=2M;" \
> - "name=bootfs,size=64MB,bootable;" \
> - "name=vendorfs,size=16M;" \
> - "name=rootfs,size=746M;" \
> - "name=userfs,size=-\0"
> -#else
> -#define STM32MP_PARTS_DEFAULT
> -#endif
> -
>  #define STM32MP_EXTRA \
>   "env_check=if env info -p -d -q; then env save; fi\0" \
>   "boot_net_usb_start=true\0"
> @@ -138,7 +125,6 @@
>  #define CFG_EXTRA_ENV_SETTINGS \
>   STM32MP_MEM_LAYOUT \
>   STM32MP_BOOTCMD \
> - STM32MP_PARTS_DEFAULT \
>   BOOTENV \
>   STM32MP_EXTRA \
>   STM32MP_BOARD_EXTRA_ENV
> diff --git a/include/configs/stm32mp15_st_common.h 
> b/include/configs/stm32mp15_st_common.h
> index 866cd7a719f8..b45982a35b8c 100644
> --- a/include/configs/stm32mp15_st_common.h
> +++ b/include/configs/stm32mp15_st_common.h
> @@ -47,7 +47,6 @@
>  #define CFG_EXTRA_ENV_SETTINGS \
>   STM32MP_MEM_LAYOUT \
>   ST_STM32MP1_BOOTCMD \
> - STM32MP_PARTS_DEFAULT \
>   BOOTENV \
>   STM32MP_EXTRA \
>   STM32MP_BOARD_EXTRA_ENV


Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH 1/2] config: stm32mp15: remove CONFIG_FASTBOOT_USB_DEV

[Patrice CHOTARD]

Hi Patrick

On 5/30/23 14:26, Patrick Delaunay wrote:
> The CONFIG_FASTBOOT_USB_DEV is used to select USB OTG controller other
> than 0 but it is not the case for STM32MP15 boards; it can be removed
> to simplify the STM32MP15 defconfig files.
> 
> On STM32MP15x boards, we have only one USB device with instance 0,
> so the device is hardcoded arch/arm/mach-stm32mp/cpu.c with
> the command "fastboot 0" and this define is not used in config files
> (include/configs/stm32mp15_st_common.h).
> 
> Fixes: 4633fd51c5d7 ("stm32mp1: activate FASTBOOT on eMMC")
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  configs/stm32mp15_basic_defconfig   | 1 -
>  configs/stm32mp15_defconfig | 1 -
>  configs/stm32mp15_trusted_defconfig | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 13355ebb4692..174eb42d6447 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -102,7 +102,6 @@ CONFIG_SET_DFU_ALT_INFO=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0xC000
>  CONFIG_FASTBOOT_BUF_SIZE=0x0200
> -CONFIG_FASTBOOT_USB_DEV=1
>  CONFIG_FASTBOOT_FLASH=y
>  CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y
> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig
> index 2669aae0f2f4..b25477c64d03 100644
> --- a/configs/stm32mp15_defconfig
> +++ b/configs/stm32mp15_defconfig
> @@ -75,7 +75,6 @@ CONFIG_SET_DFU_ALT_INFO=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0xC000
>  CONFIG_FASTBOOT_BUF_SIZE=0x0200
> -CONFIG_FASTBOOT_USB_DEV=1
>  CONFIG_FASTBOOT_FLASH=y
>  CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 5f0fb4565105..e93a66f867cf 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -76,7 +76,6 @@ CONFIG_SET_DFU_ALT_INFO=y
>  CONFIG_USB_FUNCTION_FASTBOOT=y
>  CONFIG_FASTBOOT_BUF_ADDR=0xC000
>  CONFIG_FASTBOOT_BUF_SIZE=0x0200
> -CONFIG_FASTBOOT_USB_DEV=1
>  CONFIG_FASTBOOT_FLASH=y
>  CONFIG_FASTBOOT_FLASH_MMC_DEV=1
>  CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y

Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: R: Fit Signature booting without public key

[Tom Rini]

On Wed, May 31, 2023 at 10:00:34AM +0530, Manorit Chawdhry wrote:
> Hi,
> 
> On 16:51-20230530, Pegorer Massimo wrote:
> > Hi,
> > 
> > > Inviato: venerdì 26 maggio 2023 15:00
> > > Oggetto: Re: Fit Signature booting without public key
> > > 
> > > On Fri, May 26, 2023 at 02:22:38PM +0530, Manorit Chawdhry wrote:
> > > > Hi Tom,
> > > >
> > > > On 10:05-20230525, Tom Rini wrote:
> > > > > On Thu, May 25, 2023 at 11:21:44AM +0530, Manorit Chawdhry wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On 11:30-20230516, Tom Rini wrote:
> > > > > > > On Tue, May 16, 2023 at 12:11:24PM +0530, Manorit Chawdhry wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > >
> > > > > > > > I recently came upon a discussion that had happened a while back
> > > [0].
> > > > > > > > I want to continue the discussion as I believe the issue still
> > > > > > > > persists and the checks around fit signature booting are still
> > > > > > > > the same, that allows booting the fit without changing the uboot
> > > dtb.
> > > > > > > >
> > > > > > > > Allowing the signed fit image without this seems to be a
> > > > > > > > bypass that is available and should not be allowed without any
> > > > > > > > gate to it for people who'd like to enforce these signing
> > > > > > > > checks. Let me know if there is a config already available for
> > > > > > > > it and if not, are there any plans to enable such a config in
> > > > > > > > future. Would like to hear your opinions on this as I believe 
> > > > > > > > this
> > > should be fixed as soon as possible.
> > > > > > > >
> > > > > > > > [0]:
> > > > > > > > https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boot
> > > > > > > > s-without-public-key
> > > > > > >
> > > > > > > Yes, can you please reproduce the issue in question on the
> > > > > > > current tree, with a supported platform and provide the
> > > > > > > defconfig and steps you used for this issue? Thanks.
> > > > > > >
> > > > > > > --
> > > > > >
> > > > > > I've created a branch with some custom patches to make the
> > > > > > fitimage booting currently, please try with the branch and the
> > > > > > fitimage that are also committed [0].
> > > > > >
> > > > > > The devices that I've tested this with is j721e-hs-evm, the
> > > > > > defconfig to use for the builds are j721e_evm_r5_defconfig and
> > > > > > j721e_evm_a72_defconfig. Although not synced up with the latest
> > > > > > changes but for reference the SDK documentation can help if required
> > > [1].
> > > > > >
> > > > > > Attached the logs for reference with the signed fitimage and an
> > > > > > unsigned uboot without any modifications[2].
> > > > > >
> > > > > > [0]: https://github.com/manorit2001/u-boot/tree/fit-image-poc
> > > > > > [1]:
> > > > > > https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacint
> > > > > > o7/08_06_00_11/exports/docs/linux/Foundational_Components/U-
> > > Boot/U
> > > > > > G-General-Info.html
> > > > > > [2]:
> > > > > > https://gist.github.com/manorit2001/3c49cfc19bf937783efb75fd4cddc5
> > > > > > 8f
> > > > >
> > > > > I don't see the problem there, but please go and investigate what
> > > > > problem you're seeing.  The intention is that yes, with the
> > > > > appropriate CONFIG settings, you can set U-Boot to only boot signed
> > > > > FIT configurations and unsigned ones should not boot.
> > > > >
> > > >
> > > > It boots with an unsigned fit too btw for reference [0]. The whole
> > > > logic behind the authentication is that uboot stores the public key
> > > > that is used for verification of the signed fit but apparantely if I
> > > > haven't kept the public key in uboot dtb the fit images still boot
> > > > whether signed or unsigned as that check is not guarded by anything if
> > > > you see in the codebase[1].
> > 
> > Which uboot behaviour would you expect? If uboot is missing of the public 
> > key, it has no way to check signatures. Therefore either it boots 
> > everything (signed and unsigned) or it boots nothing (signed and unsigned). 
> > The second means it would be totally useless. So the first seems the only 
> > reasonable behaviour, IMO.
> > 
> 
> I would actually expect it to through some errors telling about all this
> instead of silently booting it, if the configurations of the dtb and the
> signing ain't proper I don't believe there is any way to know about any
> of this as it just boots up without any hint about it whatsoever, I
> believe if this is enabled then there should atleast be an optional
> config that allows people to get their environment right for validating
> all this.

Right.  With the correct set of options you should be able to enforce
only booting signed images.  I thought that test/py/tests/test_vboot.py
covered this combination as well, but if it's not it should be updated
to.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 31.05.23 14:58, Dario Binacchi wrote:
> Hi Frieder, All
> 
> On Wed, May 31, 2023 at 12:58 PM Frieder Schrempf
>  wrote:
>>
>> On 17.05.23 09:43, Frieder Schrempf wrote:
>>> Hi Michael, hi Dario,
>>>
>>> On 15.05.23 23:33, Michael Nazzareno Trimarchi wrote:
 Hi

 Il lun 15 mag 2023, 23:12 Tom Rini >>> > ha scritto:

 On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
 > Hi Michael, hi Dario,
 >
 > On 18.04.23 15:46, Frieder Schrempf wrote:
 > > Hi Michael, Dario,
 > >
 > > On 28.03.23 09:57, Frieder Schrempf wrote:
 > >> Hi Michael,
 > >>
 > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
 > >>> Hi
 > >>>
 > >>> I will review
 > >>>
 > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini >>> > wrote:
 > 
 >  On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf 
 wrote:
 > > Hi,
 > >
 > > On 10.01.23 12:58, Frieder Schrempf wrote:
 > >> From: Mikhail Kshevetskiy >>> >
 > >>
 > >> Currently there are 3 different variants of read_id
 implementation:
 > >> 1. opcode only. Found in GD5FxGQ4xF.
 > >> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
 > >> 3. opcode + 1 dummy byte. Found in other currently
 supported chips.
 > >>
 > >> Original implementation was for variant 1 and let detect
 function
 > >> of chips with variant 2 and 3 to ignore the first byte.
 This isn't
 > >> robust:
 > >>
 > >> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
 > >> during read, chip will get a random id offset, and the
 entire id
 > >> buffer will shift by that offset, causing detect failure.
 > >>
 > >> 2. For chips of variant 1, if it happens to get a devid
 that equals
 > >> to manufacture id of variant 2 or 3 chips, it'll get
 incorrectly
 > >> detected.
 > >>
 > >> This patch reworks detect procedure to address problems
 above. New
 > >> logic do detection for all variants separatedly, in 1-2-3
 order.
 > >> Since all current detect methods do exactly the same id
 matching
 > >> procedure, unify them into core.c and remove detect method 
 from
 > >> manufacture_ops.
 > >>
 > >> This is a rework of Chuanhong Guo >>> > patch
 > >> submitted to linux kernel
 > >>
 > >> Signed-off-by: Mikhail Kshevetskiy
 mailto:mikhail.kshevets...@iopsys.eu>>
 > >> Signed-off-by: Frieder Schrempf
 mailto:frieder.schre...@kontron.de>>
 > >
 > > +Cc: Jagan, Tom
 > >
 > > Who is supposed to pick up these patches? Some of them have
 been around
 > > for some months (before I resent them).
 > >
 > > There is no maintainer for drivers/mtd/spinand/ and no
 maintainer for
 > > drivers/mtd/ in general.
 > >
 > > In Patchwork Jagan got assigned, but the get_maintainer.pl
  script didn't
 > > even add him to Cc, of course.
 > >
 > > Any ideas how to proceed?
 > 
 >  We don't have anyone dedicated to that area, yes, sadly. I've
 added
 >  Michael and Dario as they've also been doing mtd-but-not-spi
 work of
 >  late to see if they're interested. Or since you've long been
 working
 >  here, would you like to more formally maintain the area? Thanks!
 > >>>
 > >>> They can come from our tree. I will try to sort out all my
 duties weeked
 > >>
 > >> Any news regarding reviewing/picking these patches?
 > >
 > > Ping!
 > >
 > > Can you please apply these patches, that have been waiting for
 so long?
 >
 > I still can't see this applied anywhere. You already told me to take
 > care of it multiple times. Can you please get it done?

 Yes, I'd really like to see a PR at least vs -next at this point so
 things aren't lost, thanks!


 I think that we pick already it so it will happen.
>>>
>>> I can see patch 1/5 of this series in the nand-next tree. What about the
>>> other four patches of this series? Please pick them up, too!
>>
>> Ping, again! I will just keep on doing this and hope at some point you
>> will pick up the patches.

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Dario Binacchi]

Hi Frieder, All

On Wed, May 31, 2023 at 12:58 PM Frieder Schrempf
 wrote:
>
> On 17.05.23 09:43, Frieder Schrempf wrote:
> > Hi Michael, hi Dario,
> >
> > On 15.05.23 23:33, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >>
> >> Il lun 15 mag 2023, 23:12 Tom Rini  >> > ha scritto:
> >>
> >> On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
> >> > Hi Michael, hi Dario,
> >> >
> >> > On 18.04.23 15:46, Frieder Schrempf wrote:
> >> > > Hi Michael, Dario,
> >> > >
> >> > > On 28.03.23 09:57, Frieder Schrempf wrote:
> >> > >> Hi Michael,
> >> > >>
> >> > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
> >> > >>> Hi
> >> > >>>
> >> > >>> I will review
> >> > >>>
> >> > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini  >> > wrote:
> >> > 
> >> >  On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf 
> >> wrote:
> >> > > Hi,
> >> > >
> >> > > On 10.01.23 12:58, Frieder Schrempf wrote:
> >> > >> From: Mikhail Kshevetskiy  >> >
> >> > >>
> >> > >> Currently there are 3 different variants of read_id
> >> implementation:
> >> > >> 1. opcode only. Found in GD5FxGQ4xF.
> >> > >> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
> >> > >> 3. opcode + 1 dummy byte. Found in other currently
> >> supported chips.
> >> > >>
> >> > >> Original implementation was for variant 1 and let detect
> >> function
> >> > >> of chips with variant 2 and 3 to ignore the first byte.
> >> This isn't
> >> > >> robust:
> >> > >>
> >> > >> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
> >> > >> during read, chip will get a random id offset, and the
> >> entire id
> >> > >> buffer will shift by that offset, causing detect failure.
> >> > >>
> >> > >> 2. For chips of variant 1, if it happens to get a devid
> >> that equals
> >> > >> to manufacture id of variant 2 or 3 chips, it'll get
> >> incorrectly
> >> > >> detected.
> >> > >>
> >> > >> This patch reworks detect procedure to address problems
> >> above. New
> >> > >> logic do detection for all variants separatedly, in 1-2-3
> >> order.
> >> > >> Since all current detect methods do exactly the same id
> >> matching
> >> > >> procedure, unify them into core.c and remove detect method 
> >> from
> >> > >> manufacture_ops.
> >> > >>
> >> > >> This is a rework of Chuanhong Guo  >> > patch
> >> > >> submitted to linux kernel
> >> > >>
> >> > >> Signed-off-by: Mikhail Kshevetskiy
> >> mailto:mikhail.kshevets...@iopsys.eu>>
> >> > >> Signed-off-by: Frieder Schrempf
> >> mailto:frieder.schre...@kontron.de>>
> >> > >
> >> > > +Cc: Jagan, Tom
> >> > >
> >> > > Who is supposed to pick up these patches? Some of them have
> >> been around
> >> > > for some months (before I resent them).
> >> > >
> >> > > There is no maintainer for drivers/mtd/spinand/ and no
> >> maintainer for
> >> > > drivers/mtd/ in general.
> >> > >
> >> > > In Patchwork Jagan got assigned, but the get_maintainer.pl
> >>  script didn't
> >> > > even add him to Cc, of course.
> >> > >
> >> > > Any ideas how to proceed?
> >> > 
> >> >  We don't have anyone dedicated to that area, yes, sadly. I've
> >> added
> >> >  Michael and Dario as they've also been doing mtd-but-not-spi
> >> work of
> >> >  late to see if they're interested. Or since you've long been
> >> working
> >> >  here, would you like to more formally maintain the area? Thanks!
> >> > >>>
> >> > >>> They can come from our tree. I will try to sort out all my
> >> duties weeked
> >> > >>
> >> > >> Any news regarding reviewing/picking these patches?
> >> > >
> >> > > Ping!
> >> > >
> >> > > Can you please apply these patches, that have been waiting for
> >> so long?
> >> >
> >> > I still can't see this applied anywhere. You already told me to take
> >> > care of it multiple times. Can you please get it done?
> >>
> >> Yes, I'd really like to see a PR at least vs -next at this point so
> >> things aren't lost, thanks!
> >>
> >>
> >> I think that we pick already it so it will happen.
> >
> > I can see patch 1/5 of this series in the nand-next tree. What about the
> > other four patches of this series? Please pick them up, too!
>
> Ping, again! I will just keep on doing this and hope at some point you
> will pick up the patches.

Applied to nand-next.

Loading from squashfs with zstd compression slower than ext4

[Jonathan Liu]

Hi All,

I noticed that loading from squashfs with zstd compression is
significantly slower than ext4 on RK3399 using U-Boot 2022.01. The
filesystem is located on eMMC.

I have CONFIG_BLOCK_CACHE=y in .config and am using the generic load command.

ext4:
15682578 bytes read in 366 ms (40.9 MiB/s)

SquashFS with zstd compression:
15685001 bytes read in 2339 ms (6.4 MiB/s)

Any suggestions on how to speed up loading from SquashFS with zstd compression?

Thanks.

Regards,
Jonathan

[PATCH v2 2/3] dt-bindings: power: add Meson A1 PWRC bindings

[Alexey Romanov]

We can use them in secure pwrc driver.

Signed-off-by: Alexey Romanov 
---
 include/dt-bindings/power/meson-a1-power.h | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 include/dt-bindings/power/meson-a1-power.h

diff --git a/include/dt-bindings/power/meson-a1-power.h 
b/include/dt-bindings/power/meson-a1-power.h
new file mode 100644
index 000..8e39dfc0b62
--- /dev/null
+++ b/include/dt-bindings/power/meson-a1-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ * Author: Alexey Romanov 
+ */
+
+#ifndef _DT_BINDINGS_MESON_A1_POWER_H
+#define _DT_BINDINGS_MESON_A1_POWER_H
+
+#define PWRC_DSPA_ID   8
+#define PWRC_DSPB_ID   9
+#define PWRC_UART_ID   10
+#define PWRC_DMC_ID11
+#define PWRC_I2C_ID12
+#define PWRC_PSRAM_ID  13
+#define PWRC_ACODEC_ID 14
+#define PWRC_AUDIO_ID  15
+#define PWRC_OTP_ID16
+#define PWRC_DMA_ID17
+#define PWRC_SD_EMMC_ID18
+#define PWRC_RAMA_ID   19
+#define PWRC_RAMB_ID   20
+#define PWRC_IR_ID 21
+#define PWRC_SPICC_ID  22
+#define PWRC_SPIFC_ID  23
+#define PWRC_USB_ID24
+#define PWRC_NIC_ID25
+#define PWRC_PDMIN_ID  26
+#define PWRC_RSA_ID27
+#define PWRC_MAX_ID28
+
+#endif
-- 
2.38.1

[PATCH v2 3/3] drivers: meson: introduce secure power controller driver

[Alexey Romanov]

This patch adds Power controller driver support for Amlogic
A1 family using secure monitor calls. The power domains register
only can access in secure world.

Signed-off-by: Alexey Romanov 
---
 drivers/power/domain/Kconfig |   7 +
 drivers/power/domain/Makefile|   1 +
 drivers/power/domain/meson-secure-pwrc.c | 160 +++
 3 files changed, 168 insertions(+)
 create mode 100644 drivers/power/domain/meson-secure-pwrc.c

diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
index 7e1b8c072fa..411c210756a 100644
--- a/drivers/power/domain/Kconfig
+++ b/drivers/power/domain/Kconfig
@@ -68,6 +68,13 @@ config MESON_EE_POWER_DOMAIN
  Enable support for manipulating Amlogic Meson Everything-Else power
  domains.
 
+config MESON_SECURE_POWER_DOMAIN
+   bool "Enable Amlogic Secure power domain driver"
+   depends on POWER_DOMAIN && ARCH_MESON && MESON_A1
+   help
+ Enable support for manipulating Amlogic Meson Secure power domains.
+ Support for Amlogic A1 series.
+
 config SANDBOX_POWER_DOMAIN
bool "Enable the sandbox power domain test driver"
depends on POWER_DOMAIN && SANDBOX
diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
index e6244776216..aa5a4ba57cd 100644
--- a/drivers/power/domain/Makefile
+++ b/drivers/power/domain/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_IMX8MP_HSIOMIX_BLKCTRL) += imx8mp-hsiomix.o
 obj-$(CONFIG_MTK_POWER_DOMAIN) += mtk-power-domain.o
 obj-$(CONFIG_MESON_GX_VPU_POWER_DOMAIN) += meson-gx-pwrc-vpu.o
 obj-$(CONFIG_MESON_EE_POWER_DOMAIN) += meson-ee-pwrc.o
+obj-$(CONFIG_MESON_SECURE_POWER_DOMAIN) += meson-secure-pwrc.o
 obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain.o
 obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain-test.o
 obj-$(CONFIG_TEGRA186_POWER_DOMAIN) += tegra186-power-domain.o
diff --git a/drivers/power/domain/meson-secure-pwrc.c 
b/drivers/power/domain/meson-secure-pwrc.c
new file mode 100644
index 000..f70f8e02423
--- /dev/null
+++ b/drivers/power/domain/meson-secure-pwrc.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ * Author: Alexey Romanov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct meson_secure_pwrc_domain_desc {
+   char *name;
+   size_t index;
+};
+
+struct meson_secure_pwrc_domain_data {
+   unsigned int count;
+   struct meson_secure_pwrc_domain_desc *domains;
+};
+
+struct meson_secure_pwrc_priv {
+   const struct meson_secure_pwrc_domain_data *data;
+};
+
+static int meson_secure_pwrc_on(struct power_domain *power_domain)
+{
+   struct meson_secure_pwrc_priv *priv = dev_get_priv(power_domain->dev);
+   struct meson_secure_pwrc_domain_desc *pwrc_domain;
+   int err;
+
+   pwrc_domain = >data->domains[power_domain->id];
+
+   err = meson_sm_pwrdm_on(pwrc_domain->index);
+   if (err) {
+   pr_err("meson_sm_pwrdm_on() failed (%d)\n", err);
+   return err;
+   }
+
+   pr_debug("enable %s power domain\n", pwrc_domain->name);
+
+   return 0;
+}
+
+static int meson_secure_pwrc_off(struct power_domain *power_domain)
+{
+   struct meson_secure_pwrc_priv *priv = dev_get_priv(power_domain->dev);
+   struct meson_secure_pwrc_domain_desc *pwrc_domain;
+   int err;
+
+   pwrc_domain = >data->domains[power_domain->id];
+
+   err = meson_sm_pwrdm_off(pwrc_domain->index);
+   if (err) {
+   pr_err("meson_sm_pwrdm_off() failed (%d)\n", err);
+   return err;
+   }
+
+   pr_debug("disable %s power domain\n", pwrc_domain->name);
+
+   return 0;
+}
+
+static int meson_secure_pwrc_of_xlate(struct power_domain *power_domain,
+ struct ofnode_phandle_args *args)
+{
+   struct meson_secure_pwrc_priv *priv = dev_get_priv(power_domain->dev);
+   struct meson_secure_pwrc_domain_desc *pwrc_domain;
+
+   if (args->args_count < 1) {
+   pr_err("invalid args count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   power_domain->id = args->args[0];
+
+   if (power_domain->id >= priv->data->count) {
+   pr_err("domain with ID=%lu is invalid\n", power_domain->id);
+   return -EINVAL;
+   }
+
+   pwrc_domain = >data->domains[power_domain->id];
+
+   if (!pwrc_domain->name) {
+   pr_err("domain with ID=%lu is invalid\n", power_domain->id);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+#define SEC_PD(__name) \
+[PWRC_##__name##_ID] = \
+{  \
+   .name = #__name,\
+   .index = PWRC_##__name##_ID,\
+}
+
+static struct meson_secure_pwrc_domain_desc a1_pwrc_domains[] = {
+   SEC_PD(DSPA),
+   SEC_PD(DSPB),
+   SEC_PD(UART),
+   SEC_PD(DMC),
+   

[PATCH v2 1/3] arch/arm: meson: sm: introduce power domain functions

[Alexey Romanov]

This commit adds functions to manage secure power domain for
Amlogic SoC's using smc functionality.

Signed-off-by: Alexey Romanov 
Reviewed-by: Neil Armstrong 
---
 arch/arm/include/asm/arch-meson/sm.h | 30 
 arch/arm/mach-meson/sm.c | 14 +
 2 files changed, 44 insertions(+)

diff --git a/arch/arm/include/asm/arch-meson/sm.h 
b/arch/arm/include/asm/arch-meson/sm.h
index 53b75176493..4b1d564bc48 100644
--- a/arch/arm/include/asm/arch-meson/sm.h
+++ b/arch/arm/include/asm/arch-meson/sm.h
@@ -58,4 +58,34 @@ enum {
  */
 int meson_sm_get_reboot_reason(void);
 
+#define PWRDM_OFF 0
+#define PWRDM_ON 1
+
+/**
+ * meson_sm_pwrdm_set - do command at specified power domain.
+ *
+ * @index: power domain index.
+ * @cmd: command index.
+ * @return: zero on success or error code on failure.
+ */
+int meson_sm_pwrdm_set(size_t index, int cmd);
+
+/**
+ * meson_sm_pwrdm_off - disable specified power domain.
+ *
+ * @index: power domain index.
+ * @return: zero on success or error code on failure.
+ */
+#define meson_sm_pwrdm_off(index) \
+   meson_sm_pwrdm_set(index, PWRDM_OFF)
+
+/**
+ * meson_sm_pwrdm_on - enable specified power domain.
+ *
+ * @index: power domain index.
+ * @return: zero on success or error code on failure.
+ */
+#define meson_sm_pwrdm_on(index) \
+   meson_sm_pwrdm_set(index, PWRDM_ON)
+
 #endif /* __MESON_SM_H__ */
diff --git a/arch/arm/mach-meson/sm.c b/arch/arm/mach-meson/sm.c
index f2ca7e76932..d600c64d0be 100644
--- a/arch/arm/mach-meson/sm.c
+++ b/arch/arm/mach-meson/sm.c
@@ -24,6 +24,7 @@
 #define FN_EFUSE_READ  0x8230
 #define FN_EFUSE_WRITE 0x8231
 #define FN_CHIP_ID 0x8244
+#define FN_PWRDM_SET   0x8293
 
 static void *shmem_input;
 static void *shmem_output;
@@ -137,3 +138,16 @@ int meson_sm_get_reboot_reason(void)
/* The SMC call is not used, we directly use AO_SEC_SD_CFG15 */
return FIELD_GET(REBOOT_REASON_MASK, reason);
 }
+
+int meson_sm_pwrdm_set(size_t index, int cmd)
+{
+   struct pt_regs regs;
+
+   regs.regs[0] = FN_PWRDM_SET;
+   regs.regs[1] = index;
+   regs.regs[2] = cmd;
+
+   smc_call();
+
+   return regs.regs[0];
+}
-- 
2.38.1

[PATCH v2 0/3] Meson Secure PWRC Driver

[Alexey Romanov]

Hello!

This patch set adds support (driver and sm functions) for working with
power domain controller using secure monitor for Amlogic A1-series.
Additionally, in the future, the driver can be used for other Amlgoic
SoC series, such as S4.

Changes v1 -> v2:

* Move dt-bindings into separate patch.
* Drop 'move pwrc node to bus' patch.

Alexey Romanov (3):
  arch/arm: meson: sm: introduce power domain functions
  dt-bindings: power: add Meson A1 PWRC bindings
  drivers: meson: introduce secure power controller driver

 arch/arm/include/asm/arch-meson/sm.h   |  30 
 arch/arm/mach-meson/sm.c   |  14 ++
 drivers/power/domain/Kconfig   |   7 +
 drivers/power/domain/Makefile  |   1 +
 drivers/power/domain/meson-secure-pwrc.c   | 160 +
 include/dt-bindings/power/meson-a1-power.h |  32 +
 6 files changed, 244 insertions(+)
 create mode 100644 drivers/power/domain/meson-secure-pwrc.c
 create mode 100644 include/dt-bindings/power/meson-a1-power.h

-- 
2.38.1

Re: BTRFS Support btrload, btrls

[Jonathan Liu]

Hi Ottinger,

Perhaps you can enable CONFIG_CMD_FS_GENERIC=y in your config and try
to use the generic commands - size, load, save, ls, ln, fstype,
fstypes?

Regards,
Jonathan

On Tue, 30 May 2023 at 22:07, Ottinger Georg  wrote:
>
>
> Hi Everybody,
>
> I am currently evaluating filesystems that can be used reliable on eMMC 
> storage, which support transparent compression.
>
> I see that U-Boot supports btrfs. But I don't understand how to load for 
> example a kernel image from the fs, I was expecting 'btrload' as an analog to 
> 'ext4load' or 'fatload'.
>
> Is there a reason why this commands are not implemented?
>
> When I do patch the file cmd/btfs.c to add 'btrload' I do get a working 
> U-Boot capable of loading DT and kernal image from btrfs.
>
> '''
> char subvolname[1];
>
> int do_btr_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
>
> subvolname[0] = '\0';
>
> return do_load(cmdtp, flag, argc, argv, FS_TYPE_BTRFS);
> }
>
>
> U_BOOT_CMD(
> btrload,7,  0,  do_btr_fsload,
> "load binary file from a btr filesystem",
> " []   \n"
> "- Load binary file 'filename' from 'dev' on 'interface'\n"
> "  to address 'addr' from better filesystem.\n"
> "  the load stops on end of file.\n"
> "  All numeric parameters are assumed to be hex."
> );
> '''
>
> Are there any known stability issues, why 'btrload' and 'btrfs' are not 
> included in the current U-Boot?
> Or is there an alternative to 'btrload' to load a kernelimage from fs to ram?
>
> thanks,
> Georg
>
>
> Georg Ottinger
>
> Software Engineer
>
> RESEARCH & DEVELOPMENT
>
> ABATEC GmbH
>
> [https://abatec.at/email/phone.jpg]
>
> +43767227720532
>
> [https://abatec.at/email/email.jpg]
>
> g.ottin...@abatec.at
>
> [https://abatec.at/email/site.jpg]
>
> www.abatec.at
>
> [https://abatec.at/email/location.jpg]
>
> Oberregauer Straße 48, 4844 Regau
>
> [cid:1d2b374d-7ca8-4b52-8b3c-319d1b53c9aa]
>
>
>
> UID-Nr.: ATU67696059  Firmenbuchnummer: FN 390305d  Firmenbuchgericht: Wels
>

Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation

[Frieder Schrempf]

On 17.05.23 09:43, Frieder Schrempf wrote:
> Hi Michael, hi Dario,
> 
> On 15.05.23 23:33, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> Il lun 15 mag 2023, 23:12 Tom Rini > > ha scritto:
>>
>> On Tue, May 09, 2023 at 09:09:28AM +0200, Frieder Schrempf wrote:
>> > Hi Michael, hi Dario,
>> >
>> > On 18.04.23 15:46, Frieder Schrempf wrote:
>> > > Hi Michael, Dario,
>> > >
>> > > On 28.03.23 09:57, Frieder Schrempf wrote:
>> > >> Hi Michael,
>> > >>
>> > >> On 10.02.23 12:57, Michael Nazzareno Trimarchi wrote:
>> > >>> Hi
>> > >>>
>> > >>> I will review
>> > >>>
>> > >>> On Thu, Feb 9, 2023 at 5:52 PM Tom Rini > > wrote:
>> > 
>> >  On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote:
>> > > Hi,
>> > >
>> > > On 10.01.23 12:58, Frieder Schrempf wrote:
>> > >> From: Mikhail Kshevetskiy > >
>> > >>
>> > >> Currently there are 3 different variants of read_id
>> implementation:
>> > >> 1. opcode only. Found in GD5FxGQ4xF.
>> > >> 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E
>> > >> 3. opcode + 1 dummy byte. Found in other currently
>> supported chips.
>> > >>
>> > >> Original implementation was for variant 1 and let detect
>> function
>> > >> of chips with variant 2 and 3 to ignore the first byte.
>> This isn't
>> > >> robust:
>> > >>
>> > >> 1. For chips of variant 2, if SPI master doesn't keep MOSI low
>> > >> during read, chip will get a random id offset, and the
>> entire id
>> > >> buffer will shift by that offset, causing detect failure.
>> > >>
>> > >> 2. For chips of variant 1, if it happens to get a devid
>> that equals
>> > >> to manufacture id of variant 2 or 3 chips, it'll get
>> incorrectly
>> > >> detected.
>> > >>
>> > >> This patch reworks detect procedure to address problems
>> above. New
>> > >> logic do detection for all variants separatedly, in 1-2-3
>> order.
>> > >> Since all current detect methods do exactly the same id
>> matching
>> > >> procedure, unify them into core.c and remove detect method from
>> > >> manufacture_ops.
>> > >>
>> > >> This is a rework of Chuanhong Guo > > patch
>> > >> submitted to linux kernel
>> > >>
>> > >> Signed-off-by: Mikhail Kshevetskiy
>> mailto:mikhail.kshevets...@iopsys.eu>>
>> > >> Signed-off-by: Frieder Schrempf
>> mailto:frieder.schre...@kontron.de>>
>> > >
>> > > +Cc: Jagan, Tom
>> > >
>> > > Who is supposed to pick up these patches? Some of them have
>> been around
>> > > for some months (before I resent them).
>> > >
>> > > There is no maintainer for drivers/mtd/spinand/ and no
>> maintainer for
>> > > drivers/mtd/ in general.
>> > >
>> > > In Patchwork Jagan got assigned, but the get_maintainer.pl
>>  script didn't
>> > > even add him to Cc, of course.
>> > >
>> > > Any ideas how to proceed?
>> > 
>> >  We don't have anyone dedicated to that area, yes, sadly. I've
>> added
>> >  Michael and Dario as they've also been doing mtd-but-not-spi
>> work of
>> >  late to see if they're interested. Or since you've long been
>> working
>> >  here, would you like to more formally maintain the area? Thanks!
>> > >>>
>> > >>> They can come from our tree. I will try to sort out all my
>> duties weeked
>> > >>
>> > >> Any news regarding reviewing/picking these patches?
>> > >
>> > > Ping!
>> > >
>> > > Can you please apply these patches, that have been waiting for
>> so long?
>> >
>> > I still can't see this applied anywhere. You already told me to take
>> > care of it multiple times. Can you please get it done?
>>
>> Yes, I'd really like to see a PR at least vs -next at this point so
>> things aren't lost, thanks!
>>
>>
>> I think that we pick already it so it will happen.
> 
> I can see patch 1/5 of this series in the nand-next tree. What about the
> other four patches of this series? Please pick them up, too!

Ping, again! I will just keep on doing this and hope at some point you
will pick up the patches.

Re: [PATCH v2 3/3] drivers: meson: introduce secure power controller driver

[neil . armstrong]

On 31/05/2023 11:31, Alexey Romanov wrote:

This patch adds Power controller driver support for Amlogic
A1 family using secure monitor calls. The power domains register
only can access in secure world.

Signed-off-by: Alexey Romanov 
---
  drivers/power/domain/Kconfig |   7 +
  drivers/power/domain/Makefile|   1 +
  drivers/power/domain/meson-secure-pwrc.c | 160 +++
  3 files changed, 168 insertions(+)
  create mode 100644 drivers/power/domain/meson-secure-pwrc.c

diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
index 7e1b8c072fa..411c210756a 100644
--- a/drivers/power/domain/Kconfig
+++ b/drivers/power/domain/Kconfig
@@ -68,6 +68,13 @@ config MESON_EE_POWER_DOMAIN
  Enable support for manipulating Amlogic Meson Everything-Else power
  domains.
  
+config MESON_SECURE_POWER_DOMAIN

+   bool "Enable Amlogic Secure power domain driver"
+   depends on POWER_DOMAIN && ARCH_MESON && MESON_A1
+   help
+ Enable support for manipulating Amlogic Meson Secure power domains.
+ Support for Amlogic A1 series.
+
  config SANDBOX_POWER_DOMAIN
bool "Enable the sandbox power domain test driver"
depends on POWER_DOMAIN && SANDBOX
diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
index e6244776216..aa5a4ba57cd 100644
--- a/drivers/power/domain/Makefile
+++ b/drivers/power/domain/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_IMX8MP_HSIOMIX_BLKCTRL) += imx8mp-hsiomix.o
  obj-$(CONFIG_MTK_POWER_DOMAIN) += mtk-power-domain.o
  obj-$(CONFIG_MESON_GX_VPU_POWER_DOMAIN) += meson-gx-pwrc-vpu.o
  obj-$(CONFIG_MESON_EE_POWER_DOMAIN) += meson-ee-pwrc.o
+obj-$(CONFIG_MESON_SECURE_POWER_DOMAIN) += meson-secure-pwrc.o
  obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain.o
  obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain-test.o
  obj-$(CONFIG_TEGRA186_POWER_DOMAIN) += tegra186-power-domain.o
diff --git a/drivers/power/domain/meson-secure-pwrc.c 
b/drivers/power/domain/meson-secure-pwrc.c
new file mode 100644
index 000..f70f8e02423
--- /dev/null
+++ b/drivers/power/domain/meson-secure-pwrc.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ * Author: Alexey Romanov 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct meson_secure_pwrc_domain_desc {
+   char *name;
+   size_t index;
+};
+
+struct meson_secure_pwrc_domain_data {
+   unsigned int count;
+   struct meson_secure_pwrc_domain_desc *domains;
+};
+
+struct meson_secure_pwrc_priv {
+   const struct meson_secure_pwrc_domain_data *data;
+};
+
+static int meson_secure_pwrc_on(struct power_domain *power_domain)
+{
+   struct meson_secure_pwrc_priv *priv = dev_get_priv(power_domain->dev);
+   struct meson_secure_pwrc_domain_desc *pwrc_domain;
+   int err;
+
+   pwrc_domain = >data->domains[power_domain->id];
+
+   err = meson_sm_pwrdm_on(pwrc_domain->index);
+   if (err) {
+   pr_err("meson_sm_pwrdm_on() failed (%d)\n", err);
+   return err;
+   }
+
+   pr_debug("enable %s power domain\n", pwrc_domain->name);
+
+   return 0;
+}
+
+static int meson_secure_pwrc_off(struct power_domain *power_domain)
+{
+   struct meson_secure_pwrc_priv *priv = dev_get_priv(power_domain->dev);
+   struct meson_secure_pwrc_domain_desc *pwrc_domain;
+   int err;
+
+   pwrc_domain = >data->domains[power_domain->id];
+
+   err = meson_sm_pwrdm_off(pwrc_domain->index);
+   if (err) {
+   pr_err("meson_sm_pwrdm_off() failed (%d)\n", err);
+   return err;
+   }
+
+   pr_debug("disable %s power domain\n", pwrc_domain->name);
+
+   return 0;
+}
+
+static int meson_secure_pwrc_of_xlate(struct power_domain *power_domain,
+ struct ofnode_phandle_args *args)
+{
+   struct meson_secure_pwrc_priv *priv = dev_get_priv(power_domain->dev);
+   struct meson_secure_pwrc_domain_desc *pwrc_domain;
+
+   if (args->args_count < 1) {
+   pr_err("invalid args count: %d\n", args->args_count);
+   return -EINVAL;
+   }
+
+   power_domain->id = args->args[0];
+
+   if (power_domain->id >= priv->data->count) {
+   pr_err("domain with ID=%lu is invalid\n", power_domain->id);
+   return -EINVAL;
+   }
+
+   pwrc_domain = >data->domains[power_domain->id];
+
+   if (!pwrc_domain->name) {
+   pr_err("domain with ID=%lu is invalid\n", power_domain->id);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+#define SEC_PD(__name) \
+[PWRC_##__name##_ID] = \
+{  \
+   .name = #__name,\
+   .index = PWRC_##__name##_ID,\
+}
+
+static struct meson_secure_pwrc_domain_desc a1_pwrc_domains[] = {
+   SEC_PD(DSPA),
+   

Re: [PATCH v2 2/3] dt-bindings: power: add Meson A1 PWRC bindings

[neil . armstrong]

On 31/05/2023 11:31, Alexey Romanov wrote:

We can use them in secure pwrc driver.

Signed-off-by: Alexey Romanov 
---
  include/dt-bindings/power/meson-a1-power.h | 32 ++
  1 file changed, 32 insertions(+)
  create mode 100644 include/dt-bindings/power/meson-a1-power.h

diff --git a/include/dt-bindings/power/meson-a1-power.h 
b/include/dt-bindings/power/meson-a1-power.h
new file mode 100644
index 000..8e39dfc0b62
--- /dev/null
+++ b/include/dt-bindings/power/meson-a1-power.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */
+/*
+ * Copyright (c) 2023 SberDevices, Inc.
+ * Author: Alexey Romanov 
+ */
+
+#ifndef _DT_BINDINGS_MESON_A1_POWER_H
+#define _DT_BINDINGS_MESON_A1_POWER_H
+
+#define PWRC_DSPA_ID   8
+#define PWRC_DSPB_ID   9
+#define PWRC_UART_ID   10
+#define PWRC_DMC_ID11
+#define PWRC_I2C_ID12
+#define PWRC_PSRAM_ID  13
+#define PWRC_ACODEC_ID 14
+#define PWRC_AUDIO_ID  15
+#define PWRC_OTP_ID16
+#define PWRC_DMA_ID17
+#define PWRC_SD_EMMC_ID18
+#define PWRC_RAMA_ID   19
+#define PWRC_RAMB_ID   20
+#define PWRC_IR_ID 21
+#define PWRC_SPICC_ID  22
+#define PWRC_SPIFC_ID  23
+#define PWRC_USB_ID24
+#define PWRC_NIC_ID25
+#define PWRC_PDMIN_ID  26
+#define PWRC_RSA_ID27
+#define PWRC_MAX_ID28
+
+#endif


Reviewed-by: Neil Armstrong 

Re: [PATCH] test: fix unit test build error for crc8

[Heinrich Schuchardt]

On 5/30/23 17:39, ghidoliemanu...@gmail.com wrote:

From: Emanuele Ghidoli 

Build fail due to ENOSYS undeclared if CONFIG_SANDBOX_SDL is not defined.
Include errno.h before including test/lib.h.

Fixes: 3080ddf970b1 ("test: unit test for crc8")
Signed-off-by: Emanuele Ghidoli 
---
  test/lib/test_crc8.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/test/lib/test_crc8.c b/test/lib/test_crc8.c
index 0dac97bc5bfd..5037db806d09 100644
--- a/test/lib/test_crc8.c
+++ b/test/lib/test_crc8.c
@@ -5,6 +5,7 @@
   * Unit test for crc8
   */

+#include 
  #include 
  #include 
  #include 


Thank you for reporting the issue. Unfortunately this patch seems to add
a change in the wrong place:

For sandbox_defconfig with CONFIG_SANDBOX_SDL=n I get:

In file included from include/test/test.h:156,
 from include/test/lib.h:9,
 from test/lib/test_crc8.c:8:
./arch/sandbox/include/asm/test.h: In function ‘sandbox_sdl_set_bpp’:
  CC  lib/libavb/avb_util.o
./arch/sandbox/include/asm/test.h:323:17: error: ‘ENOSYS’ undeclared
(first use in this function)
  323 | return -ENOSYS;
  | ^~
./arch/sandbox/include/asm/test.h:323:17: note: each undeclared
identifier is reported only once for each function it appears in

The file to fix is /arch/sandbox/include/asm/test.h which uses ENOSYS
without declaring it.

Please, update your patch and add a line
Fixes: 67a36465216a ("sandbox: video: Fix building without SDL")

Best regards

Heinrich

[PATCH 1/1] test: bootflow test depends on CONFIG_VIDEO

[Heinrich Schuchardt]

qemu_arm64_defconfig with UNIT_TEST=y does not build.

CONFIG_EXPO depends on CONFIG_VIDEO. Hence on platforms without video we
must not enable unit tests invoking expo functions.

Fixes: fb1451bec2a5 ("bootstd: Add tests for bootstd including all uclasses")
Signed-off-by: Heinrich Schuchardt 
---
 test/boot/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/test/boot/Makefile b/test/boot/Makefile
index 22ed61c8fa..665017ba3d 100644
--- a/test/boot/Makefile
+++ b/test/boot/Makefile
@@ -2,7 +2,10 @@
 #
 # Copyright 2021 Google LLC
 
-obj-$(CONFIG_BOOTSTD) += bootdev.o bootstd_common.o bootflow.o bootmeth.o
+ifdef CONFIG_BOOTSTD
+obj-y += bootstd_common.o bootmeth.o
+obj-$(VIDEO) += bootdev.o bootflow.o
+endif
 obj-$(CONFIG_FIT) += image.o
 
 obj-$(CONFIG_EXPO) += expo.o
-- 
2.39.2

Re: [PATCH 1/1] python: Update requirements.txt for security issues

[Heinrich Schuchardt]

On 5/30/23 21:50, Tom Rini wrote:

Per GitHub Dependabot:
- Use setuptools 65.5.1 to avoid some DoS issue
- Use requests 2.31.0 to avoid leaking some proxy information

Signed-off-by: Tom Rini 


Documentation builds fine with the patch.

Tested-by: Heinrich Schuchardt 


---
Cc: Simon Glass 
Cc: Heinrich Schuchardt 
---
  doc/sphinx/requirements.txt | 2 +-
  test/py/requirements.txt| 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt
index f9f6cc6e928b..aed449211711 100644
--- a/doc/sphinx/requirements.txt
+++ b/doc/sphinx/requirements.txt
@@ -11,7 +11,7 @@ packaging==21.3
  Pygments==2.11.2
  pyparsing==3.0.7
  pytz==2022.1
-requests==2.27.1
+requests==2.31.0
  six==1.16.0
  snowballstemmer==2.2.0
  Sphinx==3.4.3
diff --git a/test/py/requirements.txt b/test/py/requirements.txt
index 86d6266053fd..f7e76bdb9181 100644
--- a/test/py/requirements.txt
+++ b/test/py/requirements.txt
@@ -20,8 +20,8 @@ pytest==6.2.5
  pytest-xdist==2.5.0
  python-mimeparse==1.6.0
  python-subunit==1.3.0
-requests==2.27.1
-setuptools==58.3.0
+requests==2.31.0
+setuptools==65.5.1
  six==1.16.0
  testtools==2.3.0
  traceback2==1.4.0

Re: [PATCH] efi_loader: explicitly return EFI_UNSUPPORTED for TCG 1.0 compatibility

[Ilias Apalodimas]

Hi Stuart,

On Wed, 31 May 2023 at 00:20, Stuart Yoder  wrote:
>
>
>
> On 5/30/23 1:39 AM, Ilias Apalodimas wrote:
> > In the EFI TCG spec EFI_TCG2_BOOT_SERVICE_CAPABILITY struct is
> > versioned -- there are 1.0 and 1.1 versions of that struct.
> > The spec [0] describes:
> > "Version of the EFI_TCG2_BOOT_SERVICE_CAPABILITY
> > structure itself. For this version of the protocol, the Major version
> > SHALL be set to 1 and the Minor version SHALL be set to 1."
> > which is what we currently support.
> >
> > The SCT tests perfromed By Arms SIE(Security interface extensions) [1]
> > perform a check for clients supporting the older 1.0 version of the
> > spec (Test 30.1.1.4). Given than this spec is 7 years old,  there should
> > be no need for the older 1.0 version support.  Instead of returning
> > EFI_BUFFER_TOO_SMALLL switch to EFI_UNSUPPORTED which is more
> > appropriate.  It's worth noting that the spec doesn't explicitly
> > describe the return value at the moment.
> >
> > [0] 
> > https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specification-rev13-160330final.pdf
> > [1] 
> > https://github.com/stuyod01/edk2-test/blob/master/uefi-sct/Doc/UEFI-SCT-Case-Spec/30_Protocols_TCG2_Test.md
> >
> > Signed-off-by: Ilias Apalodimas 
> > ---
> >
> > Heinrich,  Stuart is investigating the chance of the spec getting updated
> > adding EFI_UNSUPPORTED.  In any case I think the patch should be aplied 
> > since
> > the new return code makes more sense.  If for some reason the spec change is
> > rejected, I can go back and add support for 1.0 structure versions.
> >
> >   lib/efi_loader/efi_tcg2.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> > index a83ae7a46cf3..220c442bdf93 100644
> > --- a/lib/efi_loader/efi_tcg2.c
> > +++ b/lib/efi_loader/efi_tcg2.c
> > @@ -750,7 +750,7 @@ efi_tcg2_get_capability(struct efi_tcg2_protocol *this,
> >
> >   if (capability->size < sizeof(*capability)) {
> >   capability->size = sizeof(*capability);
> > - efi_ret = EFI_BUFFER_TOO_SMALL;
> > + efi_ret = EFI_UNSUPPORTED;
> >   goto out;
> >   }
>
> Hi Ilias,
>
> I don't think this is the right fix.
>
> The struct looks like this:
>
> struct tdEFI_TCG2_BOOT_SERVICE_CAPABILITY {
>UINT8 Size;
>EFI_TCG2_VERSION StructureVersion;
>EFI_TCG2_VERSION ProtocolVersion;
>EFI_TCG2_EVENT_ALGORITHM_BITMAP HashAlgorithmBitmap
>EFI_TCG2_EVENT_LOG_BITMAP SupportedEventLogs
>BOOLEAN TPMPresentFlag
>UINT16 MaxCommandSize
>UINT16 MaxResponseSize
>UINT32 ManufacturerID
>UINT32 NumberOfPcrBanks
>EFI_TCG2_EVENT_ALGORITHM_BITMAP ActivePcrBanks
> };
>
> The intent in the TCG spec is for the caller to be able to
> determine the size of the struct by passing in a small
> buffer (e.g. 1 byte buffer), and then the firmware
> should return sizeof(EFI_TCG2_BOOT_SERVICE_CAPABILITY) in the
> 1-byte "Size" field.  And the return value should be
> EFI_BUFFER_TOO_SMALL as per the spec.
>
> In order to detect a 1.0 client, which you don't want to support,
> I think you need a _new_ check that is something like this:
>
> // detect 1.0 client
> if (capability->size < sizeof(*capability) &&
>  capability->size >= offsetof(EFI_TCG2_BOOT_SERVICE_CAPABILITY,
> NumberOfPcrBanks)) {
>  efi_ret = EFI_UNSUPPORTED;
>  goto out;
> }
>
> The last field in the 1.0 struct was ManufacturerID, so you should
> be able to detect 1.0 clients that expect that based on the size they
> pass in.

The patch doesn't show the entire u-boot code there and is a bit misleading.
There's another check that precedes the one I am patching, which if I
am reading it correctly does exactly what you describe

#define BOOT_SERVICE_CAPABILITY_MIN \
  offsetof(struct efi_tcg2_boot_service_capability, number_of_pcr_banks)
if (capability->size < BOOT_SERVICE_CAPABILITY_MIN) {
  capability->size = BOOT_SERVICE_CAPABILITY_MIN;
  efi_ret = EFI_BUFFER_TOO_SMALL;
  goto out;
}

Thanks
/Ilias
>
> Thanks,
> Stuart

Re: [RFC PATCH 1/1] arm: add invalidate_dcache_all() after disable cache

[Heinrich Schuchardt]

On 5/31/23 00:08, Emanuele Ghidoli wrote:

From: Emanuele Ghidoli 

On Cortex-R5 flushing and disabling cache is not enough to avoid
cache and memory incoherence.

In particular, when the cache is enabled after a disable, and if there
are entry in the cache the value from the cache is used instead of the
value from the memory. This, in particular, lead to stack corruption if
the stack is in a cached area.

The commit 44df5e8d30a2 ("arm: move flush_dcache_all() to just before disable 
cache")
already states that following a cache disable an invalidate is expected
to be done but without coping with cache enable. So just add it explicitly.

Signed-off-by: Emanuele Ghidoli 
---
  arch/arm/lib/cache-cp15.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 0893915b3004..2921277d69e0 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -254,7 +254,15 @@ static void cache_disable(uint32_t cache_bit)
if (cache_bit == CR_C)
  #endif
flush_dcache_all();
+
set_cr(reg & ~cache_bit);
+
+#ifdef CONFIG_SYS_ARM_MMU
+   if (cache_bit == (CR_C | CR_M))
+#elif defined(CONFIG_SYS_ARM_MPU)
+   if (cache_bit == CR_C)
+#endif


We prefer 'if' over '#ifdef'. So you should use something like:

if (IS_ENABLED(CONFIG_SYS_ARM_MMU) && (cache_bit == (CR_C | CR_M) ||
IS_ENABLED(CONFIG_SYS_ARM_MPU) && (cache_bit == CR_C)) {
flush_dcache_all();
invalidate_dcache_all();
}
set_cr(reg & ~cache_bit);

(Assuming set_cr() can be called after invalidate_dcache_all.)

Best regards

Heinrich


+   invalidate_dcache_all();
  }
  #endif

[PATCH 2/2] serial: stm32: BRR must be set only when usart is disable

[Patrice Chotard]

To avoid spurious chars, BRR register must only be written when
USART is disabled.

Signed-off-by: Patrice Chotard 
---

 drivers/serial/serial_stm32.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c
index 93f70947eec..0085113f674 100644
--- a/drivers/serial/serial_stm32.c
+++ b/drivers/serial/serial_stm32.c
@@ -29,6 +29,10 @@ static void _stm32_serial_setbrg(fdt_addr_t base,
 {
bool stm32f4 = uart_info->stm32f4;
u32 int_div, mantissa, fraction, oversampling;
+   u8 uart_enable_bit = uart_info->uart_enable_bit;
+
+   /* BRR register must be set when uart is disabled */
+   clrbits_le32(base + CR1_OFFSET(stm32f4), BIT(uart_enable_bit));
 
int_div = DIV_ROUND_CLOSEST(clock_rate, baudrate);
 
@@ -44,6 +48,8 @@ static void _stm32_serial_setbrg(fdt_addr_t base,
fraction = int_div % oversampling;
 
writel(mantissa | fraction, base + BRR_OFFSET(stm32f4));
+
+   setbits_le32(base + CR1_OFFSET(stm32f4), BIT(uart_enable_bit));
 }
 
 static int stm32_serial_setbrg(struct udevice *dev, int baudrate)
-- 
2.25.1