Re: RFC: exclude partitions from efi_selftest

[AKASHI Takahiro]

On Wed, Sep 15, 2021 at 02:00:31PM +0200, Mark Kettenis wrote:
> > Date: Wed, 15 Sep 2021 12:42:16 +0200
> > From: Heinrich  Schuchardt 
> > 
> > Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick 
> > :
> > >Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
> > >> On 9/14/21 4:56 PM, Michael Lawnick wrote:
> > >>> Hi,
> > >>>
> > >>> in our environment we get error on efi_selftest if one of several SSD
> > >>> partitions isn't properly initialized (due to some other error, but
> > >>> that's a different topic). I tried to track down to where the partitions
> > >>> get registered for test but got a bit lost so I request advice from you.
> > >>
> > >> When the UEFI sub-system is intialized we call efi_disk_register(). If
> > >> it fails, we don't enter the UEFI sub-system.
> > >>
> > >> Are you able to identify where efi_disk_register() fails?
> > >
> > >The system starts up properly.
> > >This is what I see:
> > >ASIM-CN10KAS> efiload $loadaddr
> > >Loaded EFI App image at 0x4008 with 0x216000 bytes
> > >ASIM-CN10KAS> bootefi $loadaddr $fdtaddr
> > >Scanning disk sd...@8240.blk...
> > >** Unrecognized filesystem type **
> > >** Unrecognized filesystem type **
> > >** Unrecognized filesystem type **
> > 
> > This is not an error. Just an info.
> 
> It is somewhat annoying though.  The way disks are partitioned on the
> Apple M1 systems, there are several Apple native partition types that
> need to be retained and that U-Boot doesn't support.  So you see a lot
> of these warnings.
> 
> Or maybe we should have a whitelist of partition types not to warn
> about?

This message is not UEFI specific, but generic filesystem code
generates it. So you could
1) At fs_probe_unsupported() in fs/fs.c,
   change log_err() to log_warning() [or log_info()]
2) Set CONFIG_DEFAULT_LOG_LEVEL to 3(error) [or 4(warning)]
to suppress the message.

Or you may simply want to modify _log() so as to add a preamble,
like "WARN:", in front of the message.

-Takahiro Akashi

Re: [PATCH 3/3] efi_loader: add DeployedMode and AuditMode variable measurement

[Heinrich Schuchardt]

On 9/15/21 7:15 AM, Masahisa Kojima wrote:

This commit adds the DeployedMode and AuditMode variable
measurement required in TCG PC Client PFP Spec.

Signed-off-by: Masahisa Kojima 
---
  lib/efi_loader/efi_tcg2.c | 47 +++
  1 file changed, 47 insertions(+)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 35810615ed..427d6e22b1 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -12,6 +12,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -1828,6 +1829,50 @@ out:
return ret;
  }

+/**
+ * tcg2_measure_deployed_audit_mode() - measure deployedmode and auditmode
+ *
+ * @dev:   TPM device
+ *
+ * Return: status code
+ */
+static efi_status_t tcg2_measure_deployed_audit_mode(struct udevice *dev)
+{
+   u8 deployed_mode;
+   u8 audit_mode;
+   efi_uintn_t size;
+   efi_status_t ret;
+   u32 pcr_index;
+
+   size = sizeof(deployed_mode);
+   ret = efi_get_variable_int(L"DeployedMode", &efi_global_variable_guid,
+  NULL, &size, &deployed_mode, NULL);
+   if (ret != EFI_SUCCESS)
+   return ret;


Why should AuditMode not be measured if DeployedMode does not exist?

Could we handle these variables in a loop over an array containing dbt
and dbr reduce code duplication?

Best regards

Heinrich


+
+   pcr_index = (deployed_mode ? 1 : 7);
+
+   ret = tcg2_measure_variable(dev, pcr_index,
+   EV_EFI_VARIABLE_DRIVER_CONFIG,
+   L"DeployedMode",
+   &efi_global_variable_guid,
+   size, &deployed_mode);
+
+   size = sizeof(audit_mode);
+   ret = efi_get_variable_int(L"AuditMode", &efi_global_variable_guid,
+  NULL, &size, &audit_mode, NULL);
+   if (ret != EFI_SUCCESS)
+   return ret;
+
+   ret = tcg2_measure_variable(dev, pcr_index,
+   EV_EFI_VARIABLE_DRIVER_CONFIG,
+   L"AuditMode",
+   &efi_global_variable_guid,
+   size, &audit_mode);
+
+   return ret;
+}
+
  /**
   * tcg2_measure_secure_boot_variable() - measure secure boot variables
   *
@@ -1891,6 +1936,8 @@ static efi_status_t 
tcg2_measure_secure_boot_variable(struct udevice *dev)
free(data);
}

+   ret = tcg2_measure_deployed_audit_mode(dev);
+
  error:
return ret;
  }

[PATCH next] lib: hash-checksum: Use DM_HASH if supported

[Chia-Wei Wang]

Use DM_HASH to perform hashing operations if supported.
Thus either SW or HW-assisted hashing could be leveraged.

Signed-off-by: Chia-Wei Wang 
---
 lib/hash-checksum.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/lib/hash-checksum.c b/lib/hash-checksum.c
index d732ecc38f..f30873db38 100644
--- a/lib/hash-checksum.c
+++ b/lib/hash-checksum.c
@@ -10,6 +10,10 @@
 #include 
 #include 
 #include 
+#if defined(CONFIG_DM_HASH)
+#include 
+#include 
+#endif
 #else
 #include "fdt_host.h"
 #endif
@@ -20,6 +24,38 @@ int hash_calculate(const char *name,
const struct image_region region[],
int region_count, uint8_t *checksum)
 {
+#if !defined(USE_HOSTCC) && defined(CONFIG_DM_HASH)
+   int i, rc;
+   enum HASH_ALGO hash_algo;
+   struct udevice *dev;
+   void *ctx;
+
+   rc = uclass_get_device(UCLASS_HASH, 0, &dev);
+   if (rc) {
+   debug("failed to get hash device, rc=%d\n", rc);
+   return -1;
+   }
+
+   hash_algo = hash_algo_lookup_by_name(name);
+   if (hash_algo == HASH_ALGO_INVALID) {
+   debug("Unsupported hash algorithm\n");
+   return -1;
+   };
+
+   rc = hash_init(dev, hash_algo, &ctx);
+   if (rc)
+   return rc;
+
+   for (i = 0; i < region_count; i++) {
+   rc = hash_update(dev, ctx, region[i].data, region[i].size);
+   if (rc)
+   return rc;
+   }
+
+   rc = hash_finish(dev, ctx, checksum);
+   if (rc)
+   return rc;
+#else
struct hash_algo *algo;
int ret = 0;
void *ctx;
@@ -47,6 +83,7 @@ int hash_calculate(const char *name,
ret = algo->hash_finish(algo, ctx, checksum, algo->digest_size);
if (ret)
return ret;
+#endif
 
return 0;
 }
-- 
2.17.1

[PATCH] ARM: dts: ast2600: Make WDT by default disabled

[Chia-Wei Wang]

The WDT devices described in the general .dtsi file
should be marked as "disabled" by default.

A WDT should be then enabled in the board specific
.dts file on demands.

Signed-off-by: Chia-Wei Wang 
---
 arch/arm/dts/ast2600.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index ac0f08b7ea..f121f547e6 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -474,21 +474,25 @@
wdt1: watchdog@1e785000 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e785000 0x40>;
+   status = "disabled";
};
 
wdt2: watchdog@1e785040 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e785040 0x40>;
+   status = "disabled";
};
 
wdt3: watchdog@1e785080 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e785080 0x40>;
+   status = "disabled";
};
 
wdt4: watchdog@1e7850C0 {
compatible = "aspeed,ast2600-wdt";
reg = <0x1e7850C0 0x40>;
+   status = "disabled";
};
 
lpc: lpc@1e789000 {
-- 
2.17.1

RE: [PATCH v3 25/29] arm: dts: ls1028a: move the PCI I/O window to match

[Z.Q. Hou]

> -Original Message-
> From: Vladimir Oltean 
> Sent: 2021年9月15日 8:13
> To: Michael Walle ; Z.Q. Hou 
> Cc: u-boot@lists.denx.de; Jagan Teki ;
> Priyanka Jain ; Tom Rini ;
> Peter Griffin ; Manivannan Sadhasivam
> 
> Subject: Re: [PATCH v3 25/29] arm: dts: ls1028a: move the PCI I/O window
> to match
> 
> On Thu, Sep 02, 2021 at 06:45:54PM +0200, Michael Walle wrote:
> > To make the synchronization of the u-boot device tree with the one
> > from linux easier, move the I/O window to the one which is specified
> > in the linux device tree. The actual value shouldn't matter as long as
> > it mapped to the corresponding memory window of the PCIe controller
> > which is a 32GiB window at 80__h (first controller) or
> > 88__h (second controller).
> >
> > Signed-off-by: Michael Walle 
> > ---
> >  arch/arm/dts/fsl-ls1028a.dtsi | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/dts/fsl-ls1028a.dtsi
> > b/arch/arm/dts/fsl-ls1028a.dtsi index 3ef710bb3d..f11e75032b 100644
> > --- a/arch/arm/dts/fsl-ls1028a.dtsi
> > +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> > @@ -352,7 +352,7 @@
> > #size-cells = <2>;
> > device_type = "pci";
> > bus-range = <0x0 0xff>;
> > -   ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
> 0x0001   /* downstream I/O */
> > +   ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
> 0x0001   /* downstream I/O */
> >   0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> > };
> >
> > @@ -365,7 +365,7 @@
> > #size-cells = <2>;
> > device_type = "pci";
> > bus-range = <0x0 0xff>;
> > -   ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
> 0x0001   /* downstream I/O */
> > +   ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
> 0x0001   /* downstream I/O */
> >   0x8200 0x0 0x4000 0x88 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> > };
> >
> > --
> > 2.30.2
> >
> 
> Zhiqiang, can you please review this patch?

Reviewed-by: Hou Zhiqiang 

Re: [GIT PULL] rpi: updates for v2021.10

[Tom Rini]

On Wed, Sep 15, 2021 at 05:39:52PM +0200, Matthias Brugger wrote:

> Hi Tom,
> 
> I know, quite a bit late but here come the updates for RPi for v2021.10.
> Actually most of the patches are fixes.
> 
> Ivan's patch fixes a kernel warning when booting RPi2, as the firmware
> already provides a frambebuffer node.
> 
> Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.
> 
> My SMBIOS patchesfixes an issue that show up with
> e4f8e543f1 ("smbios: Drop the unused Kconfig options").
> Basically the SMBIOS table broke and wasn't readable anymore.
> 
> I think we can argue if the last one is a real fix. In case you just want to
> take the first two so late in the cycle, let me know and I can provide you
> with a separate pull request.
> 
> Regards,
> Matthias
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] apalis/colibri_imx6: move setting bootcmd to defconfig

[Marcel Ziswiler]

Hi Oleksandr

Thanks, just one minor nit-pick below.

On Sun, 2021-09-12 at 22:39 +0300, Oleksandr Suvorov wrote:
> Move setting the default boot command to the
> apalis/colibri_imx6_defconfig. It allows replacing the command
> without code modification.
> 
> Signed-off-by: Oleksandr Suvorov 
> ---
> 
>  configs/apalis_imx6_defconfig  | 1 +
>  configs/colibri_imx6_defconfig | 1 +
>  include/configs/apalis_imx6.h  | 4 
>  include/configs/colibri_imx6.h | 4 
>  4 files changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
> index a0e85ba23a4..a2e0f8e3936 100644
> --- a/configs/apalis_imx6_defconfig
> +++ b/configs/apalis_imx6_defconfig
> @@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
>  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
>  CONFIG_BOOTDELAY=1
> +CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout 
> serial,vidconsole;setenv stdin serial,usbkbd"

I believe, usually we had a space after those semicolons, not?

>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_BOARD_EARLY_INIT_F=y
> diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
> index 47b1cfb1917..bee4e7edd63 100644
> --- a/configs/colibri_imx6_defconfig
> +++ b/configs/colibri_imx6_defconfig
> @@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
>  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
>  CONFIG_BOOTDELAY=1
> +CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout 
> serial,vidconsole;setenv stdin serial,usbkbd"

Ditto.

>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_BOARD_EARLY_INIT_F=y
> diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
> index 12de0105c6c..ade479cb943 100644
> --- a/include/configs/apalis_imx6.h
> +++ b/include/configs/apalis_imx6.h
> @@ -133,10 +133,6 @@
>  #endif
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> BOOTENV \
> -   "bootcmd=run distro_bootcmd ; " \
> -   "usb start ; " \
> -   "setenv stdout serial,vidconsole; " \
> -   "setenv stdin serial,usbkbd\0" \

At least here we definitely did have them (;-p).

> "boot_file=zImage\0" \
> "console=ttymxc0\0" \
> "defargs=enable_wait_mode=off vmalloc=400M\0" \
> diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h
> index 804a144a03e..f91d6b49ea8 100644
> --- a/include/configs/colibri_imx6.h
> +++ b/include/configs/colibri_imx6.h
> @@ -115,10 +115,6 @@
>  #define FDT_FILE "imx6dl-colibri-eval-v3.dtb"
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> BOOTENV \
> -   "bootcmd=run distro_bootcmd; " \
> -   "usb start ; " \
> -   "setenv stdout serial,vidconsole; " \
> -   "setenv stdin serial,usbkbd\0" \
> "boot_file=zImage\0" \
> "console=ttymxc0\0" \
> "defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \

Cheers

Marcel

[RFC PATCH] test/py: Check hashes produced by mkimage against known values

[Alexandru Gagniuc]

Target code and mkimage share the same hashing infrastructure. If one
is wrong, it's very likely that both are wrong in the same way. Thus
testing won't catch hash regressions. This already happened in
commit 92055e138f28 ("image: Drop if/elseif hash selection in
calculate_hash()"). None of the tests caught that CRC32 was broken.

Instead of testing hash_calculate() against itself, create a FIT with
containing a kernel with pre-calculated hashes. Then check the hashes
produced against the known good hashes.

Signed-off-by: Alexandru Gagniuc 

---
Desired:
  $ ./test/py/test.py -k hash
  ...
  test_mkimage_hashes PASSED

Is very cryptic with regards to what is going on. It would be much
nicer to have tests named "crc32", "sha256", and so on. But I don't
know how to do that without several pyton functions each assembling
their own damn FIT.
I think it would also be nicer for the test log to show
test_sha1  PASSED
test_crc32 PASSED  
test_md5   FAILED

 test/py/tests/test_fit_hashes.py| 111 
 test/py/tests/vboot/hash-images.its |  76 +++
 2 files changed, 187 insertions(+)
 create mode 100644 test/py/tests/test_fit_hashes.py
 create mode 100644 test/py/tests/vboot/hash-images.its

diff --git a/test/py/tests/test_fit_hashes.py b/test/py/tests/test_fit_hashes.py
new file mode 100644
index 00..e228ea96d3
--- /dev/null
+++ b/test/py/tests/test_fit_hashes.py
@@ -0,0 +1,111 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2021 Alexandru Gagniuc 
+
+"""
+Check hashes produced by mkimage against known values
+
+This test checks the correctness of mkimage's hashes. by comparing the mkimage
+output of a fixed data block with known good hashes.
+This test doesn't run the sandbox. It only checks the host tool 'mkimage'
+"""
+
+import pytest
+import u_boot_utils as util
+
+kernel_hashes = {
+"sha512" : 
"f18c1486a2c29f56360301576cdfce4dfd8e8e932d0ed8e239a1f314b8ae1d77b2a58cd7fe32e4075e69448e623ce53b0b6aa6ce5626d2c189a5beae29a68d93",
+"sha384" : 
"16e28976740048485d08d793d8bf043ebc7826baf2bc15feac72825ad67530ceb3d09e0deb6932c62a5a0e9f3936baf4",
+"sha256" : 
"2955c56bc1e5050c111ba6e089e0f5342bb47dedf77d87e3f429095feb98a7e5",
+"sha1"   : "652383e1a6d946953e1f65092c9435f6452c2ab7",
+"md5": "4879e5086e4c76128e525b5fe2af55f1",
+"crc32"  : "32eddfdf",
+"crc16-ccitt" : "d4be"
+}
+
+class ReadonlyFitImage(object):
+""" Helper to manipulate a FIT image on disk """
+def __init__(self, cons, file_name):
+self.fit = file_name
+self.cons = cons
+self.hashable_nodes = set()
+
+def __fdt_list(self, path):
+return util.run_and_log(self.cons, f'fdtget -l {self.fit} {path}')
+
+def __fdt_get(self, node, prop):
+val = util.run_and_log(self.cons, f'fdtget {self.fit} {node} {prop}')
+return val.rstrip('\n')
+
+def __fdt_get_sexadecimal(self, node, prop):
+numbers = util.run_and_log(self.cons, f'fdtget -tbx {self.fit} {node} 
{prop}')
+
+sexadecimal = ''
+for num in numbers.rstrip('\n').split(' '):
+sexadecimal += num.zfill(2)
+return sexadecimal
+
+def find_hashable_image_nodes(self):
+for node in self.__fdt_list('/images').split():
+# We only have known hashes for the kernel node
+if 'kernel' not in node:
+continue
+self.hashable_nodes.add(f'/images/{node}')
+
+return self.hashable_nodes
+
+def verify_hashes(self):
+for image in self.hashable_nodes:
+algos = set()
+for node in self.__fdt_list(image).split():
+if "hash-" not in node:
+continue
+
+raw_hash = self.__fdt_get_sexadecimal(f'{image}/{node}', 
'value')
+algo = self.__fdt_get(f'{image}/{node}', 'algo')
+algos.add(algo)
+
+good_hash = kernel_hashes[algo]
+if good_hash != raw_hash:
+raise ValueError(f'{image} Borked hash: {algo}');
+
+# Did we test all the hashes we set out to test?
+missing_algos = kernel_hashes.keys() - algos
+if (missing_algos):
+raise ValueError(f'Missing hashes from FIT: {missing_algos}')
+
+
+@pytest.mark.buildconfigspec('hash')
+@pytest.mark.requiredtool('dtc')
+@pytest.mark.requiredtool('fdtget')
+@pytest.mark.requiredtool('fdtput')
+def test_mkimage_hashes(u_boot_console):
+""" Test that hashes generated by mkimage are correct. """
+
+def assemble_fit_image(dest_fit, its, destdir):
+dtc_args = f'-I dts -O dtb -i {destdir}'
+util.run_and_log(cons, [mkimage, '-D', dtc_args, '-f', its, dest_fit])
+
+def dtc(dts):
+dtb = dts.replace('.dts', '.dtb')
+util.run_and_log(cons, f'dtc {datadir}/{dts} -O dtb -o 
{tempdir}/{dtb}')
+
+cons = u_boot_console
+mkimage = cons.config.build_dir + '/tools/mkimage'
+  

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

[Marek Vasut]

On 9/15/21 7:55 PM, Tom Rini wrote:

On Tue, Sep 14, 2021 at 05:44:25PM -0400, Tom Rini wrote:

On Tue, Sep 14, 2021 at 11:30:01PM +0200, Marek Vasut wrote:

On 9/14/21 10:45 PM, Tom Rini wrote:

On Tue, Sep 14, 2021 at 10:10:22PM +0200, Marek Vasut wrote:

On 9/14/21 9:19 PM, Tom Rini wrote:

On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:


Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
silently defaulted to SF bus mode 0. Now the mode is always updated,
which causes breakage. It seems most SF which are used as boot media
operate in bus mode 0, so switch that as the default.

This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
with mode 3. Marvell Kirkwood and Xilinx microblaze need to be checked
as those might need mode 3.

Signed-off-by: Marek Vasut 
Cc: Aleksandar Gerasimovski 
Cc: Andreas Biessmann 
Cc: Eugen Hristev 
Cc: Michal Simek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Peng Fan 
Cc: Siew Chin Lim 
Cc: Tom Rini 
Cc: Valentin Longchamp 
Cc: Vignesh Raghavendra 


So, some background.  With commit 88e34e5ff76b ("spl: replace
CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
related moved from having their default value of SPI_MODE_3 (which
evaluates to 3) be defined in common/cmd_sf.c if not otherwise defined,
to include/spi_flash.h, and a more visible global default than it was
before.  At that time, the following platforms either set or implied
SPI_MODE_3 should be used:
alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc at91sam9n12ek_nandflash
at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager lschlv2
lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi vf610twr
zynq_zc770_xm010

Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
needs flipping some DIP switches) which has SPI flash by default.  With
current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
reading the whole of flash and crc32'ing it, and getting the same result
back.  So, SPI_MODE_3 seems correct / function here, and likely so on
the rest of the TI platforms listed above.

With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
migrate these values to Kconfig, and a quick spot-check shows that yes,
the migration did not change any values.

A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
platforms have been added (it was 5 years, after all) and those
platforms seem to be where the problems reside.  I'm not sure if or why
SPI_MODE_3 doesn't work on so many new platforms, but I would prefer to
see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to switch
the default to SPI_MODE_0 if there's not a more fundamental problem to
solve on some platforms such that SPI_MODE_3 could / should be enabled.


I rather suspect mode 3 is special case for atmel/am335x and co. and maybe
marvell kirkwood from the list above. So shouldn't we default to 0 and
special-case the two or three instead ?


I guess my question boils down to why is that the right default?  My
argument that 3 is the right default is that it's what it was in
introduction back in b6368467e6a9 ("SPI Flash: Add "sf" command").  But
references to something else such as the Linux Kernel defaults to mode 0
or some SPI specs saying you should default to mode 0 or something else
would be much appreciated.


Probably check a couple of board schematics and SoC datasheets to build up
your own statistics ? In Linux it is 0 because that's likely what most of
the systems expect it to be, and the few odd ones just set it to 3
explicitly there (or enable CPOL/CPHA as needed). My statistics indicates
that I keep running into "oh, here it is also 3, and it should be 0"
recently.

I don't have any of the am335x/atmel boards easily available, so I cannot
check those, hence the CC list.


Sigh, OK.  Lets look at the kernel and there instead of SPI_MODE_N we
have spi-cpol and spi-cpha as properties.  A quick git grep -l spi-cp
arch/arm arch/arm64 shows where we likely do and do not need to use
something other than mode 0.  So yes, mode 0 as a default makes sense,
so long as we also don't break the easily found boards that do need mode
3 (or, mode 1 or 2, as of 

Re: [PATCH v3 1/2] GPIO: fxl6408: Add support for FXL6408 GPIO expander

[Oleksandr Suvorov]

Hi Michal,

On Fri, Sep 10, 2021 at 9:35 AM Michal Simek  wrote:
>
>
>
> On 9/9/21 10:44 PM, Oleksandr Suvorov wrote:
> > From: Oleksandr Suvorov 
> >
> > Initial support for Fairchild's 8 bit I2C gpio expander FXL6408.
> > The CONFIG_FXL6408_GPIO define enables support for such devices.
> >
> > Based on: https://patchwork.kernel.org/patch/9148419/
> >
> > Signed-off-by: Oleksandr Suvorov 
> > Reviewed-by: Simon Glass 
> > Tested-by: Marcel Ziswiler 
> > Signed-off-by: Oleksandr Suvorov 
> > Signed-off-by: Oleksandr Suvorov 
>
> 3 emails for you. Would be the best to choose only one.

Thanks, fixed. That habit to always add '-s' when committing changes :)
>
> > ---
> >
> > Changes in v3:
> > - fix a warning:
> > ...drivers/gpio/gpio-fxl6408.c:348:15: warning: format ‘%ld’
> > expects argument of type ‘long int’, but argument 3 has
> > type ‘int’ [-Wformat=]...
> > - add Tested-by record.
> >
> >  drivers/gpio/Kconfig|   7 +
> >  drivers/gpio/Makefile   |   1 +
> >  drivers/gpio/gpio-fxl6408.c | 366 
> >  3 files changed, 374 insertions(+)
> >  create mode 100644 drivers/gpio/gpio-fxl6408.c
> >
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index 4a89c1a62b..f56e4cc261 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -123,6 +123,13 @@ config DA8XX_GPIO
> >   help
> > This driver supports the DA8xx GPIO controller
> >
> > +config FXL6408_GPIO
> > + bool "FXL6408 I2C GPIO expander driver"
> > + depends on DM_GPIO && DM_I2C
> > + help
> > +   This driver supports the Fairchild FXL6408 device. FXL6408 is a
> > +   fully configurable 8-bit I2C-controlled GPIO expander.
> > +
> >  config INTEL_BROADWELL_GPIO
> >   bool "Intel Broadwell GPIO driver"
> >   depends on DM
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > index 58f4704f6b..83d8b5c9d8 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -16,6 +16,7 @@ obj-$(CONFIG_AT91_GPIO) += at91_gpio.o
> >  obj-$(CONFIG_ATMEL_PIO4) += atmel_pio4.o
> >  obj-$(CONFIG_BCM6345_GPIO)   += bcm6345_gpio.o
> >  obj-$(CONFIG_CORTINA_GPIO)  += cortina_gpio.o
> > +obj-$(CONFIG_FXL6408_GPIO)   += gpio-fxl6408.o
> >  obj-$(CONFIG_INTEL_GPIO) += intel_gpio.o
> >  obj-$(CONFIG_INTEL_ICH6_GPIO)+= intel_ich6_gpio.o
> >  obj-$(CONFIG_INTEL_BROADWELL_GPIO)   += intel_broadwell_gpio.o
> > diff --git a/drivers/gpio/gpio-fxl6408.c b/drivers/gpio/gpio-fxl6408.c
> > new file mode 100644
> > index 00..dbc68618f9
> > --- /dev/null
> > +++ b/drivers/gpio/gpio-fxl6408.c
> > @@ -0,0 +1,366 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + *  Copyright (C) 2021 Toradex
> > + *  Copyright (C) 2016 Broadcom
> > + */
> > +
> > +/**
>
> Below is not kernel-doc format

I don't think so. And without formatting comments of this block as a
kernel-doc, the kernel-doc tool shows the warning:
drivers/gpio/gpio-fxl6408.c:1: warning: no structured comments found

Otherwise, it generates the correct description of the file:
**FXL6408 I2C to GPIO expander.**


This chip has 8 GPIO lines out of it, and is controlled by an I2C
bus (a pair of lines), providing 4x expansion of GPIO lines. It
also provides an interrupt line out for notifying of state changes.
...

> > + * DOC: FXL6408 I2C to GPIO expander.
> > + *
> > + * This chip has 8 GPIO lines out of it, and is controlled by an I2C
> > + * bus (a pair of lines), providing 4x expansion of GPIO lines. It
> > + * also provides an interrupt line out for notifying of state changes.
> > + *
> > + * Any preconfigured state will be left in place until the GPIO lines
> > + * get activated. At power on, everything is treated as an input,
> > + * default input is HIGH and pulled-up, all interrupts are masked.
> > + *
> > + * Documentation can be found at:
> > + * https://www.fairchildsemi.com/datasheets/FX/FXL6408.pdf
> > + *
> > + * This driver bases on:
> > + * - the original driver by Eric Anholt :
> > + *   https://patchwork.kernel.org/patch/9148419/
> > + * - the Toradex version by Max Krummenacher 
> > :
> > + *   
> > http://git.toradex.com/cgit/linux-toradex.git/tree/drivers/gpio/gpio-fxl6408.c?h=toradex_5.4-2.3.x-imx
> > + * - the U-boot PCA953x driver by Peng Fan :
> > + *   drivers/gpio/pca953x_gpio.c
> > + *
> > + * TODO:
> > + *   - Add interrupts support
> > + *   - Replace deprecated callbacks direction_input/output() with 
> > set_flags()
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> please sort it.

Done.

>
> > +
> > +#define REG_DEVID_CTRL   0x01
>
> 0x1

Here and for similar cases below: thanks, I'll fix it in the next revision.

> > +# define SW_RST  BIT(0)
> > +# define RST_INT BIT(1)
> > +/* 0b101 is the Manufacturer's ID assigned to Fairchild by Nokia */
> > +# define MF_ID_

Re: [PATCH v2 3/3] mx7ulp_com: add support for SPL

[Fabio Estevam]

Hi Igor,

On Wed, Sep 15, 2021 at 1:04 PM Igor Opaniuk  wrote:

> Maybe I misunderstood your question,
> but it's already in board/ea/mx7ulp_com/mx7ulp_com.c, no?

The DDR initialization is currently at board/ea/mx7ulp_com/imximage.cfg.

If the board supports SPL, I was expecting to see the DDR
initialization happen in C code instead.

Regards,

Fabio Estevam

Re: [RFC][PATCH] mtd: spi: Set CONFIG_SF_DEFAULT_MODE default to 0

[Tom Rini]

On Tue, Sep 14, 2021 at 05:44:25PM -0400, Tom Rini wrote:
> On Tue, Sep 14, 2021 at 11:30:01PM +0200, Marek Vasut wrote:
> > On 9/14/21 10:45 PM, Tom Rini wrote:
> > > On Tue, Sep 14, 2021 at 10:10:22PM +0200, Marek Vasut wrote:
> > > > On 9/14/21 9:19 PM, Tom Rini wrote:
> > > > > On Tue, Sep 14, 2021 at 08:28:24PM +0200, Marek Vasut wrote:
> > > > > 
> > > > > > Before e2e95e5e254 ("spi: Update speed/mode on change") most systems
> > > > > > silently defaulted to SF bus mode 0. Now the mode is always updated,
> > > > > > which causes breakage. It seems most SF which are used as boot media
> > > > > > operate in bus mode 0, so switch that as the default.
> > > > > > 
> > > > > > This should fix booting at least on Altera SoCFPGA, ST STM32, Xilinx
> > > > > > ZynqMP, NXP iMX and Rockchip SoCs, which recently ran into trouble
> > > > > > with mode 3. Marvell Kirkwood and Xilinx microblaze need to be 
> > > > > > checked
> > > > > > as those might need mode 3.
> > > > > > 
> > > > > > Signed-off-by: Marek Vasut 
> > > > > > Cc: Aleksandar Gerasimovski 
> > > > > > 
> > > > > > Cc: Andreas Biessmann 
> > > > > > Cc: Eugen Hristev 
> > > > > > Cc: Michal Simek 
> > > > > > Cc: Patrice Chotard 
> > > > > > Cc: Patrick Delaunay 
> > > > > > Cc: Peng Fan 
> > > > > > Cc: Siew Chin Lim 
> > > > > > Cc: Tom Rini 
> > > > > > Cc: Valentin Longchamp 
> > > > > > Cc: Vignesh Raghavendra 
> > > > > 
> > > > > So, some background.  With commit 88e34e5ff76b ("spl: replace
> > > > > CONFIG_SPL_SPI_* with CONFIG_SF_DEFAULT_*") CONFIG_SF_DEFAULT_MODE and
> > > > > related moved from having their default value of SPI_MODE_3 (which
> > > > > evaluates to 3) be defined in common/cmd_sf.c if not otherwise 
> > > > > defined,
> > > > > to include/spi_flash.h, and a more visible global default than it was
> > > > > before.  At that time, the following platforms either set or implied
> > > > > SPI_MODE_3 should be used:
> > > > > alt am335x_boneblack am335x_boneblack_vboot am335x_evm_norboot
> > > > > am335x_evm_nor am335x_evm am335x_evm_spiboot am335x_evm_usbspl
> > > > > am43xx_evm am43xx_evm_qspiboot at91sam9n12ek_mmc 
> > > > > at91sam9n12ek_nandflash
> > > > > at91sam9n12ek_spiflash at91sam9x5ek_dataflash at91sam9x5ek_mmc
> > > > > at91sam9x5ek_nandflash at91sam9x5ek_spiflash atstk1004 bf506f-ezkit
> > > > > bf537-stamp cam_enc_4xx coreboot-x86 d2net_v2 da830evm da850_am18xxevm
> > > > > da850evm_direct_nor da850evm dra7xx_evm dra7xx_evm_qspiboot
> > > > > dra7xx_evm_uart3 draco dreamplug dxr2 ea20 ecovec ethernut5 gplugd
> > > > > inetspace_v2 k2e_evm k2hk_evm kmcoge5un km_kirkwood_128m16
> > > > > km_kirkwood_pci km_kirkwood kmnusa kmsugp1 kmsuv31 koelsch lager 
> > > > > lschlv2
> > > > > lsxhl M53017EVB M54455EVB mgcoge3un mv88f6281gtw_ge net2big_v2
> > > > > netspace_lite_v2 netspace_max_v2 netspace_mini_v2 netspace_v2
> > > > > nios2-generic pcm051_rev1 pcm051_rev3 portl2 pxm2 rut sama5d3xek_mmc
> > > > > sama5d3xek_nandflash sama5d3xek_spiflash sh7785lcr tseries_spi 
> > > > > vf610twr
> > > > > zynq_zc770_xm010
> > > > > 
> > > > > Of those platforms, I have handy dra7xx_evm (also am335x_evm but that
> > > > > needs flipping some DIP switches) which has SPI flash by default.  
> > > > > With
> > > > > current tip of tree, I did "sf probe 0 7680 3" and a few cycles of
> > > > > reading the whole of flash and crc32'ing it, and getting the same 
> > > > > result
> > > > > back.  So, SPI_MODE_3 seems correct / function here, and likely so on
> > > > > the rest of the TI platforms listed above.
> > > > > 
> > > > > With commit 14453fbfadc2 ("Convert CONFIG_SF_DEFAULT_* to Kconfig") we
> > > > > migrate these values to Kconfig, and a quick spot-check shows that 
> > > > > yes,
> > > > > the migration did not change any values.
> > > > > 
> > > > > A big change between 88e34e5ff76b and 14453fbfadc2 is that a ton of
> > > > > platforms have been added (it was 5 years, after all) and those
> > > > > platforms seem to be where the problems reside.  I'm not sure if or 
> > > > > why
> > > > > SPI_MODE_3 doesn't work on so many new platforms, but I would prefer 
> > > > > to
> > > > > see "default 0 if ARCH_SOCFPGA || ARCH_STM32 || .." as needed to 
> > > > > switch
> > > > > the default to SPI_MODE_0 if there's not a more fundamental problem to
> > > > > solve on some platforms such that SPI_MODE_3 could / should be 
> > > > > enabled.
> > > > 
> > > > I rather suspect mode 3 is special case for atmel/am335x and co. and 
> > > > maybe
> > > > marvell kirkwood from the list above. So shouldn't we default to 0 and
> > > > special-case the two or three instead ?
> > > 
> > > I guess my question boils down to why is that the right default?  My
> > > argument that 3 is the right default is that it's what it was in
> > > introduction back in b6368467e6a9 ("SPI Flash: Add "sf" command").  But
> > > references to something else such as the Linux Kernel defaults to mode 0
> > > or some SPI specs saying you should default to mode 0 or

Re: [GIT PULL] rpi: updates for v2021.10

[Tom Rini]

On Wed, Sep 15, 2021 at 12:40:29PM -0500, Vincent Fazio wrote:
> Peter,
> 
> On 9/15/21 11:32 AM, Peter Robinson wrote:
> > On Wed, Sep 15, 2021 at 4:40 PM Matthias Brugger  wrote:
> > > Hi Tom,
> > > 
> > > I know, quite a bit late but here come the updates for RPi for v2021.10.
> > > Actually most of the patches are fixes.
> > > 
> > > Ivan's patch fixes a kernel warning when booting RPi2, as the firmware 
> > > already
> > > provides a frambebuffer node.
> > > 
> > > Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.
> > > 
> > > My SMBIOS patchesfixes an issue that show up with
> > > e4f8e543f1 ("smbios: Drop the unused Kconfig options").
> > > Basically the SMBIOS table broke and wasn't readable anymore.
> > > 
> > > I think we can argue if the last one is a real fix. In case you just want 
> > > to
> > > take the first two so late in the cycle, let me know and I can provide 
> > > you with
> > > a separate pull request.
> > It would also be good to get these[1] , although it doesn't seem like
> > they were also posted to the list. It fixes a regression with U-Boot
> > and recent RPi firmwares [2] so will likely come up sooner rather than
> > later post release.
> > 
> > Peter
> 
> I did send these to the u-boot list but received an "awaiting moderator
> approval" response.
> 
> Is there a different list i should have submitted this to, just for future
> reference?
> 
> > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=262375

This is the correct list.  That it's in patchwork means it went to the
list, even.  Moderator approval happens a few times a day (US/Eastern)
or when I see a number of obviously not spam requests go by, JFYI.

-- 
Tom


signature.asc
Description: PGP signature

Re: [GIT PULL] rpi: updates for v2021.10

[Vincent Fazio]

Peter,

On 9/15/21 11:32 AM, Peter Robinson wrote:

On Wed, Sep 15, 2021 at 4:40 PM Matthias Brugger  wrote:

Hi Tom,

I know, quite a bit late but here come the updates for RPi for v2021.10.
Actually most of the patches are fixes.

Ivan's patch fixes a kernel warning when booting RPi2, as the firmware already
provides a frambebuffer node.

Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.

My SMBIOS patchesfixes an issue that show up with
e4f8e543f1 ("smbios: Drop the unused Kconfig options").
Basically the SMBIOS table broke and wasn't readable anymore.

I think we can argue if the last one is a real fix. In case you just want to
take the first two so late in the cycle, let me know and I can provide you with
a separate pull request.

It would also be good to get these[1] , although it doesn't seem like
they were also posted to the list. It fixes a regression with U-Boot
and recent RPi firmwares [2] so will likely come up sooner rather than
later post release.

Peter


I did send these to the u-boot list but received an "awaiting moderator 
approval" response.


Is there a different list i should have submitted this to, just for 
future reference?



[1] https://patchwork.ozlabs.org/project/uboot/list/?series=262375
[2] https://github.com/raspberrypi/firmware/issues/1619


Regards,
Matthias

---

The following changes since commit bb92678ced0b1594b93ab2f10b2c17750c789c96:



Prepare v2021.10-rc4 (2021-09-14 18:58:10 -0400)



are available in the Git repository at:



https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ rpi-next



for you to fetch changes up to acc6987e59137485dbac0ee4a07cc349210954f3:



rpi: Conditionally add simple-framebuffer node (2021-09-15 13:34:06 +0200)





Ivan T. Ivanov (1):

rpi: Conditionally add simple-framebuffer node



Marek Szyprowski (1):

ARM: bcm283x: change the virtual address of the XHCI PCI device base



Matthias Brugger (2):

arm: dts: bcm283x: Add minimal smbios information

configs: rpi: Enable SMBIOS sysinfo driver



   arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++

   arch/arm/mach-bcm283x/init.c |  4 ++--

   board/raspberrypi/rpi/rpi.c  | 11 +--

   configs/rpi_0_w_defconfig|  2 ++

   configs/rpi_2_defconfig  |  2 ++

   configs/rpi_3_32b_defconfig  |  2 ++

   configs/rpi_3_b_plus_defconfig   |  2 ++

   configs/rpi_3_defconfig  |  2 ++

   configs/rpi_4_32b_defconfig  |  2 ++

   configs/rpi_4_defconfig  |  2 ++

   configs/rpi_arm64_defconfig  |  2 ++

   configs/rpi_defconfig|  2 ++

   12 files changed, 44 insertions(+), 8 deletions(-)


--
Vincent Fazio
Embedded Software Engineer - ATS
Extreme Engineering Solutions, Inc
http://www.xes-inc.com

[PATCH 1/1] phy: marvell: cp110: Support SATA invert polarity

[Denis Odintsov]

In commit b24bb99d cp110 configuration initially done in u-boot
was removed and delegated to atf firmware as smc call.
That commit didn't account for later introduced in d13b740c SATA invert 
polarity support.

This patch adds support of passing SATA invert polarity flags to atf
firmware during the smc call.

Signed-off-by: Denis Odintsov 
Cc: Baruch Siach 
Cc: Rabeeh Khoury 
Cc: Stefan Roese 
---
 drivers/phy/marvell/comphy_cp110.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/marvell/comphy_cp110.c 
b/drivers/phy/marvell/comphy_cp110.c
index 418318d12f..4fe2dfcdd1 100644
--- a/drivers/phy/marvell/comphy_cp110.c
+++ b/drivers/phy/marvell/comphy_cp110.c
@@ -36,6 +36,10 @@ DECLARE_GLOBAL_DATA_PTR;
(COMPHY_CALLER_UBOOT | ((pcie_width) << 18) |   \
((clk_src) << 17) | COMPHY_FW_FORMAT(mode, 0, speeds))
 
+/* Invert polarity are bits 1-0 of the mode */
+#define COMPHY_FW_SATA_FORMAT(mode, invert)\
+   ((invert) | COMPHY_FW_MODE_FORMAT(mode))
+
 #define COMPHY_SATA_MODE   0x1
 #define COMPHY_SGMII_MODE  0x2 /* SGMII 1G */
 #define COMPHY_HS_SGMII_MODE   0x3 /* SGMII 2.5G */
@@ -607,7 +611,8 @@ int comphy_cp110_init(struct chip_serdes_phy_config 
*ptr_chip_cfg,
break;
case COMPHY_TYPE_SATA0:
case COMPHY_TYPE_SATA1:
-   mode =  COMPHY_FW_MODE_FORMAT(COMPHY_SATA_MODE);
+   mode = COMPHY_FW_SATA_FORMAT(COMPHY_SATA_MODE,
+serdes_map[lane].invert);
ret = comphy_sata_power_up(lane, hpipe_base_addr,
   comphy_base_addr,
   ptr_chip_cfg->cp_index,
-- 
2.33.0

RE: U-BOOT missing Security support

[Cedrick Kukela]

Thank you
My only question now is how do I set the AES key I though this would be an 
option in kconfig as well or is this an option for the command itself?


Cedrick Kukela
Software Engineer


 
-Original Message-
From: Wolfgang Denk  
Sent: Wednesday, September 15, 2021 8:21 AM
To: Cedrick Kukela 
Cc: u-boot@lists.denx.de
Subject: Re: U-BOOT missing Security support 

Dear Cedrick,

In message 

 you wrote:
> 
> I was attempting to enable CONFIG_CMD_AES and I though it would be 
> under security support. Is there any reason why that option would not 
> be enabled or available?

Search under "Security commands"...

from "cmd/Kconfig":


1975 menu "Security commands"
1976 config CMD_AES
1977 bool "Enable the 'aes' command"
1978 select AES
1979 help
1980   This provides a means to encrypt and decrypt data using the AES
1981   (Advanced Encryption Standard). This algorithm uses a symetric 
key
1982   and is widely used as a streaming cipher. Different key lengths 
are
1983   supported by the algorithm but this command only supports 128 
bits
1984   at present.
1985


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 
Stanford research group advertised for participants in a  study  of 
obsessive-compulsive  disorder. They were looking for therapy clients who had 
been diagnosed with this disorder. The  response  was  grati- fying;  they  got 
 3,000 responses about three days after the ad came out. All from the same 
person.

Re: [GIT PULL] rpi: updates for v2021.10

[Peter Robinson]

On Wed, Sep 15, 2021 at 4:40 PM Matthias Brugger  wrote:
>
> Hi Tom,
>
> I know, quite a bit late but here come the updates for RPi for v2021.10.
> Actually most of the patches are fixes.
>
> Ivan's patch fixes a kernel warning when booting RPi2, as the firmware already
> provides a frambebuffer node.
>
> Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.
>
> My SMBIOS patchesfixes an issue that show up with
> e4f8e543f1 ("smbios: Drop the unused Kconfig options").
> Basically the SMBIOS table broke and wasn't readable anymore.
>
> I think we can argue if the last one is a real fix. In case you just want to
> take the first two so late in the cycle, let me know and I can provide you 
> with
> a separate pull request.

It would also be good to get these[1] , although it doesn't seem like
they were also posted to the list. It fixes a regression with U-Boot
and recent RPi firmwares [2] so will likely come up sooner rather than
later post release.

Peter

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=262375
[2] https://github.com/raspberrypi/firmware/issues/1619

> Regards,
> Matthias
>
> ---
>
> The following changes since commit bb92678ced0b1594b93ab2f10b2c17750c789c96:
>
>
>
>Prepare v2021.10-rc4 (2021-09-14 18:58:10 -0400)
>
>
>
> are available in the Git repository at:
>
>
>
>https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ rpi-next
>
>
>
> for you to fetch changes up to acc6987e59137485dbac0ee4a07cc349210954f3:
>
>
>
>rpi: Conditionally add simple-framebuffer node (2021-09-15 13:34:06 +0200)
>
>
>
> 
>
> Ivan T. Ivanov (1):
>
>rpi: Conditionally add simple-framebuffer node
>
>
>
> Marek Szyprowski (1):
>
>ARM: bcm283x: change the virtual address of the XHCI PCI device base
>
>
>
> Matthias Brugger (2):
>
>arm: dts: bcm283x: Add minimal smbios information
>
>configs: rpi: Enable SMBIOS sysinfo driver
>
>
>
>   arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++
>
>   arch/arm/mach-bcm283x/init.c |  4 ++--
>
>   board/raspberrypi/rpi/rpi.c  | 11 +--
>
>   configs/rpi_0_w_defconfig|  2 ++
>
>   configs/rpi_2_defconfig  |  2 ++
>
>   configs/rpi_3_32b_defconfig  |  2 ++
>
>   configs/rpi_3_b_plus_defconfig   |  2 ++
>
>   configs/rpi_3_defconfig  |  2 ++
>
>   configs/rpi_4_32b_defconfig  |  2 ++
>
>   configs/rpi_4_defconfig  |  2 ++
>
>   configs/rpi_arm64_defconfig  |  2 ++
>
>   configs/rpi_defconfig|  2 ++
>
>   12 files changed, 44 insertions(+), 8 deletions(-)
>

Re: [PATCH v3 1/2] mmc: fsl_esdhc_imx: initialize data for imx7ulp

[Igor Opaniuk]

Hi,

On Wed, Sep 8, 2021 at 9:56 PM Oleksandr Suvorov
 wrote:
>
> From: Jorge Ramirez-Ortiz 
>
> Import data for eSDHC driver for SoC iMX7ULP from the Linux kernel.
> Set supported by u-boot flags only.
>
> Signed-off-by: Jorge Ramirez-Ortiz 
> Signed-off-by: Ricardo Salveti 
> Co-developed-by: Oleksandr Suvorov 
> Signed-off-by: Oleksandr Suvorov 
> Reviewed-by: Fabio Estevam 
> Reviewed-by: Jaehoon Chung 
> ---
>
> Changes in v3:
> - add a Reviewed-by record
>
> Changes in v2:
> - add a Reviewed-by record
>
>  drivers/mmc/fsl_esdhc_imx.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
> index aabf39535f..6c8f77f9ee 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -1706,6 +1706,11 @@ static struct esdhc_soc_data usdhc_imx7d_data = {
> | ESDHC_FLAG_HS400,
>  };
>
> +static struct esdhc_soc_data usdhc_imx7ulp_data = {
> +   .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
> +   | ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200,
> +};
> +
>  static struct esdhc_soc_data usdhc_imx8qm_data = {
> .flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING |
> ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200 |
> @@ -1720,7 +1725,7 @@ static const struct udevice_id fsl_esdhc_ids[] = {
> { .compatible = "fsl,imx6sl-usdhc", },
> { .compatible = "fsl,imx6q-usdhc", },
> { .compatible = "fsl,imx7d-usdhc", .data = (ulong)&usdhc_imx7d_data,},
> -   { .compatible = "fsl,imx7ulp-usdhc", },
> +   { .compatible = "fsl,imx7ulp-usdhc", .data = 
> (ulong)&usdhc_imx7ulp_data,},
> { .compatible = "fsl,imx8qm-usdhc", .data = 
> (ulong)&usdhc_imx8qm_data,},
> { .compatible = "fsl,imx8mm-usdhc", .data = 
> (ulong)&usdhc_imx8qm_data,},
> { .compatible = "fsl,imx8mn-usdhc", .data = 
> (ulong)&usdhc_imx8qm_data,},
> --
> 2.31.1
>

Reviewed-by: Igor Opaniuk 

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

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

Re: [PATCH 03/11] power: pmic: Consistently depend on DM_PMIC

[Igor Opaniuk]

Hi Samuel,

On Sun, Aug 22, 2021 at 2:06 AM Samuel Holland  wrote:
>
> Kconfig symbols for two PMIC drivers (PMIC_AS3722 and DM_PMIC_MC34708)
> were missing a dependency on DM_PMIC. To fix this inconsistency, and to
> keep it from happening again, wrap the driver section with "if DM_PMIC"
> instead of using a "depends on DM_PMIC" clause for each driver.
>
> Signed-off-by: Samuel Holland 
> ---
>
>  drivers/power/pmic/Kconfig | 43 +++---
>  1 file changed, 8 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index fd6648b313e..56c0ef70312 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -10,9 +10,10 @@ config DM_PMIC
> - 'drivers/power/pmic/pmic-uclass.c'
> - 'include/power/pmic.h'
>
> +if DM_PMIC
> +
>  config PMIC_CHILDREN
> bool "Allow child devices for PMICs"
> -   depends on DM_PMIC
> default y
> ---help---
> This allows PMICs to support child devices (such as regulators) in
> @@ -22,7 +23,6 @@ config PMIC_CHILDREN
>
>  config SPL_PMIC_CHILDREN
> bool "Allow child devices for PMICs in SPL"
> -   depends on DM_PMIC
> default y
> ---help---
> This allows PMICs to support child devices (such as regulators) in
> @@ -33,7 +33,6 @@ config SPL_PMIC_CHILDREN
>
>  config PMIC_AB8500
> bool "Enable driver for ST-Ericsson AB8500 PMIC via PRCMU"
> -   depends on DM_PMIC
> select REGMAP
> select SYSCON
> help
> @@ -43,7 +42,7 @@ config PMIC_AB8500
>
>  config PMIC_ACT8846
> bool "Enable support for the active-semi 8846 PMIC"
> -   depends on DM_PMIC && DM_I2C
> +   depends on DM_I2C
> ---help---
> This PMIC includes 4 DC/DC step-down buck regulators and 8 low-dropout
> regulators (LDOs). It also provides some GPIO, reset and battery
> @@ -52,14 +51,13 @@ config PMIC_ACT8846
>
>  config DM_PMIC_DA9063
> bool "Enable Driver Model for the Dialog DA9063 PMIC"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass 
> features
>   for PMIC DA9063. The driver implements read/write operations.
>
>  config SPL_DM_PMIC_DA9063
> bool "Enable Driver Model for the Dialog DA9063 PMIC in SPL"
> -   depends on DM_PMIC && SPL
> +   depends on SPL
> help
>   This config enables implementation of driver-model pmic uclass 
> features
>   for PMIC DA9063. The driver implements read/write operations.
> @@ -74,14 +72,12 @@ config PMIC_AS3722
>
>  config DM_PMIC_BD71837
> bool "Enable Driver Model for PMIC BD71837"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass 
> features
>   for PMIC BD71837. The driver implements read/write operations.
>
>  config SPL_DM_PMIC_BD71837
> bool "Enable Driver Model for PMIC BD71837 in SPL stage"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass
>   features for PMIC BD71837. The driver implements read/write
> @@ -89,7 +85,7 @@ config SPL_DM_PMIC_BD71837
>
>  config DM_PMIC_FAN53555
> bool "Enable support for OnSemi FAN53555"
> -   depends on DM_PMIC && DM_REGULATOR && DM_I2C
> +   depends on DM_REGULATOR && DM_I2C
> select DM_REGULATOR_FAN53555
> help
>   This config enables implementation of driver-model PMIC
> @@ -103,14 +99,12 @@ config DM_PMIC_FAN53555
>
>  config DM_PMIC_MP5416
> bool "Enable Driver Model for PMIC MP5416"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass 
> features
>   for PMIC MP5416. The driver implements read/write operations.
>
>  config SPL_DM_PMIC_MP5416
> bool "Enable Driver Model for PMIC MP5416 in SPL stage"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass
>   features for PMIC MP5416. The driver implements read/write
> @@ -118,56 +112,48 @@ config SPL_DM_PMIC_MP5416
>
>  config DM_PMIC_PCA9450
> bool "Enable Driver Model for PMIC PCA9450"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass 
> features
>   for PMIC PCA9450. The driver implements read/write operations.
>
>  config SPL_DM_PMIC_PCA9450
> bool "Enable Driver Model for PMIC PCA9450"
> -   depends on DM_PMIC
> help
>   This config enables implementation of driver-model pmic uclass 
> features
>   for PMIC PCA9450 in SPL. The driver implements read/write 
> operations.
>
>  config DM_PMIC_PFUZE100
> bool "Enable Driver Model for PMIC PFUZE100"
> -   depends on DM_PMIC
> ---help---
> This config ena

Re: [PATCH v2 1/3] mx7ulp: select soc features

[Igor Opaniuk]

Hi Oleksandr,

On Sun, Sep 12, 2021 at 5:33 PM Oleksandr Suvorov
 wrote:
>
> Force selecting features present in SoC i.MX7ULP.
>
> Signed-off-by: Oleksandr Suvorov 
> ---
>
> (no changes since v1)
>
>  arch/arm/mach-imx/mx7ulp/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig 
> b/arch/arm/mach-imx/mx7ulp/Kconfig
> index 2ffac9cf7c..56a3efd7b9 100644
> --- a/arch/arm/mach-imx/mx7ulp/Kconfig
> +++ b/arch/arm/mach-imx/mx7ulp/Kconfig
> @@ -9,6 +9,9 @@ config LDO_ENABLED_MODE
>   Select this option to enable the PMC1 LDO.
>
>  config MX7ULP
> +   select ARCH_SUPPORT_PSCI
> +   select CPU_V7_HAS_NONSEC
> +   select CPU_V7_HAS_VIRT
> select HAS_CAAM
> bool
>
> --
> 2.31.1
>

Reviewed-by: Igor Opaniuk 

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

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

Re: [PATCH] apalis/colibri_imx6: move setting bootcmd to defconfig

[Igor Opaniuk]

On Sun, Sep 12, 2021 at 10:39 PM Oleksandr Suvorov
 wrote:
>
> Move setting the default boot command to the
> apalis/colibri_imx6_defconfig. It allows replacing the command
> without code modification.
>
> Signed-off-by: Oleksandr Suvorov 
> ---
>
>  configs/apalis_imx6_defconfig  | 1 +
>  configs/colibri_imx6_defconfig | 1 +
>  include/configs/apalis_imx6.h  | 4 
>  include/configs/colibri_imx6.h | 4 
>  4 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
> index a0e85ba23a4..a2e0f8e3936 100644
> --- a/configs/apalis_imx6_defconfig
> +++ b/configs/apalis_imx6_defconfig
> @@ -23,6 +23,7 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
>  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
>  CONFIG_BOOTDELAY=1
> +CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout 
> serial,vidconsole;setenv stdin serial,usbkbd"
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_BOARD_EARLY_INIT_F=y
> diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
> index 47b1cfb1917..bee4e7edd63 100644
> --- a/configs/colibri_imx6_defconfig
> +++ b/configs/colibri_imx6_defconfig
> @@ -22,6 +22,7 @@ CONFIG_DISTRO_DEFAULTS=y
>  CONFIG_FIT=y
>  CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
>  CONFIG_BOOTDELAY=1
> +CONFIG_BOOTCOMMAND="run distro_bootcmd;usb start;setenv stdout 
> serial,vidconsole;setenv stdin serial,usbkbd"
>  # CONFIG_DISPLAY_BOARDINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
>  CONFIG_BOARD_EARLY_INIT_F=y
> diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
> index 12de0105c6c..ade479cb943 100644
> --- a/include/configs/apalis_imx6.h
> +++ b/include/configs/apalis_imx6.h
> @@ -133,10 +133,6 @@
>  #endif
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> BOOTENV \
> -   "bootcmd=run distro_bootcmd ; " \
> -   "usb start ; " \
> -   "setenv stdout serial,vidconsole; " \
> -   "setenv stdin serial,usbkbd\0" \
> "boot_file=zImage\0" \
> "console=ttymxc0\0" \
> "defargs=enable_wait_mode=off vmalloc=400M\0" \
> diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h
> index 804a144a03e..f91d6b49ea8 100644
> --- a/include/configs/colibri_imx6.h
> +++ b/include/configs/colibri_imx6.h
> @@ -115,10 +115,6 @@
>  #define FDT_FILE "imx6dl-colibri-eval-v3.dtb"
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> BOOTENV \
> -   "bootcmd=run distro_bootcmd; " \
> -   "usb start ; " \
> -   "setenv stdout serial,vidconsole; " \
> -   "setenv stdin serial,usbkbd\0" \
> "boot_file=zImage\0" \
> "console=ttymxc0\0" \
> "defargs=enable_wait_mode=off galcore.contiguousSize=50331648\0" \
> --
> 2.31.1
>

Reviewed-by: Igor Opaniuk 

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

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

Re: [PATCH v2 1/9] ARM: meson: Sync Amlogic DT from Linux 5.14

[Vyacheslav]

08.09.2021 17:17, Neil Armstrong via groups.io wrote:

diff --git a/arch/arm/dts/meson-axg.dtsi b/arch/arm/dts/meson-axg.dtsi
index b9efc84692..3f5254eeb4 100644
--- a/arch/arm/dts/meson-axg.dtsi
+++ b/arch/arm/dts/meson-axg.dtsi

...

+
+   usb: usb@ffe09080 {
+   compatible = "amlogic,meson-axg-usb-ctrl";
+   reg = <0x0 0xffe09080 0x0 0x20>;
+   interrupts = ;
+   #address-cells = <2>;


Hi.
I have looked through the dts for axg and found that a usb node use 
"amlogic,meson-axg-usb-ctrl" that is not supported in uboot. In 
linux-kernel it exists in drivers/usb/dwc3/dwc3-meson-g12a.c

In previous dts usb node used amlogic,meson-gxl-usb-ctrl and it worked good.

Re: [PATCH v2 3/3] mx7ulp_com: add support for SPL

[Igor Opaniuk]

Hi Fabio,

On Mon, Sep 13, 2021 at 1:03 AM Fabio Estevam  wrote:
>
> Hi Oleksandr,
>
> On Sun, Sep 12, 2021 at 11:33 AM Oleksandr Suvorov
>  wrote:
> >
> > From: Ricardo Salveti 
> >
> > Add EA iMX7ULP COM board support for building SPL.
> >
> > Signed-off-by: Ricardo Salveti 
> > Signed-off-by: Oleksandr Suvorov 
> > ---
> >
> > Changes in v2:
> > - add a patch with SPL support for mx7ulp_com board.
> >
> >  arch/arm/dts/imx7ulp-com-u-boot.dtsi | 37 
> >  arch/arm/dts/imx7ulp-com.dts |  1 +
> >  arch/arm/mach-imx/mx7ulp/Kconfig | 12 +
> >  board/ea/mx7ulp_com/mx7ulp_com.c | 26 +++
> >  include/configs/mx7ulp_com.h |  6 +
> >  5 files changed, 82 insertions(+)
> >  create mode 100644 arch/arm/dts/imx7ulp-com-u-boot.dtsi
>
> I don't see DRAM initialization in the newly added SPL code.
>
> Am I missing something?

Maybe I misunderstood your question,
but it's already in board/ea/mx7ulp_com/mx7ulp_com.c, no?

int dram_init(void)
{
gd->ram_size = imx_ddr_size();

#ifdef CONFIG_OPTEE_TZDRAM_SIZE
   gd->ram_size -= CONFIG_OPTEE_TZDRAM_SIZE;
#endif

return 0;
}

which is in init_sequence_f (common/board_f.c), which is supposed to be
called in spl when CONFIG_SPL=y.

Or what exactly do you mean?

Regards,
Igor

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

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

[GIT PULL] rpi: updates for v2021.10

[Matthias Brugger]

Hi Tom,

I know, quite a bit late but here come the updates for RPi for v2021.10. 
Actually most of the patches are fixes.


Ivan's patch fixes a kernel warning when booting RPi2, as the firmware already 
provides a frambebuffer node.


Marek's patch fixes random crashes on 32 bit RPi4 with newer firmware.

My SMBIOS patchesfixes an issue that show up with
e4f8e543f1 ("smbios: Drop the unused Kconfig options").
Basically the SMBIOS table broke and wasn't readable anymore.

I think we can argue if the last one is a real fix. In case you just want to 
take the first two so late in the cycle, let me know and I can provide you with 
a separate pull request.


Regards,
Matthias

---

The following changes since commit bb92678ced0b1594b93ab2f10b2c17750c789c96:



  Prepare v2021.10-rc4 (2021-09-14 18:58:10 -0400)



are available in the Git repository at:



  https://source.denx.de/u-boot/custodians/u-boot-raspberrypi.git/ rpi-next



for you to fetch changes up to acc6987e59137485dbac0ee4a07cc349210954f3:



  rpi: Conditionally add simple-framebuffer node (2021-09-15 13:34:06 +0200)





Ivan T. Ivanov (1):

  rpi: Conditionally add simple-framebuffer node



Marek Szyprowski (1):

  ARM: bcm283x: change the virtual address of the XHCI PCI device base



Matthias Brugger (2):

  arm: dts: bcm283x: Add minimal smbios information

  configs: rpi: Enable SMBIOS sysinfo driver



 arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++

 arch/arm/mach-bcm283x/init.c |  4 ++--

 board/raspberrypi/rpi/rpi.c  | 11 +--

 configs/rpi_0_w_defconfig|  2 ++

 configs/rpi_2_defconfig  |  2 ++

 configs/rpi_3_32b_defconfig  |  2 ++

 configs/rpi_3_b_plus_defconfig   |  2 ++

 configs/rpi_3_defconfig  |  2 ++

 configs/rpi_4_32b_defconfig  |  2 ++

 configs/rpi_4_defconfig  |  2 ++

 configs/rpi_arm64_defconfig  |  2 ++

 configs/rpi_defconfig|  2 ++

 12 files changed, 44 insertions(+), 8 deletions(-)

Re: RFC: exclude partitions from efi_selftest

[Michael Lawnick]

Am 15.09.2021 um 13:36 schrieb Michael Lawnick:

Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt:



Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick :

Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:


Could you, please send the complete output starting with 'bootefi selftest'.


ASIM-CN10KAS> setenv efi_selftest block device
ASIM-CN10KAS> bootefi selftest

Testing EFI API implementation

Selected test: 'block device'

Setting up 'block device'
Setting up 'block device' succeeded

Executing 'block device'
** Unrecognized filesystem type **


Is the FAT file system enabled in the configuration?


No




lib/efi_selftest/efi_selftest_block_device.c(362):
ERROR: Failed to open simple file system protocol
lib/efi_selftest/efi_selftest.c(111):
ERROR: Executing 'block device' failed

Tearing down 'block device'
Tearing down 'block device' succeeded

Boot services terminated

Summary: 1 failures


Sorry Heinrich, I managed to send below part to only you, so I repeat
for the group:
What might be worth to be noted:
We are working on U-Boot provided by Marvell for upcoming SoC based on
ThunderX. It is rather up to main branch but not the latest version.
Latest change from main:
Author: Patrick Wildt 
Date:   Wed Oct 7 11:04:33 2020 +0200
efi_loader: fix use after free in receive path
Signed-off-by: Heinrich Schuchardt 

If you can give a list of relevant modules I can make comparison, but
just updating everything to latest or comparing full source tree won't
be possible.



We have 8 partitions of which no. 5 isn't initialized.
I have put a bunch of printf to the code and see that the execute() is
done exactly on the partition which is unknown, no other gets touched !?

--
KR
Michael

[PATCH] arm: zynq: Use s25fl256s1 compatible string on zedboard

[Michal Simek]

Use compatible string which is listed in the Linux kernel.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynq-zed.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
index 7a540b63f471..cf28167a7f74 100644
--- a/arch/arm/dts/zynq-zed.dts
+++ b/arch/arm/dts/zynq-zed.dts
@@ -53,7 +53,7 @@
status = "okay";
num-cs = <1>;
flash@0 {
-   compatible = "spansion,s25fl256s", "jedec,spi-nor";
+   compatible = "spansion,s25fl256s1", "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <3000>;
m25p,fast-read;
-- 
2.33.0

[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]

[Tom Rini]

Hey all,

Just a minor issue to fix from the latest scan.  A fixes tag on
19f7a34a4642e25aa8b80c6d75129fe7848a158d would be appropriate.  Thanks!

- Forwarded message from scan-ad...@coverity.com -

Date: Tue, 14 Sep 2021 23:10:58 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot

Hi,

Please find the latest report on new defect(s) introduced to Das U-Boot found 
with Coverity Scan.

1 new defect(s) introduced to Das U-Boot found with Coverity Scan.
3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent 
build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 338845:  Null pointer dereferences  (REVERSE_INULL)
/drivers/mmc/mmc.c: 3085 in mmc_init_device()



*** CID 338845:  Null pointer dereferences  (REVERSE_INULL)
/drivers/mmc/mmc.c: 3085 in mmc_init_device()
3079return ret;
3080}
3081 
3082m = mmc_get_mmc_dev(dev);
3083m->user_speed_mode = MMC_MODES_END; /* Initialising user set 
speed mode */
3084 
>>> CID 338845:  Null pointer dereferences  (REVERSE_INULL)
>>> Null-checking "m" suggests that it may be null, but it has already been 
>>> dereferenced on all paths leading to the check.
3085if (!m)
3086return 0;
3087if (m->preinit)
3088mmc_start_init(m);
3089 
3090return 0;



To view the defects in Coverity Scan visit, 
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yoA22WlOQ-2By3ieUvdbKmOyw68TMVT4Kip-2BBzfOGWXJ5yIiYplmPF9KAnKIja4Zd7tU-3DRWeY_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTu3vYiCvsy-2F4Q187kdIvXEo5jWH8-2FKD7MYSJdIip3-2Byx1oYllNoM-2F0ob1q3wtaHWq0tUNaaBFtPBtgqFvkSGHsIlwT00tS5zQP-2BCb6DQYEFZ2k5NYPFr6RdNzSJtDjKq86BuqLAmJb30Q54nF-2Fk-2Bb4BEFQu8TD4BC9Si1Mg8VeIWQ-3D-3D

  To manage Coverity Scan email notifications for "tom.r...@gmail.com", click 
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yped04pjJnmXOsUBtKYNIXxWeIHzDeopm-2BEWQ6S6K-2FtUHv9ZTk8qZbuzkkz9sa-2BJFw4elYDyedRVZOC-2ButxjBZdouVmTGuWB6Aj6G7lm7t25-2Biv1B-2B9082pHzCCex2kqMs-3Dq0B2_EEm8SbLgSDsaDZif-2Bv7ch8WqhKpLoKErHi4nXpwDNTu3vYiCvsy-2F4Q187kdIvXEoqfDQ5N8pBM-2Fjgu-2FDSK-2F-2FefZxW44efUFPv-2BUNG5gusOb1n0Y4Wtmh-2FGP7sAeHBsIh-2Fx2TbIe016grlxclHcizP0vNuIKH-2BJmHpfqnTTU1oORi0tFLIe2oPa-2BmwlB5lSAS-2BKQGq533LaGbEGxmYXNErg-3D-3D


- End forwarded message -

-- 
Tom


signature.asc
Description: PGP signature

Re: Problem with U-boot | Configuration Signature not being checked while booting

[François Ozog]

On Wed, 15 Sept 2021 at 15:36, Tom Rini  wrote:

> On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > > From: Simon Glass 
> > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> >
> > Hi Simon,
> >
> > > Hi Mark,
> > >
> > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis 
> wrote:
> > > >
> > > > > From: Moiz Imtiaz 
> > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > >
> > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot,
> but
> > > > > instead one provided by the earlier-stage firmware?
> > > > >
> > > > > Not sure, but seems like this is the case. I checked and there
> isn't any
> > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> > > > > add the dtb and other dts dtsi
> > > > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > > > from the raspberry pi Linux and compile them with
> CONFIG_OF_SEPARATE and
> > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the
> U-Boot and
> > > > > it would just give a blank screen*. I wonder why there isn't any
> device
> > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not
> supported by
> > > > > RPI4?
> > > >
> > > > The issue with the rpi4 is that the addresses of devices move around
> > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > pretty much has to use the device tree passed by the firmware since
> > > > the device tree in the U-Boot tree would be wrong for many
> > > > combinations of firmware and hardware.
> > > >
> > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > of having all U-Boot configuration information in a single device
> tree
> > > > with the hardware description doesn't work everywhere.
> > >
> > > >From my reading of this thread, it rather reinforces the need to
> > > provide a way to give U-Boot the config it needs, in the devicetree.
> >
> > As long as that configuration is optional, yes, maybe.
>
> Lets be a little careful.  We don't want to have two ways to provide the
> information for a given feature.  But some configuration properties are
> certainly optional.
>
> > > It seems that rpi is actually OK in this regard. If you think about
> > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > it could provide a devicetree to whatever is next.
> >
> > Not hopeless.  If that device tree provides a hardware description
> > that is complete enough to boot Linux, it should be good enough to run
> > U-Boot.
>
> And keep in mind that one of those long stated goals is that the device
> tree for a platform lives physically on the platform and doesn't require
> being replaced entirely at run-time with a new/different device tree.
>
> > And yes, the Raspberry Pi has a nice way to load overlays to do
> > additional hardware configuration and support add-on hardware that
> > connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> > would make very little sense.
>
> Note that in U-Boot we do have functionality to figure out and apply DT
> overlays for a platform, and it's generic enough that platforms can
> plugin their logic to detect what overlays are appropriate.  This is
> under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
> this in their in-house firmware instead of using U-Boot.
>
> > > For example, if U-Boot evolves to support more devices, they could
> > > not be supported.
> >
> > Unless the device in question has a mechanism to load device tree
> > overlays like the Pi, this would require a firmware update.
>
> In that CMD_EXTENSION is about updating the tree for the next stage, and
> not ourself, yes.  But this is also the same problem that OSes have that
> lead to overlays, at least in part.  But also why it's so hard to
> support a static device tree on hardware, and have an evolving kernel.
> I'm not sure there's many / any good examples of wholly static and also
> feature complete device trees and OSes today, on a recent / semi-recent
> piece of hardware.
>
> > In practice, the device tree provided by the firmware will have more
> > stuff than U-Boot will ever need though.  Unless you're advocating
> > that U-Boot evolves into a full-fledged OS ;).
> >
> > > If UEFI is used, the devicetree would have no effect, since it doesn't
> > > support devicetree.
> >
> > That is not true.  UEFI supports device trees just fine.  All the
> > arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> > support use device trees.  The idea that UEFI implies ACPI is a
> > misconception.
> >
> > > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> >
> > Maybe somebody can add device tree overlay support to QEMU?
>
> Havin

[PATCH] arm64: zynqmp: Add device tree properties for nand flash

[Michal Simek]

From: Amit Kumar Mahapatra 

Add ecc strength & ecc step size properties for nand flash devices,
when operating in software-ecc mode.

Signed-off-by: Amit Kumar Mahapatra 
Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts 
b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
index 4225a9547c58..f32f87acacb6 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
@@ -140,6 +140,8 @@
nand-ecc-algo = "bch";
nand-rb = <0>;
label = "main-storage-0";
+   nand-ecc-step-size = <1024>;
+   nand-ecc-strength = <24>;
 
partition@0 {   /* for testing purpose */
label = "nand-fsbl-uboot";
@@ -174,6 +176,8 @@
nand-ecc-algo = "bch";
nand-rb = <0>;
label = "main-storage-1";
+   nand-ecc-step-size = <1024>;
+   nand-ecc-strength = <24>;
 
partition@0 {   /* for testing purpose */
label = "nand1-fsbl-uboot";
-- 
2.33.0

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Wed, Sep 15, 2021 at 01:51:51PM +0200, Mark Kettenis wrote:
> > From: Simon Glass 
> > Date: Wed, 15 Sep 2021 04:13:24 -0600
> 
> Hi Simon,
> 
> > Hi Mark,
> > 
> > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  
> > wrote:
> > >
> > > > From: Moiz Imtiaz 
> > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > >
> > > > Hi Simon,
> > > >
> > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > >
> > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > instead one provided by the earlier-stage firmware?
> > > >
> > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried 
> > > > to
> > > > add the dtb and other dts dtsi
> > > > files
> > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot 
> > > > and
> > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > RPI4?
> > >
> > > The issue with the rpi4 is that the addresses of devices move around
> > > based on the version of the Raspberry Pi firmware you're using.  And
> > > possibly on the amount of memory on the board as well.  So U-Boot
> > > pretty much has to use the device tree passed by the firmware since
> > > the device tree in the U-Boot tree would be wrong for many
> > > combinations of firmware and hardware.
> > >
> > > Simon, this sort of thing is exactly the reason why I think the idea
> > > of having all U-Boot configuration information in a single device tree
> > > with the hardware description doesn't work everywhere.
> > 
> > >From my reading of this thread, it rather reinforces the need to
> > provide a way to give U-Boot the config it needs, in the devicetree.
> 
> As long as that configuration is optional, yes, maybe.

Lets be a little careful.  We don't want to have two ways to provide the
information for a given feature.  But some configuration properties are
certainly optional.

> > It seems that rpi is actually OK in this regard. If you think about
> > it, it would be pretty hopeless if first-stage firmware assumed that
> > it could provide a devicetree to whatever is next.
> 
> Not hopeless.  If that device tree provides a hardware description
> that is complete enough to boot Linux, it should be good enough to run
> U-Boot.

And keep in mind that one of those long stated goals is that the device
tree for a platform lives physically on the platform and doesn't require
being replaced entirely at run-time with a new/different device tree.

> And yes, the Raspberry Pi has a nice way to load overlays to do
> additional hardware configuration and support add-on hardware that
> connects to the GPIO header on the Pi.  Replicating all this in U-Boot
> would make very little sense.

Note that in U-Boot we do have functionality to figure out and apply DT
overlays for a platform, and it's generic enough that platforms can
plugin their logic to detect what overlays are appropriate.  This is
under CMD_EXTENSION.  It's not appropriate for Pi as they did all of
this in their in-house firmware instead of using U-Boot.

> > For example, if U-Boot evolves to support more devices, they could
> > not be supported.
> 
> Unless the device in question has a mechanism to load device tree
> overlays like the Pi, this would require a firmware update.

In that CMD_EXTENSION is about updating the tree for the next stage, and
not ourself, yes.  But this is also the same problem that OSes have that
lead to overlays, at least in part.  But also why it's so hard to
support a static device tree on hardware, and have an evolving kernel.
I'm not sure there's many / any good examples of wholly static and also
feature complete device trees and OSes today, on a recent / semi-recent
piece of hardware.

> In practice, the device tree provided by the firmware will have more
> stuff than U-Boot will ever need though.  Unless you're advocating
> that U-Boot evolves into a full-fledged OS ;).
> 
> > If UEFI is used, the devicetree would have no effect, since it doesn't
> > support devicetree.
> 
> That is not true.  UEFI supports device trees just fine.  All the
> arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
> support use device trees.  The idea that UEFI implies ACPI is a
> misconception.
> 
> > So perhaps the only remaining issue is with qemu on ARM / Risc-V?
> 
> Maybe somebody can add device tree overlay support to QEMU?

Having gone through this thread, I wonder if U-Boot generating a device
tree overlay (and also the keeping the source of it, before
preprocessing if we can) isn't part of the solution here.  Heinrich had
suggested in another thread, and Simon ha

Re: [PATCH 5/6] arm: Remove edminiv2 board and orion5x support

[Simon Guinot]

On Tue, Sep 14, 2021 at 07:43:10AM -0400, Tom Rini wrote:
> On Tue, Sep 14, 2021 at 10:37:43AM +0200, Simon Guinot wrote:
> 
> > Hi Stefan and Tom,
> > 
> > I finally managed to find a Disk Mini v2 Ethernet card and I will be
> > working on the DM conversion as soon as possible.
> > 
> > Please, let me know what is my deadline to complete this job ?
> 
> Great.  So, the deadline for DM conversion was v2020.01, which means I
> was going to remove it for the v2022.01 release.  That's pretty far
> away.  But there's also only a handful of non-converted platforms, so I
> was going to instead try and drop everything for v2021.01.  Do you think
> you can have this converted by some time in October?  End of October
> would be OK.  If you need more time than that, let me know.

Yes I think it should be good by the end of october. And if for some
reason I am unable to meet the deadline, then I'll let you know soon
enough. So you would still have the option of dropping the board.

> 
> But please update the MAINTAINERS file now :)

I just sent a patch.

Simon


signature.asc
Description: PGP signature

Re: [PATCH] arm: orion5x: edminiv2: change maintainer

[Tom Rini]

On Wed, Sep 15, 2021 at 03:01:51PM +0200, Simon Guinot wrote:

> Since Albert Aribaud is not maintaining anymore the LaCie Ethernet Disk
> mini V2 board, then I am taking over.
> 
> Signed-off-by: Simon Guinot 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Tom Rini]

On Mon, Sep 13, 2021 at 01:45:56AM +0500, Moiz Imtiaz wrote:

> Thanks a lot Tom and U-boot Team,
> 
> What I did is that I made a control FDT (with Public_key and
> signature_node) and replaced the default dtb (bcm2711-rpi-4-b.dtb) in the
> boot directory of rpi_4-b(the board I am using) with the Control FDT
> 
> I compiled U-boot with "Config_OF_BOARD" and thought that since the pi
> second stage bootloader is gonna decide what dtb to use, how about
> replacing the default with our Contro FDT and it worked :)
> 
> [image: image.png]
> 
> It's like when I will be copying u-boot.bin in the /boot directory I will
> replace the default dtb with the Control FDT. If there is any concern with
> the above implementation from a security perspective (i.e manually
> replacing the default dtb of pi with control FDT), please let me know so
> that I can improve it. I am completely open to suggestions.
> 
> I also checked by modifying the config kernel hash and it throw rejection
> and didn't boot up.
> [image: changing_the_hash_verfication.png]
> 
> Kudos on the awesome writeup
> 
> of
> manual verification by modifying the hash, saved me a couple of hours of
> googling :D

Nice!  If you want to write something up extending the documentation on
how you made this work for Pi it would be much appreciated.

> Also, one quick question, why do we not accept boot scripts with FIT
> enabled? I really like the idea of disabling legacy image support with FIT
> enabled but what is the recommended way of achieving boot scripts action
> then, if we won't allow boot script for e.g loading the FIT image in memory
> and then booting it up with bootm?
> Currently, I am using the following in my boot script.
> 
> setenv bootargs 8250.nr_uarts=1 console=ttyS0,115200 root=/dev/mmcblk0p2
> > rootwait rw;
> > fatload mmc 0:1 0x2000 image.itb;
> > bootm 0x2000;
> 
> 
> Again, thanks a lot and appreciate your input and suggestions.

I believe the general reason is that we want to have the vboot build as
locked down as possible.  You should be able to embed the bootargs in to
the FIT image, if you don't need to support some sort of A/B rootfs
scheme, or in to the default U-Boot environment otherwise.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] arm: orion5x: edminiv2: change maintainer

[Simon Guinot]

Since Albert Aribaud is not maintaining anymore the LaCie Ethernet Disk
mini V2 board, then I am taking over.

Signed-off-by: Simon Guinot 
---
 board/LaCie/edminiv2/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/LaCie/edminiv2/MAINTAINERS b/board/LaCie/edminiv2/MAINTAINERS
index e0591f4b80e1..055afd0e766f 100644
--- a/board/LaCie/edminiv2/MAINTAINERS
+++ b/board/LaCie/edminiv2/MAINTAINERS
@@ -1,5 +1,5 @@
 EDMINIV2 BOARD
-M: Albert ARIBAUD 
+M: Simon Guinot 
 S: Maintained
 F: board/LaCie/edminiv2/
 F: include/configs/edminiv2.h
-- 
2.32.0

Re: [PATCH 1/3] efi_loader: add SMBIOS table measurement

[Masahisa Kojima]

Hi Ilias,

Thank you for the review.

On Wed, 15 Sept 2021 at 17:37, Ilias Apalodimas
 wrote:
>
> Hi Kojima-san,
>
> On Wed, Sep 15, 2021 at 02:15:44PM +0900, Masahisa Kojima wrote:
> > TCG PC Client spec requires to measure the SMBIOS
> > table that contain static configuration information
> > (e.g. Platform Manufacturer Enterprise Number assigned by IANA,
> > platform model number, Vendor and Device IDs for each SMBIOS table).
> >
> > The device and environment dependent information such as
> > serial number is cleared to zero or space character for
> > the measurement.
> >
> > This commit also fixes the following compiler warning:
> >
> > lib/smbios-parser.c:59:39: warning: cast to pointer from integer of
> > different size [-Wint-to-pointer-cast]
> >   const struct smbios_header *header = (struct smbios_header 
> > *)entry->struct_table_address;
> >
> > Signed-off-by: Masahisa Kojima 
> > ---
> >  include/efi_loader.h  |   2 +
> >  include/efi_tcg2.h|  15 
> >  include/smbios.h  |  13 
> >  lib/efi_loader/Kconfig|   1 +
> >  lib/efi_loader/efi_boottime.c |   2 +
> >  lib/efi_loader/efi_smbios.c   |   2 -
> >  lib/efi_loader/efi_tcg2.c |  84 ++
> >  lib/smbios-parser.c   | 127 +-
> >  8 files changed, 243 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/efi_loader.h b/include/efi_loader.h
> > index c440962fe5..13f0c24058 100644
> > --- a/include/efi_loader.h
> > +++ b/include/efi_loader.h
> > @@ -308,6 +308,8 @@ extern const efi_guid_t efi_guid_capsule_report;
> >  extern const efi_guid_t efi_guid_firmware_management_protocol;
> >  /* GUID for the ESRT */
> >  extern const efi_guid_t efi_esrt_guid;
> > +/* GUID of the SMBIOS table */
> > +extern const efi_guid_t smbios_guid;
> >
> >  extern char __efi_runtime_start[], __efi_runtime_stop[];
> >  extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
> > diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> > index 5a1a36212e..da33f8a1d0 100644
> > --- a/include/efi_tcg2.h
> > +++ b/include/efi_tcg2.h
> > @@ -215,6 +215,21 @@ struct efi_tcg2_uefi_variable_data {
> >   u8 variable_data[1];
> >  };
> >
> > +/**
> > + * struct tdUEFI_HANDOFF_TABLE_POINTERS2 - event log structure of SMBOIS 
> > tables
> > + * @table_description_size:  size of table description
> > + * @table_description:   table description
> > + * @number_of_tables:number of uefi configuration table
> > + * @table_entry: uefi configuration table entry
> > + */
> > +#define SMBIOS_HANDOFF_TABLE_DESC  "SmbiosTable"
> > +struct smbios_handoff_table_pointers2 {
> > + u8 table_description_size;
> > + u8 table_description[sizeof(SMBIOS_HANDOFF_TABLE_DESC)];
> > + u64 number_of_tables;
> > + struct efi_configuration_table table_entry[1];
> > +} __packed;
>
> Is this included in any other struct or array? If not the last member could
> be a flexible array member?

Yes, it can be a flexible array.

>
> > +
> >  struct efi_tcg2_protocol {
> >   efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
> >  struct 
> > efi_tcg2_boot_service_capability *capability);
> > diff --git a/include/smbios.h b/include/smbios.h
> > index aa6b6f3849..0c22c0c489 100644
> > --- a/include/smbios.h
> > +++ b/include/smbios.h
> > @@ -292,4 +292,17 @@ int smbios_update_version(const char *version);
> >   */
> >  int smbios_update_version_full(void *smbios_tab, const char *version);
> >
> > +/**
> > + * smbios_prepare_measurement() - Update smbios table for the measurement
> > + *
> > + * TCG specification requires to measure static configuration information.
> > + * This function clear the device dependent parameters such as
> > + * serial number for the measurement.
> > + *
> > + * @entry: pointer to a struct smbios_entry
> > + * @header: pointer to a struct smbios_header
> > + */
> > +void smbios_prepare_measurement(const struct smbios_entry *entry,
> > + struct smbios_header *header);
> > +
> >  #endif /* _SMBIOS_H_ */
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index dacc3b5881..ac1a281a36 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -327,6 +327,7 @@ config EFI_TCG2_PROTOCOL
> >   select SHA384
> >   select SHA512
> >   select HASH
> > + select SMBIOS_PARSER
> >   help
> > Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
> > of the platform.
> > diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> > index f0283b539e..701e2212c8 100644
> > --- a/lib/efi_loader/efi_boottime.c
> > +++ b/lib/efi_loader/efi_boottime.c
> > @@ -86,6 +86,8 @@ const efi_guid_t efi_guid_event_group_reset_system =
> >  /* GUIDs of the Load File and Load File2 protocols */
> >  const efi_guid_t efi_guid_load_file_protocol = EFI_LOAD_

Re: U-BOOT missing Security support

[Wolfgang Denk]

Dear Cedrick,

In message 

 you wrote:
> 
> I was attempting to enable CONFIG_CMD_AES and I though it would be
> under security support. Is there any reason why that option would
> not be enabled or available?

Search under "Security commands"...

from "cmd/Kconfig":


1975 menu "Security commands"
1976 config CMD_AES
1977 bool "Enable the 'aes' command"
1978 select AES
1979 help
1980   This provides a means to encrypt and decrypt data using the AES
1981   (Advanced Encryption Standard). This algorithm uses a symetric 
key
1982   and is widely used as a streaming cipher. Different key lengths 
are
1983   supported by the algorithm but this command only supports 128 
bits
1984   at present.
1985


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 Stanford research group advertised for participants in a  study  of
obsessive-compulsive  disorder. They were looking for therapy clients
who had been diagnosed with this disorder. The  response  was  grati-
fying;  they  got  3,000 responses about three days after the ad came
out. All from the same person.

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

[Marek Vasut]

On 9/15/21 2:00 PM, Patrick DELAUNAY wrote:

Hi,


On 9/15/21 10:57 AM, Marek Vasut wrote:

On 9/15/21 10:53 AM, Patrice CHOTARD wrote:

Hi All

On 9/15/21 7:59 AM, Marek Vasut wrote:

On 9/15/21 6:23 AM, Heiko Schocher wrote:

Hi Marek,

On 15.09.21 01:06, Marek Vasut wrote:
The flash->mtd.name used to be nor%d before, now it is the type 
of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of 
examples
of the former in U-Boot configs by searching for 
MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the same 
type in

the system and breaks existing environments.

This does no longer get recognized when running 'mtdparts' for 
example:

CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"

Fix this by setting the correct mtd.name to nor%d.

Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple 
MTDs when DM is enabled")

Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Cc: Marek Behún 
Cc: Miquel Raynal 
Cc: Pali Rohár 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Priyanka Jain 
Cc: Simon Glass 
---
    drivers/mtd/spi/sf_mtd.c | 5 -
    1 file changed, 4 insertions(+), 1 deletion(-)


Seem fixes the same problem as Patrick already posted here:

https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/ 



I find your approach cleaner, so:

Acked-by: Heiko Schocher 

@Patrick: Could you test this patch please?


The option from Patrick does look more predictable, but looking at 
the old implementation of spi_flash_mtd_number(), that one handled 
even cases of parallel-nor and spi-nor (both using the nor%d) 
present on the same system. This:


    static int spi_flash_mtd_number(void)
    {
    #ifdef CONFIG_SYS_MAX_FLASH_BANKS
   return CONFIG_SYS_MAX_FLASH_BANKS;
    #else
   return 0;
    #endif
    }
    ...
    sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());

The patch from Patrick does not, it does per-spi-nor-only counting 
using the dev_seq() there, which is more predictable, but local to 
spi-nor.


The MTD core has its own IDR counting, which is used by this patch 
and is global to the MTD core. That has two issues, one is that it 
is possibly too global and counts both nor%d and nand%d, which 
means it would fail on systems with both SPI NOR and regular NAND. 
The other is it is likely less predictable (what happens if the 
SPI NOR and parallel NOR gets probed in the reverse order ? I know 
it is unlikely, but it can happen in the future).


So I think we need a third option which I would suggest be based 
on the patch from Patrick, but which would take into account the 
other nor%d devices like parallel NOR flashes.


That would likely have to happen in the mtd core using some 
modified IDR counting. I think you might need to modify it such 
that you would pass in the prefix of the device (like 'nor') and 
then do per-prefix counting, with the special case that parallel 
NORs are counted first. Also, that would also have to consider 
probing of multiple SPI NORs in either order (say you have two, if 
you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf probe 
0:0'), and make sure they get enumerated with the same nor%d value 
either way, that might be where the dev_seq() would come in.


I just got a try with this patch and unfortunately, it doesn't 
solve the issue.

I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2 SPI-NORs.
Here is the output of mtd list command:

U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)

CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM:  1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  1024 MiB
MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using 
default environment


In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Hit any key to stop autoboot:  0
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 
KiB, total 64 MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB, 
total 64 MiB

List of MTD devices:
* nand0
    - type: NAND flash
    - block size: 0x4 bytes
    - min I/O: 0x1000 bytes
    - OOB size: 224 bytes
    - OOB available: 118 bytes
    - ECC strength: 8 bits
    - ECC step size: 512 bytes
    - bitflip threshold: 6 bits
    - 0x-0x4000 : "nand0"
* nor2
    - device: mx66l51235l@0
    - parent: spi@58003000
    - driver: jedec_spi_nor
    - path: /soc/spi@58003000/mx66l51235l@0
    - type: NOR flash
    - block size: 0x1 bytes
    - min I/O: 0x1 bytes
    - 0x-0x0400 : "nor2"
* nor2
    - device: mx66l51235l@1
    - parent: spi@58003000
    - driver: jedec_spi_nor
    - path: /soc/

U-BOOT missing Security support

[Cedrick Kukela]

Hello,
I was attempting to enable CONFIG_CMD_AES and I though it would be under 
security support. Is there any reason why that option would not be enabled or 
available?
Thanks

Cedrick Kukela
Software Engineer

[cid:image001.png@01D7A9BC.BEA10B50]

+1 919 741-9914 (cell)
+1 919 234-6534
 1001 Winstead Drive, Suite 130
 Cary, NC 27513
 www.connecteddev.com
 cedrick.kuk...@connecteddev.com

Connected Development Confidential & Proprietary.  The message and documents 
transmitted with this email contain Confidential Information of Connected 
Development.

If you are not the intended recipient(s) of this Confidential Information, you 
are hereby notified that any disclosure, copying, distribution or use (without 
written permission of Connected Development) is strictly prohibited.  If you 
are not the intended recipient(s), please notify the sender immediately.  Thank 
you.

Re: RFC: exclude partitions from efi_selftest

[Mark Kettenis]

> Date: Wed, 15 Sep 2021 12:42:16 +0200
> From: Heinrich  Schuchardt 
> 
> Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick 
> :
> >Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
> >> On 9/14/21 4:56 PM, Michael Lawnick wrote:
> >>> Hi,
> >>>
> >>> in our environment we get error on efi_selftest if one of several SSD
> >>> partitions isn't properly initialized (due to some other error, but
> >>> that's a different topic). I tried to track down to where the partitions
> >>> get registered for test but got a bit lost so I request advice from you.
> >>
> >> When the UEFI sub-system is intialized we call efi_disk_register(). If
> >> it fails, we don't enter the UEFI sub-system.
> >>
> >> Are you able to identify where efi_disk_register() fails?
> >
> >The system starts up properly.
> >This is what I see:
> >ASIM-CN10KAS> efiload $loadaddr
> >Loaded EFI App image at 0x4008 with 0x216000 bytes
> >ASIM-CN10KAS> bootefi $loadaddr $fdtaddr
> >Scanning disk sd...@8240.blk...
> >** Unrecognized filesystem type **
> >** Unrecognized filesystem type **
> >** Unrecognized filesystem type **
> 
> This is not an error. Just an info.

It is somewhat annoying though.  The way disks are partitioned on the
Apple M1 systems, there are several Apple native partition types that
need to be retained and that U-Boot doesn't support.  So you see a lot
of these warnings.

Or maybe we should have a whitelist of partition types not to warn
about?

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

[Patrick DELAUNAY]

Hi,

On 9/15/21 11:21 AM, Marek Vasut wrote:

On 9/15/21 11:17 AM, Patrice CHOTARD wrote:



On 9/15/21 10:57 AM, Marek Vasut wrote:

On 9/15/21 10:53 AM, Patrice CHOTARD wrote:

Hi All

On 9/15/21 7:59 AM, Marek Vasut wrote:

On 9/15/21 6:23 AM, Heiko Schocher wrote:

Hi Marek,

On 15.09.21 01:06, Marek Vasut wrote:
The flash->mtd.name used to be nor%d before, now it is the type 
of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of 
examples
of the former in U-Boot configs by searching for 
MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the same 
type in

the system and breaks existing environments.

This does no longer get recognized when running 'mtdparts' for 
example:

CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"

Fix this by setting the correct mtd.name to nor%d.

Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple 
MTDs when DM is enabled")

Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Cc: Marek Behún 
Cc: Miquel Raynal 
Cc: Pali Rohár 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Priyanka Jain 
Cc: Simon Glass 
---
    drivers/mtd/spi/sf_mtd.c | 5 -
    1 file changed, 4 insertions(+), 1 deletion(-)


Seem fixes the same problem as Patrick already posted here:

https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/ 



I find your approach cleaner, so:

Acked-by: Heiko Schocher 

@Patrick: Could you test this patch please?


The option from Patrick does look more predictable, but looking at 
the old implementation of spi_flash_mtd_number(), that one handled 
even cases of parallel-nor and spi-nor (both using the nor%d) 
present on the same system. This:


    static int spi_flash_mtd_number(void)
    {
    #ifdef CONFIG_SYS_MAX_FLASH_BANKS
   return CONFIG_SYS_MAX_FLASH_BANKS;
    #else
   return 0;
    #endif
    }
    ...
    sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());

The patch from Patrick does not, it does per-spi-nor-only counting 
using the dev_seq() there, which is more predictable, but local to 
spi-nor.


The MTD core has its own IDR counting, which is used by this patch 
and is global to the MTD core. That has two issues, one is that it 
is possibly too global and counts both nor%d and nand%d, which 
means it would fail on systems with both SPI NOR and regular NAND. 
The other is it is likely less predictable (what happens if the 
SPI NOR and parallel NOR gets probed in the reverse order ? I know 
it is unlikely, but it can happen in the future).


So I think we need a third option which I would suggest be based 
on the patch from Patrick, but which would take into account the 
other nor%d devices like parallel NOR flashes.


That would likely have to happen in the mtd core using some 
modified IDR counting. I think you might need to modify it such 
that you would pass in the prefix of the device (like 'nor') and 
then do per-prefix counting, with the special case that parallel 
NORs are counted first. Also, that would also have to consider 
probing of multiple SPI NORs in either order (say you have two, if 
you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf probe 
0:0'), and make sure they get enumerated with the same nor%d value 
either way, that might be where the dev_seq() would come in.


I just got a try with this patch and unfortunately, it doesn't 
solve the issue.

I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2 SPI-NORs.
Here is the output of mtd list command:

U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)

CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM:  1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  1024 MiB
MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using 
default environment


In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Hit any key to stop autoboot:  0
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 
KiB, total 64 MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB, 
total 64 MiB

List of MTD devices:
* nand0
    - type: NAND flash
    - block size: 0x4 bytes
    - min I/O: 0x1000 bytes
    - OOB size: 224 bytes
    - OOB available: 118 bytes
    - ECC strength: 8 bits
    - ECC step size: 512 bytes
    - bitflip threshold: 6 bits
    - 0x-0x4000 : "nand0"
* nor2
    - device: mx66l51235l@0
    - parent: spi@58003000
    - driver: jedec_spi_nor
    - path: /soc/spi@58003000/mx66l51235l@0
    - type: NOR flash
    - block size: 0x1 bytes
    - min I/O: 0x1 bytes
    - 0x-0x0400 : "nor2"
* nor2
    - device: mx66l51235l@1
    - parent: spi@58003000
   

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Mark Kettenis]

> From: Simon Glass 
> Date: Wed, 15 Sep 2021 04:13:24 -0600

Hi Simon,

> Hi Mark,
> 
> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  wrote:
> >
> > > From: Moiz Imtiaz 
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > >
> > > Hi Simon,
> > >
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > >
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > >
> > > Not sure, but seems like this is the case. I checked and there isn't any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > add the dtb and other dts dtsi
> > > files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > RPI4?
> >
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> >
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
> 
> >From my reading of this thread, it rather reinforces the need to
> provide a way to give U-Boot the config it needs, in the devicetree.

As long as that configuration is optional, yes, maybe.

> It seems that rpi is actually OK in this regard. If you think about
> it, it would be pretty hopeless if first-stage firmware assumed that
> it could provide a devicetree to whatever is next.

Not hopeless.  If that device tree provides a hardware description
that is complete enough to boot Linux, it should be good enough to run
U-Boot.

And yes, the Raspberry Pi has a nice way to load overlays to do
additional hardware configuration and support add-on hardware that
connects to the GPIO header on the Pi.  Replicating all this in U-Boot
would make very little sense.

> For example, if U-Boot evolves to support more devices, they could
> not be supported.

Unless the device in question has a mechanism to load device tree
overlays like the Pi, this would require a firmware update.

In practice, the device tree provided by the firmware will have more
stuff than U-Boot will ever need though.  Unless you're advocating
that U-Boot evolves into a full-fledged OS ;).

> If UEFI is used, the devicetree would have no effect, since it doesn't
> support devicetree.

That is not true.  UEFI supports device trees just fine.  All the
arm64 and riscv64 boards supported by U-Boot that include EFI_LOADER
support use device trees.  The idea that UEFI implies ACPI is a
misconception.

> So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Maybe somebody can add device tree overlay support to QEMU?

Re: RFC: exclude partitions from efi_selftest

[Michael Lawnick]

Am 15.09.2021 um 13:22 schrieb Heinrich Schuchardt:



Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick :

Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:


Could you, please send the complete output starting with 'bootefi selftest'.


ASIM-CN10KAS> setenv efi_selftest block device
ASIM-CN10KAS> bootefi selftest

Testing EFI API implementation

Selected test: 'block device'

Setting up 'block device'
Setting up 'block device' succeeded

Executing 'block device'
** Unrecognized filesystem type **


Is the FAT file system enabled in the configuration?


No




lib/efi_selftest/efi_selftest_block_device.c(362):
ERROR: Failed to open simple file system protocol
lib/efi_selftest/efi_selftest.c(111):
ERROR: Executing 'block device' failed

Tearing down 'block device'
Tearing down 'block device' succeeded

Boot services terminated

Summary: 1 failures


Sorry Heinrich, I managed to send below part to only you, so I repeat
for the group:
What might be worth to be noted:
We are working on U-Boot provided by Marvell for upcoming SoC based on
ThunderX. It is rather up to main branch but not the latest version.
Latest change from main:
Author: Patrick Wildt 
Date:   Wed Oct 7 11:04:33 2020 +0200
efi_loader: fix use after free in receive path
Signed-off-by: Heinrich Schuchardt 

If you can give a list of relevant modules I can make comparison, but
just updating everything to latest or comparing full source tree won't
be possible.

--
KR
Michael

Re: [PATCH] rpi: Conditionally add simple-framebuffer node

[Matthias Brugger]

On 10/08/2021 16:31, Ivan T. Ivanov wrote:

It appears that RPi firmware has already added framebuffer
node under /chosen, at least on RPi 2 versions. So check
for this and don't add duplicate node.

Signed-off-by: Ivan T. Ivanov 


Applied to rpi-next now.

Thanks,
Matthias


---
  board/raspberrypi/rpi/rpi.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..372b26b6f2 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -497,12 +497,11 @@ void *board_fdt_blob_setup(void)
  
  int ft_board_setup(void *blob, struct bd_info *bd)

  {
-   /*
-* For now, we simply always add the simplefb DT node. Later, we
-* should be more intelligent, and e.g. only do this if no enabled DT
-* node exists for the "real" graphics driver.
-*/
-   lcd_dt_simplefb_add_node(blob);
+   int node;
+
+   node = fdt_node_offset_by_compatible(blob, -1, "simple-framebuffer");
+   if (node < 0)
+   lcd_dt_simplefb_add_node(blob);
  
  #ifdef CONFIG_EFI_LOADER

/* Reserve the spin table */

Re: [PATCH v2 1/2] arm: dts: bcm283x: Add minimal smbios information

[Matthias Brugger]

On 12/04/2021 15:38, matthias@kernel.org wrote:

From: Matthias Brugger 

At present SMBIOS tables are empty, which breaks some use-cases that
rely on that. Add some minimal information to fulfill this.

Signed-off-by: Matthias Brugger 



Both patches now queued in rpi-next.


---

Changes in v2:
- drop product from chassi
- fix typo in commit message

  arch/arm/dts/bcm283x-u-boot.dtsi | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/arch/arm/dts/bcm283x-u-boot.dtsi b/arch/arm/dts/bcm283x-u-boot.dtsi
index 68d03627f4..22c67c4218 100644
--- a/arch/arm/dts/bcm283x-u-boot.dtsi
+++ b/arch/arm/dts/bcm283x-u-boot.dtsi
@@ -6,6 +6,25 @@
   * (C) Copyright 2016 Fabian Vogt 
   */
  
+/ {

+   smbios {
+   compatible = "u-boot,sysinfo-smbios";
+   smbios {
+   system {
+   manufacturer = "raspberrypi";
+   product = "rpi";
+   };
+   baseboard {
+   manufacturer = "raspberrypi";
+   product = "rpi";
+   };
+   chassis {
+   manufacturer = "raspberrypi";
+   };
+   };
+   };
+};
+
  &uart0 {
skip-init;
u-boot,dm-pre-reloc;

Re: RFC: exclude partitions from efi_selftest

[Heinrich Schuchardt]

Am 15. September 2021 12:54:06 MESZ schrieb Michael Lawnick :
>Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:
>
>> Could you, please send the complete output starting with 'bootefi selftest'.
>
>ASIM-CN10KAS> setenv efi_selftest block device
>ASIM-CN10KAS> bootefi selftest
>
>Testing EFI API implementation
>
>Selected test: 'block device'
>
>Setting up 'block device'
>Setting up 'block device' succeeded
>
>Executing 'block device'
>** Unrecognized filesystem type **

Is the FAT file system enabled in the configuration?

>lib/efi_selftest/efi_selftest_block_device.c(362):
>ERROR: Failed to open simple file system protocol
>lib/efi_selftest/efi_selftest.c(111):
>ERROR: Executing 'block device' failed
>
>Tearing down 'block device'
>Tearing down 'block device' succeeded
>
>Boot services terminated
>
>Summary: 1 failures
>
>--
>KR
>Michael
>

Re: [PATCH] ARM: bcm283x: change the virtual address of the XHCI PCI device base

[Matthias Brugger]

On 17/06/2021 11:22, Marek Szyprowski wrote:

Move the XHCI PCI device base up in the virtual address space. This fixes
initialization failure observed with newer Raspberry Pi firmware, later
than 63b1922311 ("firmware: arm_loader: Update armstubs with those from
PR 117). It looks that chosing 0xff80 as the XHCI PCI device base
conflicts with the updated ARM/VideoCore firmware.

This also requires to reduce the size of the mapped PCI device region
from 8MiB to 4MiB to fit into 32bit address space. This is still enough
for the XHCI PCI device.

Signed-off-by: Marek Szyprowski 


Queued in rpi-next now.

Thanks,
Matthias


---
This fixes the issue observed on ARM 32bit after upgrading the RPi4
firmware files, described some time ago here:
https://lists.denx.de/pipermail/u-boot/2021-February/442317.html
---
  arch/arm/mach-bcm283x/init.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 49027ce0a2..9803499985 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -14,7 +14,7 @@
  #include 
  
  #define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS	0x6UL

-#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE   0x80UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE   0x40UL
  
  #ifdef CONFIG_ARM64

  #include 
@@ -148,7 +148,7 @@ int mach_cpu_init(void)
  
  #ifdef CONFIG_ARMV7_LPAE

  #ifdef CONFIG_TARGET_RPI_4_32B
-#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT   0xff80UL
+#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT   0xffc0UL
  #include 
  #include 
  

Re: [PATCH] rpi: always set fdt_addr with firmware-provided FDT address

[Matthias Brugger]

Hi Mauro,

On 07/06/2021 11:27, Mauro Salvini wrote:

On 12/05/21 14:39, Mauro Salvini wrote:

Raspberry firmware prepares the FDT blob in memory at an address
that depends on both the memory size and the blob size [1].
After commit ade243a211d6 ("rpi: passthrough of the firmware provided FDT
blob") this FDT is passed to kernel through fdt_addr environment variable,
handled in set_fdt_addr() function in board file.

When u-boot environment is persistently saved, if a change happens
in loaded FDT (e.g. for a new overlay applied), firmware produces a FDT
address different from the saved one, but u-boot still use the saved
one because set_fdt_addr() function does not overwrite the fdt_addr
variable. So, for example, if there is a script that uses fdt commands for
e.g. manipulate the bootargs, boot hangs with error

libfdt fdt_check_header(): FDT_ERR_BADMAGIC

Removing the fdt_addr variable in saved environment allows to boot.

With this patch set_fdt_addr() function always overwrite fdt_addr value.

[1] https://www.raspberrypi.org/forums//viewtopic.php?f=107&t=134018



First of all sorry for the very late reply.
I'm hesitant to apply this patch, basically because it can break other setups 
where people load a custom DTB to fdt_addr.


I wonder why you can't erase fdt_addr from your persistent storage. There is a 
command called eraseenv that should to the job.


Regards,
Matthias


Signed-off-by: Mauro Salvini 
Cc: Cédric Schieli 
Cc: Matthias Brugger 
---
  board/raspberrypi/rpi/rpi.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index df52a4689f..611013471e 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -318,9 +318,6 @@ static void set_fdtfile(void)
   */
  static void set_fdt_addr(void)
  {
-    if (env_get("fdt_addr"))
-    return;
-
  if (fdt_magic(fw_dtb_pointer) != FDT_MAGIC)
  return;




Hi all,

kind ping.

Regards

Re: RFC: exclude partitions from efi_selftest

[Michael Lawnick]

Am 15.09.2021 um 12:42 schrieb Heinrich Schuchardt:


Could you, please send the complete output starting with 'bootefi selftest'.


ASIM-CN10KAS> setenv efi_selftest block device
ASIM-CN10KAS> bootefi selftest

Testing EFI API implementation

Selected test: 'block device'

Setting up 'block device'
Setting up 'block device' succeeded

Executing 'block device'
** Unrecognized filesystem type **
lib/efi_selftest/efi_selftest_block_device.c(362):
ERROR: Failed to open simple file system protocol
lib/efi_selftest/efi_selftest.c(111):
ERROR: Executing 'block device' failed

Tearing down 'block device'
Tearing down 'block device' succeeded

Boot services terminated

Summary: 1 failures

--
KR
Michael

Re: RFC: exclude partitions from efi_selftest

[Heinrich Schuchardt]

Am 15. September 2021 11:56:07 MESZ schrieb Michael Lawnick :
>Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:
>> On 9/14/21 4:56 PM, Michael Lawnick wrote:
>>> Hi,
>>>
>>> in our environment we get error on efi_selftest if one of several SSD
>>> partitions isn't properly initialized (due to some other error, but
>>> that's a different topic). I tried to track down to where the partitions
>>> get registered for test but got a bit lost so I request advice from you.
>>
>> When the UEFI sub-system is intialized we call efi_disk_register(). If
>> it fails, we don't enter the UEFI sub-system.
>>
>> Are you able to identify where efi_disk_register() fails?
>
>The system starts up properly.
>This is what I see:
>ASIM-CN10KAS> efiload $loadaddr
>Loaded EFI App image at 0x4008 with 0x216000 bytes
>ASIM-CN10KAS> bootefi $loadaddr $fdtaddr
>Scanning disk sd...@8240.blk...
>** Unrecognized filesystem type **
>** Unrecognized filesystem type **
>** Unrecognized filesystem type **

This is not an error. Just an info.

>Found 8 disks
>Init Monotonic Count to zero
>...
>
>But the efi selftest fails.
>
>>
>>>
>>> Shouldn't be the registering of partitions for self test been made
>>> dependent on successful basic init? I wouldn't qualify a non-initialized
>>> partition as reason to let self test fail. If at all a warning should be
>>> sufficient.
>>> As far as I understand efi self test is intended more as a functional
>>> regression test, not a H/W system test, isn't it?
>>> What about the idea to allow to exclude partitions by environment variable?
>>
>> We use efi_selftest in our continuous integration. Patches that make it
>> fail will not be accepted upstream. It is nothing that you need on a
>> deployed production system.
>>
>
>Somehow I miss the connection between my question and your answer.
>We want to integrate the efi_selftest into our CI, too. But if it fails
>due to one uninitialized partition out of 8 then things become more
>complicated than they should. Based on this I am asking why this problem
>exists at all.

Could you, please send the complete output starting with 'bootefi selftest'.

Best regards

Heinrich 

>
>--
>KR
>Michael
>

Re: [PATCH v3 27/29] arm: dts: ls1028a: drop non-removable property from esdhc controller node

[Vladimir Oltean]

On Wed, Sep 15, 2021 at 10:09:45AM +0200, Michael Walle wrote:
> Am 2021-09-15 02:17, schrieb Vladimir Oltean:
> > On Thu, Sep 02, 2021 at 06:45:56PM +0200, Michael Walle wrote:
> > > The linux device tree hasn't set this property. To be similarly we
> > > remove
> >
> > s/similarly/similar/
> >
> > > it from the u-boot device tree, too. The second controller of the
> > > LS1028A has indeed no card detect pin.
> >
> > Because it is an eMMC controller.
> >
> > > The present state register of the
> > > second controller will always report the card as present. Thus, there
> > > should be no functional change otherwise than one more register access
> > > to read the present state.
> >
> > Tested?
>
> Yes, I've tested the eMMC (and actually using it this way). I also
> manually read out the register value and made sure the card detect
> bit is set.
>
> > > The property should still be introduced in
> > > the linux device tree.
> >
> > How do you feel about dropping this patch?
>
> If I drop this patch, I'll either have to (1) keep this property
> the device tree sync patch too or (2) it will be removed without a
> comment in that patch.
>
> I presume you prefer (1), but as I said, I'd keep the device trees
> between linux and u-boot the same and keep it simple by just copying
> the files. So yes, I'd like to keep this patch as the point of this
> patch is to give an explanation why this property is removed (until
> it might or might not be introduced in the kernel device tree; in
> fact I thought I had send a patch to the LKML but I must have
> forgotten it).
>
> I was thinking of putting it into the -u-boot.dtsi, but as there
> is no breakage, I didn't.

Ok, but we should still put "non-removable" in the Linux dtsi soon then.

Re: Problem with U-boot | Configuration Signature not being checked while booting

[François Ozog]

Le mer. 15 sept. 2021 à 12:13, Simon Glass  a écrit :

> Hi Mark,
>
> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis 
> wrote:
> >
> > > From: Moiz Imtiaz 
> > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > >
> > > Hi Simon,
> > >
> > > Thanks for the reply.  I already followed the steps mentioned in
> > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > >
> > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > instead one provided by the earlier-stage firmware?
> > >
> > > Not sure, but seems like this is the case. I checked and there isn't
> any
> > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I
> tried to
> > > add the dtb and other dts dtsi
> > > <
> https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom
> >files
> > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE
> and
> > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot
> and
> > > it would just give a blank screen*. I wonder why there isn't any device
> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported
> by
> > > RPI4?
> >
> > The issue with the rpi4 is that the addresses of devices move around
> > based on the version of the Raspberry Pi firmware you're using.  And
> > possibly on the amount of memory on the board as well.  So U-Boot
> > pretty much has to use the device tree passed by the firmware since
> > the device tree in the U-Boot tree would be wrong for many
> > combinations of firmware and hardware.
> >
> > Simon, this sort of thing is exactly the reason why I think the idea
> > of having all U-Boot configuration information in a single device tree
> > with the hardware description doesn't work everywhere.
>
> From my reading of this thread, it rather reinforces the need to
> provide a way to give U-Boot the config it needs, in the devicetree.
>
> It seems that rpi is actually OK in this regard. If you think about
> it, it would be pretty hopeless if first-stage firmware assumed that
> it could provide a devicetree to whatever is next. For example, if
> U-Boot evolves to support more devices, they could not be supported.
> If UEFI is used, the devicetree would have no effect, since it doesn't
> support devicetree.

Please use EDK2 when you refer to it and not by the interface it
implements. And even if we read “If EDK2 is used” this is false as
Socionext has a platform that can select ACPI or DT for its EDK2
implementation.
TF-A has fat less drivers than U-Boot. There is no problem in having a
“verified” platform DT stored in BL33_CONFIG part of a FIP, verified by TFa
and handed over by U-Boot to OS.
That can be the same thing in RPI4 case or FPGA boards.

>
>
> So perhaps the only remaining issue is with qemu on ARM / Risc-V?
>
> Regards,
> Simon
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog

Re: [PATCH] efi_loader: Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again in efi_net_receive()

[Masami Hiramatsu]

Hi Heinrich,

2021年9月15日(水) 10:31 Masami Hiramatsu :
>
> Hi Heinrich,
>
> This is obscure in the specification (I can not see any detailed
> description about EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT).

OK, I checked the UEFI specification v2.9 again.
The main purpose of EFI_SIMPLE_NETWORK.GetStatus() seems to update the
EFI_SIMPLE_NETWORK_MODE::MediaPresent, in other words, it checks link
status.
And InterruptStatus of EFI_SIMPLE_NETWORK.GetStatus() means "the
currently active interrupts", not "packet to be received".
Thus, I think it should be tested for checking the link status instead
of checking receive packets in DHCP.
You also can see the EFI_SIMPLE_NETWORK_PROTOCOL::WaitForPacket
ensures that you can receive the packet (The spec says "Event used
with EFI_BOOT_SERVICES.WaitForEvent() to wait for a packet to be
received." )
So, it is enough to use the WaitForPacket in the packet receiving
loop, no need to use GetStatus(). Then, correct test should be
something like this.


net->get_status();
if (!net->mode.MediaPresent) {
   error(no link up!)
   return;
}

submit_dhcp_discover()
for (;;) {
   wait_for_event(net)
   while (net->receive() != EFI_NOT_READY) {
  // check dhcp reply
   }
}


For your information, as far as I can see, the interrupt bit is
cleared or not depends on the platform driver implementation in EDK2
too.
In many cases (e.g. virtio-net), they do not clear the original bits,
in another case, no interrupt bit supported (IntrruptStatus always be
0).
But I couldn't find the code which really cleared the interrupt bit...
So I think there is a difference between UEFI specification and
reference implementation (EDK2).

Thank you,


>
> Thank you,
>
> 2021年9月15日(水) 0:45 Heinrich Schuchardt :
>
> >
> > On 9/14/21 4:06 AM, Masami Hiramatsu wrote:
> > > From: Kazuhiko Sakamoto 
> > >
> > > Since 'this->int_status' is cleared by efi_net_get_status(), if user
> >
> > Is it correct to clear int_status unconditionally in efi_net_get_status()?
> >
> > Shouldn't two consecutive calls to EFI_SIMPLE_NETWORK.GetStatus() return
> > the same result?
> >
> > Best regards
> >
> > Heinrich
> >
> > > does wait_for_event(wait_for_packet) and efi_net_get_status() loop
> > > and there are several received packets on the buffer, the second
> > > efi_net_get_status() does not return EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
> > > even if the 'wait_for_packet' is ready.
> > >
> > > This happens on "efiboot selftest" with noisy network.
> > > (The network device can receive both of other packets and dhcp discover
> > >   packet in a short time.)
> > >
> > > Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again when we found any
> > > packet still on the receive buffer.
> > >
> > > Signed-off-by: Kazuhiko Sakamoto 
> > > Signed-off-by: Masami Hiramatsu 
> > > ---
> > >   lib/efi_loader/efi_net.c |   13 +++--
> > >   1 file changed, 11 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
> > > index 69276b275d..9ca1e0c354 100644
> > > --- a/lib/efi_loader/efi_net.c
> > > +++ b/lib/efi_loader/efi_net.c
> > > @@ -640,10 +640,19 @@ static efi_status_t EFIAPI efi_net_receive
> > >   *buffer_size = receive_lengths[rx_packet_idx];
> > >   rx_packet_idx = (rx_packet_idx + 1) % ETH_PACKETS_BATCH_RECV;
> > >   rx_packet_num--;
> > > - if (rx_packet_num)
> > > + if (rx_packet_num) {
> > > + /*
> > > +  * Since 'this->int_status' is cleared by 
> > > efi_net_get_status(),
> > > +  * if user does wait_for_event(wait_for_packet) and
> > > +  * efi_net_get_status() again, 
> > > EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT
> > > +  * is not set even if 'wait_for_packet' is ready.
> > > +  * Set EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT again here.
> > > +  */
> > > + this->int_status |= EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
> > >   wait_for_packet->is_signaled = true;
> > > - else
> > > + } else {
> > >   this->int_status &= ~EFI_SIMPLE_NETWORK_RECEIVE_INTERRUPT;
> > > + }
> > >   out:
> > >   return EFI_EXIT(ret);
> > >   }
> > >
> >
>
>
> --
> Masami Hiramatsu



--
Masami Hiramatsu

Re: Problem with U-boot | Configuration Signature not being checked while booting

[Simon Glass]

Hi Mark,

On Sat, 11 Sept 2021 at 13:18, Mark Kettenis  wrote:
>
> > From: Moiz Imtiaz 
> > Date: Sat, 11 Sep 2021 23:19:05 +0500
> >
> > Hi Simon,
> >
> > Thanks for the reply.  I already followed the steps mentioned in
> > "doc/uImage.FIT/beaglebone_vboot.txt".
> >
> > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > instead one provided by the earlier-stage firmware?
> >
> > Not sure, but seems like this is the case. I checked and there isn't any
> > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > add the dtb and other dts dtsi
> > files
> > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > it would just give a blank screen*. I wonder why there isn't any device
> > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > RPI4?
>
> The issue with the rpi4 is that the addresses of devices move around
> based on the version of the Raspberry Pi firmware you're using.  And
> possibly on the amount of memory on the board as well.  So U-Boot
> pretty much has to use the device tree passed by the firmware since
> the device tree in the U-Boot tree would be wrong for many
> combinations of firmware and hardware.
>
> Simon, this sort of thing is exactly the reason why I think the idea
> of having all U-Boot configuration information in a single device tree
> with the hardware description doesn't work everywhere.

>From my reading of this thread, it rather reinforces the need to
provide a way to give U-Boot the config it needs, in the devicetree.

It seems that rpi is actually OK in this regard. If you think about
it, it would be pretty hopeless if first-stage firmware assumed that
it could provide a devicetree to whatever is next. For example, if
U-Boot evolves to support more devices, they could not be supported.
If UEFI is used, the devicetree would have no effect, since it doesn't
support devicetree.

So perhaps the only remaining issue is with qemu on ARM / Risc-V?

Regards,
Simon

[PATCH] configs: lx2162a: Enable CONFIG_SPI_FLASH_MT35XU for lx2162a-qds

[Kuldeep Singh]

LX2162A-QDS has micron mt35xu512aba flash which requires flag
CONFIG_SPI_FLASH_MT35XU on to probe flash successfully.

Signed-off-by: Kuldeep Singh 
---
 configs/lx2162aqds_tfa_SECURE_BOOT_defconfig   | 1 +
 configs/lx2162aqds_tfa_defconfig   | 1 +
 configs/lx2162aqds_tfa_verified_boot_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig 
b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig
index 7ade20205c..30ee188fa6 100644
--- a/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig
+++ b/configs/lx2162aqds_tfa_SECURE_BOOT_defconfig
@@ -54,6 +54,7 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_SST=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
diff --git a/configs/lx2162aqds_tfa_defconfig b/configs/lx2162aqds_tfa_defconfig
index 2724f045ed..e0b6cbe4f0 100644
--- a/configs/lx2162aqds_tfa_defconfig
+++ b/configs/lx2162aqds_tfa_defconfig
@@ -62,6 +62,7 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_SST=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
diff --git a/configs/lx2162aqds_tfa_verified_boot_defconfig 
b/configs/lx2162aqds_tfa_verified_boot_defconfig
index fa2a02753f..d6f160979d 100644
--- a/configs/lx2162aqds_tfa_verified_boot_defconfig
+++ b/configs/lx2162aqds_tfa_verified_boot_defconfig
@@ -63,6 +63,7 @@ CONFIG_MTD=y
 CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH_EON=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_SPI_FLASH_MT35XU=y
 CONFIG_SPI_FLASH_SST=y
 # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set
 CONFIG_PHYLIB=y
-- 
2.25.1

Re: RFC: exclude partitions from efi_selftest

[Michael Lawnick]

Am 14.09.2021 um 17:57 schrieb Heinrich Schuchardt:

On 9/14/21 4:56 PM, Michael Lawnick wrote:

Hi,

in our environment we get error on efi_selftest if one of several SSD
partitions isn't properly initialized (due to some other error, but
that's a different topic). I tried to track down to where the partitions
get registered for test but got a bit lost so I request advice from you.


When the UEFI sub-system is intialized we call efi_disk_register(). If
it fails, we don't enter the UEFI sub-system.

Are you able to identify where efi_disk_register() fails?


The system starts up properly.
This is what I see:
ASIM-CN10KAS> efiload $loadaddr
Loaded EFI App image at 0x4008 with 0x216000 bytes
ASIM-CN10KAS> bootefi $loadaddr $fdtaddr
Scanning disk sd...@8240.blk...
** Unrecognized filesystem type **
** Unrecognized filesystem type **
** Unrecognized filesystem type **
Found 8 disks
Init Monotonic Count to zero
...

But the efi selftest fails.





Shouldn't be the registering of partitions for self test been made
dependent on successful basic init? I wouldn't qualify a non-initialized
partition as reason to let self test fail. If at all a warning should be
sufficient.
As far as I understand efi self test is intended more as a functional
regression test, not a H/W system test, isn't it?
What about the idea to allow to exclude partitions by environment variable?


We use efi_selftest in our continuous integration. Patches that make it
fail will not be accepted upstream. It is nothing that you need on a
deployed production system.



Somehow I miss the connection between my question and your answer.
We want to integrate the efi_selftest into our CI, too. But if it fails
due to one uninitialized partition out of 8 then things become more
complicated than they should. Based on this I am asking why this problem
exists at all.

--
KR
Michael

[PATCH v2] cmd: mmc: Support mmc hwpartition user enh start -

[Marek Vasut]

Add option to extend the hardware partition to the maximum size by
using the '-' dash sign instead of $cnt parameter. This is useful
in case we want to switch the entire eMMC user area into pSLC mode,
especially in case the device may be populated with different size
eMMCs. With this change, we do not have to calculate the number of
blocks of the user area manually.

To switch the pSLC mode for user area, use e.g. the following.
WARNING: This is a one-time irreversible change.
=> mmc hwpartition user enh 0 - wrrel on complete

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Jaehoon Chung 
Cc: Peng Fan 
Cc: Stefano Babic 
---
V2: - Add comment about block units
- Fix spacing
---
 cmd/mmc.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index f1e30d0cf64..64e6be72803 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -593,7 +593,33 @@ static int do_mmc_list(struct cmd_tbl *cmdtp, int flag,
 }
 
 #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
-static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
+static void parse_hwpart_user_enh_size(struct mmc *mmc,
+  struct mmc_hwpart_conf *pconf,
+  char *argv)
+{
+   int ret;
+
+   pconf->user.enh_size = 0;
+
+   if (!strcmp(argv, "-")) { /* The rest of eMMC */
+   ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+   ret = mmc_send_ext_csd(mmc, ext_csd);
+   if (ret)
+   return;
+   /* This value is in 512B block units */
+   pconf->user.enh_size =
+   ((ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT + 2] << 16) +
+   (ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT + 1] << 8) +
+   ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT]) * 1024 *
+   ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] *
+   ext_csd[EXT_CSD_HC_WP_GRP_SIZE];
+   pconf->user.enh_size -= pconf->user.enh_start;
+   } else {
+   pconf->user.enh_size = dectoul(argv, NULL);
+   }
+}
+
+static int parse_hwpart_user(struct mmc *mmc, struct mmc_hwpart_conf *pconf,
 int argc, char *const argv[])
 {
int i = 0;
@@ -606,8 +632,7 @@ static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
return -1;
pconf->user.enh_start =
dectoul(argv[i + 1], NULL);
-   pconf->user.enh_size =
-   dectoul(argv[i + 2], NULL);
+   parse_hwpart_user_enh_size(mmc, pconf, argv[i + 2]);
i += 3;
} else if (!strcmp(argv[i], "wrrel")) {
if (i + 1 >= argc)
@@ -679,7 +704,7 @@ static int do_mmc_hwpartition(struct cmd_tbl *cmdtp, int 
flag,
while (i < argc) {
if (!strcmp(argv[i], "user")) {
i++;
-   r = parse_hwpart_user(&pconf, argc-i, &argv[i]);
+   r = parse_hwpart_user(mmc, &pconf, argc - i, &argv[i]);
if (r < 0)
return CMD_RET_USAGE;
i += r;
-- 
2.33.0

Re: [PATCH] cmd: mmc: Support mmc hwpartition user enh start -

[Marek Vasut]

On 9/15/21 4:30 AM, Peng Fan (OSS) wrote:


On 2021/9/12 5:14, Marek Vasut wrote:

Add option to extend the hardware partition to the maximum size by
using the '-' dash sign instead of $cnt parameter. This is useful
in case we want to switch the entire eMMC user area into pSLC mode,
especially in case the device may be populated with different size
eMMCs. With this change, we do not have to calculate the number of
blocks of the user area manually.

To switch the pSLC mode for user area, use e.g. the following.
WARNING: This is a one-time irreversible change.
=> mmc hwpartition user enh 0 - wrrel on complete

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Jaehoon Chung 
Cc: Peng Fan 
Cc: Stefano Babic 
---
  cmd/mmc.c | 32 
  1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/cmd/mmc.c b/cmd/mmc.c
index c67ad762422..b6bb951347d 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -560,7 +560,32 @@ static int do_mmc_list(struct cmd_tbl *cmdtp, int 
flag,

  }
  #if CONFIG_IS_ENABLED(MMC_HW_PARTITIONING)
-static int parse_hwpart_user(struct mmc_hwpart_conf *pconf,
+static void parse_hwpart_user_enh_size(struct mmc *mmc,
+   struct mmc_hwpart_conf *pconf,
+   char *argv)
+{
+    int ret;
+
+    pconf->user.enh_size = 0;
+
+    if (!strcmp(argv, "-"))    { /* The rest of eMMC */
+    ALLOC_CACHE_ALIGN_BUFFER(u8, ext_csd, MMC_MAX_BLOCK_LEN);
+    ret = mmc_send_ext_csd(mmc, ext_csd);
+    if (ret)
+    return;
+    pconf->user.enh_size =
+    ((ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT+2] << 16) +


space before/after "+"


+    (ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT+1] << 8) +


Ditto


+    ext_csd[EXT_CSD_MAX_ENH_SIZE_MULT]) * 1024 *


Hardcode HC_WP_GRP_SIZE to 1024?
Per spec:

(GP_SIZE_MULT_X_2 * 2^16 + GP_SIZE_MULT_X_1 * 2^8 + GP_SIZE_MULT_X_0 * 
2^0) * HC_WP_GRP_SIZE * HC_ERASE_GRP_SIZE * 512kBytes


That "1024" above is that "* 512kBytes" part, in 512 Byte block units.

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

[Marek Vasut]

On 9/15/21 11:17 AM, Patrice CHOTARD wrote:



On 9/15/21 10:57 AM, Marek Vasut wrote:

On 9/15/21 10:53 AM, Patrice CHOTARD wrote:

Hi All

On 9/15/21 7:59 AM, Marek Vasut wrote:

On 9/15/21 6:23 AM, Heiko Schocher wrote:

Hi Marek,

On 15.09.21 01:06, Marek Vasut wrote:

The flash->mtd.name used to be nor%d before, now it is the type of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples
of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the same type in
the system and breaks existing environments.

This does no longer get recognized when running 'mtdparts' for example:
CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"

Fix this by setting the correct mtd.name to nor%d.

Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple MTDs when DM is 
enabled")
Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Cc: Marek Behún 
Cc: Miquel Raynal 
Cc: Pali Rohár 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Priyanka Jain 
Cc: Simon Glass 
---
    drivers/mtd/spi/sf_mtd.c | 5 -
    1 file changed, 4 insertions(+), 1 deletion(-)


Seem fixes the same problem as Patrick already posted here:

https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/

I find your approach cleaner, so:

Acked-by: Heiko Schocher 

@Patrick: Could you test this patch please?


The option from Patrick does look more predictable, but looking at the old 
implementation of spi_flash_mtd_number(), that one handled even cases of 
parallel-nor and spi-nor (both using the nor%d) present on the same system. 
This:

    static int spi_flash_mtd_number(void)
    {
    #ifdef CONFIG_SYS_MAX_FLASH_BANKS
   return CONFIG_SYS_MAX_FLASH_BANKS;
    #else
   return 0;
    #endif
    }
    ...
    sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());

The patch from Patrick does not, it does per-spi-nor-only counting using the 
dev_seq() there, which is more predictable, but local to spi-nor.

The MTD core has its own IDR counting, which is used by this patch and is 
global to the MTD core. That has two issues, one is that it is possibly too 
global and counts both nor%d and nand%d, which means it would fail on systems 
with both SPI NOR and regular NAND. The other is it is likely less predictable 
(what happens if the SPI NOR and parallel NOR gets probed in the reverse order 
? I know it is unlikely, but it can happen in the future).

So I think we need a third option which I would suggest be based on the patch 
from Patrick, but which would take into account the other nor%d devices like 
parallel NOR flashes.

That would likely have to happen in the mtd core using some modified IDR 
counting. I think you might need to modify it such that you would pass in the 
prefix of the device (like 'nor') and then do per-prefix counting, with the 
special case that parallel NORs are counted first. Also, that would also have 
to consider probing of multiple SPI NORs in either order (say you have two, if 
you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf probe 0:0'), and 
make sure they get enumerated with the same nor%d value either way, that might 
be where the dev_seq() would come in.


I just got a try with this patch and unfortunately, it doesn't solve the issue.
I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2 SPI-NORs.
Here is the output of mtd list command:

U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)

CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM:  1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  1024 MiB
MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Hit any key to stop autoboot:  0
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 
MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
List of MTD devices:
* nand0
    - type: NAND flash
    - block size: 0x4 bytes
    - min I/O: 0x1000 bytes
    - OOB size: 224 bytes
    - OOB available: 118 bytes
    - ECC strength: 8 bits
    - ECC step size: 512 bytes
    - bitflip threshold: 6 bits
    - 0x-0x4000 : "nand0"
* nor2
    - device: mx66l51235l@0
    - parent: spi@58003000
    - driver: jedec_spi_nor
    - path: /soc/spi@58003000/mx66l51235l@0
    - type: NOR flash
    - block size: 0x1 bytes
    - min I/O: 0x1 bytes
    - 0x-0x0400 : "nor2"
* nor2
    - device: mx66l51235l@1
    - parent: spi@58003000
    - driver: jedec_spi_nor
    - path: /soc/spi@58003000/mx66l51235l@1

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

[Patrice CHOTARD]

On 9/15/21 10:57 AM, Marek Vasut wrote:
> On 9/15/21 10:53 AM, Patrice CHOTARD wrote:
>> Hi All
>>
>> On 9/15/21 7:59 AM, Marek Vasut wrote:
>>> On 9/15/21 6:23 AM, Heiko Schocher wrote:
 Hi Marek,

 On 15.09.21 01:06, Marek Vasut wrote:
> The flash->mtd.name used to be nor%d before, now it is the type of the
> SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples
> of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while
> the later is ambiguous if there are multiple flashes of the same type in
> the system and breaks existing environments.
>
> This does no longer get recognized when running 'mtdparts' for example:
> CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
>
> Fix this by setting the correct mtd.name to nor%d.
>
> Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple MTDs when 
> DM is enabled")
> Signed-off-by: Marek Vasut 
> Cc: Heiko Schocher 
> Cc: Jagan Teki 
> Cc: Marek Behún 
> Cc: Miquel Raynal 
> Cc: Pali Rohár 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Priyanka Jain 
> Cc: Simon Glass 
> ---
>    drivers/mtd/spi/sf_mtd.c | 5 -
>    1 file changed, 4 insertions(+), 1 deletion(-)

 Seem fixes the same problem as Patrick already posted here:

 https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/

 I find your approach cleaner, so:

 Acked-by: Heiko Schocher 

 @Patrick: Could you test this patch please?
>>>
>>> The option from Patrick does look more predictable, but looking at the old 
>>> implementation of spi_flash_mtd_number(), that one handled even cases of 
>>> parallel-nor and spi-nor (both using the nor%d) present on the same system. 
>>> This:
>>>
>>>    static int spi_flash_mtd_number(void)
>>>    {
>>>    #ifdef CONFIG_SYS_MAX_FLASH_BANKS
>>>   return CONFIG_SYS_MAX_FLASH_BANKS;
>>>    #else
>>>   return 0;
>>>    #endif
>>>    }
>>>    ...
>>>    sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
>>>
>>> The patch from Patrick does not, it does per-spi-nor-only counting using 
>>> the dev_seq() there, which is more predictable, but local to spi-nor.
>>>
>>> The MTD core has its own IDR counting, which is used by this patch and is 
>>> global to the MTD core. That has two issues, one is that it is possibly too 
>>> global and counts both nor%d and nand%d, which means it would fail on 
>>> systems with both SPI NOR and regular NAND. The other is it is likely less 
>>> predictable (what happens if the SPI NOR and parallel NOR gets probed in 
>>> the reverse order ? I know it is unlikely, but it can happen in the future).
>>>
>>> So I think we need a third option which I would suggest be based on the 
>>> patch from Patrick, but which would take into account the other nor%d 
>>> devices like parallel NOR flashes.
>>>
>>> That would likely have to happen in the mtd core using some modified IDR 
>>> counting. I think you might need to modify it such that you would pass in 
>>> the prefix of the device (like 'nor') and then do per-prefix counting, with 
>>> the special case that parallel NORs are counted first. Also, that would 
>>> also have to consider probing of multiple SPI NORs in either order (say you 
>>> have two, if you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf 
>>> probe 0:0'), and make sure they get enumerated with the same nor%d value 
>>> either way, that might be where the dev_seq() would come in.
>>
>> I just got a try with this patch and unfortunately, it doesn't solve the 
>> issue.
>> I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2 SPI-NORs.
>> Here is the output of mtd list command:
>>
>> U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)
>>
>> CPU: STM32MP157AAA Rev.B
>> Model: STMicroelectronics STM32MP157C eval daughter on eval mother
>> Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
>> Board: MB1263 Var1.0 Rev.C-01
>> DRAM:  1 GiB
>> Clocks:
>> - MPU : 650 MHz
>> - MCU : 208.878 MHz
>> - AXI : 266.500 MHz
>> - PER : 24 MHz
>> - DDR : 533 MHz
>> WDT:   Started with servicing (32s timeout)
>> NAND:  1024 MiB
>> MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
>> Loading Environment from MMC... *** Warning - bad CRC, using default 
>> environment
>>
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:   eth0: ethernet@5800a000
>> Hit any key to stop autoboot:  0
>> STM32MP> mtd list
>> SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 
>> 64 MiB
>> SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
>> List of MTD devices:
>> * nand0
>>    - type: NAND flash
>>    - block size: 0x4 bytes
>>    - min I/O: 0x1000 bytes
>>    - OOB size: 224 bytes
>>    - OOB available: 118 bytes
>>    - ECC strength: 8 bits
>>    - ECC step size: 512 bytes
>>    - bitflip threshold: 6 bits
>>   

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

[Marek Vasut]

On 9/15/21 10:53 AM, Patrice CHOTARD wrote:

Hi All

On 9/15/21 7:59 AM, Marek Vasut wrote:

On 9/15/21 6:23 AM, Heiko Schocher wrote:

Hi Marek,

On 15.09.21 01:06, Marek Vasut wrote:

The flash->mtd.name used to be nor%d before, now it is the type of the
SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples
of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while
the later is ambiguous if there are multiple flashes of the same type in
the system and breaks existing environments.

This does no longer get recognized when running 'mtdparts' for example:
CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"

Fix this by setting the correct mtd.name to nor%d.

Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple MTDs when DM is 
enabled")
Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Jagan Teki 
Cc: Marek Behún 
Cc: Miquel Raynal 
Cc: Pali Rohár 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Priyanka Jain 
Cc: Simon Glass 
---
   drivers/mtd/spi/sf_mtd.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)


Seem fixes the same problem as Patrick already posted here:

https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/

I find your approach cleaner, so:

Acked-by: Heiko Schocher 

@Patrick: Could you test this patch please?


The option from Patrick does look more predictable, but looking at the old 
implementation of spi_flash_mtd_number(), that one handled even cases of 
parallel-nor and spi-nor (both using the nor%d) present on the same system. 
This:

   static int spi_flash_mtd_number(void)
   {
   #ifdef CONFIG_SYS_MAX_FLASH_BANKS
  return CONFIG_SYS_MAX_FLASH_BANKS;
   #else
  return 0;
   #endif
   }
   ...
   sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());

The patch from Patrick does not, it does per-spi-nor-only counting using the 
dev_seq() there, which is more predictable, but local to spi-nor.

The MTD core has its own IDR counting, which is used by this patch and is 
global to the MTD core. That has two issues, one is that it is possibly too 
global and counts both nor%d and nand%d, which means it would fail on systems 
with both SPI NOR and regular NAND. The other is it is likely less predictable 
(what happens if the SPI NOR and parallel NOR gets probed in the reverse order 
? I know it is unlikely, but it can happen in the future).

So I think we need a third option which I would suggest be based on the patch 
from Patrick, but which would take into account the other nor%d devices like 
parallel NOR flashes.

That would likely have to happen in the mtd core using some modified IDR 
counting. I think you might need to modify it such that you would pass in the 
prefix of the device (like 'nor') and then do per-prefix counting, with the 
special case that parallel NORs are counted first. Also, that would also have 
to consider probing of multiple SPI NORs in either order (say you have two, if 
you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf probe 0:0'), and 
make sure they get enumerated with the same nor%d value either way, that might 
be where the dev_seq() would come in.


I just got a try with this patch and unfortunately, it doesn't solve the issue.
I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2 SPI-NORs.
Here is the output of mtd list command:

U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)

CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM:  1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  1024 MiB
MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Hit any key to stop autoboot:  0
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 
MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
List of MTD devices:
* nand0
   - type: NAND flash
   - block size: 0x4 bytes
   - min I/O: 0x1000 bytes
   - OOB size: 224 bytes
   - OOB available: 118 bytes
   - ECC strength: 8 bits
   - ECC step size: 512 bytes
   - bitflip threshold: 6 bits
   - 0x-0x4000 : "nand0"
* nor2
   - device: mx66l51235l@0
   - parent: spi@58003000
   - driver: jedec_spi_nor
   - path: /soc/spi@58003000/mx66l51235l@0
   - type: NOR flash
   - block size: 0x1 bytes
   - min I/O: 0x1 bytes
   - 0x-0x0400 : "nor2"
* nor2
   - device: mx66l51235l@1
   - parent: spi@58003000
   - driver: jedec_spi_nor
   - path: /soc/spi@58003000/mx66l51235l@1
   - type: NOR flash
   - block size: 0x1 bytes
   - min I/O: 0x1 bytes
   - 0x-0x0400 : "nor2"

Re: [PATCH] mtd: spi-nor: Fix SF MTDIDS when registering multiple MTDs with DM enabled

[Patrice CHOTARD]

Hi All

On 9/15/21 7:59 AM, Marek Vasut wrote:
> On 9/15/21 6:23 AM, Heiko Schocher wrote:
>> Hi Marek,
>>
>> On 15.09.21 01:06, Marek Vasut wrote:
>>> The flash->mtd.name used to be nor%d before, now it is the type of the
>>> SPI NOR like e.g. mt25ql02g. It is possible to find plenty of examples
>>> of the former in U-Boot configs by searching for MTDIDS.*nor.*spi, while
>>> the later is ambiguous if there are multiple flashes of the same type in
>>> the system and breaks existing environments.
>>>
>>> This does no longer get recognized when running 'mtdparts' for example:
>>> CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0"
>>>
>>> Fix this by setting the correct mtd.name to nor%d.
>>>
>>> Fixes: b7f060565e3 ("mtd: spi-nor: allow registering multiple MTDs when DM 
>>> is enabled")
>>> Signed-off-by: Marek Vasut 
>>> Cc: Heiko Schocher 
>>> Cc: Jagan Teki 
>>> Cc: Marek Behún 
>>> Cc: Miquel Raynal 
>>> Cc: Pali Rohár 
>>> Cc: Patrice Chotard 
>>> Cc: Patrick Delaunay 
>>> Cc: Priyanka Jain 
>>> Cc: Simon Glass 
>>> ---
>>>   drivers/mtd/spi/sf_mtd.c | 5 -
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> Seem fixes the same problem as Patrick already posted here:
>>
>> https://patchwork.ozlabs.org/project/uboot/patch/20210913095742.v2.1.I73dae4b93f0587dc130e512e95a1f4794e0b0233@changeid/
>>
>> I find your approach cleaner, so:
>>
>> Acked-by: Heiko Schocher 
>>
>> @Patrick: Could you test this patch please?
> 
> The option from Patrick does look more predictable, but looking at the old 
> implementation of spi_flash_mtd_number(), that one handled even cases of 
> parallel-nor and spi-nor (both using the nor%d) present on the same system. 
> This:
> 
>   static int spi_flash_mtd_number(void)
>   {
>   #ifdef CONFIG_SYS_MAX_FLASH_BANKS
>  return CONFIG_SYS_MAX_FLASH_BANKS;
>   #else
>  return 0;
>   #endif
>   }
>   ...
>   sprintf(sf_mtd_name, "nor%d", spi_flash_mtd_number());
> 
> The patch from Patrick does not, it does per-spi-nor-only counting using the 
> dev_seq() there, which is more predictable, but local to spi-nor.
> 
> The MTD core has its own IDR counting, which is used by this patch and is 
> global to the MTD core. That has two issues, one is that it is possibly too 
> global and counts both nor%d and nand%d, which means it would fail on systems 
> with both SPI NOR and regular NAND. The other is it is likely less 
> predictable (what happens if the SPI NOR and parallel NOR gets probed in the 
> reverse order ? I know it is unlikely, but it can happen in the future).
> 
> So I think we need a third option which I would suggest be based on the patch 
> from Patrick, but which would take into account the other nor%d devices like 
> parallel NOR flashes.
> 
> That would likely have to happen in the mtd core using some modified IDR 
> counting. I think you might need to modify it such that you would pass in the 
> prefix of the device (like 'nor') and then do per-prefix counting, with the 
> special case that parallel NORs are counted first. Also, that would also have 
> to consider probing of multiple SPI NORs in either order (say you have two, 
> if you do 'sf probe 0:0 ; sf probe 0:1' vs. 'sf probe 0:1 ; sf probe 0:0'), 
> and make sure they get enumerated with the same nor%d value either way, that 
> might be where the dev_seq() would come in.

I just got a try with this patch and unfortunately, it doesn't solve the issue.
I tested it on STM32MP1-ev1 board which embedds 1 NAND and 2 SPI-NORs.
Here is the output of mtd list command:

U-Boot 2021.10-rc4-1-g1923b5a21d (Sep 15 2021 - 10:48:48 +0200)

CPU: STM32MP157AAA Rev.B
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var1.0 Rev.C-01
DRAM:  1 GiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  1024 MiB
MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Hit any key to stop autoboot:  0 
STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, total 64 
MiB
SF: Detected nor1 with page size 256 Bytes, erase size 64 KiB, total 64 MiB
List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x4 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 224 bytes
  - OOB available: 118 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x-0x4000 : "nand0"
* nor2
  - device: mx66l51235l@0
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@0
  - type: NOR flash
  - block size: 0x1 bytes
  - min I/O: 0x1 bytes
  - 0x-0x0400 : "nor2"
* nor2
  - device: mx66l51235l@1
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l

Re: [PATCH] arm: dts: stm32mp1: use ssbl partition name for U-Boot

[Patrice CHOTARD]

HI Patrick

On 9/14/21 2:14 PM, Patrick Delaunay wrote:
> Continue to use the "ssbl" name for GPT partition of secondary boot
> stage = U-Boot for basic boot with SPL to avoid to disturb existing user.
> 
> The "fip" partition name is only used for TFA_BOOT with FIP, it is a TF-A
> BL2 requirement; it the default configuration for STMicroelectronics
> boards.
> 
> Fixes: b73e8bf453f8 ("arm: stm32mp: add defconfig for trusted boot with FIP")
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 4 +++-
>  arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 4 +++-
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> index 0101962ea5..15a04ae927 100644
> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
> @@ -21,11 +21,13 @@
>   st,stm32prog-gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | 
> GPIO_PULL_UP)>;
>   };
>  
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> +#if defined(CONFIG_STM32MP15x_STM32IMAGE) || defined(CONFIG_SPL)
>   config {
>   u-boot,mmc-env-partition = "ssbl";
>   };
> +#endif
>  
> +#ifdef CONFIG_STM32MP15x_STM32IMAGE
>   /* only needed for boot with TF-A, witout FIP support */
>   firmware {
>   optee {
> diff --git a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi 
> b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> index 32777384c6..408abaf52f 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi
> @@ -20,11 +20,13 @@
>   st,stm32prog-gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | 
> GPIO_PULL_UP)>;
>   };
>  
> -#ifdef CONFIG_STM32MP15x_STM32IMAGE
> +#if defined(CONFIG_STM32MP15x_STM32IMAGE) || defined(CONFIG_SPL)
>   config {
>   u-boot,mmc-env-partition = "ssbl";
>   };
> +#endif
>  
> +#ifdef CONFIG_STM32MP15x_STM32IMAGE
>   /* only needed for boot with TF-A, witout FIP support */
>   firmware {
>   optee {
> 
Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH 1/3] efi_loader: add SMBIOS table measurement

[Ilias Apalodimas]

Hi Kojima-san,

On Wed, Sep 15, 2021 at 02:15:44PM +0900, Masahisa Kojima wrote:
> TCG PC Client spec requires to measure the SMBIOS
> table that contain static configuration information
> (e.g. Platform Manufacturer Enterprise Number assigned by IANA,
> platform model number, Vendor and Device IDs for each SMBIOS table).
> 
> The device and environment dependent information such as
> serial number is cleared to zero or space character for
> the measurement.
> 
> This commit also fixes the following compiler warning:
> 
> lib/smbios-parser.c:59:39: warning: cast to pointer from integer of
> different size [-Wint-to-pointer-cast]
>   const struct smbios_header *header = (struct smbios_header 
> *)entry->struct_table_address;
> 
> Signed-off-by: Masahisa Kojima 
> ---
>  include/efi_loader.h  |   2 +
>  include/efi_tcg2.h|  15 
>  include/smbios.h  |  13 
>  lib/efi_loader/Kconfig|   1 +
>  lib/efi_loader/efi_boottime.c |   2 +
>  lib/efi_loader/efi_smbios.c   |   2 -
>  lib/efi_loader/efi_tcg2.c |  84 ++
>  lib/smbios-parser.c   | 127 +-
>  8 files changed, 243 insertions(+), 3 deletions(-)
> 
> diff --git a/include/efi_loader.h b/include/efi_loader.h
> index c440962fe5..13f0c24058 100644
> --- a/include/efi_loader.h
> +++ b/include/efi_loader.h
> @@ -308,6 +308,8 @@ extern const efi_guid_t efi_guid_capsule_report;
>  extern const efi_guid_t efi_guid_firmware_management_protocol;
>  /* GUID for the ESRT */
>  extern const efi_guid_t efi_esrt_guid;
> +/* GUID of the SMBIOS table */
> +extern const efi_guid_t smbios_guid;
>  
>  extern char __efi_runtime_start[], __efi_runtime_stop[];
>  extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
> diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
> index 5a1a36212e..da33f8a1d0 100644
> --- a/include/efi_tcg2.h
> +++ b/include/efi_tcg2.h
> @@ -215,6 +215,21 @@ struct efi_tcg2_uefi_variable_data {
>   u8 variable_data[1];
>  };
>  
> +/**
> + * struct tdUEFI_HANDOFF_TABLE_POINTERS2 - event log structure of SMBOIS 
> tables
> + * @table_description_size:  size of table description
> + * @table_description:   table description
> + * @number_of_tables:number of uefi configuration table
> + * @table_entry: uefi configuration table entry
> + */
> +#define SMBIOS_HANDOFF_TABLE_DESC  "SmbiosTable"
> +struct smbios_handoff_table_pointers2 {
> + u8 table_description_size;
> + u8 table_description[sizeof(SMBIOS_HANDOFF_TABLE_DESC)];
> + u64 number_of_tables;
> + struct efi_configuration_table table_entry[1];
> +} __packed;

Is this included in any other struct or array? If not the last member could
be a flexible array member?

> +
>  struct efi_tcg2_protocol {
>   efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
>  struct 
> efi_tcg2_boot_service_capability *capability);
> diff --git a/include/smbios.h b/include/smbios.h
> index aa6b6f3849..0c22c0c489 100644
> --- a/include/smbios.h
> +++ b/include/smbios.h
> @@ -292,4 +292,17 @@ int smbios_update_version(const char *version);
>   */
>  int smbios_update_version_full(void *smbios_tab, const char *version);
>  
> +/**
> + * smbios_prepare_measurement() - Update smbios table for the measurement
> + *
> + * TCG specification requires to measure static configuration information.
> + * This function clear the device dependent parameters such as
> + * serial number for the measurement.
> + *
> + * @entry: pointer to a struct smbios_entry
> + * @header: pointer to a struct smbios_header
> + */
> +void smbios_prepare_measurement(const struct smbios_entry *entry,
> + struct smbios_header *header);
> +
>  #endif /* _SMBIOS_H_ */
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index dacc3b5881..ac1a281a36 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -327,6 +327,7 @@ config EFI_TCG2_PROTOCOL
>   select SHA384
>   select SHA512
>   select HASH
> + select SMBIOS_PARSER
>   help
> Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
> of the platform.
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index f0283b539e..701e2212c8 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -86,6 +86,8 @@ const efi_guid_t efi_guid_event_group_reset_system =
>  /* GUIDs of the Load File and Load File2 protocols */
>  const efi_guid_t efi_guid_load_file_protocol = EFI_LOAD_FILE_PROTOCOL_GUID;
>  const efi_guid_t efi_guid_load_file2_protocol = EFI_LOAD_FILE2_PROTOCOL_GUID;
> +/* GUID of the SMBIOS table */
> +const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
>  
>  static efi_status_t EFIAPI efi_disconnect_controller(
>   efi_handle_t controller_handle,
> diff --git a/lib/efi_loader/

Re: [PATCH 2/2] phy: stm32-usbphyc: stm32: usbphyc: add protection on phy sub-node

[Patrice CHOTARD]

HI Patrick

On 9/14/21 2:31 PM, Patrick Delaunay wrote:
> Add protection on presence and order of the phy node sub node
> by using the mandatory reg information.
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/phy/phy-stm32-usbphyc.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/phy/phy-stm32-usbphyc.c b/drivers/phy/phy-stm32-usbphyc.c
> index c206efd28d..9c1dcfae52 100644
> --- a/drivers/phy/phy-stm32-usbphyc.c
> +++ b/drivers/phy/phy-stm32-usbphyc.c
> @@ -340,7 +340,7 @@ static int stm32_usbphyc_probe(struct udevice *dev)
>   struct stm32_usbphyc *usbphyc = dev_get_priv(dev);
>   struct reset_ctl reset;
>   ofnode node, connector;
> - int i, ret;
> + int ret;
>  
>   usbphyc->base = dev_read_addr(dev);
>   if (usbphyc->base == FDT_ADDR_T_NONE)
> @@ -378,14 +378,18 @@ static int stm32_usbphyc_probe(struct udevice *dev)
>   return ret;
>   }
>  
> - /*
> -  * parse all PHY subnodes in order to populate regulator associated
> -  * to each PHY port
> -  */
> - node = dev_read_first_subnode(dev);
> - for (i = 0; i < MAX_PHYS; i++) {
> - struct stm32_usbphyc_phy *usbphyc_phy = usbphyc->phys + i;
> + /* parse all PHY subnodes to populate regulator associated to each PHY 
> port */
> + dev_for_each_subnode(node, dev) {
> + fdt_addr_t phy_id;
> + struct stm32_usbphyc_phy *usbphyc_phy;
>  
> + phy_id = ofnode_read_u32_default(node, "reg", FDT_ADDR_T_NONE);
> + if (phy_id >= MAX_PHYS) {
> + dev_err(dev, "invalid reg value %lx for %s\n",
> + phy_id, ofnode_get_name(node));
> + return -ENOENT;
> + }
> + usbphyc_phy = usbphyc->phys + phy_id;
>   usbphyc_phy->init = false;
>   usbphyc_phy->powered = false;
>   ret = stm32_usbphyc_get_regulator(node, "phy-supply",
> @@ -401,8 +405,6 @@ static int stm32_usbphyc_probe(struct udevice *dev)
>   ret = stm32_usbphyc_get_regulator(connector, 
> "vbus-supply",
> &usbphyc_phy->vbus);
>   }
> -
> - node = dev_read_next_subnode(node);
>   }
>  
>   /* Check if second port has to be used for host controller */
> 
Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH 1/2] phy: stm32-usbphyc: use connector for vbus-supply with phy-stm32-usbphyc

[Patrice CHOTARD]

Hi Patrick

On 9/14/21 2:31 PM, Patrick Delaunay wrote:
> The vbus-supply is an optional property of sub-node connector node.
> and no more in the usb phyc node (in first proposed binding).
> 
> This regulator for USB VBUS may be needed for host mode.
> 
> See the latest kernel binding for details in
> Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml.
> 
>   usbphyc_port0: usb-phy@0 {
>   reg = <0>;
>   phy-supply = <&vdd_usb>;
>   #phy-cells = <0>;
>   connector {
>   compatible = "usb-a-connector";
>   vbus-supply = <&vbus_sw>;
>   };
>   };
> 
> Signed-off-by: Patrick Delaunay 
> ---
> 
>  drivers/phy/phy-stm32-usbphyc.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/phy/phy-stm32-usbphyc.c b/drivers/phy/phy-stm32-usbphyc.c
> index 02d859a039..c206efd28d 100644
> --- a/drivers/phy/phy-stm32-usbphyc.c
> +++ b/drivers/phy/phy-stm32-usbphyc.c
> @@ -339,7 +339,7 @@ static int stm32_usbphyc_probe(struct udevice *dev)
>  {
>   struct stm32_usbphyc *usbphyc = dev_get_priv(dev);
>   struct reset_ctl reset;
> - ofnode node;
> + ofnode node, connector;
>   int i, ret;
>  
>   usbphyc->base = dev_read_addr(dev);
> @@ -395,10 +395,12 @@ static int stm32_usbphyc_probe(struct udevice *dev)
>   return ret;
>   }
>  
> - ret = stm32_usbphyc_get_regulator(node, "vbus-supply",
> -   &usbphyc_phy->vbus);
> - if (ret)
> - usbphyc_phy->vbus = NULL;
> + usbphyc_phy->vbus = NULL;
> + connector = ofnode_find_subnode(node, "connector");
> + if (ofnode_valid(connector)) {
> + ret = stm32_usbphyc_get_regulator(connector, 
> "vbus-supply",
> +   &usbphyc_phy->vbus);
> + }
>  
>   node = dev_read_next_subnode(node);
>   }
> 
Reviewed-by: Patrice Chotard 

Thanks
Patrice

Re: [PATCH] mtd: cqspi: Wait for transfer completion

[Marek Vasut]

On 9/15/21 10:28 AM, Pratyush Yadav wrote:

On 14/09/21 08:22PM, Marek Vasut wrote:

On 9/14/21 7:42 PM, Pratyush Yadav wrote:

On 14/09/21 05:22AM, Marek Vasut wrote:

Wait for the read/write transfer finish bit get actually cleared,
this does not happen immediately on at least SoCFPGA Gen5.

Signed-off-by: Marek Vasut 
Cc: Jagan Teki 
Cc: Vignesh R 
Cc: Pratyush Yadav 
---
   drivers/spi/cadence_qspi_apb.c | 17 +
   1 file changed, 17 insertions(+)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 429ee335db6..2cdf4c9c9f8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_plat *plat,
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
+   /* Check indirect done status */
+   ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
+   CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
+   if (ret) {
+   printf("Indirect read clear completion error (%i)\n", ret);
+   goto failrd;
+   }
+


Huh, this is strange. I would expect the bit to clear immediately since
it doesn't really do any operation on the flash. How long does it
usually take to clear? If you don't wait for it to clear does anything
break?


Often it does clear immediately, but there were a few odd cases where it did
not happen right away, in which case I had transfer corruption.


By "transfer corruption" do you mean the current transfer gets corrupted
or the next one?

We get here _after_ the transfer is completed and this bit should have
little to do with the data received. If the current transfer fails then
I suspect something else might be going wrong the this is just a symptom
of the problem.


As far as I recall, the problem was triggered when using UBI on the SPI 
NOR, so that could very well be the next transfer.

Re: [PATCH] mtd: cqspi: Wait for transfer completion

[Pratyush Yadav]

On 14/09/21 08:22PM, Marek Vasut wrote:
> On 9/14/21 7:42 PM, Pratyush Yadav wrote:
> > On 14/09/21 05:22AM, Marek Vasut wrote:
> > > Wait for the read/write transfer finish bit get actually cleared,
> > > this does not happen immediately on at least SoCFPGA Gen5.
> > > 
> > > Signed-off-by: Marek Vasut 
> > > Cc: Jagan Teki 
> > > Cc: Vignesh R 
> > > Cc: Pratyush Yadav 
> > > ---
> > >   drivers/spi/cadence_qspi_apb.c | 17 +
> > >   1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/drivers/spi/cadence_qspi_apb.c 
> > > b/drivers/spi/cadence_qspi_apb.c
> > > index 429ee335db6..2cdf4c9c9f8 100644
> > > --- a/drivers/spi/cadence_qspi_apb.c
> > > +++ b/drivers/spi/cadence_qspi_apb.c
> > > @@ -858,6 +858,14 @@ cadence_qspi_apb_indirect_read_execute(struct 
> > > cadence_spi_plat *plat,
> > >   writel(CQSPI_REG_INDIRECTRD_DONE,
> > >  plat->regbase + CQSPI_REG_INDIRECTRD);
> > > + /* Check indirect done status */
> > > + ret = wait_for_bit_le32(plat->regbase + CQSPI_REG_INDIRECTRD,
> > > + CQSPI_REG_INDIRECTRD_DONE, 0, 10, 0);
> > > + if (ret) {
> > > + printf("Indirect read clear completion error (%i)\n", ret);
> > > + goto failrd;
> > > + }
> > > +
> > 
> > Huh, this is strange. I would expect the bit to clear immediately since
> > it doesn't really do any operation on the flash. How long does it
> > usually take to clear? If you don't wait for it to clear does anything
> > break?
> 
> Often it does clear immediately, but there were a few odd cases where it did
> not happen right away, in which case I had transfer corruption.

By "transfer corruption" do you mean the current transfer gets corrupted 
or the next one?

We get here _after_ the transfer is completed and this bit should have 
little to do with the data received. If the current transfer fails then 
I suspect something else might be going wrong the this is just a symptom 
of the problem.

-- 
Regards,
Pratyush Yadav
Texas Instruments Inc.

Re: [PATCH v2 1/9] ARM: meson: Sync Amlogic DT from Linux 5.14

[Neil Armstrong]

Hi,

On 15/09/2021 09:49, Vyacheslav wrote:
> 08.09.2021 17:17, Neil Armstrong via groups.io wrote:
>> diff --git a/arch/arm/dts/meson-axg.dtsi b/arch/arm/dts/meson-axg.dtsi
>> index b9efc84692..3f5254eeb4 100644
>> --- a/arch/arm/dts/meson-axg.dtsi
>> +++ b/arch/arm/dts/meson-axg.dtsi
> ...
>> +
>> +    usb: usb@ffe09080 {
>> +    compatible = "amlogic,meson-axg-usb-ctrl";
>> +    reg = <0x0 0xffe09080 0x0 0x20>;
>> +    interrupts = ;
>> +    #address-cells = <2>;
> 
> Hi.
> I have looked through the dts for axg and found that a usb node use 
> "amlogic,meson-axg-usb-ctrl" that is not supported in uboot. In linux-kernel 
> it exists in drivers/usb/dwc3/dwc3-meson-g12a.c
> In previous dts usb node used amlogic,meson-gxl-usb-ctrl and it worked good.
> 

You're right, "amlogic,meson-axg-usb-ctrl" is missing in the 
drivers/usb/dwc3/dwc3-meson-gxl.c driver

I'll add and resend the serie.

Neil

Re: [PATCH v3 27/29] arm: dts: ls1028a: drop non-removable property from esdhc controller node

[Michael Walle]

Am 2021-09-15 02:17, schrieb Vladimir Oltean:

On Thu, Sep 02, 2021 at 06:45:56PM +0200, Michael Walle wrote:
The linux device tree hasn't set this property. To be similarly we 
remove


s/similarly/similar/


it from the u-boot device tree, too. The second controller of the
LS1028A has indeed no card detect pin.


Because it is an eMMC controller.


The present state register of the
second controller will always report the card as present. Thus, there
should be no functional change otherwise than one more register access
to read the present state.


Tested?


Yes, I've tested the eMMC (and actually using it this way). I also
manually read out the register value and made sure the card detect
bit is set.


The property should still be introduced in
the linux device tree.


How do you feel about dropping this patch?


If I drop this patch, I'll either have to (1) keep this property
the device tree sync patch too or (2) it will be removed without a
comment in that patch.

I presume you prefer (1), but as I said, I'd keep the device trees
between linux and u-boot the same and keep it simple by just copying
the files. So yes, I'd like to keep this patch as the point of this
patch is to give an explanation why this property is removed (until
it might or might not be introduced in the kernel device tree; in
fact I thought I had send a patch to the LKML but I must have
forgotten it).

I was thinking of putting it into the -u-boot.dtsi, but as there
is no breakage, I didn't.

Thanks for reviewing the patches!

-michael


Signed-off-by: Michael Walle 
---
 arch/arm/dts/fsl-ls1028a.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/dts/fsl-ls1028a.dtsi 
b/arch/arm/dts/fsl-ls1028a.dtsi

index d2f558d208..af6dabe847 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -210,7 +210,6 @@
reg = <0x0 0x215 0x0 0x1>;
interrupts = ;
big-endian;
-   non-removable;
bus-width = <4>;
status = "disabled";
};
--
2.30.2

Re: [PATCH 9/9] board: sifive: Fix -Wint-to-pointer-cast warning

[Leo Liang]

On Sun, Sep 12, 2021 at 11:15:16AM +0800, Bin Meng wrote:
> The following warning is seen in unleashed.c in a 32-bit build:
> 
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
> 
> Cast with uintptr_t.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  board/sifive/unleashed/unleashed.c | 2 +-
>  board/sifive/unmatched/unmatched.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH v3 21/29] scsi: ceva: rename the resource name to match the linux kernel one

[Michael Walle]

Am 2021-09-15 02:10, schrieb Vladimir Oltean:

On Thu, Sep 02, 2021 at 06:45:50PM +0200, Michael Walle wrote:
The driver will look for a named resource "ecc-addr", but this isn't 
the

official binding. In fact, the official device tree binding
documentation doesn't mention any resource names at all. But it is 
safe

to assume that it's the linux ones we have to use if we want to be
compatible with the linux device tree. Thus rename "ecc-addr" to
"sata-ecc" and convert all the users in u-boot.

While at it, also rename "sata-base" to "ahci" although its not used 
at

all.

This change doesn't affect the SATA controller on the ZynqMP.


Because the "ceva,ahci-1v84" device doesn't have an ECC region, right.


I don't know if it doesn't have any. But it's not used in the
driver nor is it described in the device tree (binding).


Cc: Michal Simek 
Signed-off-by: Michael Walle 
---


Reviewed-by: Vladimir Oltean 

Re: [PATCH 8/9] ram: sifive: Fix -Wint-to-pointer-cast warnings

[Leo Liang]

On Sun, Sep 12, 2021 at 11:15:15AM +0800, Bin Meng wrote:
> The following warning is seen in sifive_ddr.c in a 32-bit build:
> 
>   warning: cast to pointer from integer of different size 
> [-Wint-to-pointer-cast]
> 
> Change to use dev_read_addr_index_ptr().
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/ram/sifive/sifive_ddr.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 6/9] dm: Provide dev_read_addr_index_ptr() wrapper

[Leo Liang]

On Sun, Sep 12, 2021 at 11:15:13AM +0800, Bin Meng wrote:
> Like dev_read_addr_ptr(), provide a wrapper for the indexed version.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  include/dm/read.h | 18 ++
>  1 file changed, 18 insertions(+)

Reviewed-by: Leo Yu-Chi Liang 

Re: [PATCH 5/9] dm: core: Add a new API devfdt_get_addr_index_ptr()

[Leo Liang]

On Sun, Sep 12, 2021 at 11:15:12AM +0800, Bin Meng wrote:
> At present there is only devfdt_get_addr_ptr() which only returns
> the first  pair in the 'reg' property. Add a new API
> devfdt_get_addr_index_ptr() to return the indexed pointer.
> 
> Signed-off-by: Bin Meng 
> ---
> 
>  drivers/core/fdtaddr.c | 11 ---
>  include/dm/fdtaddr.h   | 12 
>  2 files changed, 20 insertions(+), 3 deletions(-)

Reviewed-by: Leo Yu-Chi Liang