Re: ECDSA related PRs

[Dan Carpenter]

On Thu, Feb 22, 2024 at 03:07:01PM -0800, Bob Wolff wrote:
> Peter,
> Thanks for helping lead me down the right path here.
> 
> WRT tinycrypt, the license is quite permissive.
> https://github.com/intel/tinycrypt
> 
> Also, I'd like your advice - I was thinking for the larger patch that I'd
> do it in two commits. The first would be the addition of the tinycrypt
> files and the second is the actual changes and additions to support ecdsa
> verification. I doubt that's controversial. However when I run a trial
> `patman` against the tinycrypt commit, I geta huge number of issues:
> *checkpatch.pl  found 186 error(s), 380
> warning(s), 481 checks(s)*
> 
> What's your advice on this? I would tend to think we'd want to /not/ change
> the source files directly for such purposes so that updates could be
> brought in with greater ease.

Yeah.  For this kind of thing you wouldn't want to make a bunch of
checkpatch changes.  They sometimes pull crypto and compression
libraries into the Linux kernel pretty much unmodified as well for the
same reason.

Igor's proposal about pull this stuff from the Linux kernel instead
seems like a good idea though.

regards,
dan carpenter

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Sumit Garg]

On Wed, 28 Feb 2024 at 20:50, Tom Rini  wrote:
>
> On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> > + Shawn, Krzysztof, Conor
> >
> > Hi Tom,
> >
> > On Wed, 28 Feb 2024 at 18:40, Tom Rini  wrote:
> > >
> > > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with
> > > > > linux") removed the display timings from the board device tree whereas
> > > > > they are still needed by the mxsfb driver.
> > > > > Add the timings back (the correct ones) in the
> > > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > > opos6uldev.env file.
> > > > >
> > > > > Update the opos6uldev_defconfig file so that the LCD turns on at boot.
> > > > >
> > > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with 
> > > > > linux")
> > > > > Signed-off-by: Sébastien Szymanski 
> > > >
> > > > Huh.  This is the commit that did that upstream.
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > > >
> > > > It's interesting how the timings in linux were always slightly different
> > > > from in u-boot.
> > >
> > > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> > > because this is a recent (rather than ancient) example of one of the
> > > concerns about OF_UPSTREAM.
> >
> > I rather think about this as an opportunity to improve with
> > OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> > corresponding Linux kernel sub-arch maintainers. Especially once we
> > move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
> > to keep them aware that U-Boot should be considered too.
>
> Yes, a more extensive check around when removing information from dts
> files would be good.
>
> > > I think the commit in question can be
> > > summarized as "remove a bunch of explicit HW information because there's
> > > now a Linux Kernel driver that determines that dynamically". What do we
> > > do next? The old information is in a presumably valid binding still, can
> > > we just put it back and comment that consumers outside of Linux use this
> > > still so it's not removed again later? Or am I just missing where we can
> > > instead get this information from the DT still and not need to come up
> > > with a new driver and subsystems?
> >
> > I can see following two paths forward:
> >
> > 1) Partially revert the Linux kernel commit to add back the display
> > timings in DT.
> > 2) Extend drivers/video/simple_panel.c in U-Boot to add support for
> > compatible: "armadeus,st0700-adapt".
> >
> > If possible then I would be in favour of (2) rather than the current
> > patch to do this properly.
>
> Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
> and then our drivers/video/simple_panel.c it sure would be nice if it's
> just a matter of adding a compatible but I wouldn't be surprised if it
> ends up needing more information being passed along too?

Although I am not a LCD panel expert but looking at the kernel driver
code [1], the display timings are rather taken from a static data
structure matching the compatible "armadeus,st0700-adapt".

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c#n901

> And I'm going
> assume there's good reasons for the design change in how the drivers
> work in Linux now and note that it might make things more challenging
> for us when we do care about space.

I agree it is always going to be challenging to use DT during SPL
stage which is mostly constrained by limited on-chip RAM.

-Sumit

>
> --
> Tom

Re: [PATCH v2 6/8] pci: Add DW PCIe controller support for iMX8MP SoC

[Sumit Garg]

On Wed, 28 Feb 2024 at 22:07, Tim Harvey  wrote:
>
> On Tue, Feb 27, 2024 at 3:19 PM Adam Ford  wrote:
> >
> > On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg  wrote:
> > >
> > > pcie_imx doesn't seem to share any useful code for iMX8 SoC and it is
> > > tied to quite old port of pcie_designware driver from Linux which
> > > suffices only iMX6 specific needs.
> > >
> > > But currently we have the common DWC specific bits which alligns pretty
> > > well with DW PCIe controller on iMX8MP SoC. So lets reuse those common
> > > bits instead as a new driver for iMX8 SoCs. It should be fairly easy to
> > > add support for other iMX8 variants to this driver.
> > >
> > > iMX8MP SoC also comes up with standalone PCIe PHY support, so hence we
> > > can reuse the generic PHY infrastructure to power on PCIe PHY.
> > >
> > > Signed-off-by: Sumit Garg 
> > > ---
> > >  drivers/pci/Kconfig   |   8 +
> > >  drivers/pci/Makefile  |   1 +
> > >  drivers/pci/pcie_dw_imx.c | 314 ++
> > >  3 files changed, 323 insertions(+)
> > >  create mode 100644 drivers/pci/pcie_dw_imx.c
> > >
> > > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> > > index 463ec47eb92d..7edbf35004a9 100644
> > > --- a/drivers/pci/Kconfig
> > > +++ b/drivers/pci/Kconfig
> > > @@ -413,4 +413,12 @@ config PCIE_STARFIVE_JH7110
> > >   Say Y here if you want to enable PLDA XpressRich PCIe controller
> > >   support on StarFive JH7110 SoC.
> > >
> > > +config PCIE_DW_IMX
> > > +   bool "i.MX DW PCIe controller support"
> > > +   depends on ARCH_IMX8M
> >
> > I think this also needs to depend on REGMAP to prevent build errors.
> >
>
> Sumit,
>
> both REGMAP and SYSCON are needed to build.
>

Ack.

-Sumit

Re: [RFC PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board

[Neha Malcom Francis]

Hi Andrew

On 28/02/24 20:41, Andrew Davis wrote:

On 2/28/24 5:20 AM, Neha Malcom Francis wrote:

Add defconfig for J721E SK R5 and A72 configuration.

This includes and modifies the J721E EVM defconfigs:
j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig
j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig

Signed-off-by: Neha Malcom Francis 
---
  board/ti/j721e/MAINTAINERS  | 2 ++
  configs/j721e_evm_a72_defconfig | 2 +-
  configs/j721e_evm_r5_defconfig  | 2 +-
  configs/j721e_sk_a72_defconfig  | 4 
  configs/j721e_sk_r5_defconfig   | 5 +
  5 files changed, 13 insertions(+), 2 deletions(-)
  create mode 100644 configs/j721e_sk_a72_defconfig
  create mode 100644 configs/j721e_sk_r5_defconfig

diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS
index f5ca7d06a34..06aba53d9b0 100644
--- a/board/ti/j721e/MAINTAINERS
+++ b/board/ti/j721e/MAINTAINERS
@@ -5,5 +5,7 @@ F:    board/ti/j721e
  F:    include/configs/j721e_evm.h
  F:    configs/j721e_evm_r5_defconfig
  F:    configs/j721e_evm_a72_defconfig
+F:    configs/j721e_sk_r5_defconfig
+F:    configs/j721e_sk_a72_defconfig
  F:    configs/j7200_evm_r5_defconfig
  F:    configs/j7200_evm_a72_defconfig
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 74af5bebb51..21081a2a684 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -86,7 +86,7 @@ CONFIG_MMC_SPEED_MODE_SET=y
  # CONFIG_SPL_EFI_PARTITION is not set
  CONFIG_OF_CONTROL=y
  CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk"
+CONFIG_OF_LIST="k3-j721e-common-proc-board"
  CONFIG_MULTI_DTB_FIT=y
  CONFIG_SPL_MULTI_DTB_FIT=y
  CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index bc4f35cce11..ce2b7df58cf 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -81,7 +81,7 @@ CONFIG_CMD_MTDPARTS=y
  CONFIG_OF_CONTROL=y
  CONFIG_SPL_OF_CONTROL=y
  CONFIG_SPL_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board k3-j721e-r5-sk"
+CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board"
  CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
  CONFIG_ENV_OVERWRITE=y
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
diff --git a/configs/j721e_sk_a72_defconfig b/configs/j721e_sk_a72_defconfig
new file mode 100644
index 000..c47ad4a7616
--- /dev/null
+++ b/configs/j721e_sk_a72_defconfig
@@ -0,0 +1,4 @@
+#include 
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk"
+CONFIG_OF_LIST="k3-j721e-sk"


These two overrides should be all that is needed, but currently the `buildman`
tool parses the *_defconfigs directly to determine what arch to build every
defconfig  for when doing testing. So you also for now need to re-define the
ARCH, even though it comes in from the include. See how it was done here[0].

Basically just add here:

CONFIG_ARM=y
CONFIG_ARCH_K3=y
CONFIG_SOC_K3_J721E=y
CONFIG_TARGET_J721E_A72_EVM=y

Andrew

[0] https://lore.kernel.org/u-boot/20240223202153.3756094-15-a-nan...@ti.com/



Ah didn't realise that thanks!


diff --git a/configs/j721e_sk_r5_defconfig b/configs/j721e_sk_r5_defconfig
new file mode 100644
index 000..077e8606d57
--- /dev/null
+++ b/configs/j721e_sk_r5_defconfig
@@ -0,0 +1,5 @@
+#include 
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-sk"
+CONFIG_SPL_OF_LIST="k3-j721e-r5-sk"
+CONFIG_OF_LIST="k3-j721e-r5-sk"


--
Thanking You
Neha Malcom Francis

Re: [PATCH 0/3] mux: Drop usage of "u-boot,mux-autoprobe"

[Tom Rini]

On Wed, 31 Jan 2024 15:33:45 +0200, Roger Quadros wrote:

> MUX driver should autoprobe if the device tree has "idle-states"
> property. Drop using the custom "u-boot,mux-autoprobe" property
> in TI device trees.
> 
> cheers,
> -roger
> 
> [...]

Applied to u-boot/next, thanks!

-- 
Tom

Re: [PATCH v3 07/13] board: ti: introduce basic board files for the am62px family

[Tom Rini]

On Mon, Feb 26, 2024 at 03:19:13PM -0600, Bryan Brattlof wrote:

> Introduce the basic files needed to support the am62px family of SoCs
> 
> Co-developed-by: Hari Nagalla 
> Signed-off-by: Hari Nagalla 
> Signed-off-by: Bryan Brattlof 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [NEXT] Pull request efi-next-2024-02-28

[Tom Rini]

On Wed, Feb 28, 2024 at 08:11:52PM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes for the *next* branch since commit
> d49fa3defa50c6d3f04acbb52fd486c13c14ab6a:
> 
>   Prepare v2024.04-rc3 (2024-02-26 21:23:36 -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-next-2024-02-28
> 
> for you to fetch changes up to 97da9aea78ab71e92778649bf9d1071f30e260f0:
> 
>   arm: separate .data and .text sections of EFI binaries (2024-02-28
> 14:39:27 +0100)
> 
> Gitlab CI showed no issues:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/19761
> 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [RFC PATCH 1/6] arm: baltos: remove custom linker script

[Tom Rini]

On Wed, Feb 28, 2024 at 12:48:04PM +0200, Ilias Apalodimas wrote:

> commit 3d74a0977f514 ("ti: am335x: Remove unused linker script") removed
> the linker script for the TI variant. This linker script doesn't seem to
> do anything special and on top of that, has no definitions for the EFI
> runtime sections.
> 
> So let's get rid of it and use the generic linker script which defines
> those correctly
> 
> Signed-off-by: Ilias Apalodimas 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: ECDSA related PRs

[Igor Opaniuk]

Hi Bob,

On Wed, Feb 28, 2024 at 7:14 PM Bob Wolff  wrote:
>
> Any thoughts on how to proceed with the issue mentioned about tinycrypt
> warnings/checks?
>
> Also, I'd like your advice - I was thinking for the larger patch that I'd
> do it in two commits. The first would be the addition of the tinycrypt
> files and the second is the actual changes and additions to support ecdsa
> verification. I doubt that's controversial. However when I run a trial
> `patman` against the tinycrypt commit, I geta huge number of issues:
> *checkpatch.pl  found 186 error(s), 380
> warning(s), 481 checks(s)*
>
> What's your advice on this? I would tend to think we'd want to /not/ change
> the source files directly for such purposes so that updates could be
> brought in with greater ease.

I didn't form any opinion on that, hence asking.
Why not to backport existing ECC/ECDSA implementation from
Linux kernel (crypto/ecc.c, ./crypto/ecdsa.c), like it was already done
for RSA, X509 parser, ASN.1 decoder. Pulling the whole library into the
U-Boot source tree only just for ECDSA is a bit overkill IMO.


>
>
> On Thu, Feb 22, 2024 at 3:07 PM Bob Wolff  wrote:
>
> > Peter,
> > Thanks for helping lead me down the right path here.
> >
> > WRT tinycrypt, the license is quite permissive.
> > https://github.com/intel/tinycrypt
> >
> > Also, I'd like your advice - I was thinking for the larger patch that I'd
> > do it in two commits. The first would be the addition of the tinycrypt
> > files and the second is the actual changes and additions to support ecdsa
> > verification. I doubt that's controversial. However when I run a trial
> > `patman` against the tinycrypt commit, I geta huge number of issues:
> > *checkpatch.pl  found 186 error(s), 380
> > warning(s), 481 checks(s)*
> >
> > What's your advice on this? I would tend to think we'd want to /not/
> > change the source files directly for such purposes so that updates could be
> > brought in with greater ease.
> >
> > Let me know your thoughts.
> >
> > Thanks,
> > Bob Wolff
> >
> >
> >
> > On Wed, Feb 21, 2024 at 6:03 AM Peter Robinson 
> > wrote:
> >
> >>
> >>
> >> On Wed, 21 Feb 2024, 11:30 Bob Wolff,  wrote:
> >>
> >>> Hi there,
> >>> I have two separate but related pull requests I'd like to contribute.
> >>> They
> >>> both have to do with ECDSA support.
> >>> - The simple one is a lack of null-pointer check that can cause a crash
> >>> in
> >>> certain situations. Easy peasy.
> >>>
> >>
> >> Just send that one on it's own
> >>
> >> - The less simple one (and hopefully not too controversial) adds an ecdsa
> >>> verify driver (UCLASS_ECDSA) which utilizes tinycrypt to do the crypto
> >>> work.
> >>>
> >>
> >> Do we already use tiny crypt in the project, if not things like license
> >> need to be taken into account in the context of the GPLv2
> >>
> >> Please advise on how best to proceed. Happy to work within the confines of
> >>> what works best for the larger group.
> >>>
> >>> Thanks,
> >>> Bob Wolff
> >>>
> >>



-- 
Best regards - Freundliche Grüsse - Meilleures salutations

Igor Opaniuk
Senior Software Engineer, Embedded & Security
E: igor.opan...@foundries.io
W: www.foundries.io

[NEXT] Pull request efi-next-2024-02-28

[Heinrich Schuchardt]

Dear Tom,

The following changes for the *next* branch since commit 
d49fa3defa50c6d3f04acbb52fd486c13c14ab6a:


  Prepare v2024.04-rc3 (2024-02-26 21:23:36 -0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git 
tags/efi-next-2024-02-28


for you to fetch changes up to 97da9aea78ab71e92778649bf9d1071f30e260f0:

  arm: separate .data and .text sections of EFI binaries (2024-02-28 
14:39:27 +0100)


Gitlab CI showed no issues:
https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/19761


Pull request efi-next-2024-02-28

* set IMAGE_DLLCHARACTERISTICS_NX_COMPAT in EFI binaries
* provide SBI based runtime system reset
* page align EFI binary section on ARMv7
* separate .data and .text sections of EFI binaries on ARMv7


Heinrich Schuchardt (4):
  efi_loader: set IMAGE_DLLCHARACTERISTICS_NX_COMPAT
  efi_driver: provide SBI based runtime system reset
  arm: page align EFI binary section
  arm: separate .data and .text sections of EFI binaries

 arch/arm/lib/crt0_aarch64_efi.S  |  4 
 arch/arm/lib/crt0_arm_efi.S  | 48 
+++-

 arch/arm/lib/elf_arm_efi.lds | 28 +--
 arch/riscv/lib/crt0_riscv_efi.S  |  4 
 include/asm-generic/pe.h |  3 +++
 lib/efi_driver/Makefile  |  1 +
 lib/efi_driver/efi_reset_riscv.c | 29 
 lib/efi_loader/Kconfig   |  2 +-
 8 files changed, 100 insertions(+), 19 deletions(-)
 create mode 100644 lib/efi_driver/efi_reset_riscv.c

Re: ECDSA related PRs

[Bob Wolff]

Any thoughts on how to proceed with the issue mentioned about tinycrypt
warnings/checks?

Also, I'd like your advice - I was thinking for the larger patch that I'd
do it in two commits. The first would be the addition of the tinycrypt
files and the second is the actual changes and additions to support ecdsa
verification. I doubt that's controversial. However when I run a trial
`patman` against the tinycrypt commit, I geta huge number of issues:
*checkpatch.pl  found 186 error(s), 380
warning(s), 481 checks(s)*

What's your advice on this? I would tend to think we'd want to /not/ change
the source files directly for such purposes so that updates could be
brought in with greater ease.


On Thu, Feb 22, 2024 at 3:07 PM Bob Wolff  wrote:

> Peter,
> Thanks for helping lead me down the right path here.
>
> WRT tinycrypt, the license is quite permissive.
> https://github.com/intel/tinycrypt
>
> Also, I'd like your advice - I was thinking for the larger patch that I'd
> do it in two commits. The first would be the addition of the tinycrypt
> files and the second is the actual changes and additions to support ecdsa
> verification. I doubt that's controversial. However when I run a trial
> `patman` against the tinycrypt commit, I geta huge number of issues:
> *checkpatch.pl  found 186 error(s), 380
> warning(s), 481 checks(s)*
>
> What's your advice on this? I would tend to think we'd want to /not/
> change the source files directly for such purposes so that updates could be
> brought in with greater ease.
>
> Let me know your thoughts.
>
> Thanks,
> Bob Wolff
>
>
>
> On Wed, Feb 21, 2024 at 6:03 AM Peter Robinson 
> wrote:
>
>>
>>
>> On Wed, 21 Feb 2024, 11:30 Bob Wolff,  wrote:
>>
>>> Hi there,
>>> I have two separate but related pull requests I'd like to contribute.
>>> They
>>> both have to do with ECDSA support.
>>> - The simple one is a lack of null-pointer check that can cause a crash
>>> in
>>> certain situations. Easy peasy.
>>>
>>
>> Just send that one on it's own
>>
>> - The less simple one (and hopefully not too controversial) adds an ecdsa
>>> verify driver (UCLASS_ECDSA) which utilizes tinycrypt to do the crypto
>>> work.
>>>
>>
>> Do we already use tiny crypt in the project, if not things like license
>> need to be taken into account in the context of the GPLv2
>>
>> Please advise on how best to proceed. Happy to work within the confines of
>>> what works best for the larger group.
>>>
>>> Thanks,
>>> Bob Wolff
>>>
>>

Re: [PATCH v3 5/8] board: rzg2l: Enable access to Renesas RAA215300 PMIC

[Marek Vasut]

On 2/27/24 9:40 PM, Paul Barker wrote:

Enable the appropriate PMIC driver as well as the `pmic` command.

Signed-off-by: Paul Barker 


Reviewed-by: Marek Vasut 

Re: [PATCH v3 4/8] pmic: Add Renesas RAA215300 PMIC driver

[Marek Vasut]

On 2/27/24 9:40 PM, Paul Barker wrote:

The RZ/G2L SMARC module is powered via a Renesas RAA215300 PMIC which
provides several voltage converters, a real time clock (RTC) and reset
control. A basic driver is implemented for this device so that we can
read, write and dump the PMIC registers.

The raa215300_bind() function is added as a stub, binding of the
sysreset driver will be added in a later patch.

Additional features of this PMIC (such as reset control) may be
supported by future patches.

Signed-off-by: Paul Barker 


Reviewed-by: Marek Vasut 

Re: [PATCH v2 6/8] pci: Add DW PCIe controller support for iMX8MP SoC

[Tim Harvey]

On Tue, Feb 27, 2024 at 3:19 PM Adam Ford  wrote:
>
> On Mon, Feb 26, 2024 at 2:05 AM Sumit Garg  wrote:
> >
> > pcie_imx doesn't seem to share any useful code for iMX8 SoC and it is
> > tied to quite old port of pcie_designware driver from Linux which
> > suffices only iMX6 specific needs.
> >
> > But currently we have the common DWC specific bits which alligns pretty
> > well with DW PCIe controller on iMX8MP SoC. So lets reuse those common
> > bits instead as a new driver for iMX8 SoCs. It should be fairly easy to
> > add support for other iMX8 variants to this driver.
> >
> > iMX8MP SoC also comes up with standalone PCIe PHY support, so hence we
> > can reuse the generic PHY infrastructure to power on PCIe PHY.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >  drivers/pci/Kconfig   |   8 +
> >  drivers/pci/Makefile  |   1 +
> >  drivers/pci/pcie_dw_imx.c | 314 ++
> >  3 files changed, 323 insertions(+)
> >  create mode 100644 drivers/pci/pcie_dw_imx.c
> >
> > diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> > index 463ec47eb92d..7edbf35004a9 100644
> > --- a/drivers/pci/Kconfig
> > +++ b/drivers/pci/Kconfig
> > @@ -413,4 +413,12 @@ config PCIE_STARFIVE_JH7110
> >   Say Y here if you want to enable PLDA XpressRich PCIe controller
> >   support on StarFive JH7110 SoC.
> >
> > +config PCIE_DW_IMX
> > +   bool "i.MX DW PCIe controller support"
> > +   depends on ARCH_IMX8M
>
> I think this also needs to depend on REGMAP to prevent build errors.
>

Sumit,

both REGMAP and SYSCON are needed to build.

Best Regards,

Tim

[PATCH] mtd: spi-nor: ids: Enable Octal read for IS25LX512M flash

[Tejas Bhumkar]

The addition of the "SPI_NOR_OCTAL_READ" flag enables the use of 7Ch 
4-byte octal output fast read command for IS25LX512M flash.

Signed-off-by: Tejas Bhumkar 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4e83b8c94c..8786b6f862 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -241,7 +241,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("is25wx256",  0x9d5b19, 0, 128 * 1024, 256,
SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | 
SPI_NOR_4B_OPCODES) },
{ INFO("is25lx512",  0x9d5a1a, 0, 64 * 1024, 1024,
-   SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES | 
SPI_NOR_HAS_TB) },
+   SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ | 
SPI_NOR_4B_OPCODES | SPI_NOR_HAS_TB) },
 #endif
 #ifdef CONFIG_SPI_FLASH_MACRONIX   /* MACRONIX */
/* Macronix */
-- 
2.37.6

Re: [PATCH 1/3] Dockerfile: Build coreboot from source

[Tom Rini]

On Tue, 13 Feb 2024 09:39:26 -0500, Tom Rini wrote:

> To make CI runs rely less on external servers, build a coreboot release
> from source and populate /opt/coreboot with the output.
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH] arm64: zynqmp: Remove snps,enable_guctl1_ipd_quirk property

[Laurent Pinchart]

Hi Michal,

Thank you for the patch.

On Mon, Feb 26, 2024 at 04:54:13PM +0100, Michal Simek wrote:
> Remove undocumented DT property. Suggested solution was to apply quirk
> via glue logic driver that's why make no sense to have it listed in DT.
> 
> Signed-off-by: Michal Simek 

Reviewed-by: Laurent Pinchart 

> ---
> 
> For more information please take a look at:
> https://lore.kernel.org/r/1708023665-1441674-1-git-send-email-radhey.shyam.pan...@amd.com
> https://lore.kernel.org/r/1708717523-4006664-1-git-send-email-radhey.shyam.pan...@amd.com
> ---
>  arch/arm/dts/zynqmp.dtsi | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
> index b50b83b7723f..daae23c12b79 100644
> --- a/arch/arm/dts/zynqmp.dtsi
> +++ b/arch/arm/dts/zynqmp.dtsi
> @@ -1008,7 +1008,6 @@
>   /* iommus = < 0x860>; */
>   snps,quirk-frame-length-adjustment = <0x20>;
>   clock-names = "ref";
> - snps,enable_guctl1_ipd_quirk;
>   snps,resume-hs-terminations;
>   /* dma-coherent; */
>   };
> @@ -1040,7 +1039,6 @@
>   /* iommus = < 0x861>; */
>   snps,quirk-frame-length-adjustment = <0x20>;
>   clock-names = "ref";
> - snps,enable_guctl1_ipd_quirk;
>   snps,resume-hs-terminations;
>   /* dma-coherent; */
>   };

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2] FWU: developerbox: read boot index from NOR flash

[Jassi Brar]

On Tue, 27 Feb 2024 at 23:53, Masahisa Kojima
 wrote:
>
> The FWU Multi Bank Update feature allows the platform to boot the
> firmware images from one of the partitions(banks).
> On the Developerbox, SCP-firmware running on the SCB(Cortex-M3)
> passes the value of the boot index on the NOR flash.
> Add a function to read the boot index value from the NOR flash.
>
> Signed-off-by: Masahisa Kojima 

Acked-by: Jassi Brar 

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Tom Rini]

On Wed, Feb 28, 2024 at 07:44:42PM +0530, Sumit Garg wrote:
> + Shawn, Krzysztof, Conor
> 
> Hi Tom,
> 
> On Wed, 28 Feb 2024 at 18:40, Tom Rini  wrote:
> >
> > On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with
> > > > linux") removed the display timings from the board device tree whereas
> > > > they are still needed by the mxsfb driver.
> > > > Add the timings back (the correct ones) in the
> > > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > > opos6uldev.env file.
> > > >
> > > > Update the opos6uldev_defconfig file so that the LCD turns on at boot.
> > > >
> > > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with 
> > > > linux")
> > > > Signed-off-by: Sébastien Szymanski 
> > >
> > > Huh.  This is the commit that did that upstream.
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> > >
> > > It's interesting how the timings in linux were always slightly different
> > > from in u-boot.
> >
> > Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> > because this is a recent (rather than ancient) example of one of the
> > concerns about OF_UPSTREAM.
> 
> I rather think about this as an opportunity to improve with
> OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
> corresponding Linux kernel sub-arch maintainers. Especially once we
> move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
> to keep them aware that U-Boot should be considered too.

Yes, a more extensive check around when removing information from dts
files would be good.

> > I think the commit in question can be
> > summarized as "remove a bunch of explicit HW information because there's
> > now a Linux Kernel driver that determines that dynamically". What do we
> > do next? The old information is in a presumably valid binding still, can
> > we just put it back and comment that consumers outside of Linux use this
> > still so it's not removed again later? Or am I just missing where we can
> > instead get this information from the DT still and not need to come up
> > with a new driver and subsystems?
> 
> I can see following two paths forward:
> 
> 1) Partially revert the Linux kernel commit to add back the display
> timings in DT.
> 2) Extend drivers/video/simple_panel.c in U-Boot to add support for
> compatible: "armadeus,st0700-adapt".
> 
> If possible then I would be in favour of (2) rather than the current
> patch to do this properly.

Well, looking at the kernel drivers/gpu/drm/panel/panel-simple.c driver
and then our drivers/video/simple_panel.c it sure would be nice if it's
just a matter of adding a compatible but I wouldn't be surprised if it
ends up needing more information being passed along too? And I'm going
assume there's good reasons for the design change in how the drivers
work in Linux now and note that it might make things more challenging
for us when we do care about space.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v10 00/15] Introduce initial TI's J784S4 and AM69 support

[Marcel Ziswiler]

Hi Apurva

On Wed, 2024-02-28 at 16:59 +0530, Apurva Nandan wrote:
> Hi Marcel,
> 
> On 27/02/24 21:45, Marcel Ziswiler wrote:
> > Hi Apurva
> > 
> > On Sat, 2024-02-24 at 01:51 +0530, Apurva Nandan wrote:
> > > Hello Everyone!
> > > 
> > > This series will introduce basic support (SD and UART) support for Texas
> > > Instruments J784S4 EVM.
> > > 
> > > The J784S4 SoC device tree patches are taken from kernel patch submissions
> > > and will be updated as they are accepted and merged to the kernel tree.
> 
> 
> Sorry about that. I didn't update that part of the cover letter. So now, 
> we will be using
> Linux dts as a git subtree inside U-Boot. And hence, this series doesn't 
> has a Linux DTS sync/copy patch.
> 
> You can get all details in this series:
> https://lore.kernel.org/all/20240222093607.3085545-1-sumit.g...@linaro.org/#r

Yes, sorry. I got that now and with that it applies/compiles perfectly.

> > This patch set does not include any such, right?
> > 
> > Anyway, for my tests I took them from linux-next on kernel.org.
> > 
> > However, I could not get the SD card working apart from it booting U-Boot 
> > off of it:
> > 
> > U-Boot SPL 2024.04-rc3-00015-g7186697f1ff (Feb 27 2024 - 14:27:29 +0100)
> > SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
> > Initialized 4 DRAM controllers
> > SPL initial stack usage: 13416 bytes
> > Trying to boot from MMC2
> > Authentication passed
> > Authentication passed
> > Authentication passed
> > Loading Environment from nowhere... OK
> > Authentication passed
> > Authentication passed
> > Starting ATF on ARM64 core...
> >     
> > NOTICE:  BL31: v2.10.0(release):v2.10.0-412-g885e93f90
> > NOTICE:  BL31: Built : 09:48:15, Feb 27 2024
> > I/TC:
> > I/TC: OP-TEE version: 4.1.0-140-g4078bcde9 (gcc version 13.2.1 20231009 
> > (Arm GNU
> >   Toolchain 13.2.rel1 (Build arm-13.7))) #1 Tue Feb 27 08:54:24 UTC 2024 
> > aarch64
> > I/TC: WARNING: This OP-TEE configuration might be insecure!
> > I/TC: WARNING: Please check 
> > https://optee.readthedocs.io/en/latest/architecture/
> > porting_guidelines.html
> > I/TC: Primary CPU initializing
> > I/TC: GIC redistributor base address not provided
> > I/TC: Assuming default GIC group status and modifier
> > I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
> > I/TC: HUK Initialized
> > I/TC: Activated SA2UL device
> > I/TC: Enabled firewalls for SA2UL TRNG device
> > I/TC: SA2UL TRNG initialized
> > I/TC: SA2UL Drivers initialized
> > I/TC: Primary CPU switching to normal world boot
> >     
> > U-Boot SPL 2024.04-rc3-00015-g7186697f1ff-dirty (Feb 27 2024 - 16:40:07 
> > +0100)
> > SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
> > Trying to boot from MMC2
> > Authentication passed
> > Authentication passed
> > 
> > 
> > U-Boot 2024.04-rc3-00015-g7186697f1ff-dirty (Feb 27 2024 - 16:40:07 +0100)
> > 
> > SoC:   J784S4 SR1.0 HS-FS
> > Model: Texas Instruments J784S4 EVM
> > DRAM:  2 GiB (effective 32 GiB)
> > Core:  87 devices, 30 uclasses, devicetree: separate
> > Flash: 0 Bytes
> > MMC:   mmc@4f8: 0, mmc@4fb: 1
> > Loading Environment from nowhere... OK
> > In:    serial@288
> > Out:   serial@288
> > Err:   serial@288
> > am65_cpsw_nuss ethernet@4600: K3 CPSW: nuss_ver: 0x6BA02102 cpsw_ver: 
> > 0x6BA82102 ale_ver: 0x00293904
> > Ports:1 mdio_freq:100
> > Net:   eth0: ethernet@4600port@1
> > Hit any key to stop autoboot:  0
> > => mmc dev 0
> > switch to partitions #0, OK
> > mmc0(part 0) is current device
> > => mmc info
> > Device: mmc@4f8
> > Manufacturer ID: 13
> > OEM: 4e
> > Name: G1M15L
> > Bus Speed: 2
> > Mode: HS400 (200MHz)
> > Rd Block Len: 512
> > MMC version 5.1
> > High Capacity: Yes
> > Capacity: 29.6 GiB
> > Bus Width: 8-bit DDR
> > Erase Group Size: 512 KiB
> > HC WP Group Size: 8 MiB
> > User Capacity: 29.6 GiB WRREL
> > Boot Capacity: 31.5 MiB ENH
> > RPMB Capacity: 4 MiB ENH
> > Boot area 0 is not write protected
> > Boot area 1 is not write protected
> > => mmc dev 1
> > i2c_write: error waiting for data ACK (status=0x116)
> > pca953x gpio@22: Error reading output register
> > Card did not respond to voltage select! : -110
> > mmc_init: -95, time 114
> > =>
> > 
> > Not sure what the issue may be.
> 
> 
> Which platform are you testing this on? J784S4 EVM or AM69-SK?

AM69-SK.

> As per comments on v8, I have moved from config fragments to having 
> #include in defconfig files.
> So, to build for AM69-SK, you need to use am69_sk_r5_defconfig and 
> am69_sk_a72_defconfig .
> And for the J784S4 EVM, the defconfigs will stay same: 
> j784s4_evm_r5_defconfig and j784s4_evm_a72_defconfig .

Okay, that's what I was missing. Thanks!

Apart from a few warnings this works now perfectly.

Configuring for am69_sk_r5_defconfig I get the following:

generated_defconfig:161:warning: override: reassigning to symbol ARM
generated_defconfig:161:warning: override: ARM changes choice state

Re: [RFC PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board

[Andrew Davis]

On 2/28/24 5:20 AM, Neha Malcom Francis wrote:

Add defconfig for J721E SK R5 and A72 configuration.

This includes and modifies the J721E EVM defconfigs:
j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig
j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig

Signed-off-by: Neha Malcom Francis 
---
  board/ti/j721e/MAINTAINERS  | 2 ++
  configs/j721e_evm_a72_defconfig | 2 +-
  configs/j721e_evm_r5_defconfig  | 2 +-
  configs/j721e_sk_a72_defconfig  | 4 
  configs/j721e_sk_r5_defconfig   | 5 +
  5 files changed, 13 insertions(+), 2 deletions(-)
  create mode 100644 configs/j721e_sk_a72_defconfig
  create mode 100644 configs/j721e_sk_r5_defconfig

diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS
index f5ca7d06a34..06aba53d9b0 100644
--- a/board/ti/j721e/MAINTAINERS
+++ b/board/ti/j721e/MAINTAINERS
@@ -5,5 +5,7 @@ F:  board/ti/j721e
  F:include/configs/j721e_evm.h
  F:configs/j721e_evm_r5_defconfig
  F:configs/j721e_evm_a72_defconfig
+F: configs/j721e_sk_r5_defconfig
+F: configs/j721e_sk_a72_defconfig
  F:configs/j7200_evm_r5_defconfig
  F:configs/j7200_evm_a72_defconfig
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 74af5bebb51..21081a2a684 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -86,7 +86,7 @@ CONFIG_MMC_SPEED_MODE_SET=y
  # CONFIG_SPL_EFI_PARTITION is not set
  CONFIG_OF_CONTROL=y
  CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk"
+CONFIG_OF_LIST="k3-j721e-common-proc-board"
  CONFIG_MULTI_DTB_FIT=y
  CONFIG_SPL_MULTI_DTB_FIT=y
  CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index bc4f35cce11..ce2b7df58cf 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -81,7 +81,7 @@ CONFIG_CMD_MTDPARTS=y
  CONFIG_OF_CONTROL=y
  CONFIG_SPL_OF_CONTROL=y
  CONFIG_SPL_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board k3-j721e-r5-sk"
+CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board"
  CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
  CONFIG_ENV_OVERWRITE=y
  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
diff --git a/configs/j721e_sk_a72_defconfig b/configs/j721e_sk_a72_defconfig
new file mode 100644
index 000..c47ad4a7616
--- /dev/null
+++ b/configs/j721e_sk_a72_defconfig
@@ -0,0 +1,4 @@
+#include 
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk"
+CONFIG_OF_LIST="k3-j721e-sk"


These two overrides should be all that is needed, but currently the `buildman`
tool parses the *_defconfigs directly to determine what arch to build every
defconfig  for when doing testing. So you also for now need to re-define the
ARCH, even though it comes in from the include. See how it was done here[0].

Basically just add here:

CONFIG_ARM=y
CONFIG_ARCH_K3=y
CONFIG_SOC_K3_J721E=y
CONFIG_TARGET_J721E_A72_EVM=y

Andrew

[0] https://lore.kernel.org/u-boot/20240223202153.3756094-15-a-nan...@ti.com/


diff --git a/configs/j721e_sk_r5_defconfig b/configs/j721e_sk_r5_defconfig
new file mode 100644
index 000..077e8606d57
--- /dev/null
+++ b/configs/j721e_sk_r5_defconfig
@@ -0,0 +1,5 @@
+#include 
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-sk"
+CONFIG_SPL_OF_LIST="k3-j721e-r5-sk"
+CONFIG_OF_LIST="k3-j721e-r5-sk"

Re: [PATCH v6 08/11] doc: devicetree: Updates for devicetree-rebasing subtree

[Paul Barker]

On 28/02/2024 09:20, Sumit Garg wrote:
> Hi Paul,
> 
> On Wed, 28 Feb 2024 at 03:08, Paul Barker  
> wrote:
>>
>> Hi Sumit,
>>
>> On 22/02/2024 09:36, Sumit Garg wrote:
>>> Encourage SoC/board maintainers to migrate to using devicetree-rebasing
>>> subtree and maintain a regular sync with Linux kernel devicetree files
>>> and bindings.
>>>
>>> Along with that add documentation regarding how to run DT bindings
>>> schema checks.
>>>
>>> Signed-off-by: Sumit Garg 
>>> ---
>>>
>>> Changes in v6:
>>> - Incorporate documentation review comments from Paul.
>>>
>>
>> I have just a couple of tidy up suggestions for the links in this
>> document - these let us avoid short reference names like `dtrepo` or
>> `dttweaks` appearing in the document itself where they interrupt the
>> flow of the text.
> 
> Although these are following the same pattern as `dtspec` and `dtlist`
> , your suggestion sounds reasonable. However, I would just like to
> avoid sending a newer version just for these since this patch-set is
> already a dependency for others [1] [2].
> 
> If you agree then I can send a follow up patch to get rid of all the
> short reference names in this document.
> 
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=396399
> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=396742

Please go ahead and fix this as a follow up patch. I don't see any
reason to hold up this series.

-- 
Paul Barker

OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Sumit Garg]

+ Shawn, Krzysztof, Conor

Hi Tom,

On Wed, 28 Feb 2024 at 18:40, Tom Rini  wrote:
>
> On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> > On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with
> > > linux") removed the display timings from the board device tree whereas
> > > they are still needed by the mxsfb driver.
> > > Add the timings back (the correct ones) in the
> > > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > > opos6uldev.env file.
> > >
> > > Update the opos6uldev_defconfig file so that the LCD turns on at boot.
> > >
> > > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with 
> > > linux")
> > > Signed-off-by: Sébastien Szymanski 
> >
> > Huh.  This is the commit that did that upstream.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> >
> > It's interesting how the timings in linux were always slightly different
> > from in u-boot.
>
> Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
> because this is a recent (rather than ancient) example of one of the
> concerns about OF_UPSTREAM.

I rather think about this as an opportunity to improve with
OF_UPSTREAM. We can feed these kinds of DT ABI breakages to
corresponding Linux kernel sub-arch maintainers. Especially once we
move to OF_UPSTREAM and a sub-arch maintainer profile in Linux kernel
to keep them aware that U-Boot should be considered too.

> I think the commit in question can be
> summarized as "remove a bunch of explicit HW information because there's
> now a Linux Kernel driver that determines that dynamically". What do we
> do next? The old information is in a presumably valid binding still, can
> we just put it back and comment that consumers outside of Linux use this
> still so it's not removed again later? Or am I just missing where we can
> instead get this information from the DT still and not need to come up
> with a new driver and subsystems?

I can see following two paths forward:

1) Partially revert the Linux kernel commit to add back the display
timings in DT.
2) Extend drivers/video/simple_panel.c in U-Boot to add support for
compatible: "armadeus,st0700-adapt".

If possible then I would be in favour of (2) rather than the current
patch to do this properly.

-Sumit

>
> --
> Tom

Re: [PATCH 1/2] opos6uldev: make the LCD work again

[Tom Rini]

On Wed, Feb 28, 2024 at 10:09:13AM +0300, Dan Carpenter wrote:
> On Tue, Feb 27, 2024 at 04:40:01PM +0100, Sébastien Szymanski wrote:
> > Commit 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with
> > linux") removed the display timings from the board device tree whereas
> > they are still needed by the mxsfb driver.
> > Add the timings back (the correct ones) in the
> > imx6ul-opos6uldev-u-boot.dtsi file and remove them from the
> > opos6uldev.env file.
> > 
> > Update the opos6uldev_defconfig file so that the LCD turns on at boot.
> > 
> > Fixes: 5d7a95f4 ("imx6ul/imx6ull: synchronise device trees with linux")
> > Signed-off-by: Sébastien Szymanski 
> 
> Huh.  This is the commit that did that upstream.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d9aa4d4fca67823838fe9861456201430c545e69
> 
> It's interesting how the timings in linux were always slightly different
> from in u-boot.

Thanks for tracking that down, Dan. I'm adding in Sumit and Rob here
because this is a recent (rather than ancient) example of one of the
concerns about OF_UPSTREAM. I think the commit in question can be
summarized as "remove a bunch of explicit HW information because there's
now a Linux Kernel driver that determines that dynamically". What do we
do next? The old information is in a presumably valid binding still, can
we just put it back and comment that consumers outside of Linux use this
still so it's not removed again later? Or am I just missing where we can
instead get this information from the DT still and not need to come up
with a new driver and subsystems?

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v6] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

[MD Danish Anwar]

Add APIs to set a firmware_name to a rproc and boot the rproc with the
same firmware.

Clients can call rproc_set_firmware() API to set firmware_name for a rproc
whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
a buffer by calling request_firmware_into_buf(). rproc_boot() will then
load the firmware file to the remote processor and start the remote
processor.

Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
Kconfig so that we can call request_firmware_into_buf() from remoteproc
driver.

Signed-off-by: MD Danish Anwar 
Acked-by: Ravi Gunasekaran 
---
Changes from v5 to v6:
*) Collected Acked-by tag from Ravi Gunasekaran 
*) Fixed few typos as pointed out by Roger Quadros 
*) Added if condition to check if uc_pdata->fw_name exists and free it
   before the strndup as suggested by Roger Quadros 

Changes from v4 to v5:
*) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
   that can be loaded to a rproc.
*) Added freeing of address in rproc_boot() as pointed out by Ravi.
*) Allocating the address at a later point in rproc_boot()
*) Rebased on latest u-boot/master [commit 
   9e00b6993f724da9699ef12573307afea8c19284]

Changes from v3 to v4:
*) No functional change. Splitted the patch out of the series as suggested
   by Nishant.
*) Droppped the RFC tag.

v5: https://lore.kernel.org/all/20240217122602.3402774-1-danishan...@ti.com/
v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/

 drivers/remoteproc/Kconfig|   8 +++
 drivers/remoteproc/rproc-uclass.c | 102 ++
 include/remoteproc.h  |  34 ++
 3 files changed, 144 insertions(+)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 781de530af..9f9877931c 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -10,6 +10,7 @@ menu "Remote Processor drivers"
 # All users should depend on DM
 config REMOTEPROC
bool
+   select FS_LOADER
depends on DM
 
 # Please keep the configuration alphabetically sorted.
@@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
help
  Say 'y' here to add support for TI' K3 remoteproc driver.
 
+config REMOTEPROC_MAX_FW_SIZE
+   hex "Maximum size of firmware file that needs to be loaded to the 
remote processor"
+   default 0x1
+   help
+ Maximum size of the firmware file (elf, binary) that needs to be
+ loaded to the remote processor.
+
 endmenu
diff --git a/drivers/remoteproc/rproc-uclass.c 
b/drivers/remoteproc/rproc-uclass.c
index 28b362c887..f4f22a3851 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -961,3 +962,104 @@ unsigned long rproc_parse_resource_table(struct udevice 
*dev, struct rproc *cfg)
 
return 1;
 }
+
+int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
+{
+   struct dm_rproc_uclass_pdata *uc_pdata;
+   int len;
+   char *p;
+
+   if (!rproc_dev || !fw_name)
+   return -EINVAL;
+
+   uc_pdata = dev_get_uclass_plat(rproc_dev);
+   if (!uc_pdata)
+   return -EINVAL;
+
+   len = strcspn(fw_name, "\n");
+   if (!len) {
+   debug("invalid firmware name\n");
+   return -EINVAL;
+   }
+
+   if (uc_pdata->fw_name)
+   free(uc_pdata->fw_name);
+
+   p = strndup(fw_name, len);
+   if (!p)
+   return -ENOMEM;
+
+   uc_pdata->fw_name = p;
+
+   return 0;
+}
+
+int rproc_boot(struct udevice *rproc_dev)
+{
+   struct dm_rproc_uclass_pdata *uc_pdata;
+   struct udevice *fs_loader;
+   int core_id, ret = 0;
+   char *firmware;
+   void *addr;
+
+   if (!rproc_dev)
+   return -EINVAL;
+
+   uc_pdata = dev_get_uclass_plat(rproc_dev);
+   if (!uc_pdata)
+   return -EINVAL;
+
+   core_id = dev_seq(rproc_dev);
+   firmware = uc_pdata->fw_name;
+   if (!firmware) {
+   debug("No firmware name set for rproc core %d\n", core_id);
+   return -EINVAL;
+   }
+
+   /* Initialize all rproc cores */
+   if (!rproc_is_initialized()) {
+   ret = rproc_init();
+   if (ret) {
+   debug("rproc_init() failed: %d\n", ret);
+   return ret;
+   }
+   }
+
+   /* Loading firmware to a given address */
+   ret = get_fs_loader(_loader);
+   if (ret) {
+   debug("could not get fs loader: %d\n", ret);
+   return ret;
+   }
+
+   if (CONFIG_REMOTEPROC_MAX_FW_SIZE) {
+   addr = malloc(CONFIG_REMOTEPROC_MAX_FW_SIZE);
+   if (!addr)
+   return -ENOMEM;
+   } else {
+   

Re: [PATCH v10 00/15] Introduce initial TI's J784S4 and AM69 support

[Apurva Nandan]

Hi Marcel,

On 27/02/24 21:45, Marcel Ziswiler wrote:

Hi Apurva

On Sat, 2024-02-24 at 01:51 +0530, Apurva Nandan wrote:

Hello Everyone!

This series will introduce basic support (SD and UART) support for Texas
Instruments J784S4 EVM.

The J784S4 SoC device tree patches are taken from kernel patch submissions
and will be updated as they are accepted and merged to the kernel tree.



Sorry about that. I didn't update that part of the cover letter. So now, 
we will be using
Linux dts as a git subtree inside U-Boot. And hence, this series doesn't 
has a Linux DTS sync/copy patch.


You can get all details in this series:
https://lore.kernel.org/all/20240222093607.3085545-1-sumit.g...@linaro.org/#r


This patch set does not include any such, right?

Anyway, for my tests I took them from linux-next on kernel.org.

However, I could not get the SD card working apart from it booting U-Boot off 
of it:

U-Boot SPL 2024.04-rc3-00015-g7186697f1ff (Feb 27 2024 - 14:27:29 +0100)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
Initialized 4 DRAM controllers
SPL initial stack usage: 13416 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.10.0(release):v2.10.0-412-g885e93f90

NOTICE:  BL31: Built : 09:48:15, Feb 27 2024
I/TC:
I/TC: OP-TEE version: 4.1.0-140-g4078bcde9 (gcc version 13.2.1 20231009 (Arm GNU
  Toolchain 13.2.rel1 (Build arm-13.7))) #1 Tue Feb 27 08:54:24 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/
porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

U-Boot SPL 2024.04-rc3-00015-g7186697f1ff-dirty (Feb 27 2024 - 16:40:07 +0100)

SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
Trying to boot from MMC2
Authentication passed
Authentication passed


U-Boot 2024.04-rc3-00015-g7186697f1ff-dirty (Feb 27 2024 - 16:40:07 +0100)

SoC:   J784S4 SR1.0 HS-FS
Model: Texas Instruments J784S4 EVM
DRAM:  2 GiB (effective 32 GiB)
Core:  87 devices, 30 uclasses, devicetree: separate
Flash: 0 Bytes
MMC:   mmc@4f8: 0, mmc@4fb: 1
Loading Environment from nowhere... OK
In:serial@288
Out:   serial@288
Err:   serial@288
am65_cpsw_nuss ethernet@4600: K3 CPSW: nuss_ver: 0x6BA02102 cpsw_ver: 
0x6BA82102 ale_ver: 0x00293904
Ports:1 mdio_freq:100
Net:   eth0: ethernet@4600port@1
Hit any key to stop autoboot:  0
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc info
Device: mmc@4f8
Manufacturer ID: 13
OEM: 4e
Name: G1M15L
Bus Speed: 2
Mode: HS400 (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 29.6 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 29.6 GiB WRREL
Boot Capacity: 31.5 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
=> mmc dev 1
i2c_write: error waiting for data ACK (status=0x116)
pca953x gpio@22: Error reading output register
Card did not respond to voltage select! : -110
mmc_init: -95, time 114
=>

Not sure what the issue may be.



Which platform are you testing this on? J784S4 EVM or AM69-SK?

As per comments on v8, I have moved from config fragments to having 
#include in defconfig files.
So, to build for AM69-SK, you need to use am69_sk_r5_defconfig and 
am69_sk_a72_defconfig .
And for the J784S4 EVM, the defconfigs will stay same: 
j784s4_evm_r5_defconfig and j784s4_evm_a72_defconfig .




All other patches are specific to SPL and u-boot and do not have
dependency on other trees. Appreciate a review for acceptance to u-boot
tree.

Here are some of the salient features of the J784S4 automotive grade
application processor:

The J784S4 SoC belongs to the K3 Multicore SoC architecture
platform, providing advanced system integration in automotive,
ADAS and industrial applications requiring AI at the network edge.
This SoC extends the K3 Jacinto 7 family of SoCs with focus on
raising performance and integration while providing interfaces,
memory architecture and compute performance for multi-sensor, high
concurrency applications.

Some highlights of this SoC are:
* Up to 8 Cortex-A72s, four clusters of lockstep capable dual Cortex-R5F MCUs,
   4 C7x floating point vector DSPs with Matrix Multiply Accelerator(MMA) for
   deep learning and CNN.
* 3D GPU: Automotive grade IMG BXS-4-64 MC1
* Vision Processing 

Re: [PATCH v10 00/15] Introduce initial TI's J784S4 and AM69 support

[Marcel Ziswiler]

Hi Sumit

On Wed, 2024-02-28 at 11:04 +0530, Sumit Garg wrote:
> Hi Marcel,
> 
> On Tue, 27 Feb 2024 at 21:45, Marcel Ziswiler
>  wrote:
> > 
> > Hi Apurva
> > 
> > On Sat, 2024-02-24 at 01:51 +0530, Apurva Nandan wrote:
> > > Hello Everyone!
> > > 
> > > This series will introduce basic support (SD and UART) support for Texas
> > > Instruments J784S4 EVM.
> > > 
> > > The J784S4 SoC device tree patches are taken from kernel patch submissions
> > > and will be updated as they are accepted and merged to the kernel tree.
> > 
> > This patch set does not include any such, right?
> > 
> 
> I suppose you have missed to apply dependencies for this patch-set,
> look for following:
> 
> Note: This series is dependent on the following series for OF_UPSTREAM support
> https://lore.kernel.org/all/20240222093607.3085545-1-sumit.g...@linaro.org/

Yes, sorry, I missed that one. With that it applies/compiles perfectly. Thanks!

However, still the same issue with the SD card:

U-Boot SPL 2024.04-rc3-00028-g9edcd6ffd06 (Feb 28 2024 - 11:53:27 +0100)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
Initialized 4 DRAM controllers
SPL initial stack usage: 13416 bytes
Trying to boot from MMC2
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
Authentication passed
Authentication passed
Starting ATF on ARM64 core...
   
NOTICE:  BL31: v2.10.0(release):v2.10.0-412-g885e93f90
NOTICE:  BL31: Built : 09:48:15, Feb 27 2024
I/TC:
I/TC: OP-TEE version: 4.1.0-140-g4078bcde9 (gcc version 13.2.1 20231009 (Arm GNU
 Toolchain 13.2.rel1 (Build arm-13.7))) #1 Tue Feb 27 08:54:24 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/
porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot
   
U-Boot SPL 2024.04-rc3-00028-g9edcd6ffd06 (Feb 28 2024 - 11:54:01 +0100)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.1.9--v09.01.09 (Kool Koala)')
Trying to boot from MMC2
Authentication passed
Authentication passed


U-Boot 2024.04-rc3-00028-g9edcd6ffd06 (Feb 28 2024 - 11:54:01 +0100)

SoC:   J784S4 SR1.0 HS-FS
Model: Texas Instruments J784S4 EVM
DRAM:  2 GiB (effective 32 GiB)
Core:  81 devices, 30 uclasses, devicetree: separate
Flash: 0 Bytes
MMC:   mmc@4f8: 0, mmc@4fb: 1
Loading Environment from nowhere... OK
In:serial@288
Out:   serial@288
Err:   serial@288
am65_cpsw_nuss ethernet@4600: K3 CPSW: nuss_ver: 0x6BA02102 cpsw_ver: 
0x6BA82102 ale_ver: 0x00293904
Ports:1 mdio_freq:100
Net:   eth0: ethernet@4600port@1
Hit any key to stop autoboot:  0 
=> mmc dev 0
switch to partitions #0, OK
mmc0(part 0) is current device
=> mmc info
Device: mmc@4f8
Manufacturer ID: 13
OEM: 4e
Name: G1M15L 
Bus Speed: 2
Mode: HS400 (200MHz)
Rd Block Len: 512
MMC version 5.1
High Capacity: Yes
Capacity: 29.6 GiB
Bus Width: 8-bit DDR
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 29.6 GiB WRREL
Boot Capacity: 31.5 MiB ENH
RPMB Capacity: 4 MiB ENH
Boot area 0 is not write protected
Boot area 1 is not write protected
=> mmc dev 1
i2c_write: error waiting for data ACK (status=0x116)
pca953x gpio@22: Error reading output register
Card did not respond to voltage select! : -110
mmc_init: -95, time 114
=> 

And yes, the SD card previously did work properly. Any ideas?

> And, '[PATCH 01/15] Makefile: remove hardcoded device tree source
> directory' has been
> cherry-picked from PATCH 11 of
> https://lore.kernel.org/all/20240201030634.1120963-16...@ti.com/ by
> Bryan
> Brattlof
> 
> -Sumit
> 
> [snip]

Cheers

Marcel

Re: [PATCH v6 08/11] doc: devicetree: Updates for devicetree-rebasing subtree

[Sumit Garg]

Hi Paul,

On Wed, 28 Feb 2024 at 03:08, Paul Barker  wrote:
>
> Hi Sumit,
>
> On 22/02/2024 09:36, Sumit Garg wrote:
> > Encourage SoC/board maintainers to migrate to using devicetree-rebasing
> > subtree and maintain a regular sync with Linux kernel devicetree files
> > and bindings.
> >
> > Along with that add documentation regarding how to run DT bindings
> > schema checks.
> >
> > Signed-off-by: Sumit Garg 
> > ---
> >
> > Changes in v6:
> > - Incorporate documentation review comments from Paul.
> >
>
> I have just a couple of tidy up suggestions for the links in this
> document - these let us avoid short reference names like `dtrepo` or
> `dttweaks` appearing in the document itself where they interrupt the
> flow of the text.

Although these are following the same pattern as `dtspec` and `dtlist`
, your suggestion sounds reasonable. However, I would just like to
avoid sending a newer version just for these since this patch-set is
already a dependency for others [1] [2].

If you agree then I can send a follow up patch to get rid of all the
short reference names in this document.

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=396399
[2] https://patchwork.ozlabs.org/project/uboot/list/?series=396742

-Sumit

> For each one I've just wrote out what I think the line
> above should be, I hope that makes sense.
>
> [...]
>
> > +Resyncing with devicetree-rebasing
> > +--
> > +
> > +The devicetee-rebasing repository (dtrepo_) maintains a fork cum mirror 
> > copy of
>
> The `devicetree-rebasing repository`_ maintains a fork cum mirror copy of
>
> > +devicetree files along with the bindings synced at every Linux kernel major
> > +release or intermediate release candidates. The U-Boot maintainers 
> > regularly
> > +sync the `dts/upstream/` subtree from the devicetree-rebasing repo whenever
> > +the next branch opens (refer: :doc:`../release_cycle`) with the latest 
> > mainline
> > +Linux kernel release. To sync the `dts/upstream/` subtree, run::
> > +
> > +./dts/update-dts-subtree.sh pull 
> > +
> > +If required it is also possible to cherry-pick fixes from the
> > +devicetree-rebasing repository prior to next sync, usage::
> > +
> > +./dts/update-dts-subtree.sh pick 
> > +
> > +
> >  Configuration
> >  -
> >
> > -Set up "" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. Then 
> > put
> > -your devicetree file into::
> > +SoC/board maintainers are encouraged to migrate to use synced copies from
> > +`dts/upstream/src//`. To do that add `imply OF_UPSTREAM` for 
> > the
> > +SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=/` 
> > when
> > +prompted by Kconfig.
> >
> > -   arch//dts/.dts
> > +However, if `dts/upstream/` hasn't yet received devicetree source file for 
> > your
> > +newly added board support then you can add corresponding devicetree source 
> > file
> > +as `arch//dts/.dts`. To select that add `# CONFIG_OF_UPSTREAM 
> > is not
> > +set` and set `DEFAULT_DEVICE_TREE=` when prompted by Kconfig.
> >
> > -This should include your CPU or SOC's devicetree file, placed in
> > -`arch//dts`, and then make any adjustments required using a 
> > u-boot-dtsi
> > -file for your board.
> > +This should include your CPU or SoC's devicetree file. On top of that any 
> > U-Boot
> > +specific tweaks (see: dttweaks_) can be made for your board.
>
> specific tweaks (see: :ref:`dttweaks`) can be made for your board.
>
> >
> >  If `OF_EMBED` is selected by Kconfig, then it will be picked up and built 
> > into
> >  the U-Boot image (including u-boot.bin). This is suitable for debugging
> > @@ -155,8 +185,9 @@ ways:
> >  Adding tweaks for U-Boot
> >  
> >
> > -It is strongly recommended that devicetree files in U-Boot are an exact 
> > copy of
> > -those in Linux, so that it is easy to sync them up from time to time.
> > +With `dts/upstream` Git subtree, it is ensured that devicetree files in 
> > U-Boot
> > +are an exact copy of those in Linux kernel available under
> > +`dts/upstream/src//`.
> >
> >  U-Boot is of course a very different project from Linux, e.g. it operates 
> > under
> >  much more restrictive memory and code-size constraints. Where Linux may 
> > use a
> > @@ -169,8 +200,8 @@ constraints are even more extreme and the devicetree is 
> > shrunk to remove
> >  unwanted nodes, or even turned into C code to avoid access overhead.
> >
> >  U-Boot automatically looks for and includes a file with updates to the 
> > standard
> > -devicetree for your board, searching for them in the same directory as the
> > -main file, in this order::
> > +devicetree for your board, searching for them in `arch//dts/` in this
> > +order::
> >
> > -u-boot.dtsi
> > -u-boot.dtsi
> > @@ -199,6 +230,48 @@ option to specify a list of .dtsi files that will also 
> > be included when
> >  building .dtb files.
> >
> >
> > +Devicetree bindings schema checks
> > +-
> > +
> > +With 

[PATCH v2] FWU: developerbox: read boot index from NOR flash

[Masahisa Kojima]

The FWU Multi Bank Update feature allows the platform to boot the
firmware images from one of the partitions(banks).
On the Developerbox, SCP-firmware running on the SCB(Cortex-M3)
passes the value of the boot index on the NOR flash.
Add a function to read the boot index value from the NOR flash.

Signed-off-by: Masahisa Kojima 
---
v1 -> v2
- update my email address

 board/socionext/developerbox/fwu_plat.c | 31 +
 include/configs/synquacer.h |  1 +
 2 files changed, 32 insertions(+)

diff --git a/board/socionext/developerbox/fwu_plat.c 
b/board/socionext/developerbox/fwu_plat.c
index e724e702bd..26031795b0 100644
--- a/board/socionext/developerbox/fwu_plat.c
+++ b/board/socionext/developerbox/fwu_plat.c
@@ -35,3 +35,34 @@ void set_dfu_alt_info(char *interface, char *devstr)
 
env_set("dfu_alt_info", buf);
 }
+
+/**
+ * fwu_plat_get_bootidx() - Get the value of the boot index
+ * @boot_idx: Boot index value
+ *
+ * Get the value of the bank(partition) from which the platform
+ * has booted. This value is passed to U-Boot from the earlier
+ * stage bootloader which loads and boots all the relevant
+ * firmware images
+ */
+void fwu_plat_get_bootidx(uint *boot_idx)
+{
+   int ret;
+   u32 buf;
+   size_t readlen;
+   struct mtd_info *mtd;
+
+   *boot_idx = 0;
+
+   mtd_probe_devices();
+   mtd = get_mtd_device_nm("nor1");
+   if (IS_ERR_OR_NULL(mtd))
+   return;
+
+   ret = mtd_read(mtd, SCB_PLAT_METADATA_OFFSET, sizeof(buf),
+  , (u_char *));
+   if (ret < 0)
+   return;
+
+   *boot_idx = buf;
+}
diff --git a/include/configs/synquacer.h b/include/configs/synquacer.h
index e36e63e81e..f0867227ac 100644
--- a/include/configs/synquacer.h
+++ b/include/configs/synquacer.h
@@ -21,6 +21,7 @@
 /*
  * Boot info
  */
+#define SCB_PLAT_METADATA_OFFSET   (0x51)
 
 /*
  * Hardware drivers support
-- 
2.34.1

Re: [PATCH v10 12/15] arm: dts: Introduce am69-sk u-boot dts files

[Sumit Garg]

On Tue, 27 Feb 2024 at 21:49, Marcel Ziswiler
 wrote:
>
> Hi Apurva
>
> On Sat, 2024-02-24 at 01:51 +0530, Apurva Nandan wrote:
> > From: Dasnavis Sabiya 
> >
> > Introduce the base dts files needed for u-boot or to augment the linux
> > dtbs for use in the u-boot-spl and u-boot binaries.
> >
> > Signed-off-by: Dasnavis Sabiya 
> > Signed-off-by: Apurva Nandan 
> > ---
> >  arch/arm/dts/Makefile   |   3 +-
> >  arch/arm/dts/k3-am69-r5-sk.dts  | 106 
> >  arch/arm/dts/k3-am69-sk-u-boot.dtsi |  54 ++
> >  board/ti/j784s4/MAINTAINERS |   6 ++
> >  4 files changed, 168 insertions(+), 1 deletion(-)
> >  create mode 100644 arch/arm/dts/k3-am69-r5-sk.dts
> >  create mode 100644 arch/arm/dts/k3-am69-sk-u-boot.dtsi
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index e484112dd7c..e3a47d055b0 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1413,7 +1413,8 @@ dtb-$(CONFIG_SOC_K3_J721S2) += 
> > k3-am68-sk-base-board.dtb\
> >  k3-j721s2-common-proc-board.dtb\
> >  k3-j721s2-r5-common-proc-board.dtb
> >
> > -dtb-$(CONFIG_SOC_K3_J784S4) += k3-j784s4-r5-evm.dtb
> > +dtb-$(CONFIG_SOC_K3_J784S4) += k3-am69-r5-sk.dtb \
> > +k3-j784s4-r5-evm.dtb
> >
> >  dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
> > k3-am642-r5-evm.dtb \
> > diff --git a/arch/arm/dts/k3-am69-r5-sk.dts b/arch/arm/dts/k3-am69-r5-sk.dts
> > new file mode 100644
> > index 000..f177f563527
> > --- /dev/null
> > +++ b/arch/arm/dts/k3-am69-r5-sk.dts
> > @@ -0,0 +1,106 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
> > https://www.ti.com/
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "k3-am69-sk.dts"
> > +#include "k3-j784s4-ddr-evm-lp4-4266.dtsi"
> > +#include "k3-j784s4-ddr.dtsi"
> > +#include "k3-am69-sk-u-boot.dtsi"
> > +
> > +/ {
> > + chosen {
> > + tick-timer = _timer0;
> > + };
> > +
> > + aliases {
> > + remoteproc0 = 
> > + remoteproc1 = _0;
> > + };
> > +
> > + a72_0: a72@0 {
> > + compatible = "ti,am654-rproc";
> > + reg = <0x0 0x00a9 0x0 0x10>;
> > + power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
> > + <_pds 202 TI_SCI_PD_EXCLUSIVE>;
> > + resets = <_reset 202 0>;
> > + clocks = <_clks 61 0>;
> > + assigned-clocks = <_clks 61 0>, <_clks 202 0>;
> > + assigned-clock-parents = <_clks 61 2>;
> > + assigned-clock-rates = <2>, <20>;
> > + ti,sci = <>;
> > + ti,sci-proc-id = <32>;
> > + ti,sci-host-id = <10>;
> > + bootph-pre-ram;
> > + };
> > +
> > + dm_tifs: dm-tifs {
> > + compatible = "ti,j721e-dm-sci";
> > + ti,host-id = <3>;
> > + ti,secure-host;
> > + mbox-names = "rx", "tx";
> > + mboxes= <_proxy_mcu 21>, <_proxy_mcu 23>;
> > + bootph-pre-ram;
> > + };
> > +};
> > +
> > +_timer0 {
> > + status = "okay";
> > + clock-frequency = <25000>;
> > + bootph-pre-ram;
> > +};
> > +
> > +_proxy_sa3 {
> > + status = "okay";
> > + bootph-pre-ram;
> > +};
> > +
> > +_proxy_mcu {
> > + status = "okay";
> > + bootph-pre-ram;
> > +};
> > +
> > +_mcu_wakeup {
> > + sysctrler: sysctrler {
> > + compatible = "ti,am654-system-controller";
> > + mboxes= <_proxy_mcu 4>,
> > + <_proxy_mcu 5>,
> > + <_proxy_sa3 5>;
> > + mbox-names = "tx", "rx", "boot_notify";
> > + bootph-pre-ram;
> > + };
> > +};
> > +
> > + {
> > + mboxes= <_proxy_mcu 8>, <_proxy_mcu 6>, 
> > <_proxy_mcu 5>;
> > + mbox-names = "tx", "rx", "notify";
> > + ti,host-id = <4>;
> > + ti,secure-host;
> > + bootph-pre-ram;
> > +};
> > +
> > +/* WKUP UART0 is used for DM firmware logs */
> > +_uart0 {
> > + bootph-pre-ram;
> > + status = "okay";
> > +};
> > +
> > + {
> > + reg = <0x0 0x4704 0x0 0x100>,
> > +   <0x0 0x5000 0x0 0x800>;
> > +};
> > +
> > + {
> > + reg = <0x0 0x4705 0x0 0x100>,
> > +   <0x0 0x5800 0x0 0x800>;
> > +};
> > +
> > +_ringacc {
> > + ti,sci = <_tifs>;
> > +};
> > +
> > +_udmap {
> > + ti,sci = <_tifs>;
> > +};
> > diff --git a/arch/arm/dts/k3-am69-sk-u-boot.dtsi 
> > b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> > new file mode 100644
> > index 000..bed330e6d4e
> > --- /dev/null
> > +++ b/arch/arm/dts/k3-am69-sk-u-boot.dtsi
> > @@ -0,0 +1,54 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2022-2023 Texas Instruments Incorporated - 
> > https://www.ti.com/
> > + */
> > +
> > +#include "k3-j784s4-binman.dtsi"

Re: [PATCH v10 00/15] Introduce initial TI's J784S4 and AM69 support

[Sumit Garg]

Hi Marcel,

On Tue, 27 Feb 2024 at 21:45, Marcel Ziswiler
 wrote:
>
> Hi Apurva
>
> On Sat, 2024-02-24 at 01:51 +0530, Apurva Nandan wrote:
> > Hello Everyone!
> >
> > This series will introduce basic support (SD and UART) support for Texas
> > Instruments J784S4 EVM.
> >
> > The J784S4 SoC device tree patches are taken from kernel patch submissions
> > and will be updated as they are accepted and merged to the kernel tree.
>
> This patch set does not include any such, right?
>

I suppose you have missed to apply dependencies for this patch-set,
look for following:

Note: This series is dependent on the following series for OF_UPSTREAM support
https://lore.kernel.org/all/20240222093607.3085545-1-sumit.g...@linaro.org/

And, '[PATCH 01/15] Makefile: remove hardcoded device tree source
directory' has been
cherry-picked from PATCH 11 of
https://lore.kernel.org/all/20240201030634.1120963-16...@ti.com/ by
Bryan
Brattlof

-Sumit

[snip]

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

[MD Danish Anwar]

On 28/02/24 4:12 pm, Roger Quadros wrote:
> 
> 
> On 28/02/2024 12:35, MD Danish Anwar wrote:
>>
>>
>> On 28/02/24 3:30 pm, Roger Quadros wrote:
>>>
>>>
>>> On 17/02/2024 14:26, MD Danish Anwar wrote:
 Add APIs to set a firmware_name to a rproc and boot the rproc with the
 same firmware.

 Clients can call rproc_set_firmware() API to set firmware_name for a rproc
 whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
 a buffer by calling request_firmware_into_buf(). rproc_boot() will then
 load the firmware file to the remote processor and start the remote
 processor.

 Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
 Kconfig so that we can call request_firmware_into_buf() from remoteproc
 driver.

 Signed-off-by: MD Danish Anwar 
 ---
 Changes from v4 to v5:
 *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
that can be loaded to a rproc.
 *) Added freeing of address in rproc_boot() as pointed out by Ravi.
 *) Allocating the address at a later point in rproc_boot()
 *) Rebased on latest u-boot/master [commit 
9e00b6993f724da9699ef12573307afea8c19284]

 Changes from v3 to v4:
 *) No functional change. Splitted the patch out of the series as suggested
by Nishant.
 *) Droppped the RFC tag.

 v4: 
 https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
 v3: 
 https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/

  drivers/remoteproc/Kconfig|   8 +++
  drivers/remoteproc/rproc-uclass.c | 100 ++
  include/remoteproc.h  |  34 ++
  3 files changed, 142 insertions(+)

 diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
 index 781de530af..759d21437a 100644
 --- a/drivers/remoteproc/Kconfig
 +++ b/drivers/remoteproc/Kconfig
 @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
  # All users should depend on DM
  config REMOTEPROC
bool
 +  select FS_LOADER
depends on DM
  
  # Please keep the configuration alphabetically sorted.
 @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
help
  Say 'y' here to add support for TI' K3 remoteproc driver.
  
 +config REMOTEPROC_MAX_FW_SIZE
 +  hex "Maximum size of firmware that needs to be loaded to rproc"
>>>
>>> firmware file?
>>>
>>> /rproc/the remote processor
>>>
 +  default 0x1
 +  help
 +Maximum size of the firmware file (elf, binary) that needs to be
 +loaded to th rproc core.
>>>
>>> s/th/the
>>> s/rproc/remote processor
>>>
>>
>> Will fix these typos.
>>
 +
  endmenu
 diff --git a/drivers/remoteproc/rproc-uclass.c 
 b/drivers/remoteproc/rproc-uclass.c
 index 28b362c887..784361cef9 100644
 --- a/drivers/remoteproc/rproc-uclass.c
 +++ b/drivers/remoteproc/rproc-uclass.c
 @@ -13,6 +13,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct 
 udevice *dev, struct rproc *cfg)
  
return 1;
  }
 +
 +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
 +{
 +  struct dm_rproc_uclass_pdata *uc_pdata;
 +  int len;
 +  char *p;
 +
 +  if (!rproc_dev || !fw_name)
 +  return -EINVAL;
 +
 +  uc_pdata = dev_get_uclass_plat(rproc_dev);
 +  if (!uc_pdata)
 +  return -EINVAL;
 +
 +  len = strcspn(fw_name, "\n");
 +  if (!len) {
 +  debug("invalid firmware name\n");
 +  return -EINVAL;
 +  }
 +
 +  p = strndup(fw_name, len);
 +  if (!p)
 +  return -ENOMEM;
>>>
>>> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
>>> Can we check if uc_pdata->fw_name exists and free it before the strndup?
>>>
>>
>> Sure, How does the below diff looks to you?
>>
>> diff --git a/drivers/remoteproc/rproc-uclass.c
>> b/drivers/remoteproc/rproc-uclass.c
>> index 784361cef9..f373b64da4 100644
>> --- a/drivers/remoteproc/rproc-uclass.c
>> +++ b/drivers/remoteproc/rproc-uclass.c
>> @@ -982,6 +982,9 @@ int rproc_set_firmware(struct udevice *rproc_dev,
>> const char *fw_name)
>> return -EINVAL;
>> }
>>
>> +   if (uc_pdata->fw_name)
>> +   free(uc_pdata->fw_name);
>> +
>> p = strndup(fw_name, len);
>> if (!p)
>> return -ENOMEM;
> 
> This is OK. Please see below.
> 
>>
>>
 +
 +  uc_pdata->fw_name = p;
 +
 +  return 0;
 +}
 +
 +int rproc_boot(struct udevice *rproc_dev)
 +{
 +  struct dm_rproc_uclass_pdata *uc_pdata;
 +  struct udevice *fs_loader;
 +  int core_id, ret = 0;
 +  char *firmware;

[RFC PATCH 3/4] arm: dts: k3-j721e: Separate boot binary build

[Neha Malcom Francis]

Separate out the boot binaries built for J721E boards; J721E EVM and
J721E SK by using the common templates in k3-j721e-binman.dtsi.

Only the required boot binaries can be built from the templates in the
boards' respective -u-boot.dtsi file. FDTs and configurations are also
moved to the -u-boot.dtsi file to allow clear distinction between the
SoC common stuff vs. what is needed to boot up a board.

Signed-off-by: Neha Malcom Francis 
---
Note: I have added "dummy" sections so that node for a phandle is found
correctly. The node for a phandle is searched for among sub-nodes of a
section (check tools/binman/etype/section.py GetContentsByPhandle) and
having a template as the section instead, causes failure to find the
phandle despite it being present in the FDT. So the dummy section
bypasses this.

Avoided correct DTS alignment for the RFC at least so that it's clear
what is actually being changed.

 arch/arm/dts/k3-j721e-binman.dtsi | 178 +-
 .../k3-j721e-common-proc-board-u-boot.dtsi| 138 ++
 arch/arm/dts/k3-j721e-sk-u-boot.dtsi  | 104 ++
 3 files changed, 284 insertions(+), 136 deletions(-)

diff --git a/arch/arm/dts/k3-j721e-binman.dtsi 
b/arch/arm/dts/k3-j721e-binman.dtsi
index 75a6e9599b9..284613545ea 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -5,11 +5,12 @@
 
 #include "k3-binman.dtsi"
 
-#ifdef CONFIG_TARGET_J721E_R5_EVM
+#ifdef CONFIG_CPU_V7R
 
  {
-   tiboot3-j721e_sr1_1-hs-evm.bin {
+   tiboot3_j721e_sr1_1_hs: template-9 {
filename = "tiboot3-j721e_sr1_1-hs-evm.bin";
+   section {
ti-secure-rom {
content = <_boot_spl>;
core = "public";
@@ -19,10 +20,12 @@
u_boot_spl: u-boot-spl {
no-expanded;
};
+   };
};
 
-   tiboot3-j721e_sr2-hs-evm.bin {
+   tiboot3_j721e_sr2_hs: template-10 {
filename = "tiboot3-j721e_sr2-hs-evm.bin";
+   section {
ti-secure-rom {
content = <_boot_spl_sr2>;
core = "public";
@@ -32,10 +35,12 @@
u_boot_spl_sr2: u-boot-spl {
no-expanded;
};
+   };
};
 
-   sysfw {
+   sysfw: template-11 {
filename = "sysfw.bin";
+   section {
ti-secure-rom {
content = <_fs_cert>;
core = "secure";
@@ -53,10 +58,12 @@
type = "blob-ext";
optional;
};
+   };
};
 
-   sysfw_sr2 {
+   sysfw_sr2: template-12 {
filename = "sysfw.bin_sr2";
+   section {
ti-secure-rom {
content = <_fs_cert_sr2>;
core = "secure";
@@ -74,15 +81,17 @@
type = "blob-ext";
optional;
};
+   };
};
 
-   itb {
+   itb: template-13 {
filename = "sysfw-j721e_sr1_1-hs-evm.itb";
insert-template = <_template>;
};
 
-   itb_sr2 {
+   itb_sr2: template-14 {
filename = "sysfw-j721e_sr2-hs-evm.itb";
+   section {
insert-template = <_template>;
fit {
images {
@@ -127,11 +136,13 @@
};
};
};
+   };
 };
 
  {
-   tiboot3-j721e_sr2-hs-fs-evm.bin {
+   tiboot3_j721e_sr2_hs_fs: template-15 {
filename = "tiboot3-j721e_sr2-hs-fs-evm.bin";
+   section {
ti-secure-rom {
content = <_boot_spl_fs>;
core = "public";
@@ -142,8 +153,10 @@
no-expanded;
};
};
-   sysfw_fs {
+   };
+   sysfw_fs: template-16 {
filename = "sysfw.bin_fs";
+   section {
ti-fs-cert-fs.bin {
filename = 
"ti-sysfw/ti-fs-firmware-j721e_sr2-hs-fs-cert.bin";
type = "blob-ext";
@@ -155,16 +168,18 @@
optional;
};
};
-   itb_fs {
+   };
+   itb_fs: template-17 {
filename = "sysfw-j721e_sr2-hs-fs-evm.itb";
insert-template = <_unsigned_template>;
};
 };
 
  {
-   tiboot3-j721e-gp-evm.bin {
+   tiboot3_j721e_gp: template-18 {
filename = "tiboot3-j721e-gp-evm.bin";
symlink = "tiboot3.bin";
+   section {
ti-secure-rom {
content = <_boot_spl_unsigned>;
core = "public";
@@ -176,8 +191,10 @@
no-expanded;
  

[RFC PATCH 2/4] tools: binman: control.py: Delete template nodes after parsing

[Neha Malcom Francis]

Dynamically going through the subnode array and deleting leads to
templates being skipped from deletion when templates are consecutive in
the subnode list. Prevent this from happening by first parsing the DT
and then deleting the nodes.

Signed-off-by: Neha Malcom Francis 
---
 tools/binman/control.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/binman/control.py b/tools/binman/control.py
index 2f00279232b..1c4e6a581f9 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -522,9 +522,13 @@ def _ProcessTemplates(parent):
 def _RemoveTemplates(parent):
 """Remove any templates in the binman description
 """
+del_nodes = []
 for node in parent.subnodes:
 if node.name.startswith('template'):
-node.Delete()
+del_nodes.append(node)
+
+for node in del_nodes:
+node.Delete()
 
 def PrepareImagesAndDtbs(dtb_fname, select_images, update_fdt, use_expanded):
 """Prepare the images to be processed and select the device tree
-- 
2.34.1

[RFC PATCH 1/4] configs: j721e_sk: Move to separate defconfig for J721E SK board

[Neha Malcom Francis]

Add defconfig for J721E SK R5 and A72 configuration.

This includes and modifies the J721E EVM defconfigs:
j721e_evm_r5_defconfig -> j721e_sk_r5_defconfig
j721e_evm_a72_defconfig -> j721e_sk_a72_defconfig

Signed-off-by: Neha Malcom Francis 
---
 board/ti/j721e/MAINTAINERS  | 2 ++
 configs/j721e_evm_a72_defconfig | 2 +-
 configs/j721e_evm_r5_defconfig  | 2 +-
 configs/j721e_sk_a72_defconfig  | 4 
 configs/j721e_sk_r5_defconfig   | 5 +
 5 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 configs/j721e_sk_a72_defconfig
 create mode 100644 configs/j721e_sk_r5_defconfig

diff --git a/board/ti/j721e/MAINTAINERS b/board/ti/j721e/MAINTAINERS
index f5ca7d06a34..06aba53d9b0 100644
--- a/board/ti/j721e/MAINTAINERS
+++ b/board/ti/j721e/MAINTAINERS
@@ -5,5 +5,7 @@ F:  board/ti/j721e
 F: include/configs/j721e_evm.h
 F: configs/j721e_evm_r5_defconfig
 F: configs/j721e_evm_a72_defconfig
+F: configs/j721e_sk_r5_defconfig
+F: configs/j721e_sk_a72_defconfig
 F: configs/j7200_evm_r5_defconfig
 F: configs/j7200_evm_a72_defconfig
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 74af5bebb51..21081a2a684 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -86,7 +86,7 @@ CONFIG_MMC_SPEED_MODE_SET=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
-CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk"
+CONFIG_OF_LIST="k3-j721e-common-proc-board"
 CONFIG_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig
index bc4f35cce11..ce2b7df58cf 100644
--- a/configs/j721e_evm_r5_defconfig
+++ b/configs/j721e_evm_r5_defconfig
@@ -81,7 +81,7 @@ CONFIG_CMD_MTDPARTS=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_SPL_MULTI_DTB_FIT=y
-CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board k3-j721e-r5-sk"
+CONFIG_SPL_OF_LIST="k3-j721e-r5-common-proc-board"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_OVERWRITE=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
diff --git a/configs/j721e_sk_a72_defconfig b/configs/j721e_sk_a72_defconfig
new file mode 100644
index 000..c47ad4a7616
--- /dev/null
+++ b/configs/j721e_sk_a72_defconfig
@@ -0,0 +1,4 @@
+#include 
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-sk"
+CONFIG_OF_LIST="k3-j721e-sk"
diff --git a/configs/j721e_sk_r5_defconfig b/configs/j721e_sk_r5_defconfig
new file mode 100644
index 000..077e8606d57
--- /dev/null
+++ b/configs/j721e_sk_r5_defconfig
@@ -0,0 +1,5 @@
+#include 
+
+CONFIG_DEFAULT_DEVICE_TREE="k3-j721e-r5-sk"
+CONFIG_SPL_OF_LIST="k3-j721e-r5-sk"
+CONFIG_OF_LIST="k3-j721e-r5-sk"
-- 
2.34.1

[RFC PATCH 0/4] Cleanup J721E EVM and SK

[Neha Malcom Francis]

This series does primarily three things:
1. Split out the common J721E defconfig for both EVM and SK
2. Cleanup k3-j721e-binman.dtsi to be SoC specific binman nodes
   and -u-boot.dtsi files of the respective boards can pick and
   edit according to their board. This is based on the
   discussion [1]
3. Move J721E EVM and SK to using OF_UPSTREAM

This series depends on series [2] and patch [3] which implement
OF_UPSTREAM. Hopefully we get an idea of whether this is what we want to
see across all K3 SoCs by the next release.

[1] https://lore.kernel.org/u-boot/20240123205255.i7eynu6vdpoxwybf@irregular/
[2] 
https://lore.kernel.org/u-boot/20240222093607.3085545-1-sumit.g...@linaro.org/
[3] 
https://lore.kernel.org/u-boot/20240205-am62px-wip-rebasing-v3-11-04cbb42ea...@ti.com/

Boot logs:
https://gist.github.com/nehamalcom/3b578dfa1ef83b59f3c309557606ed63

Neha Malcom Francis (4):
  configs: j721e_sk: Move to separate defconfig for J721E SK board
  tools: binman: control.py: Delete template nodes after parsing
  arm: dts: k3-j721e: Separate boot binary build
  arm: dts: k3-j721e: Move to OF_UPSTREAM

 arch/arm/dts/Makefile |4 +-
 arch/arm/dts/k3-j721e-binman.dtsi |  178 +-
 .../k3-j721e-common-proc-board-u-boot.dtsi|  138 +
 arch/arm/dts/k3-j721e-common-proc-board.dts   |  976 --
 arch/arm/dts/k3-j721e-main.dtsi   | 2741 -
 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi |  681 
 arch/arm/dts/k3-j721e-sk-u-boot.dtsi  |  104 +
 arch/arm/dts/k3-j721e-sk.dts  | 1074 ---
 arch/arm/dts/k3-j721e-som-p0.dtsi |  446 ---
 arch/arm/dts/k3-j721e-thermal.dtsi|   75 -
 arch/arm/dts/k3-j721e.dtsi|  176 --
 board/ti/j721e/MAINTAINERS|2 +
 configs/j721e_evm_a72_defconfig   |5 +-
 configs/j721e_evm_r5_defconfig|2 +-
 configs/j721e_sk_a72_defconfig|4 +
 configs/j721e_sk_r5_defconfig |5 +
 tools/binman/control.py   |6 +-
 17 files changed, 305 insertions(+), 6312 deletions(-)
 delete mode 100644 arch/arm/dts/k3-j721e-common-proc-board.dts
 delete mode 100644 arch/arm/dts/k3-j721e-main.dtsi
 delete mode 100644 arch/arm/dts/k3-j721e-mcu-wakeup.dtsi
 delete mode 100644 arch/arm/dts/k3-j721e-sk.dts
 delete mode 100644 arch/arm/dts/k3-j721e-som-p0.dtsi
 delete mode 100644 arch/arm/dts/k3-j721e-thermal.dtsi
 delete mode 100644 arch/arm/dts/k3-j721e.dtsi
 create mode 100644 configs/j721e_sk_a72_defconfig
 create mode 100644 configs/j721e_sk_r5_defconfig

-- 
2.34.1

Re: [RFC PATCH 0/6] Clean up arm linker scripts

[Ilias Apalodimas]

On Wed, 28 Feb 2024 at 13:11, Peter Robinson  wrote:
>
> On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
>  wrote:
> >
> > The arm linker scripts had a mix of symbols and C defined variables in an
> > effort to emit relative references instead of absolute ones e.g [0].
> > This has led to confusion over the years, ending up with mixed section
> > definitions. Some sections being defined with overlays and different
> > definitions between v7 and v8 architectures.
> > For example __efi_runtime_rel_start/end is defined as a linker symbol for
> > armv8 and a C variable in armv7.
> >
> > I am not sure if this used to be a compiler bug, but linker scripts nowadays
> > can emit relative references, as long as the symbol definition is contained
> > within the section definition. So let's switch most of the C defined 
> > variables
>
> Should we be setting/upping the minimum version of the linker version
> as part of this?

The patch that added those as C-defined variables, was in 2013. So any
linker that's not ancient history should emit those correctly.


>
> > and clean up the arm sections.c file. There's still a few symbols remaining 
> > --
> > __secure_start/end, __secure_stack_start/end and __end which can be cleaned 
> > up
> > in a followup series.
> >
> > The resulting binary (tested in QEMU v7/v8) had no size differences apart 
> > from
> > the emited sections and object types of those variables. I've also added 
> > prints
> > throughout the U-Boot init sequence. The offsets and delta for 'end - start'
> > section sizes is unchanged.
> >
> > For example on QEMU v8:
> > $~ ./scripts/bloat-o-meter u-boot u-boot.new
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Function old new   delta
> > Total: Before=798861, After=798861, chg +0.00%
> >
> > $~ readelf -sW u-boot | grep bss_s
> > 12: 001029b8 0 SECTION LOCAL  DEFAULT   12 .bss_start
> >   8088: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
> >   8376: 001029b8 0 OBJECT  GLOBAL DEFAULT   12 __bss_start
> > $~ readelf -sW u-boot.new | grep bss_s
> >   8085: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
> >   8373: 001029b8 0 NOTYPE  GLOBAL DEFAULT   12 __bss_start
> >
> > For QEMU v7 the differences are a bit bigger but only affect the variables
> > placed in the .bss section because that was defined as an OVERLAY in the
> > existing linker script.
> > For example:
> > $~ nm u-boot | grep tftp_prev_block
> > 000ca0dc ? tftp_prev_block
> > $~ nm u-boot.new | grep tftp_prev_block
> > 000e0a5c b tftp_prev_block -> The symbol is now placed into .bss
> >
> > It's worth noting that since the efi regions are affected by the change, 
> > booting
> > with EFI is preferable while testing. Booting the kernel only should be 
> > enough
> > since the efi stub and the kernel proper do request boottime and runtime
> > services respectively.
> > Something along the lines of
> > > virtio scan && load virtio 0 $kernel_addr_r Image && bootefi 
> > > $kernel_addr_r
> > will work for QEMU aarch64.
> >
> > Tested platforms:
> > - QEMU aarch64
> > - Xilinx kv260 kria starter kit & zynq
> > - QEMU armv7
> > - STM32MP157C-DK2
> >
> > [0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ 
> > compiler-generated")
> >
> > Ilias Apalodimas (6):
> >   arm: baltos: remove custom linker script
> >   arm: clean up v7 and v8 linker scripts for bss_start/end
> >   arm: fix __efi_runtime_rel_start/end definitions
> >   arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end
> >   arm: fix __efi_runtime_start/end definitions
> >   arm: move image_copy_start/end to linker symbols
> >
> >  arch/arm/cpu/armv8/u-boot-spl.lds |  14 +--
> >  arch/arm/cpu/armv8/u-boot.lds |  45 ++--
> >  arch/arm/cpu/u-boot.lds   |  74 +++--
> >  arch/arm/lib/sections.c   |  10 --
> >  arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  22 +---
> >  arch/arm/mach-zynq/u-boot.lds |  72 +++-
> >  board/qualcomm/dragonboard820c/u-boot.lds |  41 ++-
> >  board/vscom/baltos/u-boot.lds | 128 --
> >  include/asm-generic/sections.h|   3 +
> >  lib/efi_loader/efi_runtime.c  |   1 +
> >  10 files changed, 58 insertions(+), 352 deletions(-)
> >  delete mode 100644 board/vscom/baltos/u-boot.lds
> >
> > --
> > 2.37.2
> >

Re: [RFC PATCH 0/6] Clean up arm linker scripts

[Peter Robinson]

On Wed, 28 Feb 2024 at 10:58, Ilias Apalodimas
 wrote:
>
> The arm linker scripts had a mix of symbols and C defined variables in an
> effort to emit relative references instead of absolute ones e.g [0].
> This has led to confusion over the years, ending up with mixed section
> definitions. Some sections being defined with overlays and different
> definitions between v7 and v8 architectures.
> For example __efi_runtime_rel_start/end is defined as a linker symbol for
> armv8 and a C variable in armv7.
>
> I am not sure if this used to be a compiler bug, but linker scripts nowadays
> can emit relative references, as long as the symbol definition is contained
> within the section definition. So let's switch most of the C defined variables

Should we be setting/upping the minimum version of the linker version
as part of this?

> and clean up the arm sections.c file. There's still a few symbols remaining --
> __secure_start/end, __secure_stack_start/end and __end which can be cleaned up
> in a followup series.
>
> The resulting binary (tested in QEMU v7/v8) had no size differences apart from
> the emited sections and object types of those variables. I've also added 
> prints
> throughout the U-Boot init sequence. The offsets and delta for 'end - start'
> section sizes is unchanged.
>
> For example on QEMU v8:
> $~ ./scripts/bloat-o-meter u-boot u-boot.new
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Function old new   delta
> Total: Before=798861, After=798861, chg +0.00%
>
> $~ readelf -sW u-boot | grep bss_s
> 12: 001029b8 0 SECTION LOCAL  DEFAULT   12 .bss_start
>   8088: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
>   8376: 001029b8 0 OBJECT  GLOBAL DEFAULT   12 __bss_start
> $~ readelf -sW u-boot.new | grep bss_s
>   8085: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
>   8373: 001029b8 0 NOTYPE  GLOBAL DEFAULT   12 __bss_start
>
> For QEMU v7 the differences are a bit bigger but only affect the variables
> placed in the .bss section because that was defined as an OVERLAY in the
> existing linker script.
> For example:
> $~ nm u-boot | grep tftp_prev_block
> 000ca0dc ? tftp_prev_block
> $~ nm u-boot.new | grep tftp_prev_block
> 000e0a5c b tftp_prev_block -> The symbol is now placed into .bss
>
> It's worth noting that since the efi regions are affected by the change, 
> booting
> with EFI is preferable while testing. Booting the kernel only should be enough
> since the efi stub and the kernel proper do request boottime and runtime
> services respectively.
> Something along the lines of
> > virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r
> will work for QEMU aarch64.
>
> Tested platforms:
> - QEMU aarch64
> - Xilinx kv260 kria starter kit & zynq
> - QEMU armv7
> - STM32MP157C-DK2
>
> [0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ 
> compiler-generated")
>
> Ilias Apalodimas (6):
>   arm: baltos: remove custom linker script
>   arm: clean up v7 and v8 linker scripts for bss_start/end
>   arm: fix __efi_runtime_rel_start/end definitions
>   arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end
>   arm: fix __efi_runtime_start/end definitions
>   arm: move image_copy_start/end to linker symbols
>
>  arch/arm/cpu/armv8/u-boot-spl.lds |  14 +--
>  arch/arm/cpu/armv8/u-boot.lds |  45 ++--
>  arch/arm/cpu/u-boot.lds   |  74 +++--
>  arch/arm/lib/sections.c   |  10 --
>  arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  22 +---
>  arch/arm/mach-zynq/u-boot.lds |  72 +++-
>  board/qualcomm/dragonboard820c/u-boot.lds |  41 ++-
>  board/vscom/baltos/u-boot.lds | 128 --
>  include/asm-generic/sections.h|   3 +
>  lib/efi_loader/efi_runtime.c  |   1 +
>  10 files changed, 58 insertions(+), 352 deletions(-)
>  delete mode 100644 board/vscom/baltos/u-boot.lds
>
> --
> 2.37.2
>

Re: [PATCH v2 2/2] arm: separate .data and .text sections of EFI binaries

[Ilias Apalodimas]

On Mon, 26 Feb 2024 at 23:24, Heinrich Schuchardt
 wrote:
>
> EFI binaries should not contain sections that are both writable and
> executable. Separate the RX .text section from the RW .data section.
>
> We currently don't created relocation sections (.rel.*) for our EFI
> binaries. Anyway these would have to be converted to PE/COFF relocations.
> Enumerate them under DISCARD and add a comment.
>
> Correct the characteristics of the sections.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> Consider that 32-bit arm uses .rel and not .rela relocations
> and discard them as they are cannot be used in EFI binaries.
> Correct the characteristics of the .reloc section.
> ---
>  arch/arm/lib/crt0_arm_efi.S  | 40 
>  arch/arm/lib/elf_arm_efi.lds | 28 ++---
>  2 files changed, 52 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
> index 7a4e5dff75..7219c0f2fe 100644
> --- a/arch/arm/lib/crt0_arm_efi.S
> +++ b/arch/arm/lib/crt0_arm_efi.S
> @@ -23,7 +23,7 @@ pe_header:
> .long   IMAGE_NT_SIGNATURE  /* 'PE' */
>  coff_header:
> .short  IMAGE_FILE_MACHINE_THUMB/* Mixed ARM/Thumb */
> -   .short  2   /* nr_sections */
> +   .short  3   /* nr_sections */
> .long   0   /* TimeDateStamp */
> .long   0   /* PointerToSymbolTable */
> .long   0   /* NumberOfSymbols */
> @@ -98,22 +98,44 @@ section_table:
> .long   0   /* PointerToLineNumbers */
> .short  0   /* NumberOfRelocations */
> .short  0   /* NumberOfLineNumbers */
> -   .long   0x42100040  /* Characteristics (section flags) */
> +   /* Characteristics (section flags) */
> +   .long   (IMAGE_SCN_MEM_READ | \
> +IMAGE_SCN_MEM_DISCARDABLE | \
> +IMAGE_SCN_CNT_INITIALIZED_DATA)
>
> .ascii  ".text"
> .byte   0
> .byte   0
> .byte   0   /* end of 0 padding of section name */
> -   .long   _edata - _start /* VirtualSize */
> +   .long   _text_size  /* VirtualSize */
> .long   _start - image_base /* VirtualAddress */
> -   .long   _edata - _start /* SizeOfRawData */
> +   .long   _text_size  /* SizeOfRawData */
> .long   _start - image_base /* PointerToRawData */
> +   .long   0   /* PointerToRelocations */
> +   .long   0   /* PointerToLineNumbers */
> +   .short  0   /* NumberOfRelocations */
> +   .short  0   /* NumberOfLineNumbers */
> +   /* Characteristics (section flags) */
> +   .long   (IMAGE_SCN_MEM_READ | \
> +IMAGE_SCN_MEM_EXECUTE | \
> +IMAGE_SCN_CNT_CODE)
>
> -   .long   0   /* PointerToRelocations (0 for executables) */
> -   .long   0   /* PointerToLineNumbers (0 for executables) */
> -   .short  0   /* NumberOfRelocations  (0 for executables) */
> -   .short  0   /* NumberOfLineNumbers  (0 for executables) */
> -   .long   0xe0500020  /* Characteristics (section flags) */
> +   .ascii  ".data"
> +   .byte   0
> +   .byte   0
> +   .byte   0   /* end of 0 padding of section name */
> +   .long   _data_size  /* VirtualSize */
> +   .long   _data - image_base  /* VirtualAddress */
> +   .long   _data_size  /* SizeOfRawData */
> +   .long   _data - image_base  /* PointerToRawData */
> +   .long   0   /* PointerToRelocations */
> +   .long   0   /* PointerToLineNumbers */
> +   .short  0   /* NumberOfRelocations */
> +   .short  0   /* NumberOfLineNumbers */
> +   /* Characteristics (section flags) */
> +   .long   (IMAGE_SCN_MEM_WRITE | \
> +IMAGE_SCN_MEM_READ | \
> +IMAGE_SCN_CNT_INITIALIZED_DATA)
>
> .align  12
>  _start:
> diff --git a/arch/arm/lib/elf_arm_efi.lds b/arch/arm/lib/elf_arm_efi.lds
> index 767ebda635..41440594aa 100644
> --- a/arch/arm/lib/elf_arm_efi.lds
> +++ b/arch/arm/lib/elf_arm_efi.lds
> @@ -7,6 +7,12 @@
>
>  OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
>  OUTPUT_ARCH(arm)
> +
> +PHDRS
> +{
> +   data PT_LOAD FLAGS(3); /* PF_W | PF_X */
> +}
> +
>  ENTRY(_start)
>  SECTIONS
>  {
> @@ -18,11 +24,13 @@ SECTIONS
> *(.gnu.linkonce.t.*)
> *(.srodata)
> *(.rodata*)
> +   . = ALIGN(16);
> +   

Re: [PATCH v2 1/2] arm: page align EFI binary section

[Ilias Apalodimas]

On Mon, 26 Feb 2024 at 23:24, Heinrich Schuchardt
 wrote:
>
> Change the alignment of the relocation code in EFI binaries to match page
> boundaries.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
> new patch
> ---
>  arch/arm/lib/crt0_arm_efi.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
> index 75ee37b7d3..7a4e5dff75 100644
> --- a/arch/arm/lib/crt0_arm_efi.S
> +++ b/arch/arm/lib/crt0_arm_efi.S
> @@ -115,14 +115,14 @@ section_table:
> .short  0   /* NumberOfLineNumbers  (0 for executables) */
> .long   0xe0500020  /* Characteristics (section flags) */
>
> -   .align  9
> +   .align  12
>  _start:
> stmfd   sp!, {r0-r2, lr}
>
> adr r1, .L_DYNAMIC
> ldr r0, [r1]
> add r1, r0, r1
> -   adr r0, image_base
> +   adrlr0, image_base
> bl  _relocate
> teq r0, #0
> bne 0f
> --
> 2.43.0
>

Reviewed-by: Ilias Apalodimas 

[PATCH v2] serial: pl01x: set baudrate when probing

[Yang Xiwen via B4 Relay]

From: Yang Xiwen 

It is found that when DM is enabled, only generic init function is
called in .probe(). Baudrate is never honored. Add a function call
to .setbrg() when probing so that we can update the baudrate of the
serial device.

Signed-off-by: Yang Xiwen 
---
Changes in v2:
- reverse if statement (Dan Carpenter)
- Link to v1: 
https://lore.kernel.org/r/20240123-b4-pl011-v1-1-fb576d0a7...@outlook.com
---
 drivers/serial/serial_pl01x.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 428a4d210de5..f04c21e08264 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -290,6 +290,7 @@ int pl01x_serial_probe(struct udevice *dev)
 {
struct pl01x_serial_plat *plat = dev_get_plat(dev);
struct pl01x_priv *priv = dev_get_priv(dev);
+   int ret;
 
 #if CONFIG_IS_ENABLED(OF_PLATDATA)
struct dtd_serial_pl01x *dtplat = >dtplat;
@@ -301,10 +302,14 @@ int pl01x_serial_probe(struct udevice *dev)
 #endif
priv->type = plat->type;
 
-   if (!plat->skip_init)
-   return pl01x_generic_serial_init(priv->regs, priv->type);
-   else
+   if (!plat->skip_init) {
+   ret = pl01x_generic_serial_init(priv->regs, priv->type);
+   if (ret)
+   return ret;
+   return pl01x_serial_setbrg(dev, gd->baudrate);
+   } else {
return 0;
+   }
 }
 
 int pl01x_serial_getc(struct udevice *dev)

---
base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3
change-id: 20240123-b4-pl011-ee9575ff2a38

Best regards,
-- 
Yang Xiwen 

[RFC PATCH 6/6] arm: move image_copy_start/end to linker symbols

[Ilias Apalodimas]

image_copy_start/end are defined as c variables in order to force the compiler
emit relative references. However, defining those within a section definition
will do the same thing.

So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
a section.

Signed-off-by: Ilias Apalodimas 
---
 arch/arm/cpu/armv8/u-boot.lds | 10 ++
 arch/arm/cpu/u-boot.lds   | 10 ++
 arch/arm/lib/sections.c   |  2 --
 arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  8 ++--
 arch/arm/mach-zynq/u-boot.lds |  9 ++---
 board/qualcomm/dragonboard820c/u-boot.lds | 11 ++-
 6 files changed, 10 insertions(+), 40 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index e737de761a9d..340acf5c043b 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -23,7 +23,7 @@ SECTIONS
. = ALIGN(8);
.text :
{
-   *(.__image_copy_start)
+   __image_copy_start = .;
CPUDIR/start.o (.text*)
}

@@ -120,13 +120,7 @@ SECTIONS
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
 __efi_runtime_rel_stop = .;
-   }
-
-   . = ALIGN(8);
-
-   .image_copy_end :
-   {
-   *(.__image_copy_end)
+   __image_copy_end = .;
}

.rela.dyn ALIGN(8) : {
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index df55bb716e35..7c4f9c2d4dd3 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -37,7 +37,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
-   *(.__image_copy_start)
+   __image_copy_start = .;
*(.vectors)
CPUDIR/start.o (.text*)
}
@@ -151,13 +151,7 @@ SECTIONS
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
__efi_runtime_rel_stop = .;
-   }
-
-   . = ALIGN(4);
-
-   .image_copy_end :
-   {
-   *(.__image_copy_end)
+   __image_copy_end = .;
}

.rel.dyn ALIGN(4) : {
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index a4d4202e99f5..db5463b2bbbc 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -19,8 +19,6 @@
  * aliasing warnings.
  */

-char __image_copy_start[0] __section(".__image_copy_start");
-char __image_copy_end[0] __section(".__image_copy_end");
 char __secure_start[0] __section(".__secure_start");
 char __secure_end[0] __section(".__secure_end");
 char __secure_stack_start[0] __section(".__secure_stack_start");
diff --git a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds 
b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
index b7887194026e..4b480ebb0c4d 100644
--- a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
+++ b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
@@ -24,7 +24,7 @@ SECTIONS

.text : {
. = ALIGN(8);
-   *(.__image_copy_start)
+   __image_copy_start = .;
CPUDIR/start.o (.text*)
*(.text*)
}
@@ -42,11 +42,7 @@ SECTIONS
__u_boot_list : {
. = ALIGN(8);
KEEP(*(SORT(__u_boot_list*)));
-   }
-
-   .image_copy_end : {
-   . = ALIGN(8);
-   *(.__image_copy_end)
+   __image_copy_end = .;
}

.end : {
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index fcd0f42a7106..553bcf182272 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ b/arch/arm/mach-zynq/u-boot.lds
@@ -16,7 +16,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
-   *(.__image_copy_start)
+   __image_copy_start = .;
*(.vectors)
CPUDIR/start.o (.text*)
}
@@ -57,12 +57,7 @@ SECTIONS
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
__efi_runtime_rel_stop = .;
-   }
-
-   . = ALIGN(8);
-   .image_copy_end :
-   {
-   *(.__image_copy_end)
+   __image_copy_end = .;
}

.rel.dyn ALIGN(8) : {
diff --git a/board/qualcomm/dragonboard820c/u-boot.lds 
b/board/qualcomm/dragonboard820c/u-boot.lds
index 2969f139bfd2..f8d3c030ef32 100644
--- a/board/qualcomm/dragonboard820c/u-boot.lds
+++ b/board/qualcomm/dragonboard820c/u-boot.lds
@@ -17,7 +17,7 @@ SECTIONS
. = ALIGN(8);
.text :
{
-   *(.__image_copy_start)
+   __image_copy_start = .;
board/qualcomm/dragonboard820c/head.o (.text*)
CPUDIR/start.o (.text*)
}
@@ -60,16 +60,9 @@ SECTIONS
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
 __efi_runtime_rel_stop = .;
+   __image_copy_end = .;
}

-   . = ALIGN(8);
-
-   

[RFC PATCH 5/6] arm: fix __efi_runtime_start/end definitions

[Ilias Apalodimas]

__efi_runtime_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing. On top of that
the v8 linker scripts define it as a symbol.

So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.

Signed-off-by: Ilias Apalodimas 
---
 arch/arm/cpu/u-boot.lds| 12 +++-
 arch/arm/lib/sections.c|  2 --
 arch/arm/mach-zynq/u-boot.lds  | 12 +++-
 include/asm-generic/sections.h |  1 +
 4 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 7c6e7891d360..df55bb716e35 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -43,18 +43,12 @@ SECTIONS
}

/* This needs to come before *(.text*) */
-   .__efi_runtime_start : {
-   *(.__efi_runtime_start)
-   }
-
-   .efi_runtime : {
+   .efi_runtime ALIGN(4) : {
+   __efi_runtime_start = .;
*(.text.efi_runtime*)
*(.rodata.efi_runtime*)
*(.data.efi_runtime*)
-   }
-
-   .__efi_runtime_stop : {
-   *(.__efi_runtime_stop)
+   __efi_runtime_stop = .;
}

.text_rest :
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 1ee3dd3667ba..a4d4202e99f5 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -25,6 +25,4 @@ char __secure_start[0] __section(".__secure_start");
 char __secure_end[0] __section(".__secure_end");
 char __secure_stack_start[0] __section(".__secure_stack_start");
 char __secure_stack_end[0] __section(".__secure_stack_end");
-char __efi_runtime_start[0] __section(".__efi_runtime_start");
-char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
 char _end[0] __section(".__end");
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index 71dea4a1f60a..fcd0f42a7106 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ b/arch/arm/mach-zynq/u-boot.lds
@@ -22,18 +22,12 @@ SECTIONS
}

/* This needs to come before *(.text*) */
-   .__efi_runtime_start : {
-   *(.__efi_runtime_start)
-   }
-
-   .efi_runtime : {
+   .efi_runtime ALIGN(4) : {
+   __efi_runtime_start = .;
*(.text.efi_runtime*)
*(.rodata.efi_runtime*)
*(.data.efi_runtime*)
-   }
-
-   .__efi_runtime_stop : {
-   *(.__efi_runtime_stop)
+   __efi_runtime_stop = .;
}

.text_rest :
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 60949200dd93..b6bca53db10d 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -35,6 +35,7 @@ extern char __priv_data_start[], __priv_data_end[];
 extern char __ctors_start[], __ctors_end[];

 extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
+extern char __efi_runtime_start[], __efi_runtime_stop[];

 /* function descriptor handling (if any).  Override
  * in asm/sections.h */
--
2.37.2

[RFC PATCH 4/6] arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end

[Ilias Apalodimas]

commit 47bd65ef057f ("arm: make __rel_dyn_{start, end} compiler-generated")
were moving the __rel_dyn_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code.

However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section [0].

[0] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC13

Signed-off-by: Ilias Apalodimas 
---
 arch/arm/cpu/armv8/u-boot.lds | 16 +++-
 arch/arm/cpu/u-boot.lds   | 14 +++---
 arch/arm/lib/sections.c   |  2 --
 arch/arm/mach-zynq/u-boot.lds | 14 +++---
 board/qualcomm/dragonboard820c/u-boot.lds | 15 +++
 5 files changed, 12 insertions(+), 49 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index eccb116d3cfa..e737de761a9d 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -129,20 +129,10 @@ SECTIONS
*(.__image_copy_end)
}

-   . = ALIGN(8);
-
-   .rel_dyn_start :
-   {
-   *(.__rel_dyn_start)
-   }
-
-   .rela.dyn : {
+   .rela.dyn ALIGN(8) : {
+   __rel_dyn_start = .;
*(.rela*)
-   }
-
-   .rel_dyn_end :
-   {
-   *(.__rel_dyn_end)
+   __rel_dyn_end = .;
}

_end = .;
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 70e78ce46672..7c6e7891d360 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -166,18 +166,10 @@ SECTIONS
*(.__image_copy_end)
}

-   .rel_dyn_start :
-   {
-   *(.__rel_dyn_start)
-   }
-
-   .rel.dyn : {
+   .rel.dyn ALIGN(4) : {
+   __rel_dyn_start = .;
*(.rel*)
-   }
-
-   .rel_dyn_end :
-   {
-   *(.__rel_dyn_end)
+   __rel_dyn_end = .;
}

.end :
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index ddfde52163fc..1ee3dd3667ba 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -21,8 +21,6 @@

 char __image_copy_start[0] __section(".__image_copy_start");
 char __image_copy_end[0] __section(".__image_copy_end");
-char __rel_dyn_start[0] __section(".__rel_dyn_start");
-char __rel_dyn_end[0] __section(".__rel_dyn_end");
 char __secure_start[0] __section(".__secure_start");
 char __secure_end[0] __section(".__secure_end");
 char __secure_stack_start[0] __section(".__secure_stack_start");
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index 66a9e37f9198..71dea4a1f60a 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ b/arch/arm/mach-zynq/u-boot.lds
@@ -71,18 +71,10 @@ SECTIONS
*(.__image_copy_end)
}

-   .rel_dyn_start :
-   {
-   *(.__rel_dyn_start)
-   }
-
-   .rel.dyn : {
+   .rel.dyn ALIGN(8) : {
+   __rel_dyn_start = .;
*(.rel*)
-   }
-
-   .rel_dyn_end :
-   {
-   *(.__rel_dyn_end)
+   __rel_dyn_end = .;
}

.end :
diff --git a/board/qualcomm/dragonboard820c/u-boot.lds 
b/board/qualcomm/dragonboard820c/u-boot.lds
index d3cc5278b610..2969f139bfd2 100644
--- a/board/qualcomm/dragonboard820c/u-boot.lds
+++ b/board/qualcomm/dragonboard820c/u-boot.lds
@@ -69,20 +69,11 @@ SECTIONS
*(.__image_copy_end)
}

-   . = ALIGN(8);
-
-   .rel_dyn_start :
-   {
-   *(.__rel_dyn_start)
-   }

-   .rela.dyn : {
+   .rela.dyn ALIGN(8) : {
+   __rel_dyn_start = .;
*(.rela*)
-   }
-
-   .rel_dyn_end :
-   {
-   *(.__rel_dyn_end)
+   __rel_dyn_end = .;
}

_end = .;
--
2.37.2

[RFC PATCH 3/6] arm: fix __efi_runtime_rel_start/end definitions

[Ilias Apalodimas]

__efi_runtime_rel_start/end are defined as c variables for arm7 only in
order to force the compiler emit relative references. However, defining
those within a section definition will do the same thing. On top of that
the v8 linker scripts define it as a symbol.

So let's remove the special sections from the linker scripts, the
variable definitions from sections.c and define them as a symbols within
the correct section.

Signed-off-by: Ilias Apalodimas 
---
 arch/arm/cpu/armv8/u-boot.lds  |  4 +---
 arch/arm/cpu/u-boot.lds| 16 +++-
 arch/arm/lib/sections.c|  2 --
 arch/arm/mach-zynq/u-boot.lds  | 16 +++-
 include/asm-generic/sections.h |  2 ++
 lib/efi_loader/efi_runtime.c   |  1 +
 6 files changed, 10 insertions(+), 31 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index c4ee10ebc3ff..eccb116d3cfa 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -115,9 +115,7 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}

-   . = ALIGN(8);
-
-   .efi_runtime_rel : {
+   .efi_runtime_rel ALIGN(8) : {
 __efi_runtime_rel_start = .;
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 90d329b1ebe0..70e78ce46672 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -152,21 +152,11 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}

-   . = ALIGN(4);
-
-   .efi_runtime_rel_start :
-   {
-   *(.__efi_runtime_rel_start)
-   }
-
-   .efi_runtime_rel : {
+   .efi_runtime_rel ALIGN(4) : {
+   __efi_runtime_rel_start = .;
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
-   }
-
-   .efi_runtime_rel_stop :
-   {
-   *(.__efi_runtime_rel_stop)
+   __efi_runtime_rel_stop = .;
}

. = ALIGN(4);
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 8e8bd5797e16..ddfde52163fc 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -29,6 +29,4 @@ char __secure_stack_start[0] 
__section(".__secure_stack_start");
 char __secure_stack_end[0] __section(".__secure_stack_end");
 char __efi_runtime_start[0] __section(".__efi_runtime_start");
 char __efi_runtime_stop[0] __section(".__efi_runtime_stop");
-char __efi_runtime_rel_start[0] __section(".__efi_runtime_rel_start");
-char __efi_runtime_rel_stop[0] __section(".__efi_runtime_rel_stop");
 char _end[0] __section(".__end");
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index 8d3259821719..66a9e37f9198 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ b/arch/arm/mach-zynq/u-boot.lds
@@ -58,21 +58,11 @@ SECTIONS
KEEP(*(SORT(__u_boot_list*)));
}

-   . = ALIGN(4);
-
-   .efi_runtime_rel_start :
-   {
-   *(.__efi_runtime_rel_start)
-   }
-
-   .efi_runtime_rel : {
+   .efi_runtime_rel ALIGN(4) : {
+   __efi_runtime_rel_start = .;
*(.rel*.efi_runtime)
*(.rel*.efi_runtime.*)
-   }
-
-   .efi_runtime_rel_stop :
-   {
-   *(.__efi_runtime_rel_stop)
+   __efi_runtime_rel_stop = .;
}

. = ALIGN(8);
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 1e1657a01673..60949200dd93 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -34,6 +34,8 @@ extern char __priv_data_start[], __priv_data_end[];
 /* Start and end of .ctors section - used for constructor calls. */
 extern char __ctors_start[], __ctors_end[];

+extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
+
 /* function descriptor handling (if any).  Override
  * in asm/sections.h */
 #ifndef dereference_function_descriptor
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 18da6892e796..9185f1894c47 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 

 /* For manual relocation support */
 DECLARE_GLOBAL_DATA_PTR;
--
2.37.2

[RFC PATCH 2/6] arm: clean up v7 and v8 linker scripts for bss_start/end

[Ilias Apalodimas]

commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ compiler-generated")
and
commit f84a7b8f54db ("ARM: Fix __bss_start and __bss_end in linker scripts")
were moving the bss_start/end on c generated variables that were
injected in their own sections. The reason was that we needed relative
relocations for position independent code.

However, the linker documentation pages states that symbols that are
defined within a section definition will create a relocatable
type with the value being a fixed offset from the base of a section.

So let's start cleaning this up starting with the bss_start and bss_end
variables. Convert them into symbols within the .bss section definition.

[0] https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_mono/ld.html#SEC13

Signed-off-by: Ilias Apalodimas 
---
 arch/arm/cpu/armv8/u-boot-spl.lds | 14 +++---
 arch/arm/cpu/armv8/u-boot.lds | 15 +++
 arch/arm/cpu/u-boot.lds   | 22 --
 arch/arm/lib/sections.c   |  2 --
 arch/arm/mach-rockchip/u-boot-tpl-v8.lds  | 14 +++---
 arch/arm/mach-zynq/u-boot.lds | 21 +++--
 board/qualcomm/dragonboard820c/u-boot.lds | 15 +++
 7 files changed, 19 insertions(+), 84 deletions(-)

diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index 7cb9d731246d..16fddb46e9cb 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -63,18 +63,10 @@ SECTIONS

_image_binary_end = .;

-   .bss_start (NOLOAD) : {
-   . = ALIGN(8);
-   KEEP(*(.__bss_start));
-   } >.sdram
-
-   .bss (NOLOAD) : {
+   .bss : {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(8);
-   } >.sdram
-
-   .bss_end (NOLOAD) : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
} >.sdram

/DISCARD/ : { *(.rela*) }
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index fb6a30c922f7..c4ee10ebc3ff 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -149,19 +149,10 @@ SECTIONS

_end = .;

-   . = ALIGN(8);
-
-   .bss_start : {
-   KEEP(*(.__bss_start));
-   }
-
-   .bss : {
+   .bss ALIGN(8): {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(8);
-   }
-
-   .bss_end : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
}

/DISCARD/ : { *(.dynsym) }
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 7724c9332c3b..90d329b1ebe0 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -206,27 +206,13 @@ SECTIONS
*(.mmutable)
}

-/*
- * Compiler-generated __bss_start and __bss_end, see arch/arm/lib/bss.c
- * __bss_base and __bss_limit are for linker only (overlay ordering)
- */
-
-   .bss_start __rel_dyn_start (OVERLAY) : {
-   KEEP(*(.__bss_start));
-   __bss_base = .;
-   }
-
-   .bss __bss_base (OVERLAY) : {
+   .bss ALIGN(4): {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(4);
-__bss_limit = .;
-   }
-
-   .bss_end __bss_limit (OVERLAY) : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
}

-   .dynsym _image_binary_end : { *(.dynsym) }
+   .dynsym  : { *(.dynsym) }
.dynbss : { *(.dynbss) }
.dynstr : { *(.dynstr*) }
.dynamic : { *(.dynamic*) }
diff --git a/arch/arm/lib/sections.c b/arch/arm/lib/sections.c
index 857879711c6a..8e8bd5797e16 100644
--- a/arch/arm/lib/sections.c
+++ b/arch/arm/lib/sections.c
@@ -19,8 +19,6 @@
  * aliasing warnings.
  */

-char __bss_start[0] __section(".__bss_start");
-char __bss_end[0] __section(".__bss_end");
 char __image_copy_start[0] __section(".__image_copy_start");
 char __image_copy_end[0] __section(".__image_copy_end");
 char __rel_dyn_start[0] __section(".__rel_dyn_start");
diff --git a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds 
b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
index 74618eba591b..b7887194026e 100644
--- a/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
+++ b/arch/arm/mach-rockchip/u-boot-tpl-v8.lds
@@ -56,18 +56,10 @@ SECTIONS

_image_binary_end = .;

-   .bss_start (NOLOAD) : {
-   . = ALIGN(8);
-   KEEP(*(.__bss_start));
-   }
-
-   .bss (NOLOAD) : {
+   .bss ALIGN(8) : {
+   __bss_start = .;
*(.bss*)
-. = ALIGN(8);
-   }
-
-   .bss_end (NOLOAD) : {
-   KEEP(*(.__bss_end));
+   __bss_end = .;
}

/DISCARD/ : { *(.dynsym) }
diff --git a/arch/arm/mach-zynq/u-boot.lds b/arch/arm/mach-zynq/u-boot.lds
index 3b7c9d515f8b..8d3259821719 100644
--- a/arch/arm/mach-zynq/u-boot.lds
+++ 

[RFC PATCH 1/6] arm: baltos: remove custom linker script

[Ilias Apalodimas]

commit 3d74a0977f514 ("ti: am335x: Remove unused linker script") removed
the linker script for the TI variant. This linker script doesn't seem to
do anything special and on top of that, has no definitions for the EFI
runtime sections.

So let's get rid of it and use the generic linker script which defines
those correctly

Signed-off-by: Ilias Apalodimas 
---
 board/vscom/baltos/u-boot.lds | 128 --
 1 file changed, 128 deletions(-)
 delete mode 100644 board/vscom/baltos/u-boot.lds

diff --git a/board/vscom/baltos/u-boot.lds b/board/vscom/baltos/u-boot.lds
deleted file mode 100644
index cb2ee6769753..
--- a/board/vscom/baltos/u-boot.lds
+++ /dev/null
@@ -1,128 +0,0 @@
-/*
- * Copyright (c) 2004-2008 Texas Instruments
- *
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering, 
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
-OUTPUT_ARCH(arm)
-ENTRY(_start)
-SECTIONS
-{
-   . = 0x;
-
-   . = ALIGN(4);
-   .text :
-   {
-   *(.__image_copy_start)
-   *(.vectors)
-   CPUDIR/start.o (.text*)
-   board/vscom/baltos/built-in.o (.text*)
-   *(.text*)
-   }
-
-   . = ALIGN(4);
-   .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
-   . = ALIGN(4);
-   .data : {
-   *(.data*)
-   }
-
-   . = ALIGN(4);
-
-   . = .;
-
-   . = ALIGN(4);
-   __u_boot_list : {
-   KEEP(*(SORT(__u_boot_list*)));
-   }
-
-   . = ALIGN(4);
-
-   .image_copy_end :
-   {
-   *(.__image_copy_end)
-   }
-
-   .rel_dyn_start :
-   {
-   *(.__rel_dyn_start)
-   }
-
-   .rel.dyn : {
-   *(.rel*)
-   }
-
-   .rel_dyn_end :
-   {
-   *(.__rel_dyn_end)
-   }
-
-   .hash : { *(.hash*) }
-
-   .end :
-   {
-   *(.__end)
-   }
-
-   _image_binary_end = .;
-
-   /*
-* Deprecated: this MMU section is used by pxa at present but
-* should not be used by new boards/CPUs.
-*/
-   . = ALIGN(4096);
-   .mmutable : {
-   *(.mmutable)
-   }
-
-/*
- * Compiler-generated __bss_start and __bss_end, see arch/arm/lib/bss.c
- * __bss_base and __bss_limit are for linker only (overlay ordering)
- */
-
-   .bss_start __rel_dyn_start (OVERLAY) : {
-   KEEP(*(.__bss_start));
-   __bss_base = .;
-   }
-
-   .bss __bss_base (OVERLAY) : {
-   *(.bss*)
-. = ALIGN(4);
-__bss_limit = .;
-   }
-
-   .bss_end __bss_limit (OVERLAY) : {
-   KEEP(*(.__bss_end));
-   }
-
-   .dynsym _image_binary_end : { *(.dynsym) }
-   .dynbss : { *(.dynbss) }
-   .dynstr : { *(.dynstr*) }
-   .dynamic : { *(.dynamic*) }
-   .gnu.hash : { *(.gnu.hash) }
-   .plt : { *(.plt*) }
-   .interp : { *(.interp*) }
-   .gnu : { *(.gnu*) }
-   .ARM.exidx : { *(.ARM.exidx*) }
-}
--
2.37.2

[RFC PATCH 0/6] Clean up arm linker scripts

[Ilias Apalodimas]

The arm linker scripts had a mix of symbols and C defined variables in an
effort to emit relative references instead of absolute ones e.g [0].
This has led to confusion over the years, ending up with mixed section
definitions. Some sections being defined with overlays and different
definitions between v7 and v8 architectures.
For example __efi_runtime_rel_start/end is defined as a linker symbol for
armv8 and a C variable in armv7.

I am not sure if this used to be a compiler bug, but linker scripts nowadays
can emit relative references, as long as the symbol definition is contained
within the section definition. So let's switch most of the C defined variables
and clean up the arm sections.c file. There's still a few symbols remaining --
__secure_start/end, __secure_stack_start/end and __end which can be cleaned up
in a followup series.

The resulting binary (tested in QEMU v7/v8) had no size differences apart from
the emited sections and object types of those variables. I've also added prints
throughout the U-Boot init sequence. The offsets and delta for 'end - start'
section sizes is unchanged.

For example on QEMU v8:
$~ ./scripts/bloat-o-meter u-boot u-boot.new
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function old new   delta
Total: Before=798861, After=798861, chg +0.00%

$~ readelf -sW u-boot | grep bss_s
12: 001029b8 0 SECTION LOCAL  DEFAULT   12 .bss_start
  8088: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
  8376: 001029b8 0 OBJECT  GLOBAL DEFAULT   12 __bss_start
$~ readelf -sW u-boot.new | grep bss_s
  8085: 0018 0 NOTYPE  GLOBAL DEFAULT1 _bss_start_ofs
  8373: 001029b8 0 NOTYPE  GLOBAL DEFAULT   12 __bss_start

For QEMU v7 the differences are a bit bigger but only affect the variables
placed in the .bss section because that was defined as an OVERLAY in the
existing linker script.
For example:
$~ nm u-boot | grep tftp_prev_block
000ca0dc ? tftp_prev_block
$~ nm u-boot.new | grep tftp_prev_block
000e0a5c b tftp_prev_block -> The symbol is now placed into .bss

It's worth noting that since the efi regions are affected by the change, booting
with EFI is preferable while testing. Booting the kernel only should be enough
since the efi stub and the kernel proper do request boottime and runtime
services respectively.
Something along the lines of
> virtio scan && load virtio 0 $kernel_addr_r Image && bootefi $kernel_addr_r
will work for QEMU aarch64.

Tested platforms:
- QEMU aarch64
- Xilinx kv260 kria starter kit & zynq
- QEMU armv7
- STM32MP157C-DK2

[0] commit 3ebd1cbc49f0 ("arm: make __bss_start and __bss_end__ 
compiler-generated")

Ilias Apalodimas (6):
  arm: baltos: remove custom linker script
  arm: clean up v7 and v8 linker scripts for bss_start/end
  arm: fix __efi_runtime_rel_start/end definitions
  arm: clean up v7 and v8 linker scripts for __rel_dyn_start/end
  arm: fix __efi_runtime_start/end definitions
  arm: move image_copy_start/end to linker symbols

 arch/arm/cpu/armv8/u-boot-spl.lds |  14 +--
 arch/arm/cpu/armv8/u-boot.lds |  45 ++--
 arch/arm/cpu/u-boot.lds   |  74 +++--
 arch/arm/lib/sections.c   |  10 --
 arch/arm/mach-rockchip/u-boot-tpl-v8.lds  |  22 +---
 arch/arm/mach-zynq/u-boot.lds |  72 +++-
 board/qualcomm/dragonboard820c/u-boot.lds |  41 ++-
 board/vscom/baltos/u-boot.lds | 128 --
 include/asm-generic/sections.h|   3 +
 lib/efi_loader/efi_runtime.c  |   1 +
 10 files changed, 58 insertions(+), 352 deletions(-)
 delete mode 100644 board/vscom/baltos/u-boot.lds

--
2.37.2

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

[Roger Quadros]

On 28/02/2024 12:35, MD Danish Anwar wrote:
> 
> 
> On 28/02/24 3:30 pm, Roger Quadros wrote:
>>
>>
>> On 17/02/2024 14:26, MD Danish Anwar wrote:
>>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>>> same firmware.
>>>
>>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>>> load the firmware file to the remote processor and start the remote
>>> processor.
>>>
>>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>>> driver.
>>>
>>> Signed-off-by: MD Danish Anwar 
>>> ---
>>> Changes from v4 to v5:
>>> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>>>that can be loaded to a rproc.
>>> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
>>> *) Allocating the address at a later point in rproc_boot()
>>> *) Rebased on latest u-boot/master [commit 
>>>9e00b6993f724da9699ef12573307afea8c19284]
>>>
>>> Changes from v3 to v4:
>>> *) No functional change. Splitted the patch out of the series as suggested
>>>by Nishant.
>>> *) Droppped the RFC tag.
>>>
>>> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
>>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>>
>>>  drivers/remoteproc/Kconfig|   8 +++
>>>  drivers/remoteproc/rproc-uclass.c | 100 ++
>>>  include/remoteproc.h  |  34 ++
>>>  3 files changed, 142 insertions(+)
>>>
>>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>>> index 781de530af..759d21437a 100644
>>> --- a/drivers/remoteproc/Kconfig
>>> +++ b/drivers/remoteproc/Kconfig
>>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>>  # All users should depend on DM
>>>  config REMOTEPROC
>>> bool
>>> +   select FS_LOADER
>>> depends on DM
>>>  
>>>  # Please keep the configuration alphabetically sorted.
>>> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>>> help
>>>   Say 'y' here to add support for TI' K3 remoteproc driver.
>>>  
>>> +config REMOTEPROC_MAX_FW_SIZE
>>> +   hex "Maximum size of firmware that needs to be loaded to rproc"
>>
>> firmware file?
>>
>> /rproc/the remote processor
>>
>>> +   default 0x1
>>> +   help
>>> + Maximum size of the firmware file (elf, binary) that needs to be
>>> + loaded to th rproc core.
>>
>> s/th/the
>> s/rproc/remote processor
>>
> 
> Will fix these typos.
> 
>>> +
>>>  endmenu
>>> diff --git a/drivers/remoteproc/rproc-uclass.c 
>>> b/drivers/remoteproc/rproc-uclass.c
>>> index 28b362c887..784361cef9 100644
>>> --- a/drivers/remoteproc/rproc-uclass.c
>>> +++ b/drivers/remoteproc/rproc-uclass.c
>>> @@ -13,6 +13,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct 
>>> udevice *dev, struct rproc *cfg)
>>>  
>>> return 1;
>>>  }
>>> +
>>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>>> +{
>>> +   struct dm_rproc_uclass_pdata *uc_pdata;
>>> +   int len;
>>> +   char *p;
>>> +
>>> +   if (!rproc_dev || !fw_name)
>>> +   return -EINVAL;
>>> +
>>> +   uc_pdata = dev_get_uclass_plat(rproc_dev);
>>> +   if (!uc_pdata)
>>> +   return -EINVAL;
>>> +
>>> +   len = strcspn(fw_name, "\n");
>>> +   if (!len) {
>>> +   debug("invalid firmware name\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   p = strndup(fw_name, len);
>>> +   if (!p)
>>> +   return -ENOMEM;
>>
>> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
>> Can we check if uc_pdata->fw_name exists and free it before the strndup?
>>
> 
> Sure, How does the below diff looks to you?
> 
> diff --git a/drivers/remoteproc/rproc-uclass.c
> b/drivers/remoteproc/rproc-uclass.c
> index 784361cef9..f373b64da4 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -982,6 +982,9 @@ int rproc_set_firmware(struct udevice *rproc_dev,
> const char *fw_name)
> return -EINVAL;
> }
> 
> +   if (uc_pdata->fw_name)
> +   free(uc_pdata->fw_name);
> +
> p = strndup(fw_name, len);
> if (!p)
> return -ENOMEM;

This is OK. Please see below.

> 
> 
>>> +
>>> +   uc_pdata->fw_name = p;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +int rproc_boot(struct udevice *rproc_dev)
>>> +{
>>> +   struct dm_rproc_uclass_pdata *uc_pdata;
>>> +   struct udevice *fs_loader;
>>> +   int core_id, ret = 0;
>>> +   char *firmware;
>>> +   void *addr;
>>> +
>>> +   if (!rproc_dev)
>>> +   return -EINVAL;
>>> +
>>> +   uc_pdata = dev_get_uclass_plat(rproc_dev);
>>> +   if (!uc_pdata)
>>> +   return 

[PATCH v2 2/2] net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework

[Roger Quadros]

Add a new Kconfig symbol MDIO_TI_CPSW for the CPSW MDIO
driver and build it with proper DM support if enabled.

If MDIO_TI_CPSW is not enabled then we continue to
behave like before.

Clean up MDIO custom handling in am65-cpsw and use
dm_eth_phy_connect() to get the PHY.

Signed-off-by: Roger Quadros 
---
Changelog:

v2: no change
---
 drivers/net/ti/Kconfig  |   8 ++
 drivers/net/ti/Makefile |   3 +-
 drivers/net/ti/am65-cpsw-nuss.c | 190 ++
 drivers/net/ti/cpsw_mdio.c  | 198 +++-
 drivers/net/ti/cpsw_mdio.h  |   2 +
 5 files changed, 196 insertions(+), 205 deletions(-)

diff --git a/drivers/net/ti/Kconfig b/drivers/net/ti/Kconfig
index c75f418628..72eccc99e5 100644
--- a/drivers/net/ti/Kconfig
+++ b/drivers/net/ti/Kconfig
@@ -45,7 +45,15 @@ config TI_AM65_CPSW_NUSS
imply MISC_INIT_R
imply MISC
imply SYSCON
+   imply MDIO_TI_CPSW
select PHYLIB
help
  This driver supports TI K3 MCU CPSW Nuss Ethernet controller
  in Texas Instruments K3 AM65x SoCs.
+
+config MDIO_TI_CPSW
+   bool "TI CPSW MDIO interface support"
+   depends on DM_MDIO
+   help
+ This driver supports the TI CPSW MDIO interface found in various
+ TI SoCs.
diff --git a/drivers/net/ti/Makefile b/drivers/net/ti/Makefile
index 0ce0cf2828..30c4c4b6d5 100644
--- a/drivers/net/ti/Makefile
+++ b/drivers/net/ti/Makefile
@@ -5,4 +5,5 @@
 obj-$(CONFIG_DRIVER_TI_CPSW) += cpsw.o cpsw-common.o cpsw_mdio.o
 obj-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
 obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o cpsw_mdio.o
-obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o cpsw_mdio.o
+obj-$(CONFIG_TI_AM65_CPSW_NUSS) += am65-cpsw-nuss.o
+obj-$(CONFIG_MDIO_TI_CPSW) += cpsw_mdio.o
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 6da018c0f9..d68ed67183 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -31,8 +31,6 @@
 #include 
 #include 
 
-#include "cpsw_mdio.h"
-
 #define AM65_CPSW_CPSWNU_MAX_PORTS 9
 
 #define AM65_CPSW_SS_BASE  0x0
@@ -113,7 +111,6 @@ struct am65_cpsw_common {
struct udevice  *dev;
fdt_addr_t  ss_base;
fdt_addr_t  cpsw_base;
-   fdt_addr_t  mdio_base;
fdt_addr_t  ale_base;
 
struct clk  fclk;
@@ -122,13 +119,8 @@ struct am65_cpsw_common {
u32 port_num;
struct am65_cpsw_port   ports[AM65_CPSW_CPSWNU_MAX_PORTS];
 
-   struct mii_dev  *bus;
u32 bus_freq;
 
-   struct gpio_descmdio_gpio_reset;
-   u32 reset_delay_us;
-   u32 reset_post_delay_us;
-
struct dma  dma_tx;
struct dma  dma_rx;
u32 rx_next;
@@ -140,13 +132,7 @@ struct am65_cpsw_priv {
struct udevice  *dev;
struct am65_cpsw_common *cpsw_common;
u32 port_id;
-
struct phy_device   *phydev;
-   boolhas_phy;
-   ofnode  phy_node;
-   u32 phy_addr;
-
-   boolmdio_manual_mode;
 };
 
 #ifdef PKTSIZE_ALIGN
@@ -622,111 +608,15 @@ static const struct eth_ops am65_cpsw_ops = {
.read_rom_hwaddr = am65_cpsw_read_rom_hwaddr,
 };
 
-static const struct soc_attr k3_mdio_soc_data[] = {
-   { .family = "AM62X", .revision = "SR1.0" },
-   { .family = "AM64X", .revision = "SR1.0" },
-   { .family = "AM64X", .revision = "SR2.0" },
-   { .family = "AM65X", .revision = "SR1.0" },
-   { .family = "AM65X", .revision = "SR2.0" },
-   { .family = "J7200", .revision = "SR1.0" },
-   { .family = "J7200", .revision = "SR2.0" },
-   { .family = "J721E", .revision = "SR1.0" },
-   { .family = "J721E", .revision = "SR1.1" },
-   { .family = "J721S2", .revision = "SR1.0" },
-   { /* sentinel */ },
-};
-
-static ofnode am65_cpsw_find_mdio(ofnode parent)
-{
-   ofnode node;
-
-   ofnode_for_each_subnode(node, parent)
-   if (ofnode_device_is_compatible(node, "ti,cpsw-mdio"))
-   return node;
-
-   return ofnode_null();
-}
-
-static int am65_cpsw_mdio_setup(struct udevice *dev)
-{
-   struct am65_cpsw_priv *priv = dev_get_priv(dev);
-   struct am65_cpsw_common *cpsw_common = priv->cpsw_common;
-   struct udevice *mdio_dev;
-   ofnode mdio;
-   int ret;
-
-   mdio = am65_cpsw_find_mdio(dev_ofnode(cpsw_common->dev));
-   if (!ofnode_valid(mdio))
-   return 0;
-
-   /*
-* The MDIO controller is represented in the DT binding by a
-* subnode of the MAC controller.
-*
-* We don't have a DM driver for the MDIO device yet, and thus 

[PATCH v2 1/2] net: mdio: Handle bus level GPIO Reset

[Roger Quadros]

Some platforms have bus level Reset controlled
by a GPIO line. If available then handle bus reset
via GPIO.

Signed-off-by: Roger Quadros 
---
Changelog:
v2:
- Fix build if DM_GPIO not set
- Fix build on platforms that don't have 
  by using 
---
 include/phy.h |  7 +++
 net/mdio-uclass.c | 37 -
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/include/phy.h b/include/phy.h
index e02cbdb58c..ae23814bbf 100644
--- a/include/phy.h
+++ b/include/phy.h
@@ -9,6 +9,7 @@
 #ifndef _PHY_H
 #define _PHY_H
 
+#include 
 #include 
 #include 
 #include 
@@ -76,6 +77,12 @@ struct mii_dev {
int (*reset)(struct mii_dev *bus);
struct phy_device *phymap[PHY_MAX_ADDR];
u32 phy_mask;
+   /** @reset_delay_us: Bus GPIO reset pulse width in microseconds */
+   int reset_delay_us;
+   /** @reset_post_delay_us: Bus GPIO reset deassert delay in microseconds 
*/
+   int reset_post_delay_us;
+   /** @reset_gpiod: Bus Reset GPIO descriptor pointer */
+   struct gpio_desc reset_gpiod;
 };
 
 /* struct phy_driver: a structure which defines PHY behavior
diff --git a/net/mdio-uclass.c b/net/mdio-uclass.c
index e758cc66d7..6fc7034111 100644
--- a/net/mdio-uclass.c
+++ b/net/mdio-uclass.c
@@ -14,6 +14,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define DEFAULT_GPIO_RESET_DELAY   10  /* in microseconds */
 
 void dm_mdio_probe_devices(void)
 {
@@ -80,6 +83,16 @@ int dm_mdio_write(struct udevice *mdio_dev, int addr, int 
devad, int reg,
 int dm_mdio_reset(struct udevice *mdio_dev)
 {
struct mdio_ops *ops = mdio_get_ops(mdio_dev);
+   struct mdio_perdev_priv *pdata = dev_get_uclass_priv(mdio_dev);
+   struct mii_dev *mii_bus = pdata->mii_bus;
+
+   if (CONFIG_IS_ENABLED(DM_GPIO) && 
dm_gpio_is_valid(_bus->reset_gpiod)) {
+   dm_gpio_set_value(_bus->reset_gpiod, 1);
+   udelay(mii_bus->reset_delay_us);
+   dm_gpio_set_value(_bus->reset_gpiod, 0);
+   if (mii_bus->reset_post_delay_us > 0)
+   udelay(mii_bus->reset_post_delay_us);
+   }
 
if (!ops->reset)
return 0;
@@ -111,14 +124,36 @@ static int mdio_reset(struct mii_dev *mii_bus)
 static int dm_mdio_post_probe(struct udevice *dev)
 {
struct mdio_perdev_priv *pdata = dev_get_uclass_priv(dev);
+   struct mii_dev *mii_bus;
+   int ret;
 
-   pdata->mii_bus = mdio_alloc();
+   mii_bus = mdio_alloc();
+   if (!mii_bus) {
+   dev_err(dev, "couldn't allocate mii_bus\n");
+   return -ENOMEM;
+   }
+   pdata->mii_bus = mii_bus;
pdata->mii_bus->read = mdio_read;
pdata->mii_bus->write = mdio_write;
pdata->mii_bus->reset = mdio_reset;
pdata->mii_bus->priv = dev;
strlcpy(pdata->mii_bus->name, dev->name, MDIO_NAME_LEN);
 
+   if (IS_ENABLED(CONFIG_DM_GPIO)) {
+   /* Get bus level PHY reset GPIO details */
+   mii_bus->reset_delay_us = dev_read_u32_default(dev, 
"reset-delay-us",
+  
DEFAULT_GPIO_RESET_DELAY);
+   mii_bus->reset_post_delay_us = dev_read_u32_default(dev,
+   
"reset-post-delay-us",
+   0);
+   ret = gpio_request_by_name(dev, "reset-gpios", 0, 
_bus->reset_gpiod,
+  GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+   if (ret && ret != -ENOENT) {
+   dev_err(dev, "couldn't get reset-gpios: %d\n", ret);
+   return ret;
+   }
+   }
+
return mdio_register(pdata->mii_bus);
 }
 

-- 
2.34.1

[PATCH v2 0/2] net: ti: am65-cpsw / cpsw-mdio: Switch to DM MDIO

[Roger Quadros]

Hi,

This converts cpsw-mdio into a proper Driver Model
driver and introduces the new Config symbol CONFIG_MDIO_TI_CPSW.

It also cleans up the am65-cpsw driver so it porperly uses
the DM PHY interface.

It does not convert the legacy cpsw and keystone-net drivers.

Tested on SK-AM62, SK-AM64, j721e_beagleboneai64 and AM335x BeagleBone.

CI tests: https://github.com/u-boot/u-boot/pull/493

Signed-off-by: Roger Quadros 
---
Changes in v2:
- Fix build if DM_GPIO not set.
- Fix build on platforms that don't define 
- Link to v1: 
https://lore.kernel.org/r/20240219-for-2024-07-am65-cpsw-mdio-v1-0-afe9aaba5...@kernel.org

---
Roger Quadros (2):
  net: mdio: Handle bus level GPIO Reset
  net: am65-cpsw: cpsw_mdio: Switch to proper DM_MDIO framework

 drivers/net/ti/Kconfig  |   8 ++
 drivers/net/ti/Makefile |   3 +-
 drivers/net/ti/am65-cpsw-nuss.c | 190 ++
 drivers/net/ti/cpsw_mdio.c  | 198 +++-
 drivers/net/ti/cpsw_mdio.h  |   2 +
 include/phy.h   |   7 ++
 net/mdio-uclass.c   |  37 +++-
 7 files changed, 239 insertions(+), 206 deletions(-)
---
base-commit: d49fa3defa50c6d3f04acbb52fd486c13c14ab6a
change-id: 20240216-for-2024-07-am65-cpsw-mdio-e3c15b297442

Best regards,
-- 
Roger Quadros 

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

[MD Danish Anwar]

On 28/02/24 3:30 pm, Roger Quadros wrote:
> 
> 
> On 17/02/2024 14:26, MD Danish Anwar wrote:
>> Add APIs to set a firmware_name to a rproc and boot the rproc with the
>> same firmware.
>>
>> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
>> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
>> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
>> load the firmware file to the remote processor and start the remote
>> processor.
>>
>> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
>> Kconfig so that we can call request_firmware_into_buf() from remoteproc
>> driver.
>>
>> Signed-off-by: MD Danish Anwar 
>> ---
>> Changes from v4 to v5:
>> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>>that can be loaded to a rproc.
>> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
>> *) Allocating the address at a later point in rproc_boot()
>> *) Rebased on latest u-boot/master [commit 
>>9e00b6993f724da9699ef12573307afea8c19284]
>>
>> Changes from v3 to v4:
>> *) No functional change. Splitted the patch out of the series as suggested
>>by Nishant.
>> *) Droppped the RFC tag.
>>
>> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
>> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
>>
>>  drivers/remoteproc/Kconfig|   8 +++
>>  drivers/remoteproc/rproc-uclass.c | 100 ++
>>  include/remoteproc.h  |  34 ++
>>  3 files changed, 142 insertions(+)
>>
>> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
>> index 781de530af..759d21437a 100644
>> --- a/drivers/remoteproc/Kconfig
>> +++ b/drivers/remoteproc/Kconfig
>> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>>  # All users should depend on DM
>>  config REMOTEPROC
>>  bool
>> +select FS_LOADER
>>  depends on DM
>>  
>>  # Please keep the configuration alphabetically sorted.
>> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>>  help
>>Say 'y' here to add support for TI' K3 remoteproc driver.
>>  
>> +config REMOTEPROC_MAX_FW_SIZE
>> +hex "Maximum size of firmware that needs to be loaded to rproc"
> 
> firmware file?
> 
> /rproc/the remote processor
> 
>> +default 0x1
>> +help
>> +  Maximum size of the firmware file (elf, binary) that needs to be
>> +  loaded to th rproc core.
> 
> s/th/the
> s/rproc/remote processor
> 

Will fix these typos.

>> +
>>  endmenu
>> diff --git a/drivers/remoteproc/rproc-uclass.c 
>> b/drivers/remoteproc/rproc-uclass.c
>> index 28b362c887..784361cef9 100644
>> --- a/drivers/remoteproc/rproc-uclass.c
>> +++ b/drivers/remoteproc/rproc-uclass.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct 
>> udevice *dev, struct rproc *cfg)
>>  
>>  return 1;
>>  }
>> +
>> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
>> +{
>> +struct dm_rproc_uclass_pdata *uc_pdata;
>> +int len;
>> +char *p;
>> +
>> +if (!rproc_dev || !fw_name)
>> +return -EINVAL;
>> +
>> +uc_pdata = dev_get_uclass_plat(rproc_dev);
>> +if (!uc_pdata)
>> +return -EINVAL;
>> +
>> +len = strcspn(fw_name, "\n");
>> +if (!len) {
>> +debug("invalid firmware name\n");
>> +return -EINVAL;
>> +}
>> +
>> +p = strndup(fw_name, len);
>> +if (!p)
>> +return -ENOMEM;
> 
> Aren't we leaking memory if rproc_set_firmware() is called multiple times?
> Can we check if uc_pdata->fw_name exists and free it before the strndup?
> 

Sure, How does the below diff looks to you?

diff --git a/drivers/remoteproc/rproc-uclass.c
b/drivers/remoteproc/rproc-uclass.c
index 784361cef9..f373b64da4 100644
--- a/drivers/remoteproc/rproc-uclass.c
+++ b/drivers/remoteproc/rproc-uclass.c
@@ -982,6 +982,9 @@ int rproc_set_firmware(struct udevice *rproc_dev,
const char *fw_name)
return -EINVAL;
}

+   if (uc_pdata->fw_name)
+   free(uc_pdata->fw_name);
+
p = strndup(fw_name, len);
if (!p)
return -ENOMEM;


>> +
>> +uc_pdata->fw_name = p;
>> +
>> +return 0;
>> +}
>> +
>> +int rproc_boot(struct udevice *rproc_dev)
>> +{
>> +struct dm_rproc_uclass_pdata *uc_pdata;
>> +struct udevice *fs_loader;
>> +int core_id, ret = 0;
>> +char *firmware;
>> +void *addr;
>> +
>> +if (!rproc_dev)
>> +return -EINVAL;
>> +
>> +uc_pdata = dev_get_uclass_plat(rproc_dev);
>> +if (!uc_pdata)
>> +return -EINVAL;
>> +
>> +core_id = dev_seq(rproc_dev);
>> +firmware = uc_pdata->fw_name;
>> +
> unnecessary blank line.
> 
>> +if (!firmware) {
>> +debug("No firmware set for rproc core %d\n", core_id);
> 

Re: [PATCH v5] remoteproc: uclass: Add methods to load firmware to rproc and boot rproc

[Roger Quadros]

On 17/02/2024 14:26, MD Danish Anwar wrote:
> Add APIs to set a firmware_name to a rproc and boot the rproc with the
> same firmware.
> 
> Clients can call rproc_set_firmware() API to set firmware_name for a rproc
> whereas rproc_boot() will load the firmware set by rproc_set_firmware() to
> a buffer by calling request_firmware_into_buf(). rproc_boot() will then
> load the firmware file to the remote processor and start the remote
> processor.
> 
> Also include "fs-loader.h" and make remoteproc driver select FS_LOADER in
> Kconfig so that we can call request_firmware_into_buf() from remoteproc
> driver.
> 
> Signed-off-by: MD Danish Anwar 
> ---
> Changes from v4 to v5:
> *) Added Kconfig option REMOTEPROC_MAX_FW_SIZE to set max firmware size
>that can be loaded to a rproc.
> *) Added freeing of address in rproc_boot() as pointed out by Ravi.
> *) Allocating the address at a later point in rproc_boot()
> *) Rebased on latest u-boot/master [commit 
>9e00b6993f724da9699ef12573307afea8c19284]
> 
> Changes from v3 to v4:
> *) No functional change. Splitted the patch out of the series as suggested
>by Nishant.
> *) Droppped the RFC tag.
> 
> v4: https://lore.kernel.org/all/20240130063322.2345057-1-danishan...@ti.com/
> v3: https://lore.kernel.org/all/20240124064930.1787929-4-danishan...@ti.com/
> 
>  drivers/remoteproc/Kconfig|   8 +++
>  drivers/remoteproc/rproc-uclass.c | 100 ++
>  include/remoteproc.h  |  34 ++
>  3 files changed, 142 insertions(+)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 781de530af..759d21437a 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -10,6 +10,7 @@ menu "Remote Processor drivers"
>  # All users should depend on DM
>  config REMOTEPROC
>   bool
> + select FS_LOADER
>   depends on DM
>  
>  # Please keep the configuration alphabetically sorted.
> @@ -102,4 +103,11 @@ config REMOTEPROC_TI_IPU
>   help
> Say 'y' here to add support for TI' K3 remoteproc driver.
>  
> +config REMOTEPROC_MAX_FW_SIZE
> + hex "Maximum size of firmware that needs to be loaded to rproc"

firmware file?

/rproc/the remote processor

> + default 0x1
> + help
> +   Maximum size of the firmware file (elf, binary) that needs to be
> +   loaded to th rproc core.

s/th/the
s/rproc/remote processor

> +
>  endmenu
> diff --git a/drivers/remoteproc/rproc-uclass.c 
> b/drivers/remoteproc/rproc-uclass.c
> index 28b362c887..784361cef9 100644
> --- a/drivers/remoteproc/rproc-uclass.c
> +++ b/drivers/remoteproc/rproc-uclass.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -961,3 +962,102 @@ unsigned long rproc_parse_resource_table(struct udevice 
> *dev, struct rproc *cfg)
>  
>   return 1;
>  }
> +
> +int rproc_set_firmware(struct udevice *rproc_dev, const char *fw_name)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + int len;
> + char *p;
> +
> + if (!rproc_dev || !fw_name)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + if (!uc_pdata)
> + return -EINVAL;
> +
> + len = strcspn(fw_name, "\n");
> + if (!len) {
> + debug("invalid firmware name\n");
> + return -EINVAL;
> + }
> +
> + p = strndup(fw_name, len);
> + if (!p)
> + return -ENOMEM;

Aren't we leaking memory if rproc_set_firmware() is called multiple times?
Can we check if uc_pdata->fw_name exists and free it before the strndup?

> +
> + uc_pdata->fw_name = p;
> +
> + return 0;
> +}
> +
> +int rproc_boot(struct udevice *rproc_dev)
> +{
> + struct dm_rproc_uclass_pdata *uc_pdata;
> + struct udevice *fs_loader;
> + int core_id, ret = 0;
> + char *firmware;
> + void *addr;
> +
> + if (!rproc_dev)
> + return -EINVAL;
> +
> + uc_pdata = dev_get_uclass_plat(rproc_dev);
> + if (!uc_pdata)
> + return -EINVAL;
> +
> + core_id = dev_seq(rproc_dev);
> + firmware = uc_pdata->fw_name;
> +
unnecessary blank line.

> + if (!firmware) {
> + debug("No firmware set for rproc core %d\n", core_id);

No firmware name...

> + return -EINVAL;
> + }
> +
> + /* Initialize all rproc cores */
> + if (!rproc_is_initialized()) {
> + ret = rproc_init();
> + if (ret) {
> + debug("rproc_init() failed: %d\n", ret);
> + return ret;
> + }
> + }
> +
> + /* Loading firmware to a given address */
> + ret = get_fs_loader(_loader);
> + if (ret) {
> + debug("could not get fs loader: %d\n", ret);
> + return ret;
> + }
> +
> + if (CONFIG_REMOTEPROC_MAX_FW_SIZE) {

if (defined(CONFIG_REMOTEPROC_MAX_FW_SIZE)) {

> + addr = malloc(CONFIG_REMOTEPROC_MAX_FW_SIZE);
> + 

Re: [PATCH v5] misc: fs-loader: Use fw_storage_interface instead of storage_interface

[Roger Quadros]

On 28/02/2024 11:02, MD Danish Anwar wrote:
> 
> On 27/02/24 7:33 pm, Sean Anderson wrote:
>> Hi Danish,
>>
>> On 2/27/24 05:26, MD Danish Anwar wrote:
>>> On 09/02/24 3:38 pm, MD Danish Anwar wrote:
 The fs-loader driver reads env storage_interface and uses it to load
 firmware file into memory using the medium set by env. Update the driver
 to use env fw_storage_interface as this variable is only used to load
 firmwares. This is to keep all variables used by fs-loader driver with
 'fw_' prefix. All other variables have 'fw_' prefix except for
 storage_interface.

 The env storage_interface will act as fallback so that the
 existing implementations do not break.

 Also update the FS Loader documentation accordingly.

 Signed-off-by: MD Danish Anwar 
 ---
>>>
>>> Hi Tom / Sean, can you please pick this patch if there is no pending
>>> comments to address.
>>>
>>
>> Sorry, I forgot to respond to this earlier.
>>
>> To be honest, I'm not really convinced. We have plenty of environmental
>> variables which are inconsistent (e.g. ethaddr, eth2addr, eth3addr) and it
>> doesn't cause any issues. While fixing code has no cost, the environment
>> is an ABI which we can't break. So we'd have to support both of these
>> variables forever. I'm not really a fan of doing that without good reason,
>> and I think aesthetics of the variable name isn't really compelling.
>>
> 
> Roger, should I keep the env variable name as it is and don't rename it?
> Sean's concern seems valid, can you please comment here.

Sure.

-- 
cheers,
-roger

Re: [PATCH] doc: board: phytec: phycore-am62x: Update artifact names

[Dhruva Gole]

Hi,

+ Tom

On 28/02/24 14:28, Wadim Egorov wrote:

Use proper binary artifact names for HSFS devices.
Do not use the *_unsigned binaries.

Signed-off-by: Wadim Egorov 
---



Reviewed-by: Dhruva Gole 


  doc/board/phytec/phycore-am62x.rst | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/board/phytec/phycore-am62x.rst 
b/doc/board/phytec/phycore-am62x.rst
index 1d641a78cf..bc6d524669 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -92,9 +92,9 @@ Assuming the uSD card is `/dev/mmcblk0`:
  To boot from a micro SD card on a HSFS device simply copy the following
  artifacts to the FAT partition:
  
-* tiboot3.bin from R5 build as tiboot3.bin

-* tispl.bin_unsigned from Cortex-A build as tispl.bin
-* u-boot.img_unsigned from Cortex-A build as u-boot.img
+* tiboot3.bin from R5 build
+* tispl.bin from Cortex-A build
+* u-boot.img from Cortex-A build


LGTM.


--
Thanks and Regards,
Dhruva Gole

Re: [PATCH v5] misc: fs-loader: Use fw_storage_interface instead of storage_interface

[MD Danish Anwar]

On 27/02/24 7:33 pm, Sean Anderson wrote:
> Hi Danish,
> 
> On 2/27/24 05:26, MD Danish Anwar wrote:
>> On 09/02/24 3:38 pm, MD Danish Anwar wrote:
>>> The fs-loader driver reads env storage_interface and uses it to load
>>> firmware file into memory using the medium set by env. Update the driver
>>> to use env fw_storage_interface as this variable is only used to load
>>> firmwares. This is to keep all variables used by fs-loader driver with
>>> 'fw_' prefix. All other variables have 'fw_' prefix except for
>>> storage_interface.
>>>
>>> The env storage_interface will act as fallback so that the
>>> existing implementations do not break.
>>>
>>> Also update the FS Loader documentation accordingly.
>>>
>>> Signed-off-by: MD Danish Anwar 
>>> ---
>>
>> Hi Tom / Sean, can you please pick this patch if there is no pending
>> comments to address.
>>
> 
> Sorry, I forgot to respond to this earlier.
> 
> To be honest, I'm not really convinced. We have plenty of environmental
> variables which are inconsistent (e.g. ethaddr, eth2addr, eth3addr) and it
> doesn't cause any issues. While fixing code has no cost, the environment
> is an ABI which we can't break. So we'd have to support both of these
> variables forever. I'm not really a fan of doing that without good reason,
> and I think aesthetics of the variable name isn't really compelling.
> 

Roger, should I keep the env variable name as it is and don't rename it?
Sean's concern seems valid, can you please comment here.

> --Sean

-- 
Thanks and Regards,
Danish

[PATCH] doc: board: phytec: phycore-am62x: Update artifact names

[Wadim Egorov]

Use proper binary artifact names for HSFS devices.
Do not use the *_unsigned binaries.

Signed-off-by: Wadim Egorov 
---
 doc/board/phytec/phycore-am62x.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/doc/board/phytec/phycore-am62x.rst 
b/doc/board/phytec/phycore-am62x.rst
index 1d641a78cf..bc6d524669 100644
--- a/doc/board/phytec/phycore-am62x.rst
+++ b/doc/board/phytec/phycore-am62x.rst
@@ -92,9 +92,9 @@ Assuming the uSD card is `/dev/mmcblk0`:
 To boot from a micro SD card on a HSFS device simply copy the following
 artifacts to the FAT partition:
 
-* tiboot3.bin from R5 build as tiboot3.bin
-* tispl.bin_unsigned from Cortex-A build as tispl.bin
-* u-boot.img_unsigned from Cortex-A build as u-boot.img
+* tiboot3.bin from R5 build
+* tispl.bin from Cortex-A build
+* u-boot.img from Cortex-A build
 
 Boot
 
-- 
2.34.1

[PATCH v3 2/2] doc: board: phytec: Add phyCORE-AM64x

[Wadim Egorov]

Add documentation for PHYTEC phyCORE-AM64x SoM.

Signed-off-by: Wadim Egorov 
Reviewed-by: Dhruva Gole 
---
 doc/board/phytec/index.rst |   1 +
 doc/board/phytec/phycore-am64x.rst | 159 +
 2 files changed, 160 insertions(+)
 create mode 100644 doc/board/phytec/phycore-am64x.rst

diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst
index fea0b07620..99848a9e95 100644
--- a/doc/board/phytec/index.rst
+++ b/doc/board/phytec/index.rst
@@ -9,5 +9,6 @@ PHYTEC
imx8mm-phygate-tauri-l
imx93-phyboard-segin
phycore-am62x
+   phycore-am64x
phycore-imx8mm
phycore-imx8mp
diff --git a/doc/board/phytec/phycore-am64x.rst 
b/doc/board/phytec/phycore-am64x.rst
new file mode 100644
index 00..a27ad01027
--- /dev/null
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -0,0 +1,159 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Wadim Egorov 
+
+phyCORE-AM64x
+=
+
+The `phyCORE-AM64x `_ is a
+SoM (System on Module) featuring TI's AM64x SoC. It can be used in combination
+with different carrier boards. This module can come with different sizes and
+models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM64x family.
+
+A development Kit, called `phyBOARD-Lyra 
`_
+is used as a carrier board reference design around the AM64x SoM.
+
+Quickstart
+--
+
+* Download sources and TI firmware blobs
+* Build Trusted Firmware-A
+* Build OP-TEE
+* Build U-Boot for the R5
+* Build U-Boot for the A53
+* Create bootable uSD Card
+* Boot
+
+Sources
+---
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure
+---
+
+Setup the environment variables:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR=phycore_am64x_r5_defconfig
+ $ export UBOOT_CFG_CORTEXA=phycore_am64x_a53_defconfig
+ $ export TFA_BOARD=lite
+ $ # we don't use any extra TFA parameters
+ $ unset TFA_EXTRA_ARGS
+ $ export OPTEE_PLATFORM=k3-am64x
+ # we don't use any extra OPTEE parameters
+ unset OPTEE_EXTRA_ARGS
+
+.. include::  ../ti/am62x_sk.rst
+:start-after: .. am62x_evm_rst_include_start_build_steps
+:end-before: .. am62x_evm_rst_include_end_build_steps
+
+uSD Card creation
+-
+
+Use fdisk to partition the uSD card. The layout should look similar to:
+
+.. code-block:: bash
+
+ $ sudo fdisk -l /dev/mmcblk0
+ Disk /dev/mmcblk0: 7.56 GiB, 8120172544 bytes, 15859712 sectors
+ Units: sectors of 1 * 512 = 512 bytes
+ Sector size (logical/physical): 512 bytes / 512 bytes
+ I/O size (minimum/optimal): 512 bytes / 512 bytes
+ Disklabel type: dos
+ Disk identifier: 0x6583d9a3
+
+ Device Boot  Start End Sectors   Size Id Type
+ /dev/mmcblk0p1 *  2048  264191  262144   128M  c W95 FAT32 (LBA)
+ /dev/mmcblk0p2  264192 1934953 1670762 815.8M 83 Linux
+
+
+Once partitioned, the boot partition has to be formatted with a FAT filesystem.
+Assuming the uSD card is `/dev/mmcblk0`:
+
+.. code-block:: bash
+
+ $ mkfs.vfat /dev/mmcblk0p1
+
+To boot from a micro SD card on a HSFS device simply copy the following
+artifacts to the FAT partition:
+
+* tiboot3.bin from R5 build
+* tispl.bin from Cortex-A build
+* u-boot.img from Cortex-A build
+
+Boot
+
+
+Put the uSD card in the slot on the board and apply power. Check the serial
+console for output.
+
+Flash to SPI NOR
+
+
+Below commands can be used to flash the SPI NOR flash; assuming
+tiboot3.bin, tispl.bin and u-boot.img are stored on the uSD card.
+
+.. code-block:: bash
+
+  sf probe
+  fatload mmc 1 ${loadaddr} tiboot3.bin
+  sf update $loadaddr 0x0 $filesize
+  fatload mmc 1 ${loadaddr} tispl.bin
+  sf update $loadaddr 0x8 $filesize
+  fatload mmc 1 ${loadaddr} u-boot.img
+  sf update $loadaddr 0x28 $filesize
+
+
+Boot Modes
+--
+
+The phyCORE-AM64x development kit supports booting from many different
+interfaces. By default, the development kit is set to boot from the micro-SD
+card. To change the boot device, DIP switches S5 and S6 can be used.
+Boot switches should be changed with power off.
+
+.. list-table:: Boot Modes
+   :widths: 16 16 16
+   :header-rows: 1
+
+   * - Switch Label
+ - SW3: 12345678
+ - SW4: 12345678
+
+   * - uSD
+ - 1110
+ - 0100
+
+   * - eMMC
+ - 11010010
+ - 
+
+   * - 

[PATCH v3 0/2] *** Add support for phyCORE-AM64x ***

[Wadim Egorov]

Add basic support for the phyCORE-AM64x.

v1: https://lists.denx.de/pipermail/u-boot/2024-January/544649.html
v2: https://lists.denx.de/pipermail/u-boot/2024-February/546757.html
v3:
  - Update doc to use proper binary artifacts for HSFS devices
  - Add Dhruva's Reviewed-by

Wadim Egorov (2):
  board: phytec: am64x: Add PHYTEC phyCORE-AM64x SoM
  doc: board: phytec: Add phyCORE-AM64x

 arch/arm/dts/Makefile |4 +-
 .../arm/dts/k3-am64-phycore-som-ddr4-2gb.dtsi | 2189 +
 arch/arm/dts/k3-am64-phycore-som.dtsi |  320 +++
 .../k3-am642-phyboard-electra-rdk-u-boot.dtsi |  147 ++
 .../arm/dts/k3-am642-phyboard-electra-rdk.dts |  302 +++
 arch/arm/dts/k3-am642-phycore-som-binman.dtsi |  457 
 arch/arm/dts/k3-am642-r5-phycore-som-2gb.dts  |  140 ++
 arch/arm/mach-k3/am64x/Kconfig|   19 +
 board/phytec/phycore_am64x/Kconfig|   33 +
 board/phytec/phycore_am64x/MAINTAINERS|   15 +
 board/phytec/phycore_am64x/Makefile   |9 +
 board/phytec/phycore_am64x/board-cfg.yaml |   36 +
 board/phytec/phycore_am64x/phycore-am64x.c|   50 +
 board/phytec/phycore_am64x/phycore_am64x.env  |   23 +
 board/phytec/phycore_am64x/pm-cfg.yaml|   12 +
 board/phytec/phycore_am64x/rm-cfg.yaml| 1215 +
 board/phytec/phycore_am64x/sec-cfg.yaml   |  379 +++
 configs/phycore_am64x_a53_defconfig   |  167 ++
 configs/phycore_am64x_r5_defconfig|  179 ++
 doc/board/phytec/index.rst|1 +
 doc/board/phytec/phycore-am64x.rst|  159 ++
 include/configs/phycore_am64x.h   |   15 +
 22 files changed, 5870 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/k3-am64-phycore-som-ddr4-2gb.dtsi
 create mode 100644 arch/arm/dts/k3-am64-phycore-som.dtsi
 create mode 100644 arch/arm/dts/k3-am642-phyboard-electra-rdk-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-am642-phyboard-electra-rdk.dts
 create mode 100644 arch/arm/dts/k3-am642-phycore-som-binman.dtsi
 create mode 100644 arch/arm/dts/k3-am642-r5-phycore-som-2gb.dts
 create mode 100644 board/phytec/phycore_am64x/Kconfig
 create mode 100644 board/phytec/phycore_am64x/MAINTAINERS
 create mode 100644 board/phytec/phycore_am64x/Makefile
 create mode 100644 board/phytec/phycore_am64x/board-cfg.yaml
 create mode 100644 board/phytec/phycore_am64x/phycore-am64x.c
 create mode 100644 board/phytec/phycore_am64x/phycore_am64x.env
 create mode 100644 board/phytec/phycore_am64x/pm-cfg.yaml
 create mode 100644 board/phytec/phycore_am64x/rm-cfg.yaml
 create mode 100644 board/phytec/phycore_am64x/sec-cfg.yaml
 create mode 100644 configs/phycore_am64x_a53_defconfig
 create mode 100644 configs/phycore_am64x_r5_defconfig
 create mode 100644 doc/board/phytec/phycore-am64x.rst
 create mode 100644 include/configs/phycore_am64x.h

-- 
2.34.1

Re: [PATCH v2 2/2] doc: board: phytec: Add phyCORE-AM64x

[Wadim Egorov]

Am 28.02.24 um 06:45 schrieb Dhruva Gole:

Hi,

On Feb 26, 2024 at 13:23:41 +0100, Wadim Egorov wrote:

Add documentation for PHYTEC phyCORE-AM64x SoM.

Signed-off-by: Wadim Egorov 
---
  doc/board/phytec/index.rst |   1 +
  doc/board/phytec/phycore-am64x.rst | 159 +
  2 files changed, 160 insertions(+)
  create mode 100644 doc/board/phytec/phycore-am64x.rst

diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst
index fea0b07620..99848a9e95 100644
--- a/doc/board/phytec/index.rst
+++ b/doc/board/phytec/index.rst
@@ -9,5 +9,6 @@ PHYTEC
 imx8mm-phygate-tauri-l
 imx93-phyboard-segin
 phycore-am62x
+   phycore-am64x
 phycore-imx8mm
 phycore-imx8mp
diff --git a/doc/board/phytec/phycore-am64x.rst 
b/doc/board/phytec/phycore-am64x.rst
new file mode 100644
index 00..202b756dc4
--- /dev/null
+++ b/doc/board/phytec/phycore-am64x.rst
@@ -0,0 +1,159 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. sectionauthor:: Wadim Egorov 
+
+phyCORE-AM64x
+=
+
+The `phyCORE-AM64x `_ is a
+SoM (System on Module) featuring TI's AM64x SoC. It can be used in combination
+with different carrier boards. This module can come with different sizes and
+models for DDR, eMMC, SPI NOR Flash and various SoCs from the AM64x family.
+
+A development Kit, called `phyBOARD-Lyra 
`_
+is used as a carrier board reference design around the AM64x SoM.
+
+Quickstart
+--
+
+* Download sources and TI firmware blobs
+* Build Trusted Firmware-A
+* Build OP-TEE
+* Build U-Boot for the R5
+* Build U-Boot for the A53
+* Create bootable uSD Card
+* Boot
+
+Sources
+---
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_boot_sources
+:end-before: .. k3_rst_include_end_boot_sources
+
+Build procedure
+---
+
+Setup the environment variables:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_desc
+:end-before: .. k3_rst_include_end_common_env_vars_desc
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_board_env_vars_desc
+:end-before: .. k3_rst_include_end_board_env_vars_desc
+
+Set the variables corresponding to this platform:
+
+.. include::  ../ti/k3.rst
+:start-after: .. k3_rst_include_start_common_env_vars_defn
+:end-before: .. k3_rst_include_end_common_env_vars_defn
+.. code-block:: bash
+
+ $ export UBOOT_CFG_CORTEXR=phycore_am64x_r5_defconfig
+ $ export UBOOT_CFG_CORTEXA=phycore_am64x_a53_defconfig
+ $ export TFA_BOARD=lite
+ $ # we don't use any extra TFA parameters
+ $ unset TFA_EXTRA_ARGS
+ $ export OPTEE_PLATFORM=k3-am64x
+ # we don't use any extra OPTEE parameters
+ unset OPTEE_EXTRA_ARGS
+
+.. include::  ../ti/am62x_sk.rst
+:start-after: .. am62x_evm_rst_include_start_build_steps
+:end-before: .. am62x_evm_rst_include_end_build_steps
+
+uSD Card creation
+-
+
+Use fdisk to partition the uSD card. The layout should look similar to:
+
+.. code-block:: bash
+
+ $ sudo fdisk -l /dev/mmcblk0
+ Disk /dev/mmcblk0: 7.56 GiB, 8120172544 bytes, 15859712 sectors
+ Units: sectors of 1 * 512 = 512 bytes
+ Sector size (logical/physical): 512 bytes / 512 bytes
+ I/O size (minimum/optimal): 512 bytes / 512 bytes
+ Disklabel type: dos
+ Disk identifier: 0x6583d9a3
+
+ Device Boot  Start End Sectors   Size Id Type
+ /dev/mmcblk0p1 *  2048  264191  262144   128M  c W95 FAT32 (LBA)
+ /dev/mmcblk0p2  264192 1934953 1670762 815.8M 83 Linux
+
+
+Once partitioned, the boot partition has to be formatted with a FAT filesystem.
+Assuming the uSD card is `/dev/mmcblk0`:
+
+.. code-block:: bash
+
+ $ mkfs.vfat /dev/mmcblk0p1
+
+To boot from a micro SD card on a HSFS device simply copy the following
+artifacts to the FAT partition:
+
+* tiboot3.bin from R5 build as tiboot3.bin
+* tispl.bin_unsigned from Cortex-A build as tispl.bin
+* u-boot.img_unsigned from Cortex-A build as u-boot.img

Is the _unsigned really required? I guess the regular tispl and
u-boot.img should also work right? It will just skip auth I guess.


No, it is not required. Copy it from phycore-am62x.rst.
Thanks, I will update both doc files.




[...]

Mostly looks good, thanks!
Reviewed-by: Dhruva Gole