date:20210713

Enable DM SATA, removed IDE driver, and add SATA MV driver.

Signed-off-by: Tony Dinh 
---

 include/configs/sheevaplug.h | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h
index 41ba799659..e28f98458e 100644
--- a/include/configs/sheevaplug.h
+++ b/include/configs/sheevaplug.h
@@ -53,10 +53,9 @@
 /*
  * SATA driver configuration
  */
-#ifdef CONFIG_IDE
-#define __io
-#define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET
-#define CONFIG_SYS_ATA_IDE1_OFFSET MV_SATA_PORT1_OFFSET
-#endif /* CONFIG_IDE */
+#ifdef CONFIG_SATA
+#define CONFIG_SYS_SATA_MAX_DEVICE 2
+#define CONFIG_LBA48
+#endif /* CONFIG_SATA */
 
 #endif /* _CONFIG_SHEEVAPLUG_H */
-- 
2.20.1

[PATCH 2/3] Marvell Sheevaplug: Use Ethernet PHY name and address from device tree

- In DM Ethernet, the old "egiga0" name is no longer valid, so replace it
with Ethernet PHY name from device tree. Also, Ethernet PHY address
is available so read it from device tree.

Signed-off-by: Tony Dinh 
---

 board/Marvell/sheevaplug/sheevaplug.c | 54 +--
 1 file changed, 42 insertions(+), 12 deletions(-)

diff --git a/board/Marvell/sheevaplug/sheevaplug.c 
b/board/Marvell/sheevaplug/sheevaplug.c
index 0cc7f2b392..7ba56a44e4 100644
--- a/board/Marvell/sheevaplug/sheevaplug.c
+++ b/board/Marvell/sheevaplug/sheevaplug.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
+ * Copyright (C) 2021  Tony Dinh 
  * (C) Copyright 2009
  * Marvell Semiconductor 
  * Written-by: Prafulla Wadaskar 
@@ -100,36 +101,65 @@ int board_init(void)
return 0;
 }
 
+static int fdt_get_phy_addr(const char *path)
+{
+   const void *fdt = gd->fdt_blob;
+   const u32 *reg;
+   const u32 *val;
+   int node, phandle, addr;
+
+   /* Find the node by its full path */
+   node = fdt_path_offset(fdt, path);
+   if (node >= 0) {
+   /* Look up phy-handle */
+   val = fdt_getprop(fdt, node, "phy-handle", NULL);
+   if (val) {
+   phandle = fdt32_to_cpu(*val);
+   if (!phandle)
+   return -1;
+   /* Follow it to its node */
+   node = fdt_node_offset_by_phandle(fdt, phandle);
+   if (node) {
+   /* Look up reg */
+   reg = fdt_getprop(fdt, node, "reg", NULL);
+   if (reg) {
+   addr = fdt32_to_cpu(*reg);
+   return addr;
+   }
+   }
+   }
+   }
+   return -1;
+}
+
 #ifdef CONFIG_RESET_PHY_R
 /* Configure and enable MV88E1116 PHY */
 void reset_phy(void)
 {
u16 reg;
-   u16 devadr;
-   char *name = "egiga0";
+   u16 phyaddr;
+   char *name = "ethernet-controller@72000";
+   char *eth0_path = 
"/ocp@f100/ethernet-controller@72000/ethernet0-port@0";
 
if (miiphy_set_current_dev(name))
return;
 
-   /* command to read PHY dev address */
-   if (miiphy_read(name, 0xEE, 0xEE, (u16 *) )) {
-   printf("Err..%s could not read PHY dev address\n",
-   __FUNCTION__);
+   phyaddr = fdt_get_phy_addr(eth0_path);
+   if (phyaddr < 0)
return;
-   }
 
/*
 * Enable RGMII delay on Tx and Rx for CPU port
 * Ref: sec 4.7.2 of chip datasheet
 */
-   miiphy_write(name, devadr, MV88E1116_PGADR_REG, 2);
-   miiphy_read(name, devadr, MV88E1116_MAC_CTRL_REG, );
+   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 2);
+   miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, );
reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
-   miiphy_write(name, devadr, MV88E1116_MAC_CTRL_REG, reg);
-   miiphy_write(name, devadr, MV88E1116_PGADR_REG, 0);
+   miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
+   miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 0);
 
/* reset the phy */
-   miiphy_reset(name, devadr);
+   miiphy_reset(name, phyaddr);
 
printf("88E1116 Initialized on %s\n", name);
 }
-- 
2.20.1

[PATCH 1/3] Marvell Sheevaplug: Add DM Ethernet and DM SATA configs

Add DM_ETH, SATA_MV and associated configs to sheevaplug_defconfig

Signed-off-by: Tony Dinh 
---

 configs/sheevaplug_defconfig | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/configs/sheevaplug_defconfig b/configs/sheevaplug_defconfig
index 676c47af27..4c7259e6d7 100644
--- a/configs/sheevaplug_defconfig
+++ b/configs/sheevaplug_defconfig
@@ -17,7 +17,6 @@ CONFIG_USE_PREBOOT=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_FLASH is not set
-CONFIG_CMD_IDE=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
 CONFIG_CMD_USB=y
@@ -53,3 +52,8 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_STORAGE=y
 CONFIG_LZMA=y
 CONFIG_BZIP2=y
+CONFIG_BLK=y
+CONFIG_DM_ETH=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_CMD_SATA=y
+CONFIG_SATA_MV=y
-- 
2.20.1

[PATCH 0/3] Marvell SheevaPlug : convert Ethernet and SATA to Driver Model.



- Add DM_ETH, SATA_MV and associated configs to sheevaplug_defconfig
- Remove IDE, and add SATA configs in board file sheevaplug.h
- Replace old device name "egiga0" with Ethernet PHY name from device
tree.
- Replace the old Ethernet PHY addr lookup with a device tree parsing
lookup function. Note that all Kirkwood SoCs boards use the same binding
for Ethernet port 0 and 1 nodes from kirkwood.dtsi. Thus the new lookup
function fdt_get_phy_addr() in this patch series probably should be
factored out to a common fdt support function and used in other
Kirkwood boards.


Tony Dinh (3):
  Marvell Sheevaplug: Add DM Ethernet and DM SATA configs
  Marvell Sheevaplug: Use Ethernet PHY name and address from device tree
  Marvell Sheevaplug: Add DM SATA and remove IDE configs

 board/Marvell/sheevaplug/sheevaplug.c | 54 +--
 configs/sheevaplug_defconfig  |  6 ++-
 include/configs/sheevaplug.h  |  9 ++---
 3 files changed, 51 insertions(+), 18 deletions(-)

-- 
2.20.1

Re: U-Boot: Arm64: bootm gets stuck if RANDOMIZE_BASE is disabled

2021-07-13 Thread Ahsan Hussain




On 7/13/21 2:25 PM, Mark Rutland wrote:

On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:

Hello,

I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot
when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've
verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.MX8QXP)
and the results remain consistent.

I'm able to boot kernel when I use booti command. However when I use bootm
to boot a U-Boot fitImage (with kernel and fdt load addresses/entrypoint in
.its file same as I used for booti command; also tried disabling relocation
for fdt by setting fdt_high=~0UL), the boot gets stuck at "Starting kernel
...". On disabling RANDOMIZE_BASE kconfig in Linux the same fitImage is able
to boot.

Can you say which address you're trying to load the kernel to?
At 0xf000, towards the end of first DRAM bank which starts at 
0x4000.

I've tried enabling earlycon and U-Boot debug messages in common/bootm.c and
arch/arm/lib/bootm.c but found no helpful difference in both boot flows.
Please let me know if I'm missing something obvious or where do I start
looking to debug this issue.

IIUC, the booti command respects the text_offset from the kernel header,
whereas bootm will not. If you have a hard-coded offset, it's possible
you're violating the offset the kernel expects, and where the kernel is
not relocatable, if can't fix itself up.


A minor correction is that when CONFIG_RANDOMIZE_BASE is _enabled_ the 
issue is gone. It is only observed when RANDOMIZE_BASE is _disabled_. 
Both booti and bootm calculate text_offset the same way based on arm64 
image header->image_size field, in booti_setup() routine from U-Boot 
arch/arm/lib/image.c.



Regards,
Ahsan

Re: U-Boot: Arm64: bootm gets stuck if RANDOMIZE_BASE is disabled

2021-07-13 Thread Mark Rutland

On Tue, Jul 13, 2021 at 02:15:08PM +0500, Ahsan Hussain wrote:
> Hello,
> 
> I'm dumbfounded by a seemingly unrelated early kernel hang/failing to boot
> when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT uImage. I've
> verified this behavior on a couple of i.MX8 SoCs (i.MX8M plus and i.MX8QXP)
> and the results remain consistent.
> 
> I'm able to boot kernel when I use booti command. However when I use bootm
> to boot a U-Boot fitImage (with kernel and fdt load addresses/entrypoint in
> .its file same as I used for booti command; also tried disabling relocation
> for fdt by setting fdt_high=~0UL), the boot gets stuck at "Starting kernel
> ...". On disabling RANDOMIZE_BASE kconfig in Linux the same fitImage is able
> to boot.

Can you say which address you're trying to load the kernel to?

> I've tried enabling earlycon and U-Boot debug messages in common/bootm.c and
> arch/arm/lib/bootm.c but found no helpful difference in both boot flows.
> Please let me know if I'm missing something obvious or where do I start
> looking to debug this issue.

IIUC, the booti command respects the text_offset from the kernel header,
whereas bootm will not. If you have a hard-coded offset, it's possible
you're violating the offset the kernel expects, and where the kernel is
not relocatable, if can't fix itself up.

I suspect you have a hard-coded offset of 0x8, whereas recent
kernels have a text offset of 0x0. Your bootloader *should* read
this dynamially rather than hard-coding it.

For details, see:

https://www.kernel.org/doc/html/v5.4/arm64/booting.html#call-the-kernel-image

Thanks,
Mark.

U-Boot: Arm64: bootm gets stuck if RANDOMIZE_BASE is disabled

2021-07-13 Thread Ahsan Hussain


Hello,

I'm dumbfounded by a seemingly unrelated early kernel hang/failing to 
boot when CONFIG_RANDOMIZE_BASE=n is set in kernel and we use FIT 
uImage. I've verified this behavior on a couple of i.MX8 SoCs (i.MX8M 
plus and i.MX8QXP) and the results remain consistent.


I'm able to boot kernel when I use booti command. However when I use 
bootm to boot a U-Boot fitImage (with kernel and fdt load 
addresses/entrypoint in .its file same as I used for booti command; also 
tried disabling relocation for fdt by setting fdt_high=~0UL), the boot 
gets stuck at "Starting kernel ...". On disabling RANDOMIZE_BASE kconfig 
in Linux the same fitImage is able to boot.


I've tried enabling earlycon and U-Boot debug messages in common/bootm.c 
and arch/arm/lib/bootm.c but found no helpful difference in both boot 
flows. Please let me know if I'm missing something obvious or where do I 
start looking to debug this issue.


Best regards,
Ehson

Re: [PATCH 2/2] tpm2: Add a TPMv2 MMIO TIS driver

Hi Ilias,

On Tue, 13 Jul 2021 at 14:11, Ilias Apalodimas
 wrote:
>
>
> [...]
> > > > Should be a uclass interface.
> > > >
> > >
> > > Why? A uclass is supposed to describe and abstract hardware.  This is just
> > > a specific implementation of a TPM, not all TPMs are TIS compliant. We 
> > > already
> > > have a uclass for those.
> >
> > Who told you that a uclass is supposed to describe and abstract hardware? 
> > :-)
> >
>
> That's what I've mostly seen it used for, maybe i got the idea wrong.

A uclass is basically a software construct. It is an interface between
clients and the driver, typically. Quite often the uclass is an
interface on top of the hardware (actually the driver). But quite
often it is not. For example, we use an GPIO uclass to access a pmic's
GPIOs, we use an I2C uclass to access the cros_ec I2C tunnel. Anywhere
where it makes sense to have an abstraction, we use a uclass.

>
> > The uclass is how driver model does APIs, so normally a uclass would
> > be used for any API. There are exceptions, but this one actually looks
> > like a useful interface we should have.
> >
>
> the point is we already have a uclass for tpm devices.  So why should the
> we add another one that just describes the TIS interface?

You have already added another API, right? All we are discussing is
whether it should be a uclass or not. Unless there is a very good
reason, we should avoid creating custom interfaces that don't use
driver model. I actually think the interface you've created (MMIO)
will be very useful as a uclass.

[..]

Regards,
Simon

Re: [PATCH 3/5] efi_loader: add boot variable measurement

2021-07-13 Thread Masahisa Kojima

Hi Heinrich, Akashi-san,

Thank you for your comment.
I will keep current implementation.

Thanks,
Masahisa Kojima

On Wed, 14 Jul 2021 at 08:54, AKASHI Takahiro
 wrote:
>
> On Tue, Jul 13, 2021 at 04:24:52PM +0200, Heinrich Schuchardt wrote:
> >
> >
> > On 13.07.21 10:31, Masahisa Kojima wrote:
> > > Hi Heinrich,
> > >
> > > > > > TCG spec also requires to measure "Calling EFI Application from
> > > > > > Boot Option" for each boot attempt, and "Returning from EFI
> > > > > > Application from Boot Option" if a boot device returns control
> > > > > > back to the Boot Manager.
> > >
> > > I would like to hear your opinion regarding
> > > "Calling EFI Application from Boot Option" measurement.
> > >
> > > My current(v1 patch series) implementation considers
> > > both "bootefi bootmgr" and "bootefi $image_addr" cases,
> > > so I do this "Calling EFI Application from Boot Option" measurement
> > > at efi_boottime.c::efi_start_image().
> > > Do I need to implement only the case UEFI application boot from bootmgr?
> > > If yes, I will move the timing of this measurement at
> > > efi_bootmgr.c::efi_bootmgr_load().
> > >
> > > As a reference, in edk2, this measurement is performed in
> > > ready_to_boot event handler, ready_to_boot handler is called
> > > upon the user selects the boot option in boot manager.
> >
> > When booting you can call
> >
> >bootefi $driver1
> >booefii $driver2
> >bootefi bootmgr
> >
> > in sequence.
> >
> > Any of the binaries can call LoadImage(), StartImage() multiple times to
> > execute further images. E.g. I am loading iPXE. By default it loads GRUB
> > from an iSCSI drive but I can choose in the menu or the iPXE console to
> > invoke another UEFI binary.
> >
> > I suggest to measure any image no matter how it is invoked. The
> > measurement must depend on the sequence of invocation.
>
> Moreover,
> booting from the default path, like /EFI/BOOT/BOOTAA64.EFI,
> is only implemented by using bootefi  syntax.
>
> -Takahiro Akashi
>
>
> > Best regards
> >
> > Heinrich
> >
> > >
> > > What do you think?
> > >
> > > Thanks,
> > > Masahisa Kojima
> > >
> > >
> > >
> > >
> > >
> > > On Fri, 9 Jul 2021 at 11:44, Masahisa Kojima  
> > > wrote:
> > > >
> > > > On Fri, 9 Jul 2021 at 02:46, Heinrich Schuchardt  
> > > > wrote:
> > > > >
> > > > > On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> > > > > > TCG PC Client PFP spec requires to measure "Boot"
> > > > > > and "BootOrder" variables, EV_SEPARATOR event prior
> > > > > > to the Ready to Boot invocation.
> > > > > > Since u-boot does not implement Ready to Boot event,
> > > > > > these measurements are performed when efi_start_image() is called.
> > > > > >
> > > > > > TCG spec also requires to measure "Calling EFI Application from
> > > > > > Boot Option" for each boot attempt, and "Returning from EFI
> > > > > > Application from Boot Option" if a boot device returns control
> > > > > > back to the Boot Manager.
> > > > > >
> > > > > > Signed-off-by: Masahisa Kojima 
> > > > > > ---
> > > > > >include/efi_loader.h  |   4 ++
> > > > > >include/tpm-v2.h  |  18 -
> > > > > >lib/efi_loader/efi_boottime.c |  20 ++
> > > > > >lib/efi_loader/efi_tcg2.c | 123 
> > > > > > ++
> > > > > >4 files changed, 164 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > > > > index 0a9c82a257..28130f 100644
> > > > > > --- a/include/efi_loader.h
> > > > > > +++ b/include/efi_loader.h
> > > > > > @@ -407,6 +407,10 @@ efi_status_t efi_run_image(void 
> > > > > > *source_buffer, efi_uintn_t source_size);
> > > > > >efi_status_t efi_init_variables(void);
> > > > > >/* Notify ExitBootServices() is called */
> > > > > >void efi_variables_boot_exit_notify(void);
> > > > > > +/* Measure efi application invocation */
> > > > > > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_invocation(void);
> > > > > > +/* Measure efi application exit */
> > > > > > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void);
> > > > > >/* Called by bootefi to initialize root node */
> > > > > >efi_status_t efi_root_node_register(void);
> > > > > >/* Called by bootefi to initialize runtime */
> > > > > > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > > > > > index 3e48e35861..8a7b7f1874 100644
> > > > > > --- a/include/tpm-v2.h
> > > > > > +++ b/include/tpm-v2.h
> > > > > > @@ -73,7 +73,7 @@ struct udevice;
> > > > > >/*
> > > > > > * event types, cf.
> > > > > > * "TCG PC Client Platform Firmware Profile Specification", 
> > > > > > Family "2.0"
> > > > > > - * rev 1.04, June 3, 2019
> > > > > > + * Level 00 Version 1.05 Revision 23, May 7, 2021
> > > > > > */
> > > > > >#define EV_EFI_EVENT_BASE   ((u32)0x8000)
> > > > > >#define EV_EFI_VARIABLE_DRIVER_CONFIG   
> > > > > > ((u32)0x8001)
> > > > > > @@ -85,8 +85,24 @@ struct udevice;
>

Re: [PATCH 3/5] efi_loader: add boot variable measurement

2021-07-13 Thread AKASHI Takahiro

On Tue, Jul 13, 2021 at 04:24:52PM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 13.07.21 10:31, Masahisa Kojima wrote:
> > Hi Heinrich,
> > 
> > > > > TCG spec also requires to measure "Calling EFI Application from
> > > > > Boot Option" for each boot attempt, and "Returning from EFI
> > > > > Application from Boot Option" if a boot device returns control
> > > > > back to the Boot Manager.
> > 
> > I would like to hear your opinion regarding
> > "Calling EFI Application from Boot Option" measurement.
> > 
> > My current(v1 patch series) implementation considers
> > both "bootefi bootmgr" and "bootefi $image_addr" cases,
> > so I do this "Calling EFI Application from Boot Option" measurement
> > at efi_boottime.c::efi_start_image().
> > Do I need to implement only the case UEFI application boot from bootmgr?
> > If yes, I will move the timing of this measurement at
> > efi_bootmgr.c::efi_bootmgr_load().
> > 
> > As a reference, in edk2, this measurement is performed in
> > ready_to_boot event handler, ready_to_boot handler is called
> > upon the user selects the boot option in boot manager.
> 
> When booting you can call
> 
>bootefi $driver1
>booefii $driver2
>bootefi bootmgr
> 
> in sequence.
> 
> Any of the binaries can call LoadImage(), StartImage() multiple times to
> execute further images. E.g. I am loading iPXE. By default it loads GRUB
> from an iSCSI drive but I can choose in the menu or the iPXE console to
> invoke another UEFI binary.
> 
> I suggest to measure any image no matter how it is invoked. The
> measurement must depend on the sequence of invocation.

Moreover,
booting from the default path, like /EFI/BOOT/BOOTAA64.EFI,
is only implemented by using bootefi  syntax.

-Takahiro Akashi


> Best regards
> 
> Heinrich
> 
> > 
> > What do you think?
> > 
> > Thanks,
> > Masahisa Kojima
> > 
> > 
> > 
> > 
> > 
> > On Fri, 9 Jul 2021 at 11:44, Masahisa Kojima  
> > wrote:
> > > 
> > > On Fri, 9 Jul 2021 at 02:46, Heinrich Schuchardt  
> > > wrote:
> > > > 
> > > > On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> > > > > TCG PC Client PFP spec requires to measure "Boot"
> > > > > and "BootOrder" variables, EV_SEPARATOR event prior
> > > > > to the Ready to Boot invocation.
> > > > > Since u-boot does not implement Ready to Boot event,
> > > > > these measurements are performed when efi_start_image() is called.
> > > > > 
> > > > > TCG spec also requires to measure "Calling EFI Application from
> > > > > Boot Option" for each boot attempt, and "Returning from EFI
> > > > > Application from Boot Option" if a boot device returns control
> > > > > back to the Boot Manager.
> > > > > 
> > > > > Signed-off-by: Masahisa Kojima 
> > > > > ---
> > > > >include/efi_loader.h  |   4 ++
> > > > >include/tpm-v2.h  |  18 -
> > > > >lib/efi_loader/efi_boottime.c |  20 ++
> > > > >lib/efi_loader/efi_tcg2.c | 123 
> > > > > ++
> > > > >4 files changed, 164 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > > > index 0a9c82a257..28130f 100644
> > > > > --- a/include/efi_loader.h
> > > > > +++ b/include/efi_loader.h
> > > > > @@ -407,6 +407,10 @@ efi_status_t efi_run_image(void *source_buffer, 
> > > > > efi_uintn_t source_size);
> > > > >efi_status_t efi_init_variables(void);
> > > > >/* Notify ExitBootServices() is called */
> > > > >void efi_variables_boot_exit_notify(void);
> > > > > +/* Measure efi application invocation */
> > > > > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_invocation(void);
> > > > > +/* Measure efi application exit */
> > > > > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void);
> > > > >/* Called by bootefi to initialize root node */
> > > > >efi_status_t efi_root_node_register(void);
> > > > >/* Called by bootefi to initialize runtime */
> > > > > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > > > > index 3e48e35861..8a7b7f1874 100644
> > > > > --- a/include/tpm-v2.h
> > > > > +++ b/include/tpm-v2.h
> > > > > @@ -73,7 +73,7 @@ struct udevice;
> > > > >/*
> > > > > * event types, cf.
> > > > > * "TCG PC Client Platform Firmware Profile Specification", Family 
> > > > > "2.0"
> > > > > - * rev 1.04, June 3, 2019
> > > > > + * Level 00 Version 1.05 Revision 23, May 7, 2021
> > > > > */
> > > > >#define EV_EFI_EVENT_BASE   ((u32)0x8000)
> > > > >#define EV_EFI_VARIABLE_DRIVER_CONFIG   
> > > > > ((u32)0x8001)
> > > > > @@ -85,8 +85,24 @@ struct udevice;
> > > > >#define EV_EFI_ACTION   
> > > > > ((u32)0x8007)
> > > > >#define EV_EFI_PLATFORM_FIRMWARE_BLOB   
> > > > > ((u32)0x8008)
> > > > >#define EV_EFI_HANDOFF_TABLES   
> > > > > ((u32)0x8009)
> > > > > +#define EV_EFI_PLATFORM_FIRMWARE_BLOB2   
> > > > > ((u32)0x800A)
> > > > >

Re: [PATCH] efi_loader: Fix to set bootdev_root correctly if bootdev found

2021-07-13 Thread Masami Hiramatsu

Hi Heinrich,

2021年7月13日(火) 2:40 Heinrich Schuchardt :
>
> On 7/12/21 11:05 AM, Masami Hiramatsu wrote:
> > Fix find_boot_device() to set bootdev_root if it finds the
> > bootdev from BootNext. Currently it sets the bootdev_root only
> > when it finds bootdev from BootOrder.
> >
> > Fixes: c74cd8bd08d1 ("efi_loader: capsule: add capsule_on_disk support")
> > Signed-off-by: Masami Hiramatsu 
> > ---
> >   lib/efi_loader/efi_capsule.c |3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index 50bed32bfb..b736f4ef9e 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -632,7 +632,7 @@ static efi_status_t find_boot_device(void)
> >   ret = get_dp_device(boot_var16, _dev);
> >   if (ret == EFI_SUCCESS) {
> >   if (device_is_present_and_system_part(boot_dev)) {
> > - goto out;
> > + goto found;
> >   } else {
> >   efi_free_pool(boot_dev);
> >   boot_dev = NULL;
> > @@ -675,6 +675,7 @@ skip:
> >   efi_free_pool(boot_dev);
> >   boot_dev = NULL;
> >   }
> > +found:
> >   if (boot_dev) {
> >   u16 *path_str;
>
> The code that follows should be reworked too:
>
> 
> u16 *path_str;
>
> path_str = efi_dp_str(boot_dev);
> log_debug("Boot device %ls\n", path_str);
> efi_free_pool(path_str);
> 
>
> Use log-debug("Boot device %pD\n", boot_dev); instead.
>
> But that is work for a separate patch.

OK, let me fix that.

>
> Reviewed-by: Heinrich Schuchardt 

Thank you!

>
> >
> >
>


-- 
Masami Hiramatsu

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

On Tue, Jul 13, 2021 at 10:35:03PM +0200, Marek Vasut wrote:
> On 7/13/21 8:11 PM, Tom Rini wrote:
> > On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
> > > On 7/13/21 6:47 PM, Simon Glass wrote:
> > > > Hi Marek,
> > > > 
> > > > On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:
> > > > > 
> > > > > On 7/13/21 4:41 PM, Tom Rini wrote:
> > > > > > On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
> > > > > > > On 7/13/21 3:47 PM, Tom Rini wrote:
> > > > > > > > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
> > > > > > > > > On 7/12/21 10:15 AM, Tom Rini wrote:
> > > > > > > > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
> > > > > > > > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > I submitted an almost identical patch. See 
> > > > > > > > > > > > https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
> > > > > > > > > > > > 
> > > > > > > > > > > > This patch eventually had to be reverted 
> > > > > > > > > > > > (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
> > > > > > > > > > > >  because it was causing issues on some platforms that 
> > > > > > > > > > > > had FIT on 32 bit boundary. However I continue to use 
> > > > > > > > > > > > it in production code, as without it the boot on my 
> > > > > > > > > > > > platform aborts.
> > > > > > > > > > > > 
> > > > > > > > > > > > I don't have time to investigate why this was 
> > > > > > > > > > > > happening, but you need to check this code won't just 
> > > > > > > > > > > > cause exactly the same faults.
> > > > > > > > > > > 
> > > > > > > > > > > Thanks for your information.
> > > > > > > > > > > 
> > > > > > > > > > > +Marek who did the revert
> > > > > > > > > > > 
> > > > > > > > > > > The revert commit message says:
> > > > > > > > > > > 
> > > > > > > > > > >  "The commit breaks booting of fitImage by SPL, 
> > > > > > > > > > > the system simply
> > > > > > > > > > > hangs. This is because on arm32, the fitImage and all of 
> > > > > > > > > > > its content
> > > > > > > > > > > can be aligned to 4 bytes and U-Boot expects just that."
> > > > > > > > > > > 
> > > > > > > > > > > I don't understand this. If an address is aligned to 8, 
> > > > > > > > > > > it is already
> > > > > > > > > > > aligned to 4, so how did this commit make the system hang 
> > > > > > > > > > > on arm32?
> > > > > > > > > > 
> > > > > > > > > > I think this had something to do with embedding contents 
> > > > > > > > > > somewhere in
> > > > > > > > > > the image?  There is a thread on the ML from then but I 
> > > > > > > > > > don't know how
> > > > > > > > > > informative it will end up being.
> > > > > > > > > 
> > > > > > > > > It's true that the flat devicetree spec requires an 8-byte 
> > > > > > > > > alignment, even
> > > > > > > > > on 32-bit. The issues here are specific to u-boot.
> > > > > > > > > 
> > > > > > > > > SPL and u-boot have to agree where u-boot's FDT is located. 
> > > > > > > > > We'll look at
> > > > > > > > > two cases:
> > > > > > > > >  1) u-boot as a FIT (binary and FDT separately loaded)
> > > > > > > > >  2) u-boot with embedded FDT
> > > > > > > > > 
> > > > > > > > > In case (1) SPL must place the FDT at a location where u-boot 
> > > > > > > > > will find it.
> > > > > > > > > The current logic is
> > > > > > > > >  SPL:fdt = ALIGN_4(u_boot + u_boot_size)
> > > > > > > > >  u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> > > > > > > > > 
> > > > > > > > > In case (2), SPL's view of the FDT is not relevant, but 
> > > > > > > > > instead the build
> > > > > > > > > system must place the FDT correctly:
> > > > > > > > >  build:  fdt >> u-boot.bin
> > > > > > > > >  u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> > > > > > > > > 
> > > > > > > > > We have 3 places that must agree. A correct and complete 
> > > > > > > > > patch could change
> > > > > > > > > all three, but one has to consider compatibility issues when 
> > > > > > > > > crossing u-boot
> > > > > > > > > and SPL versions.
> > > > > > > > > 
> > > > > > > > > I had proposed in the revert discussion that SPL use r2 or 
> > > > > > > > > similar mechanism
> > > > > > > > > to pass the location of the FDT to u-boot.
> > > > > > > > 
> > > > > > > > I'm not sure that we need to worry too much about mix-and-match
> > > > > > > > SPL/U-Boot, but documenting what to go change if you must do it
> > > > > > > > somewhere under doc/ would be good.  I think we can just switch 
> > > > > > > > to
> > > > > > > > ALIGN(8) not ALIGN(4) and be done with it?
> > > > > > > 
> > > > > > > Remember, there is also falcon boot. And we definitely have to be 
> > > > > > > able to
> > > > > > > have old u-boot (SPL) boot new fitImage and vice versa.
> > > > > > 
> > > > > > I don't follow you, sorry.  But since you seem to have the best
> > > > > > understanding of

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

2021-07-13 Thread Alex G





On 7/13/21 1:11 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:

On 7/13/21 6:47 PM, Simon Glass wrote:

Hi Marek,

On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:


On 7/13/21 4:41 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:

On 7/13/21 3:47 PM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:

On 7/12/21 10:15 AM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:

On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:


I submitted an almost identical patch. See 
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76

This patch eventually had to be reverted 
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
 because it was causing issues on some platforms that had FIT on 32 bit 
boundary. However I continue to use it in production code, as without it the 
boot on my platform aborts.

I don't have time to investigate why this was happening, but you need to check 
this code won't just cause exactly the same faults.


Thanks for your information.

+Marek who did the revert

The revert commit message says:

 "The commit breaks booting of fitImage by SPL, the system simply
hangs. This is because on arm32, the fitImage and all of its content
can be aligned to 4 bytes and U-Boot expects just that."

I don't understand this. If an address is aligned to 8, it is already
aligned to 4, so how did this commit make the system hang on arm32?


I think this had something to do with embedding contents somewhere in
the image?  There is a thread on the ML from then but I don't know how
informative it will end up being.


It's true that the flat devicetree spec requires an 8-byte alignment, even
on 32-bit. The issues here are specific to u-boot.

SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
two cases:
 1) u-boot as a FIT (binary and FDT separately loaded)
 2) u-boot with embedded FDT

In case (1) SPL must place the FDT at a location where u-boot will find it.
The current logic is
 SPL:fdt = ALIGN_4(u_boot + u_boot_size)
 u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

In case (2), SPL's view of the FDT is not relevant, but instead the build
system must place the FDT correctly:
 build:  fdt >> u-boot.bin
 u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

We have 3 places that must agree. A correct and complete patch could change
all three, but one has to consider compatibility issues when crossing u-boot
and SPL versions.

I had proposed in the revert discussion that SPL use r2 or similar mechanism
to pass the location of the FDT to u-boot.


I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?


Remember, there is also falcon boot. And we definitely have to be able to
have old u-boot (SPL) boot new fitImage and vice versa.


I don't follow you, sorry.  But since you seem to have the best
understanding of where all of the cases something could go wrong here,
can you perhaps post an RFC patch?  That is likely to be clearer than
another long thread here.


I don't follow you, sorry. I believe the revert did the right thing and
new systems should use mkimage -E when generating fitImages, to avoid
the string alignment problem. That is all.


Using -E should be optional and things really should work without it.


See the DTSpec, I don't think that is possible unless you relocate fitImage
components, and if you want fast boot time esp. in SPL, that is not good.


This is why I've asked you to make up some patch to perhaps highlight
the problem.  Ensuring that the device tree, which is small, is also
8-byte aligned, shouldn't be a big problem nor performance hit.  I'm not
sure where the problem case is that isn't "user put things they control
in a bad spot, fail and tell them why" but I could just be missing a
case.



As far as highlighting the problem, here's an excerpt from the previous 
discussion [1].



## SPL:

image_info.load_addr = ALIGN(spl_image->load_addr + spl_image->size, 8);

(gdb) print/x (spl_image->load_addr + spl_image->size)
$19 = 0xc01cf85c
(gdb) print/x image_info->load_addr
$20 = 0xc01cf860

FDT is installed at 0xc01cf860


## u-boot:

__weak void *board_fdt_blob_setup(void)
{
/* FDT is at end of image */

fdt_blob = (ulong *)&_end;

(gdb) print &_end
$22 = (char (*)[]) 0xc01cf85c

FDT is expected at 0xc01cf85c


Alex

[1] https://lists.denx.de/pipermail/u-boot/2020-October/430066.html

[PATCH] mux: correct prototype for mux_control_try_select()

2021-07-13 Thread Patrick Wildt

The macro should be passed a state, which should be passed
to the actual function.  Otherwise using that macro would
yield a build error.

Signed-off-by: Patrick Wildt 
---
 include/mux.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/mux.h b/include/mux.h
index 23844f480a..9f80991274 100644
--- a/include/mux.h
+++ b/include/mux.h
@@ -51,7 +51,7 @@ unsigned int mux_control_states(struct mux_control *mux);
  */
 int __must_check mux_control_select(struct mux_control *mux,
unsigned int state);
-#define mux_control_try_select(mux) mux_control_select(mux)
+#define mux_control_try_select(mux, state) mux_control_select(mux, state)
 
 /**
  * mux_control_deselect() - Deselect the previously selected multiplexer state.
@@ -128,7 +128,7 @@ int __must_check mux_control_select(struct mux_control *mux,
return -ENOSYS;
 }
 
-#define mux_control_try_select(mux) mux_control_select(mux)
+#define mux_control_try_select(mux, state) mux_control_select(mux, state)
 
 int mux_control_deselect(struct mux_control *mux)
 {
-- 
2.32.0

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

2021-07-13 Thread Alex G





On 7/13/21 3:35 PM, Marek Vasut wrote:

On 7/13/21 8:11 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:

On 7/13/21 6:47 PM, Simon Glass wrote:

Hi Marek,

On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:


On 7/13/21 4:41 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:

On 7/13/21 3:47 PM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:

On 7/12/21 10:15 AM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle 
 wrote:


I submitted an almost identical patch. See 
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76 



This patch eventually had to be reverted 
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114), 
because it was causing issues on some platforms that had FIT 
on 32 bit boundary. However I continue to use it in 
production code, as without it the boot on my platform aborts.


I don't have time to investigate why this was happening, but 
you need to check this code won't just cause exactly the 
same faults.


Thanks for your information.

+Marek who did the revert

The revert commit message says:

 "The commit breaks booting of fitImage by SPL, the 
system simply
hangs. This is because on arm32, the fitImage and all of its 
content

can be aligned to 4 bytes and U-Boot expects just that."

I don't understand this. If an address is aligned to 8, it is 
already
aligned to 4, so how did this commit make the system hang on 
arm32?


I think this had something to do with embedding contents 
somewhere in
the image?  There is a thread on the ML from then but I don't 
know how

informative it will end up being.


It's true that the flat devicetree spec requires an 8-byte 
alignment, even

on 32-bit. The issues here are specific to u-boot.

SPL and u-boot have to agree where u-boot's FDT is located. 
We'll look at

two cases:
 1) u-boot as a FIT (binary and FDT separately loaded)
 2) u-boot with embedded FDT

In case (1) SPL must place the FDT at a location where u-boot 
will find it.

The current logic is
 SPL:    fdt = ALIGN_4(u_boot + u_boot_size)
 u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

In case (2), SPL's view of the FDT is not relevant, but instead 
the build

system must place the FDT correctly:
 build:  fdt >> u-boot.bin
 u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

We have 3 places that must agree. A correct and complete patch 
could change
all three, but one has to consider compatibility issues when 
crossing u-boot

and SPL versions.

I had proposed in the revert discussion that SPL use r2 or 
similar mechanism

to pass the location of the FDT to u-boot.


I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?


Remember, there is also falcon boot. And we definitely have to be 
able to

have old u-boot (SPL) boot new fitImage and vice versa.


I don't follow you, sorry.  But since you seem to have the best
understanding of where all of the cases something could go wrong 
here,

can you perhaps post an RFC patch?  That is likely to be clearer than
another long thread here.


I don't follow you, sorry. I believe the revert did the right thing 
and

new systems should use mkimage -E when generating fitImages, to avoid
the string alignment problem. That is all.


Using -E should be optional and things really should work without it.


See the DTSpec, I don't think that is possible unless you relocate 
fitImage
components, and if you want fast boot time esp. in SPL, that is not 
good.


This is why I've asked you to make up some patch to perhaps highlight
the problem.  Ensuring that the device tree, which is small, is also
8-byte aligned, shouldn't be a big problem nor performance hit.  I'm not
sure where the problem case is that isn't "user put things they control
in a bad spot, fail and tell them why" but I could just be missing a
case.


The fail case is this:
- you update SPL with this 8 byte alignment change
- you have older kernel fitImage with embedded DT for falcon mode
- system no longer boots because there is off-by-4 error in the DT
   address passed to the kernel


I'm not sure how falcon mode would break the kernel. It passes to the 
kernel the load address of the fdt. The concern here is loading u-boot.




I hope this is clear now.

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary


On 7/13/21 8:11 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:

On 7/13/21 6:47 PM, Simon Glass wrote:

Hi Marek,

On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:


On 7/13/21 4:41 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:

On 7/13/21 3:47 PM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:

On 7/12/21 10:15 AM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:

On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:


I submitted an almost identical patch. See 
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76

This patch eventually had to be reverted 
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
 because it was causing issues on some platforms that had FIT on 32 bit 
boundary. However I continue to use it in production code, as without it the 
boot on my platform aborts.

I don't have time to investigate why this was happening, but you need to check 
this code won't just cause exactly the same faults.


Thanks for your information.

+Marek who did the revert

The revert commit message says:

 "The commit breaks booting of fitImage by SPL, the system simply
hangs. This is because on arm32, the fitImage and all of its content
can be aligned to 4 bytes and U-Boot expects just that."

I don't understand this. If an address is aligned to 8, it is already
aligned to 4, so how did this commit make the system hang on arm32?


I think this had something to do with embedding contents somewhere in
the image?  There is a thread on the ML from then but I don't know how
informative it will end up being.


It's true that the flat devicetree spec requires an 8-byte alignment, even
on 32-bit. The issues here are specific to u-boot.

SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
two cases:
 1) u-boot as a FIT (binary and FDT separately loaded)
 2) u-boot with embedded FDT

In case (1) SPL must place the FDT at a location where u-boot will find it.
The current logic is
 SPL:fdt = ALIGN_4(u_boot + u_boot_size)
 u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

In case (2), SPL's view of the FDT is not relevant, but instead the build
system must place the FDT correctly:
 build:  fdt >> u-boot.bin
 u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

We have 3 places that must agree. A correct and complete patch could change
all three, but one has to consider compatibility issues when crossing u-boot
and SPL versions.

I had proposed in the revert discussion that SPL use r2 or similar mechanism
to pass the location of the FDT to u-boot.


I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?


Remember, there is also falcon boot. And we definitely have to be able to
have old u-boot (SPL) boot new fitImage and vice versa.


I don't follow you, sorry.  But since you seem to have the best
understanding of where all of the cases something could go wrong here,
can you perhaps post an RFC patch?  That is likely to be clearer than
another long thread here.


I don't follow you, sorry. I believe the revert did the right thing and
new systems should use mkimage -E when generating fitImages, to avoid
the string alignment problem. That is all.


Using -E should be optional and things really should work without it.


See the DTSpec, I don't think that is possible unless you relocate fitImage
components, and if you want fast boot time esp. in SPL, that is not good.


This is why I've asked you to make up some patch to perhaps highlight
the problem.  Ensuring that the device tree, which is small, is also
8-byte aligned, shouldn't be a big problem nor performance hit.  I'm not
sure where the problem case is that isn't "user put things they control
in a bad spot, fail and tell them why" but I could just be missing a
case.


The fail case is this:
- you update SPL with this 8 byte alignment change
- you have older kernel fitImage with embedded DT for falcon mode
- system no longer boots because there is off-by-4 error in the DT
  address passed to the kernel

I hope this is clear now.

Nokia RX51 U-Boot USB support updates?

Hey all,

So, the DM_USB migration deadline issue has been addressed by the series
here:
https://patchwork.ozlabs.org/project/uboot/list/?series=252793=*
which splits out host and gadget support from the CONFIG_USB symbol
itself. The migration deadline was for host support, and as noted, N900
is gadget only. That particular issue is resolved.

But investigating that issue lead me to figure out some other problems,
that I do need someone to say how will be addressed. Now that the other
board removal series has been applied, and then with:
https://patchwork.ozlabs.org/project/uboot/patch/20210708014348.4010-1-tr...@konsulko.com/
also applied (for which the maintainer is happy to take), this brings
N900 as the last and only user of the "old" musb driver (the "new" musb
driver is now almost 9 years old) and also the last and only user of the
usbtty driver.

I suspect that moving to the "new" MUSB driver, for gadget only, and
with that enabling DM_USB_GADGET should be a mechanical affair, so long
as you can fit within the space constraints of the platform. I'm not
immediately sure how hard it will be to update usbtty.c to modern gadget
APIs. If there are size problems, then, well, we need solutions
proposed (it's possible that some of the usb-uclass.c code is host-only
and needs moving, but that likely won't stop gadget from needing it for
gadget related information, to bring up a specific example).

It's also likely that the MUSB support needs a little further
clean-up for supporting building as gadget-only when there's some common
code under a host-only check.

What I would like is for someone to step forward and say they'll pick up
this work. Is there an immediate deadline? No. I don't think that
would be helpful. I'm not going to dictate how long it takes for
someone to do the work, that's for the person doing the work to say how
long they think it'll take.

Thanks all!

--
Tom

signature.asc
Description: PGP signature

Re: [PATCH v6 2/4] rockchip: rk3066: add clock driver for rk3066 soc

Hi Paweł,

On Tue, 13 Jul 2021 at 12:59, Paweł Jarosz  wrote:
>
> Add clock driver for rk3066 platform.
>
> Signed-off-by: Paweł Jarosz 
> Acked-by: Philipp Tomsich 
> ---
>
> Changes since v1:
> - updated to shifted masks
> - moved clk init to tpl
>
> Changes since v2:
> - none
>
> Changes since v3:
> - none
>
> Changes since v4:
> - updated to current codebase
> - fixed compilation errors
>
> Changes since v5:
> - various style changes
> - added clk_enable/clk_disable support for nand and mmc clocks
> - updated maintainer email
> - renamed uint32_t to u32
> - used #if IS_ENABLED macro instead #ifdef
>
>
>
>  .../include/asm/arch-rockchip/cru_rk3066.h| 203 +
>  drivers/clk/rockchip/Makefile |   1 +
>  drivers/clk/rockchip/clk_rk3066.c | 704 ++
>  3 files changed, 908 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3066.h
>  create mode 100644 drivers/clk/rockchip/clk_rk3066.c
>
[..]

> +
> +static int rk3066_clk_of_to_plat(struct udevice *dev)
> +{
> +#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> +   struct rk3066_clk_priv *priv = dev_get_priv(dev);
> +
> +   priv->cru = dev_read_addr_ptr(dev);
> +#endif
> +
> +   return 0;
> +}
> +
> +static int rk3066_clk_probe(struct udevice *dev)
> +{
> +   struct rk3066_clk_priv *priv = dev_get_priv(dev);
> +
> +   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
> +   if (IS_ERR(priv->grf))
> +   return PTR_ERR(priv->grf);
> +
> +#if IS_ENABLED(CONFIG_TPL_BUILD)

Do you need that? The line below should take care of it.

> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
> +   struct rk3066_clk_plat *plat = dev_get_plat(dev);
> +
> +   priv->cru = map_sysmem(plat->dtd.reg[0], plat->dtd.reg[1]);
> +#endif
> +
> +   rkclk_init(priv->cru, priv->grf);
> +
> +   /* Init CPU frequency */
> +   rkclk_configure_cpu(priv->cru, priv->grf, APLL_SAFE_HZ);
> +#endif
> +
> +   return 0;
> +}
> +
> +static int rk3066_clk_bind(struct udevice *dev)
> +{
> +   int ret;
> +   struct udevice *sys_child;
> +   struct sysreset_reg *priv;
> +
> +   /* The reset driver does not have a device node, so bind it here */
> +   ret = device_bind_driver(dev, "rockchip_sysreset", "sysreset",
> +_child);
> +   if (ret) {
> +   debug("Warning: No sysreset driver: ret=%d\n", ret);
> +   } else {
> +   priv = malloc(sizeof(struct sysreset_reg));
> +   priv->glb_srst_fst_value = offsetof(struct rk3066_cru,
> +   cru_glb_srst_fst_value);
> +   priv->glb_srst_snd_value = offsetof(struct rk3066_cru,
> +   cru_glb_srst_snd_value);
> +   dev_set_priv(sys_child, priv);
> +   }
> +
> +#if CONFIG_IS_ENABLED(RESET_ROCKCHIP)

Can you use if() instead of #if ?

> +   ret = offsetof(struct rk3066_cru, cru_softrst_con[0]);
> +   ret = rockchip_reset_bind(dev, ret, 9);
> +   if (ret)
> +   debug("Warning: software reset driver bind failed\n");
> +#endif
> +
> +   return 0;
> +}
> +
> +static const struct udevice_id rk3066_clk_ids[] = {
> +   { .compatible = "rockchip,rk3066a-cru" },
> +   { }
> +};
> +
> +U_BOOT_DRIVER(rockchip_rk3066a_cru) = {
> +   .name   = "rockchip_rk3066a_cru",
> +   .id = UCLASS_CLK,
> +   .of_match   = rk3066_clk_ids,
> +   .priv_auto  = sizeof(struct rk3066_clk_priv),
> +   .plat_auto  = sizeof(struct rk3066_clk_plat),
> +   .ops= _clk_ops,
> +   .bind   = rk3066_clk_bind,
> +   .of_to_plat = rk3066_clk_of_to_plat,
> +   .probe  = rk3066_clk_probe,
> +};
> --
> 2.32.0
>

Regards,
Simon

Re: [PATCH v3 2/9] arm: dts: imx8mp: Add common u-boot dtsi

Hi Tim,

On Mon, 12 Jul 2021 at 14:58, Tim Harvey  wrote:
>
> On Mon, Jul 12, 2021 at 12:44 PM Simon Glass  wrote:
> >
> > Hi Tim,
> >
> > On Mon, 12 Jul 2021 at 10:42, Tim Harvey  wrote:
> > >
> > > On Sat, Jul 10, 2021 at 5:23 AM Heiko Schocher  wrote:
> > > >
> > > > Hello Tim,
> > > >
> > > > On 09.07.21 16:47, Tim Harvey wrote:
> > > > > On Wed, Jul 7, 2021 at 5:58 AM Teresa Remmet  
> > > > > wrote:
> > > > >>
> > > > >> Factor out the common node settings for dm-spl and dm-pre-reloc
> > > > >> and move them to imx8mp-u-boot.dtsi
> > > > >>
> > > > >> Signed-off-by: Teresa Remmet 
> > > > >> Reviewed-by: Fabio Estevam 
> > > > >> Reviewed-by: Heiko Schocher 
> > > > >> ---
> > > > >> Changes in v3:
> > > > >> - Moved binman nodes to common imx8mp-u-boot.dtsi
> > > > >> Changes in v2:
> > > > >> - none
> > > > >>
> > > > >>  arch/arm/dts/imx8mp-evk-u-boot.dtsi   | 143 
> > > > >> +
> > > > >>  .../imx8mp-phyboard-pollux-rdk-u-boot.dtsi|  39 +
> > > > >>  arch/arm/dts/imx8mp-u-boot.dtsi   | 149 
> > > > >> ++
> > > > >>  3 files changed, 153 insertions(+), 178 deletions(-)
> > > > >>  create mode 100644 arch/arm/dts/imx8mp-u-boot.dtsi
> > > > >>
> > > 
> > > > >>
> > > > >
> > > > > Teresa,
> > > > >
> > > > > I've noticed many of the imx8m boards migrating to using binman for
> > > > > image packaging.
> > > > >
> > > > > Doesn't this change from having a single flash.bin encompasing the SPL
> > > > > and U-Boot proper to having split files? I noticed that happened with
> > > > > imx8mm_evk for example when it switched to binman.
> > > >
> > > > Yes, but you can easy generate there a single image again.
> > > >
> > > > > What are the benefits to using binman?
> > > >
> > > > Beside the pros from binmal in general, I see the benefit in special
> > > > for imx8mp, that you can get all infos you need for signing the image
> > > > from within the image. No need to save some log output from U-Boot
> > > > build and parse this output ...
> > > >
> > >
> > > (+cc Simon)
> > >
> > > Heiko,
> > >
> > > And what are the pros from binman in general? I've read over
> > > tools/binman/binman.rst so I'm assuming you mean what is described
> > > there as benefits.
> > >
> > > How do you get all the details needed for signing the image from binman?
> > >
> > > If I make imx8mm_evk_defconfig which produces via binman flash.bin and
> > > u-boot.itb I get the following:
> > >
> > > $ ./tools/binman/binman ls -i flash.bin
> > > binman: Cannot find FDT map in image
> > > $ ./tools/binman/binman ls -i u-boot.itb
> > > binman: Cannot find FDT map in image
> >
> > As the message says, you need an 'fdtmap' in the image:
> >
> >fdtmap {
> >}:
> >
>
> Simon,
>
> Sorry I still don't quite understand:
>
> diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> index f200afac9f..c6d8932fa4 100644
> --- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> +++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
> @@ -163,6 +163,9 @@
> itb {
> filename = "u-boot.itb";
>
> +   fdtmap {
> +   };
> +
> fit {
> description = "Configuration to load ATF before 
> U-Boot";
> #address-cells = <1>;
>
>
> $ make imx8mm_evk_defconfig
> $ make
> $ ./tools/binman/binman ls -i u-boot.itb
> Name  Image-pos  SizeEntry-type  Offset  Uncomp-size
> --
> main-section  0   a3875  section  0
>   fdtmap  0 48d  fdtmap   0
>   fit   48d   a33e8  fit48d
>
> For signing we need the loadaddr/offset/size of the components within
> the FIT image. Since binman is calling mkimage to create FIT images it
> seems outside the scope of binman to be able to dump details on the
> actual FIT image. Perhaps mkimage or another tool is to be used for
> that detail?

Yes, binman does not look inside FITs at presnt. You may want to look
at dump_image?

>
> > >
> > > I would very much like to understand how to use binman to get the
> > > various offsets needed for signing an IMX image for use with HAB.
> >
> > You should be able to add signing support to binman for your use case.
> > See for example how vblock.py works.
>
> I see... so your saying instead of using an external tool to generate
> a txt template with the offset/size values for the various blobs
> instead we need to implement for example a habv4.py to add a habv4
> entry and the python class would have access to the content handles to
> determine the addr/size in order to create the text template file fed
> to the NXP code signing tool?

Yes that should work. It is in fact what binman is designed for
(producing images, with all the signing, etc.)

Regards,
Simon

Re: [PATCH 1/2 v2] tpm2: Introduce TIS tpm core

Hi Ilias,

On Mon, 12 Jul 2021 at 23:51, Ilias Apalodimas
 wrote:
>
> Hi Simon,
> > > >
>
> [...]
>
> > > > Yes, but I hope you see my point, that you have added a new interface.
> > > > It is definitely better than adding a new driver and duplicating all
> > > > the code, but it is still one more copy and in fact, the code is
> > > > duplicated.
> > > >
> > >
> > > I get the point but I don't exactly agree here.  It's not duplicated code.
> > > We need to plug in the mmio driver.  The original code was just doing what
> > > every TPM does.  It carried the TIS relevant code in the new driver.
> > > The new approach defines an API for everyone to use and the new driver 
> > > uses it.
> > > So I don't see the duplication here.  You need the TIS code one way or the
> > > other.  Now it's on a common interface for everyone to use.
> >
> > Well how about converting a TPM blindly and then we'll find someone to test 
> > it?
>
> Let's do the cr50
>
> >
> > >
> > > > Can you get access to TPM hardware? I see that you have offered to be
> > > > the maintainer for this subsystem, so I think that would be useful.
> > > > Can sandbox use your new API?
> > >
> > > It depends, is the sandbox TIS compatible? If it is sure we could use it.
> >
> > At present sandbox implements the tpm_ops API. So if we did that we
> > would need to tear it apart to insert this new API as well.
>
> Ok then that might make too much sense for the sandbox.
>
> >
> > > I offered to maintain the drivers because I wrote the API and I have an
> > > idea of how TPMs should work.  If that means I'll have to go and get every
> > > hardware we support, I'll just volunteer into maintaining the TIS layer.
> > > Moreover I dont see why I should start porting drivers to use that API.
> > > People decided to duplicate that code in every driver (in fact multiple 
> > > times).
> >
> > See https://xkcd.com/927/ :-)
> >
>
> Yea I don't disagree with that.  That's one of the points of adding myself
> as a maintainer for the entire tpm/drivers/*.  I can just reply 'no thanks'
> at least for new drivers that don't use it.  But frankly I don't see why,
> adding a new drivers, while using the TIS API boils down to a few lines of
> code defining the bus accesses
>
> > >
> > > I am happy to work with you on the cr50 i2c driver if that would help.
> >
> > Sure that might be easier as I can definitely test it.
>
> Ok, let me have a look at that, I still think the patch should go in
> regardless though.  We can always send a follow up for cr50 once we are
> done testing

Well if you set it up as an MMIO uclass with a sandbox test then I
think there is enough value to this approach and we avoid the xkcd
issue.

Regards,
Simon

Re: [PATCH 5/6] MIPS: malta: add support for PCI driver model

Hi Daniel,

On Mon, 12 Jul 2021 at 19:17, Daniel Schwierzeck
 wrote:
>
> Hi Simon,
>
> Am Samstag, den 10.07.2021, 18:00 -0600 schrieb Simon Glass:
> > () Hi Daniel,
> >
> > On Tue, 6 Jul 2021 at 08:22, Daniel Schwierzeck
> >  wrote:
> > > As almost all peripherals are connected via PCI dependent on the
> > > used core card, PCI setup is always required. Thus run pci_init()
> > > including PCI scanning and probing and core card specific setups
> > > in board_early_init_r().
> > >
> > > Also prepare support for dynamically managing the status of the
> > > different PCI DT nodes dependent on used core card via option
> > > CONFIG_OF_BOARD_FIXUP. Before this feature can be enabled,
> > > the call order of the fix_fdt() init hook in board_init_f
> > > needs to be changed. Otherwise rw_fdt_blob points to a read-only
> > > NOR flash address. Thus this options needs to stay disabled
> > > until the board_init_f problem could be solved. This breaks
> > > running the default U-Boot image on real HW using the FPGA core
> > > card but Qemu emulation still works. Currently Qemu is more
> > > important as MIPS CI tests depend on Malta and the deadline
> > > for PCI DM conversion will be enforced soon.
> > >
> > > Signed-off-by: Daniel Schwierzeck 
> > > ---
> > >
> > >  board/imgtec/malta/malta.c | 84
> > > +-
> > >  1 file changed, 83 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/board/imgtec/malta/malta.c
> > > b/board/imgtec/malta/malta.c
> > > index c04f727961..e78d5a7fbc 100644
> > > --- a/board/imgtec/malta/malta.c
> > > +++ b/board/imgtec/malta/malta.c
> > > @@ -4,7 +4,8 @@
> > >   * Copyright (C) 2013 Imagination Technologies
> > >   */
> > >
> > > -#include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -24,6 +25,9 @@
> > >
> > >  DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +#define MALTA_GT_PATH   "/pci0@1be0"
> > > +#define MALTA_MSC_PATH  "/pci0@1bd0"
> > > +
> > >  enum core_card {
> > > CORE_UNKNOWN,
> > > CORE_LV,
> > > @@ -120,10 +124,12 @@ int checkboard(void)
> > > return 0;
> > >  }
> > >
> > > +#if !IS_ENABLED(CONFIG_DM_ETH)
> > >  int board_eth_init(struct bd_info *bis)
> > >  {
> > > return pci_eth_init(bis);
> > >  }
> > > +#endif
> > >
> > >  void _machine_restart(void)
> > >  {
> > > @@ -167,6 +173,81 @@ int misc_init_r(void)
> > > return 0;
> > >  }
> > >
> > > +#if IS_ENABLED(CONFIG_OF_BOARD_FIXUP)
> > > +/*
> > > + * TODO: currently doesn't work because rw_fdt_blob points to a
> > > + * NOR flash address. This needs some changes in board_init_f.
> > > + */
> > > +int board_fix_fdt(void *rw_fdt_blob)
> > > +{
> > > +   int node = -1;
> > > +
> > > +   switch (malta_sys_con()) {
> > > +   case SYSCON_GT64120:
> > > +   node =  fdt_path_offset(rw_fdt_blob,
> > > MALTA_GT_PATH);
> > > +   break;
> > > +   default:
> > > +   case SYSCON_MSC01:
> > > +   node =  fdt_path_offset(rw_fdt_blob,
> > );
> > > +   break;
> > > +   }
> > > +
> > > +   return fdt_status_okay(rw_fdt_blob, node);
> > > +}
> > > +#endif
> > > +
> > > +#if IS_ENABLED(CONFIG_DM_PCI)
> > > +int board_early_init_r(void)
> > > +{
> > > +   struct udevice *dev;
> > > +   u32 val32;
> > > +   u8 val8;
> > > +   int ret;
> > > +
> > > +   pci_init();
> > > +
> > > +   ret = dm_pci_find_device(PCI_VENDOR_ID_INTEL,
> > > +PCI_DEVICE_ID_INTEL_82371AB_0, 0,
> > > );
> >
> > This feels a bit wonky to me. How about a sysinfo driver for your
> > board which does this init? Then you could just probe it.
> >
> > As to finding PCI devices, your sysinfo driver could have a few
> > phandle properties to point to the two devices you need.
> >
> > But if these are really SYSCON devices, why not use the SYSCON
> > devices, give them a unique ID (perhaps you already have with
> > SYSCON_MSC01) and then call syscon_get_regmap_by_driver_data() ?
>
> This is just a reimplementation of the original pci_init_board()
> function. I wanted to keep the changes small and to keep the original
> PCI init behaviour to get the PCI DM conversion done and get this patch
> series merged in this merge window ;) The Malta board is the reference
> board for MIPS Qemu and essential for testing and U-Boot CI. Therefore
> it would be very bad if it gets removed due to the PCI DM conversion
> deadline.
>
> I already tried to add PIIX4 IRQ and ATA drivers for this init code.
> But those drivers were just bound and I didn't have an idea how to
> trigger a probe. I will look into it again with the next patch series
> for removing all non-DM code.

OK.


> >
> >
> > > +   if (ret)
> > > +   panic("Failed to find PIIX4 PCI bridge\n");
> > > +
> > > +   /* setup PCI interrupt routing */
> > > +   dm_pci_write_config8(dev, PCI_CFG_PIIX4_PIRQRCA, 10);
> > > +   dm_pci_write_config8(dev,

Re: [PATCH 2/2] tpm2: Add a TPMv2 MMIO TIS driver

2021-07-13 Thread Ilias Apalodimas



[...]
> > > Should be a uclass interface.
> > >
> >
> > Why? A uclass is supposed to describe and abstract hardware.  This is just
> > a specific implementation of a TPM, not all TPMs are TIS compliant. We 
> > already
> > have a uclass for those.
> 
> Who told you that a uclass is supposed to describe and abstract hardware? :-)
> 

That's what I've mostly seen it used for, maybe i got the idea wrong.

> The uclass is how driver model does APIs, so normally a uclass would
> be used for any API. There are exceptions, but this one actually looks
> like a useful interface we should have.
> 

the point is we already have a uclass for tpm devices.  So why should the
we add another one that just describes the TIS interface?

> >
> > > > +   .read_bytes = mmio_read_bytes,
> > > > +   .write_bytes = mmio_write_bytes,
> > > > +   .read16 = mmio_read16,
> > > > +   .read32 = mmio_read32,
> > > > +   .write32 = mmio_write32,
> > > > +};
> > > > +
> > > > +static int tpm_tis_probe(struct udevice *udev)
> > > > +{
> > > > +   struct tpm_tis_chip_data *drv_data = (void 
> > > > *)dev_get_driver_data(udev);
> > > > +   struct tpm_chip_priv *priv = dev_get_uclass_priv(udev);
> > > > +   int ret = 0;
> > > > +   fdt_addr_t ioaddr;
> > > > +   u64 sz;
> > > > +
> > > > +   ioaddr = dev_read_addr(udev);
> > > > +   if (ioaddr == FDT_ADDR_T_NONE)
> > > > +   return -EINVAL;
> > >
> > > consider this for easier debugging:
> > >
> > >return log_msg_ret("ioaddr", -EINVAL);
> > >
> >
> > Sure
> >
> > > > +
> > > > +   ret = dev_read_u64(udev, "reg", );
> > > > +   if (ret)
> > > > +   return -EINVAL;
> > > > +
> > > > +   drv_data->iobase = ioremap(ioaddr, sz);
> > > > +   log_info("Remapped TPM2 base: 0x%llx size: 0x%llx\n", ioaddr, 
> > > > sz);
> > >
> > > log_debug() I think?
> > >
> > Yea, that's a leftover of my initial code, were I needed to make sure the
> > ioremap worked.
> >
> > > > +   tpm_tis_ops_register(udev, _ops);
> > > > +   ret = tpm_tis_init(udev);
> > > > +   if (ret)
> > > > +   goto iounmap;
> > > > +
> > > > +   priv->pcr_count = drv_data->pcr_count;
> > > > +   priv->pcr_select_min = drv_data->pcr_select_min;
> > > > +   /*
> > > > +* Although the driver probably works with a TPMv1 our Kconfig
> > > > +* limits the driver to TPMv2 only
> > > > +*/
> > > > +   priv->version = TPM_V2;
> > > > +
> > > > +   return ret;
> > > > +iounmap:
> > > > +   iounmap(drv_data->iobase);
> > > > +   return -EINVAL;
> > > > +}
> > > > +
> > > > +static int tpm_tis_remove(struct udevice *udev)
> > > > +{
> > > > +   struct tpm_tis_chip_data *drv_data = (void 
> > > > *)dev_get_driver_data(udev);
> > > > +
> > > > +   iounmap(drv_data->iobase);
> > > > +   return tpm_tis_cleanup(udev);
> > > > +}
> > > > +
> > > > +static const struct tpm_ops tpm_tis_ops = {
> > > > +   .open   = tpm_tis_open,
> > > > +   .close  = tpm_tis_close,
> > > > +   .get_desc   = tpm_tis_get_desc,
> > > > +   .send   = tpm_tis_send,
> > > > +   .recv   = tpm_tis_recv,
> > > > +   .cleanup= tpm_tis_cleanup,
> > > > +};
> > > > +
> > > > +static const struct tpm_tis_chip_data tpm_tis_std_chip_data = {
> > > > +   .pcr_count = 24,
> > > > +   .pcr_select_min = 3,
> > > > +};
> > > > +
> > > > +static const struct udevice_id tpm_tis_ids[] = {
> > > > +   {
> > > > +   .compatible = "tcg,tpm-tis-mmio",
> > > > +   .data = (ulong)_tis_std_chip_data,
> > > > +   },
> > > > +   { }
> > > > +};
> > > > +
> > > > +U_BOOT_DRIVER(tpm_tis_mmio) = {
> > > > +   .name   = "tpm_tis_mmio",
> > > > +   .id = UCLASS_TPM,
> > > > +   .of_match = tpm_tis_ids,
> > > > +   .ops= _tis_ops,
> > > > +   .probe  = tpm_tis_probe,
> > > > +   .remove = tpm_tis_remove,
> > > > +   .priv_auto  = sizeof(struct tpm_chip),
> > > > +};
> > > > --
> > > > 2.32.0.rc0
> > > >
> > >
> > > Regards,
> > > Simon
> >
> > Thanks for looking at this
> > /Ilias
> 
> Likewise.
> 
> Regards,
> Simon

Re: [PATCH v4 20/21] doc: board: Move j721e document to doc/board/ti/ directory

On Mon, Jul 12, 2021 at 11:50:24AM +0530, Kishon V;ijay Abraham I wrote:

> Move j721e document from board/ti/j721e/README to
> doc/board/ti/j721e_evm.rst after converting it to RST format.
> 
> Signed-off-by: Kishon Vijay Abraham I 
[snip]
> diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst
> new file mode 100644
> index 00..d0cf7c23f8
> --- /dev/null
> +++ b/doc/board/ti/j721e_evm.rst
> @@ -0,0 +1,316 @@
> +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
> +.. sectionauthor:: Patrick Delaunay 

Should fix this :)

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request for efi-2021-10-rc1

On Tue, Jul 13, 2021 at 07:30:02AM +0200, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 490101a5e5df65238b900b21b81361bc4b13da2e:
> 
>   Merge branch 'master' of
> https://source.denx.de/u-boot/custodians/u-boot-sunxi (2021-07-09
> 21:08:52 -0400)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/efi-2021-10-rc1
> 
> for you to fetch changes up to b0b1449b3be9b93ecc57d91b0cb18ed81fc8a1ee:
> 
>   efi_loader: Fix to set bootdev_root correctly if bootdev found
> (2021-07-12 20:38:16 +0200)
> 
> Gitlab CI showed no problems:
> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/8182
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v6 4/4] rockchip: rk3066: add sdram driver

Add rockchip rk3066 sdram driver

Signed-off-by: Paweł Jarosz 
Acked-by: Simon Glass 
Acked-by: Philipp Tomsich 
---

Changes since v1:
- use common rockchip_sdram_size
- moved sdram init from sdram_init.c

Changes since v2:
- none

Changes since v3:
- none

Changes since v4:
- updated to current codebase
- fixed compilation errors

Changes since v5:
- fixed various style issues
- added arch-rockchip/hardware.h include
- used BIT macro
- used #if IS_ENABLED macro instead of #ifdef


 drivers/ram/rockchip/Makefile   |   1 +
 drivers/ram/rockchip/sdram_rk3066.c | 942 
 2 files changed, 943 insertions(+)
 create mode 100644 drivers/ram/rockchip/sdram_rk3066.c

diff --git a/drivers/ram/rockchip/Makefile b/drivers/ram/rockchip/Makefile
index ca1c289b88..6d530c29af 100644
--- a/drivers/ram/rockchip/Makefile
+++ b/drivers/ram/rockchip/Makefile
@@ -5,6 +5,7 @@

 obj-$(CONFIG_ROCKCHIP_PX30) += sdram_px30.o sdram_pctl_px30.o sdram_phy_px30.o
 obj-$(CONFIG_ROCKCHIP_RK3368) = dmc-rk3368.o
+obj-$(CONFIG_ROCKCHIP_RK3066) = sdram_rk3066.o
 obj-$(CONFIG_ROCKCHIP_RK3128) = sdram_rk3128.o
 obj-$(CONFIG_ROCKCHIP_RK3188) = sdram_rk3188.o
 obj-$(CONFIG_ROCKCHIP_RK322X) = sdram_rk322x.o
diff --git a/drivers/ram/rockchip/sdram_rk3066.c 
b/drivers/ram/rockchip/sdram_rk3066.c
new file mode 100644
index 00..0dd0a496aa
--- /dev/null
+++ b/drivers/ram/rockchip/sdram_rk3066.c
@@ -0,0 +1,942 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * (C) Copyright 2015 Google, Inc
+ * Copyright 2014 Rockchip Inc.
+ *
+ * Adapted from the very similar rk3188 ddr init.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct chan_info {
+   struct rk3288_ddr_pctl *pctl;
+   struct rk3288_ddr_publ *publ;
+   struct rk3188_msch *msch;
+};
+
+struct dram_info {
+   struct chan_info chan[1];
+   struct ram_info info;
+   struct clk ddr_clk;
+   struct rk3066_cru *cru;
+   struct rk3066_grf *grf;
+   struct rk3066_sgrf *sgrf;
+   struct rk3188_pmu *pmu;
+};
+
+struct rk3066_sdram_params {
+#if CONFIG_IS_ENABLED(OF_PLATDATA)
+   struct dtd_rockchip_rk3066_dmc of_plat;
+#endif
+   struct rk3288_sdram_channel ch[2];
+   struct rk3288_sdram_pctl_timing pctl_timing;
+   struct rk3288_sdram_phy_timing phy_timing;
+   struct rk3288_base_params base;
+   int num_channels;
+   struct regmap *map;
+};
+
+const int ddrconf_table[] = {
+   /*
+* [5:4] row(13+n)
+* [1:0] col(9+n), assume bw=2
+* row  col,bw
+*/
+   0,
+   (2 << DDRCONF_ROW_SHIFT) | 1 << DDRCONF_COL_SHIFT,
+   (1 << DDRCONF_ROW_SHIFT) | 1 << DDRCONF_COL_SHIFT,
+   (0 << DDRCONF_ROW_SHIFT) | 1 << DDRCONF_COL_SHIFT,
+   (2 << DDRCONF_ROW_SHIFT) | 2 << DDRCONF_COL_SHIFT,
+   (1 << DDRCONF_ROW_SHIFT) | 2 << DDRCONF_COL_SHIFT,
+   (0 << DDRCONF_ROW_SHIFT) | 2 << DDRCONF_COL_SHIFT,
+   (1 << DDRCONF_ROW_SHIFT) | 0 << DDRCONF_COL_SHIFT,
+   (0 << DDRCONF_ROW_SHIFT) | 0 << DDRCONF_COL_SHIFT,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+   0,
+};
+
+#define TEST_PATTEN0x5aa5f00f
+#define DQS_GATE_TRAINING_ERROR_RANK0  BIT(4)
+#define DQS_GATE_TRAINING_ERROR_RANK1  BIT(5)
+
+#if IS_ENABLED(CONFIG_TPL_BUILD)
+static void copy_to_reg(u32 *dest, const u32 *src, u32 n)
+{
+   int i;
+
+   for (i = 0; i < n / sizeof(u32); i++) {
+   writel(*src, dest);
+   src++;
+   dest++;
+   }
+}
+
+static void ddr_reset(struct rk3066_cru *cru, u32 ch, u32 ctl, u32 phy)
+{
+   u32 phy_ctl_srstn_shift = 13;
+   u32 ctl_psrstn_shift = 11;
+   u32 ctl_srstn_shift = 10;
+   u32 phy_psrstn_shift = 9;
+   u32 phy_srstn_shift = 8;
+
+   rk_clrsetreg(>cru_softrst_con[5],
+1 << phy_ctl_srstn_shift | 1 << ctl_psrstn_shift |
+1 << ctl_srstn_shift | 1 << phy_psrstn_shift |
+1 << phy_srstn_shift,
+phy << phy_ctl_srstn_shift | ctl << ctl_psrstn_shift |
+ctl << ctl_srstn_shift | phy << phy_psrstn_shift |
+phy << phy_srstn_shift);
+}
+
+static void ddr_phy_ctl_reset(struct rk3066_cru *cru, u32 ch, u32 n)
+{
+   u32 phy_ctl_srstn_shift = 13;
+
+   rk_clrsetreg(>cru_softrst_con[5],
+1 << phy_ctl_srstn_shift, n << phy_ctl_srstn_shift);
+}
+
+static void phy_pctrl_reset(struct rk3066_cru *cru,
+   struct rk3288_ddr_publ *publ,
+   int channel)
+{
+   int i;
+
+   ddr_reset(cru, channel, 1, 1);
+   udelay(1);
+   clrbits_le32(>acdllcr, ACDLLCR_DLLSRST);
+   for (i = 0; i < 4; i++)
+   clrbits_le32(>datx8[i].dxdllcr,

[PATCH v6 3/4] rockchip: rk3066: add rk3066 pinctrl driver

Add driver supporting pin multiplexing on rk3066 platform.

Signed-off-by: Paweł Jarosz 
---

Changes since v1:
- updated to shifted masks
- added nand support

Changes since v2:
- none

Changes since v3:
- none

Changes since v4:
- updated driver to pinctrl full

Changes since v5:
- none

 drivers/pinctrl/rockchip/Makefile |   1 +
 drivers/pinctrl/rockchip/pinctrl-rk3066.c | 113 ++
 2 files changed, 114 insertions(+)
 create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3066.c

diff --git a/drivers/pinctrl/rockchip/Makefile 
b/drivers/pinctrl/rockchip/Makefile
index fcf19f877a..7d03f8101d 100644
--- a/drivers/pinctrl/rockchip/Makefile
+++ b/drivers/pinctrl/rockchip/Makefile
@@ -5,6 +5,7 @@
 obj-y += pinctrl-rockchip-core.o
 obj-$(CONFIG_ROCKCHIP_PX30) += pinctrl-px30.o
 obj-$(CONFIG_ROCKCHIP_RK3036) += pinctrl-rk3036.o
+obj-$(CONFIG_ROCKCHIP_RK3066) += pinctrl-rk3066.o
 obj-$(CONFIG_ROCKCHIP_RK3128) += pinctrl-rk3128.o
 obj-$(CONFIG_ROCKCHIP_RK3188) += pinctrl-rk3188.o
 obj-$(CONFIG_ROCKCHIP_RK322X) += pinctrl-rk322x.o
diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3066.c 
b/drivers/pinctrl/rockchip/pinctrl-rk3066.c
new file mode 100644
index 00..8faba05a4a
--- /dev/null
+++ b/drivers/pinctrl/rockchip/pinctrl-rk3066.c
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinctrl-rockchip.h"
+
+static int rk3066_set_mux(struct rockchip_pin_bank *bank, int pin, int mux)
+{
+   struct rockchip_pinctrl_priv *priv = bank->priv;
+   int iomux_num = (pin / 8);
+   struct regmap *regmap;
+   int reg, ret, mask, mux_type;
+   u8 bit;
+   u32 data;
+
+   regmap = (bank->iomux[iomux_num].type & IOMUX_SOURCE_PMU)
+   ? priv->regmap_pmu : priv->regmap_base;
+
+   /* get basic quadrupel of mux registers and the correct reg inside */
+   mux_type = bank->iomux[iomux_num].type;
+   reg = bank->iomux[iomux_num].offset;
+   reg += rockchip_get_mux_data(mux_type, pin, , );
+
+   data = (mask << (bit + 16));
+   data |= (mux & mask) << bit;
+   ret = regmap_write(regmap, reg, data);
+
+   return ret;
+}
+
+#define RK3066_PULL_OFFSET 0x118
+#define RK3066_PULL_PINS_PER_REG   16
+#define RK3066_PULL_BANK_STRIDE8
+
+static void rk3066_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
+int pin_num, struct regmap **regmap,
+int *reg, u8 *bit)
+{
+   struct rockchip_pinctrl_priv *priv = bank->priv;
+
+   *regmap = priv->regmap_base;
+   *reg = RK3066_PULL_OFFSET;
+   *reg += bank->bank_num * RK3066_PULL_BANK_STRIDE;
+   *reg += (pin_num / RK3066_PULL_PINS_PER_REG) * 4;
+
+   *bit = pin_num % RK3066_PULL_PINS_PER_REG;
+};
+
+static int rk3066_set_pull(struct rockchip_pin_bank *bank,
+  int pin_num, int pull)
+{
+   struct regmap *regmap;
+   int reg, ret;
+   u8 bit;
+   u32 data;
+
+   if (pull != PIN_CONFIG_BIAS_PULL_PIN_DEFAULT &&
+   pull != PIN_CONFIG_BIAS_DISABLE)
+   return -ENOTSUPP;
+
+   rk3066_calc_pull_reg_and_bit(bank, pin_num, , , );
+   data = BIT(bit + 16);
+   if (pull == PIN_CONFIG_BIAS_DISABLE)
+   data |= BIT(bit);
+   ret = regmap_write(regmap, reg, data);
+
+   return ret;
+}
+
+static struct rockchip_pin_bank rk3066_pin_banks[] = {
+   PIN_BANK(0, 32, "gpio0"),
+   PIN_BANK(1, 32, "gpio1"),
+   PIN_BANK(2, 32, "gpio2"),
+   PIN_BANK(3, 32, "gpio3"),
+   PIN_BANK(4, 32, "gpio4"),
+   PIN_BANK(6, 16, "gpio6"),
+};
+
+static struct rockchip_pin_ctrl rk3066_pin_ctrl = {
+   .pin_banks  = rk3066_pin_banks,
+   .nr_banks   = ARRAY_SIZE(rk3066_pin_banks),
+   .grf_mux_offset = 0xa8,
+   .set_mux= rk3066_set_mux,
+   .set_pull   = rk3066_set_pull,
+};
+
+static const struct udevice_id rk3066_pinctrl_ids[] = {
+   {
+   .compatible = "rockchip,rk3066a-pinctrl",
+   .data = (ulong)_pin_ctrl
+   },
+   {}
+};
+
+U_BOOT_DRIVER(rockchip_rk3066a_pinctrl) = {
+   .name   = "rockchip_rk3066a_pinctrl",
+   .id = UCLASS_PINCTRL,
+   .of_match   = rk3066_pinctrl_ids,
+   .priv_auto  = sizeof(struct rockchip_pinctrl_priv),
+   .ops= _pinctrl_ops,
+#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+   .bind   = dm_scan_fdt_dev,
+#endif
+   .probe  = rockchip_pinctrl_probe,
+};
--
2.32.0

[PATCH v6 2/4] rockchip: rk3066: add clock driver for rk3066 soc

Add clock driver for rk3066 platform.

Signed-off-by: Paweł Jarosz 
Acked-by: Philipp Tomsich 
---

Changes since v1:
- updated to shifted masks
- moved clk init to tpl

Changes since v2:
- none

Changes since v3:
- none

Changes since v4:
- updated to current codebase
- fixed compilation errors

Changes since v5:
- various style changes
- added clk_enable/clk_disable support for nand and mmc clocks
- updated maintainer email
- renamed uint32_t to u32
- used #if IS_ENABLED macro instead #ifdef



 .../include/asm/arch-rockchip/cru_rk3066.h| 203 +
 drivers/clk/rockchip/Makefile |   1 +
 drivers/clk/rockchip/clk_rk3066.c | 704 ++
 3 files changed, 908 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3066.h
 create mode 100644 drivers/clk/rockchip/clk_rk3066.c

diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3066.h 
b/arch/arm/include/asm/arch-rockchip/cru_rk3066.h
new file mode 100644
index 00..711366d530
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3066.h
@@ -0,0 +1,203 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2021 Paweł Jarosz 
+ */
+
+#ifndef _ASM_ARCH_CRU_RK3066_H
+#define _ASM_ARCH_CRU_RK3066_H
+
+#define OSC_HZ (24 * 1000 * 1000)
+
+#define APLL_HZ(1416 * 100)
+#define APLL_SAFE_HZ   (600 * 100)
+#define GPLL_HZ(594 * 100)
+#define CPLL_HZ(384 * 100)
+
+/* The SRAM is clocked off aclk_cpu, so we want to max it out for boot speed */
+#define CPU_ACLK_HZ29700
+#define CPU_HCLK_HZ14850
+#define CPU_PCLK_HZ7425
+#define CPU_H2P_HZ 7425
+
+#define PERI_ACLK_HZ   14850
+#define PERI_HCLK_HZ   14850
+#define PERI_PCLK_HZ   7425
+
+/* Private data for the clock driver - used by rockchip_get_cru() */
+struct rk3066_clk_priv {
+   struct rk3066_grf *grf;
+   struct rk3066_cru *cru;
+   ulong rate;
+   bool has_bwadj;
+};
+
+struct rk3066_cru {
+   struct rk3066_pll {
+   u32 con0;
+   u32 con1;
+   u32 con2;
+   u32 con3;
+   } pll[4];
+   u32 cru_mode_con;
+   u32 cru_clksel_con[35];
+   u32 cru_clkgate_con[10];
+   u32 reserved1[2];
+   u32 cru_glb_srst_fst_value;
+   u32 cru_glb_srst_snd_value;
+   u32 reserved2[2];
+   u32 cru_softrst_con[9];
+   u32 cru_misc_con;
+   u32 reserved3[2];
+   u32 cru_glb_cnt_th;
+};
+
+check_member(rk3066_cru, cru_glb_cnt_th, 0x0140);
+
+/* CRU_CLKSEL0_CON */
+enum {
+   /* a9_core_div: core = core_src / (a9_core_div + 1) */
+   A9_CORE_DIV_SHIFT   = 9,
+   A9_CORE_DIV_MASK= 0x1f << A9_CORE_DIV_SHIFT,
+   CORE_PLL_SHIFT  = 8,
+   CORE_PLL_MASK   = 1 << CORE_PLL_SHIFT,
+   CORE_PLL_SELECT_APLL= 0,
+   CORE_PLL_SELECT_GPLL,
+
+   /* core peri div: core:core_peri = 2:1, 4:1, 8:1 or 16:1 */
+   CORE_PERI_DIV_SHIFT = 6,
+   CORE_PERI_DIV_MASK  = 3 << CORE_PERI_DIV_SHIFT,
+
+   /* aclk_cpu pll selection */
+   CPU_ACLK_PLL_SHIFT  = 5,
+   CPU_ACLK_PLL_MASK   = 1 << CPU_ACLK_PLL_SHIFT,
+   CPU_ACLK_PLL_SELECT_APLL= 0,
+   CPU_ACLK_PLL_SELECT_GPLL,
+
+   /* a9_cpu_div: aclk_cpu = cpu_src / (a9_cpu_div + 1) */
+   A9_CPU_DIV_SHIFT= 0,
+   A9_CPU_DIV_MASK = 0x1f << A9_CPU_DIV_SHIFT,
+};
+
+/* CRU_CLKSEL1_CON */
+enum {
+   /* ahb2apb_pclk_div: hclk_cpu:pclk_cpu = 1:1, 2:1 or 4:1 */
+   AHB2APB_DIV_SHIFT   = 14,
+   AHB2APB_DIV_MASK= 3 << AHB2APB_DIV_SHIFT,
+
+   /* cpu_pclk_div: aclk_cpu:pclk_cpu = 1:1, 2:1, 4:1 or 8:1 */
+   CPU_PCLK_DIV_SHIFT  = 12,
+   CPU_PCLK_DIV_MASK   = 3 << CPU_PCLK_DIV_SHIFT,
+
+   /* cpu_hclk_div: aclk_cpu:hclk_cpu = 1:1, 2:1 or 4:1 */
+   CPU_HCLK_DIV_SHIFT  = 8,
+   CPU_HCLK_DIV_MASK   = 3 << CPU_HCLK_DIV_SHIFT,
+
+   /* core_aclk_div: cire:aclk_core = 1:1, 2:1, 3:1, 4:1 or 8:1 */
+   CORE_ACLK_DIV_SHIFT = 3,
+   CORE_ACLK_DIV_MASK  = 7 << CORE_ACLK_DIV_SHIFT,
+};
+
+/* CRU_CLKSEL10_CON */
+enum {
+   PERI_SEL_PLL_SHIFT  = 15,
+   PERI_SEL_PLL_MASK   = 1 << PERI_SEL_PLL_SHIFT,
+   PERI_SEL_CPLL   = 0,
+   PERI_SEL_GPLL,
+
+   /* peri pclk div: aclk_bus:pclk_bus = 1:1, 2:1, 4:1 or 8:1 */
+   PERI_PCLK_DIV_SHIFT = 12,
+   PERI_PCLK_DIV_MASK  = 3 << PERI_PCLK_DIV_SHIFT,
+
+   /* peripheral bus hclk div:aclk_bus: hclk_bus = 1:1, 2:1 or 4:1 */
+   PERI_HCLK_DIV_SHIFT = 8,
+   PERI_HCLK_DIV_MASK  = 3 << PERI_HCLK_DIV_SHIFT,
+
+   /* peri aclk div: aclk_peri = periph_src / (peri_aclk_div + 1) */
+   PERI_ACLK_DIV_SHIFT = 0,
+   PERI_ACLK_DIV_MASK  = 0x1f << PERI_ACLK_DIV_SHIFT,
+};
+
+/* CRU_CLKSEL11_CON */
+enum {
+   MMC0_DIV_SHIFT  = 0,
+   MMC0_DIV_MASK   = 0x3f << MMC0_DIV_SHIFT,
+};
+
+/*

[PATCH v6 1/4] rockchip: rk3066: add grf header file

grf is needed by various drivers for rk3066 soc.

Signed-off-by: Paweł Jarosz 
Acked-by: Philipp Tomsich 
---

Changes since v1:
- updated to shifted masks

Changes since v2:
- none

Changes since v3:
- none

Changes since v4:
- removed gpio iomux related constants

Changes since v5:
- removed unintentional tab
- updated maintainer email
- style related changes

 .../include/asm/arch-rockchip/grf_rk3066.h| 211 ++
 1 file changed, 211 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3066.h

diff --git a/arch/arm/include/asm/arch-rockchip/grf_rk3066.h 
b/arch/arm/include/asm/arch-rockchip/grf_rk3066.h
new file mode 100644
index 00..71fdcd0372
--- /dev/null
+++ b/arch/arm/include/asm/arch-rockchip/grf_rk3066.h
@@ -0,0 +1,211 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2021 Paweł Jarosz 
+ */
+
+#ifndef _ASM_ARCH_GRF_RK3066_H
+#define _ASM_ARCH_GRF_RK3066_H
+
+struct rk3066_grf_gpio_lh {
+   u32 l;
+   u32 h;
+};
+
+struct rk3066_grf {
+   struct rk3066_grf_gpio_lh gpio_dir[7];
+   struct rk3066_grf_gpio_lh gpio_do[7];
+   struct rk3066_grf_gpio_lh gpio_en[7];
+
+   u32 gpio0a_iomux;
+   u32 gpio0b_iomux;
+   u32 gpio0c_iomux;
+   u32 gpio0d_iomux;
+
+   u32 gpio1a_iomux;
+   u32 gpio1b_iomux;
+   u32 gpio1c_iomux;
+   u32 gpio1d_iomux;
+
+   u32 gpio2a_iomux;
+   u32 gpio2b_iomux;
+   u32 gpio2c_iomux;
+   u32 gpio2d_iomux;
+
+   u32 gpio3a_iomux;
+   u32 gpio3b_iomux;
+   u32 gpio3c_iomux;
+   u32 gpio3d_iomux;
+
+   u32 gpio4a_iomux;
+   u32 gpio4b_iomux;
+   u32 gpio4c_iomux;
+   u32 gpio4d_iomux;
+
+   u32 reserved0[5];
+
+   u32 gpio6b_iomux;
+
+   u32 reserved1[2];
+
+   struct rk3066_grf_gpio_lh gpio_pull[7];
+
+   u32 soc_con0;
+   u32 soc_con1;
+   u32 soc_con2;
+
+   u32 soc_status0;
+
+   u32 dmac1_con[3];
+   u32 dmac2_con[4];
+
+   u32 uoc0_con[3];
+   u32 uoc1_con[4];
+   u32 ddrc_con;
+   u32 ddrc_stat;
+
+   u32 reserved2[10];
+
+   u32 os_reg[4];
+};
+
+check_member(rk3066_grf, os_reg[3], 0x01d4);
+
+/* GRF_GPIO1B_IOMUX */
+enum {
+   GPIO1B1_SHIFT   = 2,
+   GPIO1B1_MASK= 1 << GPIO1B1_SHIFT,
+   GPIO1B1_GPIO= 0,
+   GPIO1B1_UART2_SOUT,
+
+   GPIO1B0_SHIFT   = 0,
+   GPIO1B0_MASK= 1 << GPIO1B0_SHIFT,
+   GPIO1B0_GPIO= 0,
+   GPIO1B0_UART2_SIN
+};
+
+/* GRF_SOC_CON0 */
+enum {
+   SMC_MUX_CON_SHIFT   = 13,
+   SMC_MUX_CON_MASK= 1 << SMC_MUX_CON_SHIFT,
+
+   NOC_REMAP_SHIFT = 12,
+   NOC_REMAP_MASK  = 1 << NOC_REMAP_SHIFT,
+
+   EMMC_FLASH_SEL_SHIFT= 11,
+   EMMC_FLASH_SEL_MASK = 1 << EMMC_FLASH_SEL_SHIFT,
+
+   TZPC_REVISION_SHIFT = 7,
+   TZPC_REVISION_MASK  = 0xf << TZPC_REVISION_SHIFT,
+
+   L2CACHE_ACC_SHIFT   = 5,
+   L2CACHE_ACC_MASK= 3 << L2CACHE_ACC_SHIFT,
+
+   L2RD_WAIT_SHIFT = 3,
+   L2RD_WAIT_MASK  = 3 << L2RD_WAIT_SHIFT,
+
+   IMEMRD_WAIT_SHIFT   = 1,
+   IMEMRD_WAIT_MASK= 3 << IMEMRD_WAIT_SHIFT,
+
+   SOC_REMAP_SHIFT = 0,
+   SOC_REMAP_MASK  = 1 << SOC_REMAP_SHIFT,
+};
+
+/* GRF_SOC_CON1 */
+enum {
+   RKI2C4_SEL_SHIFT= 15,
+   RKI2C4_SEL_MASK = 1 << RKI2C4_SEL_SHIFT,
+
+   RKI2C3_SEL_SHIFT= 14,
+   RKI2C3_SEL_MASK = 1 << RKI2C3_SEL_SHIFT,
+
+   RKI2C2_SEL_SHIFT= 13,
+   RKI2C2_SEL_MASK = 1 << RKI2C2_SEL_SHIFT,
+
+   RKI2C1_SEL_SHIFT= 12,
+   RKI2C1_SEL_MASK = 1 << RKI2C1_SEL_SHIFT,
+
+   RKI2C0_SEL_SHIFT= 11,
+   RKI2C0_SEL_MASK = 1 << RKI2C0_SEL_SHIFT,
+
+   VCODEC_SEL_SHIFT= 10,
+   VCODEC_SEL_MASK = 1 << VCODEC_SEL_SHIFT,
+
+   PERI_EMEM_PAUSE_SHIFT   = 9,
+   PERI_EMEM_PAUSE_MASK= 1 << PERI_EMEM_PAUSE_SHIFT,
+
+   PERI_USB_PAUSE_SHIFT= 8,
+   PERI_USB_PAUSE_MASK = 1 << PERI_USB_PAUSE_SHIFT,
+
+   SMC_MUX_MODE_0_SHIFT= 6,
+   SMC_MUX_MODE_0_MASK = 1 << SMC_MUX_MODE_0_SHIFT,
+
+   SMC_SRAM_MW_0_SHIFT = 4,
+   SMC_SRAM_MW_0_MASK  = 3 << SMC_SRAM_MW_0_SHIFT,
+
+   SMC_REMAP_0_SHIFT   = 3,
+   SMC_REMAP_0_MASK= 1 << SMC_REMAP_0_SHIFT,
+
+   SMC_A_GT_M0_SYNC_SHIFT  = 2,
+   SMC_A_GT_M0_SYNC_MASK   = 1 << SMC_A_GT_M0_SYNC_SHIFT,
+
+   EMAC_SPEED_SHIFT= 1,
+   EMAC_SPEEC_MASK = 1 << EMAC_SPEED_SHIFT,
+
+   EMAC_MODE_SHIFT = 0,
+   EMAC_MODE_MASK  = 1 << EMAC_MODE_SHIFT,
+};
+
+/* GRF_SOC_CON2 */
+enum {
+   MSCH4_MAINDDR3_SHIFT= 7,
+   MSCH4_MAINDDR3_MASK = 1 << MSCH4_MAINDDR3_SHIFT,
+   MSCH4_MAINDDR3_DDR3 = 1,
+
+   EMAC_NEWRCV_EN_SHIFT= 6,
+   EMAC_NEWRCV_EN_MASK = 1 <<

[PATCH v6 0/4] Add basic support for rk3066 platform.

This patch serie adds basic support for Rockchip RK3066 processor.
For now it's clock, pinctrl and sdram driver.

Paweł Jarosz (4):
  rockchip: rk3066: add grf header file
  rockchip: rk3066: add clock driver for rk3066 soc
  rockchip: rk3066: add rk3066 pinctrl driver
  rockchip: rk3066: add sdram driver

 .../include/asm/arch-rockchip/cru_rk3066.h| 203 
 .../include/asm/arch-rockchip/grf_rk3066.h| 211 
 drivers/clk/rockchip/Makefile |   1 +
 drivers/clk/rockchip/clk_rk3066.c | 704 +
 drivers/pinctrl/rockchip/Makefile |   1 +
 drivers/pinctrl/rockchip/pinctrl-rk3066.c | 113 +++
 drivers/ram/rockchip/Makefile |   1 +
 drivers/ram/rockchip/sdram_rk3066.c   | 942 ++
 8 files changed, 2176 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-rockchip/cru_rk3066.h
 create mode 100644 arch/arm/include/asm/arch-rockchip/grf_rk3066.h
 create mode 100644 drivers/clk/rockchip/clk_rk3066.c
 create mode 100644 drivers/pinctrl/rockchip/pinctrl-rk3066.c
 create mode 100644 drivers/ram/rockchip/sdram_rk3066.c

--
2.32.0

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

On Tue, Jul 13, 2021 at 07:50:49PM +0200, Marek Vasut wrote:
> On 7/13/21 6:47 PM, Simon Glass wrote:
> > Hi Marek,
> > 
> > On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:
> > > 
> > > On 7/13/21 4:41 PM, Tom Rini wrote:
> > > > On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
> > > > > On 7/13/21 3:47 PM, Tom Rini wrote:
> > > > > > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
> > > > > > > On 7/12/21 10:15 AM, Tom Rini wrote:
> > > > > > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
> > > > > > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle 
> > > > > > > > >  wrote:
> > > > > > > > > > 
> > > > > > > > > > I submitted an almost identical patch. See 
> > > > > > > > > > https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
> > > > > > > > > > 
> > > > > > > > > > This patch eventually had to be reverted 
> > > > > > > > > > (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
> > > > > > > > > >  because it was causing issues on some platforms that had 
> > > > > > > > > > FIT on 32 bit boundary. However I continue to use it in 
> > > > > > > > > > production code, as without it the boot on my platform 
> > > > > > > > > > aborts.
> > > > > > > > > > 
> > > > > > > > > > I don't have time to investigate why this was happening, 
> > > > > > > > > > but you need to check this code won't just cause exactly 
> > > > > > > > > > the same faults.
> > > > > > > > > 
> > > > > > > > > Thanks for your information.
> > > > > > > > > 
> > > > > > > > > +Marek who did the revert
> > > > > > > > > 
> > > > > > > > > The revert commit message says:
> > > > > > > > > 
> > > > > > > > > "The commit breaks booting of fitImage by SPL, the 
> > > > > > > > > system simply
> > > > > > > > > hangs. This is because on arm32, the fitImage and all of its 
> > > > > > > > > content
> > > > > > > > > can be aligned to 4 bytes and U-Boot expects just that."
> > > > > > > > > 
> > > > > > > > > I don't understand this. If an address is aligned to 8, it is 
> > > > > > > > > already
> > > > > > > > > aligned to 4, so how did this commit make the system hang on 
> > > > > > > > > arm32?
> > > > > > > > 
> > > > > > > > I think this had something to do with embedding contents 
> > > > > > > > somewhere in
> > > > > > > > the image?  There is a thread on the ML from then but I don't 
> > > > > > > > know how
> > > > > > > > informative it will end up being.
> > > > > > > 
> > > > > > > It's true that the flat devicetree spec requires an 8-byte 
> > > > > > > alignment, even
> > > > > > > on 32-bit. The issues here are specific to u-boot.
> > > > > > > 
> > > > > > > SPL and u-boot have to agree where u-boot's FDT is located. We'll 
> > > > > > > look at
> > > > > > > two cases:
> > > > > > > 1) u-boot as a FIT (binary and FDT separately loaded)
> > > > > > > 2) u-boot with embedded FDT
> > > > > > > 
> > > > > > > In case (1) SPL must place the FDT at a location where u-boot 
> > > > > > > will find it.
> > > > > > > The current logic is
> > > > > > > SPL:fdt = ALIGN_4(u_boot + u_boot_size)
> > > > > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> > > > > > > 
> > > > > > > In case (2), SPL's view of the FDT is not relevant, but instead 
> > > > > > > the build
> > > > > > > system must place the FDT correctly:
> > > > > > > build:  fdt >> u-boot.bin
> > > > > > > u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> > > > > > > 
> > > > > > > We have 3 places that must agree. A correct and complete patch 
> > > > > > > could change
> > > > > > > all three, but one has to consider compatibility issues when 
> > > > > > > crossing u-boot
> > > > > > > and SPL versions.
> > > > > > > 
> > > > > > > I had proposed in the revert discussion that SPL use r2 or 
> > > > > > > similar mechanism
> > > > > > > to pass the location of the FDT to u-boot.
> > > > > > 
> > > > > > I'm not sure that we need to worry too much about mix-and-match
> > > > > > SPL/U-Boot, but documenting what to go change if you must do it
> > > > > > somewhere under doc/ would be good.  I think we can just switch to
> > > > > > ALIGN(8) not ALIGN(4) and be done with it?
> > > > > 
> > > > > Remember, there is also falcon boot. And we definitely have to be 
> > > > > able to
> > > > > have old u-boot (SPL) boot new fitImage and vice versa.
> > > > 
> > > > I don't follow you, sorry.  But since you seem to have the best
> > > > understanding of where all of the cases something could go wrong here,
> > > > can you perhaps post an RFC patch?  That is likely to be clearer than
> > > > another long thread here.
> > > 
> > > I don't follow you, sorry. I believe the revert did the right thing and
> > > new systems should use mkimage -E when generating fitImages, to avoid
> > > the string alignment problem. That is all.
> > 
> > Using -E should be optional and things really should work without it.
> 
> See the DTSpec, I don't think that is

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary


On 7/13/21 6:47 PM, Simon Glass wrote:

Hi Marek,

On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:


On 7/13/21 4:41 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:

On 7/13/21 3:47 PM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:

On 7/12/21 10:15 AM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:

On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:


I submitted an almost identical patch. See 
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76

This patch eventually had to be reverted 
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
 because it was causing issues on some platforms that had FIT on 32 bit 
boundary. However I continue to use it in production code, as without it the 
boot on my platform aborts.

I don't have time to investigate why this was happening, but you need to check 
this code won't just cause exactly the same faults.


Thanks for your information.

+Marek who did the revert

The revert commit message says:

"The commit breaks booting of fitImage by SPL, the system simply
hangs. This is because on arm32, the fitImage and all of its content
can be aligned to 4 bytes and U-Boot expects just that."

I don't understand this. If an address is aligned to 8, it is already
aligned to 4, so how did this commit make the system hang on arm32?


I think this had something to do with embedding contents somewhere in
the image?  There is a thread on the ML from then but I don't know how
informative it will end up being.


It's true that the flat devicetree spec requires an 8-byte alignment, even
on 32-bit. The issues here are specific to u-boot.

SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
two cases:
1) u-boot as a FIT (binary and FDT separately loaded)
2) u-boot with embedded FDT

In case (1) SPL must place the FDT at a location where u-boot will find it.
The current logic is
SPL:fdt = ALIGN_4(u_boot + u_boot_size)
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

In case (2), SPL's view of the FDT is not relevant, but instead the build
system must place the FDT correctly:
build:  fdt >> u-boot.bin
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

We have 3 places that must agree. A correct and complete patch could change
all three, but one has to consider compatibility issues when crossing u-boot
and SPL versions.

I had proposed in the revert discussion that SPL use r2 or similar mechanism
to pass the location of the FDT to u-boot.


I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?


Remember, there is also falcon boot. And we definitely have to be able to
have old u-boot (SPL) boot new fitImage and vice versa.


I don't follow you, sorry.  But since you seem to have the best
understanding of where all of the cases something could go wrong here,
can you perhaps post an RFC patch?  That is likely to be clearer than
another long thread here.


I don't follow you, sorry. I believe the revert did the right thing and
new systems should use mkimage -E when generating fitImages, to avoid
the string alignment problem. That is all.


Using -E should be optional and things really should work without it.


See the DTSpec, I don't think that is possible unless you relocate 
fitImage components, and if you want fast boot time esp. in SPL, that is 
not good.

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
> On 7/12/21 10:15 AM, Tom Rini wrote:
> > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
> > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:
> > > > 
> > > > I submitted an almost identical patch. See 
> > > > https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
> > > > 
> > > > This patch eventually had to be reverted 
> > > > (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
> > > >  because it was causing issues on some platforms that had FIT on 32 bit 
> > > > boundary. However I continue to use it in production code, as without 
> > > > it the boot on my platform aborts.
> > > > 
> > > > I don't have time to investigate why this was happening, but you need 
> > > > to check this code won't just cause exactly the same faults.
> > > 
> > > Thanks for your information.
> > > 
> > > +Marek who did the revert
> > > 
> > > The revert commit message says:
> > > 
> > >  "The commit breaks booting of fitImage by SPL, the system simply
> > > hangs. This is because on arm32, the fitImage and all of its content
> > > can be aligned to 4 bytes and U-Boot expects just that."
> > > 
> > > I don't understand this. If an address is aligned to 8, it is already
> > > aligned to 4, so how did this commit make the system hang on arm32?
> > 
> > I think this had something to do with embedding contents somewhere in
> > the image?  There is a thread on the ML from then but I don't know how
> > informative it will end up being.
> 
> It's true that the flat devicetree spec requires an 8-byte alignment, even
> on 32-bit. The issues here are specific to u-boot.
> 
> SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
> two cases:
>   1) u-boot as a FIT (binary and FDT separately loaded)
>   2) u-boot with embedded FDT
> 
> In case (1) SPL must place the FDT at a location where u-boot will find it.
> The current logic is
>   SPL:fdt = ALIGN_4(u_boot + u_boot_size)
>   u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> 
> In case (2), SPL's view of the FDT is not relevant, but instead the build
> system must place the FDT correctly:
>   build:  fdt >> u-boot.bin
>   u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> 
> We have 3 places that must agree. A correct and complete patch could change
> all three, but one has to consider compatibility issues when crossing u-boot
> and SPL versions.
> 
> I had proposed in the revert discussion that SPL use r2 or similar mechanism
> to pass the location of the FDT to u-boot.

Looking at this again, and trying to figure out what we can do here most
easily, I think we need to have spl_fit_append_fdt() perhaps be split in
to "find the fdt" and then either a new function, or more logic within
the function for "ensure fdt is aligned properly".  We had made the
assumption that we can use the fdt in place in memory but that's not
always true.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] tpm2: Add a TPMv2 MMIO TIS driver

Hi Heinrich,

On Mon, 12 Jul 2021 at 16:47, Heinrich Schuchardt  wrote:
>
> Am 12. Juli 2021 21:43:53 MESZ schrieb Simon Glass :
> >Hi Heinrich,
> >
> >On Mon, 12 Jul 2021 at 13:19, Heinrich Schuchardt 
> >wrote:
> >>
> >> On 7/12/21 8:22 PM, Ilias Apalodimas wrote:
> >> > Hi Simon,
> >> > On Sat, Jul 10, 2021 at 06:00:59PM -0600, Simon Glass wrote:
> >> >> Hi Ilias,
> >> >>
> >> >> On Wed, 7 Jul 2021 at 10:26, Ilias Apalodimas
> >> >>  wrote:
> >> >>>
> >> >>> Add support for devices that expose a TPMv2 though MMIO.
> >> >>> Apart from those devices, we can use the driver in our QEMU
> >setups and
> >> >>> test TPM related code which is difficult to achieve using the
> >sandbox
> >> >>> driver (e.g test the EFI TCG2 protocol).
> >> >>>
> >> >>> It's worth noting that a previous patch added TPMv2 TIS core
> >functions,
> >> >>> which the current driver is consuming.
> >> >>>
> >> >>> Signed-off-by: Ilias Apalodimas 
> >> >>> ---
> >> >>> Changes since v1:
> >> >>> - split off the tis core code into a different file
> >> >>>   drivers/tpm/Kconfig |   9 +++
> >> >>>   drivers/tpm/Makefile|   1 +
> >> >>>   drivers/tpm/tpm2_tis_mmio.c | 156
> >
> >> >>>   3 files changed, 166 insertions(+)
> >> >>>   create mode 100644 drivers/tpm/tpm2_tis_mmio.c
> >> >>
> >> >> Looks good to me
> >> >
> >> > Thanks!
> >> >
> >> >>>
> >> >>> +struct tpm_tis_chip_data {
> >> >>> +   unsigned int pcr_count;
> >> >>> +   unsigned int pcr_select_min;
> >> >>> +   unsigned int time_before_first_cmd_ms;
> >> >>> +   void __iomem *iobase;
> >> >>> +};
> >> >>
> >> >> comments
> >> >>
> >> >
> >> > You mean on all the internal functions?
> >> > Sure I can add them
> >> >
> >> >>> +
> >> >>> +static int mmio_read_bytes(struct udevice *udev, u32 addr, u16
> >len,
> >> >>> +  u8 *result)
> >> >>> +{
> >> >>> +   struct tpm_tis_chip_data *drv_data = (void
> >*)dev_get_driver_data(udev);
> >> >>> +
> >> >>> +   while (len--)
> >> >>> +   *result++ = ioread8(drv_data->iobase + addr);
> >> >>
> >> >> We normally put a blank line before the final return
> >> >>
> >> >
> >> > sure
> >> >
> >> >>> +   return 0;
> >> >>> +}
> >> >>> +
> >> >>> +static int mmio_write_bytes(struct udevice *udev, u32 addr, u16
> >len,
> >> >>> +   const u8 *value)
> >> >>> +{
> >> >>> +   struct tpm_tis_chip_data *drv_data = (void
> >*)dev_get_driver_data(udev);
> >> >>> +
> >> >>> +   while (len--)
> >> >>> +   iowrite8(*value++, drv_data->iobase + addr);
> >> >>> +   return 0;
> >> >>> +}
> >> >>> +
> >> >>> +static int mmio_read16(struct udevice *udev, u32 addr, u16
> >*result)
> >> >>> +{
> >> >>> +   struct tpm_tis_chip_data *drv_data = (void
> >*)dev_get_driver_data(udev);
> >> >>> +
> >> >>> +   *result = ioread16(drv_data->iobase + addr);
> >> >>> +   return 0;
> >> >>> +}
> >> >>> +
> >> >>> +static int mmio_read32(struct udevice *udev, u32 addr, u32
> >*result)
> >> >>> +{
> >> >>> +   struct tpm_tis_chip_data *drv_data = (void
> >*)dev_get_driver_data(udev);
> >> >>> +
> >> >>> +   *result = ioread32(drv_data->iobase + addr);
> >> >>> +   return 0;
> >> >>> +}
> >> >>> +
> >> >>> +static int mmio_write32(struct udevice *udev, u32 addr, u32
> >value)
> >> >>> +{
> >> >>> +   struct tpm_tis_chip_data *drv_data = (void
> >*)dev_get_driver_data(udev);
> >> >>> +
> >> >>> +   iowrite32(value, drv_data->iobase + addr);
> >> >>> +   return 0;
> >> >>> +}
> >> >>> +
> >> >>> +static struct tpm_tis_phy_ops phy_ops = {
> >> >>
> >> >> Should be a uclass interface.
> >> >>
> >> >
> >> > Why? A uclass is supposed to describe and abstract hardware.  This
> >is just
> >> > a specific implementation of a TPM, not all TPMs are TIS compliant.
> >We already
> >> > have a uclass for those.
> >>
> >> The design proposed by Ilias matches what we find in Linux for TPM.
> >> Keeping the same structure should render porting of drivers for
> >> additional devices easier.
> >
> >Can you please be more specific in your comment? What change are you
> >asking for?
> >
> >Regards,
> >Simon
>
> None. I think the design is ok as is.
>
> I was responding to your idea of adding another uclass.

It seems obvious to me that the proposed API is useful outside TPMs.
It provides an MMIO interface, after all.

Regards,
Simon

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

Hi Marek,

On Tue, 13 Jul 2021 at 08:53, Marek Vasut  wrote:
>
> On 7/13/21 4:41 PM, Tom Rini wrote:
> > On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
> >> On 7/13/21 3:47 PM, Tom Rini wrote:
> >>> On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
>  On 7/12/21 10:15 AM, Tom Rini wrote:
> > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
> >> On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  
> >> wrote:
> >>>
> >>> I submitted an almost identical patch. See 
> >>> https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
> >>>
> >>> This patch eventually had to be reverted 
> >>> (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
> >>>  because it was causing issues on some platforms that had FIT on 32 
> >>> bit boundary. However I continue to use it in production code, as 
> >>> without it the boot on my platform aborts.
> >>>
> >>> I don't have time to investigate why this was happening, but you need 
> >>> to check this code won't just cause exactly the same faults.
> >>
> >> Thanks for your information.
> >>
> >> +Marek who did the revert
> >>
> >> The revert commit message says:
> >>
> >>"The commit breaks booting of fitImage by SPL, the system simply
> >> hangs. This is because on arm32, the fitImage and all of its content
> >> can be aligned to 4 bytes and U-Boot expects just that."
> >>
> >> I don't understand this. If an address is aligned to 8, it is already
> >> aligned to 4, so how did this commit make the system hang on arm32?
> >
> > I think this had something to do with embedding contents somewhere in
> > the image?  There is a thread on the ML from then but I don't know how
> > informative it will end up being.
> 
>  It's true that the flat devicetree spec requires an 8-byte alignment, 
>  even
>  on 32-bit. The issues here are specific to u-boot.
> 
>  SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
>  two cases:
> 1) u-boot as a FIT (binary and FDT separately loaded)
> 2) u-boot with embedded FDT
> 
>  In case (1) SPL must place the FDT at a location where u-boot will find 
>  it.
>  The current logic is
> SPL:fdt = ALIGN_4(u_boot + u_boot_size)
> u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> 
>  In case (2), SPL's view of the FDT is not relevant, but instead the build
>  system must place the FDT correctly:
> build:  fdt >> u-boot.bin
> u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> 
>  We have 3 places that must agree. A correct and complete patch could 
>  change
>  all three, but one has to consider compatibility issues when crossing 
>  u-boot
>  and SPL versions.
> 
>  I had proposed in the revert discussion that SPL use r2 or similar 
>  mechanism
>  to pass the location of the FDT to u-boot.
> >>>
> >>> I'm not sure that we need to worry too much about mix-and-match
> >>> SPL/U-Boot, but documenting what to go change if you must do it
> >>> somewhere under doc/ would be good.  I think we can just switch to
> >>> ALIGN(8) not ALIGN(4) and be done with it?
> >>
> >> Remember, there is also falcon boot. And we definitely have to be able to
> >> have old u-boot (SPL) boot new fitImage and vice versa.
> >
> > I don't follow you, sorry.  But since you seem to have the best
> > understanding of where all of the cases something could go wrong here,
> > can you perhaps post an RFC patch?  That is likely to be clearer than
> > another long thread here.
>
> I don't follow you, sorry. I believe the revert did the right thing and
> new systems should use mkimage -E when generating fitImages, to avoid
> the string alignment problem. That is all.

Using -E should be optional and things really should work without it.

Regards,
Simon

Re: [PATCHv2 1/4] ge_bx50v3: Remove unused USB related defines

2021-07-13 Thread Sebastian Reichel

Hi,

On Fri, Jul 09, 2021 at 10:11:53AM -0400, Tom Rini wrote:
> These USB defines do not change the build as there is no USB support
> enabled currently.
> 
> Cc: Ian Ray 
> Cc: Sebastian Reichel 
> Signed-off-by: Tom Rini 
> ---

Reviewed-by: Sebastian Reichel 

-- Sebastian

> Changes in v2:
> - New patch
> ---
>  include/configs/ge_bx50v3.h | 11 ---
>  1 file changed, 11 deletions(-)
> 
> diff --git a/include/configs/ge_bx50v3.h b/include/configs/ge_bx50v3.h
> index c8e9d3b17f5e..2b61172cc739 100644
> --- a/include/configs/ge_bx50v3.h
> +++ b/include/configs/ge_bx50v3.h
> @@ -33,17 +33,6 @@
>  #define CONFIG_LBA48
>  #endif
>  
> -/* USB Configs */
> -#ifdef CONFIG_USB
> -#define CONFIG_USB_MAX_CONTROLLER_COUNT 2
> -#define CONFIG_EHCI_HCD_INIT_AFTER_RESET
> -#define CONFIG_MXC_USB_PORTSC(PORT_PTS_UTMI | PORT_PTS_PTW)
> -#define CONFIG_MXC_USB_FLAGS 0
> -
> -#define CONFIG_USBD_HS
> -#define CONFIG_USB_GADGET_MASS_STORAGE
> -#endif
> -
>  /* Serial Flash */
>  
>  #define CONFIG_LOADADDR  0x1200
> -- 
> 2.17.1
> 


signature.asc
Description: PGP signature

Re: [[PATCH] tools: image-host: fix wrong return value

2021-07-13 Thread Igor Opaniuk

Hi Ming,

On Mon, May 31, 2021 at 10:05 AM  wrote:
>
> From: Ming Liu 
>
> The return value '-ENOSPC' of fit_set_timestamp function does not match
> the caller fit_image_write_sig's expection which is '-FDT_ERR_NOSPACE'.
>
> Fix it by not calling fit_set_timestamp, but call fdt_setprop instead.
>
> This fixes a following mkimage error:
> | Can't write signature for 'signature@1' signature node in
> | 'c...@imx6ull-colibri-wifi-eval-v3.dtb' conf node: 
> | mkimage Can't add hashes to FIT blob: -1
>
> Signed-off-by: Ming Liu 
> ---
>  tools/image-host.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/image-host.c b/tools/image-host.c
> index 270d36fe45..73095461a7 100644
> --- a/tools/image-host.c
> +++ b/tools/image-host.c
> @@ -132,8 +132,10 @@ static int fit_image_write_sig(void *fit, int noffset, 
> uint8_t *value,
> if (!ret) {
> time_t timestamp = imagetool_get_source_date(cmdname,
>  time(NULL));
> +   uint32_t t = cpu_to_uimage(timestamp);
>
> -   ret = fit_set_timestamp(fit, noffset, timestamp);
> +   ret = fdt_setprop(fit, noffset, FIT_TIMESTAMP_PROP, ,
> +   sizeof(uint32_t));
> }
> if (region_prop && !ret) {
> uint32_t strdata[2];
> --
> 2.29.0
>

I've hit exactly the same issue on my side today :)

Tested-by: Igor Opaniuk 

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

Igor Opaniuk
Embedded Software Engineer
T:  +380 938364067
E: igor.opan...@foundries.io
W: www.foundries.io

[PATCH 3/3] arm64: zynqmp: Enable reset and poweroff via sysreset framework

reset and poweroff are called via hooks in psci driver which is going
around sysreset framework that's why enable sysreset drivers and do reset
and poweroff via this framework. Using this flow will allow us to call
SYSTEM_WARM_RESET based on psci 1.1 spec which can be calles with reset -w
command.

Signed-off-by: Michal Simek 
---

 configs/xilinx_zynqmp_virt_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/xilinx_zynqmp_virt_defconfig 
b/configs/xilinx_zynqmp_virt_defconfig
index 5f32ca49300f..bac1e181d265 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -157,6 +157,9 @@ CONFIG_ZYNQ_SERIAL=y
 CONFIG_SPI=y
 CONFIG_ZYNQ_SPI=y
 CONFIG_ZYNQMP_GQSPI=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_CMD_POWEROFF=y
+CONFIG_SYSRESET_PSCI=y
 CONFIG_TPM2_TIS_SPI=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
-- 
2.32.0

[PATCH 2/3] arm64: zynqmp: Do not define do_reset() if sysreset is enabled

The SPL can also be compiled with sysreset drivers just fine, so
update the condition to cater for that option.
The same change was done by commit efa1a62ad2dd ("ARM: imx8m: Do not define
do_reset() if sysreset is enabled").

Signed-off-by: Michal Simek 
---

 board/xilinx/zynqmp/zynqmp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 18d5c515def1..38c910fa5bab 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -499,9 +499,11 @@ int dram_init(void)
 }
 #endif
 
+#if !CONFIG_IS_ENABLED(SYSRESET)
 void reset_cpu(void)
 {
 }
+#endif
 
 static u8 __maybe_unused zynqmp_get_bootmode(void)
 {
-- 
2.32.0

[PATCH 1/3] psci: Do not define do_poweroff() if CONFIG_SYSRESET_CMD_POWEROFF is enabled

CONFIG_SYSRESET_CMD_POWEROFF defines do_poweroff() in sysreset-uclass.c
that's why don't define it twice when both CONFIG_SYSRESET_CMD_POWEROFF and
CONFIG_CMD_POWEROFF are enabled. CONFIG_SYSRESET_CMD_POWEROFF depends on
CONFIG_CMD_POWEROFF.

Signed-off-by: Michal Simek 
---

 drivers/firmware/psci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index 89cb7d88e5b3..657e7eb5aea3 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -210,7 +210,7 @@ void psci_sys_poweroff(void)
invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
 }
 
-#ifdef CONFIG_CMD_POWEROFF
+#if IS_ENABLED(CONFIG_CMD_POWEROFF) && 
!IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
 int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
do_psci_probe();
-- 
2.32.0

[PATCH 0/3] arm64: zynqmp: Use sysreset framework for reset and poweroff

Hi,

it is time to do reset/poweroff via sysreset framework to align it with
psci 1.1 spec.

Thanks,
Michal


Michal Simek (3):
  psci: Do not define do_poweroff() if CONFIG_SYSRESET_CMD_POWEROFF is
enabled
  arm64: zynqmp: Do not define do_reset() if sysreset is enabled
  arm64: zynqmp: Enable reset and poweroff via sysreset framework

 board/xilinx/zynqmp/zynqmp.c | 2 ++
 configs/xilinx_zynqmp_virt_defconfig | 3 +++
 drivers/firmware/psci.c  | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

-- 
2.32.0

Re: Build a standalone ext4 file system driver

On Fri, Jul 09, 2021 at 07:13:04AM +, Feng Libo wrote:

> Uboot implements the simple file protocol of ext4 file system, already. 
> However, the driver is embedded in Uboot. Is it possible to build a 
> standalone ext4 file system driver for UEFI, in the format of efi, just like 
> the helloworld.efi. So I can use the UEFI shell command: load to load the 
> driver and access a ext4 partition.

No, we do not support anything like that.  You'll need to look at the
other existing UEFI filesystem drivers instead.  There's at least one,
as of a few years ago.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary


On 7/13/21 4:41 PM, Tom Rini wrote:

On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:

On 7/13/21 3:47 PM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:

On 7/12/21 10:15 AM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:

On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:


I submitted an almost identical patch. See 
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76

This patch eventually had to be reverted 
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
 because it was causing issues on some platforms that had FIT on 32 bit 
boundary. However I continue to use it in production code, as without it the 
boot on my platform aborts.

I don't have time to investigate why this was happening, but you need to check 
this code won't just cause exactly the same faults.


Thanks for your information.

+Marek who did the revert

The revert commit message says:

   "The commit breaks booting of fitImage by SPL, the system simply
hangs. This is because on arm32, the fitImage and all of its content
can be aligned to 4 bytes and U-Boot expects just that."

I don't understand this. If an address is aligned to 8, it is already
aligned to 4, so how did this commit make the system hang on arm32?


I think this had something to do with embedding contents somewhere in
the image?  There is a thread on the ML from then but I don't know how
informative it will end up being.


It's true that the flat devicetree spec requires an 8-byte alignment, even
on 32-bit. The issues here are specific to u-boot.

SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
two cases:
1) u-boot as a FIT (binary and FDT separately loaded)
2) u-boot with embedded FDT

In case (1) SPL must place the FDT at a location where u-boot will find it.
The current logic is
SPL:fdt = ALIGN_4(u_boot + u_boot_size)
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

In case (2), SPL's view of the FDT is not relevant, but instead the build
system must place the FDT correctly:
build:  fdt >> u-boot.bin
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

We have 3 places that must agree. A correct and complete patch could change
all three, but one has to consider compatibility issues when crossing u-boot
and SPL versions.

I had proposed in the revert discussion that SPL use r2 or similar mechanism
to pass the location of the FDT to u-boot.


I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?


Remember, there is also falcon boot. And we definitely have to be able to
have old u-boot (SPL) boot new fitImage and vice versa.


I don't follow you, sorry.  But since you seem to have the best
understanding of where all of the cases something could go wrong here,
can you perhaps post an RFC patch?  That is likely to be clearer than
another long thread here.


I don't follow you, sorry. I believe the revert did the right thing and 
new systems should use mkimage -E when generating fitImages, to avoid 
the string alignment problem. That is all.

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

On Tue, Jul 13, 2021 at 04:35:38PM +0200, Marek Vasut wrote:
> On 7/13/21 3:47 PM, Tom Rini wrote:
> > On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
> > > On 7/12/21 10:15 AM, Tom Rini wrote:
> > > > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
> > > > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  
> > > > > wrote:
> > > > > > 
> > > > > > I submitted an almost identical patch. See 
> > > > > > https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
> > > > > > 
> > > > > > This patch eventually had to be reverted 
> > > > > > (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
> > > > > >  because it was causing issues on some platforms that had FIT on 32 
> > > > > > bit boundary. However I continue to use it in production code, as 
> > > > > > without it the boot on my platform aborts.
> > > > > > 
> > > > > > I don't have time to investigate why this was happening, but you 
> > > > > > need to check this code won't just cause exactly the same faults.
> > > > > 
> > > > > Thanks for your information.
> > > > > 
> > > > > +Marek who did the revert
> > > > > 
> > > > > The revert commit message says:
> > > > > 
> > > > >   "The commit breaks booting of fitImage by SPL, the system simply
> > > > > hangs. This is because on arm32, the fitImage and all of its content
> > > > > can be aligned to 4 bytes and U-Boot expects just that."
> > > > > 
> > > > > I don't understand this. If an address is aligned to 8, it is already
> > > > > aligned to 4, so how did this commit make the system hang on arm32?
> > > > 
> > > > I think this had something to do with embedding contents somewhere in
> > > > the image?  There is a thread on the ML from then but I don't know how
> > > > informative it will end up being.
> > > 
> > > It's true that the flat devicetree spec requires an 8-byte alignment, even
> > > on 32-bit. The issues here are specific to u-boot.
> > > 
> > > SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
> > > two cases:
> > >   1) u-boot as a FIT (binary and FDT separately loaded)
> > >   2) u-boot with embedded FDT
> > > 
> > > In case (1) SPL must place the FDT at a location where u-boot will find 
> > > it.
> > > The current logic is
> > >   SPL:fdt = ALIGN_4(u_boot + u_boot_size)
> > >   u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> > > 
> > > In case (2), SPL's view of the FDT is not relevant, but instead the build
> > > system must place the FDT correctly:
> > >   build:  fdt >> u-boot.bin
> > >   u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> > > 
> > > We have 3 places that must agree. A correct and complete patch could 
> > > change
> > > all three, but one has to consider compatibility issues when crossing 
> > > u-boot
> > > and SPL versions.
> > > 
> > > I had proposed in the revert discussion that SPL use r2 or similar 
> > > mechanism
> > > to pass the location of the FDT to u-boot.
> > 
> > I'm not sure that we need to worry too much about mix-and-match
> > SPL/U-Boot, but documenting what to go change if you must do it
> > somewhere under doc/ would be good.  I think we can just switch to
> > ALIGN(8) not ALIGN(4) and be done with it?
> 
> Remember, there is also falcon boot. And we definitely have to be able to
> have old u-boot (SPL) boot new fitImage and vice versa.

I don't follow you, sorry.  But since you seem to have the best
understanding of where all of the cases something could go wrong here,
can you perhaps post an RFC patch?  That is likely to be clearer than
another long thread here.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary


On 7/13/21 3:47 PM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:

On 7/12/21 10:15 AM, Tom Rini wrote:

On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:

On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:


I submitted an almost identical patch. See 
https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76

This patch eventually had to be reverted 
(https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
 because it was causing issues on some platforms that had FIT on 32 bit 
boundary. However I continue to use it in production code, as without it the 
boot on my platform aborts.

I don't have time to investigate why this was happening, but you need to check 
this code won't just cause exactly the same faults.


Thanks for your information.

+Marek who did the revert

The revert commit message says:

  "The commit breaks booting of fitImage by SPL, the system simply
hangs. This is because on arm32, the fitImage and all of its content
can be aligned to 4 bytes and U-Boot expects just that."

I don't understand this. If an address is aligned to 8, it is already
aligned to 4, so how did this commit make the system hang on arm32?


I think this had something to do with embedding contents somewhere in
the image?  There is a thread on the ML from then but I don't know how
informative it will end up being.


It's true that the flat devicetree spec requires an 8-byte alignment, even
on 32-bit. The issues here are specific to u-boot.

SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
two cases:
1) u-boot as a FIT (binary and FDT separately loaded)
2) u-boot with embedded FDT

In case (1) SPL must place the FDT at a location where u-boot will find it.
The current logic is
SPL:fdt = ALIGN_4(u_boot + u_boot_size)
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

In case (2), SPL's view of the FDT is not relevant, but instead the build
system must place the FDT correctly:
build:  fdt >> u-boot.bin
u-boot: fdt = ALIGN_4(u_boot + u_boot_size)

We have 3 places that must agree. A correct and complete patch could change
all three, but one has to consider compatibility issues when crossing u-boot
and SPL versions.

I had proposed in the revert discussion that SPL use r2 or similar mechanism
to pass the location of the FDT to u-boot.


I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?


Remember, there is also falcon boot. And we definitely have to be able 
to have old u-boot (SPL) boot new fitImage and vice versa.

Re: zynqmpbif - sample

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/07/21, Michal Simek wrote:
> > > 
> > > 
> > > On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > > >> On 13/07/21, Michal Simek wrote:
> > > >>> Hi,
> > > >>>
> > > >>> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > >  hi Michal,
> > > 
> > >  Would you have some sample/reference code to generate a SPL boot 
> > >  image
> > >  using zynqmpbif instead of zynqmpimage? I cant find any documentation
> > >  and I see no option to enable it (I was expecting to find some config
> > >  in Makefile.spl but I see none).
> > > 
> > >  What is the expected way of building these images?
> > > >>>
> > > >>> Alex implemented it for Xilinx bif format after origin zynqmpimage
> > > >>> format. But usage is just like this.
> > > >>>
> > > >>> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif
> > > >>> /tmp/boot.bin
> > > >>> Image Type   : Xilinx ZynqMP Boot Image support
> > > >>> Image Offset : 0x09c0
> > > >>> Image Size   : 147216 bytes (147216 bytes packed)
> > > >>> PMUFW Size   : 129792 bytes (129792 bytes packed)
> > > >>> Image Load   : 0xfffc
> > > >>> Checksum : 0xfd15d661
> > > >>> [u-boot](debian-sent)$ cat /tmp/bif
> > > >>> image : {
> > > >>>   [pmufw_image, load=0xffdc] 
> > > >>> /mnt/disk/u-boot-bins/zynqmp/pmu.elf
> > > >>>   [destination_cpu=a53-0, load=0xfffc, bootloader] 
> > > >>> spl/u-boot-spl.bin
> > > >>> }
> > > >>
> > > >> awesome, exactly what I needed to start with.
> > > > 
> > > > So I can boot using the steps you mentioned above.
> > > > 
> > > > But shouldnt the same bif work with bootgen?
> > > > 
> > > > ** Xilinx Bootgen v2019.2
> > > >    Build date : Oct 23 2019-22:59:42
> > > > ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
> > > > 
> > > > [TRACE]  : Command Line parsing started
> > > > [TRACE]  : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log 
> > > > trace
> > > > [INFO]   : Command line parsing completed successfully
> > > > [TRACE]  : BIF File: ./bif
> > > > [TRACE]  : BIF file parsing started
> > > > [TRACE]  : Setting PMU FW Image file as pmu.elf
> > > > [INFO]   : BIF file parsing completed successfully
> > > > [INFO]   : Parsing Partition Data to Image
> > > > [INFO]   : Building image - image
> > > > [INFO]   : Building the Partition Header Table
> > > > [INFO]   : After build
> > > >-- Dump of Binary Image 
> > > > Len: 08b8 Res:  "BootHeader"
> > > > Len: 0040 Res:  "ImageHeaderTable"
> > > > Len: 0024 Res: 0800 "ImageHeader 
> > > > u-boot-spl.bin"
> > > > Len: 0040 Res:  "PartitionHeader 
> > > > u-boot-spl.bin.0"
> > > > Len: 0040 Res: 16c0 "PartitionHeader Null"
> > > > Len: 00020574 Res:  "u-boot-spl.bin.0"
> > > >-- End of Dump
> > > > [INFO]   : After align
> > > >-- Dump of Binary Image 
> > > > Len: 08b8 Res:  "BootHeader"
> > > >08c0 Len: 0040 Res:  "ImageHeaderTable"
> > > >0900 Len: 0024 Res: 0800 "ImageHeader 
> > > > u-boot-spl.bin"
> > > >1100 Len: 0040 Res:  "PartitionHeader 
> > > > u-boot-spl.bin.0"
> > > >1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
> > > >2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
> > > >-- End of Dump
> > > > [INFO]   : Partition Information:
> > > > [INFO]   : Image: u-boot-spl.bin
> > > > [INFO]   :Partition 0: u-boot-spl.bin.0,  Size: 132467
> > > > [INFO]   : After Link
> > > >-- Dump of Binary Image 
> > > > Len: 08b8 Res:  "BootHeader"
> > > >08c0 Len: 0040 Res:  "ImageHeaderTable"
> > > >0900 Len: 0024 Res: 0800 "ImageHeader 
> > > > u-boot-spl.bin"
> > > >1100 Len: 0040 Res:  "PartitionHeader 
> > > > u-boot-spl.bin.0"
> > > >1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
> > > >2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
> > > >-- End of Dump
> > > > 
> > > > 
> > > > however when I boot and inspect the processor state, xsdb returns "APU
> > > > L2 cache is held in reset"
> > > > 
> > > > Since the functionality to support RSA authentication is missing from
> > > > mkimage (I'll have to add that), I would first like to see it
> > > > functional with SPL using bootgen.
> > > > 
> > > > However the same bif doesnt even boot - is this to be expected?
> > > > 
> > > > also the layouts generated from the bif using mkimage and bootgen

Re: [PATCH 3/5] efi_loader: add boot variable measurement

2021-07-13 Thread Heinrich Schuchardt





On 13.07.21 10:31, Masahisa Kojima wrote:

Hi Heinrich,


TCG spec also requires to measure "Calling EFI Application from
Boot Option" for each boot attempt, and "Returning from EFI
Application from Boot Option" if a boot device returns control
back to the Boot Manager.


I would like to hear your opinion regarding
"Calling EFI Application from Boot Option" measurement.

My current(v1 patch series) implementation considers
both "bootefi bootmgr" and "bootefi $image_addr" cases,
so I do this "Calling EFI Application from Boot Option" measurement
at efi_boottime.c::efi_start_image().
Do I need to implement only the case UEFI application boot from bootmgr?
If yes, I will move the timing of this measurement at
efi_bootmgr.c::efi_bootmgr_load().

As a reference, in edk2, this measurement is performed in
ready_to_boot event handler, ready_to_boot handler is called
upon the user selects the boot option in boot manager.


When booting you can call

   bootefi $driver1
   booefii $driver2
   bootefi bootmgr

in sequence.

Any of the binaries can call LoadImage(), StartImage() multiple times to
execute further images. E.g. I am loading iPXE. By default it loads GRUB
from an iSCSI drive but I can choose in the menu or the iPXE console to
invoke another UEFI binary.

I suggest to measure any image no matter how it is invoked. The
measurement must depend on the sequence of invocation.

Best regards

Heinrich



What do you think?

Thanks,
Masahisa Kojima





On Fri, 9 Jul 2021 at 11:44, Masahisa Kojima  wrote:


On Fri, 9 Jul 2021 at 02:46, Heinrich Schuchardt  wrote:


On 7/7/21 3:36 PM, Masahisa Kojima wrote:

TCG PC Client PFP spec requires to measure "Boot"
and "BootOrder" variables, EV_SEPARATOR event prior
to the Ready to Boot invocation.
Since u-boot does not implement Ready to Boot event,
these measurements are performed when efi_start_image() is called.

TCG spec also requires to measure "Calling EFI Application from
Boot Option" for each boot attempt, and "Returning from EFI
Application from Boot Option" if a boot device returns control
back to the Boot Manager.

Signed-off-by: Masahisa Kojima 
---
   include/efi_loader.h  |   4 ++
   include/tpm-v2.h  |  18 -
   lib/efi_loader/efi_boottime.c |  20 ++
   lib/efi_loader/efi_tcg2.c | 123 ++
   4 files changed, 164 insertions(+), 1 deletion(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 0a9c82a257..28130f 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -407,6 +407,10 @@ efi_status_t efi_run_image(void *source_buffer, 
efi_uintn_t source_size);
   efi_status_t efi_init_variables(void);
   /* Notify ExitBootServices() is called */
   void efi_variables_boot_exit_notify(void);
+/* Measure efi application invocation */
+efi_status_t EFIAPI efi_tcg2_measure_efi_app_invocation(void);
+/* Measure efi application exit */
+efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void);
   /* Called by bootefi to initialize root node */
   efi_status_t efi_root_node_register(void);
   /* Called by bootefi to initialize runtime */
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 3e48e35861..8a7b7f1874 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -73,7 +73,7 @@ struct udevice;
   /*
* event types, cf.
* "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
- * rev 1.04, June 3, 2019
+ * Level 00 Version 1.05 Revision 23, May 7, 2021
*/
   #define EV_EFI_EVENT_BASE   ((u32)0x8000)
   #define EV_EFI_VARIABLE_DRIVER_CONFIG   ((u32)0x8001)
@@ -85,8 +85,24 @@ struct udevice;
   #define EV_EFI_ACTION   ((u32)0x8007)
   #define EV_EFI_PLATFORM_FIRMWARE_BLOB   ((u32)0x8008)
   #define EV_EFI_HANDOFF_TABLES   ((u32)0x8009)
+#define EV_EFI_PLATFORM_FIRMWARE_BLOB2   ((u32)0x800A)
+#define EV_EFI_HANDOFF_TABLES2   ((u32)0x800B)
+#define EV_EFI_VARIABLE_BOOT2((u32)0x800C)
   #define EV_EFI_HCRTM_EVENT  ((u32)0x8010)
   #define EV_EFI_VARIABLE_AUTHORITY   ((u32)0x80E0)
+#define EV_EFI_SPDM_FIRMWARE_BLOB((u32)0x80E1)
+#define EV_EFI_SPDM_FIRMWARE_CONFIG  ((u32)0x80E2)
+
+#define EFI_CALLING_EFI_APPLICATION \
+ "Calling EFI Application from Boot Option"
+#define EFI_RETURNING_FROM_EFI_APPLICATION  \
+ "Returning from EFI Application from Boot Option"
+#define EFI_EXIT_BOOT_SERVICES_INVOCATION   \
+ "Exit Boot Services Invocation"
+#define EFI_EXIT_BOOT_SERVICES_FAILED   \
+ "Exit Boot Services Returned with Failure"
+#define EFI_EXIT_BOOT_SERVICES_SUCCEEDED\
+ "Exit Boot Services Returned with Success"


Which spec defines if the string in the event log shall be utf-8 or utf-16?


TCG PC Client PFP spec does not clearly define the character encoding.
In my understanding,

[PATCHv2] configs: am65x_evm: Switch envboot out for distro_bootcmd

Swap out the TI-centric "envboot" logic for the generic distro_bootcmd
logic for the bootcmd we run before trying to do something more complex
involving additional firmware, etc.

Cc: Lokesh Vutla 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Only change to distroboot for a53 and not r5.
---
 configs/am65x_evm_a53_defconfig |  2 +-
 include/configs/am65x_evm.h | 14 --
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
index 6f9309e17147..eefcdfa36571 100644
--- a/configs/am65x_evm_a53_defconfig
+++ b/configs/am65x_evm_a53_defconfig
@@ -29,7 +29,7 @@ CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 # CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run 
boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
get_overlay_${boot}; run run_kern"
 CONFIG_LOGLEVEL=7
 CONFIG_CONSOLE_MUX=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 8c50fe9d11ff..d4514a0dbada 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -10,7 +10,6 @@
 #define __CONFIG_AM654_EVM_H
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -126,6 +125,16 @@
DFU_ALT_INFO_EMMC   \
DFU_ALT_INFO_OSPI
 
+#ifdef CONFIG_TARGET_AM654_A53_EVM
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 1) \
+   func(MMC, mmc, 0)
+
+#include 
+#else
+#define BOOTENV
+#endif
+
 /* Incorporate settings into the U-Boot environment */
 #define CONFIG_EXTRA_ENV_SETTINGS  \
DEFAULT_LINUX_BOOT_ENV  \
@@ -136,7 +145,8 @@
EXTRA_ENV_AM65X_BOARD_SETTINGS_MTD  \
EXTRA_ENV_AM65X_BOARD_SETTINGS_UBI  \
EXTRA_ENV_RPROC_SETTINGS\
-   EXTRA_ENV_DFUARGS
+   EXTRA_ENV_DFUARGS   \
+   BOOTENV
 
 #define CONFIG_SYS_USB_FAT_BOOT_PARTITION 1
 
-- 
2.17.1

Re: [PATCH] configs: am65x_evm: Switch envboot out for distro_bootcmd

On Tue, Jul 13, 2021 at 02:33:15PM +0530, Lokesh Vutla wrote:
> 
> 
> On 02/07/21 1:34 am, Tom Rini wrote:
> > Swap out the TI-centric "envboot" logic for the generic distro_bootcmd
> > logic for the bootcmd we run before trying to do something more complex
> > involving additional firmware, etc.
> > 
> > Cc: Lokesh Vutla 
> > Signed-off-by: Tom Rini 
> 
> This is causing build errors for am6 platforms.
> https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/291139

Ah, whopos.  While I'm a little puzzled by why we have so many r5
configs, I see what to change here, v2 shortly.

-- 
Tom


signature.asc
Description: PGP signature

Re: zynqmpbif - sample

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Michal Simek wrote:
> > 
> > 
> > On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> > >> On 13/07/21, Michal Simek wrote:
> > >>> Hi,
> > >>>
> > >>> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> >  hi Michal,
> > 
> >  Would you have some sample/reference code to generate a SPL boot image
> >  using zynqmpbif instead of zynqmpimage? I cant find any documentation
> >  and I see no option to enable it (I was expecting to find some config
> >  in Makefile.spl but I see none).
> > 
> >  What is the expected way of building these images?
> > >>>
> > >>> Alex implemented it for Xilinx bif format after origin zynqmpimage
> > >>> format. But usage is just like this.
> > >>>
> > >>> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif
> > >>> /tmp/boot.bin
> > >>> Image Type   : Xilinx ZynqMP Boot Image support
> > >>> Image Offset : 0x09c0
> > >>> Image Size   : 147216 bytes (147216 bytes packed)
> > >>> PMUFW Size   : 129792 bytes (129792 bytes packed)
> > >>> Image Load   : 0xfffc
> > >>> Checksum : 0xfd15d661
> > >>> [u-boot](debian-sent)$ cat /tmp/bif
> > >>> image : {
> > >>> [pmufw_image, load=0xffdc] 
> > >>> /mnt/disk/u-boot-bins/zynqmp/pmu.elf
> > >>> [destination_cpu=a53-0, load=0xfffc, bootloader] 
> > >>> spl/u-boot-spl.bin
> > >>> }
> > >>
> > >> awesome, exactly what I needed to start with.
> > > 
> > > So I can boot using the steps you mentioned above.
> > > 
> > > But shouldnt the same bif work with bootgen?
> > > 
> > > ** Xilinx Bootgen v2019.2
> > >    Build date : Oct 23 2019-22:59:42
> > > ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
> > > 
> > > [TRACE]  : Command Line parsing started
> > > [TRACE]  : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace
> > > [INFO]   : Command line parsing completed successfully
> > > [TRACE]  : BIF File: ./bif
> > > [TRACE]  : BIF file parsing started
> > > [TRACE]  : Setting PMU FW Image file as pmu.elf
> > > [INFO]   : BIF file parsing completed successfully
> > > [INFO]   : Parsing Partition Data to Image
> > > [INFO]   : Building image - image
> > > [INFO]   : Building the Partition Header Table
> > > [INFO]   : After build
> > >-- Dump of Binary Image 
> > > Len: 08b8 Res:  "BootHeader"
> > > Len: 0040 Res:  "ImageHeaderTable"
> > > Len: 0024 Res: 0800 "ImageHeader 
> > > u-boot-spl.bin"
> > > Len: 0040 Res:  "PartitionHeader 
> > > u-boot-spl.bin.0"
> > > Len: 0040 Res: 16c0 "PartitionHeader Null"
> > > Len: 00020574 Res:  "u-boot-spl.bin.0"
> > >-- End of Dump
> > > [INFO]   : After align
> > >-- Dump of Binary Image 
> > > Len: 08b8 Res:  "BootHeader"
> > >08c0 Len: 0040 Res:  "ImageHeaderTable"
> > >0900 Len: 0024 Res: 0800 "ImageHeader 
> > > u-boot-spl.bin"
> > >1100 Len: 0040 Res:  "PartitionHeader 
> > > u-boot-spl.bin.0"
> > >1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
> > >2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
> > >-- End of Dump
> > > [INFO]   : Partition Information:
> > > [INFO]   : Image: u-boot-spl.bin
> > > [INFO]   :Partition 0: u-boot-spl.bin.0,  Size: 132467
> > > [INFO]   : After Link
> > >-- Dump of Binary Image 
> > > Len: 08b8 Res:  "BootHeader"
> > >08c0 Len: 0040 Res:  "ImageHeaderTable"
> > >0900 Len: 0024 Res: 0800 "ImageHeader 
> > > u-boot-spl.bin"
> > >1100 Len: 0040 Res:  "PartitionHeader 
> > > u-boot-spl.bin.0"
> > >1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
> > >2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
> > >-- End of Dump
> > > 
> > > 
> > > however when I boot and inspect the processor state, xsdb returns "APU
> > > L2 cache is held in reset"
> > > 
> > > Since the functionality to support RSA authentication is missing from
> > > mkimage (I'll have to add that), I would first like to see it
> > > functional with SPL using bootgen.
> > > 
> > > However the same bif doesnt even boot - is this to be expected?
> > > 
> > > also the layouts generated from the bif using mkimage and bootgen are
> > > completely different (it seems that naively I expected them to be the
> > > same); is there any information on the different layouts used for the
> > > bootrom? 
> > 
> > 
> > I tested it and it works fine for me. Take a look at the code what
> > exactly is
> > 
> >

Re: [PATCH] spl: Align device tree blob address at 8-byte boundary

On Mon, Jul 12, 2021 at 11:01:24AM -0500, Alex G. wrote:
> On 7/12/21 10:15 AM, Tom Rini wrote:
> > On Mon, Jul 12, 2021 at 01:36:14PM +0800, Bin Meng wrote:
> > > On Mon, Jul 12, 2021 at 1:21 PM Reuben Dowle  wrote:
> > > > 
> > > > I submitted an almost identical patch. See 
> > > > https://github.com/u-boot/u-boot/commit/eb39d8ba5f0d1468b01b89a2a464d18612d3ea76
> > > > 
> > > > This patch eventually had to be reverted 
> > > > (https://github.com/u-boot/u-boot/commit/5675ed7cb645f5ec13958726992daeeed16fd114),
> > > >  because it was causing issues on some platforms that had FIT on 32 bit 
> > > > boundary. However I continue to use it in production code, as without 
> > > > it the boot on my platform aborts.
> > > > 
> > > > I don't have time to investigate why this was happening, but you need 
> > > > to check this code won't just cause exactly the same faults.
> > > 
> > > Thanks for your information.
> > > 
> > > +Marek who did the revert
> > > 
> > > The revert commit message says:
> > > 
> > >  "The commit breaks booting of fitImage by SPL, the system simply
> > > hangs. This is because on arm32, the fitImage and all of its content
> > > can be aligned to 4 bytes and U-Boot expects just that."
> > > 
> > > I don't understand this. If an address is aligned to 8, it is already
> > > aligned to 4, so how did this commit make the system hang on arm32?
> > 
> > I think this had something to do with embedding contents somewhere in
> > the image?  There is a thread on the ML from then but I don't know how
> > informative it will end up being.
> 
> It's true that the flat devicetree spec requires an 8-byte alignment, even
> on 32-bit. The issues here are specific to u-boot.
> 
> SPL and u-boot have to agree where u-boot's FDT is located. We'll look at
> two cases:
>   1) u-boot as a FIT (binary and FDT separately loaded)
>   2) u-boot with embedded FDT
> 
> In case (1) SPL must place the FDT at a location where u-boot will find it.
> The current logic is
>   SPL:fdt = ALIGN_4(u_boot + u_boot_size)
>   u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> 
> In case (2), SPL's view of the FDT is not relevant, but instead the build
> system must place the FDT correctly:
>   build:  fdt >> u-boot.bin
>   u-boot: fdt = ALIGN_4(u_boot + u_boot_size)
> 
> We have 3 places that must agree. A correct and complete patch could change
> all three, but one has to consider compatibility issues when crossing u-boot
> and SPL versions.
> 
> I had proposed in the revert discussion that SPL use r2 or similar mechanism
> to pass the location of the FDT to u-boot.

I'm not sure that we need to worry too much about mix-and-match
SPL/U-Boot, but documenting what to go change if you must do it
somewhere under doc/ would be good.  I think we can just switch to
ALIGN(8) not ALIGN(4) and be done with it?

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/5] spi: fsl_qspi: Build driver only if DM_SPI is available

2021-07-13 Thread Stefan Roese


On 13.07.21 11:14, Frieder Schrempf wrote:

From: Frieder Schrempf 

The driver depends on DM_SPI and if it's not available (e. g. in SPL),
then we should not try to build it as this will fail.

Signed-off-by: Frieder Schrempf 


Looks good, but you could also add a "depends on DM_SPI" to the Kconfig
entry of this driver.

Reviewed-by: Stefan Roese 

Thanks,
Stefan


---
  drivers/spi/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index f70851e4bc..216e72c60f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
  obj-$(CONFIG_SOFT_SPI) += soft_spi.o
  obj-$(CONFIG_SPI_MEM) += spi-mem.o
  obj-$(CONFIG_TI_QSPI) += ti_qspi.o
+obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
  else
  obj-y += spi.o
  obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
@@ -30,7 +31,6 @@ obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
  obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
  obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
  obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
-obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
  obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o
  obj-$(CONFIG_ICH_SPI) +=  ich.o
  obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o




Viele Grüße,
Stefan

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de

RE: [PATCH v2 0/5] arm: dts: Add PMIC node for J7200

2021-07-13 Thread Tammana, Gowtham



>-Original Message-
>From: Vutla, Lokesh
>Sent: Tuesday, July 13, 2021 1:57 AM
>To: Tammana, Gowtham ; Tom Rini ;
>jh80.ch...@samsung.com
>Cc: Bajjuri, Praneeth ; u-boot@lists.denx.de
>Subject: Re: [PATCH v2 0/5] arm: dts: Add PMIC node for J7200
>
>
>
>On 24/06/21 2:44 am, Gowtham Tammana wrote:
>> The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset
>> adds dt nodes, compatible string, and configs to enable the
>> corresponding driver.
>>
>> v2:
>>  - rebased the changes are reordered patches 3/4
>
>There are minor conflicts with latest master. Can you rebase and repost?

Sure. Will rebase and post v3.

Gowtham

>
>Thanks and regards,
>Lokesh
>
>>
>> v1:
>>  - https://lore.kernel.org/u-boot/20200915113633.25449-1-g-
>tamm...@ti.com/
>>
>> Gowtham Tammana (5):
>>   power: pmic: tps65941: Add compatible for LP876441
>>   arm/dts: k3-j7200-r5-common: Add pmic lp876441 node
>>   arm/dts: k3-j7200-r5-common: Add VTM node
>>   arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply
>>   configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent
>> configs
>>
>>  .../arm/dts/k3-j7200-r5-common-proc-board.dts | 38 +++
>>  configs/j7200_evm_r5_defconfig|  6 +++
>>  drivers/power/pmic/tps65941.c |  1 +
>>  include/power/tps65941.h  |  1 +
>>  4 files changed, 46 insertions(+)
>>

[PATCH] net: emaclite: fix possible underflow bug

2021-07-13 Thread Tianrui Wei

This commit fixes a corner case when length < first_read. which would
cause the last argument of xemaclite_alignedread to be a very large
unsigned integer.

Signed-off-by: Tianrui Wei 
---
 drivers/net/xilinx_emaclite.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xilinx_emaclite.c b/drivers/net/xilinx_emaclite.c
index 43fc36dc6a..3b8f0f4678 100644
--- a/drivers/net/xilinx_emaclite.c
+++ b/drivers/net/xilinx_emaclite.c
@@ -526,7 +526,7 @@ try_again:
}
 
/* Read the rest of the packet which is longer then first read */
-   if (length != first_read)
+   if (length >= first_read)
xemaclite_alignedread(addr + first_read,
  etherrxbuff + first_read,
  length - first_read);
-- 
2.32.0

Re: [PATCH 1/4] phy: phy-imx8mq-usb: Add USB PHY driver for i.MX8MQ

2021-07-13 Thread Stefano Babic


On 13.07.21 13:53, Marek Vasut wrote:

On 7/13/21 1:22 PM, Patrick Wildt wrote:

Am Tue, Jul 13, 2021 at 12:46:04PM +0200 schrieb Stefano Babic:

On 13.07.21 12:39, Marek Vasut wrote:

On 7/13/21 7:53 AM, Stefano Babic wrote:

Hi Fabio,

On 12.07.21 23:31, Fabio Estevam wrote:

Hi Patrick,

On Mon, Jul 12, 2021 at 11:27 AM Patrick Wildt
 wrote:


Am Sun, Feb 21, 2021 at 08:26:21AM -0800 schrieb Ye Li:
Add the USB PHY driver for i.MX8MQ to work with DWC3 USB 
controller.


Signed-off-by: Ye Li 


Reviewed-by: Patrick Wildt 
Tested-by: Patrick Wildt 


It seems Ye Li missed adding Marek on Cc.

Could you please resend the series with Marek on Cc?



I see that the series is already assigned to Marek:

http://patchwork.ozlabs.org/project/uboot/list/?series=230965

So I guess it is enough to inform Marek (in CC) about this and he
can review / apply the patches without reposting.


USB3 is Bin.


Then delegate on patchwork is wrong as the patches are assigned to you.


The patches contain a new PHY driver, i.MX8MQ clock init code and device
tree change.  So it's not really USB, it's just some work in the i.MX8MQ
stuff to *enable* USB.


Then just lets have Stefano pick it all, since its imx anyway, and be 
done with it.


Right, it looks like I took advantage that patches were not assigned to 
me and I have simply ignored...


I set myself as delegate and I will pick them up.

Regards,
Stefano

--
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Re: [PATCH 1/4] phy: phy-imx8mq-usb: Add USB PHY driver for i.MX8MQ


On 7/13/21 1:22 PM, Patrick Wildt wrote:

Am Tue, Jul 13, 2021 at 12:46:04PM +0200 schrieb Stefano Babic:

On 13.07.21 12:39, Marek Vasut wrote:

On 7/13/21 7:53 AM, Stefano Babic wrote:

Hi Fabio,

On 12.07.21 23:31, Fabio Estevam wrote:

Hi Patrick,

On Mon, Jul 12, 2021 at 11:27 AM Patrick Wildt
 wrote:


Am Sun, Feb 21, 2021 at 08:26:21AM -0800 schrieb Ye Li:

Add the USB PHY driver for i.MX8MQ to work with DWC3 USB controller.

Signed-off-by: Ye Li 


Reviewed-by: Patrick Wildt 
Tested-by: Patrick Wildt 


It seems Ye Li missed adding Marek on Cc.

Could you please resend the series with Marek on Cc?



I see that the series is already assigned to Marek:

http://patchwork.ozlabs.org/project/uboot/list/?series=230965

So I guess it is enough to inform Marek (in CC) about this and he
can review / apply the patches without reposting.


USB3 is Bin.


Then delegate on patchwork is wrong as the patches are assigned to you.


The patches contain a new PHY driver, i.MX8MQ clock init code and device
tree change.  So it's not really USB, it's just some work in the i.MX8MQ
stuff to *enable* USB.


Then just lets have Stefano pick it all, since its imx anyway, and be 
done with it.

Re: zynqmpbif - sample

On 13/07/21, Michal Simek wrote:
> 
> 
> On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> >> On 13/07/21, Michal Simek wrote:
> >>> Hi,
> >>>
> >>> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
>  hi Michal,
> 
>  Would you have some sample/reference code to generate a SPL boot image
>  using zynqmpbif instead of zynqmpimage? I cant find any documentation
>  and I see no option to enable it (I was expecting to find some config
>  in Makefile.spl but I see none).
> 
>  What is the expected way of building these images?
> >>>
> >>> Alex implemented it for Xilinx bif format after origin zynqmpimage
> >>> format. But usage is just like this.
> >>>
> >>> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif
> >>> /tmp/boot.bin
> >>> Image Type   : Xilinx ZynqMP Boot Image support
> >>> Image Offset : 0x09c0
> >>> Image Size   : 147216 bytes (147216 bytes packed)
> >>> PMUFW Size   : 129792 bytes (129792 bytes packed)
> >>> Image Load   : 0xfffc
> >>> Checksum : 0xfd15d661
> >>> [u-boot](debian-sent)$ cat /tmp/bif
> >>> image : {
> >>>   [pmufw_image, load=0xffdc] /mnt/disk/u-boot-bins/zynqmp/pmu.elf
> >>>   [destination_cpu=a53-0, load=0xfffc, bootloader] spl/u-boot-spl.bin
> >>> }
> >>
> >> awesome, exactly what I needed to start with.
> > 
> > So I can boot using the steps you mentioned above.
> > 
> > But shouldnt the same bif work with bootgen?
> > 
> > ** Xilinx Bootgen v2019.2
> >    Build date : Oct 23 2019-22:59:42
> > ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
> > 
> > [TRACE]  : Command Line parsing started
> > [TRACE]  : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace
> > [INFO]   : Command line parsing completed successfully
> > [TRACE]  : BIF File: ./bif
> > [TRACE]  : BIF file parsing started
> > [TRACE]  : Setting PMU FW Image file as pmu.elf
> > [INFO]   : BIF file parsing completed successfully
> > [INFO]   : Parsing Partition Data to Image
> > [INFO]   : Building image - image
> > [INFO]   : Building the Partition Header Table
> > [INFO]   : After build
> >-- Dump of Binary Image 
> > Len: 08b8 Res:  "BootHeader"
> > Len: 0040 Res:  "ImageHeaderTable"
> > Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
> > Len: 0040 Res:  "PartitionHeader 
> > u-boot-spl.bin.0"
> > Len: 0040 Res: 16c0 "PartitionHeader Null"
> > Len: 00020574 Res:  "u-boot-spl.bin.0"
> >-- End of Dump
> > [INFO]   : After align
> >-- Dump of Binary Image 
> > Len: 08b8 Res:  "BootHeader"
> >08c0 Len: 0040 Res:  "ImageHeaderTable"
> >0900 Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
> >1100 Len: 0040 Res:  "PartitionHeader 
> > u-boot-spl.bin.0"
> >1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
> >2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
> >-- End of Dump
> > [INFO]   : Partition Information:
> > [INFO]   : Image: u-boot-spl.bin
> > [INFO]   :Partition 0: u-boot-spl.bin.0,  Size: 132467
> > [INFO]   : After Link
> >-- Dump of Binary Image 
> > Len: 08b8 Res:  "BootHeader"
> >08c0 Len: 0040 Res:  "ImageHeaderTable"
> >0900 Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
> >1100 Len: 0040 Res:  "PartitionHeader 
> > u-boot-spl.bin.0"
> >1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
> >2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
> >-- End of Dump
> > 
> > 
> > however when I boot and inspect the processor state, xsdb returns "APU
> > L2 cache is held in reset"
> > 
> > Since the functionality to support RSA authentication is missing from
> > mkimage (I'll have to add that), I would first like to see it
> > functional with SPL using bootgen.
> > 
> > However the same bif doesnt even boot - is this to be expected?
> > 
> > also the layouts generated from the bif using mkimage and bootgen are
> > completely different (it seems that naively I expected them to be the
> > same); is there any information on the different layouts used for the
> > bootrom? 
> 
> 
> I tested it and it works fine for me. Take a look at the code what
> exactly is
> 
> [u-boot]$ cat /tmp/bif
> image : {
>   [pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin
>   [destination_cpu=a53-0, load=0xfffc, bootloader]
> spl/u-boot-spl-align.bin
> }
> 
> Didn't try the latest bootgen but format is changing over years but none
> is updating this tool. Feel free to take a look at it.

Re: [PATCH 1/4] phy: phy-imx8mq-usb: Add USB PHY driver for i.MX8MQ

2021-07-13 Thread Patrick Wildt

Am Tue, Jul 13, 2021 at 12:46:04PM +0200 schrieb Stefano Babic:
> On 13.07.21 12:39, Marek Vasut wrote:
> > On 7/13/21 7:53 AM, Stefano Babic wrote:
> > > Hi Fabio,
> > > 
> > > On 12.07.21 23:31, Fabio Estevam wrote:
> > > > Hi Patrick,
> > > > 
> > > > On Mon, Jul 12, 2021 at 11:27 AM Patrick Wildt
> > > >  wrote:
> > > > > 
> > > > > Am Sun, Feb 21, 2021 at 08:26:21AM -0800 schrieb Ye Li:
> > > > > > Add the USB PHY driver for i.MX8MQ to work with DWC3 USB controller.
> > > > > > 
> > > > > > Signed-off-by: Ye Li 
> > > > > 
> > > > > Reviewed-by: Patrick Wildt 
> > > > > Tested-by: Patrick Wildt 
> > > > 
> > > > It seems Ye Li missed adding Marek on Cc.
> > > > 
> > > > Could you please resend the series with Marek on Cc?
> > > > 
> > > 
> > > I see that the series is already assigned to Marek:
> > > 
> > > http://patchwork.ozlabs.org/project/uboot/list/?series=230965
> > > 
> > > So I guess it is enough to inform Marek (in CC) about this and he
> > > can review / apply the patches without reposting.
> > 
> > USB3 is Bin.
> 
> Then delegate on patchwork is wrong as the patches are assigned to you.

The patches contain a new PHY driver, i.MX8MQ clock init code and device
tree change.  So it's not really USB, it's just some work in the i.MX8MQ
stuff to *enable* USB.

Re: [PATCH 1/4] phy: phy-imx8mq-usb: Add USB PHY driver for i.MX8MQ

2021-07-13 Thread Stefano Babic


On 13.07.21 12:39, Marek Vasut wrote:

On 7/13/21 7:53 AM, Stefano Babic wrote:

Hi Fabio,

On 12.07.21 23:31, Fabio Estevam wrote:

Hi Patrick,

On Mon, Jul 12, 2021 at 11:27 AM Patrick Wildt  
wrote:


Am Sun, Feb 21, 2021 at 08:26:21AM -0800 schrieb Ye Li:

Add the USB PHY driver for i.MX8MQ to work with DWC3 USB controller.

Signed-off-by: Ye Li 


Reviewed-by: Patrick Wildt 
Tested-by: Patrick Wildt 


It seems Ye Li missed adding Marek on Cc.

Could you please resend the series with Marek on Cc?



I see that the series is already assigned to Marek:

http://patchwork.ozlabs.org/project/uboot/list/?series=230965

So I guess it is enough to inform Marek (in CC) about this and he can 
review / apply the patches without reposting.


USB3 is Bin.


Then delegate on patchwork is wrong as the patches are assigned to you.

Regards,
Stefano

--
=
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=

Re: [PATCH 1/4] phy: phy-imx8mq-usb: Add USB PHY driver for i.MX8MQ


On 7/13/21 7:53 AM, Stefano Babic wrote:

Hi Fabio,

On 12.07.21 23:31, Fabio Estevam wrote:

Hi Patrick,

On Mon, Jul 12, 2021 at 11:27 AM Patrick Wildt  wrote:


Am Sun, Feb 21, 2021 at 08:26:21AM -0800 schrieb Ye Li:

Add the USB PHY driver for i.MX8MQ to work with DWC3 USB controller.

Signed-off-by: Ye Li 


Reviewed-by: Patrick Wildt 
Tested-by: Patrick Wildt 


It seems Ye Li missed adding Marek on Cc.

Could you please resend the series with Marek on Cc?



I see that the series is already assigned to Marek:

http://patchwork.ozlabs.org/project/uboot/list/?series=230965

So I guess it is enough to inform Marek (in CC) about this and he can 
review / apply the patches without reposting.


USB3 is Bin.

Re: [PATCH 4/6] imx8m: Restrict usable memory to space below 4G boundary


On 7/13/21 11:25 AM, Frieder Schrempf wrote:

On 15.06.21 02:41, Marek Vasut wrote:

On 6/15/21 2:28 AM, Peng Fan (OSS) wrote:



On 2021/6/7 20:38, Marek Vasut wrote:

On 6/7/21 2:05 PM, Frieder Schrempf wrote:

From: Frieder Schrempf 

Some IPs have their accessible address space restricted by the
interconnect. Let's make sure U-Boot only ever uses the space below
the 4G address boundary (which is 3GiB big), even when the effective
available memory is bigger.

We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the
whole family is affected by this.


Shouldn't only those specific IP drivers handle buffers in the 64bit space 
somehow ? E.g. using a bounce buffer ?


That could cause extra mem copy.


If you want to avoid the extra memcopy, then make sure the buffers are not 
allocated above 4 GiB boundary. Then the bounce buffer does no copy.

This board_get_usable_ram_top() is just a temporary workaround for platforms 
with broken drivers which are not fixed yet, so please fix the drivers instead.


Bounce buffer would be good for systems
that take U-Boot as UEFI firmware, because U-Boot would be located at
high end, but in the middle just top of 4GB.


The bounce buffer is a necessity for IPs which cannot address more than the 4 
GiB of memory. In fact, it would be even better to handle DT dma-ranges, but 
that is the next step.


I not object this patch, but it also be good if bounce buffer be added
for improvement.

Reviewed-by: Peng Fan 


I do object to this, since it increases the proliferation of this broken 
board_get_usable_ram_top() workaround instead of fixing the drivers properly.


I generally agree with Marek's objections and if anyone comes up with a proper 
fix this will be highly appreciated. For now I just dropped this patch from my 
v2 patchset, but Stefano has already pulled it into u-boot-imx. I guess it's up 
to him to decide if this intermediate fix should be merged or not.


Fix the drivers, that is the only way unless you want to see U-Boot turn 
into pile of hacks and workarounds which become unmanageable.

Re: zynqmpbif - sample




On 7/13/21 11:25 AM, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
>> On 13/07/21, Michal Simek wrote:
>>> Hi,
>>>
>>> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
 hi Michal,

 Would you have some sample/reference code to generate a SPL boot image
 using zynqmpbif instead of zynqmpimage? I cant find any documentation
 and I see no option to enable it (I was expecting to find some config
 in Makefile.spl but I see none).

 What is the expected way of building these images?
>>>
>>> Alex implemented it for Xilinx bif format after origin zynqmpimage
>>> format. But usage is just like this.
>>>
>>> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif
>>> /tmp/boot.bin
>>> Image Type   : Xilinx ZynqMP Boot Image support
>>> Image Offset : 0x09c0
>>> Image Size   : 147216 bytes (147216 bytes packed)
>>> PMUFW Size   : 129792 bytes (129792 bytes packed)
>>> Image Load   : 0xfffc
>>> Checksum : 0xfd15d661
>>> [u-boot](debian-sent)$ cat /tmp/bif
>>> image : {
>>> [pmufw_image, load=0xffdc] /mnt/disk/u-boot-bins/zynqmp/pmu.elf
>>> [destination_cpu=a53-0, load=0xfffc, bootloader] spl/u-boot-spl.bin
>>> }
>>
>> awesome, exactly what I needed to start with.
> 
> So I can boot using the steps you mentioned above.
> 
> But shouldnt the same bif work with bootgen?
> 
> ** Xilinx Bootgen v2019.2
>    Build date : Oct 23 2019-22:59:42
> ** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.
> 
> [TRACE]  : Command Line parsing started
> [TRACE]  : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace
> [INFO]   : Command line parsing completed successfully
> [TRACE]  : BIF File: ./bif
> [TRACE]  : BIF file parsing started
> [TRACE]  : Setting PMU FW Image file as pmu.elf
> [INFO]   : BIF file parsing completed successfully
> [INFO]   : Parsing Partition Data to Image
> [INFO]   : Building image - image
> [INFO]   : Building the Partition Header Table
> [INFO]   : After build
>-- Dump of Binary Image 
> Len: 08b8 Res:  "BootHeader"
> Len: 0040 Res:  "ImageHeaderTable"
> Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
> Len: 0040 Res:  "PartitionHeader 
> u-boot-spl.bin.0"
> Len: 0040 Res: 16c0 "PartitionHeader Null"
> Len: 00020574 Res:  "u-boot-spl.bin.0"
>-- End of Dump
> [INFO]   : After align
>-- Dump of Binary Image 
> Len: 08b8 Res:  "BootHeader"
>08c0 Len: 0040 Res:  "ImageHeaderTable"
>0900 Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
>1100 Len: 0040 Res:  "PartitionHeader 
> u-boot-spl.bin.0"
>1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
>2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
>-- End of Dump
> [INFO]   : Partition Information:
> [INFO]   : Image: u-boot-spl.bin
> [INFO]   :Partition 0: u-boot-spl.bin.0,  Size: 132467
> [INFO]   : After Link
>-- Dump of Binary Image 
> Len: 08b8 Res:  "BootHeader"
>08c0 Len: 0040 Res:  "ImageHeaderTable"
>0900 Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
>1100 Len: 0040 Res:  "PartitionHeader 
> u-boot-spl.bin.0"
>1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
>2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
>-- End of Dump
> 
> 
> however when I boot and inspect the processor state, xsdb returns "APU
> L2 cache is held in reset"
> 
> Since the functionality to support RSA authentication is missing from
> mkimage (I'll have to add that), I would first like to see it
> functional with SPL using bootgen.
> 
> However the same bif doesnt even boot - is this to be expected?
> 
> also the layouts generated from the bif using mkimage and bootgen are
> completely different (it seems that naively I expected them to be the
> same); is there any information on the different layouts used for the
> bootrom? 


I tested it and it works fine for me. Take a look at the code what
exactly is

[u-boot]$ cat /tmp/bif
image : {
[pmufw_image] /mnt/disk/u-boot-bins/zynqmp/pmu.bin
[destination_cpu=a53-0, load=0xfffc, bootloader]
spl/u-boot-spl-align.bin
}

Didn't try the latest bootgen but format is changing over years but none
is updating this tool. Feel free to take a look at it.

Thanks,
Michal

Re: [PATCH 4/6] imx8m: Restrict usable memory to space below 4G boundary

On 15.06.21 02:41, Marek Vasut wrote:
> On 6/15/21 2:28 AM, Peng Fan (OSS) wrote:
>>
>>
>> On 2021/6/7 20:38, Marek Vasut wrote:
>>> On 6/7/21 2:05 PM, Frieder Schrempf wrote:
 From: Frieder Schrempf 

 Some IPs have their accessible address space restricted by the
 interconnect. Let's make sure U-Boot only ever uses the space below
 the 4G address boundary (which is 3GiB big), even when the effective
 available memory is bigger.

 We implement board_get_usable_ram_top() for all i.MX8M SoCs, as the
 whole family is affected by this.
>>>
>>> Shouldn't only those specific IP drivers handle buffers in the 64bit space 
>>> somehow ? E.g. using a bounce buffer ?
>>
>> That could cause extra mem copy.
> 
> If you want to avoid the extra memcopy, then make sure the buffers are not 
> allocated above 4 GiB boundary. Then the bounce buffer does no copy.
> 
> This board_get_usable_ram_top() is just a temporary workaround for platforms 
> with broken drivers which are not fixed yet, so please fix the drivers 
> instead.
> 
>> Bounce buffer would be good for systems
>> that take U-Boot as UEFI firmware, because U-Boot would be located at
>> high end, but in the middle just top of 4GB.
> 
> The bounce buffer is a necessity for IPs which cannot address more than the 4 
> GiB of memory. In fact, it would be even better to handle DT dma-ranges, but 
> that is the next step.
> 
>> I not object this patch, but it also be good if bounce buffer be added
>> for improvement.
>>
>> Reviewed-by: Peng Fan 
> 
> I do object to this, since it increases the proliferation of this broken 
> board_get_usable_ram_top() workaround instead of fixing the drivers properly.

I generally agree with Marek's objections and if anyone comes up with a proper 
fix this will be highly appreciated. For now I just dropped this patch from my 
v2 patchset, but Stefano has already pulled it into u-boot-imx. I guess it's up 
to him to decide if this intermediate fix should be merged or not.

Re: zynqmpbif - sample

On 13/07/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 13/07/21, Michal Simek wrote:
> > Hi,
> > 
> > On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > > hi Michal,
> > > 
> > > Would you have some sample/reference code to generate a SPL boot image
> > > using zynqmpbif instead of zynqmpimage? I cant find any documentation
> > > and I see no option to enable it (I was expecting to find some config
> > > in Makefile.spl but I see none).
> > > 
> > > What is the expected way of building these images?
> > 
> > Alex implemented it for Xilinx bif format after origin zynqmpimage
> > format. But usage is just like this.
> > 
> > [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif
> > /tmp/boot.bin
> > Image Type   : Xilinx ZynqMP Boot Image support
> > Image Offset : 0x09c0
> > Image Size   : 147216 bytes (147216 bytes packed)
> > PMUFW Size   : 129792 bytes (129792 bytes packed)
> > Image Load   : 0xfffc
> > Checksum : 0xfd15d661
> > [u-boot](debian-sent)$ cat /tmp/bif
> > image : {
> > [pmufw_image, load=0xffdc] /mnt/disk/u-boot-bins/zynqmp/pmu.elf
> > [destination_cpu=a53-0, load=0xfffc, bootloader] spl/u-boot-spl.bin
> > }
> 
> awesome, exactly what I needed to start with.

So I can boot using the steps you mentioned above.

But shouldnt the same bif work with bootgen?

** Xilinx Bootgen v2019.2
   Build date : Oct 23 2019-22:59:42
** Copyright 1986-2019 Xilinx, Inc. All Rights Reserved.

[TRACE]  : Command Line parsing started
[TRACE]  : Command: -arch zynqmp -image ./bif -w -o bootbif.bin -log trace
[INFO]   : Command line parsing completed successfully
[TRACE]  : BIF File: ./bif
[TRACE]  : BIF file parsing started
[TRACE]  : Setting PMU FW Image file as pmu.elf
[INFO]   : BIF file parsing completed successfully
[INFO]   : Parsing Partition Data to Image
[INFO]   : Building image - image
[INFO]   : Building the Partition Header Table
[INFO]   : After build
   -- Dump of Binary Image 
    Len: 08b8 Res:  "BootHeader"
    Len: 0040 Res:  "ImageHeaderTable"
    Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
    Len: 0040 Res:  "PartitionHeader 
u-boot-spl.bin.0"
    Len: 0040 Res: 16c0 "PartitionHeader Null"
    Len: 00020574 Res:  "u-boot-spl.bin.0"
   -- End of Dump
[INFO]   : After align
   -- Dump of Binary Image 
    Len: 08b8 Res:  "BootHeader"
   08c0 Len: 0040 Res:  "ImageHeaderTable"
   0900 Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
   1100 Len: 0040 Res:  "PartitionHeader 
u-boot-spl.bin.0"
   1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
   2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
   -- End of Dump
[INFO]   : Partition Information:
[INFO]   : Image: u-boot-spl.bin
[INFO]   :Partition 0: u-boot-spl.bin.0,  Size: 132467
[INFO]   : After Link
   -- Dump of Binary Image 
    Len: 08b8 Res:  "BootHeader"
   08c0 Len: 0040 Res:  "ImageHeaderTable"
   0900 Len: 0024 Res: 0800 "ImageHeader u-boot-spl.bin"
   1100 Len: 0040 Res:  "PartitionHeader 
u-boot-spl.bin.0"
   1140 Len: 0040 Res: 16c0 "PartitionHeader Null"
   2800 Len: 00020574 Res:  "u-boot-spl.bin.0"
   -- End of Dump


however when I boot and inspect the processor state, xsdb returns "APU
L2 cache is held in reset"

Since the functionality to support RSA authentication is missing from
mkimage (I'll have to add that), I would first like to see it
functional with SPL using bootgen.

However the same bif doesnt even boot - is this to be expected?

also the layouts generated from the bif using mkimage and bootgen are
completely different (it seems that naively I expected them to be the
same); is there any information on the different layouts used for the
bootrom? 

thanks
Jorge

> 
> 
> > 
> > Thanks,
> > Michal

[PATCH v2 5/5] imx: imx8mm: Add support for Kontron Electronics SL/BL i.MX8M-Mini boards (N801x)

From: Frieder Schrempf 

The Kontron SoM-Line i.MX8MM (N801x) by Kontron Electronics GmbH is a SoM
module with an i.MX8M-Mini SoC, 1/2/4 GB LPDDR4 RAM, SPI NOR, eMMC and PMIC.

The matching evaluation boards (Board-Line) have 2 Ethernets, USB 2.0, 
HDMI/LVDS,
SD card, CAN, RS485 and much more.

Signed-off-by: Frieder Schrempf 
Reviewed-by: Stefano Babic 
---
Fixes in v2:
  * Fix header includes in spl.c
  * Add MAINTAINERS file
  * Rename board directory
  * Add Stefano's R-b tag
---
 arch/arm/dts/Makefile |2 +
 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts  |  116 ++
 .../dts/imx8mm-kontron-n801x-s-u-boot.dtsi|  237 +++
 arch/arm/dts/imx8mm-kontron-n801x-s.dts   |  387 
 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi|  298 +++
 arch/arm/mach-imx/imx8m/Kconfig   |8 +
 board/kontron/sl-mx8mm/Kconfig|   15 +
 board/kontron/sl-mx8mm/MAINTAINERS|7 +
 board/kontron/sl-mx8mm/Makefile   |9 +
 board/kontron/sl-mx8mm/imximage.cfg   |9 +
 board/kontron/sl-mx8mm/kontron_mx8mm.c|  102 +
 board/kontron/sl-mx8mm/lpddr4_timing.c| 1846 +
 board/kontron/sl-mx8mm/spl.c  |  322 +++
 configs/kontron_mx8mm_defconfig   |  124 ++
 include/configs/kontron_mx8mm.h   |   66 +
 15 files changed, 3548 insertions(+)
 create mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
 create mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mm-kontron-n801x-s.dts
 create mode 100644 arch/arm/dts/imx8mm-kontron-n801x-som.dtsi
 create mode 100644 board/kontron/sl-mx8mm/Kconfig
 create mode 100644 board/kontron/sl-mx8mm/MAINTAINERS
 create mode 100644 board/kontron/sl-mx8mm/Makefile
 create mode 100644 board/kontron/sl-mx8mm/imximage.cfg
 create mode 100644 board/kontron/sl-mx8mm/kontron_mx8mm.c
 create mode 100644 board/kontron/sl-mx8mm/lpddr4_timing.c
 create mode 100644 board/kontron/sl-mx8mm/spl.c
 create mode 100644 configs/kontron_mx8mm_defconfig
 create mode 100644 include/configs/kontron_mx8mm.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8238ba1444..54120b04c1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -864,6 +864,8 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-evk.dtb \
imx8mm-icore-mx8mm-ctouch2.dtb \
imx8mm-icore-mx8mm-edimm2.2.dtb \
+   imx8mm-kontron-n801x-s.dtb \
+   imx8mm-kontron-n801x-s-lvds.dtb \
imx8mm-venice.dtb \
imx8mm-venice-gw71xx-0x.dtb \
imx8mm-venice-gw72xx-0x.dtb \
diff --git a/arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts 
b/arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
new file mode 100644
index 00..dd1addea70
--- /dev/null
+++ b/arch/arm/dts/imx8mm-kontron-n801x-s-lvds.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Kontron Electronics GmbH
+ */
+
+#include "imx8mm-kontron-n801x-s.dts"
+
+/ {
+   model = "Kontron i.MX8MM N801X S LVDS";
+   compatible = "kontron,imx8mm-n801x-s-lvds", "fsl,imx8mm";
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5>; /* period = 500 ns => f = 200 Hz */
+   power-supply = <_vdd_24v>;
+   brightness-levels = <0 100>;
+   num-interpolated-steps = <100>;
+   default-brightness-level = <100>;
+   status = "okay";
+   };
+
+   reg_panel_pwr: regpanel-pwr {
+   compatible = "regulator-fixed";
+   regulator-name = "reg_panel_pwr";
+   regulator-always-on;
+   gpio = < 19 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_panel_rst: regpanel-rst {
+   compatible = "regulator-fixed";
+   regulator-name = "reg_panel_rst";
+   regulator-always-on;
+   gpio = < 20 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_panel_stby: regpanel-stby {
+   compatible = "regulator-fixed";
+   regulator-name = "reg_panel_stby";
+   regulator-always-on;
+   gpio = < 21 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_panel_hinv: regpanel-hinv {
+   compatible = "regulator-fixed";
+   regulator-name = "reg_panel_hinv";
+   regulator-always-on;
+   gpio = < 24 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_panel_vinv: regpanel-vinv {
+   compatible = "regulator-fixed";
+   regulator-name = "reg_panel_vinv";
+   gpio = < 25 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
+
+   reg_vdd_24v: regulator-24v {
+   compatible = "regulator-fixed";
+   regulator-name = "reg-vdd-24v";
+   regulator-min-microvolt

[PATCH v2 4/5] imx: imx6ul: Add support for Kontron Electronics SL/BL i.MX6UL/ULL boards (N63xx/N64xx)

From: Frieder Schrempf 

This adds support for i.MX6UL/ULL-based evaluation kits with SoMs by
Kontron Electronics GmbH.

Currently there are the following SoM flavors (SoM-Line):
  * N6310: SOM with i.MX6UL-2, 256MB RAM, 256MB SPI NAND
  * N6311: SOM with i.MX6UL-2, 512MB RAM, 512MB SPI NAND
  * N6411: SOM with i.MX6ULL, 512MB RAM, 512MB SPI NAND

And the according evaluation boards (Board-Line):
  * N6310-S: Baseboard with SOM N6310, eMMC, display (optional), ...
  * N6311-S: Baseboard with SOM N6311, eMMC, display (optional), ...
  * N6411-S: Baseboard with SOM N6411, eMMC, display (optional), ...

Currently U-Boot describes i.MX6UL and i.MX6ULL through separate config
options at compile-time. Though the differences are so minor, that for
the scope of these SoMs we just use a single defconfig that is compatible
with both SoCs.

Signed-off-by: Frieder Schrempf 
Reviewed-by: Stefano Babic 
---
Fixes in v2:
  * Add MAINTAINERS file
  * Rename board directory
  * Use binman to generate FIT
  * Support legacy images
  * Add Stefano's R-b tag
---
 arch/arm/dts/Makefile |   4 +-
 .../dts/imx6ul-kontron-n631x-s-u-boot.dtsi|   7 +
 arch/arm/dts/imx6ul-kontron-n631x-s.dts   |  17 +
 arch/arm/dts/imx6ul-kontron-n631x-som.dtsi|  14 +
 .../dts/imx6ul-kontron-n6x1x-s-u-boot.dtsi|  94 
 arch/arm/dts/imx6ul-kontron-n6x1x-s.dts   | 423 ++
 arch/arm/dts/imx6ul-kontron-n6x1x-s.dtsi  | 420 +
 .../dts/imx6ul-kontron-n6x1x-som-common.dtsi  | 124 +
 .../dts/imx6ull-kontron-n641x-s-u-boot.dtsi   |   7 +
 arch/arm/dts/imx6ull-kontron-n641x-s.dts  |  16 +
 arch/arm/dts/imx6ull-kontron-n641x-som.dtsi   |  13 +
 arch/arm/mach-imx/mx6/Kconfig |   9 +
 board/kontron/sl-mx6ul/Kconfig|  15 +
 board/kontron/sl-mx6ul/MAINTAINERS|   9 +
 board/kontron/sl-mx6ul/Makefile   |   8 +
 board/kontron/sl-mx6ul/kontron_mx6ul.c|  85 
 board/kontron/sl-mx6ul/spl.c  | 376 
 configs/kontron_mx6ul_defconfig   | 109 +
 include/configs/kontron_common.h  |  86 
 include/configs/kontron_mx6ul.h   |  52 +++
 20 files changed, 1887 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/imx6ul-kontron-n631x-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6ul-kontron-n631x-s.dts
 create mode 100644 arch/arm/dts/imx6ul-kontron-n631x-som.dtsi
 create mode 100644 arch/arm/dts/imx6ul-kontron-n6x1x-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6ul-kontron-n6x1x-s.dts
 create mode 100644 arch/arm/dts/imx6ul-kontron-n6x1x-s.dtsi
 create mode 100644 arch/arm/dts/imx6ul-kontron-n6x1x-som-common.dtsi
 create mode 100644 arch/arm/dts/imx6ull-kontron-n641x-s-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6ull-kontron-n641x-s.dts
 create mode 100644 arch/arm/dts/imx6ull-kontron-n641x-som.dtsi
 create mode 100644 board/kontron/sl-mx6ul/Kconfig
 create mode 100644 board/kontron/sl-mx6ul/MAINTAINERS
 create mode 100644 board/kontron/sl-mx6ul/Makefile
 create mode 100644 board/kontron/sl-mx6ul/kontron_mx6ul.c
 create mode 100644 board/kontron/sl-mx6ul/spl.c
 create mode 100644 configs/kontron_mx6ul_defconfig
 create mode 100644 include/configs/kontron_common.h
 create mode 100644 include/configs/kontron_mx6ul.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7ce3ae6caa..8238ba1444 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -810,7 +810,9 @@ dtb-$(CONFIG_MX6UL) += \
imx6ul-liteboard.dtb \
imx6ul-phytec-segin-ff-rdk-nand.dtb \
imx6ul-pico-hobbit.dtb \
-   imx6ul-pico-pi.dtb
+   imx6ul-pico-pi.dtb \
+   imx6ul-kontron-n631x-s.dtb \
+   imx6ull-kontron-n641x-s.dtb
 
 dtb-$(CONFIG_MX6ULL) += \
imx6ull-14x14-evk.dtb \
diff --git a/arch/arm/dts/imx6ul-kontron-n631x-s-u-boot.dtsi 
b/arch/arm/dts/imx6ul-kontron-n631x-s-u-boot.dtsi
new file mode 100644
index 00..d3f013c58c
--- /dev/null
+++ b/arch/arm/dts/imx6ul-kontron-n631x-s-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ */
+
+#include "imx6ul-kontron-n6x1x-s-u-boot.dtsi"
diff --git a/arch/arm/dts/imx6ul-kontron-n631x-s.dts 
b/arch/arm/dts/imx6ul-kontron-n631x-s.dts
new file mode 100644
index 00..407d2b1dab
--- /dev/null
+++ b/arch/arm/dts/imx6ul-kontron-n631x-s.dts
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski 
+ */
+
+/dts-v1/;
+
+#include "imx6ul-kontron-n631x-som.dtsi"
+#include "imx6ul-kontron-n6x1x-s.dtsi"
+
+/ {
+   model = "Kontron N631X S";
+   compatible = "kontron,imx6ul-n631x-s", "kontron,imx6ul-n631x-som",
+"fsl,imx6ul";
+};
diff --git

[PATCH v2 3/5] clk: imx8mm: Add SPI clocks

From: Frieder Schrempf 

Add the clocks for the ECSPI controllers. This is ported from
Linux v5.13-rc4.

Signed-off-by: Frieder Schrempf 
---
 drivers/clk/imx/clk-imx8mm.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index d32ff8409a..3aa8c641f9 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -131,6 +131,15 @@ static const char *imx8mm_usb_core_sels[] = 
{"clock-osc-24m", "sys_pll1_100m", "
 static const char *imx8mm_usb_phy_sels[] = {"clock-osc-24m", "sys_pll1_100m", 
"sys_pll1_40m", "sys_pll2_100m",
 "sys_pll2_200m", "clk_ext2", 
"clk_ext3", "audio_pll2_out", };
 
+static const char *imx8mm_ecspi1_sels[] = {"clock-osc-24m", "sys_pll2_200m", 
"sys_pll1_40m", "sys_pll1_160m",
+  "sys_pll1_800m", "sys_pll3_out", 
"sys_pll2_250m", "audio_pll2_out", };
+
+static const char *imx8mm_ecspi2_sels[] = {"clock-osc-24m", "sys_pll2_200m", 
"sys_pll1_40m", "sys_pll1_160m",
+  "sys_pll1_800m", "sys_pll3_out", 
"sys_pll2_250m", "audio_pll2_out", };
+
+static const char *imx8mm_ecspi3_sels[] = {"clock-osc-24m", "sys_pll2_200m", 
"sys_pll1_40m", "sys_pll1_160m",
+  "sys_pll1_800m", "sys_pll3_out", 
"sys_pll2_250m", "audio_pll2_out", };
+
 static ulong imx8mm_clk_get_rate(struct clk *clk)
 {
struct clk *c;
@@ -393,7 +402,19 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_core_ref", imx8mm_usb_core_sels, base 
+ 0xb100));
clk_dm(IMX8MM_CLK_USB_PHY_REF,
imx8m_clk_composite("usb_phy_ref", imx8mm_usb_phy_sels, base + 
0xb180));
-
+   clk_dm(IMX8MM_CLK_ECSPI1,
+  imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base + 
0xb280));
+   clk_dm(IMX8MM_CLK_ECSPI2,
+  imx8m_clk_composite("ecspi2", imx8mm_ecspi2_sels, base + 
0xb300));
+   clk_dm(IMX8MM_CLK_ECSPI3,
+  imx8m_clk_composite("ecspi3", imx8mm_ecspi3_sels, base + 
0xc180));
+
+   clk_dm(IMX8MM_CLK_ECSPI1_ROOT,
+  imx_clk_gate4("ecspi1_root_clk", "ecspi1", base + 0x4070, 0));
+   clk_dm(IMX8MM_CLK_ECSPI2_ROOT,
+  imx_clk_gate4("ecspi2_root_clk", "ecspi2", base + 0x4080, 0));
+   clk_dm(IMX8MM_CLK_ECSPI3_ROOT,
+  imx_clk_gate4("ecspi3_root_clk", "ecspi3", base + 0x4090, 0));
clk_dm(IMX8MM_CLK_I2C1_ROOT,
   imx_clk_gate4("i2c1_root_clk", "i2c1", base + 0x4170, 0));
clk_dm(IMX8MM_CLK_I2C2_ROOT,
-- 
2.25.1

[PATCH v2 2/5] spi: fsl_qspi: Build driver only if DM_SPI is available

From: Frieder Schrempf 

The driver depends on DM_SPI and if it's not available (e. g. in SPL),
then we should not try to build it as this will fail.

Signed-off-by: Frieder Schrempf 
---
 drivers/spi/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index f70851e4bc..216e72c60f 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SANDBOX) += spi-emul-uclass.o
 obj-$(CONFIG_SOFT_SPI) += soft_spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem.o
 obj-$(CONFIG_TI_QSPI) += ti_qspi.o
+obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
 else
 obj-y += spi.o
 obj-$(CONFIG_SPI_MEM) += spi-mem-nodm.o
@@ -30,7 +31,6 @@ obj-$(CONFIG_DESIGNWARE_SPI) += designware_spi.o
 obj-$(CONFIG_EXYNOS_SPI) += exynos_spi.o
 obj-$(CONFIG_FSL_DSPI) += fsl_dspi.o
 obj-$(CONFIG_FSL_ESPI) += fsl_espi.o
-obj-$(CONFIG_FSL_QSPI) += fsl_qspi.o
 obj-$(CONFIG_SYNQUACER_SPI) += spi-synquacer.o
 obj-$(CONFIG_ICH_SPI) +=  ich.o
 obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
-- 
2.25.1

[PATCH v2 1/5] mtd: spi-nor-ids: Add support for Macronix MX25V8035F and MX25R1635F

From: Frieder Schrempf 

The MX25V8035F is a 8Mb SPI NOR flash and the MX25R1635F is very
similar, but has twice the size (16Mb) and supports a wider supply
voltage range.

They were tested on the Kontron Electronics i.MX6UL and i.MX8MM SoMs.

Signed-off-by: Frieder Schrempf 
---
 drivers/mtd/spi/spi-nor-ids.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 1af1c86486..6f84c54a47 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -160,6 +160,8 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx25l12855e", 0xc22618, 0, 64 * 1024, 256, 0) },
{ INFO("mx25l25635e", 0xc22019, 0, 64 * 1024, 512, SPI_NOR_DUAL_READ | 
SPI_NOR_QUAD_READ) },
{ INFO("mx25u25635f", 0xc22539, 0, 64 * 1024, 512, SECT_4K | 
SPI_NOR_4B_OPCODES) },
+   { INFO("mx25v8035f",  0xc22314, 0, 64 * 1024,  16, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+   { INFO("mx25r1635f",  0xc22815, 0, 64 * 1024,  32, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("mx25l25655e", 0xc22619, 0, 64 * 1024, 512, 0) },
{ INFO("mx66l51235l", 0xc2201a, 0, 64 * 1024, 1024, SPI_NOR_DUAL_READ | 
SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx66u51235f", 0xc2253a, 0, 64 * 1024, 1024, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
-- 
2.25.1

Re: [PATCH] configs: am65x_evm: Switch envboot out for distro_bootcmd




On 02/07/21 1:34 am, Tom Rini wrote:
> Swap out the TI-centric "envboot" logic for the generic distro_bootcmd
> logic for the bootcmd we run before trying to do something more complex
> involving additional firmware, etc.
> 
> Cc: Lokesh Vutla 
> Signed-off-by: Tom Rini 

This is causing build errors for am6 platforms.
https://source.denx.de/u-boot/custodians/u-boot-ti/-/jobs/291139

Thanks and regards,
Lokesh

> ---
>  configs/am65x_evm_a53_defconfig |  2 +-
>  include/configs/am65x_evm.h | 10 --
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
> index 6f9309e17147..eefcdfa36571 100644
> --- a/configs/am65x_evm_a53_defconfig
> +++ b/configs/am65x_evm_a53_defconfig
> @@ -29,7 +29,7 @@ CONFIG_SPL_LOAD_FIT=y
>  CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
>  # CONFIG_USE_SPL_FIT_GENERATOR is not set
>  CONFIG_OF_BOARD_SETUP=y
> -CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run 
> boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
> get_overlay_${boot}; run run_kern"
> +CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run 
> boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run 
> get_overlay_${boot}; run run_kern"
>  CONFIG_LOGLEVEL=7
>  CONFIG_CONSOLE_MUX=y
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
> index 8c50fe9d11ff..749689ca3610 100644
> --- a/include/configs/am65x_evm.h
> +++ b/include/configs/am65x_evm.h
> @@ -10,7 +10,6 @@
>  #define __CONFIG_AM654_EVM_H
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -126,6 +125,12 @@
>   DFU_ALT_INFO_EMMC   \
>   DFU_ALT_INFO_OSPI
>  
> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 1) \
> + func(MMC, mmc, 0)
> +
> +#include 
> +
>  /* Incorporate settings into the U-Boot environment */
>  #define CONFIG_EXTRA_ENV_SETTINGS\
>   DEFAULT_LINUX_BOOT_ENV  \
> @@ -136,7 +141,8 @@
>   EXTRA_ENV_AM65X_BOARD_SETTINGS_MTD  \
>   EXTRA_ENV_AM65X_BOARD_SETTINGS_UBI  \
>   EXTRA_ENV_RPROC_SETTINGS\
> - EXTRA_ENV_DFUARGS
> + EXTRA_ENV_DFUARGS   \
> + BOOTENV
>  
>  #define CONFIG_SYS_USB_FAT_BOOT_PARTITION 1
>  
>

[PATCH 14/14] configs: ast2600: Boot kernel FIT in DRAM

AST2600 leverages the FIT hash/signature verification to fulfill
secure boot trust chain. To improve the performance and save SW
code size for those crypto operations, the two HW crypto engine,
HACE and ARCY, are enabled.

However, both of the engines can only access to data stored in
DRAM space. Therefore, we need to move the FIT image into DRAM
before the booting.

This patch update the CONFIG_BOOTCOMMAND to execute the pre-defined
ENV variable which consists of FIT image copy to memory and booting.

Signed-off-by: Chia-Wei Wang 
---
 configs/evb-ast2600_defconfig | 2 +-
 include/configs/evb_ast2600.h | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 5049217b55..f87487b82f 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -27,7 +27,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x1
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS4,115200n8 root=/dev/ram rw"
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="bootm 2010"
+CONFIG_BOOTCOMMAND="run bootspi"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
 CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h
index d2aceb6663..83002db317 100644
--- a/include/configs/evb_ast2600.h
+++ b/include/configs/evb_ast2600.h
@@ -14,7 +14,14 @@
 #define CONFIG_SYS_LOAD_ADDR   0x8300
 
 /* Misc */
+#define STR_HELPER(s)  #s
+#define STR(s) STR_HELPER(s)
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
+   "loadaddr=" STR(CONFIG_SYS_LOAD_ADDR) "\0" \
+   "bootspi=fdt addr 2010 && fdt header get fitsize totalsize && " \
+   "cp.b 2010 ${loadaddr} ${fitsize} && bootm; " \
+   "echo Error loading kernel FIT image\0" \
"verify=yes\0"  \
"spi_dma=yes\0" \
""
-- 
2.17.1

[PATCH 13/14] configs: aspeed: Make EXTRA_ENV_SETTINGS board specific

Move CONFIG_EXTRA_ENV_SETTINGS to board-specific
configuration headers.

Signed-off-by: Chia-Wei Wang 
---
 include/configs/aspeed-common.h | 9 -
 include/configs/evb_ast2500.h   | 6 ++
 include/configs/evb_ast2600.h   | 6 ++
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/include/configs/aspeed-common.h b/include/configs/aspeed-common.h
index df0f5d2e76..afe690af53 100644
--- a/include/configs/aspeed-common.h
+++ b/include/configs/aspeed-common.h
@@ -43,13 +43,4 @@
  */
 #define CONFIG_BOOTP_BOOTFILESIZE
 
-/*
- * Miscellaneous configurable options
- */
-
-#define CONFIG_EXTRA_ENV_SETTINGS \
-   "verify=yes\0"  \
-   "spi_dma=yes\0" \
-   ""
-
 #endif /* __AST_COMMON_CONFIG_H */
diff --git a/include/configs/evb_ast2500.h b/include/configs/evb_ast2500.h
index 0ff01af833..a886fd941e 100644
--- a/include/configs/evb_ast2500.h
+++ b/include/configs/evb_ast2500.h
@@ -16,4 +16,10 @@
 /* Memory Info */
 #define CONFIG_SYS_LOAD_ADDR   0x8300
 
+/* Misc */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   "verify=yes\0"  \
+   "spi_dma=yes\0" \
+   ""
+
 #endif /* __CONFIG_H */
diff --git a/include/configs/evb_ast2600.h b/include/configs/evb_ast2600.h
index e7975bf66d..d2aceb6663 100644
--- a/include/configs/evb_ast2600.h
+++ b/include/configs/evb_ast2600.h
@@ -13,4 +13,10 @@
 /* Memory Info */
 #define CONFIG_SYS_LOAD_ADDR   0x8300
 
+/* Misc */
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   "verify=yes\0"  \
+   "spi_dma=yes\0" \
+   ""
+
 #endif /* __CONFIG_H */
-- 
2.17.1

[PATCH 09/14] ast2600: spl: Add ARCY probing

Probe ARCY driver in SPL board init if enabled.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/mach-aspeed/ast2600/spl.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/mach-aspeed/ast2600/spl.c 
b/arch/arm/mach-aspeed/ast2600/spl.c
index a0fc420ff1..2172bb4ae7 100644
--- a/arch/arm/mach-aspeed/ast2600/spl.c
+++ b/arch/arm/mach-aspeed/ast2600/spl.c
@@ -49,6 +49,12 @@ void spl_board_init(void)
 );
if (rc)
debug("HACE initialization failure, rc=%d\n", rc);
+
+   rc = uclass_get_device_by_driver(UCLASS_MOD_EXP,
+DM_DRIVER_GET(aspeed_arcy),
+);
+   if (rc)
+   debug("ARCY initialization failure, rc=%d\n", rc);
 }
 #endif
 
-- 
2.17.1

[PATCH 06/14] common: fit: Use hash.c to call CRC/SHA function

Currently the FIT verification calls directly into
SW implemented functions to get a CRC/SHA/MD5 hash.

This patch removes duplcated algorithm lookup and use
hash_lookup_algo to get the hashing function with HW
accelearation supported if configured.

The MD5 direct call remains as it is not included in
the hash lookup table of hash.c.

Signed-off-by: Chia-Wei Wang 
---
 common/image-fit.c | 35 ++-
 1 file changed, 10 insertions(+), 25 deletions(-)

diff --git a/common/image-fit.c b/common/image-fit.c
index 0c5a05948d..e52ff47bc3 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -1196,7 +1196,7 @@ int fit_set_timestamp(void *fit, int noffset, time_t 
timestamp)
  * calculate_hash - calculate and return hash for provided input data
  * @data: pointer to the input data
  * @data_len: data length
- * @algo: requested hash algorithm
+ * @algo_name: requested hash algorithm
  * @value: pointer to the char, will hold hash value data (caller must
  * allocate enough free space)
  * value_len: length of the calculated hash
@@ -1210,37 +1210,22 @@ int fit_set_timestamp(void *fit, int noffset, time_t 
timestamp)
  * 0, on success
  *-1, when algo is unsupported
  */
-int calculate_hash(const void *data, int data_len, const char *algo,
-   uint8_t *value, int *value_len)
+int calculate_hash(const void *data, int data_len, const char *algo_name,
+  uint8_t *value, int *value_len)
 {
-   if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
-   *((uint32_t *)value) = crc32_wd(0, data, data_len,
-   CHUNKSZ_CRC32);
-   *((uint32_t *)value) = cpu_to_uimage(*((uint32_t *)value));
-   *value_len = 4;
-   } else if (IMAGE_ENABLE_SHA1 && strcmp(algo, "sha1") == 0) {
-   sha1_csum_wd((unsigned char *)data, data_len,
-(unsigned char *)value, CHUNKSZ_SHA1);
-   *value_len = 20;
-   } else if (IMAGE_ENABLE_SHA256 && strcmp(algo, "sha256") == 0) {
-   sha256_csum_wd((unsigned char *)data, data_len,
-  (unsigned char *)value, CHUNKSZ_SHA256);
-   *value_len = SHA256_SUM_LEN;
-   } else if (IMAGE_ENABLE_SHA384 && strcmp(algo, "sha384") == 0) {
-   sha384_csum_wd((unsigned char *)data, data_len,
-  (unsigned char *)value, CHUNKSZ_SHA384);
-   *value_len = SHA384_SUM_LEN;
-   } else if (IMAGE_ENABLE_SHA512 && strcmp(algo, "sha512") == 0) {
-   sha512_csum_wd((unsigned char *)data, data_len,
-  (unsigned char *)value, CHUNKSZ_SHA512);
-   *value_len = SHA512_SUM_LEN;
-   } else if (IMAGE_ENABLE_MD5 && strcmp(algo, "md5") == 0) {
+   struct hash_algo *algo;
+
+   if (IMAGE_ENABLE_MD5 && strcmp(algo_name, "md5") == 0) {
md5_wd((unsigned char *)data, data_len, value, CHUNKSZ_MD5);
*value_len = 16;
+   } else if (hash_lookup_algo(algo_name, ) == 0) {
+   algo->hash_func_ws(data, data_len, value, algo->chunk_size);
+   *value_len = algo->digest_size;
} else {
debug("Unsupported hash alogrithm\n");
return -1;
}
+
return 0;
 }
 
-- 
2.17.1

[PATCH 12/14] configs: ast2600-evb: Enable SPL FIT support

Enable SPL FIT image load and verification support.
The HW accelerated SHA is also available with the
newly added support of the HACE HW hash engine.

Signed-off-by: Chia-Wei Wang 
---
 configs/evb-ast2600_defconfig | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index f24425997d..5049217b55 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_SYS_DCACHE_OFF=y
 CONFIG_ARCH_ASPEED=y
-CONFIG_SYS_TEXT_BASE=0x1
+CONFIG_SYS_TEXT_BASE=0x8000
 CONFIG_ASPEED_AST2600=y
 CONFIG_TARGET_EVB_AST2600=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
@@ -11,12 +11,19 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_SIZE=0x1
 CONFIG_DEFAULT_DEVICE_TREE="ast2600-evb"
 CONFIG_SPL_SERIAL_SUPPORT=y
+CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
+CONFIG_SPL_STACK_R_ADDR=0x8300
 CONFIG_SPL_SIZE_LIMIT=0x1
 CONFIG_SPL=y
 # CONFIG_ARMV7_NONSEC is not set
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_FIT=y
-# CONFIG_LEGACY_IMAGE_FORMAT is not set
+CONFIG_FIT_ENABLE_SHA384_SUPPORT=y
+CONFIG_FIT_ENABLE_SHA512_SUPPORT=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x1
+# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS4,115200n8 root=/dev/ram rw"
 CONFIG_USE_BOOTCOMMAND=y
@@ -24,8 +31,15 @@ CONFIG_BOOTCOMMAND="bootm 2010"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
 CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
-# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
+CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x200
+CONFIG_SPL_SHA1_SUPPORT=y
+CONFIG_SPL_SHA256_SUPPORT=y
+CONFIG_SPL_SHA384_SUPPORT=y
+CONFIG_SPL_SHA512_SUPPORT=y
+CONFIG_SPL_FIT_IMAGE_TINY=y
 CONFIG_SPL_DM_RESET=y
 CONFIG_SPL_RAM_SUPPORT=y
 CONFIG_SPL_RAM_DEVICE=y
@@ -45,6 +59,8 @@ CONFIG_REGMAP=y
 CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_CLK=y
 CONFIG_SPL_CLK=y
+CONFIG_ASPEED_HACE=y
+CONFIG_ASPEED_ARCY=y
 CONFIG_DM_I2C=y
 CONFIG_MISC=y
 CONFIG_SPL_MISC=y
@@ -63,6 +79,8 @@ CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
 CONFIG_SPL_SYSRESET=y
 CONFIG_WDT=y
+CONFIG_SHA512_HW_ACCEL=y
 CONFIG_HEXDUMP=y
 # CONFIG_SPL_HEXDUMP is not set
 # CONFIG_EFI_LOADER is not set
+CONFIG_PHANDLE_CHECK_SEQ=y
-- 
2.17.1

[PATCH 10/14] ARM: dts: ast2600: Add ARCY to device tree

Add ARCY DTS node and enable it for AST2600 EVB.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/dts/ast2600-evb.dts | 5 +
 arch/arm/dts/ast2600.dtsi| 9 +
 2 files changed, 14 insertions(+)

diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts
index adb80a30ef..fd4e35e954 100644
--- a/arch/arm/dts/ast2600-evb.dts
+++ b/arch/arm/dts/ast2600-evb.dts
@@ -182,3 +182,8 @@
u-boot,dm-pre-reloc;
status = "okay";
 };
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index 642206fb77..216156bfbb 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -195,6 +195,15 @@
status = "disabled";
};
 
+   arcy: arcy@1e6fa000 {
+   compatible = "aspeed,ast2600-arcy";
+   reg = <0x1e6fa000 0x1000>,
+ <0x1e71 0x1>;
+   interrupts = ;
+   clocks = < ASPEED_CLK_GATE_RSACLK>;
+   status = "disabled";
+   };
+
edac: sdram@1e6e {
compatible = "aspeed,ast2600-sdram-edac";
reg = <0x1e6e 0x174>;
-- 
2.17.1

[PATCH 11/14] ast2600: spl: Locate load buffer in DRAM space

Return CONFIG_SYS_LOAD_ADDR pointing to DRAM space for
spl_get_load_buffer() to allow generic SPL image loading
code (e.g. FIT and Ymodem) to store data in DRAM.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/mach-aspeed/ast2600/spl.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/arch/arm/mach-aspeed/ast2600/spl.c 
b/arch/arm/mach-aspeed/ast2600/spl.c
index 2172bb4ae7..42ef24316e 100644
--- a/arch/arm/mach-aspeed/ast2600/spl.c
+++ b/arch/arm/mach-aspeed/ast2600/spl.c
@@ -28,14 +28,7 @@ u32 spl_boot_device(void)
 
 struct image_header *spl_get_load_buffer(ssize_t offset, size_t size)
 {
-   /*
-* When boot from SPI, AST2600 already remap 0x ~ 0x0fff
-* to BMC SPI memory space 0x2000 ~ 0x2fff. The next stage BL
-* has been located in SPI for XIP. In this case, the load buffer for
-* SPL image loading will be set to the remapped address of the next
-* BL instead of the DRAM space CONFIG_SYS_LOAD_ADDR
-*/
-   return (struct image_header *)(CONFIG_SYS_TEXT_BASE);
+   return (struct image_header *)(CONFIG_SYS_LOAD_ADDR);
 }
 
 #ifdef CONFIG_SPL_BOARD_INIT
-- 
2.17.1

[PATCH 04/14] ast2600: spl: Add HACE probing

Probe HACE driver in SPL board init if enabled.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/mach-aspeed/ast2600/spl.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/mach-aspeed/ast2600/spl.c 
b/arch/arm/mach-aspeed/ast2600/spl.c
index 0d8cb29678..a0fc420ff1 100644
--- a/arch/arm/mach-aspeed/ast2600/spl.c
+++ b/arch/arm/mach-aspeed/ast2600/spl.c
@@ -38,6 +38,20 @@ struct image_header *spl_get_load_buffer(ssize_t offset, 
size_t size)
return (struct image_header *)(CONFIG_SYS_TEXT_BASE);
 }
 
+#ifdef CONFIG_SPL_BOARD_INIT
+void spl_board_init(void)
+{
+   int rc;
+   struct udevice *dev;
+
+   rc = uclass_get_device_by_driver(UCLASS_MISC,
+DM_DRIVER_GET(aspeed_hace),
+);
+   if (rc)
+   debug("HACE initialization failure, rc=%d\n", rc);
+}
+#endif
+
 #ifdef CONFIG_SPL_OS_BOOT
 int spl_start_uboot(void)
 {
-- 
2.17.1

[PATCH 08/14] crypto: aspeed: Add AST2600 ARCY support

ARCY is deisnged to accerlerate ECC/RSA digital signature
generation and verification.

Signed-off-by: Chia-Wei Wang 
---
 drivers/crypto/aspeed/Kconfig   |  10 ++
 drivers/crypto/aspeed/Makefile  |   1 +
 drivers/crypto/aspeed/aspeed_arcy.c | 182 
 lib/rsa/Kconfig |  10 +-
 4 files changed, 202 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/aspeed/aspeed_arcy.c

diff --git a/drivers/crypto/aspeed/Kconfig b/drivers/crypto/aspeed/Kconfig
index 299efc223f..9d896afa8a 100644
--- a/drivers/crypto/aspeed/Kconfig
+++ b/drivers/crypto/aspeed/Kconfig
@@ -10,3 +10,13 @@ config ASPEED_HACE
 
 Enabling this allows the use of SHA operations in hardware without 
requiring the
 SHA software implementations. It also improves performance and saves 
code size.
+
+config ASPEED_ARCY
+   bool "ASPEED RSA and ECC Engine"
+   depends on ASPEED_AST2600
+   help
+Select this option to enable a driver for using the RSA/ECC engine in
+the ASPEED BMC SoCs.
+
+Enabling this allows the use of RSA/ECC operations in hardware without 
requiring the
+software implementations. It also improves performance and saves code 
size.
diff --git a/drivers/crypto/aspeed/Makefile b/drivers/crypto/aspeed/Makefile
index 84e6bfe82a..8de95eef7e 100644
--- a/drivers/crypto/aspeed/Makefile
+++ b/drivers/crypto/aspeed/Makefile
@@ -1 +1,2 @@
 obj-$(CONFIG_ASPEED_HACE) += aspeed_hace.o
+obj-$(CONFIG_ASPEED_ARCY) += aspeed_arcy.o
diff --git a/drivers/crypto/aspeed/aspeed_arcy.c 
b/drivers/crypto/aspeed/aspeed_arcy.c
new file mode 100644
index 00..d3da869f83
--- /dev/null
+++ b/drivers/crypto/aspeed/aspeed_arcy.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2021 ASPEED Technology Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ARCY register offsets */
+#define ARCY_CTRL1 0x00
+#define   ARCY_CTRL1_RSA_DMA   BIT(1)
+#define   ARCY_CTRL1_RSA_START BIT(0)
+#define ARCY_CTRL2 0x44
+#define ARCY_CTRL3 0x48
+#define   ARCY_CTRL3_SRAM_AHB_ACCESS   BIT(8)
+#define   ARCY_CTRL3_ECC_RSA_MODE_MASK GENMASK(5, 4)
+#define   ARCY_CTRL3_ECC_RSA_MODE_SHIFT4
+#define ARCY_DMA_DRAM_SADDR0x4c
+#define ARCY_DMA_DMEM_TADDR0x50
+#define   ARCY_DMA_DMEM_TADDR_LEN_MASK GENMASK(15, 0)
+#define   ARCY_DMA_DMEM_TADDR_LEN_SHIFT0
+#define ARCY_RSA_PARAM 0x58
+#define   ARCY_RSA_PARAM_EXP_MASK  GENMASK(31, 16)
+#define   ARCY_RSA_PARAM_EXP_SHIFT 16
+#define   ARCY_RSA_PARAM_MOD_MASK  GENMASK(15, 0)
+#define   ARCY_RSA_PARAM_MOD_SHIFT 0
+#define ARCY_RSA_INT_EN0x3f8
+#define   ARCY_RSA_INT_EN_RSA_READYBIT(2)
+#define   ARCY_RSA_INT_EN_RSA_CMPLTBIT(1)
+#define ARCY_RSA_INT_STS   0x3fc
+#define   ARCY_RSA_INT_STS_RSA_READY   BIT(2)
+#define   ARCY_RSA_INT_STS_RSA_CMPLT   BIT(1)
+
+/* misc. constant */
+#define ARCY_ECC_MODE  2
+#define ARCY_RSA_MODE  3
+#define ARCY_CTX_BUFSZ 0x600
+
+struct aspeed_arcy {
+   phys_addr_t base;
+   phys_addr_t sram_base; /* internal sram */
+   struct clk clk;
+};
+
+static int aspeed_arcy_mod_exp(struct udevice *dev, const uint8_t *sig, 
uint32_t sig_len,
+  struct key_prop *prop, uint8_t *out)
+{
+   int i, j;
+   u8 *ctx;
+   u8 *ptr;
+   u32 reg;
+   struct aspeed_arcy *arcy = dev_get_priv(dev);
+
+   ctx = memalign(16, ARCY_CTX_BUFSZ);
+   if (!ctx)
+   return -ENOMEM;
+
+   memset(ctx, 0, ARCY_CTX_BUFSZ);
+
+   ptr = (u8 *)prop->public_exponent;
+   for (i = prop->exp_len - 1, j = 0; i >= 0; --i) {
+   ctx[j] = ptr[i];
+   j++;
+   j = (j % 16) ? j : j + 32;
+   }
+
+   ptr = (u8 *)prop->modulus;
+   for (i = (prop->num_bits >> 3) - 1, j = 0; i >= 0; --i) {
+   ctx[j + 16] = ptr[i];
+   j++;
+   j = (j % 16) ? j : j + 32;
+   }
+
+   ptr = (u8 *)sig;
+   for (i = sig_len - 1, j = 0; i >= 0; --i) {
+   ctx[j + 32] = ptr[i];
+   j++;
+   j = (j % 16) ? j : j + 32;
+   }
+
+   writel((u32)ctx, arcy->base + ARCY_DMA_DRAM_SADDR);
+
+   reg = (((prop->exp_len << 3) << ARCY_RSA_PARAM_EXP_SHIFT) & 
ARCY_RSA_PARAM_EXP_MASK) |
+ ((prop->num_bits << ARCY_RSA_PARAM_MOD_SHIFT) & 
ARCY_RSA_PARAM_MOD_MASK);
+   writel(reg, arcy->base + ARCY_RSA_PARAM);
+
+   reg = (ARCY_CTX_BUFSZ << ARCY_DMA_DMEM_TADDR_LEN_SHIFT) & 
ARCY_DMA_DMEM_TADDR_LEN_MASK;
+   writel(reg, arcy->base + ARCY_DMA_DMEM_TADDR);
+
+   reg = (ARCY_RSA_MODE << ARCY_CTRL3_ECC_RSA_MODE_SHIFT) & 
ARCY_CTRL3_ECC_RSA_MODE_MASK;
+   writel(reg, arcy->base + ARCY_CTRL3);
+
+   writel(ARCY_CTRL1_RSA_DMA | ARCY_CTRL1_RSA_START, arcy->base + 
ARCY_CTRL1);
+
+

[PATCH 07/14] clk: ast2600: Add RSACLK control for ARCY

Add RSACLK enable for ARCY, the HW RSA/ECC crypto engine
of ASPEED AST26xx SoCs.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/include/asm/arch-aspeed/scu_ast2600.h |  1 +
 drivers/clk/aspeed/clk_ast2600.c   | 15 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h 
b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
index d7b500f656..27f4e9f994 100644
--- a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
+++ b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
@@ -8,6 +8,7 @@
 #define SCU_UNLOCK_KEY 0x1688a8a8
 
 #define SCU_CLKGATE1_EMMC  BIT(27)
+#define SCU_CLKGATE1_ARCY  BIT(24)
 #define SCU_CLKGATE1_MAC2  BIT(21)
 #define SCU_CLKGATE1_MAC1  BIT(20)
 #define SCU_CLKGATE1_USB_HUB   BIT(14)
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index 69128fd3c4..bf3379fce2 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1030,6 +1030,18 @@ static ulong ast2600_enable_haceclk(struct ast2600_scu 
*scu)
return 0;
 }
 
+static ulong ast2600_enable_rsaclk(struct ast2600_scu *scu)
+{
+   uint32_t clkgate_bit;
+
+   clkgate_bit = SCU_CLKGATE1_ARCY;
+
+   writel(clkgate_bit, >clkgate_clr1);
+   mdelay(20);
+
+   return 0;
+}
+
 static int ast2600_clk_enable(struct clk *clk)
 {
struct ast2600_clk_priv *priv = dev_get_priv(clk->dev);
@@ -1071,6 +1083,9 @@ static int ast2600_clk_enable(struct clk *clk)
case ASPEED_CLK_GATE_YCLK:
ast2600_enable_haceclk(priv->scu);
break;
+   case ASPEED_CLK_GATE_RSACLK:
+   ast2600_enable_rsaclk(priv->scu);
+   break;
default:
pr_err("can't enable clk\n");
return -ENOENT;
-- 
2.17.1

[PATCH 02/14] clk: ast2600: Add YCLK control for HACE

Add YCLK enable for HACE, the HW hash engine of
ASPEED AST2600 SoCs.

Signed-off-by: Chia-Wei Wang 
---
 .../arm/include/asm/arch-aspeed/scu_ast2600.h |  5 +++--
 drivers/clk/aspeed/clk_ast2600.c  | 20 +++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h 
b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
index a205fb1f76..d7b500f656 100644
--- a/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
+++ b/arch/arm/include/asm/arch-aspeed/scu_ast2600.h
@@ -10,8 +10,9 @@
 #define SCU_CLKGATE1_EMMC  BIT(27)
 #define SCU_CLKGATE1_MAC2  BIT(21)
 #define SCU_CLKGATE1_MAC1  BIT(20)
-#define SCU_CLKGATE1_USB_HUB   BIT(14)
-#define SCU_CLKGATE1_USB_HOST2 BIT(7)
+#define SCU_CLKGATE1_USB_HUB   BIT(14)
+#define SCU_CLKGATE1_HACE  BIT(13)
+#define SCU_CLKGATE1_USB_HOST2 BIT(7)
 
 #define SCU_CLKGATE2_FSI   BIT(30)
 #define SCU_CLKGATE2_MAC4  BIT(21)
diff --git a/drivers/clk/aspeed/clk_ast2600.c b/drivers/clk/aspeed/clk_ast2600.c
index 3a92739f5c..69128fd3c4 100644
--- a/drivers/clk/aspeed/clk_ast2600.c
+++ b/drivers/clk/aspeed/clk_ast2600.c
@@ -1013,6 +1013,23 @@ static ulong ast2600_enable_usbbhclk(struct ast2600_scu 
*scu)
return 0;
 }
 
+static ulong ast2600_enable_haceclk(struct ast2600_scu *scu)
+{
+   uint32_t reset_bit;
+   uint32_t clkgate_bit;
+
+   reset_bit = BIT(ASPEED_RESET_HACE);
+   clkgate_bit = SCU_CLKGATE1_HACE;
+
+   writel(reset_bit, >modrst_ctrl1);
+   udelay(100);
+   writel(clkgate_bit, >clkgate_clr1);
+   mdelay(20);
+   writel(reset_bit, >modrst_clr1);
+
+   return 0;
+}
+
 static int ast2600_clk_enable(struct clk *clk)
 {
struct ast2600_clk_priv *priv = dev_get_priv(clk->dev);
@@ -1051,6 +1068,9 @@ static int ast2600_clk_enable(struct clk *clk)
case ASPEED_CLK_GATE_USBPORT2CLK:
ast2600_enable_usbbhclk(priv->scu);
break;
+   case ASPEED_CLK_GATE_YCLK:
+   ast2600_enable_haceclk(priv->scu);
+   break;
default:
pr_err("can't enable clk\n");
return -ENOENT;
-- 
2.17.1

[PATCH 03/14] crypto: aspeed: Add AST2600 HACE support

Hash and Crypto Engine (HACE) is designed to accelerate the
throughput of hash data digest, and symmetric-key encryption.

Signed-off-by: Chia-Wei Wang 
---
 drivers/crypto/Kconfig  |   2 +
 drivers/crypto/Makefile |   1 +
 drivers/crypto/aspeed/Kconfig   |  12 ++
 drivers/crypto/aspeed/Makefile  |   1 +
 drivers/crypto/aspeed/aspeed_hace.c | 288 
 5 files changed, 304 insertions(+)
 create mode 100644 drivers/crypto/aspeed/Kconfig
 create mode 100644 drivers/crypto/aspeed/Makefile
 create mode 100644 drivers/crypto/aspeed/aspeed_hace.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 1ea116be75..422d01403e 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -2,4 +2,6 @@ menu "Hardware crypto devices"
 
 source drivers/crypto/fsl/Kconfig
 
+source drivers/crypto/aspeed/Kconfig
+
 endmenu
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index efbd1d3fca..0442067e5e 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,3 +6,4 @@
 obj-$(CONFIG_EXYNOS_ACE_SHA)   += ace_sha.o
 obj-y += rsa_mod_exp/
 obj-y += fsl/
+obj-y += aspeed/
diff --git a/drivers/crypto/aspeed/Kconfig b/drivers/crypto/aspeed/Kconfig
new file mode 100644
index 00..299efc223f
--- /dev/null
+++ b/drivers/crypto/aspeed/Kconfig
@@ -0,0 +1,12 @@
+config ASPEED_HACE
+   bool "ASPEED Hash and Crypto Engine"
+   depends on ASPEED_AST2600
+   imply SHA_HW_ACCEL
+   imply SHA_PROG_HW_ACCEL
+   imply CMD_HASH
+   help
+Select this option to enable a driver for using the SHA engine in
+the ASPEED BMC SoCs.
+
+Enabling this allows the use of SHA operations in hardware without 
requiring the
+SHA software implementations. It also improves performance and saves 
code size.
diff --git a/drivers/crypto/aspeed/Makefile b/drivers/crypto/aspeed/Makefile
new file mode 100644
index 00..84e6bfe82a
--- /dev/null
+++ b/drivers/crypto/aspeed/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_ASPEED_HACE) += aspeed_hace.o
diff --git a/drivers/crypto/aspeed/aspeed_hace.c 
b/drivers/crypto/aspeed/aspeed_hace.c
new file mode 100644
index 00..34e68c07f4
--- /dev/null
+++ b/drivers/crypto/aspeed/aspeed_hace.c
@@ -0,0 +1,288 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2021 IBM Corp.
+ * Copyright 2021 ASPEED Technology Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register offsets*/
+#define HACE_STS   0x1C
+#define   HACE_HASH_INTBIT(9)
+#define   HACE_HASH_BUSY   BIT(0)
+#define HACE_HASH_DATA 0x20
+#define HACE_HASH_DIGEST   0x24
+#define HACE_HASH_HMAC_KEY 0x28
+#define HACE_HASH_DATA_LEN 0x2C
+#define   HACE_SG_LAST BIT(31)
+#define HACE_HASH_CMD  0x30
+#define   HACE_SG_EN   BIT(18)
+#define   HACE_ALGO_SHA384 (BIT(10) | BIT(6) | BIT(5))
+#define   HACE_ALGO_SHA512 (BIT(6) | BIT(5))
+#define   HACE_ALGO_SHA256 (BIT(6) | BIT(4))
+#define   HACE_ALGO_SHA224 BIT(6)
+#define   HACE_ALGO_SHA1   BIT(5)
+#define   HACE_SHA_BE_EN   BIT(3)
+#define   HACE_MD5_LE_EN   BIT(2)
+
+#define HACE_MAX_SG32
+
+struct aspeed_sg {
+   u32 len;
+   u32 addr;
+};
+
+struct aspeed_hash_ctx {
+   u32 method;
+   u32 digest_size;
+   u32 len;
+   u32 count;
+   struct aspeed_sg list[HACE_MAX_SG]; /* Must be 8 byte aligned */
+};
+
+struct aspeed_hace {
+   phys_addr_t base;
+   struct clk clk;
+};
+
+static phys_addr_t aspeed_hace_get_base(void)
+{
+   int rc;
+   struct udevice *dev;
+   struct aspeed_hace *hace;
+
+   rc = uclass_get_device_by_driver(UCLASS_MISC,
+DM_DRIVER_GET(aspeed_hace),
+);
+   if (rc) {
+   printf("Cannot get HACE device, rc=%d\n", rc);
+   return 0;
+   }
+
+   hace = dev_get_priv(dev);
+
+   return hace->base;
+}
+
+static int aspeed_hace_wait_completion(u32 reg, u32 flag, int timeout_us)
+{
+   u32 val;
+
+   return readl_poll_timeout(reg, val, (val & flag) == flag, timeout_us);
+}
+
+static int digest_object(const void *data, unsigned int length, void *digest,
+u32 method)
+{
+   phys_addr_t base = aspeed_hace_get_base();
+
+   if (!((u32)data & BIT(31))) {
+   debug("HACE src out of bounds: can only copy from SDRAM\n");
+   return -EINVAL;
+   }
+
+   if (!((u32)digest & BIT(31))) {
+   debug("HACE dst out of bounds: can only copy to SDRAM\n");
+   return -EINVAL;
+   }
+
+   if ((u32)digest & 0x7) {
+   debug("HACE dst alignment incorrect: %p\n", digest);
+   return -EINVAL;
+   }
+
+   if (readl(base + HACE_STS) &

[PATCH 05/14] ARM: dts: ast2600: Add HACE to device tree

Add HACE DTS node and enable it for AST2600 EVB.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/dts/ast2600-evb.dts | 5 +
 arch/arm/dts/ast2600.dtsi| 8 
 2 files changed, 13 insertions(+)

diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts
index 2abd31341c..adb80a30ef 100644
--- a/arch/arm/dts/ast2600-evb.dts
+++ b/arch/arm/dts/ast2600-evb.dts
@@ -177,3 +177,8 @@
  0x08 0x04
  0x08 0x04>;
 };
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+};
diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index ac0f08b7ea..642206fb77 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -187,6 +187,14 @@
};
};
 
+   hace: hace@1e6d {
+   compatible = "aspeed,ast2600-hace";
+   reg = <0x1e6d 0x200>;
+   interrupts = ;
+   clocks = < ASPEED_CLK_GATE_YCLK>;
+   status = "disabled";
+   };
+
edac: sdram@1e6e {
compatible = "aspeed,ast2600-sdram-edac";
reg = <0x1e6e 0x174>;
-- 
2.17.1

[PATCH 01/14] aspeed: ast2600: Enlarge SRAM size

The AST2600 SRAM has been extended to 88KB since A1
chip revision. This patch updates the SRAM size to
offer more space for early stack/heap use.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/include/asm/arch-aspeed/platform.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-aspeed/platform.h 
b/arch/arm/include/asm/arch-aspeed/platform.h
index d50ec5f8a9..589abd4a3f 100644
--- a/arch/arm/include/asm/arch-aspeed/platform.h
+++ b/arch/arm/include/asm/arch-aspeed/platform.h
@@ -17,7 +17,7 @@
 #define ASPEED_MAC_COUNT   4
 #define ASPEED_DRAM_BASE   0x8000
 #define ASPEED_SRAM_BASE   0x1000
-#define ASPEED_SRAM_SIZE   0x1
+#define ASPEED_SRAM_SIZE   0x16000
 #else
 #err "Unrecognized Aspeed platform."
 #endif
-- 
2.17.1

[PATCH 00/14] aspeed: Support secure boot chain with FIT image verification

This patch series intends to provide a secure boot chain from SPL to Linux 
kernel
based on the hash and signature verification of FIT image paradigm.

To improve the performance and save code size (SPL is limited to 64KB due to 
HW-RoT),
the drviers of two HW crypto engine HACE and ARCY are also added for AST26xx 
SoCs.

As HACE and ARCY can only access to DRAM space, additional configuration and
boot command are also updated according to move each FIT image before its 
booting.

In addition, the common code of FIT image hash algorithm lookup is also revised
to leverage the HW accelerated calculation.

Chia-Wei Wang (14):
  aspeed: ast2600: Enlarge SRAM size
  clk: ast2600: Add YCLK control for HACE
  crypto: aspeed: Add AST2600 HACE support
  ast2600: spl: Add HACE probing
  ARM: dts: ast2600: Add HACE to device tree
  common: fit: Use hash.c to call CRC/SHA function
  clk: ast2600: Add RSACLK control for ARCY
  crypto: aspeed: Add AST2600 ARCY support
  ast2600: spl: Add ARCY probing
  ARM: dts: ast2600: Add ARCY to device tree
  ast2600: spl: Locate load buffer in DRAM space
  configs: ast2600-evb: Enable SPL FIT support
  configs: aspeed: Make EXTRA_ENV_SETTINGS board specific
  configs: ast2600: Boot kernel FIT in DRAM

 arch/arm/dts/ast2600-evb.dts  |  10 +
 arch/arm/dts/ast2600.dtsi |  17 ++
 arch/arm/include/asm/arch-aspeed/platform.h   |   2 +-
 .../arm/include/asm/arch-aspeed/scu_ast2600.h |   6 +-
 arch/arm/mach-aspeed/ast2600/spl.c|  29 +-
 common/image-fit.c|  35 +--
 configs/evb-ast2600_defconfig |  26 +-
 drivers/clk/aspeed/clk_ast2600.c  |  35 +++
 drivers/crypto/Kconfig|   2 +
 drivers/crypto/Makefile   |   1 +
 drivers/crypto/aspeed/Kconfig |  22 ++
 drivers/crypto/aspeed/Makefile|   2 +
 drivers/crypto/aspeed/aspeed_arcy.c   | 182 +++
 drivers/crypto/aspeed/aspeed_hace.c   | 288 ++
 include/configs/aspeed-common.h   |   9 -
 include/configs/evb_ast2500.h |   6 +
 include/configs/evb_ast2600.h |  13 +
 lib/rsa/Kconfig   |  10 +-
 18 files changed, 645 insertions(+), 50 deletions(-)
 create mode 100644 drivers/crypto/aspeed/Kconfig
 create mode 100644 drivers/crypto/aspeed/Makefile
 create mode 100644 drivers/crypto/aspeed/aspeed_arcy.c
 create mode 100644 drivers/crypto/aspeed/aspeed_hace.c

-- 
2.17.1

Re: [PATCH 3/5] efi_loader: add boot variable measurement

2021-07-13 Thread Masahisa Kojima

Hi Heinrich,

> > > TCG spec also requires to measure "Calling EFI Application from
> > > Boot Option" for each boot attempt, and "Returning from EFI
> > > Application from Boot Option" if a boot device returns control
> > > back to the Boot Manager.

I would like to hear your opinion regarding
"Calling EFI Application from Boot Option" measurement.

My current(v1 patch series) implementation considers
both "bootefi bootmgr" and "bootefi $image_addr" cases,
so I do this "Calling EFI Application from Boot Option" measurement
at efi_boottime.c::efi_start_image().
Do I need to implement only the case UEFI application boot from bootmgr?
If yes, I will move the timing of this measurement at
efi_bootmgr.c::efi_bootmgr_load().

As a reference, in edk2, this measurement is performed in
ready_to_boot event handler, ready_to_boot handler is called
upon the user selects the boot option in boot manager.

What do you think?

Thanks,
Masahisa Kojima





On Fri, 9 Jul 2021 at 11:44, Masahisa Kojima  wrote:
>
> On Fri, 9 Jul 2021 at 02:46, Heinrich Schuchardt  wrote:
> >
> > On 7/7/21 3:36 PM, Masahisa Kojima wrote:
> > > TCG PC Client PFP spec requires to measure "Boot"
> > > and "BootOrder" variables, EV_SEPARATOR event prior
> > > to the Ready to Boot invocation.
> > > Since u-boot does not implement Ready to Boot event,
> > > these measurements are performed when efi_start_image() is called.
> > >
> > > TCG spec also requires to measure "Calling EFI Application from
> > > Boot Option" for each boot attempt, and "Returning from EFI
> > > Application from Boot Option" if a boot device returns control
> > > back to the Boot Manager.
> > >
> > > Signed-off-by: Masahisa Kojima 
> > > ---
> > >   include/efi_loader.h  |   4 ++
> > >   include/tpm-v2.h  |  18 -
> > >   lib/efi_loader/efi_boottime.c |  20 ++
> > >   lib/efi_loader/efi_tcg2.c | 123 ++
> > >   4 files changed, 164 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > > index 0a9c82a257..28130f 100644
> > > --- a/include/efi_loader.h
> > > +++ b/include/efi_loader.h
> > > @@ -407,6 +407,10 @@ efi_status_t efi_run_image(void *source_buffer, 
> > > efi_uintn_t source_size);
> > >   efi_status_t efi_init_variables(void);
> > >   /* Notify ExitBootServices() is called */
> > >   void efi_variables_boot_exit_notify(void);
> > > +/* Measure efi application invocation */
> > > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_invocation(void);
> > > +/* Measure efi application exit */
> > > +efi_status_t EFIAPI efi_tcg2_measure_efi_app_exit(void);
> > >   /* Called by bootefi to initialize root node */
> > >   efi_status_t efi_root_node_register(void);
> > >   /* Called by bootefi to initialize runtime */
> > > diff --git a/include/tpm-v2.h b/include/tpm-v2.h
> > > index 3e48e35861..8a7b7f1874 100644
> > > --- a/include/tpm-v2.h
> > > +++ b/include/tpm-v2.h
> > > @@ -73,7 +73,7 @@ struct udevice;
> > >   /*
> > >* event types, cf.
> > >* "TCG PC Client Platform Firmware Profile Specification", Family "2.0"
> > > - * rev 1.04, June 3, 2019
> > > + * Level 00 Version 1.05 Revision 23, May 7, 2021
> > >*/
> > >   #define EV_EFI_EVENT_BASE   ((u32)0x8000)
> > >   #define EV_EFI_VARIABLE_DRIVER_CONFIG   ((u32)0x8001)
> > > @@ -85,8 +85,24 @@ struct udevice;
> > >   #define EV_EFI_ACTION   ((u32)0x8007)
> > >   #define EV_EFI_PLATFORM_FIRMWARE_BLOB   ((u32)0x8008)
> > >   #define EV_EFI_HANDOFF_TABLES   ((u32)0x8009)
> > > +#define EV_EFI_PLATFORM_FIRMWARE_BLOB2   ((u32)0x800A)
> > > +#define EV_EFI_HANDOFF_TABLES2   ((u32)0x800B)
> > > +#define EV_EFI_VARIABLE_BOOT2((u32)0x800C)
> > >   #define EV_EFI_HCRTM_EVENT  ((u32)0x8010)
> > >   #define EV_EFI_VARIABLE_AUTHORITY   ((u32)0x80E0)
> > > +#define EV_EFI_SPDM_FIRMWARE_BLOB((u32)0x80E1)
> > > +#define EV_EFI_SPDM_FIRMWARE_CONFIG  ((u32)0x80E2)
> > > +
> > > +#define EFI_CALLING_EFI_APPLICATION \
> > > + "Calling EFI Application from Boot Option"
> > > +#define EFI_RETURNING_FROM_EFI_APPLICATION  \
> > > + "Returning from EFI Application from Boot Option"
> > > +#define EFI_EXIT_BOOT_SERVICES_INVOCATION   \
> > > + "Exit Boot Services Invocation"
> > > +#define EFI_EXIT_BOOT_SERVICES_FAILED   \
> > > + "Exit Boot Services Returned with Failure"
> > > +#define EFI_EXIT_BOOT_SERVICES_SUCCEEDED\
> > > + "Exit Boot Services Returned with Success"
> >
> > Which spec defines if the string in the event log shall be utf-8 or utf-16?
>
> TCG PC Client PFP spec does not clearly define the character encoding.
> In my understanding, the string derived from UEFI spec such as
> UEFI variable name uses utf-16(CHAR16).
> Other strings like

Re: zynqmpbif - sample

On 13/07/21, Michal Simek wrote:
> Hi,
> 
> On 7/12/21 7:40 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > hi Michal,
> > 
> > Would you have some sample/reference code to generate a SPL boot image
> > using zynqmpbif instead of zynqmpimage? I cant find any documentation
> > and I see no option to enable it (I was expecting to find some config
> > in Makefile.spl but I see none).
> > 
> > What is the expected way of building these images?
> 
> Alex implemented it for Xilinx bif format after origin zynqmpimage
> format. But usage is just like this.
> 
> [u-boot](debian-sent)$ ./tools/mkimage -T zynqmpbif -d /tmp/bif
> /tmp/boot.bin
> Image Type   : Xilinx ZynqMP Boot Image support
> Image Offset : 0x09c0
> Image Size   : 147216 bytes (147216 bytes packed)
> PMUFW Size   : 129792 bytes (129792 bytes packed)
> Image Load   : 0xfffc
> Checksum : 0xfd15d661
> [u-boot](debian-sent)$ cat /tmp/bif
> image : {
>   [pmufw_image, load=0xffdc] /mnt/disk/u-boot-bins/zynqmp/pmu.elf
>   [destination_cpu=a53-0, load=0xfffc, bootloader] spl/u-boot-spl.bin
> }

awesome, exactly what I needed to start with.


> 
> Thanks,
> Michal

Re: [PATCH] configs: omap3x_logic: Enable LTO on more LogicPD OMAP3 boards




On 26/06/21 4:51 pm, Adam Ford wrote:
> There are five omap3 based boards from LogicPD.  Two of them
> have added LTO support. Add the remaining three to use LTO.
> 
> Signed-off-by: Adam Ford 

There are many merge conflicts with this patch. Can you rebase on top of latest
master and repost?

Thanks and regards,
Lokesh

> 
> diff --git a/configs/omap35_logic_defconfig b/configs/omap35_logic_defconfig
> index 9ff5929b96..d359e32a36 100644
> --- a/configs/omap35_logic_defconfig
> +++ b/configs/omap35_logic_defconfig
> @@ -12,6 +12,7 @@ CONFIG_TARGET_OMAP3_LOGIC=y
>  # CONFIG_SPL_OMAP3_ID_NAND is not set
>  CONFIG_SPL=y
>  CONFIG_DEFAULT_DEVICE_TREE="logicpd-torpedo-35xx-devkit"
> +CONFIG_LTO=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_ANDROID_BOOT_IMAGE=y
>  # CONFIG_USE_BOOTCOMMAND is not set
> diff --git a/configs/omap35_logic_somlv_defconfig 
> b/configs/omap35_logic_somlv_defconfig
> index 2cc7060de5..d221ace735 100644
> --- a/configs/omap35_logic_somlv_defconfig
> +++ b/configs/omap35_logic_somlv_defconfig
> @@ -12,6 +12,7 @@ CONFIG_TARGET_OMAP3_LOGIC=y
>  # CONFIG_SPL_OMAP3_ID_NAND is not set
>  CONFIG_SPL=y
>  CONFIG_DEFAULT_DEVICE_TREE="logicpd-som-lv-35xx-devkit"
> +CONFIG_LTO=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_ANDROID_BOOT_IMAGE=y
>  # CONFIG_USE_BOOTCOMMAND is not set
> diff --git a/configs/omap3_logic_somlv_defconfig 
> b/configs/omap3_logic_somlv_defconfig
> index 90c670cee2..e2b71c5ab6 100644
> --- a/configs/omap3_logic_somlv_defconfig
> +++ b/configs/omap3_logic_somlv_defconfig
> @@ -12,6 +12,7 @@ CONFIG_TARGET_OMAP3_LOGIC=y
>  # CONFIG_SPL_OMAP3_ID_NAND is not set
>  CONFIG_SPL=y
>  CONFIG_DEFAULT_DEVICE_TREE="logicpd-som-lv-37xx-devkit"
> +CONFIG_LTO=y
>  CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_ANDROID_BOOT_IMAGE=y
>  # CONFIG_USE_BOOTCOMMAND is not set
>

Re: [PATCH v2 0/5] arm: dts: Add PMIC node for J7200




On 24/06/21 2:44 am, Gowtham Tammana wrote:
> The J7200 EVM has PMIC LP876441 for supporting CPU AVS. This patchset
> adds dt nodes, compatible string, and configs to enable the
> corresponding driver.
> 
> v2:
>  - rebased the changes are reordered patches 3/4

There are minor conflicts with latest master. Can you rebase and repost?

Thanks and regards,
Lokesh

> 
> v1:
>  - https://lore.kernel.org/u-boot/20200915113633.25449-1-g-tamm...@ti.com/
> 
> Gowtham Tammana (5):
>   power: pmic: tps65941: Add compatible for LP876441
>   arm/dts: k3-j7200-r5-common: Add pmic lp876441 node
>   arm/dts: k3-j7200-r5-common: Add VTM node
>   arm/dts: k3-j7200-r5-common: Hook buck1_reg to vtm supply
>   configs: j7200_evm_r5_defconfig: Enable AVS, PMIC and dependent
> configs
> 
>  .../arm/dts/k3-j7200-r5-common-proc-board.dts | 38 +++
>  configs/j7200_evm_r5_defconfig|  6 +++
>  drivers/power/pmic/tps65941.c |  1 +
>  include/power/tps65941.h  |  1 +
>  4 files changed, 46 insertions(+)
>

[PATCH] board: amlogic: vim3: fix phy-names property setup

2021-07-13 Thread Artem Lapkin

phy-names was improperly implemented resulting in an inoperable USB-OTG
port.

- phy-names = "usb2-phy0\0\0usb2-phy1\0";
+ phy-names = "usb2-phy0\0usb2-phy1";

Signed-off-by: Artem Lapkin 
---
 board/amlogic/vim3/vim3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
index c8ebd676..6a67a39c 100644
--- a/board/amlogic/vim3/vim3.c
+++ b/board/amlogic/vim3/vim3.c
@@ -109,8 +109,8 @@ int meson_ft_board_setup(void *blob, struct bd_info *bd)
}
 
/* Update PHY names (mandatory to disable USB3.0) */
-   len = strlcpy(data, "usb2-phy0", 32) + 1;
-   len += strlcpy([len], "usb2-phy1", 32 - len) + 1;
+   len = strlcpy(data, "usb2-phy0", 32);
+   len += strlcpy([len], "usb2-phy1", 32 - len);
ret = fdt_setprop(blob, node, "phy-names", data, len);
if (ret < 0) {
printf("vim3: failed to update usb phy names property 
(%d)\n", ret);
-- 
2.25.1

Re: [PATCH v2 5/5] configs: am335x_evm: Fix BeagleBone Green DTB selection