date:20211116

Re: [PATCH v2] sf: Querying write-protect status before operating the flash

2021-11-16 Thread chaochao




On 2021/11/15 22:02, Jagan Teki wrote:

On Mon, Nov 15, 2021 at 6:51 PM chaochao2021...@163.com
 wrote:


On 2021/11/15 13:57, tudor.amba...@microchip.com wrote:

Hi,

+ Michael

On 11/15/21 4:37 AM, chaochao2021...@163.com wrote:

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe

From: chao zeng 

When operating the write-protection flash,spi_flash_std_write() and
spi_flash_std_erase() would return wrong result.The flash is protected,
but write or erase the flash would show "OK".

Check the flash write protection state before operating the flash
and give a prompt to show it has been locked if the write-protection
has enbale

Signed-off-by: chao zeng 

---

Changes for V2:
  - Return 0 not ENOPROTOOPT to refelect the flash feature
  - Output prompt information
---
  drivers/mtd/spi/sf_probe.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index f461082e03..995801817d 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -109,6 +109,11 @@ static int spi_flash_std_write(struct udevice *dev, u32 
offset, size_t len,
 struct mtd_info *mtd = >mtd;
 size_t retlen;

+   if (flash->flash_is_locked && flash->flash_is_locked(flash, offset, 
len)) {
+   printf("SF: Flash is locked\n");

I would use a debug message, it's a flash specific thing. Also, I would update
a bit the message, something like
"SF: Flash has protected areas in the requested length. Writes will be ignored on 
those."

+   return 0;

Michael has suggested to drop this line. I agree with him, check the 
conversation
on the previous email thread.

Cheers,
ta

+   }
+
 return mtd->_write(mtd, offset, len, , buf);
  }

@@ -127,6 +132,11 @@ static int spi_flash_std_erase(struct udevice *dev, u32 
offset, size_t len)
 instr.addr = offset;
 instr.len = len;

+   if (flash->flash_is_locked && flash->flash_is_locked(flash, offset, 
len)) {
+   printf("SF: Flash is locked\n");
+   return 0;
+   }
+
 return mtd->_erase(mtd, );
  }

--
2.33.1



the background is we like to use sf command to operate the flash under uboot 
shell,

"sf erase" command still would show the prompt  "erase ok" even though  
write-enable has enabled.


So at the beginning  I'd like to return an error ,so the sf operation would show 
"erase failed" when operating the write-enabled devices.


I'm agree with only output information to prompt the user the operation 
unsuccessful.

But It should explicitly give clear hints,so I suggest at here using printf not 
debug.


We cannot encourage sf to show non operational prints like locked or
unlocked on command line. Just check the contents via read and compare
and understand whether flash is written properly, if not written
properly user has to debug on his own.

Jagan.



I think it’s not user friendly at all. Using debug is not a problem for 
developers, but it is not so good for users who use the sf command.



BRs
Chao

Re: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation

2021-11-16 Thread Michael Walle


Am 2021-11-16 12:57, schrieb Gaurav Jain:

>> > +int hwrng_generate(u8 *dst, u32 len)
>>
>> likewise.
>> But more important what is the difference to drivers/crypto/fsl/rng.c?
>> Why
>> do you need a new function here?

This one. Why can't you reuse the code which is already there?


I might have missed to update this.
dm_rng_read() can be used. Will remove hwrng_generate().


Nice, thanks. Slightly lesser code :)

-michael

Re: [PATCH v7 01/12] tools: mkeficapsule: rework the code a little bit

2021-11-16 Thread Heinrich Schuchardt


On 11/16/21 05:32, AKASHI Takahiro wrote:

Abstract common routines to make the code easily understandable.
No functional change.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Simon Glass 
---
  tools/mkeficapsule.c | 223 ++-
  1 file changed, 159 insertions(+), 64 deletions(-)

diff --git a/tools/mkeficapsule.c b/tools/mkeficapsule.c
index 4995ba4e0c2a..afdcaf7e7933 100644
--- a/tools/mkeficapsule.c
+++ b/tools/mkeficapsule.c
@@ -61,17 +61,122 @@ static void print_usage(void)
   tool_name);
  }

+/**
+ * read_bin_file - read a firmware binary file
+ * @bin:   Path to a firmware binary file
+ * @data:  Pointer to pointer of allocated buffer
+ * @bin_size:  Size of allocated buffer
+ *
+ * Read out a content of binary, @bin, into @data.
+ * A caller should free @data.
+ *
+ * Return:
+ * * 0  - on success
+ * * -1 - on failure
+ */
+static int read_bin_file(char *bin, void **data, off_t *bin_size)
+{
+   FILE *g;
+   struct stat bin_stat;
+   void *buf;
+   size_t size;
+   int ret = 0;
+
+   g = fopen(bin, "r");
+   if (!g) {
+   printf("cannot open %s\n", bin);


Error messages should be written to stderr. Use perror(bin) to get a
message like:

: No such file or directory

Or use fprintf(stderr, ...).


+   return -1;
+   }
+   if (stat(bin, _stat) < 0) {
+   printf("cannot determine the size of %s\n", bin);
+   ret = -1;
+   goto err;
+   }
+   if (bin_stat.st_size > (u32)~0U) {
+   printf("file size is too large: %s\n", bin);
+   ret = -1;
+   goto err;
+   }
+   buf = malloc(bin_stat.st_size);


For a symbolic link st_size is the length of the pathname it contains.
So this function is of no help here.


+   if (!buf) {
+   printf("cannot allocate memory: %zx\n",
+  (size_t)bin_stat.st_size);
+   ret = -1;
+   goto err;
+   }
+
+   size = fread(buf, 1, bin_stat.st_size, g);
+   if (size < bin_stat.st_size) {


fread() reads from a stream which is not necessarily a file but can be a
named pipe. stat() does not indicate when the stream will end.

You have to run fread() in a loop until feof() or ferror() indicate that
there is nothing more to be read from the stream.

Best regards

Heinrich


+   printf("read failed (%zx)\n", size);
+   ret = -1;
+   goto err;
+   }
+
+   *data = buf;
+   *bin_size = bin_stat.st_size;
+err:
+   fclose(g);
+
+   return ret;
+}
+
+/**
+ * write_capsule_file - write a capsule file
+ * @bin:   FILE stream
+ * @data:  Pointer to data
+ * @bin_size:  Size of data
+ *
+ * Write out data, @data, with the size @bin_size.
+ *
+ * Return:
+ * * 0  - on success
+ * * -1 - on failure
+ */
+static int write_capsule_file(FILE *f, void *data, size_t size, const char 
*msg)
+{
+   size_t size_written;
+
+   size_written = fwrite(data, 1, size, f);
+   if (size_written < size) {
+   printf("%s: write failed (%zx != %zx)\n", msg,
+  size_written, size);
+   return -1;
+   }
+
+   return 0;
+}
+
+/**
+ * create_fwbin - create an uefi capsule file
+ * @path:  Path to a created capsule file
+ * @bin:   Path to a firmware binary to encapsulate
+ * @guid:  GUID of related FMP driver
+ * @index: Index number in capsule
+ * @instance:  Instance number in capsule
+ * @mcount:Monotonic count in authentication information
+ * @private_file:  Path to a private key file
+ * @cert_file: Path to a certificate file
+ *
+ * This function actually does the job of creating an uefi capsule file.
+ * All the arguments must be supplied.
+ * If either @private_file ror @cert_file is NULL, the capsule file
+ * won't be signed.
+ *
+ * Return:
+ * * 0  - on success
+ * * -1 - on failure
+ */
  static int create_fwbin(char *path, char *bin, efi_guid_t *guid,
unsigned long index, unsigned long instance)
  {
struct efi_capsule_header header;
struct efi_firmware_management_capsule_header capsule;
struct efi_firmware_management_capsule_image_header image;
-   FILE *f, *g;
-   struct stat bin_stat;
-   u8 *data;
-   size_t size;
+   FILE *f;
+   void *data;
+   off_t bin_size;
u64 offset;
+   int ret;

  #ifdef DEBUG
printf("For output: %s\n", path);
@@ -79,25 +184,28 @@ static int create_fwbin(char *path, char *bin, efi_guid_t 
*guid,
printf("\tindex: %ld\n\tinstance: %ld\n", index, instance);
  #endif

-   g = fopen(bin, "r");
-   if (!g) {
-   printf("cannot open %s\n", bin);
-   return -1;
-   }
-   if (stat(bin, _stat) < 0) {
-   printf("cannot determine the size of %s\n", bin);
-   goto err_1;
-   }
-   data =

Re: [PATCH v7 02/12] tools: build mkeficapsule with tools-only_defconfig

2021-11-16 Thread Heinrich Schuchardt


On 11/16/21 05:32, AKASHI Takahiro wrote:

We want to always build mkeficapsule if tools-only_defconfig is used.

Signed-off-by: AKASHI Takahiro 


Reviewed-by: Heinrich Schuchardt 


---
  configs/tools-only_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig
index f482c9a1c1b0..5427797dd4c3 100644
--- a/configs/tools-only_defconfig
+++ b/configs/tools-only_defconfig
@@ -31,3 +31,4 @@ CONFIG_I2C_EDID=y
  # CONFIG_VIRTIO_MMIO is not set
  # CONFIG_VIRTIO_PCI is not set
  # CONFIG_VIRTIO_SANDBOX is not set
+CONFIG_TOOLS_MKEFICAPSULE=y

[PATCH 01/18] arm: ls1021a: limit debug eth phy speed to 100Mbps

2021-11-16 Thread Aleksandar Gerasimovski

Beside that mounted rgmii debug phy is 1000Mbps capable, the debug link
between the piggy board and the phy is 100Mbps only.
This leads to longer link establishment time when working in debug mode,
as phy tries to autoneg 1000Mbps.

This patch fixes the speed to 100Mbps and allows smother link establishment
time for the debug interface.

Signed-off-by: Aleksandar Gerasimovski 

---
 arch/arm/dts/ls1021a-pg-wcom-seli8.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/ls1021a-pg-wcom-seli8.dts 
b/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
index e335188..f2cadd7 100644
--- a/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
+++ b/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
@@ -38,6 +38,7 @@
  {
phy-handle = <_phy>;
phy-connection-type = "rgmii-id";
+   max-speed = <100>;
status = "okay";
 };
 
-- 
1.8.3.1

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

SoCs enabled for DTB Overlay features are:
LS1046A-RDB
LS1043A-RDB
LS1012A-RDB
LS1028A-RDB
LS1088A-RDB
LS2088A-RDB

Signed-off-by: Sahil Malhotra 
---
 configs/ls1012ardb_tfa_defconfig | 2 ++
 configs/ls1028ardb_tfa_defconfig | 1 +
 configs/ls1043ardb_tfa_defconfig | 2 ++
 configs/ls1046ardb_tfa_defconfig | 2 ++
 configs/ls1088ardb_tfa_defconfig | 2 ++
 configs/ls2088ardb_tfa_defconfig | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index c52359e51d..49ee762e38 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -69,3 +69,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index 8ce9da5b4f..b360427eb3 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_LS_HDP_LOAD=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig
index de3db3e2c4..a64df243f9 100644
--- a/configs/ls1043ardb_tfa_defconfig
+++ b/configs/ls1043ardb_tfa_defconfig
@@ -67,3 +67,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index e9e2efb210..55b6016e74 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -71,3 +71,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index 2e99e337c8..2351749d7d 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index de57235284..d1b6e7f7ae 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -89,3 +89,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
-- 
2.17.1

RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS

2021-11-16 Thread Joakim Zhang


> -Original Message-
> From: Ramon Fried 
> Sent: 2021年11月16日 18:45
> To: Joakim Zhang 
> Cc: Joe Hershberger ; U-Boot Mailing List
> ; Ye Li ; Patrick Delaunay
> ; Daniil Stas ;
> Stephen Warren 
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
> 
> On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang 
> wrote:
> >
> >
> > Hi Ramon,
> >
> > > -Original Message-
> > > From: Ramon Fried 
> > > Sent: 2021年11月16日 13:57
> > > To: Joakim Zhang 
> > > Cc: Joe Hershberger ; U-Boot Mailing List
> > > ; Ye Li ; Patrick Delaunay
> > > ; Daniil Stas
> > > ; Stephen Warren 
> > > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe
> > > stage instead of starting EQOS
> > >
> > > On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang
> > > 
> > > wrote:
> > > >
> > > > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > > > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > > > auto negotiation to complete when do tftp boot.
> > > > phy_config()
> > > > -> board_phy_config()
> > > > -> phydev->drv->config() // i.MX8MP/DXL use
> > > realtek PHY
> > > > -> rtl8211f_config()
> > > > -> genphy_config_aneg()
> > > > ->
> > > genphy_restart_aneg()
> > > > // restart auto-nego, then need seconds to complete
> > > >
> > > > To avoid wasting time, we can move PHY connection and
> > > > configuration from
> > > > eqos_start() to eqos_probe(). This patch also moves clock setting
> > > > from
> > > > eqos_start() to eqos_probe() as MDIO access need CSR clock, there
> > > > is no function change.
> > > >
> > > > Tested-on: i.MX8MP & i.MX8DXL
> > > >
> > > > Before:
> > > > u-boot=> run netboot
> > > > Booting from net ...
> > > > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > > > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > > > (313 ms) Using ethernet@30bf device TFTP from server
> > > > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > > > gateway 10.193.102.254
> > > > After:
> > > > u-boot=> run netboot
> > > > Booting from net ...
> > > > BOOTP broadcast 1
> > > > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > > > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > > > address is 10.193.102.192; sending through gateway 10.193.102.254
> > > >
> > > How much time do you save exactly, Is it the ~140ms you show here at
> > > the commit log ?
> >
> > Exactly not. This time points to DHCP client bound to address, not the time
> this patch saves.
> >
> > How can we evaluate the time we save? Please see the log:
> >
> > Before:
> > Booting from net ...
> > ethernet@30bf Waiting for PHY auto negotiation to complete...
> done
> > BOOTP broadcast 1
> > After:
> > Booting from net ...
> > BOOTP broadcast 1
> >
> > And you need to check the related code:
> > drivers/net/dwc_eth_qos.c: phy_startup ->...->
> > drivers/net/phy/phy.c: genphy_update_link()
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsour
> >
> ce.denx.de%2Fu-boot%2Fu-boot%2F-%2Fblob%2Fmaster%2Fdrivers%2Fnet
> %2Fphy
> > %2Fphy.c%23L225data=04%7C01%7Cqiangqing.zhang%40nxp.com%
> 7C59322db
> >
> 193a54788a09308d9a8ee2cfc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C0%7
> >
> C637726563178464522%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIj
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=usRIR7L
> exBnk
> > dnDO3U8hHYtMAIWT8bJ0Q7wgTElUjHs%3Dreserved=0
> >
> > while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> > /*
> >  * Timeout reached ?
> >  */
> > if (i > (PHY_ANEG_TIMEOUT / 50)) {
> > printf(" TIMEOUT !\n");
> > phydev->link = 0;
> > return -ETIMEDOUT;
> > }
> >
> > if (ctrlc()) {
> > puts("user interrupt!\n");
> > phydev->link = 0;
> > return -EINTR;
> > }
> >
> > if ((i++ % 10) == 0)
> > printf(".");
> >
> > mii_reg = phy_read(phydev,
> MDIO_DEVAD_NONE, MII_BMSR);
> > mdelay(50); /* 50 ms */
> > }
> >
> > We can see that one "." is about 500ms, so from the log, we save about
> 500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete
> auto-nego.
> >
> > I also described this in the commit message, "users need wait seconds for
> PHY auto negotiation to complete when do tftp boot", may not quite clear, I
> will improve it.
> >
> > Best Regards,
> >

Re: Your message to U-Boot awaits moderator approval

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 10:26:37AM +, Sahil Malhotra (OSS) wrote:

> Hi,
> 
> I am trying to send some patches on u-boot@lists.denx.de but every time I am 
> getting reply "Your message to U-Boot awaits moderator approval".
> Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the 
> list u-boot@lists.denx.de.
> 
> Tried multiple times, but always getting this reply.
> Any help regarding this is really appreciated.

Yes, your messages and then subscription (I'm not sure whey, on the
latter) were waiting for approval, which is now done.

-- 
Tom


signature.asc
Description: PGP signature

RE: Your message to U-Boot awaits moderator approval

2021-11-16 Thread Sahil Malhotra (OSS)

Hi,

I am trying to send some patches on u-boot@lists.denx.de but every time I am 
getting reply "Your message to U-Boot awaits moderator approval".
Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the 
list u-boot@lists.denx.de.

Tried multiple times, but always getting this reply.
Any help regarding this is really appreciated.

Regards,
Sahil Malhotra

-Original Message-
From: U-Boot  On Behalf Of 
u-boot-ow...@lists.denx.de
Sent: Tuesday, November 16, 2021 3:47 PM
To: Sahil Malhotra (OSS) 
Subject: Your message to U-Boot awaits moderator approval

Your mail to 'U-Boot' with the subject

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post to moderated list

Either the message will get posted to the list, or you will receive 
notification of the moderator's decision.  If you would like to cancel this 
posting, please visit the following URL:


https://lists.denx.de/confirm/u-boot/1d3c54aafb0ee9f189c3cef4f19bfd29f25cf5ed

RE: [EXT] Your message to U-Boot awaits moderator approval

2021-11-16 Thread Sahil Malhotra

Hi,

I am trying to send some patches on u-boot@lists.denx.de but every time I am 
getting reply "Your message to U-Boot awaits moderator approval".
Created account on http://patchwork.ozlabs.org/user/, Also subscribed to the 
list u-boot@lists.denx.de.

Tried multiple times, but always getting this reply.
Any help regarding this is really appreciated.

Regards,
Sahil Malhotra

-Original Message-
From: U-Boot  On Behalf Of 
u-boot-ow...@lists.denx.de
Sent: Tuesday, November 16, 2021 2:05 PM
To: Sahil Malhotra 
Subject: [EXT] Your message to U-Boot awaits moderator approval

Caution: EXT Email

Your mail to 'U-Boot' with the subject

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

Is being held until the list moderator can review it for approval.

The reason it is being held:

Post to moderated list

Either the message will get posted to the list, or you will receive 
notification of the moderator's decision.  If you would like to cancel this 
posting, please visit the following URL:


https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.denx.de%2Fconfirm%2Fu-boot%2Fc921389ccb7759ac41403909f360475b5243a75ddata=04%7C01%7Csahil.malhotra%40nxp.com%7C64ce15466de943b4c9cf08d9a8dc06ea%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637726485232188800%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=qBbVbxrlgCIP4Y7yNQDxYixWJPzQnmJvyXACZakrQmE%3Dreserved=0

[PATCH 13/18] configs: expu1: enable ver envvar for version_string

2021-11-16 Thread Aleksandar Gerasimovski

This is used by out ESW for reading u-boot build version.

Signed-off-by: Aleksandar Gerasimovski 

---
 configs/pg_wcom_expu1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/pg_wcom_expu1_defconfig b/configs/pg_wcom_expu1_defconfig
index 267864f..9e8697d 100644
--- a/configs/pg_wcom_expu1_defconfig
+++ b/configs/pg_wcom_expu1_defconfig
@@ -75,3 +75,4 @@ CONFIG_SYS_QE_FW_ADDR=0x6002
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_VERSION_VARIABLE=y
-- 
1.8.3.1

[PATCH 17/18] configs/expu1/seli8: limit autoboot stop to space key

2021-11-16 Thread Aleksandar Gerasimovski

Make it in a same way as on the other FOXMC products, this also helps to
avoid unwanted stop caused by some terminal servers that are sending junk
on the serial line.

Signed-off-by: Aleksandar Gerasimovski 

---
 configs/pg_wcom_expu1_defconfig | 3 +++
 configs/pg_wcom_seli8_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/pg_wcom_expu1_defconfig b/configs/pg_wcom_expu1_defconfig
index 0ff96e5..65ac373 100644
--- a/configs/pg_wcom_expu1_defconfig
+++ b/configs/pg_wcom_expu1_defconfig
@@ -28,6 +28,9 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_BOOTDELAY=3
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_AUTOBOOT_PROMPT="Hit  key to stop autoboot in %2ds\n"
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0"
 CONFIG_SILENT_CONSOLE=y
diff --git a/configs/pg_wcom_seli8_defconfig b/configs/pg_wcom_seli8_defconfig
index f13cc55..9124c31 100644
--- a/configs/pg_wcom_seli8_defconfig
+++ b/configs/pg_wcom_seli8_defconfig
@@ -28,6 +28,9 @@ CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_BOOTDELAY=3
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_AUTOBOOT_PROMPT="Hit  key to stop autoboot in %2ds\n"
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0"
 CONFIG_SILENT_CONSOLE=y
-- 
1.8.3.1

Re: [PATCH RFC] cmd: fix net list command

2021-11-16 Thread Wolfgang Denk

Dear Tom,

In message <2025154516.GR24579@bill-the-cat> you wrote:
> 
> > One practical use case is board provisioning in the factory, which
> > includes setting up valid produt data like serial number, MAC
> > address etc. Yes, this can be done over serial consone as well, but
> > 1) this is slower than network and 2) many commecial products don't
> > have the connector etc. populated.
> 
> Is that the case for the layerscape or imx8 families?  I know on the TI
> side these values are derived from chip-specific fuses that are blown at
> chip production so we don't need an initial random one.  I'd have to
> pull up some NXP manuals to see what's the case there, but I think some
> other people on the thread know the answers here already.

This is actually independent of the hardware, I think.

It is more or less a management decision how board bringup / inital
commissioning is organized.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
In a business, marketroids, salespukes, and  lawyers  have  different
goals from those who actually do work and produce something. Usually,
is  is the former who triumph over the latter, due to the simple rule
that those who print the money make the rules.
 -- Tom Christiansen in <5jdcls$b04$2...@csnews.cs.colorado.edu>

Re: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation

2021-11-16 Thread Michael Walle


Hi,

Am 2021-11-16 12:09, schrieb Gaurav Jain:

> --- a/drivers/crypto/fsl/fsl_blob.c
> +++ b/drivers/crypto/fsl/fsl_blob.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2021 NXP
>   *
>   */
>
> @@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst,
u32 len)
>   return ret;
>  }
>
> +int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)

where is this function actually used? looks like dead code to me.


I was thinking to add the command for this function later.
But will remove this patch from this series and send this later with
derive blob kek cmd implementation.


ok, but you've missed the question below.



> +{
> + int ret, size;
> + u32 *desc;
> +
> + if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
> + !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
> + puts("Error: derive_bkek: Address arguments are not 
aligned!\n");
> + return -EINVAL;
> + }
> +
> + printf("\nBlob key encryption key(bkek)\n");
> + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> + if (!desc) {
> + printf("Not enough memory for descriptor allocation\n");
> + return -ENOMEM;
> + }
> +
> + size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)key_mod, (unsigned
> + long)key_mod + size);
> +
> + /* construct blob key encryption key(bkek) derive descriptor */
> + inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod,
> + key_sz);
> +
> + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE,
ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> + size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> +
> + /* run descriptor */
> + ret = run_descriptor_jr(desc);
> + if (ret < 0) {
> + printf("Error: %s failed 0x%x\n", __func__, ret);
> + } else {
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> + puts("derive bkek successful.\n");
> + }
> +
> + free(desc);
> + return ret;
> +}
> +
> +int hwrng_generate(u8 *dst, u32 len)

likewise.
But more important what is the difference to drivers/crypto/fsl/rng.c? 
Why

do you need a new function here?


This one. Why can't you reuse the code which is already there?

-michael

RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS

2021-11-16 Thread Joakim Zhang


Hi Patrick,

> -Original Message-
> From: Patrick DELAUNAY 
> Sent: 2021年11月15日 18:42
> To: Joakim Zhang ; joe.hershber...@ni.com;
> rfried@gmail.com
> Cc: u-boot@lists.denx.de; Ye Li ; daniil.s...@posteo.net;
> swar...@nvidia.com; Christophe ROULLIER
> ; Marek Vasut 
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
> 
> Hi,
> 
> On 11/10/21 6:42 AM, Joakim Zhang wrote:
> > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > auto negotiation
> 
> s/eqos_srart()/eqos_start()/
> 
> 
> > to complete when do tftp boot.
> >  phy_config()
> >  -> board_phy_config()
> >  -> phydev->drv->config() // i.MX8MP/DXL use
> realtek PHY
> >  -> rtl8211f_config()
> >  -> genphy_config_aneg()
> >  ->
> genphy_restart_aneg()
> > // restart auto-nego, then need seconds to complete
> >
> > To avoid wasting time, we can move PHY connection and configuration
> > from
> > eqos_start() to eqos_probe(). This patch also moves clock setting from
> > eqos_start() to eqos_probe() as MDIO access need CSR clock, there is
> > no function change.
> >
> > Tested-on: i.MX8MP & i.MX8DXL
> >
> > Before:
> > u-boot=> run netboot
> > Booting from net ...
> > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > (313 ms) Using ethernet@30bf device TFTP from server
> > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > gateway 10.193.102.254
> > After:
> > u-boot=> run netboot
> > Booting from net ...
> > BOOTP broadcast 1
> > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > address is 10.193.102.192; sending through gateway 10.193.102.254
> >
> > Signed-off-by: Joakim Zhang 
> > ---
> >   drivers/net/dwc_eth_qos.c | 132
> +++---
> >   1 file changed, 67 insertions(+), 65 deletions(-)
> >
> > diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
> > index 585101804d..c1923fbe6b 100644
> > --- a/drivers/net/dwc_eth_qos.c
> > +++ b/drivers/net/dwc_eth_qos.c
> > @@ -1045,20 +1045,6 @@ static int eqos_start(struct udevice *dev)
> > eqos->tx_desc_idx = 0;
> > eqos->rx_desc_idx = 0;
> >
> > -   ret = eqos->config->ops->eqos_start_clks(dev);
> > -   if (ret < 0) {
> > -   pr_err("eqos_start_clks() failed: %d", ret);
> > -   goto err;
> > -   }
> > -
> > -   ret = eqos->config->ops->eqos_start_resets(dev);
> > -   if (ret < 0) {
> > -   pr_err("eqos_start_resets() failed: %d", ret);
> > -   goto err_stop_clks;
> > -   }
> > -
> > -   udelay(10);
> > -
> > eqos->reg_access_ok = true;
> 
> => as clock is moved in probe...
> 
> the line
> eqos->reg_access_ok = true
> should be also moved I think
>
> or reg_access_ok can be removed, as reg_access_ok is always one when
> eqos_write_hwaddr is called

Why? I saw this variable "reg_access_ok " doesn't have initialize value. If 
remove this line,
I think it will break the logic in eqos_write_hwaddr(), so I agree also move it 
into probe().

> >
> > ret = wait_for_bit_le32(>dma_regs->mode,
> > @@ -1066,68 +1052,34 @@ static int eqos_start(struct udevice *dev)
> > eqos->config->swr_wait, false);
> > if (ret) {
> > pr_err("EQOS_DMA_MODE_SWR stuck");
> > -   goto err_stop_resets;
> > +   goto err;
> > }
> >
> > ret = eqos->config->ops->eqos_calibrate_pads(dev);
> > if (ret < 0) {
> > pr_err("eqos_calibrate_pads() failed: %d", ret);
> > -   goto err_stop_resets;
> > +   goto err;
> > }
> > rate = eqos->config->ops->eqos_get_tick_clk_rate(dev);
> >
> > val = (rate / 100) - 1;
> > writel(val, >mac_regs->us_tic_counter);
> >
> > -   /*
> > -* if PHY was already connected and configured,
> > -* don't need to reconnect/reconfigure again
> > -*/
> > -   if (!eqos->phy) {
> > -   int addr = -1;
> > -#ifdef CONFIG_DM_ETH_PHY
> > -   addr = eth_phy_get_addr(dev);
> > -#endif
> > -#ifdef DWC_NET_PHYADDR
> > -   addr = DWC_NET_PHYADDR;
> > -#endif
> > -   eqos->phy = phy_connect(eqos->mii, addr, dev,
> > -   eqos->config->interface(dev));
> > -   if (!eqos->phy) {
> > -   pr_err("phy_connect() failed");
> > -   goto err_stop_resets;
> > -   }
> > -
> > -   if (eqos->max_speed) {
> > -   ret = phy_set_supported(eqos->phy, eqos->max_speed);
> > -   if (ret) {
> > -   pr_err("phy_set_supported() failed: %d", ret);
> > -

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

This patch enables the DTB overlay feature for LS platforms.

Signed-off-by: Sahil Malhotra 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c  | 39 +++
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h  | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 12 ++
 .../cpu/armv8/fsl-layerscape/lowlevel_init.S  | 25 
 5 files changed, 87 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
 obj-y += soc.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 endif
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include 
+#include 
+#include 
+#include 
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+   int ret = 0;
+
+   /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+   if (!rom_pointer[0]) {
+   debug("No BL32_BASE passed means no TEE running\n");
+   return ret;
+   }
+
+   if (rom_pointer[2]) {
+   debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+   ret = fdt_check_header((void *)rom_pointer[2]);
+   if (ret == 0) {
+   /* Copy the fdt overlay to next 1M and use copied 
overlay */
+   memcpy((void *)(rom_pointer[2] + SZ_1M), (void 
*)rom_pointer[2],
+  fdt_totalsize((void *)rom_pointer[2]));
+   ret = fdt_overlay_apply_verbose(fdt, (void 
*)(rom_pointer[2] + SZ_1M));
+   if (ret == 0) {
+   debug("Overlay applied with success");
+   fdt_pack(fdt);
+   }
+   }
+   }
+   return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
 #endif
 #include 
 #include 
+#include "dt_optee.h"
 
 int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
 {
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
 #endif
 }
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+   return ft_add_optee_overlay(blob, bd);
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include 
+
+.align 8
+.global rom_pointer
+rom_pointer:
+   .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+   /* The firmware provided FDT address can be found in r2/x0 */
+   adr x0, rom_pointer
+   stp x1, x2, [x0], #16
+   stp x3, x4, [x0], #16
+
+   ldr x1, =save_boot_params_ret
+   br  x1
-- 
2.17.1

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

2021-11-16 Thread Sahil Malhotra

SoCs enabled for DTB Overlay features are:
LS1046A-RDB
LS1043A-RDB
LS1012A-RDB
LS1028A-RDB
LS1088A-RDB
LS2088A-RDB

Signed-off-by: Sahil Malhotra 
---
 configs/ls1012ardb_tfa_defconfig | 2 ++
 configs/ls1028ardb_tfa_defconfig | 1 +
 configs/ls1043ardb_tfa_defconfig | 2 ++
 configs/ls1046ardb_tfa_defconfig | 2 ++
 configs/ls1088ardb_tfa_defconfig | 2 ++
 configs/ls2088ardb_tfa_defconfig | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index c52359e51d..49ee762e38 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -69,3 +69,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index 8ce9da5b4f..b360427eb3 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_LS_HDP_LOAD=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig
index de3db3e2c4..a64df243f9 100644
--- a/configs/ls1043ardb_tfa_defconfig
+++ b/configs/ls1043ardb_tfa_defconfig
@@ -67,3 +67,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index e9e2efb210..55b6016e74 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -71,3 +71,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index 2e99e337c8..2351749d7d 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index de57235284..d1b6e7f7ae 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -89,3 +89,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
-- 
2.17.1

RE: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS

2021-11-16 Thread Joakim Zhang


Hi Ramon,

> -Original Message-
> From: Ramon Fried 
> Sent: 2021年11月16日 13:57
> To: Joakim Zhang 
> Cc: Joe Hershberger ; U-Boot Mailing List
> ; Ye Li ; Patrick Delaunay
> ; Daniil Stas ;
> Stephen Warren 
> Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> instead of starting EQOS
> 
> On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang 
> wrote:
> >
> > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > auto negotiation to complete when do tftp boot.
> > phy_config()
> > -> board_phy_config()
> > -> phydev->drv->config() // i.MX8MP/DXL use
> realtek PHY
> > -> rtl8211f_config()
> > -> genphy_config_aneg()
> > ->
> genphy_restart_aneg()
> > // restart auto-nego, then need seconds to complete
> >
> > To avoid wasting time, we can move PHY connection and configuration
> > from
> > eqos_start() to eqos_probe(). This patch also moves clock setting from
> > eqos_start() to eqos_probe() as MDIO access need CSR clock, there is
> > no function change.
> >
> > Tested-on: i.MX8MP & i.MX8DXL
> >
> > Before:
> > u-boot=> run netboot
> > Booting from net ...
> > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > (313 ms) Using ethernet@30bf device TFTP from server
> > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > gateway 10.193.102.254
> > After:
> > u-boot=> run netboot
> > Booting from net ...
> > BOOTP broadcast 1
> > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > address is 10.193.102.192; sending through gateway 10.193.102.254
> >
> How much time do you save exactly, Is it the ~140ms you show here at the
> commit log ?

Exactly not. This time points to DHCP client bound to address, not the time 
this patch saves.

How can we evaluate the time we save? Please see the log:

Before:
Booting from net ...
ethernet@30bf Waiting for PHY auto negotiation to complete... done
BOOTP broadcast 1
After:
Booting from net ...
BOOTP broadcast 1   

And you need to check the related code:
drivers/net/dwc_eth_qos.c: phy_startup ->...->
drivers/net/phy/phy.c: genphy_update_link()

https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/phy/phy.c#L225

while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
/*
 * Timeout reached ?
 */
if (i > (PHY_ANEG_TIMEOUT / 50)) {
printf(" TIMEOUT !\n");
phydev->link = 0;
return -ETIMEDOUT;
}

if (ctrlc()) {
puts("user interrupt!\n");
phydev->link = 0;
return -EINTR;
}

if ((i++ % 10) == 0)
printf(".");

mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);
mdelay(50); /* 50 ms */
}

We can see that one "." is about 500ms, so from the log, we save about 
500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete 
auto-nego.

I also described this in the commit message, "users need wait seconds for PHY 
auto negotiation to complete when do tftp boot", may not quite clear, I will 
improve it.

Best Regards,
Joakim Zhang

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

SoCs enabled for DTB Overlay features are:
LS1046A-RDB
LS1043A-RDB
LS1012A-RDB
LS1028A-RDB
LS1088A-RDB
LS2088A-RDB

Signed-off-by: Sahil Malhotra 
---
 configs/ls1012ardb_tfa_defconfig | 2 ++
 configs/ls1028ardb_tfa_defconfig | 1 +
 configs/ls1043ardb_tfa_defconfig | 2 ++
 configs/ls1046ardb_tfa_defconfig | 2 ++
 configs/ls1088ardb_tfa_defconfig | 2 ++
 configs/ls2088ardb_tfa_defconfig | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index c52359e51d..49ee762e38 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -69,3 +69,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index 8ce9da5b4f..b360427eb3 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_LS_HDP_LOAD=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig
index de3db3e2c4..a64df243f9 100644
--- a/configs/ls1043ardb_tfa_defconfig
+++ b/configs/ls1043ardb_tfa_defconfig
@@ -67,3 +67,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index e9e2efb210..55b6016e74 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -71,3 +71,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index 2e99e337c8..2351749d7d 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index de57235284..d1b6e7f7ae 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -89,3 +89,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
-- 
2.17.1

Re: [PATCH v2] pci: Work around PCIe link training failures

2021-11-16 Thread Pali Rohár

Hello!

On Tuesday 16 November 2021 11:35:24 Maciej W. Rozycki wrote:
> Attempt to handle cases with a downstream port of a PCIe switch where
> link training never completes and the link continues switching between 
> speeds indefinitely with the data link layer never reaching the active 
> state.
> 
> It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 
> switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 
> switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, 
> P/N 41433, wired to a SiFive HiFive Unmatched board.  In this setup the 
> switches are supposed to negotiate the link speed of preferably 5.0GT/s, 
> falling back to 2.5GT/s.
> 
> However the link continues oscillating between the two speeds, at the 
> rate of 34-35 times per second, with link training reported active ~84% 
> of the time repeatedly, e.g.:
> 
> 02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet 
> Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
> [...]
>   Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
> [...]
>   Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
> [...]
>   LnkSta: Speed 5GT/s (downgraded), Width x1 (ok)
>   TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt-
> [...]
>   LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, 
> Selectable De-emphasis: -3.5dB
>Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>Compliance De-emphasis: -6dB
> [...]
> 
> Forcibly limiting the target link speed to 2.5GT/s with the upstream 
> ASM2824 device makes the two switches communicate correctly however:
> 
> 02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet 
> Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
> [...]
>   Bus: primary=02, secondary=05, subordinate=09, sec-latency=0
> [...]
>   Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
> [...]
>   LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
>   TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
> [...]
>   LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
> SpeedDis+, Selectable De-emphasis: -3.5dB
>Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>Compliance De-emphasis: -6dB
> [...]
> 
> and then:
> 
> 05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 
> 3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode])
> [...]
>   Bus: primary=05, secondary=06, subordinate=09, sec-latency=0
> [...]
>   Capabilities: [c0] Express (v2) Upstream Port, MSI 00
> [...]
>   LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
>   TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
> [...]
>   LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
>Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>Compliance De-emphasis: -6dB
> [...]
> 
> Make use of this observation then and attempt to detect the inability to 
> negotiate the link speed automatically, and then handle it by hand.  Use 
> the Data Link Layer Link Active status flag as the primary indicator of 
> successful link speed negotiation, but given that the flag is optional 
> by hardware to implement (the ASM2824 does have it though), resort to 
> checking for the mandatory Link Bandwidth Management Status flag showing 
> that the link speed or width has been changed in an attempt to correct 
> unreliable link operation (the ASM2824 does set it too).
> 
> If these checks indicate that link may not operate correctly, then poll 
> the Data Link Layer Link Active status flag along with the Link Training 
> flag for the duration of 200ms to see if the link has stabilised, that 
> is either that the Data Link Layer Link Active status flag has been set 
> or that Link Training has been inactive during at least the second half 
> of the inteval.
> 
> If that has indicated failure, reduce the target speed, request a link 
> retrain and check again if the link has stabilised.  Repeat until either 
> successful or the link speeds supported by the downstream port have been 
> exhausted.

I would like to hear what Bjorn Helgaas thinks about this issue at all
and how to handle it, without potentially break something else. And
based on the fact that in U-Boot's PCI core code there is no such global
quirk implemented, I really do not know if U-Boot maintainers and
developers want to review and understand all PCI Express aspect of this
code and possible side-effects. This is just what I think about it, I do
not have maintainer hat.

I suggested to to first send this fixup to the Linux kernel for proper
review (or to

Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 08:37:06AM -0300, Fabio Estevam wrote:
> Hi Ariel,
> 
> The patch looks good. Only some minor comments:
> 
> On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro
>  wrote:
> >
> > Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
> >
> > - 1GiB DDR4 RAM
> > - 16 GiB eMMC
> > - SD card
> > - Gigabit ethernet
> > - USBOTG1 peripheral - fastboot
> >
> > Signed-off-by: Ariel D'Alessandro 
> 
> It would be nice to have a README file so that the users can know how
> to build and flash mainline
> U-Boot in this board.

And that means an entry under doc/board/variscite/ to be clear.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: eqos: connect and config PHY from probe stage instead of starting EQOS

2021-11-16 Thread Ramon Fried

On Tue, Nov 16, 2021 at 10:04 AM Joakim Zhang  wrote:
>
>
> Hi Ramon,
>
> > -Original Message-
> > From: Ramon Fried 
> > Sent: 2021年11月16日 13:57
> > To: Joakim Zhang 
> > Cc: Joe Hershberger ; U-Boot Mailing List
> > ; Ye Li ; Patrick Delaunay
> > ; Daniil Stas ;
> > Stephen Warren 
> > Subject: Re: [PATCH] net: eqos: connect and config PHY from probe stage
> > instead of starting EQOS
> >
> > On Wed, Nov 10, 2021 at 7:42 AM Joakim Zhang 
> > wrote:
> > >
> > > For EQOS ethernet, it will do phy_connect() and phy_config() when
> > > start the ethernet (eqos_srart()), users need wait seconds for PHY
> > > auto negotiation to complete when do tftp boot.
> > > phy_config()
> > > -> board_phy_config()
> > > -> phydev->drv->config() // i.MX8MP/DXL use
> > realtek PHY
> > > -> rtl8211f_config()
> > > -> genphy_config_aneg()
> > > ->
> > genphy_restart_aneg()
> > > // restart auto-nego, then need seconds to complete
> > >
> > > To avoid wasting time, we can move PHY connection and configuration
> > > from
> > > eqos_start() to eqos_probe(). This patch also moves clock setting from
> > > eqos_start() to eqos_probe() as MDIO access need CSR clock, there is
> > > no function change.
> > >
> > > Tested-on: i.MX8MP & i.MX8DXL
> > >
> > > Before:
> > > u-boot=> run netboot
> > > Booting from net ...
> > > ethernet@30bf Waiting for PHY auto negotiation to complete...
> > > done BOOTP broadcast 1 DHCP client bound to address 10.193.102.192
> > > (313 ms) Using ethernet@30bf device TFTP from server
> > > 10.193.108.176; our IP address is 10.193.102.192; sending through
> > > gateway 10.193.102.254
> > > After:
> > > u-boot=> run netboot
> > > Booting from net ...
> > > BOOTP broadcast 1
> > > DHCP client bound to address 10.193.102.192 (454 ms) Using
> > > ethernet@30bf device TFTP from server 10.193.108.176; our IP
> > > address is 10.193.102.192; sending through gateway 10.193.102.254
> > >
> > How much time do you save exactly, Is it the ~140ms you show here at the
> > commit log ?
>
> Exactly not. This time points to DHCP client bound to address, not the time 
> this patch saves.
>
> How can we evaluate the time we save? Please see the log:
>
> Before:
> Booting from net ...
> ethernet@30bf Waiting for PHY auto negotiation to complete... done
> BOOTP broadcast 1
> After:
> Booting from net ...
> BOOTP broadcast 1
>
> And you need to check the related code:
> drivers/net/dwc_eth_qos.c: phy_startup ->...->
> drivers/net/phy/phy.c: genphy_update_link()
>
> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/net/phy/phy.c#L225
>
> while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> /*
>  * Timeout reached ?
>  */
> if (i > (PHY_ANEG_TIMEOUT / 50)) {
> printf(" TIMEOUT !\n");
> phydev->link = 0;
> return -ETIMEDOUT;
> }
>
> if (ctrlc()) {
> puts("user interrupt!\n");
> phydev->link = 0;
> return -EINTR;
> }
>
> if ((i++ % 10) == 0)
> printf(".");
>
> mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);
> mdelay(50); /* 50 ms */
> }
>
> We can see that one "." is about 500ms, so from the log, we save about 
> 500*7=3500ms=3.5s, this also means that PHY needs about 3.5s to complete 
> auto-nego.
>
> I also described this in the commit message, "users need wait seconds for PHY 
> auto negotiation to complete when do tftp boot", may not quite clear, I will 
> improve it.
>
> Best Regards,
> Joakim Zhang

NACK.
Hi Joakim.
It's currently working like that for all network drivers, it's not specific
What you're currently suggesting is that the link will be brought up
automatically for all users, even if they're not interested in network
booting.
That won't work.
Thanks,
Ramon

Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation

2021-11-16 Thread Michael Walle

Hi,

> --- a/drivers/crypto/fsl/fsl_blob.c
> +++ b/drivers/crypto/fsl/fsl_blob.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2014 Freescale Semiconductor, Inc.
> + * Copyright 2021 NXP
>   *
>   */
>  
> @@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
>   return ret;
>  }
>  
> +int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)

where is this function actually used? looks like dead code to me.

> +{
> + int ret, size;
> + u32 *desc;
> +
> + if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
> + !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
> + puts("Error: derive_bkek: Address arguments are not 
> aligned!\n");
> + return -EINVAL;
> + }
> +
> + printf("\nBlob key encryption key(bkek)\n");
> + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> + if (!desc) {
> + printf("Not enough memory for descriptor allocation\n");
> + return -ENOMEM;
> + }
> +
> + size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)key_mod, (unsigned long)key_mod + 
> size);
> +
> + /* construct blob key encryption key(bkek) derive descriptor */
> + inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod, key_sz);
> +
> + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> + size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> +
> + /* run descriptor */
> + ret = run_descriptor_jr(desc);
> + if (ret < 0) {
> + printf("Error: %s failed 0x%x\n", __func__, ret);
> + } else {
> + invalidate_dcache_range((unsigned long)bkek_buf,
> + (unsigned long)bkek_buf + size);
> + puts("derive bkek successful.\n");
> + }
> +
> + free(desc);
> + return ret;
> +}
> +
> +int hwrng_generate(u8 *dst, u32 len)

likewise.
But more important what is the difference to drivers/crypto/fsl/rng.c? Why
do you need a new function here?

> +{
> + int ret, size;
> + u32 *desc;
> +
> + if (!IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
> + puts("Error: caam_hwrng_test: Address arguments are not 
> aligned!\n");
> + return -EINVAL;
> + }
> +
> + printf("\nRNG generate\n");
> + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> + if (!desc) {
> + printf("Not enough memory for descriptor allocation\n");
> + return -ENOMEM;
> + }
> +
> + inline_cnstr_jobdesc_rng(desc, dst, len);
> +
> + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
> + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> + size = ALIGN(len, ARCH_DMA_MINALIGN);
> + invalidate_dcache_range((unsigned long)dst, (unsigned long)dst + size);
> +
> + ret = run_descriptor_jr(desc);
> + if (ret < 0) {
> + printf("Error: RNG generate failed 0x%x\n", ret);
> + } else {
> + invalidate_dcache_range((unsigned long)dst,
> + (unsigned long)dst + size);
> + puts("RNG generation successful.\n");
> + }
> +
> + free(desc);
> + return ret;
> +}
> +
>  #ifdef CONFIG_CMD_DEKBLOB
>  int blob_dek(const u8 *src, u8 *dst, u8 len)
>  {

-michael

[PATCH 05/18] km/ls102xa: dbg phy prst depends on piggy presence

2021-11-16 Thread Aleksandar Gerasimovski

The PHY for the debug interface was placed on the board for the
pg_wcom_ls102x. Hence only when a piggy is plugged, a RJ45 jack
including magnetics is connected to the MDI of the PHY. Without a
piggy the MDI lines are left floating and it does not make sense to
have an active debug PHY.
In case of expu1 an active PHY without a piggy even led to increased
jitter for syncE.

This patch only deactivates the prst line of the debug PHY when a piggy
is detected persent.

Signed-off-by: Rainer Boschung 
Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c 
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index 2be2b64..cff18dc 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -91,8 +91,10 @@ int board_early_init_f(void)
qrio_prstcfg(WCOM_CLIPS_RST, PRSTCFG_POWUP_UNIT_RST);
qrio_prst(WCOM_CLIPS_RST, false, false);
 #endif
+
+   /* deasset debug phy reset only if piggy is present */
qrio_prstcfg(KM_DBG_ETH_RST, PRSTCFG_POWUP_UNIT_CORE_RST);
-   qrio_prst(KM_DBG_ETH_RST, false, false);
+   qrio_prst(KM_DBG_ETH_RST, !qrio_get_pgy_pres_pin(), false);
 
i2c_deblock_gpio_cfg();
 
-- 
1.8.3.1

[PATCH 06/18] km: qrio: add access functions for ebootcount

2021-11-16 Thread Aleksandar Gerasimovski

The EBOOTCNT is a reserved persistent static memory area in QRIO,
and similar to BOOTCNT is intended to be used as boot counter location.

Comparable to BOOTCNT that is reserved for u-boot main bootcount
infrastructure, EBOOTCNT is intended to be used for pg-wcom board
specific purposes (e.g implementing early boot counter for fail-safe
u-boot update).

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/common/common.h |  3 +++
 board/keymile/common/qrio.c   | 38 ++
 2 files changed, 41 insertions(+)

diff --git a/board/keymile/common/common.h b/board/keymile/common/common.h
index 15a3c37..fc14728 100644
--- a/board/keymile/common/common.h
+++ b/board/keymile/common/common.h
@@ -133,6 +133,9 @@ int get_testpin(void);
 
 int set_km_env(void);
 
+ulong early_bootcount_load(void);
+void early_bootcount_store(ulong ebootcount);
+
 #define DELAY_ABORT_SEQ62  /* @200kHz 9 clocks = 44us, 62us is 
ok */
 #define DELAY_HALF_PERIOD  (500 / (CONFIG_SYS_I2C_SPEED / 1000))
 
diff --git a/board/keymile/common/qrio.c b/board/keymile/common/qrio.c
index 89a9726..5401bdd 100644
--- a/board/keymile/common/qrio.c
+++ b/board/keymile/common/qrio.c
@@ -270,6 +270,44 @@ void qrio_uprstreq(u8 mode)
out_8(qrio_base + RSTCFG_OFF, rstcfg);
 }
 
+/* Early bootcount memory area is avilable starting from QRIO3 Rev.2 */
+#define QRIO3_ID   0x71
+#define QRIO3_REV  0x02
+#define EBOOTCNT_OFF   0x28
+
+ulong early_bootcount_load(void)
+{
+   void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+   u16 id_rev = in_be16(qrio_base + ID_REV_OFF);
+   u8 id = (id_rev >> 8) & 0xff;
+   u8 rev = id_rev & 0xff;
+   u32 ebootcount = 0;
+
+   if (id == QRIO3_ID && rev >= QRIO3_REV) {
+   ebootcount = in_be32(qrio_base + EBOOTCNT_OFF);
+   } else {
+   printf("QRIO: warning: early bootcount not supported, ");
+   printf("id = %u, rev = %u\n", id, rev);
+   }
+
+   return ebootcount;
+}
+
+void early_bootcount_store(ulong ebootcount)
+{
+   void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+   u16 id_rev = in_be16(qrio_base + ID_REV_OFF);
+   u8 id = (id_rev >> 8) & 0xff;
+   u8 rev = id_rev & 0xff;
+
+   if (id == QRIO3_ID && rev >= QRIO3_REV) {
+   out_be32(qrio_base + EBOOTCNT_OFF, ebootcount);
+   } else {
+   printf("QRIO: warning: early bootcount not supported, ");
+   printf("id = %u, rev = %u\n", id, rev);
+   }
+}
+
 /* I2C deblocking uses the algorithm defined in board/keymile/common/common.c
  * 2 dedicated QRIO GPIOs externally pull the SCL and SDA lines
  * For I2C only the low state is activly driven and high state is pulled-up
-- 
1.8.3.1

[PATCH 04/18] km: qrio: add function to read PGY_PRES pin status

2021-11-16 Thread Aleksandar Gerasimovski

It is necessary to read the status of the PGY_PRES pin
so that u-boot can react accordingly.

Signed-off-by: Rainer Boschung 
Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/common/qrio.c | 13 +
 board/keymile/common/qrio.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/board/keymile/common/qrio.c b/board/keymile/common/qrio.c
index ed5e472..89a9726 100644
--- a/board/keymile/common/qrio.c
+++ b/board/keymile/common/qrio.c
@@ -40,6 +40,19 @@ bool qrio_get_selftest_pin(void)
return (slftest & 1) > 0;
 }
 
+#define BPRTH_OFF  0x04
+
+bool qrio_get_pgy_pres_pin(void)
+{
+   u8 pgy_pres;
+
+   void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+   pgy_pres = in_8(qrio_base + BPRTH_OFF);
+
+   return (pgy_pres & 0x80) > 0;
+}
+
 int qrio_get_gpio(u8 port_off, u8 gpio_nr)
 {
u32 gprt;
diff --git a/board/keymile/common/qrio.h b/board/keymile/common/qrio.h
index c341cd9..2b997d9 100644
--- a/board/keymile/common/qrio.h
+++ b/board/keymile/common/qrio.h
@@ -13,6 +13,7 @@
 
 void show_qrio(void);
 bool qrio_get_selftest_pin(void);
+bool qrio_get_pgy_pres_pin(void);
 int qrio_get_gpio(u8 port_off, u8 gpio_nr);
 void qrio_set_opendrain_gpio(u8 port_off, u8 gpio_nr, u8 val);
 void qrio_set_gpio(u8 port_off, u8 gpio_nr, bool value);
-- 
1.8.3.1

[PATCH 02/18] km: qrio: add function to read SLFTEST pin status

2021-11-16 Thread Aleksandar Gerasimovski

There is a request from HW designers to use this QRIO pin for detecting
DIC26_SELFTEST status instead of a GPIO pin.
This pin is typically used during production for executing POST tests and
starting test ESW bank.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/common/qrio.c | 13 +
 board/keymile/common/qrio.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/board/keymile/common/qrio.c b/board/keymile/common/qrio.c
index da51691..ed5e472 100644
--- a/board/keymile/common/qrio.c
+++ b/board/keymile/common/qrio.c
@@ -27,6 +27,19 @@ void show_qrio(void)
   (id_rev >> 8) & 0xff, id_rev & 0xff);
 }
 
+#define SLFTEST_OFF0x06
+
+bool qrio_get_selftest_pin(void)
+{
+   u8 slftest;
+
+   void __iomem *qrio_base = (void *)CONFIG_SYS_QRIO_BASE;
+
+   slftest = in_8(qrio_base + SLFTEST_OFF);
+
+   return (slftest & 1) > 0;
+}
+
 int qrio_get_gpio(u8 port_off, u8 gpio_nr)
 {
u32 gprt;
diff --git a/board/keymile/common/qrio.h b/board/keymile/common/qrio.h
index 757bcbf..c341cd9 100644
--- a/board/keymile/common/qrio.h
+++ b/board/keymile/common/qrio.h
@@ -12,6 +12,7 @@
 #define QRIO_GPIO_B0x60
 
 void show_qrio(void);
+bool qrio_get_selftest_pin(void);
 int qrio_get_gpio(u8 port_off, u8 gpio_nr);
 void qrio_set_opendrain_gpio(u8 port_off, u8 gpio_nr, u8 val);
 void qrio_set_gpio(u8 port_off, u8 gpio_nr, bool value);
-- 
1.8.3.1

[PATCH 03/18] km/ls102xa: use qrio selftest_pin for reading selftest

2021-11-16 Thread Aleksandar Gerasimovski

QRIO library now supports direct read of the test pin status.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c 
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index db49e8f..2be2b64 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -150,9 +150,8 @@ int ft_board_setup(void *blob, struct bd_info *bd)
 #if defined(CONFIG_POST)
 int post_hotkeys_pressed(void)
 {
-   /* DIC26_SELFTEST: GPRTA0, GPA0 */
-   qrio_gpio_direction_input(QRIO_GPIO_A, 0);
-   return qrio_get_gpio(QRIO_GPIO_A, 0);
+   /* DIC26_SELFTEST: QRIO, SLFTEST */
+   return qrio_get_selftest_pin();
 }
 
 ulong post_word_load(void)
-- 
1.8.3.1

[PATCH 08/18] km/ls102xa: add support for field fail-safe u-boot

2021-11-16 Thread Aleksandar Gerasimovski

Field fail-safe u-boot update procedure for pg-wcom boards is defined and
implemented by 59b3403.
This patch invokes the update procedure for pg-wcom-ls102x designs during
early misc_init_f execution.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 7 +++
 include/configs/km/pg-wcom-ls102xa.h| 2 ++
 2 files changed, 9 insertions(+)

diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c 
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index cff18dc..3dae423 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -109,6 +109,13 @@ int board_early_init_f(void)
return 0;
 }
 
+int misc_init_f(void)
+{
+   if (IS_ENABLED(CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED))
+   check_for_uboot_update();
+   return 0;
+}
+
 int board_init(void)
 {
if (IS_ENABLED(CONFIG_SYS_FSL_ERRATUM_A010315))
diff --git a/include/configs/km/pg-wcom-ls102xa.h 
b/include/configs/km/pg-wcom-ls102xa.h
index 743d09e..249bcef 100644
--- a/include/configs/km/pg-wcom-ls102xa.h
+++ b/include/configs/km/pg-wcom-ls102xa.h
@@ -280,4 +280,6 @@
 #define CONFIG_SYS_BOOTM_LEN   (64 << 20) /* Increase max gunzip size */
 #define CONFIG_SYS_BOOTMAPSZ   (256 << 20) /* Increase map for Linux */
 
+#define CONFIG_MISC_INIT_F
+
 #endif
-- 
1.8.3.1

[PATCH 14/18] configs/expu1: enable field fail-safe u-boot update

2021-11-16 Thread Aleksandar Gerasimovski

Field fail-safe u-boot update for pg-wcom-ls102x designs is introduced
with 81fb05e.

This patch enables already added support by:
 - Defining default u-boot build as bootpackage (factory) image.
 - Defining u-boot update image location according to the EXPU1 NOR layout.
 - Extending mtd partitions according defined EXPU1 NOR layout.

Signed-off-by: Aleksandar Gerasimovski 

---
 configs/pg_wcom_expu1_defconfig | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configs/pg_wcom_expu1_defconfig b/configs/pg_wcom_expu1_defconfig
index 9e8697d..0ff96e5 100644
--- a/configs/pg_wcom_expu1_defconfig
+++ b/configs/pg_wcom_expu1_defconfig
@@ -1,7 +1,10 @@
 CONFIG_ARM=y
 CONFIG_SKIP_LOWLEVEL_INIT=y
 CONFIG_TARGET_PG_WCOM_EXPU1=y
+CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED=y
+CONFIG_PG_WCOM_UBOOT_BOOTPACKAGE=y
 CONFIG_SYS_TEXT_BASE=0x6010
+CONFIG_PG_WCOM_UBOOT_UPDATE_TEXT_BASE=0x6024
 CONFIG_SYS_MALLOC_LEN=0x1004000
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_KM_DEF_NETDEV="eth2"
@@ -41,7 +44,7 @@ CONFIG_CMD_NAND_TRIMFFS=y
 CONFIG_CMD_CRAMFS=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nor0=6000.nor,nand0=6800.flash"
-CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),-(ubi0);6800.flash:-(ubi1)"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),128k(redenvred),128k(redenv),1m(redu-boot),-(ubi0);6800.flash:-(ubi1)"
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
-- 
1.8.3.1

Re: [PATCH RFC] cmd: fix net list command

2021-11-16 Thread Wolfgang Denk

Dear Michal,

In message  you wrote:
> 
> In perfect world u-boot will just get it and use. And if manufacturer 
> doesn't do it properly but want to enable ethernet in u-boot random 
> address could be a solution for them.
> And then in Linux where drivers are available you will use the right one.

You miss the point.  The whole argument is about who is control of
the system - can I as user do what I want, or are there some stupid
limitations in the system that prevent me from doing it.

But if the user of the system decides to use a specific MAC address
(for whatever reason ever), the software should just do what he
requests, and use this MAC address on no other one.  It is up to the
user to decide which is "the right one".

> But back to this patch. I think it is good that net list will show all 
> mac addresses even they are not saved in environment.

Agreed.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A girl with a future avoids the man with a past.
   -- Evan Esar, "The Humor of Humor"

[RFC] binman: add support for creating dummy files for external blobs

2021-11-16 Thread Heiko Thiery

While converting to binman for an imx8mq board, it has been found that
building in the u-boot CI fails. This is because an imx8mq requires an
external binary (signed_hdmi_imx8m.bin). If this file cannot be found
mkimage fails.
To be able to build this board in the u-boot CI a binman option
(--fake-ext-blobs) is introduced that can be switched on via the u-boot
makefile option BINMAN_FAKE_EXT_BLOBS. With that the needed dummy files are
created.

Signed-off-by: Heiko Thiery 
---
 Makefile   |  1 +
 tools/binman/cmdline.py|  2 ++
 tools/binman/control.py| 16 
 tools/binman/entry.py  |  1 +
 tools/binman/etype/blob_ext.py |  1 +
 5 files changed, 21 insertions(+)

diff --git a/Makefile b/Makefile
index f911f70344..1a833a1637 100644
--- a/Makefile
+++ b/Makefile
@@ -1307,6 +1307,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if 
$(BINMAN_DEBUG),-D) \
-a tpl-bss-pad=$(if $(CONFIG_TPL_SEPARATE_BSS),,1) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
-a tpl-dtb=$(CONFIG_SPL_OF_REAL) \
+   $(if $(BINMAN_FAKE_EXT_BLOBS),--fake-ext-blobs) \
$(BINMAN_$(@F))
 
 OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index d6156df408..2b29981cb4 100644
--- a/tools/binman/cmdline.py
+++ b/tools/binman/cmdline.py
@@ -52,6 +52,8 @@ controlled by a description in the board device tree.'''
 help='Configuration file (.dtb) to use')
 build_parser.add_argument('--fake-dtb', action='store_true',
 help='Use fake device tree contents (for testing only)')
+build_parser.add_argument('--fake-ext-blobs', action='store_true',
+help='Create fake ext blobs with dummy content (for testing only)')
 build_parser.add_argument('-i', '--image', type=str, action='append',
 help='Image filename to build (if not specified, build all)')
 build_parser.add_argument('-I', '--indir', action='append',
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 0dbcbc28e9..f95aadd1f3 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -8,6 +8,7 @@
 from collections import OrderedDict
 import glob
 import os
+import pathlib
 import pkg_resources
 import re
 
@@ -401,6 +402,17 @@ def ReplaceEntries(image_fname, input_fname, indir, 
entry_paths,
 return image
 
 
+def PrepareFakeExtBlobs(images):
+for (_, image) in images.items():
+for entry in image._entries.values():
+if entry.allow_dummy:
+if not pathlib.Path(entry._filename).is_file():
+tout.Warning("Missing external blob '%s', fake it" %
+ entry._filename)
+with open(entry._filename, "wb") as out:
+out.truncate(1024)
+
+
 def PrepareImagesAndDtbs(dtb_fname, select_images, update_fdt, use_expanded):
 """Prepare the images to be processed and select the device tree
 
@@ -629,6 +641,10 @@ def Binman(args):
 
 images = PrepareImagesAndDtbs(dtb_fname, args.image,
   args.update_fdt, use_expanded)
+
+if args.fake_ext_blobs:
+PrepareFakeExtBlobs(images)
+
 if args.test_section_timeout:
 # Set the first image to timeout, used in testThreadTimeout()
 images[list(images.keys())[0]].test_section_timeout = True
diff --git a/tools/binman/entry.py b/tools/binman/entry.py
index 70222718ea..2f5c38d15a 100644
--- a/tools/binman/entry.py
+++ b/tools/binman/entry.py
@@ -100,6 +100,7 @@ class Entry(object):
 self.missing = False
 self.external = False
 self.allow_missing = False
+self.allow_dummy = False
 
 @staticmethod
 def Lookup(node_path, etype, expanded):
diff --git a/tools/binman/etype/blob_ext.py b/tools/binman/etype/blob_ext.py
index d6b0ca17c3..85bc9fe6b8 100644
--- a/tools/binman/etype/blob_ext.py
+++ b/tools/binman/etype/blob_ext.py
@@ -26,3 +26,4 @@ class Entry_blob_ext(Entry_blob):
 def __init__(self, section, etype, node):
 Entry_blob.__init__(self, section, etype, node)
 self.external = True
+self.allow_dummy = True
-- 
2.30.2

Re: [PATCH v2 1/1] tpm: clear state post probing

2021-11-16 Thread Ilias Apalodimas

On Mon, Nov 15, 2021 at 08:30:06PM +0100, Heinrich Schuchardt wrote:
> Before we can start measuring the TPM must be cleared. Do this in the
> post_probe() method of the uclass.
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> v2:
>   tpm_startup2() is not available on all boards.
>   tpm_startup() takes care of translating the call.
> ---
>  drivers/tpm/tpm-uclass.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/tpm/tpm-uclass.c b/drivers/tpm/tpm-uclass.c
> index f67fe1019b..abd9ce35e8 100644
> --- a/drivers/tpm/tpm-uclass.c
> +++ b/drivers/tpm/tpm-uclass.c
> @@ -11,6 +11,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "tpm_internal.h"
> @@ -136,6 +137,17 @@ int tpm_xfer(struct udevice *dev, const uint8_t 
> *sendbuf, size_t send_size,
>   return 0;
>  }
>  
> +static int dm_tpm_post_probe(struct udevice *dev)
> +{
> + /*
> +  * Clearing the TPM state is only possible once after a hard reset.
> +  * As we do not know if the TPM has been cleared by a prior boot stage
> +  * ignore the return value here.
> +  */
> + tpm_startup(dev, TPM_ST_CLEAR);
> + return 0;
> +}
> +
>  UCLASS_DRIVER(tpm) = {
>   .id = UCLASS_TPM,
>   .name   = "tpm",
> @@ -143,5 +155,6 @@ UCLASS_DRIVER(tpm) = {
>  #if CONFIG_IS_ENABLED(OF_REAL)
>   .post_bind  = dm_scan_fdt_dev,
>  #endif
> + .post_probe = dm_tpm_post_probe,
>   .per_device_auto= sizeof(struct tpm_chip_priv),
>  };
> -- 
> 2.32.0
> 

Reviewed-by: Ilias Apalodimas

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Sahil Malhotra

This patch enables the DTB overlay feature for LS platforms.

Signed-off-by: Sahil Malhotra 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c  | 39 +++
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h  | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 12 ++
 .../cpu/armv8/fsl-layerscape/lowlevel_init.S  | 25 
 5 files changed, 87 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
 obj-y += soc.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 endif
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include 
+#include 
+#include 
+#include 
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+   int ret = 0;
+
+   /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+   if (!rom_pointer[0]) {
+   debug("No BL32_BASE passed means no TEE running\n");
+   return ret;
+   }
+
+   if (rom_pointer[2]) {
+   debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+   ret = fdt_check_header((void *)rom_pointer[2]);
+   if (ret == 0) {
+   /* Copy the fdt overlay to next 1M and use copied 
overlay */
+   memcpy((void *)(rom_pointer[2] + SZ_1M), (void 
*)rom_pointer[2],
+  fdt_totalsize((void *)rom_pointer[2]));
+   ret = fdt_overlay_apply_verbose(fdt, (void 
*)(rom_pointer[2] + SZ_1M));
+   if (ret == 0) {
+   debug("Overlay applied with success");
+   fdt_pack(fdt);
+   }
+   }
+   }
+   return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
 #endif
 #include 
 #include 
+#include "dt_optee.h"
 
 int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
 {
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
 #endif
 }
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+   return ft_add_optee_overlay(blob, bd);
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include 
+
+.align 8
+.global rom_pointer
+rom_pointer:
+   .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+   /* The firmware provided FDT address can be found in r2/x0 */
+   adr x0, rom_pointer
+   stp x1, x2, [x0], #16
+   stp x3, x4, [x0], #16
+
+   ldr x1, =save_boot_params_ret
+   br  x1
-- 
2.17.1

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

SoCs enabled for DTB Overlay features are:
LS1046A-RDB
LS1043A-RDB
LS1012A-RDB
LS1028A-RDB
LS1088A-RDB
LS2088A-RDB

Signed-off-by: Sahil Malhotra 
---
 configs/ls1012ardb_tfa_defconfig | 2 ++
 configs/ls1028ardb_tfa_defconfig | 1 +
 configs/ls1043ardb_tfa_defconfig | 2 ++
 configs/ls1046ardb_tfa_defconfig | 2 ++
 configs/ls1088ardb_tfa_defconfig | 2 ++
 configs/ls2088ardb_tfa_defconfig | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index c52359e51d..49ee762e38 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -69,3 +69,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index 8ce9da5b4f..b360427eb3 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_LS_HDP_LOAD=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig
index de3db3e2c4..a64df243f9 100644
--- a/configs/ls1043ardb_tfa_defconfig
+++ b/configs/ls1043ardb_tfa_defconfig
@@ -67,3 +67,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index e9e2efb210..55b6016e74 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -71,3 +71,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index 2e99e337c8..2351749d7d 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index de57235284..d1b6e7f7ae 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -89,3 +89,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
-- 
2.17.1

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

This patch enables the DTB overlay feature for LS platforms.

Signed-off-by: Sahil Malhotra 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c  | 39 +++
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h  | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 12 ++
 .../cpu/armv8/fsl-layerscape/lowlevel_init.S  | 25 
 5 files changed, 87 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
 obj-y += soc.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 endif
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include 
+#include 
+#include 
+#include 
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+   int ret = 0;
+
+   /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+   if (!rom_pointer[0]) {
+   debug("No BL32_BASE passed means no TEE running\n");
+   return ret;
+   }
+
+   if (rom_pointer[2]) {
+   debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+   ret = fdt_check_header((void *)rom_pointer[2]);
+   if (ret == 0) {
+   /* Copy the fdt overlay to next 1M and use copied 
overlay */
+   memcpy((void *)(rom_pointer[2] + SZ_1M), (void 
*)rom_pointer[2],
+  fdt_totalsize((void *)rom_pointer[2]));
+   ret = fdt_overlay_apply_verbose(fdt, (void 
*)(rom_pointer[2] + SZ_1M));
+   if (ret == 0) {
+   debug("Overlay applied with success");
+   fdt_pack(fdt);
+   }
+   }
+   }
+   return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
 #endif
 #include 
 #include 
+#include "dt_optee.h"
 
 int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
 {
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
 #endif
 }
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+   return ft_add_optee_overlay(blob, bd);
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include 
+
+.align 8
+.global rom_pointer
+rom_pointer:
+   .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+   /* The firmware provided FDT address can be found in r2/x0 */
+   adr x0, rom_pointer
+   stp x1, x2, [x0], #16
+   stp x3, x4, [x0], #16
+
+   ldr x1, =save_boot_params_ret
+   br  x1
-- 
2.17.1

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

This patch enables the DTB overlay feature for LS platforms.

Signed-off-by: Sahil Malhotra 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c  | 39 +++
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h  | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 12 ++
 .../cpu/armv8/fsl-layerscape/lowlevel_init.S  | 25 
 5 files changed, 87 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
 obj-y += soc.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 endif
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include 
+#include 
+#include 
+#include 
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+   int ret = 0;
+
+   /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+   if (!rom_pointer[0]) {
+   debug("No BL32_BASE passed means no TEE running\n");
+   return ret;
+   }
+
+   if (rom_pointer[2]) {
+   debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+   ret = fdt_check_header((void *)rom_pointer[2]);
+   if (ret == 0) {
+   /* Copy the fdt overlay to next 1M and use copied 
overlay */
+   memcpy((void *)(rom_pointer[2] + SZ_1M), (void 
*)rom_pointer[2],
+  fdt_totalsize((void *)rom_pointer[2]));
+   ret = fdt_overlay_apply_verbose(fdt, (void 
*)(rom_pointer[2] + SZ_1M));
+   if (ret == 0) {
+   debug("Overlay applied with success");
+   fdt_pack(fdt);
+   }
+   }
+   }
+   return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
 #endif
 #include 
 #include 
+#include "dt_optee.h"
 
 int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
 {
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
 #endif
 }
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+   return ft_add_optee_overlay(blob, bd);
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include 
+
+.align 8
+.global rom_pointer
+rom_pointer:
+   .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+   /* The firmware provided FDT address can be found in r2/x0 */
+   adr x0, rom_pointer
+   stp x1, x2, [x0], #16
+   stp x3, x4, [x0], #16
+
+   ldr x1, =save_boot_params_ret
+   br  x1
-- 
2.17.1

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

SoCs enabled for DTB Overlay features are:
LS1046A-RDB
LS1043A-RDB
LS1012A-RDB
LS1028A-RDB
LS1088A-RDB
LS2088A-RDB

Signed-off-by: Sahil Malhotra 
---
 configs/ls1012ardb_tfa_defconfig | 2 ++
 configs/ls1028ardb_tfa_defconfig | 1 +
 configs/ls1043ardb_tfa_defconfig | 2 ++
 configs/ls1046ardb_tfa_defconfig | 2 ++
 configs/ls1088ardb_tfa_defconfig | 2 ++
 configs/ls2088ardb_tfa_defconfig | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index c52359e51d..49ee762e38 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -69,3 +69,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index 8ce9da5b4f..b360427eb3 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_LS_HDP_LOAD=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig
index de3db3e2c4..a64df243f9 100644
--- a/configs/ls1043ardb_tfa_defconfig
+++ b/configs/ls1043ardb_tfa_defconfig
@@ -67,3 +67,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index e9e2efb210..55b6016e74 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -71,3 +71,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index 2e99e337c8..2351749d7d 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index de57235284..d1b6e7f7ae 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -89,3 +89,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
-- 
2.17.1

[PATCH 10/18] configs/seli8: add u-boot update defconfig

2021-11-16 Thread Aleksandar Gerasimovski

This patch adds default defconfig for u-boot update version, the u-boot
update defconfig is a copy of the default (factory) defconfig with:
- adapted text base and environment addresses
- explicit flag that this is a field updated u-boot version

At the time of implementation this version is only used to verify the
update procedure, in future depend on the needs this defconfig can be
extended with additional options.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/MAINTAINERS |  1 +
 configs/pg_wcom_seli8_update_defconfig| 83 +++
 2 files changed, 84 insertions(+)
 create mode 100644 configs/pg_wcom_seli8_update_defconfig

diff --git a/board/keymile/pg-wcom-ls102xa/MAINTAINERS 
b/board/keymile/pg-wcom-ls102xa/MAINTAINERS
index 966c88b..9fabad1 100644
--- a/board/keymile/pg-wcom-ls102xa/MAINTAINERS
+++ b/board/keymile/pg-wcom-ls102xa/MAINTAINERS
@@ -7,6 +7,7 @@ F:  include/configs/km/pg-wcom-ls102xa.h
 F: include/configs/pg-wcom-seli8.h
 F: include/configs/pg-wcom-expu1.h
 F: configs/pg_wcom_seli8_defconfig
+F: configs/pg_wcom_seli8_update_defconfig
 F: configs/pg_wcom_expu1_defconfig
 F: arch/arm/dts/ls1021a-pg-wcom-seli8.dts
 F: arch/arm/dts/ls1021a-pg-wcom-expu1.dts
diff --git a/configs/pg_wcom_seli8_update_defconfig 
b/configs/pg_wcom_seli8_update_defconfig
new file mode 100644
index 000..fb5b715
--- /dev/null
+++ b/configs/pg_wcom_seli8_update_defconfig
@@ -0,0 +1,83 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_TARGET_PG_WCOM_SELI8=y
+CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED=y
+CONFIG_PG_WCOM_UBOOT_UPDATE=y
+CONFIG_SYS_TEXT_BASE=0x6024
+CONFIG_SYS_MALLOC_LEN=0x1004000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_KM_DEF_NETDEV="eth2"
+CONFIG_KM_COMMON_ETH_INIT=y
+CONFIG_PIGGY_MAC_ADDRESS_OFFSET=3
+CONFIG_SYS_MEMTEST_START=0x8000
+CONFIG_SYS_MEMTEST_END=0x9fff
+CONFIG_ENV_SIZE=0x4000
+CONFIG_ENV_SECT_SIZE=0x2
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-pg-wcom-seli8"
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_ADDR=0x7020
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_BOOTDELAY=3
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_AUTOBOOT_PROMPT="Hit  key to stop autoboot in %2ds\n"
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0"
+CONFIG_SILENT_CONSOLE=y
+CONFIG_LAST_STAGE_INIT=y
+CONFIG_MISC_INIT_R=y
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_CRAMFS=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nor0=6000.nor,nand0=6800.flash"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),128k(redenvred),128k(redenv),1m(redu-boot),-(ubi0);6800.flash:-(ubi1)"
+CONFIG_CMD_UBI=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+CONFIG_ENV_ADDR=0x6022
+CONFIG_ENV_ADDR_REDUND=0x6020
+CONFIG_DM=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_DDR_CLK_FREQ=5000
+CONFIG_SYS_FSL_DDR3=y
+CONFIG_SYS_I2C_LEGACY=y
+# CONFIG_MMC is not set
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_MTD_RAW_NAND=y
+CONFIG_NAND_FSL_IFC=y
+CONFIG_SYS_NAND_ONFI_DETECTION=y
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_PHY_GIGE=y
+CONFIG_MII=y
+CONFIG_TSEC_ENET=y
+CONFIG_SYS_QE_FW_ADDR=0x6002
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_VERSION_VARIABLE=y
-- 
1.8.3.1

[PATCH 16/18] arm/expu1/seli8: adapt dts NOR partition table to the latest used

2021-11-16 Thread Aleksandar Gerasimovski

Even not used by u-boot, this has to be inline with the hw and kernel dts.
U-boot partition table is defined by MTDPARTS_DEFAULT Kconfig.

Signed-off-by: Aleksandar Gerasimovski 

---
 arch/arm/dts/ls1021a-pg-wcom-expu1.dts | 15 +--
 arch/arm/dts/ls1021a-pg-wcom-seli8.dts | 14 +-
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/arch/arm/dts/ls1021a-pg-wcom-expu1.dts 
b/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
index 33456b7..ec8e7de 100644
--- a/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
+++ b/arch/arm/dts/ls1021a-pg-wcom-expu1.dts
@@ -87,7 +87,6 @@
label = "qe";
reg = <0x2 0x2>;
};
-   /* ZL30343 init data to be added here */
partition@4 {
label = "envred";
reg = <0x4 0x2>;
@@ -101,8 +100,20 @@
reg = <0x10 0x10>;
};
partition@20 {
+   label = "redenvred";
+   reg = <0x20 0x2>;
+   };
+   partition@22 {
+   label = "redenv";
+   reg = <0x22 0x2>;
+   };
+   partition@24 {
+   label = "redu-boot";
+   reg = <0x24 0x10>;
+   };
+   partition@34 {
label = "ubi0";
-   reg = <0x20 0x3E0>;
+   reg = <0x34 0x03C0>;
};
};
 };
diff --git a/arch/arm/dts/ls1021a-pg-wcom-seli8.dts 
b/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
index f2cadd7..03ce3ab 100644
--- a/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
+++ b/arch/arm/dts/ls1021a-pg-wcom-seli8.dts
@@ -83,8 +83,20 @@
reg = <0x10 0x10>;
};
partition@20 {
+   label = "redenvred";
+   reg = <0x20 0x2>;
+   };
+   partition@22 {
+   label = "redenv";
+   reg = <0x22 0x2>;
+   };
+   partition@24 {
+   label = "redu-boot";
+   reg = <0x24 0x10>;
+   };
+   partition@34 {
label = "ubi0";
-   reg = <0x20 0x3E0>;
+   reg = <0x34 0x03C0>;
};
};
 };
-- 
1.8.3.1

Re: [PATCH RFC] cmd: fix net list command

2021-11-16 Thread Wolfgang Denk

Dear Ramon,

In message  
you wrote:
>
> It appears that Michael has some board and a scenario that *this* bug
> was working for his best interest, where he can have two distinct MAC
> addresses, one in U-boot and one in Linux.

If the Linux environment is supposed to be a specific MAC address
(which may be different from the one passed by U-Boot), then there
are standard tools available to set the address.  I don't see a
problem here.

> Mark and I already provided work around for Michael to delete the
> environment variable before he boots. or implement the necessary OTP
> driver in U-Boot.

As Marek pointed out, in this specific case it would be best to
provide such a driver.

> From my end, I think we can conclude the discussion.

ACK.

Thanks.

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
My challenge to the goto-less programmer  is  to  recode  tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch). - W. R. Stevens

Re: [PATCH 1/1] pxe: simplify label_boot()

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 03:09:58PM +0800, Art Nikpal wrote:
> On Tue, Nov 16, 2021 at 2:26 AM Heinrich Schuchardt
>  wrote:
> >
> > Coverity CID 131256 indicates a possible buffer overflow in label_boot().
> > This would only occur if the size of the downloaded file would exceed 4
> > GiB. But anyway we can simplify the code by using snprintf() and checking
> > the return value.
> >
> > Signed-off-by: Heinrich Schuchardt 
> > ---
> >  boot/pxe_utils.c | 9 -
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
> > index a7a84f26c1..5841561bdf 100644
> > --- a/boot/pxe_utils.c
> > +++ b/boot/pxe_utils.c
> > @@ -465,11 +465,10 @@ static int label_boot(struct pxe_context *ctx, struct 
> > pxe_label *label)
> > }
> >
> > initrd_addr_str = env_get("ramdisk_addr_r");
> > -   strcpy(initrd_filesize, simple_xtoa(size));
> > -
> > -   strncpy(initrd_str, initrd_addr_str, 18);
> > -   strcat(initrd_str, ":");
> > -   strncat(initrd_str, initrd_filesize, 9);
> > +   size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
> > +   initrd_addr_str, size);
> > +   if (size >= sizeof(initrd_str))
> > +   return 1;
> > }
> >
> > if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
> 
> Reviewed-by: Artem Lapkin 

Thanks for the review everyone and thanks for the patch Heinrich.  It
looks like in the kernel the new'ish standard tag is:
Addresses-Coverity-ID: 131256 ("Security best practices violations")
and then not need to mention Coverity in the main message.  I'll fix
things up slightly when applying.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Hi Tom,

On 11/16/21 10:13 AM, Tom Rini wrote:
> On Tue, Nov 16, 2021 at 08:37:06AM -0300, Fabio Estevam wrote:
>> Hi Ariel,
>>
>> The patch looks good. Only some minor comments:
>>
>> On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro
>>  wrote:
>>>
>>> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
>>>
>>> - 1GiB DDR4 RAM
>>> - 16 GiB eMMC
>>> - SD card
>>> - Gigabit ethernet
>>> - USBOTG1 peripheral - fastboot
>>>
>>> Signed-off-by: Ariel D'Alessandro 
>>
>> It would be nice to have a README file so that the users can know how
>> to build and flash mainline
>> U-Boot in this board.
> 
> And that means an entry under doc/board/variscite/ to be clear.

Yes :-) thanks, will add it in v4.

Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Fabio Estevam

Hi Ariel,

The patch looks good. Only some minor comments:

On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro
 wrote:
>
> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
>
> - 1GiB DDR4 RAM
> - 16 GiB eMMC
> - SD card
> - Gigabit ethernet
> - USBOTG1 peripheral - fastboot
>
> Signed-off-by: Ariel D'Alessandro 

It would be nice to have a README file so that the users can know how
to build and flash mainline
U-Boot in this board.

> +#define PHYS_SDRAM 0x4000
> +#define PHYS_SDRAM_SIZESZ_1G /* 1GB DDR */
> +
> +#define CONFIG_BAUDRATE115200

This is the default. No need to be specified here.

> +#define CONFIG_MXC_UART_BASE   UART4_BASE_ADDR
> +
> +/* Monitor Command Prompt */
> +#define CONFIG_SYS_CBSIZE  SZ_2K
> +#define CONFIG_SYS_MAXARGS 64
> +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
> +#define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + \
> +sizeof(CONFIG_SYS_PROMPT) + 16)
> +
> +/* USDHC */
> +#define CONFIG_FSL_USDHC

This should be placed in defconfig.

> +#define CONFIG_SYS_FSL_USDHC_NUM   2

This is not used. Please remove it.

RE: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation

2021-11-16 Thread Gaurav Jain

Hi

> -Original Message-
> From: Michael Walle 
> Sent: Tuesday, November 16, 2021 4:53 PM
> To: Gaurav Jain 
> Cc: Shengzhou Liu ; Varun Sethi
> ; Adrian Alonso ; Alison Wang
> ; Andy Tang ;
> feste...@gmail.com; Franck Lenormand ;
> Horia Geanta ; Ji Luo ;
> Meenakshi Aggarwal ; Mingkai Hu
> ; olte...@gmail.com; Pankaj Gupta
> ; Peng Fan ; Pramod Kumar
> ; Priyanka Jain ;
> Rajesh Bhagat ; Sahil Malhotra
> ; sba...@denx.de; Silvano Di Ninno
> ; s...@chromium.org; u-boot@lists.denx.de; dl-
> uboot-imx ; Wasim Khan ;
> Ye Li 
> Subject: Re: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for
> bkek, random number generation
> 
> Caution: EXT Email
> 
> Hi,
> 
> Am 2021-11-16 12:09, schrieb Gaurav Jain:
> >> > --- a/drivers/crypto/fsl/fsl_blob.c
> >> > +++ b/drivers/crypto/fsl/fsl_blob.c
> >> > @@ -1,6 +1,7 @@
> >> >  // SPDX-License-Identifier: GPL-2.0+
> >> >  /*
> >> >   * Copyright 2014 Freescale Semiconductor, Inc.
> >> > + * Copyright 2021 NXP
> >> >   *
> >> >   */
> >> >
> >> > @@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst,
> >> u32 len)
> >> >   return ret;
> >> >  }
> >> >
> >> > +int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)
> >>
> >> where is this function actually used? looks like dead code to me.
> >
> > I was thinking to add the command for this function later.
> > But will remove this patch from this series and send this later with
> > derive blob kek cmd implementation.
> 
> ok, but you've missed the question below.
> 
> >>
> >> > +{
> >> > + int ret, size;
> >> > + u32 *desc;
> >> > +
> >> > + if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
> >> > + !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
> >> > + puts("Error: derive_bkek: Address arguments are not
> aligned!\n");
> >> > + return -EINVAL;
> >> > + }
> >> > +
> >> > + printf("\nBlob key encryption key(bkek)\n");
> >> > + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> >> > + if (!desc) {
> >> > + printf("Not enough memory for descriptor allocation\n");
> >> > + return -ENOMEM;
> >> > + }
> >> > +
> >> > + size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
> >> > + flush_dcache_range((unsigned long)key_mod, (unsigned
> >> > + long)key_mod + size);
> >> > +
> >> > + /* construct blob key encryption key(bkek) derive descriptor */
> >> > + inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod,
> >> > + key_sz);
> >> > +
> >> > + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE,
> >> ARCH_DMA_MINALIGN);
> >> > + flush_dcache_range((unsigned long)desc, (unsigned long)desc +
> size);
> >> > + size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
> >> > + invalidate_dcache_range((unsigned long)bkek_buf,
> >> > + (unsigned long)bkek_buf + size);
> >> > +
> >> > + /* run descriptor */
> >> > + ret = run_descriptor_jr(desc);
> >> > + if (ret < 0) {
> >> > + printf("Error: %s failed 0x%x\n", __func__, ret);
> >> > + } else {
> >> > + invalidate_dcache_range((unsigned long)bkek_buf,
> >> > + (unsigned long)bkek_buf + size);
> >> > + puts("derive bkek successful.\n");
> >> > + }
> >> > +
> >> > + free(desc);
> >> > + return ret;
> >> > +}
> >> > +
> >> > +int hwrng_generate(u8 *dst, u32 len)
> >>
> >> likewise.
> >> But more important what is the difference to drivers/crypto/fsl/rng.c?
> >> Why
> >> do you need a new function here?
> 
> This one. Why can't you reuse the code which is already there?

I might have missed to update this.
dm_rng_read() can be used. Will remove hwrng_generate().

Regards
Gaurav Jain
> 
> -michael

[PATCH 2/2] configs: enabled DTB overlay feature for LS SoCs

2021-11-16 Thread Sahil Malhotra

SoCs enabled for DTB Overlay features are:
LS1046A-RDB
LS1043A-RDB
LS1012A-RDB
LS1028A-RDB
LS1088A-RDB
LS2088A-RDB

Signed-off-by: Sahil Malhotra 
---
 configs/ls1012ardb_tfa_defconfig | 2 ++
 configs/ls1028ardb_tfa_defconfig | 1 +
 configs/ls1043ardb_tfa_defconfig | 2 ++
 configs/ls1046ardb_tfa_defconfig | 2 ++
 configs/ls1088ardb_tfa_defconfig | 2 ++
 configs/ls2088ardb_tfa_defconfig | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index c52359e51d..49ee762e38 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -69,3 +69,5 @@ CONFIG_USB=y
 CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig
index 8ce9da5b4f..b360427eb3 100644
--- a/configs/ls1028ardb_tfa_defconfig
+++ b/configs/ls1028ardb_tfa_defconfig
@@ -95,3 +95,4 @@ CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
 CONFIG_VIDEO=y
 CONFIG_VIDEO_LS_HDP_LOAD=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1043ardb_tfa_defconfig b/configs/ls1043ardb_tfa_defconfig
index de3db3e2c4..a64df243f9 100644
--- a/configs/ls1043ardb_tfa_defconfig
+++ b/configs/ls1043ardb_tfa_defconfig
@@ -67,3 +67,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index e9e2efb210..55b6016e74 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -71,3 +71,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls1088ardb_tfa_defconfig b/configs/ls1088ardb_tfa_defconfig
index 2e99e337c8..2351749d7d 100644
--- a/configs/ls1088ardb_tfa_defconfig
+++ b/configs/ls1088ardb_tfa_defconfig
@@ -94,3 +94,5 @@ CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
 CONFIG_USB_ETHER_RTL8152=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index de57235284..d1b6e7f7ae 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -89,3 +89,5 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_SYSTEM_SETUP=y
-- 
2.17.1

board_init.c file not compiled

2021-11-16 Thread Chan Kim

Hello all,

I'm new to u-boot and having difficulty while trying to build u-boot for our
test board.(arm64, armv8)

I wanted to try the "SPL falcon" mode". The DDR is not ready yet in the
board. 

A small scp chip(cortex-M7) will initialize clk and will load
kernel(including initramfs), dtb, u-boot-spl, images to a small internal
RAM.

And the AP chip will start from the u-boot-spl. (I know some low-level init
can be skipped)

I added SPL related config settings and ran this command.

make CROSS_COMPILE=aarch64-none-elf- ab21m_defconfig

make CROSS_COMPILE=aarch64-none-elf-

I see "u-boot/arch/arm/lib/crt0_64.S:88: undefined reference to
`board_init_f_alloc_reserve'" error during the u-boot build. (not related to
SPL).

By comparing the build process with that of rk3036 board (arm board with
SUPPORT_SPL, no SUPPORT_TPL), I found in my case even common/board_init.c is
not compiled.

Where should I look? I'm reading the documents or build scripts here and
there but can't figure it out.

Thank you.

Chan Kim

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Sahil Malhotra

From: Sahil Malhotra 

This patch enables the DTB overlay feature for LS platforms.

Signed-off-by: Sahil Malhotra 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c  | 39 +++
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h  | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 12 ++
 .../cpu/armv8/fsl-layerscape/lowlevel_init.S  | 25 
 5 files changed, 87 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
 obj-y += soc.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 endif
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include 
+#include 
+#include 
+#include 
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+   int ret = 0;
+
+   /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+   if (!rom_pointer[0]) {
+   debug("No BL32_BASE passed means no TEE running\n");
+   return ret;
+   }
+
+   if (rom_pointer[2]) {
+   debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+   ret = fdt_check_header((void *)rom_pointer[2]);
+   if (ret == 0) {
+   /* Copy the fdt overlay to next 1M and use copied 
overlay */
+   memcpy((void *)(rom_pointer[2] + SZ_1M), (void 
*)rom_pointer[2],
+  fdt_totalsize((void *)rom_pointer[2]));
+   ret = fdt_overlay_apply_verbose(fdt, (void 
*)(rom_pointer[2] + SZ_1M));
+   if (ret == 0) {
+   debug("Overlay applied with success");
+   fdt_pack(fdt);
+   }
+   }
+   }
+   return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
 #endif
 #include 
 #include 
+#include "dt_optee.h"
 
 int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
 {
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
 #endif
 }
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+   return ft_add_optee_overlay(blob, bd);
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include 
+
+.align 8
+.global rom_pointer
+rom_pointer:
+   .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+   /* The firmware provided FDT address can be found in r2/x0 */
+   adr x0, rom_pointer
+   stp x1, x2, [x0], #16
+   stp x3, x4, [x0], #16
+
+   ldr x1, =save_boot_params_ret
+   br  x1
-- 
2.17.1

[PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Sahil Malhotra

This patch enables the DTB overlay feature for LS platforms.

Signed-off-by: Sahil Malhotra 
---
 arch/arm/cpu/armv8/fsl-layerscape/Makefile|  1 +
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c  | 39 +++
 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h  | 10 +
 arch/arm/cpu/armv8/fsl-layerscape/fdt.c   | 12 ++
 .../cpu/armv8/fsl-layerscape/lowlevel_init.S  | 25 
 5 files changed, 87 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 598c36ee66..97f1f291dd 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -7,6 +7,7 @@ obj-y += lowlevel.o
 obj-y += soc.o
 ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_MP) += mp.o spintable.o
+obj-$(CONFIG_OF_LIBFDT_OVERLAY) += lowlevel_init.o dt_optee.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
 endif
 obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
new file mode 100644
index 00..2418ad09c7
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 NXP
+ */
+#include 
+#include 
+#include 
+#include 
+#include "dt_optee.h"
+
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd)
+{
+   int ret = 0;
+
+   /*
+* No BL32_BASE passed means no TEE running, so no
+* need to add optee node in dts
+*/
+   if (!rom_pointer[0]) {
+   debug("No BL32_BASE passed means no TEE running\n");
+   return ret;
+   }
+
+   if (rom_pointer[2]) {
+   debug("OP-TEE: applying overlay on 0x%lx\n", rom_pointer[2]);
+   ret = fdt_check_header((void *)rom_pointer[2]);
+   if (ret == 0) {
+   /* Copy the fdt overlay to next 1M and use copied 
overlay */
+   memcpy((void *)(rom_pointer[2] + SZ_1M), (void 
*)rom_pointer[2],
+  fdt_totalsize((void *)rom_pointer[2]));
+   ret = fdt_overlay_apply_verbose(fdt, (void 
*)(rom_pointer[2] + SZ_1M));
+   if (ret == 0) {
+   debug("Overlay applied with success");
+   fdt_pack(fdt);
+   }
+   }
+   }
+   return ret;
+}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h 
b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
new file mode 100644
index 00..d1ff25d531
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/dt_optee.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+#ifndef __DT_OPTEE_H__
+#define __DT_OPTEE_H__
+
+extern unsigned long rom_pointer[];
+int ft_add_optee_overlay(void *fdt, struct bd_info *bd);
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index f1624ff30a..0824c62264 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -31,6 +31,7 @@
 #endif
 #include 
 #include 
+#include "dt_optee.h"
 
 int fdt_fixup_phy_connection(void *blob, int offset, phy_interface_t phyc)
 {
@@ -698,3 +699,14 @@ void ft_cpu_setup(void *blob, struct bd_info *bd)
fdt_fixup_ecam(blob);
 #endif
 }
+
+#ifdef CONFIG_OF_SYSTEM_SETUP
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+#ifdef CONFIG_OF_LIBFDT_OVERLAY
+   return ft_add_optee_overlay(blob, bd);
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
new file mode 100644
index 00..1d6a2d85fa
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel_init.S
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2021 NXP
+ */
+
+#include 
+
+.align 8
+.global rom_pointer
+rom_pointer:
+   .space 32
+
+/*
+ * Routine: save_boot_params (called after reset from start.S)
+ */
+
+.global save_boot_params
+save_boot_params:
+   /* The firmware provided FDT address can be found in r2/x0 */
+   adr x0, rom_pointer
+   stp x1, x2, [x0], #16
+   stp x3, x4, [x0], #16
+
+   ldr x1, =save_boot_params_ret
+   br  x1
-- 
2.17.1

[PATCH 11/18] km/ls102xa: fix device disable configuration

2021-11-16 Thread Aleksandar Gerasimovski

This was probably broken when mainlining, CONFIG_FSL_DEVICE_DISABLE is
not Kconfig but whitelisted.

It's fine to be without flag as this is always enabled for abec1020
(pg-wcom-ls102xa.h)

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c 
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index 3dae423..a37d111 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -137,8 +137,7 @@ int board_late_init(void)
 
 int misc_init_r(void)
 {
-   if (IS_ENABLED(CONFIG_FSL_DEVICE_DISABLE))
-   device_disable(devdis_tbl, ARRAY_SIZE(devdis_tbl));
+   device_disable(devdis_tbl, ARRAY_SIZE(devdis_tbl));
 
ivm_read_eeprom(ivm_content, CONFIG_SYS_IVM_EEPROM_MAX_LEN,
CONFIG_PIGGY_MAC_ADDRESS_OFFSET);
-- 
1.8.3.1

[PATCH 12/18] configs: seli8: enable ver envvar for version_string

2021-11-16 Thread Aleksandar Gerasimovski

This is used by out ESW for reading u-boot build version.

Signed-off-by: Aleksandar Gerasimovski 

---
 configs/pg_wcom_seli8_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/pg_wcom_seli8_defconfig b/configs/pg_wcom_seli8_defconfig
index cb7c680..f13cc55 100644
--- a/configs/pg_wcom_seli8_defconfig
+++ b/configs/pg_wcom_seli8_defconfig
@@ -78,3 +78,4 @@ CONFIG_SYS_QE_FW_ADDR=0x6002
 CONFIG_SPECIFY_CONSOLE_INDEX=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
+CONFIG_VERSION_VARIABLE=y
-- 
1.8.3.1

[PATCH 18/18] km/ls102xa: use unused scratchrw4 address for post word

2021-11-16 Thread Aleksandar Gerasimovski

The SCRATCHRW4 is only used in secure boot scenario that is unsupported by
our design, so this address can be stolen for storing POST status.
The SCRATCHRW4 is initialized to zero at core rest.

Using a DDR address was unfortunate choice, the DDR at boot time has a
random contend and it happens that sometimes is matching POST magic number.
This behavior can lead to undefined POST behavior and u-boot ending in
failbootcmd command.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c 
b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
index a37d111..467f110 100644
--- a/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
+++ b/board/keymile/pg-wcom-ls102xa/pg-wcom-ls102xa.c
@@ -162,19 +162,18 @@ int post_hotkeys_pressed(void)
return qrio_get_selftest_pin();
 }
 
+/* POST word is located in the unused SCRATCHRW4 register */
+#define CCSR_SCRATCHRW4_ADDR   0x1ee020c
+
 ulong post_word_load(void)
 {
-   /* POST word is located at the beginning of reserved physical RAM */
-   void *addr = (void *)(CONFIG_SYS_SDRAM_BASE +
-   gd->ram_size - CONFIG_KM_RESERVED_PRAM + 8);
+   void *addr = (void *)CCSR_SCRATCHRW4_ADDR;
return in_le32(addr);
 }
 
 void post_word_store(ulong value)
 {
-   /* POST word is located at the beginning of reserved physical RAM */
-   void *addr = (void *)(CONFIG_SYS_SDRAM_BASE +
-   gd->ram_size - CONFIG_KM_RESERVED_PRAM + 8);
+   void *addr = (void *)CCSR_SCRATCHRW4_ADDR;
out_le32(addr, value);
 }
 
-- 
1.8.3.1

Re: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

2021-11-16 Thread Michael Walle

> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 5b30b13e43..2b24672505 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2009,6 +2009,7 @@ config CMD_AES
>  
>  config CMD_BLOB
>   bool "Enable the 'blob' command"
> + select FSL_BLOB

this looks wrong, because CMD_BLOB sounds like a generic command but it
will automatically select FSL_BLOB which in turn sounds freescale specific.
Looking at the help text, this command is (at least at the moment) freescale
specific, but the code seems to be generic and the blob_encap() and
blob_decap() are weak functions, thus they could be implemented in a
different way and not just by fsl_blob.c.

I don't think this should automatically select FSL_BLOB.

Also, shouldn't this be an uclass with encap and decap ops?

>   depends on !MX6ULL && !MX6SLL && !MX6SL
>   select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M
>   help
> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
> index 94ff540111..ab59d516f8 100644
> --- a/drivers/crypto/fsl/Kconfig
> +++ b/drivers/crypto/fsl/Kconfig
> @@ -66,4 +66,11 @@ config FSL_CAAM_RNG
> using the prediction resistance flag which means the DRGB is
> reseeded from the TRNG every time random data is generated.
>  
> +config FSL_BLOB
> +bool "Enable Blob Encap/Decap, Blob KEK support"

wrong indendation?

> + help
> +   Enable support for the hardware based crytographic blob encap/decap
> +   module of the CAAM. blobs can be safely placed into non-volatile
> +   storage. blobs can only be decapsulated by the SoC that created it.
> +   Enable support for blob key encryption key generation.
>  endif

RE: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek, random number generation

2021-11-16 Thread Gaurav Jain

Hello Michael,

> -Original Message-
> From: Michael Walle 
> Sent: Tuesday, November 16, 2021 4:16 PM
> To: Gaurav Jain 
> Cc: Shengzhou Liu ; Varun Sethi
> ; Adrian Alonso ; Alison Wang
> ; Andy Tang ;
> feste...@gmail.com; Franck Lenormand ;
> Horia Geanta ; Ji Luo ;
> Meenakshi Aggarwal ; Mingkai Hu
> ; olte...@gmail.com; Pankaj Gupta
> ; Peng Fan ; Pramod Kumar
> ; Priyanka Jain ;
> Rajesh Bhagat ; Sahil Malhotra
> ; sba...@denx.de; Silvano Di Ninno
> ; s...@chromium.org; u-boot@lists.denx.de; dl-
> uboot-imx ; Wasim Khan ;
> Ye Li ; Michael Walle 
> Subject: [EXT] Re: [PATCH v5 02/16] crypto/fsl: Add CAAM support for bkek,
> random number generation
> 
> Caution: EXT Email
> 
> Hi,
> 
> > --- a/drivers/crypto/fsl/fsl_blob.c
> > +++ b/drivers/crypto/fsl/fsl_blob.c
> > @@ -1,6 +1,7 @@
> >  // SPDX-License-Identifier: GPL-2.0+
> >  /*
> >   * Copyright 2014 Freescale Semiconductor, Inc.
> > + * Copyright 2021 NXP
> >   *
> >   */
> >
> > @@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst,
> u32 len)
> >   return ret;
> >  }
> >
> > +int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)
> 
> where is this function actually used? looks like dead code to me.

I was thinking to add the command for this function later.
But will remove this patch from this series and send this later with derive 
blob kek cmd implementation.

Regards
Gaurav Jain
> 
> > +{
> > + int ret, size;
> > + u32 *desc;
> > +
> > + if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
> > + !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
> > + puts("Error: derive_bkek: Address arguments are not 
> > aligned!\n");
> > + return -EINVAL;
> > + }
> > +
> > + printf("\nBlob key encryption key(bkek)\n");
> > + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> > + if (!desc) {
> > + printf("Not enough memory for descriptor allocation\n");
> > + return -ENOMEM;
> > + }
> > +
> > + size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
> > + flush_dcache_range((unsigned long)key_mod, (unsigned
> > + long)key_mod + size);
> > +
> > + /* construct blob key encryption key(bkek) derive descriptor */
> > + inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod,
> > + key_sz);
> > +
> > + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE,
> ARCH_DMA_MINALIGN);
> > + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> > + size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
> > + invalidate_dcache_range((unsigned long)bkek_buf,
> > + (unsigned long)bkek_buf + size);
> > +
> > + /* run descriptor */
> > + ret = run_descriptor_jr(desc);
> > + if (ret < 0) {
> > + printf("Error: %s failed 0x%x\n", __func__, ret);
> > + } else {
> > + invalidate_dcache_range((unsigned long)bkek_buf,
> > + (unsigned long)bkek_buf + size);
> > + puts("derive bkek successful.\n");
> > + }
> > +
> > + free(desc);
> > + return ret;
> > +}
> > +
> > +int hwrng_generate(u8 *dst, u32 len)
> 
> likewise.
> But more important what is the difference to drivers/crypto/fsl/rng.c? Why
> do you need a new function here?
> 
> > +{
> > + int ret, size;
> > + u32 *desc;
> > +
> > + if (!IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
> > + puts("Error: caam_hwrng_test: Address arguments are not
> aligned!\n");
> > + return -EINVAL;
> > + }
> > +
> > + printf("\nRNG generate\n");
> > + desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
> > + if (!desc) {
> > + printf("Not enough memory for descriptor allocation\n");
> > + return -ENOMEM;
> > + }
> > +
> > + inline_cnstr_jobdesc_rng(desc, dst, len);
> > +
> > + size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE,
> ARCH_DMA_MINALIGN);
> > + flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
> > + size = ALIGN(len, ARCH_DMA_MINALIGN);
> > + invalidate_dcache_range((unsigned long)dst, (unsigned long)dst +
> > + size);
> > +
> > + ret = run_descriptor_jr(desc);
> > + if (ret < 0) {
> > + printf("Error: RNG generate failed 0x%x\n", ret);
> > + } else {
> > + invalidate_dcache_range((unsigned long)dst,
> > + (unsigned long)dst + size);
> > + puts("RNG generation successful.\n");
> > + }
> > +
> > + free(desc);
> > + return ret;
> > +}
> > +
> >  #ifdef CONFIG_CMD_DEKBLOB
> >  int blob_dek(const u8 *src, u8 *dst, u8 len)  {
> 
> -michael

Re: [PATCH v5 13/16] Layerscape: Enable Job ring driver model in U-Boot.

2021-11-16 Thread Michael Walle

> LS(1021/1012/1028/1043/1046/1088/2088), LX2160, LX2162
> platforms are enabled with JR driver model.
> 
> removed sec_init() call from board files.
> removed CONFIG_FSL_CAAM from defconfig files.
> sec is initialized based on job ring information processed
> from device tree.
> 
> Signed-off-by: Gaurav Jain 
> Reviewed-by: Priyanka Jain 
> ---
>  arch/arm/cpu/armv7/ls102xa/Kconfig|  4 +++
>  arch/arm/cpu/armv7/ls102xa/cpu.c  | 16 +++
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 27 +++
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c   | 10 ++-
>  board/freescale/ls1012afrdm/ls1012afrdm.c |  7 +
>  board/freescale/ls1012aqds/ls1012aqds.c   |  6 +
>  board/freescale/ls1012ardb/ls1012ardb.c   |  6 +
>  board/freescale/ls1021aiot/ls1021aiot.c   |  6 ++---
>  board/freescale/ls1021aqds/ls1021aqds.c   |  6 +
>  board/freescale/ls1021atsn/ls1021atsn.c   |  7 ++---
>  board/freescale/ls1021atwr/ls1021atwr.c   |  8 ++
>  board/freescale/ls1028a/ls1028a.c |  6 +
>  board/freescale/ls1043ardb/ls1043ardb.c   |  6 +
>  board/freescale/ls1046afrwy/ls1046afrwy.c |  7 +
>  board/freescale/ls1046aqds/ls1046aqds.c   |  7 +
>  board/freescale/ls1046ardb/ls1046ardb.c   |  6 +
>  board/freescale/ls1088a/ls1088a.c |  6 +
>  board/freescale/ls2080aqds/ls2080aqds.c   |  6 +
>  board/freescale/ls2080ardb/ls2080ardb.c   |  9 +--
>  board/freescale/lx2160a/lx2160a.c |  5 
>  configs/ls1021aiot_qspi_defconfig |  1 -
>  configs/ls1021aqds_nor_defconfig  |  1 -
>  configs/ls1021aqds_qspi_defconfig |  1 -
>  configs/ls1021atsn_qspi_defconfig |  1 -
>  configs/ls1021atwr_nor_defconfig  |  1 -
>  ...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig |  1 +
>  configs/ls1028ardb_tfa_defconfig  |  1 -
>  configs/ls1043ardb_tfa_defconfig  |  1 -
>  configs/ls1046afrwy_tfa_defconfig |  1 -
>  configs/ls1046aqds_tfa_defconfig  |  1 -
>  configs/ls1046ardb_tfa_defconfig  |  1 -
>  configs/ls2088aqds_tfa_defconfig  |  1 -
>  configs/ls2088ardb_tfa_defconfig  |  1 -
>  configs/lx2160aqds_tfa_defconfig  |  1 -
>  configs/lx2160ardb_tfa_defconfig  |  1 -
>  configs/lx2162aqds_tfa_defconfig  |  1 -
>  36 files changed, 75 insertions(+), 102 deletions(-)

board/kontron/sl28/sl28.c fixes are missing here. With this patch
applied I'll get the following error during boot:

U-Boot 2022.01-rc2-00026-gf82ded5126-dirty (Nov 16 2021 - 11:16:40 +0100)

SoC:  LS1028A Rev1.0 (0x870b0110)
Clock Configuration:
   CPU0(A72):1300 MHz  CPU1(A72):1300 MHz  
   Bus:  400  MHz  DDR:  1600 MT/s
Reset Configuration Word (RCW):
   : 34004010 0030  
   0010:  008f 0030c000 
   0020: 0620 2580  00019016
   0030:  0048  
   0040:    
   0050:    
   0060: 0304  000e7000 
   0070: bb58 0002
Model: Kontron SMARC-sAL28 (Dual PHY)
EL:3
CPLD:  v64
DRAM:  4 GiB (DDR3, 32-bit, CL=11, ECC on)
caam_jr: caam not found

^^ this error.

please add the following hunk to this patch:

diff --git a/board/kontron/sl28/sl28.c b/board/kontron/sl28/sl28.c
index 9572502499..555e831f2a 100644
--- a/board/kontron/sl28/sl28.c
+++ b/board/kontron/sl28/sl28.c
@@ -31,9 +31,6 @@ int board_early_init_f(void)
 
 int board_init(void)
 {
-   if (CONFIG_IS_ENABLED(FSL_CAAM))
-   sec_init();
-
return 0;
 }

>  config ARCH_LS1028A
> @@ -53,6 +57,9 @@ config ARCH_LS1028A
>   select SYS_FSL_ERRATUM_A011334
>   select SYS_FSL_ESDHC_UNRELIABLE_PULSE_DETECTION_WORKAROUND
>   select RESV_RAM if GIC_V3_ITS
> + select FSL_CAAM
> + select FSL_BLOB
> + select MISC

There are boards like the sl28 which also have ARCH_LS1028A set and
doesn't depend on neither FSL_CAAM nor FSL_BLOB. Please don't set
this per architecture. Both should be set by the individual boards
instead as they are optional and having this here will just increase
binary size.

Of course this is like to be true for all ARCH_LSxxx Kconfig options.

>   imply PANIC_HANG 

-michael

[PATCH v2] pci: Work around PCIe link training failures

2021-11-16 Thread Maciej W. Rozycki

Attempt to handle cases with a downstream port of a PCIe switch where
link training never completes and the link continues switching between 
speeds indefinitely with the data link layer never reaching the active 
state.

It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 
switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 
switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, 
P/N 41433, wired to a SiFive HiFive Unmatched board.  In this setup the 
switches are supposed to negotiate the link speed of preferably 5.0GT/s, 
falling back to 2.5GT/s.

However the link continues oscillating between the two speeds, at the 
rate of 34-35 times per second, with link training reported active ~84% 
of the time repeatedly, e.g.:

02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet 
Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 5GT/s (downgraded), Width x1 (ok)
TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, 
Selectable De-emphasis: -3.5dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
[...]

Forcibly limiting the target link speed to 2.5GT/s with the upstream 
ASM2824 device makes the two switches communicate correctly however:

02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet 
Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=09, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
SpeedDis+, Selectable De-emphasis: -3.5dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
[...]

and then:

05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 
3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode])
[...]
Bus: primary=05, secondary=06, subordinate=09, sec-latency=0
[...]
Capabilities: [c0] Express (v2) Upstream Port, MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
[...]

Make use of this observation then and attempt to detect the inability to 
negotiate the link speed automatically, and then handle it by hand.  Use 
the Data Link Layer Link Active status flag as the primary indicator of 
successful link speed negotiation, but given that the flag is optional 
by hardware to implement (the ASM2824 does have it though), resort to 
checking for the mandatory Link Bandwidth Management Status flag showing 
that the link speed or width has been changed in an attempt to correct 
unreliable link operation (the ASM2824 does set it too).

If these checks indicate that link may not operate correctly, then poll 
the Data Link Layer Link Active status flag along with the Link Training 
flag for the duration of 200ms to see if the link has stabilised, that 
is either that the Data Link Layer Link Active status flag has been set 
or that Link Training has been inactive during at least the second half 
of the inteval.

If that has indicated failure, reduce the target speed, request a link 
retrain and check again if the link has stabilised.  Repeat until either 
successful or the link speeds supported by the downstream port have been 
exhausted.

Signed-off-by: Maciej W. Rozycki 
---
Hi,

 Thank you, Pali, for your valuable feedback.  Here's v2 of the change 
with your suggestions taken into account.  I believe I have addressed all 
your concerns and I haven't heard from anyone else, so I consider this 
version final unless someone speaks out.

 Please apply then.

  Maciej

Changes from v1:

- also handle root complex and PCI/PCI-X to PCIe bridge devices,

- update comments throughout accordingly,

- likewise the change description; mention the rate of oscillations 
  observed with the ASM2824 device.
---
 drivers/pci/pci_auto.c |  157 +
 include/pci.h  |   18 +
 2 files changed, 174 insertions(+), 1 deletion(-)

Re: [PATCH v2] pci: Work around PCIe link training failures

2021-11-16 Thread Stefan Roese


Hi Maciej,

On 11/16/21 12:35, Maciej W. Rozycki wrote:

Attempt to handle cases with a downstream port of a PCIe switch where
link training never completes and the link continues switching between
speeds indefinitely with the data link layer never reaching the active
state.

It has been observed with a downstream port of the ASMedia ASM2824 Gen 3
switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2
switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device,
P/N 41433, wired to a SiFive HiFive Unmatched board.  In this setup the
switches are supposed to negotiate the link speed of preferably 5.0GT/s,
falling back to 2.5GT/s.

However the link continues oscillating between the two speeds, at the
rate of 34-35 times per second, with link training reported active ~84%
of the time repeatedly, e.g.:


Interesting topic and approach. Please find a few questions / comments
below.


02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet 
Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=05, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 5GT/s (downgraded), Width x1 (ok)
TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, 
Selectable De-emphasis: -3.5dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
[...]

Forcibly limiting the target link speed to 2.5GT/s with the upstream
ASM2824 device makes the two switches communicate correctly however:

02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet 
Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode])
[...]
Bus: primary=02, secondary=05, subordinate=09, sec-latency=0
[...]
Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
SpeedDis+, Selectable De-emphasis: -3.5dB
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
[...]

and then:

05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 
3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode])
[...]
Bus: primary=05, secondary=06, subordinate=09, sec-latency=0
[...]
Capabilities: [c0] Express (v2) Upstream Port, MSI 00
[...]
LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
[...]
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
[...]

Make use of this observation then and attempt to detect the inability to
negotiate the link speed automatically, and then handle it by hand.  Use
the Data Link Layer Link Active status flag as the primary indicator of
successful link speed negotiation, but given that the flag is optional
by hardware to implement (the ASM2824 does have it though), resort to
checking for the mandatory Link Bandwidth Management Status flag showing
that the link speed or width has been changed in an attempt to correct
unreliable link operation (the ASM2824 does set it too).

If these checks indicate that link may not operate correctly, then poll
the Data Link Layer Link Active status flag along with the Link Training
flag for the duration of 200ms to see if the link has stabilised, that
is either that the Data Link Layer Link Active status flag has been set
or that Link Training has been inactive during at least the second half
of the inteval.

If that has indicated failure, reduce the target speed, request a link
retrain and check again if the link has stabilised.  Repeat until either
successful or the link speeds supported by the downstream port have been
exhausted.


So in such cases, the link speed will be downgraded? I would expect at
least a big warning in such cases.

Did you try to change some other configuration options for the link
establishment? I remember that on some hardware we were able to get
better "link-up results" by setting the de-emphasis level to -3.5dB
instead of -6dB (in the link control status register 2), before trying
to re-estblish the link. Did you also test with "tuning" such
parameters. There might be other, which I'm missing right now.

Thanks,
Stefan


Signed-off-by: Maciej W. Rozycki 
---
Hi,

  Thank you, Pali, for your valuable feedback.  Here's v2 of

[PATCH 07/18] km: common: implement field fail-safe u-boot update

2021-11-16 Thread Aleksandar Gerasimovski

This patch provides possibility for field fail-safe u-boot updates.
The implementation can be used on all pg-wcom boards that are booting from
parallel NOR flash.

When used in a board design, provided check_for_uboot_update function will
start new u-boot at defined location if updateduboot envvar is set to yes.
With this implementation it is expected that factory programmed u-boot
will always stay as it is, and optionally new u-boot can be safely
programmed by embedded software when the unit is rolled out on the field.

It is expected check_for_uboot_update to be called early in execution
before relocation (*_f) once SoC is basically initialized and environment
can be read, with this possibilities to not be able to fix a u-boot bug by
a u-boot update are reduced to minimum.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/Kconfig | 32 ++
 board/keymile/common/common.c | 53 +++
 board/keymile/common/common.h |  1 +
 3 files changed, 86 insertions(+)

diff --git a/board/keymile/Kconfig b/board/keymile/Kconfig
index 7dd8213..863c07d 100644
--- a/board/keymile/Kconfig
+++ b/board/keymile/Kconfig
@@ -130,6 +130,38 @@ config SYS_IVM_EEPROM_PAGE_LEN
help
  Page size of inventory in EEPROM.
 
+config PG_WCOM_UBOOT_UPDATE_SUPPORTED
+   bool "Enable U-boot Field Fail-Safe Update Functionality"
+   default n
+   help
+ Indicates that field fail-safe u-boot update is supported.
+ This functionality works only for designs that are booting
+ from parallel NOR flash.
+
+config PG_WCOM_UBOOT_BOOTPACKAGE
+   bool "U-boot Is Part Of Factory Boot-Package Image"
+   default n
+   help
+ Indicates that u-boot will be a part of the factory programmed
+ boot-package image.
+ Has to be set for original u-boot programmed at factory.
+
+config PG_WCOM_UBOOT_UPDATE_TEXT_BASE
+   hex "Text Base For U-boot Programmed Outside Factory"
+   default 0x
+   help
+ Text base of an updated u-boot that is not factory programmed but
+ later when the unit is rolled out on the field.
+ Has to be set for original u-boot programmed at factory.
+
+config PG_WCOM_UBOOT_UPDATE
+   bool "U-boot Is Part Of Factory Boot-Package Image"
+   default n
+   help
+ Indicates that u-boot will be a part of the embedded software and
+ programmed at field.
+ Has to be set for updated u-boot version programmed at field.
+
 source "board/keymile/km83xx/Kconfig"
 source "board/keymile/kmcent2/Kconfig"
 source "board/keymile/km_arm/Kconfig"
diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c
index ff07260..3999f48 100644
--- a/board/keymile/common/common.c
+++ b/board/keymile/common/common.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #if defined(CONFIG_POST)
 #include "post.h"
@@ -76,6 +78,57 @@ int set_km_env(void)
return 0;
 }
 
+#if CONFIG_IS_ENABLED(PG_WCOM_UBOOT_UPDATE_SUPPORTED)
+#if   ((!CONFIG_IS_ENABLED(PG_WCOM_UBOOT_BOOTPACKAGE) && \
+   !CONFIG_IS_ENABLED(PG_WCOM_UBOOT_UPDATE)) || \
+   (CONFIG_IS_ENABLED(PG_WCOM_UBOOT_BOOTPACKAGE) && \
+   CONFIG_IS_ENABLED(PG_WCOM_UBOOT_UPDATE)))
+#error "It has to be either bootpackage or update u-boot image!"
+#endif
+void check_for_uboot_update(void)
+{
+   void (*uboot_update_entry)(void) =
+   (void (*)(void)) CONFIG_PG_WCOM_UBOOT_UPDATE_TEXT_BASE;
+   char *isupdated = env_get("updateduboot");
+   ulong bootcount = bootcount_load();
+   ulong ebootcount = 0;
+
+   if (IS_ENABLED(CONFIG_PG_WCOM_UBOOT_BOOTPACKAGE)) {
+   /*
+* When running in factory burned u-boot move to the updated
+* u-boot version only if updateduboot envvar is set to 'yes'
+* and bootcount limit is not exceeded.
+* Board must be able to start in factory bootloader mode!
+*/
+   if (isupdated && !strncmp(isupdated, "yes", 3) &&
+   bootcount <= CONFIG_BOOTCOUNT_BOOTLIMIT) {
+   printf("Check update: update detected, ");
+   printf("starting new image @%08x ...\n",
+  CONFIG_PG_WCOM_UBOOT_UPDATE_TEXT_BASE);
+   ebootcount = early_bootcount_load();
+   if (ebootcount <= CONFIG_BOOTCOUNT_BOOTLIMIT) {
+   early_bootcount_store(++ebootcount);
+   uboot_update_entry();
+   } else {
+   printf("Check update: warning: ");
+   printf("early bootcount exceeded (%lu)\n",
+  ebootcount);
+   }
+   }
+   printf("Check update: starting factory image @%08x ...\n",
+

[PATCH 15/18] configs/expu1: add u-boot update defconfig

2021-11-16 Thread Aleksandar Gerasimovski

This patch adds default defconfig for u-boot update version, the u-boot
update defconfig is a copy of the default (factory) defconfig with:
- adapted text base and environment addresses
- explicit flag that this is a field updated u-boot version

At the time of implementation this version is only used to verify the
update procedure, in future depend on the needs this defconfig can be
extended with additional options.

Signed-off-by: Aleksandar Gerasimovski 

---
 board/keymile/pg-wcom-ls102xa/MAINTAINERS |  1 +
 configs/pg_wcom_expu1_update_defconfig| 83 +++
 2 files changed, 84 insertions(+)
 create mode 100644 configs/pg_wcom_expu1_update_defconfig

diff --git a/board/keymile/pg-wcom-ls102xa/MAINTAINERS 
b/board/keymile/pg-wcom-ls102xa/MAINTAINERS
index 9fabad1..33db2b2 100644
--- a/board/keymile/pg-wcom-ls102xa/MAINTAINERS
+++ b/board/keymile/pg-wcom-ls102xa/MAINTAINERS
@@ -9,5 +9,6 @@ F:  include/configs/pg-wcom-expu1.h
 F: configs/pg_wcom_seli8_defconfig
 F: configs/pg_wcom_seli8_update_defconfig
 F: configs/pg_wcom_expu1_defconfig
+F: configs/pg_wcom_expu1_update_defconfig
 F: arch/arm/dts/ls1021a-pg-wcom-seli8.dts
 F: arch/arm/dts/ls1021a-pg-wcom-expu1.dts
diff --git a/configs/pg_wcom_expu1_update_defconfig 
b/configs/pg_wcom_expu1_update_defconfig
new file mode 100644
index 000..0fd5ebc
--- /dev/null
+++ b/configs/pg_wcom_expu1_update_defconfig
@@ -0,0 +1,83 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_TARGET_PG_WCOM_EXPU1=y
+CONFIG_PG_WCOM_UBOOT_UPDATE_SUPPORTED=y
+CONFIG_PG_WCOM_UBOOT_UPDATE=y
+CONFIG_SYS_TEXT_BASE=0x6024
+CONFIG_SYS_MALLOC_LEN=0x1004000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_KM_DEF_NETDEV="eth2"
+CONFIG_KM_COMMON_ETH_INIT=y
+CONFIG_PIGGY_MAC_ADDRESS_OFFSET=3
+CONFIG_SYS_MEMTEST_START=0x8000
+CONFIG_SYS_MEMTEST_END=0x9fff
+CONFIG_ENV_SIZE=0x4000
+CONFIG_ENV_SECT_SIZE=0x2
+CONFIG_SYS_I2C_MXC_I2C1=y
+CONFIG_SYS_I2C_MXC_I2C2=y
+CONFIG_SYS_I2C_MXC_I2C3=y
+CONFIG_DEFAULT_DEVICE_TREE="ls1021a-pg-wcom-expu1"
+CONFIG_BOOTCOUNT_BOOTLIMIT=3
+CONFIG_SYS_BOOTCOUNT_ADDR=0x7020
+CONFIG_AHCI=y
+CONFIG_DISTRO_DEFAULTS=y
+CONFIG_SYS_LOAD_ADDR=0x8200
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_OF_BOARD_SETUP=y
+CONFIG_OF_STDOUT_VIA_ALIAS=y
+CONFIG_BOOTDELAY=3
+CONFIG_AUTOBOOT_KEYED=y
+CONFIG_AUTOBOOT_STOP_STR=" "
+CONFIG_AUTOBOOT_PROMPT="Hit  key to stop autoboot in %2ds\n"
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="console=ttyS0,115200 root=/dev/ram0"
+CONFIG_SILENT_CONSOLE=y
+CONFIG_LAST_STAGE_INIT=y
+CONFIG_MISC_INIT_R=y
+CONFIG_CMD_IMLS=y
+CONFIG_CMD_GREPENV=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_NAND=y
+CONFIG_CMD_NAND_TRIMFFS=y
+CONFIG_CMD_CRAMFS=y
+CONFIG_CMD_MTDPARTS=y
+CONFIG_MTDIDS_DEFAULT="nor0=6000.nor,nand0=6800.flash"
+CONFIG_MTDPARTS_DEFAULT="mtdparts=6000.nor:128k(rcw),128k(qe),128k(envred),128k(env),512k(res),1m(u-boot),128k(redenvred),128k(redenv),1m(redu-boot),-(ubi0);6800.flash:-(ubi1)"
+CONFIG_CMD_UBI=y
+CONFIG_OF_CONTROL=y
+CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+CONFIG_ENV_ADDR=0x6022
+CONFIG_ENV_ADDR_REDUND=0x6020
+CONFIG_DM=y
+CONFIG_BOOTCOUNT_LIMIT=y
+CONFIG_DDR_CLK_FREQ=5000
+CONFIG_SYS_FSL_DDR3=y
+CONFIG_SYS_I2C_LEGACY=y
+# CONFIG_MMC is not set
+CONFIG_MTD=y
+CONFIG_MTD_NOR_FLASH=y
+CONFIG_FLASH_CFI_DRIVER=y
+CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
+CONFIG_FLASH_CFI_MTD=y
+CONFIG_SYS_FLASH_CFI=y
+CONFIG_MTD_RAW_NAND=y
+CONFIG_NAND_FSL_IFC=y
+CONFIG_SYS_NAND_ONFI_DETECTION=y
+CONFIG_PHY_MARVELL=y
+CONFIG_PHY_FIXED=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_PHY_GIGE=y
+CONFIG_MII=y
+CONFIG_TSEC_ENET=y
+CONFIG_SYS_QE_FW_ADDR=0x6002
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SYS_NS16550=y
+CONFIG_VERSION_VARIABLE=y
-- 
1.8.3.1

Re: [PATCH v7 02/12] tools: build mkeficapsule with tools-only_defconfig

2021-11-16 Thread Heinrich Schuchardt


On 11/16/21 13:20, Heinrich Schuchardt wrote:

On 11/16/21 05:32, AKASHI Takahiro wrote:

We want to always build mkeficapsule if tools-only_defconfig is used.

Signed-off-by: AKASHI Takahiro 


Reviewed-by: Heinrich Schuchardt 


---
  configs/tools-only_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/tools-only_defconfig b/configs/tools-only_defconfig
index f482c9a1c1b0..5427797dd4c3 100644
--- a/configs/tools-only_defconfig
+++ b/configs/tools-only_defconfig
@@ -31,3 +31,4 @@ CONFIG_I2C_EDID=y
  # CONFIG_VIRTIO_MMIO is not set
  # CONFIG_VIRTIO_PCI is not set
  # CONFIG_VIRTIO_SANDBOX is not set
+CONFIG_TOOLS_MKEFICAPSULE=y




You cannot use a symbol that is not yet defined. Please, swap patches 2
and 3 when resubmitting.

Best regards

Heinrich

Re: [PATCH RFC] cmd: fix net list command

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 02:33:01PM +0100, Wolfgang Denk wrote:
> Dear Ramon,
> 
> In message 
>  you 
> wrote:
> >
> > It appears that Michael has some board and a scenario that *this* bug
> > was working for his best interest, where he can have two distinct MAC
> > addresses, one in U-boot and one in Linux.
> 
> If the Linux environment is supposed to be a specific MAC address
> (which may be different from the one passed by U-Boot), then there
> are standard tools available to set the address.  I don't see a
> problem here.

One thing I'm not totally sure on yet is, looking at the README I see:
"If Ethernet drivers implement the 'write_hwaddr' function, valid MAC
addresses will be programmed into hardware as part of the initialization
process.  This may be skipped by setting the appropriate 'ethmacskip'
environment variable.  The naming convention is as follows: "ethmacskip"
(=>eth0), "eth1macskip" (=>eth1) etc."

As I'm sure that predates device trees being used to the extent they are
now, should 'ethmacskip' be involved in the "fixup the device tree"
logic, and appropriate rST / Kconfig help text updated?  My first
reaction is that in spirit, this is how to solve Michael's use case and
README / doc/README.enetaddr do not specify when/why the "also fixup the
device tree if it exists" is done.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH v3 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Hi Fabio,

On 11/16/21 8:37 AM, Fabio Estevam wrote:
> Hi Ariel,
> 
> The patch looks good. Only some minor comments:
> 
> On Tue, Nov 16, 2021 at 12:51 AM Ariel D'Alessandro
>  wrote:
>>
>> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
>>
>> - 1GiB DDR4 RAM
>> - 16 GiB eMMC
>> - SD card
>> - Gigabit ethernet
>> - USBOTG1 peripheral - fastboot
>>
>> Signed-off-by: Ariel D'Alessandro 
> 
> It would be nice to have a README file so that the users can know how
> to build and flash mainline
> U-Boot in this board.

Added that to doc/board/variscite/imx8mn_var_som.rst
Will submit in v4.

> 
>> +#define PHYS_SDRAM 0x4000
>> +#define PHYS_SDRAM_SIZESZ_1G /* 1GB DDR */
>> +
>> +#define CONFIG_BAUDRATE115200
> 
> This is the default. No need to be specified here.

Ack.

> 
>> +#define CONFIG_MXC_UART_BASE   UART4_BASE_ADDR
>> +
>> +/* Monitor Command Prompt */
>> +#define CONFIG_SYS_CBSIZE  SZ_2K
>> +#define CONFIG_SYS_MAXARGS 64
>> +#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
>> +#define CONFIG_SYS_PBSIZE  (CONFIG_SYS_CBSIZE + \
>> +sizeof(CONFIG_SYS_PROMPT) + 16)
>> +
>> +/* USDHC */
>> +#define CONFIG_FSL_USDHC
> 
> This should be placed in defconfig.

Done.

> 
>> +#define CONFIG_SYS_FSL_USDHC_NUM   2
> 
> This is not used. Please remove it.

Done.

Thanks a lot,
Ariel

[GIT PULL] xilinx patches for v2022.01-rc3

2021-11-16 Thread Michal Simek


Hi Tom,

Please pull these changes to your tree. CI loop doesn't show any issue 
with these patches.


Thanks,
Michal

The following changes since commit fb1018106a7bbb1a0d723029f6760b1b1b4d306d:

  Merge branch '2021-10-19-assorted-changes' (2021-10-19 20:45:12 -0400)

are available in the Git repository at:

  g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git 
tags/xilinx-for-v2022.01-rc3


for you to fetch changes up to 11c0255cd8a7177e2b714040efcfd51844cb5d8e:

  xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check (2021-11-15 15:59:33 +0100)


Xilinx changes for v2022.01-rc3

sdhci:
- Fix emmc mini case with missing firmware interface

zynqmp:
- Restore JTAG interface if required
- Allow overriding board name
- Add support for DLC21
- Fix one fallthrought statement description
- Use config macro instead of name duplication
- Save multiboot to variable

firmware:
- Handle ipi_req errors better
- Use local buffer in case user doesn't need it instead of NULL/0 location

spi:
- gqsi: Fix write issue at low frequencies

net:
- gem: Disable broadcasts


Ashok Reddy Soma (1):
  spi: zynqmp_gqspi: Fix write issue at low frequencies

Jorge Ramirez-Ortiz (1):
  zynqmp: restore the jtag interface

Liam Beguin (1):
  arm64: zynqmp: allow overriding board name

Michal Simek (9):
  arm64: zynqmp: Add support for DLC21 (Smartlynq+) board
  arm64: zynqmp: Fix sgmii clock input freq for p-a2197
  net: gem: Disable broadcast setting
  firmware: zynqmp: Handle errors from ipi_req properly
  firmware: zynqmp: fix write to an uninitialised pointer in ipi_req()
  xilinx: zynqmp: Handle fallthrough statement properly
  xilinx: zynqmp: Use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
  xilinx: zynqmp: Save multiboot as variable
  arm64: zynqmp: Replace comma by semicolon

Ricardo Salveti (1):
  xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check

T Karthik Reddy (1):
  mmc: zynq_sdhci: Add xilinx_pm_request weak function

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/zynqmp-dlc21-revA.dts   | 221 
++

 arch/arm/dts/zynqmp-p-a2197-00-revA.dts  |   2 +-
 arch/arm/mach-zynqmp/Kconfig |   9 +
 arch/arm/mach-zynqmp/include/mach/hardware.h |  31 +++-
 board/xilinx/zynqmp/zynqmp-dlc21-revA/psu_init_gpl.c | 922 
+++

 board/xilinx/zynqmp/zynqmp.c |  48 -
 configs/xilinx_zynqmp_virt_defconfig |   2 +-
 drivers/firmware/firmware-zynqmp.c   |  10 +-
 drivers/mmc/zynq_sdhci.c |   6 +
 drivers/net/zynq_gem.c   |   2 +
 drivers/spi/zynqmp_gqspi.c   |  11 +-
 12 files changed, 1243 insertions(+), 22 deletions(-)
 create mode 100644 arch/arm/dts/zynqmp-dlc21-revA.dts
 create mode 100644 board/xilinx/zynqmp/zynqmp-dlc21-revA/psu_init_gpl.c

Re: [PATCH] net: uclass: Save ethernet MAC address when generated

2021-11-16 Thread Tom Rini

On Thu, Nov 11, 2021 at 10:10:57AM +0100, Michael Walle wrote:
> Hi Ramon,
> 
> Am 2021-11-09 14:55, schrieb Michael Walle:
> > Am 2021-11-04 22:00, schrieb Ramon Fried:
> > 
> > > What's the verdict ? We're keeping this patch ?
> > 
> > There was a good point from Grygorii: linux might deal
> > in its own way with missing ethernet addresses (and warn
> > the user about it because its usually an error).
> > 
> > And IMHO that net list can be fixed in a different way.
> > 
> > If this patch is accepted, it should be clearly documented
> > in the Kconfig help text. And as I said, it changes behavior.
> 
> So this patch now in your pull request. Why are you even asking
> then?

So, to quote lib/Kconfig:
config NET_RANDOM_ETHADDR
bool "Random ethaddr if unset"
help
  Selecting this will allow the Ethernet interface to function
  even when the ethaddr variable for that interface is unset.
  A new MAC address will be generated on every boot and it will
  not be added to the environment.

We need either a re-spin or follow-up as we're changing the documented
behavior.  And as I mentioned in the other thread related on-going
thread, perhaps "ethmacskip" should play a role in preserving existing
behavior?

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH] net: uclass: Save ethernet MAC address when generated

2021-11-16 Thread Wolfgang Denk

Dear Tom,

In message <2026141855.GD24579@bill-the-cat> you wrote:
> 
> So, to quote lib/Kconfig:
> config NET_RANDOM_ETHADDR
> bool "Random ethaddr if unset"
> help
>   Selecting this will allow the Ethernet interface to function
>   even when the ethaddr variable for that interface is unset.
>   A new MAC address will be generated on every boot and it will
>   not be added to the environment.

This description is at least incomplete, because it makes no
difference between the persistent copy of the environment and it's
in-memory copy.  For network to function, I think the MAC address
must be stored in the in-memory copy of the environment.

> We need either a re-spin or follow-up as we're changing the documented
> behavior.  And as I mentioned in the other thread related on-going
> thread, perhaps "ethmacskip" should play a role in preserving existing
> behavior?

We have way too many ways to do the same thing - nearly, just a
little different :-(

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"A little knowledge is a dangerous thing."- Doug Gwyn

Re: [PATCH v4] lib: sparse: Make CHUNK_TYPE_RAW buffer aligned

2021-11-16 Thread Sean Anderson





On 11/15/21 8:35 PM, qianfangui...@qq.com wrote:

From: qianfan Zhao 

CHUNK_TYPE_RAW buffer is not aligned, and flash sparse images by
fastboot will report "Misaligned operation" if DCACHE is enabled.

Flashing Sparse Image
CACHE: Misaligned operation at range [8428, 84001028]
CACHE: Misaligned operation at range [84001034, 84002034]
CACHE: Misaligned operation at range [8401104c, 8401304c]

Fix it

Signed-off-by: qianfan Zhao 
---
  lib/image-sparse.c | 69 --
  1 file changed, 61 insertions(+), 8 deletions(-)

diff --git a/lib/image-sparse.c b/lib/image-sparse.c
index d80fdbbf58..5ec0f94ab3 100644
--- a/lib/image-sparse.c
+++ b/lib/image-sparse.c
@@ -46,9 +46,66 @@
  #include 
  
  #include 

+#include 
  
  static void default_log(const char *ignored, char *response) {}
  
+static lbaint_t write_sparse_chunk_raw(struct sparse_storage *info,

+  lbaint_t blk, lbaint_t blkcnt,
+  void *data,
+  char *response)
+{
+   lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
+   uint32_t *aligned_buf = NULL;
+
+   if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
+   write_blks = info->write(info, blk, n, data);
+   if (write_blks < n)
+   goto write_fail;
+
+   return write_blks;
+   }
+
+   aligned_buf = memalign(ARCH_DMA_MINALIGN, info->blksz * 
aligned_buf_blks);
+   if (!aligned_buf) {
+   info->mssg("Malloc failed for: CHUNK_TYPE_RAW", response);
+   return -ENOMEM;
+   }
+
+   while (blkcnt > 0) {
+   n = min(aligned_buf_blks, blkcnt);
+   memcpy(aligned_buf, data, n * info->blksz);
+
+   /* write_blks might be > n due to NAND bad-blocks */


nit: <


+   write_blks = info->write(info, blk + blks, n, aligned_buf);
+   if (write_blks < n) {
+   free(aligned_buf);
+   goto write_fail;
+   }
+
+   blks += write_blks;
+   data += n * info->blksz;
+   blkcnt -= n;
+   }
+
+   free(aligned_buf);
+   return blks;
+
+write_fail:


I think this label can be lower, but it does not affect correctness.


+   if (IS_ERR_VALUE(write_blks)) {
+   printf("%s: Write failed, block #" LBAFU " [" LBAFU "] 
(%lld)\n",
+  __func__, blk + blks, n, (long long)write_blks);
+   info->mssg("flash write failure", response);
+   return write_blks;
+   }
+
+   /* write_blks < n */
+   printf("%s: Write failed, block #" LBAFU " [" LBAFU "]\n",
+  __func__, blk + blks, n);
+   info->mssg("flash write failure(incomplete)", response);
+   return -1;


-EIO?


+}
+
  int write_sparse_image(struct sparse_storage *info,
   const char *part_name, void *data, char *response)
  {
@@ -152,15 +209,11 @@ int write_sparse_image(struct sparse_storage *info,
return -1;
}
  
-			blks = info->write(info, blk, blkcnt, data);

-   /* blks might be > blkcnt (eg. NAND bad-blocks) */
-   if (blks < blkcnt) {
-   printf("%s: %s" LBAFU " [" LBAFU "]\n",
-  __func__, "Write failed, block #",
-  blk, blks);
-   info->mssg("flash write failure", response);
+   blks = write_sparse_chunk_raw(info, blk, blkcnt,
+ data, response);
+   if (blks < 0)
return -1;


ditto


-   }
+
blk += blks;
bytes_written += ((u64)blkcnt) * info->blksz;
total_blocks += chunk_header->chunk_sz;



Reviewed-by: Sean Anderson

[PATCH v4 0/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Changes in v4:
* Added board documentation.
* Cleaned up board config.

Changes in v3:
* Picked device tree from kernel.
* Properly added MAINTAINERS entry.
* Removed CONFIG_SPL_BUILD anti-pattern in board config.

Changes in v2:
* Reordered dt properties alphabetically.
* Removed downstream stuff in bootargs.
* Fixed binman configuration.
* Several code styling fixes.

Ariel D'Alessandro (1):
  imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 256 
 arch/arm/dts/imx8mn-var-som-symphony.dts  | 240 
 arch/arm/dts/imx8mn-var-som.dtsi  | 547 ++
 arch/arm/mach-imx/imx8m/Kconfig   |   9 +
 board/variscite/imx8mn_var_som/Kconfig|  17 +
 board/variscite/imx8mn_var_som/MAINTAINERS|   7 +
 board/variscite/imx8mn_var_som/Makefile   |  12 +
 board/variscite/imx8mn_var_som/ddr4_timing.c  | 528 +
 .../variscite/imx8mn_var_som/imx8mn_var_som.c |  30 +
 .../imx8mn_var_som/imximage-8mn-ddr4.cfg  |  10 +
 board/variscite/imx8mn_var_som/spl.c  |  93 +++
 configs/imx8mn_var_som_defconfig  |  98 
 doc/board/variscite/imx8mn_var_som.rst|  56 ++
 doc/board/variscite/index.rst |   9 +
 include/configs/imx8mn_var_som.h  |  90 +++
 16 files changed, 2003 insertions(+)
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts
 create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi
 create mode 100644 board/variscite/imx8mn_var_som/Kconfig
 create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS
 create mode 100644 board/variscite/imx8mn_var_som/Makefile
 create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c
 create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c
 create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg
 create mode 100644 board/variscite/imx8mn_var_som/spl.c
 create mode 100644 configs/imx8mn_var_som_defconfig
 create mode 100644 doc/board/variscite/imx8mn_var_som.rst
 create mode 100644 doc/board/variscite/index.rst
 create mode 100644 include/configs/imx8mn_var_som.h

-- 
2.30.2

[PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:

- 1GiB DDR4 RAM
- 16 GiB eMMC
- SD card
- Gigabit ethernet
- USBOTG1 peripheral - fastboot

Signed-off-by: Ariel D'Alessandro 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 256 
 arch/arm/dts/imx8mn-var-som-symphony.dts  | 240 
 arch/arm/dts/imx8mn-var-som.dtsi  | 547 ++
 arch/arm/mach-imx/imx8m/Kconfig   |   9 +
 board/variscite/imx8mn_var_som/Kconfig|  17 +
 board/variscite/imx8mn_var_som/MAINTAINERS|   7 +
 board/variscite/imx8mn_var_som/Makefile   |  12 +
 board/variscite/imx8mn_var_som/ddr4_timing.c  | 528 +
 .../variscite/imx8mn_var_som/imx8mn_var_som.c |  30 +
 .../imx8mn_var_som/imximage-8mn-ddr4.cfg  |  10 +
 board/variscite/imx8mn_var_som/spl.c  |  93 +++
 configs/imx8mn_var_som_defconfig  |  98 
 doc/board/variscite/imx8mn_var_som.rst|  56 ++
 doc/board/variscite/index.rst |   9 +
 include/configs/imx8mn_var_som.h  |  90 +++
 16 files changed, 2003 insertions(+)
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts
 create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi
 create mode 100644 board/variscite/imx8mn_var_som/Kconfig
 create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS
 create mode 100644 board/variscite/imx8mn_var_som/Makefile
 create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c
 create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c
 create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg
 create mode 100644 board/variscite/imx8mn_var_som/spl.c
 create mode 100644 configs/imx8mn_var_som_defconfig
 create mode 100644 doc/board/variscite/imx8mn_var_som.rst
 create mode 100644 doc/board/variscite/index.rst
 create mode 100644 include/configs/imx8mn_var_som.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd83..8d27876fa0e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -901,6 +901,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-ddr4-evk.dtb \
imx8mq-cm.dtb \
imx8mn-evk.dtb \
+   imx8mn-var-som-symphony.dtb \
imx8mq-evk.dtb \
imx8mm-beacon-kit.dtb \
imx8mn-beacon-kit.dtb \
diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi 
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
new file mode 100644
index 000..ce475885df6
--- /dev/null
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Collabora Ltd.
+ */
+
+/ {
+   binman: binman {
+   multiple-images;
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   u-boot,dm-spl;
+   };
+};
+
+&{/soc@0} {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_24m {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+_i2c1 {
+   u-boot,dm-spl;
+};
+
+_pmic {
+   u-boot,dm-spl;
+};
+
+_reg_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+_uart4 {
+   u-boot,dm-spl;
+};
+
+_usdhc2 {
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
+
+_wdog {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot-spl-ddr {
+   align = <4>;
+   align-size = <4>;
+   filename = "u-boot-spl-ddr.bin";
+   pad-byte = <0xff>;
+
+   u-boot-spl {
+   align-end = <4>;
+   filename = "u-boot-spl.bin";
+   };
+
+   1d-imem {
+   filename = "ddr4_imem_1d.bin";
+   size = <0x8000>;
+   type = "blob-ext";
+   };
+
+   1d_dmem {
+   filename = "ddr4_dmem_1d.bin";
+   size = <0x4000>;
+   type = "blob-ext";
+   };
+
+   2d_imem {
+   filename = "ddr4_imem_2d.bin";
+   size =

Re: [PATCH RFC] cmd: fix net list command

2021-11-16 Thread Wolfgang Denk

Dear Tom,

In message <2026141030.GC24579@bill-the-cat> you wrote:
> 
> One thing I'm not totally sure on yet is, looking at the README I see:
> "If Ethernet drivers implement the 'write_hwaddr' function, valid MAC
> addresses will be programmed into hardware as part of the initialization
> process.  This may be skipped by setting the appropriate 'ethmacskip'
> environment variable.  The naming convention is as follows: "ethmacskip"
> (=>eth0), "eth1macskip" (=>eth1) etc."

I have to admit that until now I was not even aware of these
variables...

> As I'm sure that predates device trees being used to the extent they are
> now, should 'ethmacskip' be involved in the "fixup the device tree"
> logic, and appropriate rST / Kconfig help text updated?  My first
> reaction is that in spirit, this is how to solve Michael's use case and
> README / doc/README.enetaddr do not specify when/why the "also fixup the
> device tree if it exists" is done.

Apparently this logic was added more than 10 years ago in commit
ecee9324d "Program net device MAC addresses after initializing".

I think it does not change anything to the logic that Linux uses the
MAC address passed by U-Boot. Whether U-Boot also writes some MAC
address to the device's persistent storage is an independent act.
If there already was an addressed stored there befoire it would not
have been read by Linux, so the same should happen here.

[Here it is even less problematic as U-Boot has the very same MAC
address in it's environment.]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Everyting looks interesting until you do it. Then you find it's  just
another job. - Terry Pratchett, _Moving Pictures_

RE: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver model

2021-11-16 Thread ZHIZHIKIN Andrey

Hello Gaurav,

> -Original Message-
> From: U-Boot  On Behalf Of Gaurav Jain
> Sent: Monday, November 15, 2021 8:00 AM
> To: u-boot@lists.denx.de
> Cc: Stefano Babic ; Fabio Estevam ; Peng 
> Fan
> ; Simon Glass ; Priyanka Jain
> ; Ye Li ; Horia Geanta
> ; Ji Luo ; Franck Lenormand
> ; Silvano Di Ninno ; Sahil
> malhotra ; Pankaj Gupta ; Varun
> Sethi ; NXP i . MX U-Boot Team ; Shengzhou
> Liu ; Mingkai Hu ; Rajesh Bhagat
> ; Meenakshi Aggarwal ; 
> Wasim
> Khan ; Alison Wang ; Pramod Kumar
> ; Tang Yuantian ; Adrian Alonso
> ; Vladimir Oltean ; Gaurav Jain
> 
> Subject: [PATCH v5 01/16] crypto/fsl: Add support for CAAM Job ring driver 
> model
> 
> 
> added device tree support for job ring driver.
> sec is initialized based on job ring information processed
> from device tree.
> 
> Signed-off-by: Gaurav Jain 
> Reviewed-by: Ye Li 
> ---
>  cmd/Kconfig |   1 +
>  drivers/crypto/fsl/Kconfig  |   7 +
>  drivers/crypto/fsl/Makefile |   4 +-
>  drivers/crypto/fsl/jr.c | 316 +++-
>  drivers/crypto/fsl/jr.h |  14 ++
>  5 files changed, 232 insertions(+), 110 deletions(-)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 5b30b13e43..2b24672505 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2009,6 +2009,7 @@ config CMD_AES
> 
>  config CMD_BLOB
> bool "Enable the 'blob' command"
> +   select FSL_BLOB
> depends on !MX6ULL && !MX6SLL && !MX6SL
> select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M
> help
> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
> index 94ff540111..ab59d516f8 100644
> --- a/drivers/crypto/fsl/Kconfig
> +++ b/drivers/crypto/fsl/Kconfig
> @@ -66,4 +66,11 @@ config FSL_CAAM_RNG
>   using the prediction resistance flag which means the DRGB is
>   reseeded from the TRNG every time random data is generated.
> 
> +config FSL_BLOB
> +bool "Enable Blob Encap/Decap, Blob KEK support"
> +   help
> + Enable support for the hardware based crytographic blob encap/decap
> + module of the CAAM. blobs can be safely placed into non-volatile
> + storage. blobs can only be decapsulated by the SoC that created it.
> + Enable support for blob key encryption key generation.
>  endif
> diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
> index f9c3ccecfc..738535b8e4 100644
> --- a/drivers/crypto/fsl/Makefile
> +++ b/drivers/crypto/fsl/Makefile
> @@ -1,10 +1,12 @@
>  # SPDX-License-Identifier: GPL-2.0+
>  #
>  # Copyright 2014 Freescale Semiconductor, Inc.
> +# Copyright 2021 NXP
> 
>  obj-y += sec.o
>  obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> -obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
> +obj-$(CONFIG_FSL_BLOB) += fsl_blob.o
> +obj-$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
>  obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
>  obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
>  obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 22b649219e..eea2225a1e 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -1,7 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0+
>  /*
>   * Copyright 2008-2014 Freescale Semiconductor, Inc.
> - * Copyright 2018 NXP
> + * Copyright 2018, 2021 NXP
>   *
>   * Based on CAAM driver in drivers/crypto/caam in Linux
>   */
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include "fsl_sec.h"
>  #include "jr.h"
>  #include "jobdesc.h"
>  #include "desc_constr.h"
> @@ -21,8 +20,11 @@
>  #include 
>  #include 
>  #endif
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> 
>  #define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
>  #define CIRC_SPACE(head, tail, size)   CIRC_CNT((tail), (head) + 1, (size))
> @@ -35,20 +37,30 @@ uint32_t sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {
>  #endif
>  };
> 
> +#if CONFIG_IS_ENABLED(DM)
> +struct udevice *caam_dev;
> +#else
>  #define SEC_ADDR(idx)  \
> (ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
> 
>  #define SEC_JR0_ADDR(idx)  \
> (ulong)(SEC_ADDR(idx) + \
>  (CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
> +struct caam_regs caam_st;
> +#endif
> 
> -struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
> +static inline u32 jr_start_reg(u8 jrid)
> +{
> +   return (1 << jrid);
> +}
> 
> -static inline void start_jr0(uint8_t sec_idx)
> +#ifndef CONFIG_ARCH_IMX8
> +static inline void start_jr(struct caam_regs *caam)
>  {
> -   ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
> +   ccsr_sec_t *sec = caam->sec;
> u32 ctpr_ms = sec_in32(>ctpr_ms);
> u32 scfgr = sec_in32(>scfgr);
> +   u32 jrstart = jr_start_reg(caam->jrid);
> 
> if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_INCL) {
> /* VIRT_EN_INCL = 1 & VIRT_EN_POR = 1 or
> @@ -56,23 +68,17 @@ static inline void start_jr0(uint8_t sec_idx)
>

Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Fabio Estevam

On Tue, Nov 16, 2021 at 11:26 AM Ariel D'Alessandro
 wrote:

> --- /dev/null
> +++ b/doc/board/variscite/imx8mn_var_som.rst
> @@ -0,0 +1,56 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +imx8mn_evk
> +==

Copy and paste error :-)

Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro




On 11/16/21 2:54 PM, Fabio Estevam wrote:
> On Tue, Nov 16, 2021 at 11:26 AM Ariel D'Alessandro
>  wrote:
> 
>> --- /dev/null
>> +++ b/doc/board/variscite/imx8mn_var_som.rst
>> @@ -0,0 +1,56 @@
>> +.. SPDX-License-Identifier: GPL-2.0+
>> +
>> +imx8mn_evk
>> +==
> 
> Copy and paste error :-)

Ugh, :hard-facepalm:

Thanks!

Re: [PATCH 3/3] cmd: add acmconsole command

2021-11-16 Thread Loic Poulain

Hi Pali,

Sorry for the late reply,

On Mon, 27 Sept 2021 at 22:04, Pali Rohár  wrote:
>
> On Thursday 19 August 2021 13:13:06 Loic Poulain wrote:
> > This command allows to start CDC ACM function and redirect console
> > (stdin, stdout, stderr) to USB (acmconsole start). The console can
> > then be accessed through the USB host for debugging purpose. The
> > host can stop the session (acmconsole stop) to revert back console
> > to serial and unregister CDC ACM USB function.
>
> Hello!
>
> Could you rather implement this CDC ACM gadget in a way that calling
> 'setenv stdout cdc_acm' (or 'setenv stdout usbtty') would do this
> console redirect? Like it is supported for current usbtty or vga output
> code.
>
> Then this acmconsole command would not be needed at all.

Yes, that would be good, but AFAIR I restricted this cdc_acm usage to
this command because we can't have fine grained control like e.g.
using cdc_acm as stdout only, when used, it should necessarily be
STDIN (at least). The reason is because of the single-tasking nature
of u-boot, and the fact that we need to poll the USB controller for
events via the 'usb_gadget_handle_interrupts()' function. In our case
we simply do that in the getc() function, which is only called for
input consoles in the u-boot mainloop.

An alternative would be to have a u-boot API to register generic
callbacks to be executed in the mainloop, but this is probably a
different thread.

Also we could possibly live with this 'bug' and simply accept that
stdout-only configuration will be broken.

Regards,
Loic

Re: [PATCH v5 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 03:11:19PM -0300, Ariel D'Alessandro wrote:

> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
> 
> - 1GiB DDR4 RAM
> - 16 GiB eMMC
> - SD card
> - Gigabit ethernet
> - USBOTG1 peripheral - fastboot
> 
> Signed-off-by: Ariel D'Alessandro 

Reviewed-by: Tom Rini 

-- 
Tom

signature.asc
Description: PGP signature

Re: [GIT PULL] xilinx patches for v2022.01-rc3

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 03:46:44PM +0100, Michal Simek wrote:

> Hi Tom,
> 
> Please pull these changes to your tree. CI loop doesn't show any issue with
> these patches.
> 
> Thanks,
> Michal
> 
> The following changes since commit fb1018106a7bbb1a0d723029f6760b1b1b4d306d:
> 
>   Merge branch '2021-10-19-assorted-changes' (2021-10-19 20:45:12 -0400)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git
> tags/xilinx-for-v2022.01-rc3
> 
> for you to fetch changes up to 11c0255cd8a7177e2b714040efcfd51844cb5d8e:
> 
>   xilinx: zynqmp: fix ZYNQMP_RESTORE_JTAG check (2021-11-15 15:59:33 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 3/3] cmd: add acmconsole command

2021-11-16 Thread Pali Rohár

Hello!

On Tuesday 16 November 2021 20:05:07 Loic Poulain wrote:
> Hi Pali,
> 
> Sorry for the late reply,
> 
> On Mon, 27 Sept 2021 at 22:04, Pali Rohár  wrote:
> >
> > On Thursday 19 August 2021 13:13:06 Loic Poulain wrote:
> > > This command allows to start CDC ACM function and redirect console
> > > (stdin, stdout, stderr) to USB (acmconsole start). The console can
> > > then be accessed through the USB host for debugging purpose. The
> > > host can stop the session (acmconsole stop) to revert back console
> > > to serial and unregister CDC ACM USB function.
> >
> > Hello!
> >
> > Could you rather implement this CDC ACM gadget in a way that calling
> > 'setenv stdout cdc_acm' (or 'setenv stdout usbtty') would do this
> > console redirect? Like it is supported for current usbtty or vga output
> > code.
> >
> > Then this acmconsole command would not be needed at all.
> 
> Yes, that would be good, but AFAIR I restricted this cdc_acm usage to
> this command because we can't have fine grained control like e.g.
> using cdc_acm as stdout only, when used, it should necessarily be
> STDIN (at least). The reason is because of the single-tasking nature
> of u-boot, and the fact that we need to poll the USB controller for
> events via the 'usb_gadget_handle_interrupts()' function.

There was already discussion that custom commands for activating drivers
are against driver model design. See:
https://lore.kernel.org/u-boot/20211026151742.42b0fcfa@thinkpad/

So I think that there should not be any driver specific command which
just activates device (in this case console).

> In our case
> we simply do that in the getc() function, which is only called for
> input consoles in the u-boot mainloop.

This looks like a hack in the current implementation which seems that
also misuse driver model design. At least this should be documented as
this is limitation of functionality.

> An alternative would be to have a u-boot API to register generic
> callbacks to be executed in the mainloop, but this is probably a
> different thread.

I guess that this should be discussed, so some optimal solution for
issue is chosen. Otherwise we will have there second implementation of
"usbtty", which even would not provide all functionality as original
"usbtty" code.

> Also we could possibly live with this 'bug' and simply accept that
> stdout-only configuration will be broken.
> 
> Regards,
> Loic

Re: [PATCH v2] sf: Querying write-protect status before operating the flash

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 04:41:46PM +0800, chaochao wrote:
> 
> On 2021/11/15 22:02, Jagan Teki wrote:
> > On Mon, Nov 15, 2021 at 6:51 PM chaochao2021...@163.com
> >  wrote:
> > > 
> > > On 2021/11/15 13:57, tudor.amba...@microchip.com wrote:
> > > 
> > > Hi,
> > > 
> > > + Michael
> > > 
> > > On 11/15/21 4:37 AM, chaochao2021...@163.com wrote:
> > > 
> > > EXTERNAL EMAIL: Do not click links or open attachments unless you know 
> > > the content is safe
> > > 
> > > From: chao zeng 
> > > 
> > > When operating the write-protection flash,spi_flash_std_write() and
> > > spi_flash_std_erase() would return wrong result.The flash is protected,
> > > but write or erase the flash would show "OK".
> > > 
> > > Check the flash write protection state before operating the flash
> > > and give a prompt to show it has been locked if the write-protection
> > > has enbale
> > > 
> > > Signed-off-by: chao zeng 
> > > 
> > > ---
> > > 
> > > Changes for V2:
> > >   - Return 0 not ENOPROTOOPT to refelect the flash feature
> > >   - Output prompt information
> > > ---
> > >   drivers/mtd/spi/sf_probe.c | 10 ++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
> > > index f461082e03..995801817d 100644
> > > --- a/drivers/mtd/spi/sf_probe.c
> > > +++ b/drivers/mtd/spi/sf_probe.c
> > > @@ -109,6 +109,11 @@ static int spi_flash_std_write(struct udevice *dev, 
> > > u32 offset, size_t len,
> > >  struct mtd_info *mtd = >mtd;
> > >  size_t retlen;
> > > 
> > > +   if (flash->flash_is_locked && flash->flash_is_locked(flash, 
> > > offset, len)) {
> > > +   printf("SF: Flash is locked\n");
> > > 
> > > I would use a debug message, it's a flash specific thing. Also, I would 
> > > update
> > > a bit the message, something like
> > > "SF: Flash has protected areas in the requested length. Writes will be 
> > > ignored on those."
> > > 
> > > +   return 0;
> > > 
> > > Michael has suggested to drop this line. I agree with him, check the 
> > > conversation
> > > on the previous email thread.
> > > 
> > > Cheers,
> > > ta
> > > 
> > > +   }
> > > +
> > >  return mtd->_write(mtd, offset, len, , buf);
> > >   }
> > > 
> > > @@ -127,6 +132,11 @@ static int spi_flash_std_erase(struct udevice *dev, 
> > > u32 offset, size_t len)
> > >  instr.addr = offset;
> > >  instr.len = len;
> > > 
> > > +   if (flash->flash_is_locked && flash->flash_is_locked(flash, 
> > > offset, len)) {
> > > +   printf("SF: Flash is locked\n");
> > > +   return 0;
> > > +   }
> > > +
> > >  return mtd->_erase(mtd, );
> > >   }
> > > 
> > > --
> > > 2.33.1
> > > 
> > > 
> > > 
> > > the background is we like to use sf command to operate the flash under 
> > > uboot shell,
> > > 
> > > "sf erase" command still would show the prompt  "erase ok" even though  
> > > write-enable has enabled.
> > > 
> > > 
> > > So at the beginning  I'd like to return an error ,so the sf operation 
> > > would show "erase failed" when operating the write-enabled devices.
> > > 
> > > 
> > > I'm agree with only output information to prompt the user the operation 
> > > unsuccessful.
> > > 
> > > But It should explicitly give clear hints,so I suggest at here using 
> > > printf not debug.
> > 
> > We cannot encourage sf to show non operational prints like locked or
> > unlocked on command line. Just check the contents via read and compare
> > and understand whether flash is written properly, if not written
> > properly user has to debug on his own.
> 
> I think it’s not user friendly at all. Using debug is not a problem for
> developers, but it is not so good for users who use the sf command.

Yes, I think I agree that this is the kind of information that since it
is easily available to us at run time should be printed to the user when
things fail.  We don't document and expect people to start with running
"sf protect" to check the status of writing to a specific area nor do we
tell people that all writes should be read back and verified in the
normal case.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] net: uclass: Save ethernet MAC address when generated

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 03:56:45PM +0100, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <2026141855.GD24579@bill-the-cat> you wrote:
> > 
> > So, to quote lib/Kconfig:
> > config NET_RANDOM_ETHADDR
> > bool "Random ethaddr if unset"
> > help
> >   Selecting this will allow the Ethernet interface to function
> >   even when the ethaddr variable for that interface is unset.
> >   A new MAC address will be generated on every boot and it will
> >   not be added to the environment.
> 
> This description is at least incomplete, because it makes no
> difference between the persistent copy of the environment and it's
> in-memory copy.  For network to function, I think the MAC address
> must be stored in the in-memory copy of the environment.

Well, networking has been working with NET_RANDOM_ETHADDR not updating
the environment, with caveats that user display information that reads
from the environment rather than ->enetaddr.  In so far as the
networking stack cares, ->enetaddr is what matters.  We look at the
environment for a MAC, and if it doesn't match the HW we use environment
MAC, but warn.

Now, I think RFC7042 is the current correct and relevant RFC here and it
doesn't mention persistence.  So I don't see a clear external authority
on if locally administered MAC addresses like this should be persistent
or not in this manner.

> > We need either a re-spin or follow-up as we're changing the documented
> > behavior.  And as I mentioned in the other thread related on-going
> > thread, perhaps "ethmacskip" should play a role in preserving existing
> > behavior?
> 
> We have way too many ways to do the same thing - nearly, just a
> little different :-(

Well, in this case I'm not sure that's the right problem to point at.
We can just set ethmacskip as a bit of corner-case functionality and
move on.

Because honestly, the more I read this, the more I think
https://patchwork.ozlabs.org/project/uboot/patch/2025121152.3470910-1-mich...@walle.cc/
is essentially the right direction.  There's no reason for 'net list' to
be using the environment here when ->enetaddr is what's being used by
the stack.  The use case of "I want to make my locally administered MAC
persist because my USB ethernet adapter lacks a MAC address" is solved
via the environment already.

-- 
Tom

signature.asc
Description: PGP signature

[PATCH 1/1] scripts: update spelling.txt from upstream Linux

2021-11-16 Thread Heinrich Schuchardt

This list is used by checkpatch.pl. The Linux v5.15 version has several
words that where mispelled in U-Boot too.

Signed-off-by: Heinrich Schuchardt 
---
 scripts/spelling.txt | 365 ++-
 1 file changed, 360 insertions(+), 5 deletions(-)

diff --git a/scripts/spelling.txt b/scripts/spelling.txt
index 9a058cff49..17fdc620d5 100644
--- a/scripts/spelling.txt
+++ b/scripts/spelling.txt
@@ -9,7 +9,12 @@
 #
 abandonning||abandoning
 abigious||ambiguous
+abitrary||arbitrary
 abitrate||arbitrate
+abnornally||abnormally
+abnrormal||abnormal
+abord||abort
+aboslute||absolute
 abov||above
 abreviated||abbreviated
 absense||absence
@@ -17,6 +22,7 @@ absolut||absolute
 absoulte||absolute
 acccess||access
 acceess||access
+accelaration||acceleration
 acceleratoin||acceleration
 accelleration||acceleration
 accesing||accessing
@@ -25,6 +31,7 @@ accessable||accessible
 accesss||access
 accidentaly||accidentally
 accidentually||accidentally
+acclerated||accelerated
 accoding||according
 accomodate||accommodate
 accomodates||accommodates
@@ -34,8 +41,11 @@ accout||account
 accquire||acquire
 accquired||acquired
 accross||across
+accumalate||accumulate
+accumalator||accumulator
 acessable||accessible
 acess||access
+acessing||accessing
 achitecture||architecture
 acient||ancient
 acitions||actions
@@ -49,7 +59,9 @@ activete||activate
 actived||activated
 actualy||actually
 acumulating||accumulating
+acumulative||accumulative
 acumulator||accumulator
+acutally||actually
 adapater||adapter
 addional||additional
 additionaly||additionally
@@ -58,18 +70,22 @@ addres||address
 adddress||address
 addreses||addresses
 addresss||address
+addrress||address
 aditional||additional
 aditionally||additionally
 aditionaly||additionally
 adminstrative||administrative
 adress||address
 adresses||addresses
+adrresses||addresses
+advertisment||advertisement
 adviced||advised
 afecting||affecting
 againt||against
 agaist||against
 aggreataon||aggregation
 aggreation||aggregation
+ajust||adjust
 albumns||albums
 alegorical||allegorical
 algined||aligned
@@ -77,6 +93,7 @@ algorith||algorithm
 algorithmical||algorithmically
 algoritm||algorithm
 algoritms||algorithms
+algorithmn||algorithm
 algorrithm||algorithm
 algorritm||algorithm
 aligment||alignment
@@ -88,6 +105,7 @@ alloated||allocated
 allocatote||allocate
 allocatrd||allocated
 allocte||allocate
+allocted||allocated
 allpication||application
 alocate||allocate
 alogirhtms||algorithms
@@ -95,11 +113,16 @@ alogrithm||algorithm
 alot||a lot
 alow||allow
 alows||allows
+alreay||already
+alredy||already
 altough||although
 alue||value
 ambigious||ambiguous
+ambigous||ambiguous
 amoung||among
 amout||amount
+amplifer||amplifier
+amplifyer||amplifier
 an union||a union
 an user||a user
 an userspace||a userspace
@@ -130,6 +153,7 @@ arbitary||arbitrary
 architechture||architecture
 arguement||argument
 arguements||arguments
+arithmatic||arithmetic
 aritmetic||arithmetic
 arne't||aren't
 arraival||arrival
@@ -138,27 +162,42 @@ artillary||artillery
 asign||assign
 asser||assert
 assertation||assertion
+assertting||asserting
+assgined||assigned
 assiged||assigned
 assigment||assignment
 assigments||assignments
 assistent||assistant
+assocaited||associated
+assocating||associating
 assocation||association
 associcated||associated
 assotiated||associated
+asssert||assert
 assum||assume
 assumtpion||assumption
 asuming||assuming
 asycronous||asynchronous
 asynchnous||asynchronous
+asynchromous||asynchronous
+asymetric||asymmetric
+asymmeric||asymmetric
+atleast||at least
 atomatically||automatically
 atomicly||atomically
 atempt||attempt
+atrributes||attributes
 attachement||attachment
+attatch||attach
 attched||attached
+attemp||attempt
 attemps||attempts
 attemping||attempting
+attepmpt||attempt
+attnetion||attention
 attruibutes||attributes
 authentification||authentication
+authenicated||authenticated
 automaticaly||automatically
 automaticly||automatically
 automatize||automate
@@ -172,6 +211,7 @@ avaible||available
 availabe||available
 availabled||available
 availablity||availability
+availaible||available
 availale||available
 availavility||availability
 availble||available
@@ -205,28 +245,42 @@ boardcast||broadcast
 borad||board
 boundry||boundary
 brievely||briefly
+brigde||bridge
+broadcase||broadcast
 broadcat||broadcast
+bufer||buffer
+bufufer||buffer
 cacluated||calculated
+caculate||calculate
 caculation||calculation
+cadidate||candidate
+cahces||caches
 calender||calendar
 calescing||coalescing
 calle||called
 callibration||calibration
+callled||called
+callser||caller
 calucate||calculate
 calulate||calculate
 cancelation||cancellation
 cancle||cancel
+canot||cannot
 capabilites||capabilities
+capabilties||capabilities
 capabilty||capability
 capabitilies||capabilities
+capablity||capability
 capatibilities||capabilities
 capapbilities||capabilities
+caputure||capture
 carefuly||carefully
 cariage||carriage
 catagory||category
 cehck||check

[PATCH v5 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:

- 1GiB DDR4 RAM
- 16 GiB eMMC
- SD card
- Gigabit ethernet
- USBOTG1 peripheral - fastboot

Signed-off-by: Ariel D'Alessandro 
---
 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 256 
 arch/arm/dts/imx8mn-var-som-symphony.dts  | 240 
 arch/arm/dts/imx8mn-var-som.dtsi  | 547 ++
 arch/arm/mach-imx/imx8m/Kconfig   |   9 +
 board/variscite/imx8mn_var_som/Kconfig|  17 +
 board/variscite/imx8mn_var_som/MAINTAINERS|   7 +
 board/variscite/imx8mn_var_som/Makefile   |  12 +
 board/variscite/imx8mn_var_som/ddr4_timing.c  | 528 +
 .../variscite/imx8mn_var_som/imx8mn_var_som.c |  30 +
 .../imx8mn_var_som/imximage-8mn-ddr4.cfg  |  10 +
 board/variscite/imx8mn_var_som/spl.c  |  93 +++
 configs/imx8mn_var_som_defconfig  |  98 
 doc/board/index.rst   |   1 +
 doc/board/variscite/imx8mn_var_som.rst|  56 ++
 doc/board/variscite/index.rst |   9 +
 include/configs/imx8mn_var_som.h  |  90 +++
 17 files changed, 2004 insertions(+)
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts
 create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi
 create mode 100644 board/variscite/imx8mn_var_som/Kconfig
 create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS
 create mode 100644 board/variscite/imx8mn_var_som/Makefile
 create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c
 create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c
 create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg
 create mode 100644 board/variscite/imx8mn_var_som/spl.c
 create mode 100644 configs/imx8mn_var_som_defconfig
 create mode 100644 doc/board/variscite/imx8mn_var_som.rst
 create mode 100644 doc/board/variscite/index.rst
 create mode 100644 include/configs/imx8mn_var_som.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index cc34da7bd83..8d27876fa0e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -901,6 +901,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mn-ddr4-evk.dtb \
imx8mq-cm.dtb \
imx8mn-evk.dtb \
+   imx8mn-var-som-symphony.dtb \
imx8mq-evk.dtb \
imx8mm-beacon-kit.dtb \
imx8mn-beacon-kit.dtb \
diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi 
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
new file mode 100644
index 000..ce475885df6
--- /dev/null
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -0,0 +1,256 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Collabora Ltd.
+ */
+
+/ {
+   binman: binman {
+   multiple-images;
+   };
+
+   wdt-reboot {
+   compatible = "wdt-reboot";
+   wdt = <>;
+   u-boot,dm-spl;
+   };
+};
+
+&{/soc@0} {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b} {
+   u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a2/pmic@4b/regulators} {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+   /delete-property/ assigned-clocks;
+   /delete-property/ assigned-clock-parents;
+   /delete-property/ assigned-clock-rates;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_24m {
+   u-boot,dm-pre-reloc;
+   u-boot,dm-spl;
+};
+
+_i2c1 {
+   u-boot,dm-spl;
+};
+
+_pmic {
+   u-boot,dm-spl;
+};
+
+_reg_usdhc2_vmmc {
+   u-boot,dm-spl;
+};
+
+_uart4 {
+   u-boot,dm-spl;
+};
+
+_usdhc2 {
+   u-boot,dm-spl;
+};
+
+_usdhc3 {
+   u-boot,dm-spl;
+};
+
+_wdog {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot-spl-ddr {
+   align = <4>;
+   align-size = <4>;
+   filename = "u-boot-spl-ddr.bin";
+   pad-byte = <0xff>;
+
+   u-boot-spl {
+   align-end = <4>;
+   filename = "u-boot-spl.bin";
+   };
+
+   1d-imem {
+   filename = "ddr4_imem_1d.bin";
+   size = <0x8000>;
+   type = "blob-ext";
+   };
+
+   1d_dmem {
+   filename = "ddr4_dmem_1d.bin";
+   size = <0x4000>;
+   type = "blob-ext";
+   };
+
+   2d_imem {
+   filename =

[PATCH v5 0/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Changes in v5:
* Fixed documentation.

Changes in v4:
* Added board documentation.
* Cleaned up board config.

Changes in v3:
* Picked device tree from kernel.
* Properly added MAINTAINERS entry.
* Removed CONFIG_SPL_BUILD anti-pattern in board config.

Changes in v2:
* Reordered dt properties alphabetically.
* Removed downstream stuff in bootargs.
* Fixed binman configuration.
* Several code styling fixes.

Ariel D'Alessandro (1):
  imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

 arch/arm/dts/Makefile |   1 +
 .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 256 
 arch/arm/dts/imx8mn-var-som-symphony.dts  | 240 
 arch/arm/dts/imx8mn-var-som.dtsi  | 547 ++
 arch/arm/mach-imx/imx8m/Kconfig   |   9 +
 board/variscite/imx8mn_var_som/Kconfig|  17 +
 board/variscite/imx8mn_var_som/MAINTAINERS|   7 +
 board/variscite/imx8mn_var_som/Makefile   |  12 +
 board/variscite/imx8mn_var_som/ddr4_timing.c  | 528 +
 .../variscite/imx8mn_var_som/imx8mn_var_som.c |  30 +
 .../imx8mn_var_som/imximage-8mn-ddr4.cfg  |  10 +
 board/variscite/imx8mn_var_som/spl.c  |  93 +++
 configs/imx8mn_var_som_defconfig  |  98 
 doc/board/index.rst   |   1 +
 doc/board/variscite/imx8mn_var_som.rst|  56 ++
 doc/board/variscite/index.rst |   9 +
 include/configs/imx8mn_var_som.h  |  90 +++
 17 files changed, 2004 insertions(+)
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx8mn-var-som-symphony.dts
 create mode 100644 arch/arm/dts/imx8mn-var-som.dtsi
 create mode 100644 board/variscite/imx8mn_var_som/Kconfig
 create mode 100644 board/variscite/imx8mn_var_som/MAINTAINERS
 create mode 100644 board/variscite/imx8mn_var_som/Makefile
 create mode 100644 board/variscite/imx8mn_var_som/ddr4_timing.c
 create mode 100644 board/variscite/imx8mn_var_som/imx8mn_var_som.c
 create mode 100644 board/variscite/imx8mn_var_som/imximage-8mn-ddr4.cfg
 create mode 100644 board/variscite/imx8mn_var_som/spl.c
 create mode 100644 configs/imx8mn_var_som_defconfig
 create mode 100644 doc/board/variscite/imx8mn_var_som.rst
 create mode 100644 doc/board/variscite/index.rst
 create mode 100644 include/configs/imx8mn_var_som.h

-- 
2.30.2

Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Tom Rini

On Tue, Nov 16, 2021 at 11:26:01AM -0300, Ariel D'Alessandro wrote:

> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
> 
> - 1GiB DDR4 RAM
> - 16 GiB eMMC
> - SD card
> - Gigabit ethernet
> - USBOTG1 peripheral - fastboot
> 
> Signed-off-by: Ariel D'Alessandro 
> ---
>  arch/arm/dts/Makefile |   1 +
>  .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 256 
>  arch/arm/dts/imx8mn-var-som-symphony.dts  | 240 
>  arch/arm/dts/imx8mn-var-som.dtsi  | 547 ++
>  arch/arm/mach-imx/imx8m/Kconfig   |   9 +
>  board/variscite/imx8mn_var_som/Kconfig|  17 +
>  board/variscite/imx8mn_var_som/MAINTAINERS|   7 +
>  board/variscite/imx8mn_var_som/Makefile   |  12 +
>  board/variscite/imx8mn_var_som/ddr4_timing.c  | 528 +
>  .../variscite/imx8mn_var_som/imx8mn_var_som.c |  30 +
>  .../imx8mn_var_som/imximage-8mn-ddr4.cfg  |  10 +
>  board/variscite/imx8mn_var_som/spl.c  |  93 +++
>  configs/imx8mn_var_som_defconfig  |  98 
>  doc/board/variscite/imx8mn_var_som.rst|  56 ++
>  doc/board/variscite/index.rst |   9 +

You need to update doc/board/index.rst as well, otherwise you get:
Warning, treated as error:
/home/trini/work/u-boot/u-boot/doc/board/variscite/index.rst:document isn't 
included in any toctree
make[1]: *** [doc/Makefile:68: htmldocs] Error 2
make: *** [Makefile:2250: htmldocs] Error 2

The easiest way to test doc building is:
$ virtualenv -p /usr/bin/python3 /tmp/venv
$ ( . /tmp/venv/bin/activate ; pip install -r doc/sphinx/requirements.txt ; 
make htmldocs)

Thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] doc: fix typos in trace.rst

2021-11-16 Thread Heinrich Schuchardt

Fix obvious typos. Use US spelling consistently.

Signed-off-by: Heinrich Schuchardt 
---
 doc/develop/trace.rst | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/doc/develop/trace.rst b/doc/develop/trace.rst
index 7776c48428..09f5745a90 100644
--- a/doc/develop/trace.rst
+++ b/doc/develop/trace.rst
@@ -4,7 +4,7 @@
 Tracing in U-Boot
 =
 
-U-Boot supports a simple tracing feature which allows a record of excecution
+U-Boot supports a simple tracing feature which allows a record of execution
 to be collected and sent to a host machine for analysis. At present the
 main use for this is to profile boot time.
 
@@ -161,10 +161,10 @@ limit of the trace buffer size you have specified. Once 
that is exhausted
 no more data will be collected.
 
 Collecting trace data has an affect on execution time/performance. You
-will notice this particularly with trvial functions - the overhead of
+will notice this particularly with trivial functions - the overhead of
 recording their execution may even exceed their normal execution time.
 In practice this doesn't matter much so long as you are aware of the
-effect. Once you have done your optimisations, turn off tracing before
+effect. Once you have done your optimizations, turn off tracing before
 doing end-to-end timing.
 
 The best time to start tracing is right at the beginning of U-Boot. The
@@ -184,7 +184,7 @@ the OS. In practical terms, U-Boot runs the 'fakegocmd' 
environment
 variable at this point. This variable should have a short script which
 collects the trace data and writes it somewhere.
 
-Trace data collection relies on a microsecond timer, accesed through
+Trace data collection relies on a microsecond timer, accessed through
 timer_get_us(). So the first think you should do is make sure that
 this produces sensible results for your board. Suitable sources for
 this timer include high resolution timers, PWMs or profile timers if
@@ -285,7 +285,7 @@ Options
 Specify U-Boot map file
 
 -p 
-Specifiy profile/trace file
+Specify profile/trace file
 
 Commands:
 
@@ -315,11 +315,11 @@ time:
 2. Build U-Boot with tracing and run it. Note the difference in boot time
(it is common for tracing to add 10% to the time)
 
-3. Collect the trace information as descibed above. Use this to find where
+3. Collect the trace information as described above. Use this to find where
all the time is being spent.
 
-4. Take a look at that code and see if you can optimise it. Perhaps it is
-   possible to speed up the initialisation of a device, or remove an unused
+4. Take a look at that code and see if you can optimize it. Perhaps it is
+   possible to speed up the initialization of a device, or remove an unused
feature.
 
 5. Rebuild, run and collect again. Compare your results.
-- 
2.32.0

Re: [PATCH] makefile: add missing semicolons

2021-11-16 Thread Tom Rini

On Fri, Nov 05, 2021 at 04:20:24PM +0100, Angelo Dureghello wrote:

> On some distributions, as Debian GNU 11, this targets fails
> with errors.
> 
> Signed-off-by: Angelo Dureghello 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm64: relocate-rela: Add support for ld.lld

2021-11-16 Thread Tom Rini

On Wed, Oct 20, 2021 at 09:31:32PM +, Alistair Delva wrote:

> Cap end of relocations by the binary size.
> 
> Linkers like to insert some auxiliary sections between .rela.dyn and
> .bss_start. These sections don't make their way to the final binary, but
> reloc_rela still tries to relocate them, resulting in attempted read
> past the end of file.
> 
> When linking U-Boot with ld.lld, the STATIC_RELA feature (enabled by
> default on arm64) breaks the build. After this patch, U-Boot can be
> linked successfully with and without CONFIG_STATIC_RELA.
> 
> Originally-from: Elena Petrova 
> Signed-off-by: Alistair Delva 
> Cc: David Brazdil 
> Cc: Scott Wood 
> Cc: Tom Rini 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/2] board: rename "tqc" vendor to "tq"

2021-11-16 Thread Tom Rini

On Tue, Nov 02, 2021 at 11:36:45AM +0100, Matthias Schiffer wrote:

> The subdivision name "TQ Components" hasn't been in use for a long time.
> Rename the vendor directory to "tq", which also matches our Device Tree
> vendor prefix.
> 
> Signed-off-by: Matthias Schiffer 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 2/2] board: tq: fix spelling of "TQ-Systems"

2021-11-16 Thread Tom Rini

On Tue, Nov 02, 2021 at 11:36:46AM +0100, Matthias Schiffer wrote:

> "TQ-Systems" is written with a dash.
> 
> Signed-off-by: Matthias Schiffer 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v4 1/1] imx8mn_var_som: Add support for Variscite VAR-SOM-MX8M-NANO board

2021-11-16 Thread Ariel D'Alessandro

Hi Tom,

On 11/16/21 2:52 PM, Tom Rini wrote:
> On Tue, Nov 16, 2021 at 11:26:01AM -0300, Ariel D'Alessandro wrote:
> 
>> Add support for iMX8MN VAR-SOM-MX8M-NANO board. Enables support for:
>>
>> - 1GiB DDR4 RAM
>> - 16 GiB eMMC
>> - SD card
>> - Gigabit ethernet
>> - USBOTG1 peripheral - fastboot
>>
>> Signed-off-by: Ariel D'Alessandro 
>> ---
>>  arch/arm/dts/Makefile |   1 +
>>  .../dts/imx8mn-var-som-symphony-u-boot.dtsi   | 256 
>>  arch/arm/dts/imx8mn-var-som-symphony.dts  | 240 
>>  arch/arm/dts/imx8mn-var-som.dtsi  | 547 ++
>>  arch/arm/mach-imx/imx8m/Kconfig   |   9 +
>>  board/variscite/imx8mn_var_som/Kconfig|  17 +
>>  board/variscite/imx8mn_var_som/MAINTAINERS|   7 +
>>  board/variscite/imx8mn_var_som/Makefile   |  12 +
>>  board/variscite/imx8mn_var_som/ddr4_timing.c  | 528 +
>>  .../variscite/imx8mn_var_som/imx8mn_var_som.c |  30 +
>>  .../imx8mn_var_som/imximage-8mn-ddr4.cfg  |  10 +
>>  board/variscite/imx8mn_var_som/spl.c  |  93 +++
>>  configs/imx8mn_var_som_defconfig  |  98 
>>  doc/board/variscite/imx8mn_var_som.rst|  56 ++
>>  doc/board/variscite/index.rst |   9 +
> 
> You need to update doc/board/index.rst as well, otherwise you get:
> Warning, treated as error:
> /home/trini/work/u-boot/u-boot/doc/board/variscite/index.rst:document isn't 
> included in any toctree
> make[1]: *** [doc/Makefile:68: htmldocs] Error 2
> make: *** [Makefile:2250: htmldocs] Error 2
> 
> The easiest way to test doc building is:
> $ virtualenv -p /usr/bin/python3 /tmp/venv
> $ ( . /tmp/venv/bin/activate ; pip install -r doc/sphinx/requirements.txt ; 
> make htmldocs)

Fixed, thanks a lot for the patience :-)

Re: [PATCH v1 1/1] usb: doc: Fix spelling issues in README.usb

2021-11-16 Thread Tom Rini

On Fri, Nov 12, 2021 at 06:37:47PM +0300, Andy Shevchenko wrote:

> Fix spelling issues in README.usb.
> 
> Signed-off-by: Andy Shevchenko 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] image: Explicitly declare do_bdinfo()

2021-11-16 Thread Tom Rini

On Mon, Nov 08, 2021 at 09:03:38PM +0300, Andy Shevchenko wrote:

> Compiler is not happy:
> 
> common/image-board.c: In function ‘boot_get_kbd’:
> common/image-board.c:902:17: warning: implicit declaration of function 
> ‘do_bdinfo’ [-Wimplicit-function-declaration]
>   902 | do_bdinfo(NULL, 0, 0, NULL);
>   | ^
> 
> Move the forward declaration to a header.
> 
> Signed-off-by: Andy Shevchenko 
> Reviewed-by: Simon Glass 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [BUGFIX PATCH] configs: synquacer: Fix dfu_alt_info to use nor1

2021-11-16 Thread Tom Rini

On Wed, Nov 10, 2021 at 09:40:07AM +0900, Masami Hiramatsu wrote:

> Fix dfu_alt_info to use nor1 instead of the device name.
> This reverts a part of commit 59bd18d4c4d7 ("configs: synquacer:
> Remove mtdparts settings and update DFU setting") because the
> commit a4f2d8341455 ("mtd: spi: nor: force mtd name to "nor%d"")
> changed the mtd device naming scheme to nor%d.
> 
> Signed-off-by: Masami Hiramatsu 
> Acked-by: Ilias Apalodimas 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm: Fix bad memcpy.S str8w macro argument count

2021-11-16 Thread Tom Rini

On Wed, Nov 10, 2021 at 03:04:40PM +0100,  Pierre-Clément Tosi  wrote:

> Remove the extra (empty) argument passed to str8w, causing the following
> error:
> 
>:40:47: error: too many positional arguments
>  str8w r0, r3, r4, r5, r6, r7, r8, r9, ip, , abort=19f
>  ^
>u-boot/arch/arm/lib/memcpy.S:240:5: note: while in macro instantiation
>17: forward_copy_shift pull=16 push=16
>^
> 
> Note: no functional change intended.
> 
> Fixes: d8834a1323af ("arm: Use optimized memcpy and memset from linux")
> Signed-off-by: Pierre-Clément Tosi 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] efi_loader: fix FinalEvent table initial position

2021-11-16 Thread Ilias Apalodimas

When initializing the final event table in create_final_event() we are
setting the initial buffer position to sizeof(*final_event).  Although
we clear the buffer correctly and won't cause any problems,  we should
start logging events starting from zero.
While at it add a cast when defining the final_event.

Signed-off-by: Ilias Apalodimas 
---
 lib/efi_loader/efi_tcg2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 189e4a5ba59c..634556342a7c 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1257,10 +1257,11 @@ static efi_status_t create_final_event(void)
goto out;
 
memset(event_log.final_buffer, 0xff, TPM2_EVENT_LOG_SIZE);
-   final_event = event_log.final_buffer;
+   final_event =
+   (struct efi_tcg2_final_events_table *)event_log.final_buffer;
final_event->number_of_events = 0;
final_event->version = EFI_TCG2_FINAL_EVENTS_TABLE_VERSION;
-   event_log.final_pos = sizeof(*final_event);
+   event_log.final_pos = 0;
ret = efi_install_configuration_table(_guid_final_events,
  final_event);
if (ret != EFI_SUCCESS) {
-- 
2.33.1

Re: [PATCH 10/10] board: sl28: disable random MAC address generation

2021-11-16 Thread Tom Rini

On Mon, Nov 15, 2021 at 11:45:51PM +0100, Michael Walle wrote:

> Nowadays, u-boot (when CONFIG_NET_RANDOM_ETHADDR is set) will set
> enetaddr to a random value if not set and then pass the randomly
> generated MAC address to linux.

First, for clarity I'm not nak'ing this.  I kind of would like to see a
slight reword as I think some things aren't 100% correct, even if the
"save random MAC to ethaddr environment variable" change goes in.  For
example, it's quite long standing that (dev|pdata)->enetaddr populates
"mac-address" and "local-mac-address" and it seems in some older cases
we only set the "local-mac-address" property.

> This is bad for the following reasons:
>  (1) it makes it impossible for linux to detect this error
>  (2) linux won't trigger any fallback mechanism for the case where
>  it didn't find any valid MAC address

This feels in some ways to be a limitation of the binding:
https://www.kernel.org/doc/Documentation/devicetree/bindings/net/ethernet-controller.yaml

And it reads like we really must be populating "mac-address" with that
random one and while providing a blank "local-mac-address" would be a
way to say we don't know the true device one, it seems that wouldn't be
used / noticed?

>  (3) a saveenv will store this randomly generated MAC address in the
>  environment
> 
> Probably, the user will also be unaware that something is wrong. He will
> just get different MAC addresses on each reboot, asking himself why this
> is the case.
> 
> As this board usually have a serial port, the user can just fix this by
> setting the MAC address manually in the environment. Also disable the
> netconsole just in case, because it cannot be guaranteed that it will
> work in any case. After all, this was just a convenience option, because
> the bootloader - right now - doesn't have the ability to read the MAC
> address, which is stored in the OTP. But it is far more important to
> have a clear view of whats wrong with a board and that means we can no
> longer use this Kconfig option.
> 
> Signed-off-by: Michael Walle 
> ---
>  configs/kontron_sl28_defconfig | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/configs/kontron_sl28_defconfig b/configs/kontron_sl28_defconfig
> index af907175f1..7fb6bdbe82 100644
> --- a/configs/kontron_sl28_defconfig
> +++ b/configs/kontron_sl28_defconfig
> @@ -59,8 +59,6 @@ CONFIG_OF_LIST=""
>  CONFIG_ENV_OVERWRITE=y
>  CONFIG_ENV_IS_IN_SPI_FLASH=y
>  CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> -CONFIG_NET_RANDOM_ETHADDR=y
> -CONFIG_NETCONSOLE=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_SCSI_AHCI=y
>  CONFIG_SATA_CEVA=y

Now, an alternate solution here would be to enable these two options
still and write an ft_board_setup() with:
... if ethaddr is in the locally administered pool then
fdt_delprop(... "mac-address");
fdt_delprop(... "local-mac-address");

And that should cause the kernel to fall through the cases to find out
where to get the real MAC from.  I'm not super happy with this at first,
but I also don't see anything clever in the binding we can do.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH] efi_loader: fix FinalEvent table initial position

2021-11-16 Thread Ilias Apalodimas

Hi Heinrich,


On Wed, 17 Nov 2021 at 01:24, Ilias Apalodimas
 wrote:
>
> When initializing the final event table in create_final_event() we are
> setting the initial buffer position to sizeof(*final_event).  Although
> we clear the buffer correctly and won't cause any problems,  we should
> start logging events starting from zero.
> While at it add a cast when defining the final_event.
>
> Signed-off-by: Ilias Apalodimas 
> ---
>  lib/efi_loader/efi_tcg2.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index 189e4a5ba59c..634556342a7c 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -1257,10 +1257,11 @@ static efi_status_t create_final_event(void)
> goto out;
>
> memset(event_log.final_buffer, 0xff, TPM2_EVENT_LOG_SIZE);
> -   final_event = event_log.final_buffer;
> +   final_event =
> +   (struct efi_tcg2_final_events_table *)event_log.final_buffer;
> final_event->number_of_events = 0;
> final_event->version = EFI_TCG2_FINAL_EVENTS_TABLE_VERSION;
> -   event_log.final_pos = sizeof(*final_event);
> +   event_log.final_pos = 0;
> ret = efi_install_configuration_table(_guid_final_events,
>   final_event);
> if (ret != EFI_SUCCESS) {
> --
> 2.33.1
>

After sending this I just realized it's wrong.  The current code is
correct, since we have to account for the number of events and version

Sorry for the noise

Cheers
/Ilias

Re: Testing pci_mvebu.c with Kirkwood SoCs

2021-11-16 Thread Pali Rohár

On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote:
> Hi Pali,
> 
> While we are at it, this default should be changed in 
> drivers/usb/host/Kconfig.
> 
> config USB_XHCI_MVEBU
> bool "MVEBU USB 3.0 support"
> default y
> 
> Setting this default correctly will save a couple Kbytes for other boards.
> default y if ARCH_MVEBU

Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means
that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So
"default y if ARCH_MVEBU" is same as "default y".

If you have mvebu board when mvebu xhci controller is unused, you can
disable this option and save some space. I see that other xhci drivers
have also "default y" so seems that this is the standard default option.

Re: Testing pci_mvebu.c with Kirkwood SoCs

2021-11-16 Thread Tony Dinh

Hi Pali,

While we are at it, this default should be changed in drivers/usb/host/Kconfig.

config USB_XHCI_MVEBU
bool "MVEBU USB 3.0 support"
default y

Setting this default correctly will save a couple Kbytes for other boards.
default y if ARCH_MVEBU

Thanks,
Tony

On Fri, Nov 12, 2021 at 3:24 PM Tony Dinh  wrote:
>
> On Fri, Nov 12, 2021 at 2:42 PM Pali Rohár  wrote:
> >
> > On Friday 12 November 2021 13:46:29 Tony Dinh wrote:
> > > Hi Stefan & Pali,
> > >
> > > On Fri, Nov 12, 2021 at 7:06 AM Pali Rohár  wrote:
> > > >
> > > > On Friday 12 November 2021 15:36:31 Stefan Roese wrote:
> > > > > On 11/11/21 22:10, Pali Rohár wrote:
> > > > > > On Wednesday 10 November 2021 16:04:20 Tony Dinh wrote:
> > > > > > > I've also tried mdelay(3000), just to be sure. The result was the 
> > > > > > > same
> > > > > > > hang in 'usb start'.
> > > > > >
> > > > > > Ok. So put pci_init() into board_late_init().
> > > > > >
> > > > > > There are some more cleanup and fixes patches for pci_mvebu.c on 
> > > > > > mailing
> > > > > > list. After they are merged I will prepare and send final PCI 
> > > > > > Kirkwood
> > > > > > patch for testing.
> > > > >
> > > > > Chiming in a bit late in this discussion:
> > > > >
> > > > > Is an explicit call to pci_init() necessary in this Kirwood case? 
> > > > > IIRC,
> > > > > the DM infrastructure should make sure that all device are probed - 
> > > > > but
> > > > > only when really needed. So if you don't need PCI in the boot process
> > > > > at all, then it's not probed at all. Or if you set CONFIG_PCI_PNP this
> > > > > will be done always. Then there should be no need for the additional
> > > > > "pci enum".
> > > >
> > > > CONFIG_PCI_PNP probe and initialize all devices behind host bridge.
> > > > CONFIG_PCI_INIT_R probe and initialize host bridge (this is done by
> > > > calling pci_init()). Based on tests (see discussion in this thread) it
> > > > looks like that CONFIG_PCI_INIT_R calls pci_init() too early and
> > > > initialization is failing. So unsetting CONFIG_PCI_INIT_R and calling
> > > > pci_init() manually from board_late_init() (which is called later than
> > > > CONFIG_PCI_INIT_R) seems to fix these issues. No idea why...
> > > > > I might be missing something - did not check in depth.
> > >
> > > I think this must be the problem. Sorry I've missed this:
> > >
> > > config USB_XHCI_MVEBU
> > > bool "MVEBU USB 3.0 support"
> > > default y
> > > depends on ARCH_MVEBU
> > > select DM_REGULATOR
> > > help
> > >   Choose this option to add support for USB 3.0 driver on mvebu
> > >   SoCs, which includes Armada8K, Armada3700 and other Armada
> > >   family SoCs.
> >
> > This is used for native USB 3.0 controller in Marvell SoC (connected via
> > serdes).
> >
> > But you wrote and sent pci output, that you have PCIe-based USB
> > controller connected via PCIe.
>
> Ah, got it.
>
> Thanks,
> Tony
>
> > > So I'll need rebuild with "depends on (ARCH_MVEBU || ARCH_KIRKWOOD)"
> > > and do some more testing.
> > >
> > > Thanks,
> > > Tony
> > >
> > > > >
> > > > > Thanks,
> > > > > Stefan

Re: Testing pci_mvebu.c with Kirkwood SoCs

2021-11-16 Thread Tony Dinh

Hi Pali,

On Tue, Nov 16, 2021 at 2:37 PM Pali Rohár  wrote:
>
> On Tuesday 16 November 2021 14:26:56 Tony Dinh wrote:
> > Hi Pali,
> >
> > While we are at it, this default should be changed in 
> > drivers/usb/host/Kconfig.
> >
> > config USB_XHCI_MVEBU
> > bool "MVEBU USB 3.0 support"
> > default y
> >
> > Setting this default correctly will save a couple Kbytes for other boards.
> > default y if ARCH_MVEBU
>
> Hello! USB_XHCI_MVEBU has currently "depends on ARCH_MVEBU" which means
> that USB_XHCI_MVEBU cannot be enabled when ARCH_MVEBU is disabled. So
> "default y if ARCH_MVEBU" is same as "default y".

Ah, thanks. This "depends on ARCH_MVEBU" was added in the latest
master tree. I'm switching back and forth between the 2021.10 tag and
master so I did not see this in the 2021.10 tree.

Thanks,
Tony

> If you have mvebu board when mvebu xhci controller is unused, you can
> disable this option and save some space. I see that other xhci drivers
> have also "default y" so seems that this is the standard default option.

Re: [PATCH] net: uclass: Save ethernet MAC address when generated

2021-11-16 Thread Wolfgang Denk

Dear Tom,

In message <2026184146.GF24579@bill-the-cat> you wrote:
> 
> Because honestly, the more I read this, the more I think
> https://patchwork.ozlabs.org/project/uboot/patch/2025121152.3470910-1-m=
> ich...@walle.cc/
> is essentially the right direction.  There's no reason for 'net list' to
> be using the environment here when ->enetaddr is what's being used by
> the stack.  The use case of "I want to make my locally administered MAC
> persist because my USB ethernet adapter lacks a MAC address" is solved
> via the environment already.

If the MAC address is not placed in the environment, then how can a
user query the currently used MAC address?  All documentation says
basically: run "printenv ethaddr".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Plan to throw one away. You will anyway."
  - Fred Brooks, "The Mythical Man Month"

Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature

2021-11-16 Thread Michael Walle

> From: Sahil Malhotra 
> 
> This patch enables the DTB overlay feature for LS platforms.

Could you please add some description what this is doing and for what
this is intended? To have a "DTB overlay feature", it is enough to just
enable CONFIG_OF_LIBFDT_OVERLAY.

Apparently you're adding an overlay passed by optee. Doesn't this have to
be applied to u-boot's control dtb too?

-michael

1 2 >

1 - 100 of 119 matches

Mail list logo