Re: using sudo?, Re: [PATCH v2 8/8] test/py: efi_secboot: add test for intermediate certificates
Tom, On Wed, Jul 08, 2020 at 11:15:26PM -0400, Tom Rini wrote: > On Thu, Jul 09, 2020 at 09:58:03AM +0900, AKASHI Takahiro wrote: > > > Hi Tom, > > > > I'd like to make sure of your policy about usage of "sudo" on CI. > > Do you think that we should always avoid using "sudo" in testing? > > > > I remember that you had allowed us to run sudo in (python) > > test scripts on Travis CI when I requested this (for FAT filesystem?). > > So, the best practices at this time are to have the code try and use > guestmount (or similar tools) when possible and fall back to sudo, as > Ubuntu breaks guestmount (and similar tools) by default. See the commands log (on my ubuntu 19.10) below: ===8<=== << try 1 >> tmp$ mkdir tmpdir tmp$ virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img libguestfs: error: /usr/bin/supermin exited with error status 1. To see full error messages you may need to enable debugging. Do: export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 and run the command again. For further information, read: http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs You can also run 'libguestfs-test-tool' and post the *complete* output into a bug report or message to the libguestfs mailing list. << try 2 >> tmp$ LIBGUESTFS_DEBUG=1 virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img ... supermin: kernel: kernel_version 5.3.0-62-generic supermin: kernel: modpath /lib/modules/5.3.0-62-generic cp: cannot open '/boot/vmlinuz-5.3.0-62-generic' for reading: Permission denied supermin: cp -p '/boot/vmlinuz-5.3.0-62-generic' '/var/tmp/.guestfs-1000/appliance.d.op62psoy/kernel': command failed, see earlier errors libguestfs: error: /usr/bin/supermin exited with error status 1, see debug messages above ... << try 3 >> tmp$ sudo chmod a+rw /boot/vmlinuz-5.3.0-62-generic tmp$ LIBGUESTFS_DEBUG=1 virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img ... tmp$ ls -l tmp.img -rw-r--r-- 1 akashi akashi 1341440 Jul 9 13:50 tmp.img ===>8=== As you can see, virt-make-fs will fail on *standard* ubuntu. You have to change the permission of the current kernel's binary. While I can't make sure, we will have the same issue with guestmount as it will also create a minimum virtual machine before execution. What does it mean? You must change the permission every time when you re-install the OS or re-bump the kernel version. Obviously, I can't do that from my own test script (without sudo). So if you don't have any way (or workaround) to deal with it, libguestfs-tools or guestmount cannot be a solution here. -Takahiro Akashi > -- > Tom
Re: [PATCH v2 2/5] arm: kirkwood: convert LaCie boards to DM_SPI_FLASH
On 08.07.20 20:46, Jagan Teki wrote: On Wed, Jul 8, 2020 at 12:19 PM Jagan Teki wrote: On Sun, Jun 28, 2020 at 10:31 PM Simon Guinot wrote: This patch converts the following Kirkwood-based LaCie boards to DM, DM_SPI and DM_SPI_FLASH: - d2 Network v2 - Internet Space v2 - 2Big Network v2 - Network Space v2 - Network Space Lite v2 - Network Space Max v2 - Network Space Mini v2 Signed-off-by: Simon Guinot --- Reviewed-by: Jagan Teki Any chance to move this series into master, I have a dependency for kirkwood spi driver patches. I'll try to take care of it today. Thanks, Stefan
Re: [PATCH] arm: cmd_stm32prog: Fix the CONFIG_IS_ENABLED() usage
On Thu, Jul 9, 2020 at 1:32 AM Patrick DELAUNAY wrote: > > Hi Bin, > > > From: Bin Meng > > Sent: mercredi 8 juillet 2020 09:19 > > > > Add parentheses around CONFIG_IS_ENABLED() in the if statement, to fix > > potential build failures. > > > > Signed-off-by: Bin Meng > > > > --- > > Fixes the issue as seen with Azure: > > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=251=logs=064 > > 47dc8-3759-5480-c2ba-b1f5a74bd12e=3906ed62-68d1-5fd5-bbe4-e8a557f9b32f > > > > arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > > b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > > index 0722e4a..cbf0120 100644 > > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > > @@ -147,7 +147,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, > > int argc, > > /* Try bootm for legacy and FIT format image */ > > if (genimg_get_format((void *)uimage) != > > IMAGE_FORMAT_INVALID) > > do_bootm(cmdtp, 0, 4, bootm_argv); > > - else if CONFIG_IS_ENABLED(CMD_BOOTZ) > > + else if (CONFIG_IS_ENABLED(CMD_BOOTZ)) > > do_bootz(cmdtp, 0, 4, bootm_argv); > > } > > > > -- > > 2.7.4 > > Reviewed-by: Patrick Delaunay > applied to u-boot-x86, thanks!
Re: [PATCH 1/8] dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matching
Simon,
On 7/2/20 10:50 PM, Simon Glass wrote:
On Mon, 29 Jun 2020 at 22:38, Dave Gerlach wrote:
Introduce UCLASS_SOC to be used for SOC identification and attribute
matching based on the SoC ID info. This allows drivers to be provided
for SoCs to retrieve SoC identifying information and also for matching
device attributes for selecting SoC specific data.
This is useful for other device drivers that may need different
parameters or quirks enabled depending on the specific device variant in
use.
Signed-off-by: Dave Gerlach
---
drivers/soc/Kconfig | 9 +++
drivers/soc/Makefile | 1 +
drivers/soc/soc-uclass.c | 102 ++
include/dm/uclass-id.h | 1 +
include/soc.h| 132 +++
5 files changed, 245 insertions(+)
create mode 100644 drivers/soc/soc-uclass.c
create mode 100644 include/soc.h
Reviewed-by: Simon Glass
As Tom says, docs please but looks great otherwise.
Yes will add docs in v2.
Nits below. Do you think it might make sense to have an
integer-encoded version? Maybe it would be more hassle than it is
worth.
Well my primary driver for using strings was to be consistent with the
kernel counterpart, but I also thought it was convenient beacuse it
allows the identifiers to be descriptive and also to be printed out
directly once retrieved. Attributes could be added as needed in the future.
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 7b4e4d613088..e715dfd01712 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,5 +1,14 @@
menu "SOC (System On Chip) specific Drivers"
+config SOC_DEVICE
+ bool "Enable SoC Device ID drivers using Driver Model"
+ help
+ This allows drivers to be provided for SoCs to help in identifying
+ the SoC in use and matching SoC attributes for selecting SoC
+ specific data. This is useful for other device drivers that may
+ need different parameters or quirks enabled depending on the
+ specific device variant in use.
+
source "drivers/soc/ti/Kconfig"
endmenu
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index ce253b7aa886..1c09a8465670 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,3 +3,4 @@
# Makefile for the U-Boot SOC specific device drivers.
obj-$(CONFIG_SOC_TI) += ti/
+obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
diff --git a/drivers/soc/soc-uclass.c b/drivers/soc/soc-uclass.c
new file mode 100644
index ..22f89514ed7d
--- /dev/null
+++ b/drivers/soc/soc-uclass.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 - Texas Instruments Incorporated - http://www.ti.com/
+ * Dave Gerlach
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+int soc_get(struct udevice **devp)
+{
+ return uclass_first_device_err(UCLASS_SOC, devp);
+}
+
+int soc_get_machine(struct udevice *dev, char *buf, int size)
+{
+ struct soc_ops *ops = soc_get_ops(dev);
+
+ if (!ops->get_machine)
+ return -ENOSYS;
+
+ return ops->get_machine(dev, buf, size);
+}
+
+int soc_get_family(struct udevice *dev, char *buf, int size)
+{
+ struct soc_ops *ops = soc_get_ops(dev);
+
+ if (!ops->get_family)
+ return -ENOSYS;
+
+ return ops->get_family(dev, buf, size);
+}
+
+int soc_get_revision(struct udevice *dev, char *buf, int size)
+{
+ struct soc_ops *ops = soc_get_ops(dev);
+
+ if (!ops->get_revision)
+ return -ENOSYS;
+
+ return ops->get_revision(dev, buf, size);
+}
+
+const struct soc_device_attribute *
+soc_device_match(const struct soc_device_attribute *matches)
+{
+ bool match;
+ struct udevice *soc;
+ char str[SOC_MAX_STR_SIZE];
+
+ if (!matches)
+ return NULL;
+
+ if (soc_get())
+ return NULL;
+
+ while (1) {
+ if (!(matches->machine || matches->family ||
+ matches->revision))
+ break;
+
+ match = true;
+
+ if (matches->machine) {
+ if (!soc_get_machine(soc, str, SOC_MAX_STR_SIZE)) {
+ if (strcmp(matches->machine, str))
+ match = false;
+ }
+ }
+
+ if (matches->family) {
+ if (!soc_get_family(soc, str, SOC_MAX_STR_SIZE)) {
+ if (strcmp(matches->family, str))
+ match = false;
+ }
+ }
+
+ if (matches->revision) {
+ if (!soc_get_revision(soc, str, SOC_MAX_STR_SIZE)) {
+ if (strcmp(matches->revision, str))
+ match = false;
+ }
+ }
+
+ if (match)
+
Re: [PATCH 1/8] dm: soc: Introduce UCLASS_SOC for SOC ID and attribute matching
Tom, On 6/30/20 7:43 AM, Tom Rini wrote: On Mon, Jun 29, 2020 at 11:38:46PM -0500, Dave Gerlach wrote: Introduce UCLASS_SOC to be used for SOC identification and attribute matching based on the SoC ID info. This allows drivers to be provided for SoCs to retrieve SoC identifying information and also for matching device attributes for selecting SoC specific data. This is useful for other device drivers that may need different parameters or quirks enabled depending on the specific device variant in use. Signed-off-by: Dave Gerlach --- drivers/soc/Kconfig | 9 +++ drivers/soc/Makefile | 1 + drivers/soc/soc-uclass.c | 102 ++ include/dm/uclass-id.h | 1 + include/soc.h| 132 +++ 5 files changed, 245 insertions(+) create mode 100644 drivers/soc/soc-uclass.c create mode 100644 include/soc.h Can we please get a write-up in doc/driver-model/ as well for this? Thanks! Yes, will add for v2, thanks for the suggestion. Regards, Dave
Re: using sudo?, Re: [PATCH v2 8/8] test/py: efi_secboot: add test for intermediate certificates
On Thu, Jul 09, 2020 at 09:58:03AM +0900, AKASHI Takahiro wrote: > Hi Tom, > > I'd like to make sure of your policy about usage of "sudo" on CI. > Do you think that we should always avoid using "sudo" in testing? > > I remember that you had allowed us to run sudo in (python) > test scripts on Travis CI when I requested this (for FAT filesystem?). So, the best practices at this time are to have the code try and use guestmount (or similar tools) when possible and fall back to sudo, as Ubuntu breaks guestmount (and similar tools) by default. -- Tom signature.asc Description: PGP signature
using sudo?, Re: [PATCH v2 8/8] test/py: efi_secboot: add test for intermediate certificates
Hi Tom,
I'd like to make sure of your policy about usage of "sudo" on CI.
Do you think that we should always avoid using "sudo" in testing?
I remember that you had allowed us to run sudo in (python)
test scripts on Travis CI when I requested this (for FAT filesystem?).
-Takahiro Akashi
On Tue, Jul 07, 2020 at 12:42:35PM +0200, Heinrich Schuchardt wrote:
> On 16.06.20 07:26, AKASHI Takahiro wrote:
> > In this test case, an image may have a signature with additional
> > intermediate certificates. A chain of trust will be followed and all
> > the certificates in the middle of chain must be verified before loading.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > test/py/tests/test_efi_secboot/conftest.py| 138 +-
> > test/py/tests/test_efi_secboot/defs.py| 11 +-
> > test/py/tests/test_efi_secboot/openssl.cnf| 48 ++
> > .../test_efi_secboot/test_signed_intca.py | 134 +
> > 4 files changed, 328 insertions(+), 3 deletions(-)
> > create mode 100644 test/py/tests/test_efi_secboot/openssl.cnf
> > create mode 100644 test/py/tests/test_efi_secboot/test_signed_intca.py
> >
> > diff --git a/test/py/tests/test_efi_secboot/conftest.py
> > b/test/py/tests/test_efi_secboot/conftest.py
> > index 34abcd79ae00..e5ac2a2a21b7 100644
> > --- a/test/py/tests/test_efi_secboot/conftest.py
> > +++ b/test/py/tests/test_efi_secboot/conftest.py
> > @@ -37,7 +37,7 @@ def efi_boot_env(request, u_boot_config):
> > global HELLO_PATH
> >
> > image_path = u_boot_config.persistent_data_dir
> > -image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME
> > +image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME + '.img'
> > image_size = EFI_SECBOOT_IMAGE_SIZE
> > part_size = EFI_SECBOOT_PART_SIZE
> > fs_type = EFI_SECBOOT_FS_TYPE
> > @@ -46,7 +46,7 @@ def efi_boot_env(request, u_boot_config):
> > HELLO_PATH = u_boot_config.build_dir +
> > '/lib/efi_loader/helloworld.efi'
> >
> > try:
> > -mnt_point = u_boot_config.persistent_data_dir + '/mnt_efisecure'
> > +mnt_point = u_boot_config.persistent_data_dir + MNTPNT
> > check_call('mkdir -p {}'.format(mnt_point), shell=True)
> >
> > # create a disk/partition
> > @@ -170,3 +170,137 @@ def efi_boot_env(request, u_boot_config):
> > yield image_path
> > finally:
> > call('rm -f %s' % image_path, shell=True)
> > +
> > +#
> > +# Fixture for UEFI secure boot test of intermediate certificates
>
> Thanks for adding a test.
>
>
> > +#
> > +@pytest.fixture(scope='session')
> > +def efi_boot_env_intca(request, u_boot_config):
> > +"""Set up a file system to be used in UEFI secure boot test
> > +of intermediate certificates.
> > +
> > +Args:
> > +request: Pytest request object.
> > + u_boot_config: U-boot configuration.
> > +
> > +Return:
> > +A path to disk image to be used for testing
> > +"""
> > +global HELLO_PATH
> > +
> > +image_path = u_boot_config.persistent_data_dir
> > +image_path = image_path + '/' + EFI_SECBOOT_IMAGE_NAME + '_intca.img'
> > +image_size = EFI_SECBOOT_IMAGE_SIZE
> > +part_size = EFI_SECBOOT_PART_SIZE
> > +fs_type = EFI_SECBOOT_FS_TYPE
> > +
> > +if HELLO_PATH == '':
> > +HELLO_PATH = u_boot_config.build_dir +
> > '/lib/efi_loader/helloworld.efi'
> > +
> > +try:
> > +mnt_point = u_boot_config.persistent_data_dir + MNTPNT
> > +check_call('mkdir -p {}'.format(mnt_point), shell=True)
> > +
> > +# create a disk/partition
> > +check_call('dd if=/dev/zero of=%s bs=1MiB count=%d'
> > +% (image_path, image_size), shell=True)
> > +check_call('sgdisk %s -n 1:0:+%dMiB'
> > +% (image_path, part_size), shell=True)
> > +# create a file system
> > +check_call('dd if=/dev/zero of=%s.tmp bs=1MiB count=%d'
> > +% (image_path, part_size), shell=True)
> > +check_call('mkfs -t %s %s.tmp' % (fs_type, image_path), shell=True)
> > +check_call('dd if=%s.tmp of=%s bs=1MiB seek=1 count=%d
> > conv=notrunc'
> > +% (image_path, image_path, 1), shell=True)
> > +check_call('rm %s.tmp' % image_path, shell=True)
> > +loop_dev = check_output('sudo losetup -o 1MiB --sizelimit %dMiB
> > --show -f %s | tr -d "\n"'
> > +% (part_size, image_path),
> > shell=True).decode()
> > +check_output('sudo mount -t %s -o umask=000 %s %s'
> > +% (fs_type, loop_dev, mnt_point),
> > shell=True)
>
> Can we use virt-make-fs to avoid sudo, please. Package libguestfs-tools
> has been added to the Docker image for Gitlab recently.
>
> > +
> > +# Create signature database
> > +## PK
> > +check_call('cd %s; openssl req -x509 -sha256 -newkey rsa:2048
> > -subj /CN=TEST_PK/ -keyout PK.key -out
Re: [PATCH v3 01/13] lib/crypto, efi_loader: avoid multiple inclusions of header files
Heinrich, On Wed, Jul 08, 2020 at 12:29:54PM +0200, Heinrich Schuchardt wrote: > On 08.07.20 07:01, AKASHI Takahiro wrote: > > By adding extra symbols, we can now avoid including x509_parser and > > pkcs7_parser.h files multiple times. > > > > Signed-off-by: AKASHI Takahiro > > Suggested-by: Heinrich Schuchardt > > --- > > lib/efi_loader/efi_image_loader.c | 1 + > > lib/efi_loader/efi_signature.c| 1 + > > 2 files changed, 2 insertions(+) > > > > diff --git a/lib/efi_loader/efi_image_loader.c > > b/lib/efi_loader/efi_image_loader.c > > index 06a2ebdb9081..5b00fea2f113 100644 > > --- a/lib/efi_loader/efi_image_loader.c > > +++ b/lib/efi_loader/efi_image_loader.c > > @@ -14,6 +14,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID; > > diff --git a/lib/efi_loader/efi_signature.c b/lib/efi_loader/efi_signature.c > > index e05c471c61ce..da3818ac62e2 100644 > > --- a/lib/efi_loader/efi_signature.c > > +++ b/lib/efi_loader/efi_signature.c > > @@ -11,6 +11,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include > > The patch (and the commit message) seems to have been somehow corrupted during my rework. > I would prefer to use > > [PATCH 1/1] lib/crypto: use qualified path for x509_parser.h > https://lists.denx.de/pipermail/u-boot/2020-July/419214.html My point is, as I said before, that we should include a header *directly* if some symbols in that header are used in a given file even though such a header is *indirectly* inherited by another header, pkcs7_parser.h in this case. That way, "#include" explicitly indicates that the C file relies on another header and associated functions. I always take this practice. In this sense, this patch still makes sense. -Takahiro Akashi > > which has the same effect. > > Best regards > > Heinrich
Re: [PATCH v2] cmd: add a panic command
On Tue, Jun 30, 2020 at 01:05:45AM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > Even in boot scripts it may be needed to "panic" when all options > are exhausted and the device specification specifies hanging > instead of resetting the board. > > So add a new panic command that just wraps around the core panic > call in U-Boot and can take an optional message. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Simon Glass > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 8/8] spl: fit: select SPL_CRYPTO_SUPPORT for SPL_FIT_SIGNATURE
On Thu, Jun 18, 2020 at 04:23:28PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > Verifying FIT images obviously needs the rsa parts of crypto > support and while main uboot always compiles crypto support, > it's optional for SPL and we should thus select the necessary > option to not end up in compile errors like: > > u-boot/lib/rsa/rsa-verify.c:328: undefined reference to `rsa_mod_exp' > > So select SPL_CRYPTO_SUPPORT in SPL_FIT_SIGNATURE. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 1/1] lib: rsa: fix allocated size for rr and rrtmp in rsa_gen_key_prop()
On Tue, Jul 07, 2020 at 10:57:26PM +0200, Heinrich Schuchardt wrote: > From: Heiko Stuebner > > When calculating rrtmp/rr rsa_gen_key_prop() tries to make > (((rlen + 31) >> 5) + 1) steps in the rr uint32_t array and > (((rlen + 7) >> 3) + 1) / 4 steps in uint32_t rrtmp[] > with rlen being num_bits * 2 > > On a 4096bit key this comes down to to 257 uint32_t elements > in rr and 256 elements in rrtmp but with the current allocation > rr and rrtmp only have 129 uint32_t elements. > > On 2048bit keys this works by chance as the defined max_rsa_size=4096 > allocates a suitable number of elements, but with an actual 4096bit key > this results in other memory parts getting overwritten. > > So as suggested by Heinrich Schuchardt just use the actual bit-size > of the key as base for the size calculation, in turn making the code > compatible to any future keysizes. > > Suggested-by: Heinrich Schuchardt > Signed-off-by: Heiko Stuebner > Reviewed-by: Simon Glass > > rrtmp needs 2 + (((*prop)->num_bits * 2) >> 5) array elements. > > Reviewed-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 7/8] spl: fit: select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE
On Thu, Jun 18, 2020 at 04:23:27PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > rsa-checsum needs support for hash functions or else will run into > compile errors like: > u-boot/lib/rsa/rsa-checksum.c:28: undefined reference to > `hash_progressive_lookup_algo' > > So similar to the main FIT_SIGNATURE entry selects HASH, > select SPL_HASH_SUPPORT for SPL_FIT_SIGNATURE. > > Cc: Heinrich Schuchardt > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 1/8] lib: rsa: distinguish between tpl and spl for CONFIG_RSA_VERIFY
On Thu, Jun 18, 2020 at 04:23:21PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > While the SPL may want to do signature checking this won't be > the case for TPL in all cases, as TPL is mostly used when the > amount of initial memory is not enough for a full SPL. > > So on a system where SPL uses DM but TPL does not we currently > end up with a TPL compile error of: > > lib/rsa/rsa-verify.c:48:25: error: dereferencing pointer to incomplete > type ‘struct checksum_algo’ > > To prevent that change the $(SPL_) to $(SPL_TPL_) to distinguish > between both. If someone really needs FIT signature checking in > TPL as well, a new TPL_RSA_VERIFY config symbol needs to be added. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 6/8] lib: rsa: add documentation to padding_pss_verify to document limitations
On Thu, Jun 18, 2020 at 04:23:26PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > padding_pss_verify only works with the default pss salt setting of -2 > (length to be automatically determined based on the PSS block structure) > not -1 (salt length set to the maximum permissible value), which makes > verifications of signatures with that saltlen fail. > > Until this gets implemented at least document this behaviour. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 2/8] lib: rsa: take spl/non-spl into account when building rsa_verify_with_pkey()
On Thu, Jun 18, 2020 at 04:23:22PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > Right now in multiple places there are only checks for the full > CONFIG_RSA_VERIFY_WITH_PKEY option, not split into main,spl,tpl variants. > > This breaks when the rsa functions get enabled for SPL, for example to > verify u-boot proper from spl. > > So fix this by using the existing helpers to distinguis between > build-steps. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] tpm2: tis_spi: add linux compatible fallback string
On Fri, Jun 12, 2020 at 05:17:33PM +0200, Bruno Thomsen wrote: > This solves a compatibility issue with Linux device trees > that contain TPMv2.x hardware. So it's easier to import DTS > from upstream kernel when migrating board init from C code > to DTS. > > The issue is that fallback binding is different between Linux > and u-Boot. > > Linux: "tcg,tpm_tis-spi" > U-Boot: "tis,tpm2-spi" > > As there are currently no in-tree users of the U-Boot binding, > it makes sense to use Linux fallback binding. > > Signed-off-by: Bruno Thomsen > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 5/8] lib: rsa: free local arrays after use in rsa_gen_key_prop()
On Thu, Jun 18, 2020 at 04:23:25PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > n, rr and rrtmp are used for internal calculations, but in the end > the results are copied into separately allocated elements of the > actual key_prop, so the n, rr and rrtmp elements are not used anymore > when returning from the function and should of course be freed. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] tpm: add TPM2_GetRandom command support
On Thu, Jun 04, 2020 at 04:43:59PM -0700, Dhananjay Phadke wrote: > Add support for TPM2 GetRandom command > > Signed-off-by: Dhananjay Phadke > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 3/8] lib: rsa: bring exp_len in line when generating a key_prop
On Thu, Jun 18, 2020 at 04:23:23PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > The exponent field of struct key_prop gets allocated an uint64_t, > and the contents are positioned from the back, so an exponent of > "0x01 0x00 0x01" becomes 0x0 0x0 0x0 0x0 0x0 0x1 0x0 0x1" > > Right now rsa_gen_key_prop() allocates a uint64_t but sets exp_len > to the size returned from the parser, while on the other hand the > when getting the key from the devicetree exp_len always gets set to > sizeof(uint64_t). > > So bring that in line with the established code. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 5/6] command: Drop #ifdef for MEM_SUPPORT_64BIT_DATA
On Tue, Jun 02, 2020 at 07:26:48PM -0600, Simon Glass wrote: > This is defined only when __lp64__ is defined. That means that ulong is > 64 bits long. Therefore we don't need to use a separate u64 type on those > architectures. > > Fix up the code to take advantage of that, removing the preprocessor > conditions. > > Also include the header file that defines MEM_SUPPORT_64BIT_DATA. It is > included by env.h in this file, but that might not last forever. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 6/6] cmd: Add a memory-search command
On Tue, Jun 02, 2020 at 07:26:49PM -0600, Simon Glass wrote: > It is useful to be able to find hex values and strings in a memory range. > Add a command to support this. > > cmd: Fix 'md' and add a memory-search command > At present 'md.q' is broken. This series provides a fix for this. It also > implements a new memory-search command called 'ms'. It allows searching > memory for hex and string data. > END > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/6] display_options: Drop #ifdef for MEM_SUPPORT_64BIT_DATA
On Tue, Jun 02, 2020 at 07:26:47PM -0600, Simon Glass wrote:
> This is defined only when __lp64__ is defined. That means that ulong is
> 64 bits long. Therefore we don't need to use a separate u64 type on those
> architectures.
>
> Fix up the code to take advantage of that, removing the preprocessor
> conditions.
>
> Also include the missing header file that defines MEM_SUPPORT_64BIT_DATA
>
> Fixes: 09140113108 ("command: Remove the cmd_tbl_t typedef")
> Signed-off-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] sata_sil: make it buildable with DM_PCI
On Thu, Jun 04, 2020 at 01:29:22PM +0200, Marcin Juszkiewicz wrote: > Linker complained about lack of `pci_virt_to_mem` function. > Looks like driver was not ready for device model - I took solution from > e1000.c driver. > > Signed-off-by: Marcin Juszkiewicz Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/6] cmd: mem: Drop #ifdef for MEM_SUPPORT_64BIT_DATA
On Tue, Jun 02, 2020 at 07:26:46PM -0600, Simon Glass wrote: > This is defined only when __lp64__ is defined. That means that ulong is > 64 bits long. Therefore we don't need to use a separate u64 type on those > architectures. > > Fix up the code to take advantage of that, removing the preprocessor > conditions. > > Signed-off-by: Simon Glass > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/4] spl: fit: improve spl_nand_fit_read(...) readability
On Wed, May 27, 2020 at 01:56:21PM +0200, Dario Binacchi wrote: > Replacing the ret variable with err and handling first the error > condition about the value returned by the spl_nand_fit_read routine, > improves the code readability. > Furthermore, the 'else' int the 'else return ret' instruction was > useless. > > cc: Michael Trimarchi > Signed-off-by: Dario Binacchi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 3/4] spl: fit: nand: fix fit loading in case of bad blocks
On Wed, May 27, 2020 at 01:56:20PM +0200, Dario Binacchi wrote: > The offset at which the image to be loaded from NAND is located is > retrieved from the itb header. The presence of bad blocks in the area > of the NAND where the itb image is located could invalidate the offset > which must therefore be adjusted taking into account the state of the > sectors concerned. > > cc: Michael Trimarchi > Signed-off-by: Dario Binacchi > Reviewed-by: Michael Trimarchi Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/4] spl: fit: fail fit loading in case of FDT appending error
On Wed, May 27, 2020 at 01:56:19PM +0200, Dario Binacchi wrote: > If uboot does not embed its device tree and the FIT loading function > returns error in case of failure in the FDT append, the redundant itb > image could be loaded. > > cc: Michael Trimarchi > Signed-off-by: Dario Binacchi > Reviewed-by: Michael Trimarchi > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/6] cmd: mem: Use a macro to avoid #ifdef in help
On Tue, Jun 02, 2020 at 07:26:45PM -0600, Simon Glass wrote: > It is a bit painful to have #ifdefs in the middle of the help for each > command. Add a macro to avoid this. > > Signed-off-by: Simon Glass > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/6] Update MEM_SUPPORT_64BIT_DATA to be always defined
On Tue, Jun 02, 2020 at 07:26:44PM -0600, Simon Glass wrote: > Define this macro always so we don't need the preprocessor to check it. > Convert the users to #if instead of #ifdef. > > Note that '#if MEM_SUPPORT_64BIT_DATA' does not give an error if the > macro is not define. It just assumes zero. > > Signed-off-by: Simon Glass > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] debug_uart: Add CR before and after announce string
On Fri, May 15, 2020 at 07:09:03AM +0200, Stefan Roese wrote: > Add linefeeds before and after the announce string. This makes the > output easier to read, especially if some text follows the announce > message without a specific additional CR. > > Signed-off-by: Stefan Roese > Reviewed-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/4] spl: fix format of function documentation
On Wed, May 27, 2020 at 01:56:18PM +0200, Dario Binacchi wrote: > U-Boot adopted the kernel-doc annotation style. > > cc: Michael Trimarchi > Signed-off-by: Dario Binacchi > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: rsa: function to verify a signature against a hash
On Fri, May 22, 2020 at 04:20:33PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > rsa_verify() expects a memory region and wants to do the hashing itself, > but there may be cases where the hashing is done via other means, > like hashing a squashfs rootfs. > > So add rsa_verify_hash() to allow verifiying a signature against > an existing hash. As this entails the same verification routines > we can just move the relevant code over from rsa_verify() and also > call rsa_verify_hash() from there. > > Signed-off-by: Heiko Stuebner Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bugfix: tpm2_tis_spi: redeclaration compile error
On Mon, Jul 06, 2020 at 05:32:27PM +0200, Bruno Thomsen wrote: > tpm2_tis_spi driver fails to compile with errors like this: > > drivers/tpm/tpm_tis.h:117:2: error: redeclaration of enumerator > 'TPM_ACCESS_VALID' > drivers/tpm/tpm_tis.h:118:2: error: redeclaration of enumerator > 'TPM_ACCESS_ACTIVE_LOCALITY' > drivers/tpm/tpm_tis.h:119:2: error: redeclaration of enumerator > 'TPM_ACCESS_REQUEST_PENDING' > drivers/tpm/tpm_tis.h:120:2: error: redeclaration of enumerator > 'TPM_ACCESS_REQUEST_USE' > drivers/tpm/tpm_tis.h:124:2: error: redeclaration of enumerator > 'TPM_STS_VALID' > drivers/tpm/tpm_tis.h:125:2: error: redeclaration of enumerator > 'TPM_STS_COMMAND_READY' > drivers/tpm/tpm_tis.h:126:2: error: redeclaration of enumerator 'TPM_STS_GO' > drivers/tpm/tpm_tis.h:127:2: error: redeclaration of enumerator > 'TPM_STS_DATA_AVAIL' > drivers/tpm/tpm_tis.h:128:2: error: redeclaration of enumerator > 'TPM_STS_DATA_EXPECT' > > This is due to redeclaration of 9 values in tis_access and tis_status enums > from tpm_tis.h. Defines are now declared in include/tpm-v2.h, so removing > duplicates from tpm_tis.h. > > Signed-off-by: Bruno Thomsen > --- > drivers/tpm/tpm_tis.h | 15 --- > 1 file changed, 15 deletions(-) Doing it this way however breaks tpm1 support. I've taken a different patch for this issue, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] tpm: add #ifndef to fix redeclaration build errors
On Mon, May 11, 2020 at 03:22:25PM +0200, Johannes Holland wrote: > tpm_tis_spi.c directly includes tpm_tis.h and tpm-v2.h which both > define the same enums (see e.g. TPM_ACCESS_VALID). Add an #ifndef to > prevent redeclaration errors. > > Signed-off-by: Johannes Holland Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/2] configs: rock64-rk3328_defconfig: Add SPI Flash support
Add U-Boot SPI Flash support for the PINE64 Rock64 board Signed-off-by: Johannes Krottmayer Cc: Matwey V. Kornilov --- configs/rock64-rk3328_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index f123826358..0a51e51a0c 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -97,3 +97,5 @@ CONFIG_SPL_TINY_MEMSET=y CONFIG_TPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y CONFIG_SMBIOS_MANUFACTURER="pine64" +CONFIG_ROCKCHIP_SPI=y +CONFIG_SPI_FLASH_GIGADEVICE=y -- 2.26.2
[PATCH 1/2] ARM: dts: rk3328-rock64: Add SPI Flash support
Add U-Boot SPI Flash support for the PINE64 Rock64 board
Signed-off-by: Johannes Krottmayer
Cc: Matwey V. Kornilov
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index f076075076..7340ef95f1 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -46,3 +46,9 @@
_sd {
u-boot,dm-spl;
};
+
+ {
+ spi_flash: spiflash@0 {
+ u-boot,dm-pre-reloc;
+ };
+};
--
2.26.2
[PATCH 0/2] PINE64 Rock64 board: Add SPI Flash support
This patch series adds SPI Flash support for the PINE64 Rock64 board. Tested with the version 2.0 of the board. Johannes Krottmayer (2): ARM: dts: rk3328-rock64: Add SPI Flash support configs: rock64-rk3328_defconfig: Add SPI Flash support arch/arm/dts/rk3328-rock64-u-boot.dtsi | 6 ++ configs/rock64-rk3328_defconfig| 2 ++ 2 files changed, 8 insertions(+) -- 2.26.2
Re: [PATCH 1/2] vboot: add support for multiple required keys
Hi Simon, Thanks a lot for reviewing the patch. I would appreciate if you could clarify the following in-line questions: On 6/29/2020 10:31 AM, Simon Glass wrote: > Hi Thirupathaiah, > > > On Mon, 29 Jun 2020 at 11:26, Simon Glass wrote: >> >> Hi Thirupathaiah, >> >> On Thu, 25 Jun 2020 at 09:51, Thirupathaiah Annapureddy >> wrote: >>> >>> Currently Verified Boot fails if there is a signature verification failure >>> using required key in U-boot DTB. This patch adds support for multiple >>> required keys. This means if verified boot passes with one of the required >>> keys, u-boot will continue the OS hand off. >>> >>> There was a prior attempt to resolve this with the following patch: >>> https://lists.denx.de/pipermail/u-boot/2019-April/366047.html >>> The above patch was failing "make tests". >>> >>> Signed-off-by: Thirupathaiah Annapureddy >>> --- >>> common/image-fit-sig.c | 12 +++- >>> 1 file changed, 11 insertions(+), 1 deletion(-) > > One more thing...this patch is changing the policy. I assume you are referring to the policy of conf signing with all required keys instead of just one. I just wanted to double check. However I did not see any test in test_vboot.py for verifying this policy. So I thought signing with all required keys is not by design and it is an unintended bug. Could you please clarify on this? > > I think we need a new string property in the DTB alongside the > 'required' properly, that indicates whether the image must be signed > with all required keys, or just one. > > Regards, > Simon > Best Regards, Thiru
Re: [PATCH] fixdep: fix CONFIG_IS_ENABLED etc. handling
On Wed, 8 Jul 2020 at 15:46, Stephen Warren wrote:
>
> From: Stephen Warren
>
> When fixdep detects CONFIG_IS_ENABLED and other similar macros, it must
> parse the macro parameter to determine which actual CONFIG_ option is
> being referenced. This involves moving a pointer forward through the
> entire CONFIG_ option "word". Currently, the code uses variable q to walk
> through the word, but doesn't actually initialize it to point at the
> parameter before doing so. Consequently, the walking process immediately
> fails since it sees the macro invocatoins's ( rather than the expected
> alpha-numeric characters in the macro parameter. Fix this by adding the
> missing initialization.
>
> Fixes: 67f2ee86ccbe ("kbuild: fixdep: Resync this with v4.17")
> Fixes: 7012865e961c ("gpio: fix test.py for gpio label lookup")
> Signed-off-by: Stephen Warren
> ---
> scripts/basic/fixdep.c | 1 +
> 1 file changed, 1 insertion(+)
I'm really not sure how you found that needle.
Reviewed-by: Simon Glass
Oddly enough I cannot repeat the problems I was having last week after
a quick try, but this definitely looks like the culprit to me.
Re: [PATCH 08/12] poweroff: Add poweroff-gpio driver
Hi Sebastian, On Wed, 1 Jul 2020 at 11:27, Sebastian Reichel wrote: > > Add GPIO poweroff driver, which is based on the Linux > driver and uses the same DT binding. > > Signed-off-by: Sebastian Reichel > --- > drivers/power/Kconfig | 8 > drivers/power/Makefile| 1 + > drivers/power/poweroff-gpio.c | 87 +++ > 3 files changed, 96 insertions(+) > create mode 100644 drivers/power/poweroff-gpio.c Can you use the SYSRESET uclass instead of creating a new one? Regards, SImon
Re: [PATCH 08/12] poweroff: Add poweroff-gpio driver
On 7/2/20 2:26 AM, Sebastian Reichel wrote:
> Add GPIO poweroff driver, which is based on the Linux
> driver and uses the same DT binding.
>
> Signed-off-by: Sebastian Reichel
> ---
> drivers/power/Kconfig | 8
> drivers/power/Makefile| 1 +
> drivers/power/poweroff-gpio.c | 87 +++
> 3 files changed, 96 insertions(+)
> create mode 100644 drivers/power/poweroff-gpio.c
>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 5a76e23b5fb0..d1eaa0895ddd 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -382,4 +382,12 @@ config POWEROFF
> provide access to board-specific implementations. Using device
> tree for configuration is recommended.
>
> +config POWEROFF_GPIO
> + bool "GPIO power-off driver"
> + depends on POWEROFF
> + help
> + This driver supports turning off your board via a GPIO line.
> + If your board needs a GPIO high/low to power down, say Y and
> + create a binding in your devicetree.
> +
> endmenu
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 924e99114ccd..34a2c2c48195 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -23,3 +23,4 @@ obj-$(CONFIG_POWER_SPI) += power_spi.o
> obj-$(CONFIG_POWER_MT6323) += mt6323.o
>
> obj-$(CONFIG_POWEROFF) += poweroff-uclass.o
> +obj-$(CONFIG_POWEROFF_GPIO) += poweroff-gpio.o
> diff --git a/drivers/power/poweroff-gpio.c b/drivers/power/poweroff-gpio.c
> new file mode 100644
> index ..cf2bdab9e551
> --- /dev/null
> +++ b/drivers/power/poweroff-gpio.c
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Toggles a GPIO pin to power down a device
> + *
> + * Created using the Linux driver as reference, which
> + * has been written by:
> + *
> + * Jamie Lentin
> + * Andrew Lunn
> + *
> + * Copyright (C) 2012 Jamie Lentin
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct poweroff_gpio_info {
> + struct gpio_desc gpio;
> + u32 active_delay;
> + u32 inactive_delay;
> + u32 timeout;
> +};
> +
> +static int poweroff_gpio_do_poweroff(struct udevice *dev)
> +{
> + struct poweroff_gpio_info *priv = dev_get_priv(dev);
> +
> + /* drive it active, also inactive->active edge */
> + dm_gpio_set_value(>gpio, 1);
> + mdelay(priv->active_delay);
> +
> + /* drive inactive, also active->inactive edge */
> + dm_gpio_set_value(>gpio, 0);
> + mdelay(priv->inactive_delay);
> +
> + /* drive it active, also inactive->active edge */
> + dm_gpio_set_value(>gpio, 1);
> +
> + /* give it some time */
> + mdelay(priv->timeout);
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int poweroff_gpio_probe(struct udevice *dev)
> +{
> + struct poweroff_gpio_info *priv = dev_get_priv(dev);
> + int flags;
> +
> + if (dev_read_bool(dev, "input"))
> + flags = GPIOD_IS_IN;
> + else
> + flags = GPIOD_IS_OUT;
> +
> + priv->active_delay = 100;
> + dev_read_u32(dev, "active-delay-ms", >active_delay);
How about using dev_read_u32_default() instead of dev_read_u32()?
priv->activate_delay = dev_read_u32_default(dev, "active-delay-ms", 100);
> +
> + priv->inactive_delay = 100;
> + dev_read_u32(dev, "inactive-delay-ms", >inactive_delay);
ditto
> +
> + priv->timeout = 3000;
> + dev_read_u32(dev, "timeout-ms", >timeout);
ditto
Best Regards,
Jaehoon Chung
> +
> + return gpio_request_by_name(dev, "gpios", 0, >gpio, flags);
> +}
> +
> +static const struct poweroff_ops poweroff_gpio_ops = {
> + .poweroff = poweroff_gpio_do_poweroff,
> +};
> +
> +static const struct udevice_id poweroff_gpio_ids[] = {
> + { .compatible = "gpio-poweroff", },
> + {},
> +};
> +
> +U_BOOT_DRIVER(poweroff_gpio) = {
> + .name = "poweroff-gpio",
> + .id = UCLASS_POWEROFF,
> + .ops= _gpio_ops,
> + .probe = poweroff_gpio_probe,
> + .priv_auto_alloc_size = sizeof(struct poweroff_gpio_info),
> + .of_match = poweroff_gpio_ids,
> +};
>
[PATCH 1/3] drivers: clk: rockchip: clk_rk3328: Add SPI support
Add SPI support for the RK3328 clock driver
Signed-off-by: Johannes Krottmayer
Cc: Kever Yang
Cc: Jagan Teki
---
drivers/clk/rockchip/clk_rk3328.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/clk/rockchip/clk_rk3328.c
b/drivers/clk/rockchip/clk_rk3328.c
index 02d3b08efa..bf4f1069ea 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -555,6 +555,31 @@ static ulong rk3328_saradc_set_clk(struct rk3328_cru *cru,
uint hz)
return rk3328_saradc_get_clk(cru);
}
+static ulong rk3328_spi_get_clk(struct rk3328_cru *cru)
+{
+ u32 div, val;
+
+ val = readl(>clksel_con[24]);
+ div = (val & CLK_SPI_DIV_CON_MASK) >> CLK_SPI_DIV_CON_SHIFT;
+
+ return DIV_TO_RATE(OSC_HZ, div);
+}
+
+static ulong rk3328_spi_set_clk(struct rk3328_cru *cru, uint hz)
+{
+ u32 src_clk_div;
+
+ src_clk_div = GPLL_HZ / hz;
+ assert(src_clk_div < 128);
+
+ rk_clrsetreg(>clksel_con[24],
+CLK_PWM_PLL_SEL_MASK | CLK_PWM_DIV_CON_MASK,
+CLK_PWM_PLL_SEL_GPLL << CLK_PWM_PLL_SEL_SHIFT |
+(src_clk_div - 1) << CLK_PWM_DIV_CON_SHIFT);
+
+ return rk3328_spi_get_clk(cru);
+}
+
static ulong rk3328_clk_get_rate(struct clk *clk)
{
struct rk3328_clk_priv *priv = dev_get_priv(clk->dev);
@@ -581,6 +606,9 @@ static ulong rk3328_clk_get_rate(struct clk *clk)
case SCLK_SARADC:
rate = rk3328_saradc_get_clk(priv->cru);
break;
+ case SCLK_SPI:
+ rate = rk3328_spi_get_clk(priv->cru);
+ break;
default:
return -ENOENT;
}
@@ -617,6 +645,9 @@ static ulong rk3328_clk_set_rate(struct clk *clk, ulong
rate)
case SCLK_SARADC:
ret = rk3328_saradc_set_clk(priv->cru, rate);
break;
+ case SCLK_SPI:
+ ret = rk3328_spi_set_clk(priv->cru, rate);
+ break;
case DCLK_LCDC:
case SCLK_PDM:
case SCLK_RTC32K:
--
2.26.2
[PATCH 3/3] ARM: dts: rk3328: Add SPI support
Add U-Boot SPI support for the RK3328
Signed-off-by: Johannes Krottmayer
Cc: Kever Yang
Cc: Jagan Teki
---
arch/arm/dts/rk3328-u-boot.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index c69e13e11e..c980daae99 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -7,6 +7,7 @@
aliases {
mmc0 =
mmc1 =
+ spi0 =
};
chosen {
@@ -66,3 +67,7 @@
_otg {
hnp-srp-disable;
};
+
+ {
+ u-boot,dm-pre-reloc;
+};
--
2.26.2
[PATCH 0/3] rockchip: rk3328: Add SPI support
This patch series adds support for the RK3328 SPI controller. Johannes Krottmayer (3): drivers: clk: rockchip: clk_rk3328: Add SPI support drivers: spi: rk_spi: Add support for RK3328 ARM: dts: rk3328: Add SPI support arch/arm/dts/rk3328-u-boot.dtsi | 5 + drivers/clk/rockchip/clk_rk3328.c | 31 +++ drivers/spi/rk_spi.c | 2 ++ 3 files changed, 38 insertions(+) -- 2.26.2
[PATCH 2/3] drivers: spi: rk_spi: Add support for RK3328
Add support for the RK3328 SPI controller
Signed-off-by: Johannes Krottmayer
Cc: Kever Yang
Cc: Jagan Teki
---
I don't know if "rk3399_spi_params" is also required for the
RK3328 SPI controller.
Probing, Reading, Writing and Erasing of a flash device works
with the SF command. Tested it with the PINE64 Rock64 board.
drivers/spi/rk_spi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
index 833cb04922..0495e04945 100644
--- a/drivers/spi/rk_spi.c
+++ b/drivers/spi/rk_spi.c
@@ -545,7 +545,9 @@ const struct rockchip_spi_params rk3399_spi_params = {
};
static const struct udevice_id rockchip_spi_ids[] = {
+ { .compatible = "rockchip,rk3066-spi" },
{ .compatible = "rockchip,rk3288-spi" },
+ { .compatible = "rockchip,rk3328-spi" },
{ .compatible = "rockchip,rk3368-spi",
.data = (ulong)_spi_params },
{ .compatible = "rockchip,rk3399-spi",
--
2.26.2
[PATCH] fixdep: fix CONFIG_IS_ENABLED etc. handling
From: Stephen Warren
When fixdep detects CONFIG_IS_ENABLED and other similar macros, it must
parse the macro parameter to determine which actual CONFIG_ option is
being referenced. This involves moving a pointer forward through the
entire CONFIG_ option "word". Currently, the code uses variable q to walk
through the word, but doesn't actually initialize it to point at the
parameter before doing so. Consequently, the walking process immediately
fails since it sees the macro invocatoins's ( rather than the expected
alpha-numeric characters in the macro parameter. Fix this by adding the
missing initialization.
Fixes: 67f2ee86ccbe ("kbuild: fixdep: Resync this with v4.17")
Fixes: 7012865e961c ("gpio: fix test.py for gpio label lookup")
Signed-off-by: Stephen Warren
---
scripts/basic/fixdep.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/scripts/basic/fixdep.c b/scripts/basic/fixdep.c
index 24be244d5e6a..958668df5546 100644
--- a/scripts/basic/fixdep.c
+++ b/scripts/basic/fixdep.c
@@ -266,6 +266,7 @@ static void parse_config_file(const char *p)
(q - p == 9 && !memcmp(p, "IS_MODULE(", 10)) ||
(q - p == 3 && !memcmp(p, "VAL(", 4))) {
p = q + 1;
+ q = p;
while (isalnum(*q) || *q == '_')
q++;
r = q;
--
2.25.1
Re: test/py GPIO failure in u-boot/master
On 7/8/20 2:24 PM, Stephen Warren wrote:
> On 7/8/20 10:06 AM, Tom Rini wrote:
>> On Wed, Jul 08, 2020 at 09:50:06AM -0600, Stephen Warren wrote:
>>> Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
>>>
=> ut dm gpio
Test: dm_test_gpio: gpio.c
extra-gpios: get_value: error: gpio b5 not reserved
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
Test: dm_test_gpio: gpio.c (flat tree)
extra-gpios: get_value: error: gpio b5 not reserved
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
Failures: 2
>>>
>>>
=> ut dm gpio_leak
Test: dm_test_gpio_leak: gpio.c
extra-gpios: get_value: error: gpio b5 not reserved
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
(1)
Test: dm_test_gpio_leak: gpio.c (flat tree)
extra-gpios: get_value: error: gpio b5 not reserved
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
/var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
(1)
Failures: 4
>>>
>>> This was introduced by one of the following changes; I'd assume due to
>>> the GPIO patch:
>>>
cmd: part: Add subcommand to list supported partition tables (detail)
cmd: fs: Add command to list supported fs types (detail)
cmd: dm: Fixed/Added DM driver listing subcommands (detail)
cmd: blkls: Add blkls command (detail)
image: Add support for ZSTD decompression (detail)
Actions: OWL: Calculate SDRAM size (detail)
arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs
(detail)
clk: actions: Add Ethernet clocks (detail)
net: phy: realtek: Add support for RTL8201F PHY module. (detail)
net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust
(detail)
net: designware: s700: Add glue code for S700 mac (detail)
arm: dts: s700: add node for ethernet controller (detail)
owl: Kconfig: Enable DM eth for OWL platform (detail)
configs: Enable mac and phy configs (detail)
gpio: search for gpio label if gpio is not found through bank name (detail)
test_sleep.py: make sleep time and margin configurable (detail)
fs: fat_write: fix short name creation. (detail)
trace: clang compatible handling of gd register (detail)
arm: remove outdated comment concerning -ffixed-x18 (detail)
arm: use correct argument size of special registers (detail)
arm: vexpress64: Fix counter frequency (detail)
net: dm: Remove warning about EEPROM provided MAC address (detail)
net: smc911x: Properly handle EEPROM MAC address (detail)
arm: juno: Enable DM_ETH (detail)
sata_sil: Enable DM_PCI operation (detail)
arm: juno: Enable PCI (detail)
arm: juno: Enable SATA controller (detail)
>>>
>>> I see what was probably an attempt to fix this:
>>>
commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
Author: Heiko Schocher
Date: Wed Jul 8 10:24:00 2020 +0200
gpio: fix test.py for gpio label lookup
>>>
>>> ... but the tests are still failing after that. Did that patch edit the
>>> wrong defconfig, or is there an incremental build issue that prevented
>>> that patch being effective?
>>
>> The tests are passing here and in GitLab again, so I'm not sure what's
>> happening on your end.
>
> Hmm. There is some kind of incremental build issue. I repro'd on a
> different system with a different OS, so it's not isolated to the system
> that I use to run Jenkins:
>
> # Ensure clean build
> git clean -fdx
>
> # Check out the last commit before the fix
> git checkout 526fe06a5d1d96ce22cca743576945016ec4e2ef
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests fail here due to the original GPIO issue
>
> # Check out the fix for the GPIO issue
> git checkout 7012865e961ca2645d783adf4b75ca4abdbfe5a7
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests still fail!
>
> # Ensure clean build
> rm -rf build-sandbox/
> ./test/py/test.py --bd sandbox --build -k
Re: test/py GPIO failure in u-boot/master
Hi,
On Wed, 8 Jul 2020 at 14:24, Stephen Warren wrote:
>
> On 7/8/20 10:06 AM, Tom Rini wrote:
> > On Wed, Jul 08, 2020 at 09:50:06AM -0600, Stephen Warren wrote:
> >> Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
> >>
> >>> => ut dm gpio
> >>> Test: dm_test_gpio: gpio.c
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> >>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> >>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> >>> Test: dm_test_gpio: gpio.c (flat tree)
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> >>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> >>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> >>> Failures: 2
> >>
> >>
> >>> => ut dm gpio_leak
> >>> Test: dm_test_gpio_leak: gpio.c
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> >>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> >>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
> >>> dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
> >>> (1)
> >>> Test: dm_test_gpio_leak: gpio.c (flat tree)
> >>> extra-gpios: get_value: error: gpio b5 not reserved
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> >>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> >>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> >>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
> >>> dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
> >>> (1)
> >>> Failures: 4
> >>
> >> This was introduced by one of the following changes; I'd assume due to
> >> the GPIO patch:
> >>
> >>> cmd: part: Add subcommand to list supported partition tables (detail)
> >>> cmd: fs: Add command to list supported fs types (detail)
> >>> cmd: dm: Fixed/Added DM driver listing subcommands (detail)
> >>> cmd: blkls: Add blkls command (detail)
> >>> image: Add support for ZSTD decompression (detail)
> >>> Actions: OWL: Calculate SDRAM size (detail)
> >>> arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs
> >>> (detail)
> >>> clk: actions: Add Ethernet clocks (detail)
> >>> net: phy: realtek: Add support for RTL8201F PHY module. (detail)
> >>> net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust
> >>> (detail)
> >>> net: designware: s700: Add glue code for S700 mac (detail)
> >>> arm: dts: s700: add node for ethernet controller (detail)
> >>> owl: Kconfig: Enable DM eth for OWL platform (detail)
> >>> configs: Enable mac and phy configs (detail)
> >>> gpio: search for gpio label if gpio is not found through bank name
> >>> (detail)
> >>> test_sleep.py: make sleep time and margin configurable (detail)
> >>> fs: fat_write: fix short name creation. (detail)
> >>> trace: clang compatible handling of gd register (detail)
> >>> arm: remove outdated comment concerning -ffixed-x18 (detail)
> >>> arm: use correct argument size of special registers (detail)
> >>> arm: vexpress64: Fix counter frequency (detail)
> >>> net: dm: Remove warning about EEPROM provided MAC address (detail)
> >>> net: smc911x: Properly handle EEPROM MAC address (detail)
> >>> arm: juno: Enable DM_ETH (detail)
> >>> sata_sil: Enable DM_PCI operation (detail)
> >>> arm: juno: Enable PCI (detail)
> >>> arm: juno: Enable SATA controller (detail)
> >>
> >> I see what was probably an attempt to fix this:
> >>
> >>> commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
> >>> Author: Heiko Schocher
> >>> Date: Wed Jul 8 10:24:00 2020 +0200
> >>>
> >>> gpio: fix test.py for gpio label lookup
> >>
> >> ... but the tests are still failing after that. Did that patch edit the
> >> wrong defconfig, or is there an incremental build issue that prevented
> >> that patch being effective?
> >
> > The tests are passing here and in GitLab again, so I'm not sure what's
> > happening on your end.
>
> Hmm. There is some kind of incremental build issue. I repro'd on a
> different system with a different OS, so it's not isolated to the system
> that I use to run Jenkins:
>
> # Ensure clean build
> git clean -fdx
>
> # Check out the last commit before the fix
> git checkout 526fe06a5d1d96ce22cca743576945016ec4e2ef
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests fail here due to the original GPIO issue
>
> # Check out the fix for the GPIO issue
> git checkout 7012865e961ca2645d783adf4b75ca4abdbfe5a7
> ./test/py/test.py --bd sandbox --build -k test_ut
> # Tests still
Re: test/py GPIO failure in u-boot/master
On 7/8/20 10:06 AM, Tom Rini wrote:
> On Wed, Jul 08, 2020 at 09:50:06AM -0600, Stephen Warren wrote:
>> Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
>>
>>> => ut dm gpio
>>> Test: dm_test_gpio: gpio.c
>>> extra-gpios: get_value: error: gpio b5 not reserved
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
>>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
>>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
>>> Test: dm_test_gpio: gpio.c (flat tree)
>>> extra-gpios: get_value: error: gpio b5 not reserved
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
>>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
>>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
>>> Failures: 2
>>
>>
>>> => ut dm gpio_leak
>>> Test: dm_test_gpio_leak: gpio.c
>>> extra-gpios: get_value: error: gpio b5 not reserved
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
>>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
>>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
>>> dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
>>> (1)
>>> Test: dm_test_gpio_leak: gpio.c (flat tree)
>>> extra-gpios: get_value: error: gpio b5 not reserved
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
>>> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
>>> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
>>> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
>>> dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
>>> (1)
>>> Failures: 4
>>
>> This was introduced by one of the following changes; I'd assume due to
>> the GPIO patch:
>>
>>> cmd: part: Add subcommand to list supported partition tables (detail)
>>> cmd: fs: Add command to list supported fs types (detail)
>>> cmd: dm: Fixed/Added DM driver listing subcommands (detail)
>>> cmd: blkls: Add blkls command (detail)
>>> image: Add support for ZSTD decompression (detail)
>>> Actions: OWL: Calculate SDRAM size (detail)
>>> arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs
>>> (detail)
>>> clk: actions: Add Ethernet clocks (detail)
>>> net: phy: realtek: Add support for RTL8201F PHY module. (detail)
>>> net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust
>>> (detail)
>>> net: designware: s700: Add glue code for S700 mac (detail)
>>> arm: dts: s700: add node for ethernet controller (detail)
>>> owl: Kconfig: Enable DM eth for OWL platform (detail)
>>> configs: Enable mac and phy configs (detail)
>>> gpio: search for gpio label if gpio is not found through bank name (detail)
>>> test_sleep.py: make sleep time and margin configurable (detail)
>>> fs: fat_write: fix short name creation. (detail)
>>> trace: clang compatible handling of gd register (detail)
>>> arm: remove outdated comment concerning -ffixed-x18 (detail)
>>> arm: use correct argument size of special registers (detail)
>>> arm: vexpress64: Fix counter frequency (detail)
>>> net: dm: Remove warning about EEPROM provided MAC address (detail)
>>> net: smc911x: Properly handle EEPROM MAC address (detail)
>>> arm: juno: Enable DM_ETH (detail)
>>> sata_sil: Enable DM_PCI operation (detail)
>>> arm: juno: Enable PCI (detail)
>>> arm: juno: Enable SATA controller (detail)
>>
>> I see what was probably an attempt to fix this:
>>
>>> commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
>>> Author: Heiko Schocher
>>> Date: Wed Jul 8 10:24:00 2020 +0200
>>>
>>> gpio: fix test.py for gpio label lookup
>>
>> ... but the tests are still failing after that. Did that patch edit the
>> wrong defconfig, or is there an incremental build issue that prevented
>> that patch being effective?
>
> The tests are passing here and in GitLab again, so I'm not sure what's
> happening on your end.
Hmm. There is some kind of incremental build issue. I repro'd on a
different system with a different OS, so it's not isolated to the system
that I use to run Jenkins:
# Ensure clean build
git clean -fdx
# Check out the last commit before the fix
git checkout 526fe06a5d1d96ce22cca743576945016ec4e2ef
./test/py/test.py --bd sandbox --build -k test_ut
# Tests fail here due to the original GPIO issue
# Check out the fix for the GPIO issue
git checkout 7012865e961ca2645d783adf4b75ca4abdbfe5a7
./test/py/test.py --bd sandbox --build -k test_ut
# Tests still fail!
# Ensure clean build
rm -rf build-sandbox/
./test/py/test.py --bd sandbox --build -k test_ut
# Tests now pass due to clean build
Masahiro, do you have any ideas?
[PATCH v5] ARM: dts: stm32: add seeed studio odyssey-stm32mp157c board
This commit adds device tree files supporting
SBC from Seeed Studio based on STM32MP157C.
This works with generic stm32mp1 config.
Right now only booting from SD card is supported.
Signed-off-by: Marcin Sloniewski
---
Changes in v5:
- removed description of PLL1 which is now handled by OPP info
- removed cd-gpio for sdmmc1 since it is not yet supported
Changes in v4:
- removed unnecessary pull up on uart4 rx
Changes in v3:
- changed name of dts files from odyssey-stm32mp157c...
to stm32mp157c-odyssey...
- removed usbotg node config
- add new board in dts/Makefile in alphabetical order
Changes in v2:
- removed `st,adc_usb_pd` from config since that
adc connection is non-existent which caused
warning or hang during boot
arch/arm/dts/Makefile | 1 +
.../dts/stm32mp157c-odyssey-som-u-boot.dtsi | 125 ++
arch/arm/dts/stm32mp157c-odyssey-som.dtsi | 364 ++
arch/arm/dts/stm32mp157c-odyssey-u-boot.dtsi | 58 +++
arch/arm/dts/stm32mp157c-odyssey.dts | 161
5 files changed, 709 insertions(+)
create mode 100644 arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
create mode 100644 arch/arm/dts/stm32mp157c-odyssey-som.dtsi
create mode 100644 arch/arm/dts/stm32mp157c-odyssey-u-boot.dtsi
create mode 100644 arch/arm/dts/stm32mp157c-odyssey.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d345e30f35..d9629aba7d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -931,6 +931,7 @@ dtb-$(CONFIG_STM32MP15x) += \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb \
+ stm32mp157c-odyssey.dtb \
stm32mp15xx-dhcom-pdk2.dtb \
stm32mp15xx-dhcor-avenger96.dtb
diff --git a/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
new file mode 100644
index 00..6be728846e
--- /dev/null
+++ b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2020 Marcin Sloniewski
+ */
+
+#include
+#include "stm32mp15-u-boot.dtsi"
+#include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
+
+/ {
+ config {
+ u-boot,boot-led = "heartbeat";
+ };
+};
+
+_hse {
+ st,digbypass;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_pins_a {
+ u-boot,dm-pre-reloc;
+ pins {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ st,clksrc = <
+ CLK_MPU_PLL1P
+ CLK_AXI_PLL2P
+ CLK_MCU_PLL3P
+ CLK_PLL12_HSE
+ CLK_PLL3_HSE
+ CLK_PLL4_HSE
+ CLK_RTC_LSE
+ CLK_MCO1_DISABLED
+ CLK_MCO2_DISABLED
+ >;
+
+ st,clkdiv = <
+ 1 /*MPU*/
+ 0 /*AXI*/
+ 0 /*MCU*/
+ 1 /*APB1*/
+ 1 /*APB2*/
+ 1 /*APB3*/
+ 1 /*APB4*/
+ 2 /*APB5*/
+ 23 /*RTC*/
+ 0 /*MCO1*/
+ 0 /*MCO2*/
+ >;
+
+ st,pkcs = <
+ CLK_CKPER_HSE
+ CLK_FMC_ACLK
+ CLK_QSPI_ACLK
+ CLK_ETH_DISABLED
+ CLK_SDMMC12_PLL4P
+ CLK_DSI_DSIPLL
+ CLK_STGEN_HSE
+ CLK_USBPHY_HSE
+ CLK_SPI2S1_PLL3Q
+ CLK_SPI2S23_PLL3Q
+ CLK_SPI45_HSI
+ CLK_SPI6_HSI
+ CLK_I2C46_HSI
+ CLK_SDMMC3_PLL4P
+ CLK_USBO_USBPHY
+ CLK_ADC_CKPER
+ CLK_CEC_LSE
+ CLK_I2C12_HSI
+ CLK_I2C35_HSI
+ CLK_UART1_HSI
+ CLK_UART24_HSI
+ CLK_UART35_HSI
+ CLK_UART6_HSI
+ CLK_UART78_HSI
+ CLK_SPDIF_PLL4P
+ CLK_FDCAN_PLL4R
+ CLK_SAI1_PLL3Q
+ CLK_SAI2_PLL3Q
+ CLK_SAI3_PLL3Q
+ CLK_SAI4_PLL3Q
+ CLK_RNG1_LSI
+ CLK_RNG2_LSI
+ CLK_LPTIM1_PCLK1
+ CLK_LPTIM23_PCLK3
+ CLK_LPTIM45_LSE
+ >;
+
+ /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
+ pll2: st,pll@1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
+ cfg = < 2 65 1 0 0 PQR(1,1,1) >;
+ frac = < 0x1400 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
+ pll3: st,pll@2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
+ cfg = < 1 33 1 16 36 PQR(1,1,1) >;
+ frac = < 0x1a04 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
+ pll4: st,pll@3 {
+ compatible = "st,stm32mp1-pll";
Re: [RFC PATCH 01/16] patman: Use test_util to show test results
On Tue, 2020-07-07 at 11:09 +1000, Daniel Axtens wrote: > Simon Glass writes: > > > Hi Daniel, > > > > On Sun, 5 Jul 2020 at 22:50, Daniel Axtens wrote: > > > Daniel Axtens writes: > > > > > > > Hi Simon, > > > > > > > > I can't see a cover letter so apologies if I've misunderstood something > > > > basic, but this doesn't appear to apply to the patchwork tree - I'm > > > > guessing the patchwork relevance is with regards to the last few patches > > > > that (AFAICT) parse the patchwork web interface for information? > > > > > > Ah, nevermind, the cover letter got caught in moderation. I've released > > > it. > > > > > > pwclient speaks the old, less documented XML-RPC API. We have a new > > > REST API which is much better documented, and is explorable > > > (e.g. https://patchwork.ozlabs.org/api/ and > > > https://patchwork.readthedocs.io/en/latest/api/rest/ ) > > > > > > > I haven't fully digested the patches (and I lack a lot of context) but > > > > is there a reason the patchwork API isn't able to meet your needs here? > > > > (And if so, could we extend it rather than having you parse the > > > > frontend?) > > > > > > So these questions still stand but for the REST API. > > > > So use the REST API instead of the web page? That sounds fine to me. > > Is it generally enabled on patchwork servers? > > I mean patman is your code so it's ultimately not my call :P But yes, > I'd strongly prefer you used the REST API! It is enabled on ozlabs.org > and kernel.org and has been for a while (~a couple of years). > > > What is the status of pwclient? Is it dead? Is there a replacement? > > I'd love to use a Python library if one exists. > > Stephen F is the expert on the client stuff, so I'm not going to make a > call on the status of pwclient. All I am confident to say is that I have > migrated to using 'git-pw' and I recommend others do so to too. pwclient is alive and won't be going anywhere, but it's still using the now-deprecated XML-RPC API. Eventually this will move to the REST API, but I just haven't found the time to do so yet. > I'm not sure if a dedicated Python client library exists: the last time > I wanted to write a Python client app I found it simple enough to just > use the JSON that the API provides directly. But the place I'd start > with is git-pw. There's no patchwork SDK yet and git-pw is intended for use as a tool rather than a library (the internal API isn't stable). However, the Patchwork API itself is very trivial so requests should get you what you want very easily. Stephen > Regards, > Daniel > > > Regards, > > SImon
[PATCH v6] ARM: dts: stm32: add seeed studio odyssey-stm32mp157c board
This commit adds device tree files supporting
SBC from Seeed Studio based on STM32MP157C.
This works with generic stm32mp1 config.
Right now only booting from SD card is supported.
Signed-off-by: Marcin Sloniewski
---
Changes in v6:
- forgot to add changes in v5 ;(
Changes in v5:
- removed description of PLL1 which is now handled by OPP info
- removed cd-gpio for sdmmc1 since it is not yet supported
Changes in v4:
- removed unnecessary pull up on uart4 rx
Changes in v3:
- changed name of dts files from odyssey-stm32mp157c...
to stm32mp157c-odyssey...
- removed usbotg node config
- add new board in dts/Makefile in alphabetical order
Changes in v2:
- removed `st,adc_usb_pd` from config since that
adc connection is non-existent which caused
warning or hang during boot
arch/arm/dts/Makefile | 1 +
.../dts/stm32mp157c-odyssey-som-u-boot.dtsi | 125 ++
arch/arm/dts/stm32mp157c-odyssey-som.dtsi | 364 ++
arch/arm/dts/stm32mp157c-odyssey-u-boot.dtsi | 58 +++
arch/arm/dts/stm32mp157c-odyssey.dts | 161
5 files changed, 709 insertions(+)
create mode 100644 arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
create mode 100644 arch/arm/dts/stm32mp157c-odyssey-som.dtsi
create mode 100644 arch/arm/dts/stm32mp157c-odyssey-u-boot.dtsi
create mode 100644 arch/arm/dts/stm32mp157c-odyssey.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d345e30f35..d9629aba7d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -931,6 +931,7 @@ dtb-$(CONFIG_STM32MP15x) += \
stm32mp157c-dk2.dtb \
stm32mp157c-ed1.dtb \
stm32mp157c-ev1.dtb \
+ stm32mp157c-odyssey.dtb \
stm32mp15xx-dhcom-pdk2.dtb \
stm32mp15xx-dhcor-avenger96.dtb
diff --git a/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
new file mode 100644
index 00..6be728846e
--- /dev/null
+++ b/arch/arm/dts/stm32mp157c-odyssey-som-u-boot.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2020 Marcin Sloniewski
+ */
+
+#include
+#include "stm32mp15-u-boot.dtsi"
+#include "stm32mp15-ddr3-1x4Gb-1066-binG.dtsi"
+
+/ {
+ config {
+ u-boot,boot-led = "heartbeat";
+ };
+};
+
+_hse {
+ st,digbypass;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_pins_a {
+ u-boot,dm-pre-reloc;
+ pins {
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ st,clksrc = <
+ CLK_MPU_PLL1P
+ CLK_AXI_PLL2P
+ CLK_MCU_PLL3P
+ CLK_PLL12_HSE
+ CLK_PLL3_HSE
+ CLK_PLL4_HSE
+ CLK_RTC_LSE
+ CLK_MCO1_DISABLED
+ CLK_MCO2_DISABLED
+ >;
+
+ st,clkdiv = <
+ 1 /*MPU*/
+ 0 /*AXI*/
+ 0 /*MCU*/
+ 1 /*APB1*/
+ 1 /*APB2*/
+ 1 /*APB3*/
+ 1 /*APB4*/
+ 2 /*APB5*/
+ 23 /*RTC*/
+ 0 /*MCO1*/
+ 0 /*MCO2*/
+ >;
+
+ st,pkcs = <
+ CLK_CKPER_HSE
+ CLK_FMC_ACLK
+ CLK_QSPI_ACLK
+ CLK_ETH_DISABLED
+ CLK_SDMMC12_PLL4P
+ CLK_DSI_DSIPLL
+ CLK_STGEN_HSE
+ CLK_USBPHY_HSE
+ CLK_SPI2S1_PLL3Q
+ CLK_SPI2S23_PLL3Q
+ CLK_SPI45_HSI
+ CLK_SPI6_HSI
+ CLK_I2C46_HSI
+ CLK_SDMMC3_PLL4P
+ CLK_USBO_USBPHY
+ CLK_ADC_CKPER
+ CLK_CEC_LSE
+ CLK_I2C12_HSI
+ CLK_I2C35_HSI
+ CLK_UART1_HSI
+ CLK_UART24_HSI
+ CLK_UART35_HSI
+ CLK_UART6_HSI
+ CLK_UART78_HSI
+ CLK_SPDIF_PLL4P
+ CLK_FDCAN_PLL4R
+ CLK_SAI1_PLL3Q
+ CLK_SAI2_PLL3Q
+ CLK_SAI3_PLL3Q
+ CLK_SAI4_PLL3Q
+ CLK_RNG1_LSI
+ CLK_RNG2_LSI
+ CLK_LPTIM1_PCLK1
+ CLK_LPTIM23_PCLK3
+ CLK_LPTIM45_LSE
+ >;
+
+ /* VCO = 1066.0 MHz => P = 266 (AXI), Q = 533 (GPU), R = 533 (DDR) */
+ pll2: st,pll@1 {
+ compatible = "st,stm32mp1-pll";
+ reg = <1>;
+ cfg = < 2 65 1 0 0 PQR(1,1,1) >;
+ frac = < 0x1400 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 417.8 MHz => P = 209, Q = 24, R = 11 */
+ pll3: st,pll@2 {
+ compatible = "st,stm32mp1-pll";
+ reg = <2>;
+ cfg = < 1 33 1 16 36 PQR(1,1,1) >;
+ frac = < 0x1a04 >;
+ u-boot,dm-pre-reloc;
+ };
+
+ /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
+ pll4: st,pll@3 {
Re: [PATCH 16/16] arm: Remove mx31pdk_defconfig board
On Wed, 8 Jul 2020 at 15:04, Jagan Teki wrote: > > On Sat, Jun 13, 2020 at 7:26 PM Jagan Teki wrote: > > > > DM, OF_CONTROL, DM_SPI and other driver model migration > > deadlines are expired for this board. > > > > Remove it. > > > > Patch-cc: Magnus Lilja > > Signed-off-by: Jagan Teki > > --- > > Added board maintainer. Acked-by: Magnus Lilja Regards, Magnus
Re: [PATCH 00/16] spi: dm-conversion (part3)
On Wed, 8 Jul 2020 at 14:55, Stefano Babic wrote: > > On 08.07.20 13:40, Jagan Teki wrote: > > On Sat, Jun 13, 2020 at 9:11 PM Tom Rini wrote: > >> > >> On Sat, Jun 13, 2020 at 07:24:39PM +0530, Jagan Teki wrote: > >> > >>> This series updated boards which are using mxc_spi > >>> driver. > >>> > >>> Series has patches for > >>> 1) DM_SPI/SPI_FLASH enablement for boards which > >>>already support DM and OF_CONTROL. > >>> 2) Drop the boards which doesn't support DM or OF_CONTROL. > >>> > >>> Now it's call for board maintainers to update their > >>> board to use device tree and DM options to alive > >>> on tree before MW. > > A couple of boards (pcm058, for example) were already updated. Some > other boards are strongly maintained and I get patches for them (dh6 for > example), so I guess it is enough to CC the board maintainers again > asking to update. We can check later how many boards will still remain. > > Best regards, > Stefano I don't think I have the possibility to bring i.MX31 PDK uptodate in the near future. Also I currently don't have access to a JTAG programmer so reprogramming u-boot on my hardware without is a bit risky. Best regards, Magnus > > > >>> > >>> thanks, > >>> Jagan. > >>> > >>> Jagan Teki (16): > >>> cl-som-imx7: Switch to DM_SPI/DM_SPI_FLASH > >>> cm_fx6: Switch to full DM-aware > >>> dh_imx6: Switch to full DM-aware > >>> arm: Remove mx51evk board > >>> arm: Remove ts4800 board > >>> arm: Remove tqma6s_wru4_mmc_defconfig > >>> arm: Remove pfla02 board > >>> arm: Remove pcm058 board > >>> arm: Remove riotboard board > >>> arm: Remove zc5202/zc5601 board > >>> arm: Remove cgtqmx6eval board > >>> arm: Remove ot1200 board > >>> arm: Remove dms-ba16 board > >>> arm: Remove configs/mx35pdk_defconfig board > >>> arm: Remove flea3_defconfig board > >>> arm: Remove mx31pdk_defconfig board > >>> > >>> arch/arm/Kconfig | 11 - > >>> arch/arm/mach-imx/mx3/Kconfig | 12 - > >>> arch/arm/mach-imx/mx5/Kconfig | 11 - > >>> arch/arm/mach-imx/mx6/Kconfig | 59 -- > >>> board/CarMediaLab/flea3/Kconfig| 15 - > >>> board/CarMediaLab/flea3/MAINTAINERS|6 - > >>> board/CarMediaLab/flea3/Makefile |8 - > >>> board/CarMediaLab/flea3/flea3.c| 224 > >>> board/CarMediaLab/flea3/lowlevel_init.S| 24 - > >>> board/advantech/dms-ba16/Kconfig | 31 - > >>> board/advantech/dms-ba16/MAINTAINERS |8 - > >>> board/advantech/dms-ba16/Makefile |6 - > >>> board/advantech/dms-ba16/clocks.cfg| 25 - > >>> board/advantech/dms-ba16/ddr-setup.cfg | 39 - > >>> board/advantech/dms-ba16/dms-ba16.c| 629 --- > >>> board/advantech/dms-ba16/dms-ba16_1g.cfg | 24 - > >>> board/advantech/dms-ba16/dms-ba16_2g.cfg | 24 - > >>> board/advantech/dms-ba16/micron-1g.cfg | 63 -- > >>> board/advantech/dms-ba16/samsung-2g.cfg| 63 -- > >>> board/bachmann/ot1200/Kconfig | 12 - > >>> board/bachmann/ot1200/MAINTAINERS |6 - > >>> board/bachmann/ot1200/Makefile | 11 - > >>> board/bachmann/ot1200/README | 20 - > >>> board/bachmann/ot1200/mx6q_4x_mt41j128.cfg | 154 --- > >>> board/bachmann/ot1200/ot1200.c | 359 --- > >>> board/bachmann/ot1200/ot1200_spl.c | 152 --- > >>> board/congatec/cgtqmx6eval/Kconfig | 12 - > >>> board/congatec/cgtqmx6eval/MAINTAINERS |6 - > >>> board/congatec/cgtqmx6eval/Makefile|8 - > >>> board/congatec/cgtqmx6eval/README | 74 -- > >>> board/congatec/cgtqmx6eval/cgtqmx6eval.c | 1091 > >>> board/el/el6x/Kconfig | 25 - > >>> board/el/el6x/MAINTAINERS |8 - > >>> board/el/el6x/Makefile |5 - > >>> board/el/el6x/el6x.c | 636 > >>> board/embest/mx6boards/Kconfig | 12 - > >>> board/embest/mx6boards/MAINTAINERS |8 - > >>> board/embest/mx6boards/Makefile|7 - > >>> board/embest/mx6boards/mx6boards.c | 662 > >>> board/freescale/mx31pdk/Kconfig| 15 - > >>> board/freescale/mx31pdk/MAINTAINERS|6 - > >>> board/freescale/mx31pdk/Makefile | 11 - > >>> board/freescale/mx31pdk/lowlevel_init.S| 76 -- > >>> board/freescale/mx31pdk/mx31pdk.c | 119 --- > >>> board/freescale/mx35pdk/Kconfig| 15 - > >>> board/freescale/mx35pdk/MAINTAINERS|6 - > >>> board/freescale/mx35pdk/Makefile |8 - > >>> board/freescale/mx35pdk/README | 114 -- > >>> board/freescale/mx35pdk/lowlevel_init.S| 239 - > >>> board/freescale/mx35pdk/mx35pdk.c | 293 -- > >>> board/freescale/mx35pdk/mx35pdk.h | 41 - > >>>
Re: [PATCH v2 2/5] arm: kirkwood: convert LaCie boards to DM_SPI_FLASH
On Wed, Jul 8, 2020 at 12:19 PM Jagan Teki wrote: > > On Sun, Jun 28, 2020 at 10:31 PM Simon Guinot > wrote: > > > > This patch converts the following Kirkwood-based LaCie boards to DM, > > DM_SPI and DM_SPI_FLASH: > > > > - d2 Network v2 > > - Internet Space v2 > > - 2Big Network v2 > > - Network Space v2 > > - Network Space Lite v2 > > - Network Space Max v2 > > - Network Space Mini v2 > > > > Signed-off-by: Simon Guinot > > --- > > Reviewed-by: Jagan Teki Any chance to move this series into master, I have a dependency for kirkwood spi driver patches. Jagan.
Re: [PATCH v2 16/23] ti: Drop sdp4430 board
On Wed, Jul 08, 2020 at 12:12:57PM +0530, Jagan Teki wrote: > On Tue, Jul 7, 2020 at 9:30 PM Tom Rini wrote: > > > > On Tue, Jul 07, 2020 at 09:18:52PM +0530, Jagan Teki wrote: > > > On Sat, Jun 13, 2020 at 11:51 PM Jagan Teki > > > wrote: > > > > > > > > On Wed, May 27, 2020 at 6:27 PM Jagan Teki > > > > wrote: > > > > > > > > > > DM, DM_SPI and other driver model migration deadlines > > > > > are expired for this board. > > > > > > > > > > Drop it. > > > > > > > > > > Cc: Lokesh Vutla > > > > > > > > Any comments? > > > > > > Any patches for DM_SPI switch on this board? > > > > As there's been > > http://patchwork.ozlabs.org/project/uboot/list/?series=183630=* > > since this was posted, if nothing else a trivial "build tested only" > > patch is appropriate now if still relevant (the specific patch to this > > board just disabled SPI outright). > > Better merge them as soon as possible, have SPI PR depends on this. It was in -next and now in master. -- Tom signature.asc Description: PGP signature
RE: [PATCH] i2c: stm32f7: SYSCFG Fast Mode Plus support for I2C STM32F7
Hi Heiko > From: Heiko Schocher > Sent: mardi 7 juillet 2020 07:21 > > Hello Patrick, > > Am 06.07.2020 um 13:31 schrieb Patrick Delaunay: > > Read SYSCFG bindings to set Fast Mode Plus bits if Fast Mode Plus > > speed is selected. > > > > Handle the stm32mp15 specific compatible to handle FastMode+ registers > > handling which is different on the stm32mp15 compared to the stm32f7 > > or stm32h7. > > Indeed, on the stm32mp15, the FastMode+ set and clear registers are > > separated while on the other platforms (F7 or H7) the control is done > > in a unique register. > > > > Signed-off-by: Patrick Delaunay > > --- > > > > drivers/i2c/stm32f7_i2c.c | 74 > ++- > > 1 file changed, 73 insertions(+), 1 deletion(-) > > Just tried to apply your patch on current mainline, but this fails for me, > reason is > missing patch: > > http://patchwork.ozlabs.org/project/uboot/patch/20200706112653.18951-2- > patrick.delau...@st.com/ > > So I add this patch also to my repo, if nobody has objections. No objection for me (as u-boot stm32 custodians / shared with Patrice Chotard), You can take the in tiny patch in your repo. I delegate the serie to Patrice only to have a review before merge this serie in stm32 tree. But he is in holiday... and I wait him for my next pull request (including this serie). > Beside of this: > > Reviewed-by: Heiko Schocher Thanks. > Thanks! > > bye, > Heiko Regards, Patrick > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PULL u-boot] Please pull u-boot-amlogic-20200708
On Wed, Jul 08, 2020 at 03:36:10PM +0200, Neil Armstrong wrote: > Hi Tom, > > This PR adds a proper board support for Odroid-N2 to get the MAC address from > fuses and > adds support for the new Odroid-C4 single board computer. > > The CI job is at > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/3944 > > Thanks, > Neil > > The following changes since commit 2f5fbb5b39f7b67044dda5c35e4a4b31685a3109: > > Prepare v2020.07 (2020-07-06 15:22:53 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-20200708 > > for you to fetch changes up to d9c967792b7830d51a1fe596f9a27ea6dfd4bcfe: > > ARM: dts: meson-sm1-odroid-c4: add ethernet PHY reset (2020-07-08 10:52:45 > +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH] arm: cmd_stm32prog: Fix the CONFIG_IS_ENABLED() usage
Hi Bin, > From: Bin Meng > Sent: mercredi 8 juillet 2020 09:19 > > Add parentheses around CONFIG_IS_ENABLED() in the if statement, to fix > potential build failures. > > Signed-off-by: Bin Meng > > --- > Fixes the issue as seen with Azure: > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=251=logs=064 > 47dc8-3759-5480-c2ba-b1f5a74bd12e=3906ed62-68d1-5fd5-bbe4-e8a557f9b32f > > arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > index 0722e4a..cbf0120 100644 > --- a/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/cmd_stm32prog.c > @@ -147,7 +147,7 @@ static int do_stm32prog(struct cmd_tbl *cmdtp, int flag, > int argc, > /* Try bootm for legacy and FIT format image */ > if (genimg_get_format((void *)uimage) != > IMAGE_FORMAT_INVALID) > do_bootm(cmdtp, 0, 4, bootm_argv); > - else if CONFIG_IS_ENABLED(CMD_BOOTZ) > + else if (CONFIG_IS_ENABLED(CMD_BOOTZ)) > do_bootz(cmdtp, 0, 4, bootm_argv); > } > > -- > 2.7.4 Reviewed-by: Patrick Delaunay Thanks Patrick
RE: [PATCH 3/3] cmd: adtimg: Refactor usage style
Thanks, > From: Eugeniu Rosca > Sent: lundi 6 juillet 2020 08:47 > > Hi Patrick, > > On Fri, Jul 03, 2020 at 04:40:28PM +, Patrick DELAUNAY wrote: > > > From: U-Boot On Behalf Of Eugeniu > > > Rosca > > > Sent: samedi 11 janvier 2020 00:30 > > > > > > Hi Tom, > > > > > > On Fri, Jan 10, 2020 at 04:50:52PM -0500, Tom Rini wrote: > > > > On Tue, Dec 24, 2019 at 05:51:08PM +0100, Eugeniu Rosca wrote: > > > > > Signed-off-by: Eugeniu Rosca > > > > > Reviewed-by: Sam Protsenko > > > > > > > > Applied to u-boot/master, thanks! > > > > > > Thanks for merging! > > > > For the planned update of the command adtimg: > > > > > [6] Soon-to-be-provided "by id|rev" add-on functionality adtimg get > > > dt --id= --rev= [avar [svar [ivar]]] > > > - Get DT address/size/index by id|rev fields > > > > Do you have plan to upstream this code or it is available in downstream ? > > > > Because stm32mp1 platform needs this feature > > Good to hear that the features are used by people out there. > > > We code in downstream [1] based on v2020.01 almost the same command > > but based on the old usage = [2] > > After a quick look, this is certainly missing the latest vanilla patches, so > is out of > sync with mainline. > > > dtimg getindex[varname] > > - get index of FDT in the image, by board identifier and revision > > : image address in RAM, in hex > > : board identifier > > : board revision (0 if not used) > > [varname]: name of variable where to store index of FDT > > > > So if you have nothing ready, I can update my code with your proposed > parameters. > > > > [1] > > https://github.com/STMicroelectronics/u-boot/blob/v2020.01-stm32mp/cmd > > /dtimg.c [2] > > https://github.com/STMicroelectronics/u-boot/commit/21b57a166e73a8457d > > 4caea6a1d37f1f3fda3d45 > > You would need to rebase these commits first. > A quicker route is to just take my patches available below: > https://github.com/erosca/u-boot/commits/master_adtimg_id_rev > > These have been extensively tested and are now running in > development/production systems for months w/o any issues. > > Do you have any comments concerning the two commits below? > https://github.com/erosca/u- > boot/commit/936a08faaf3f485527e2d1cfb8a53dcf44e17b3a > https://github.com/erosca/u- > boot/commit/e37d090dabb6973762376adca5ae10292ca3ba3d I check the 2 patches, they seems OK. I just surprized by the '--' for the command parameter because it is unusual in U-Boot commands. It wasn't enough to have .= as other command (unzip for example) but it is perhaps to late to change again the commands adtimg and it is aligned with "abootimg.c" For information, I will activate the command ADTIMG for stm32mp32 [1] and update the stm32mp1 downstream android bootcmd to use when they will be available. But I have don't yet tested them We do you plan to rebase and upstream these 2 commits ? [1] = http://patchwork.ozlabs.org/project/uboot/patch/20200706130046.22446-1-patrick.delau...@st.com/ > -- > Best regards, > Eugeniu Rosca Best regards, Patrick
Re: [PATCH v3 00/13] efi_loader: rework/improve UEFI secure boot code
On 08.07.20 07:01, AKASHI Takahiro wrote: > Summary > === > I'm currently working on reworking UEFI secure boot, aiming to add > "intermediate certificates" support. In this effort, I found a couple > of issues that should immediately be fixed or useful improvements even > without intermediate certificates support. > > Each commit in this patch series has self-explained description of > the issue to be addressed. > While they are independent in terms of functionality, they are compiled > in a set since the one may depend on the other in terms of code change > overlap. All the changes can and should be merged at once for best > convenience. Hello Takahiro, I will include patches 2-13 in the efi-2020-10-rc1-2 pull request. Thanks for your dedicated contributions to the UEFI implementation. Best regards Heinrich
[PATCH v3 14/17] efi_loader: memory buffer for variables
Saving UEFI variable as encoded U-Boot environment variables does not allow
support at runtime.
Provide functions to manage a memory buffer with UEFI variables.
Signed-off-by: Heinrich Schuchardt
---
include/efi_variable.h | 54 +++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_var_mem.c | 266 +++
3 files changed, 321 insertions(+)
create mode 100644 lib/efi_loader/efi_var_mem.c
diff --git a/include/efi_variable.h b/include/efi_variable.h
index 01054209c4..bc5985cfdb 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -141,4 +141,58 @@ efi_status_t efi_var_to_file(void);
*/
efi_status_t efi_var_from_file(void);
+/**
+ * efi_var_mem_init() - set-up variable list
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_mem_init(void);
+
+/**
+ * efi_var_mem_find() - find a variable in the list
+ *
+ * @guid: GUID of the variable
+ * @name: name of the variable
+ * @next: on exit pointer to the next variable after the found one
+ * Return: found variable
+ */
+struct efi_var_entry *efi_var_mem_find(const efi_guid_t *guid, const u16 *name,
+ struct efi_var_entry **next);
+
+/**
+ * efi_var_mem_del() - delete a variable from the list of variables
+ *
+ * @var: variable to delete
+ */
+void efi_var_mem_del(struct efi_var_entry *var);
+
+/**
+ * efi_var_mem_ins() - append a variable to the list of variables
+ *
+ * The variable is appended without checking if a variable of the same name
+ * already exists. The two data buffers are concatenated.
+ *
+ * @variable_name: variable name
+ * @vendor:GUID
+ * @attributes:variable attributes
+ * @size1: size of the first data buffer
+ * @data1: first data buffer
+ * @size2: size of the second data field
+ * @data2: second data buffer
+ * @time: time of authentication (as seconds since start of epoch)
+ * Result: status code
+ */
+efi_status_t efi_var_mem_ins(u16 *variable_name,
+const efi_guid_t *vendor, u32 attributes,
+const efi_uintn_t size1, const void *data1,
+const efi_uintn_t size2, const void *data2,
+const u64 time);
+
+/**
+ * efi_var_mem_free() - determine free memory for variables
+ *
+ * Return: maximum data size plus variable name size
+ */
+u64 efi_var_mem_free(void);
+
#endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index c87b82db32..f81ec8d277 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -36,6 +36,7 @@ obj-y += efi_runtime.o
obj-y += efi_setup.o
obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
obj-y += efi_var_common.o
+obj-y += efi_var_mem.o
ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
obj-y += efi_variable_tee.o
else
diff --git a/lib/efi_loader/efi_var_mem.c b/lib/efi_loader/efi_var_mem.c
new file mode 100644
index 00..ac55d8f8dc
--- /dev/null
+++ b/lib/efi_loader/efi_var_mem.c
@@ -0,0 +1,266 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * File interface for UEFI variables
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#include
+#include
+#include
+#include
+
+static struct efi_var_file __efi_runtime_data *efi_var_buf;
+static struct efi_var_entry __efi_runtime_data *efi_current_var;
+
+/**
+ * efi_var_mem_compare() - compare GUID and name with a variable
+ *
+ * @var: variable to compare
+ * @guid: GUID to compare
+ * @name: variable name to compare
+ * @next: pointer to next variable
+ * Return: true if match
+ */
+static bool __efi_runtime
+efi_var_mem_compare(struct efi_var_entry *var, const efi_guid_t *guid,
+ const u16 *name, struct efi_var_entry **next)
+{
+ int i;
+ u8 *guid1, *guid2;
+ const u16 *data, *var_name;
+ bool match = true;
+
+ for (guid1 = (u8 *)>guid, guid2 = (u8 *)guid, i = 0;
+i < sizeof(efi_guid_t) && match; ++i)
+ match = (guid1[i] == guid2[i]);
+
+ for (data = var->name, var_name = name;; ++data, ++var_name) {
+ if (match)
+ match = (*data == *var_name);
+ if (!*data)
+ break;
+ }
+
+ ++data;
+
+ if (next)
+ *next = (struct efi_var_entry *)
+ ALIGN((uintptr_t)data + var->length, 8);
+
+ return match;
+}
+
+struct efi_var_entry __efi_runtime
+*efi_var_mem_find(const efi_guid_t *guid, const u16 *name,
+ struct efi_var_entry **next)
+{
+ struct efi_var_entry *var, *last;
+
+ last = (struct efi_var_entry *)
+ ((uintptr_t)efi_var_buf + efi_var_buf->length);
+
+ if (!*name) {
+ if (next) {
+ *next = efi_var_buf->var;
+ if (*next >= last)
+
[PATCH v3 17/17] efi_selftest: adjust runtime test for variables
As variable services are available at runtime we have to expect EFI_SUCCESS
when calling the services.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_selftest/efi_selftest_variables_runtime.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/lib/efi_selftest/efi_selftest_variables_runtime.c
b/lib/efi_selftest/efi_selftest_variables_runtime.c
index b3b40ad2cf..3226069c0b 100644
--- a/lib/efi_selftest/efi_selftest_variables_runtime.c
+++ b/lib/efi_selftest/efi_selftest_variables_runtime.c
@@ -16,9 +16,7 @@
static struct efi_boot_services *boottime;
static struct efi_runtime_services *runtime;
-static const efi_guid_t guid_vendor0 =
- EFI_GUID(0x67029eb5, 0x0af2, 0xf6b1,
-0xda, 0x53, 0xfc, 0xb5, 0x66, 0xdd, 0x1c, 0xe6);
+static const efi_guid_t guid_vendor0 = EFI_GLOBAL_VARIABLE_GUID;
/*
* Setup unit test.
@@ -68,17 +66,18 @@ static int execute(void)
efi_st_error("SetVariable failed\n");
return EFI_ST_FAILURE;
}
- len = 3;
- ret = runtime->get_variable(L"efi_st_var0", _vendor0,
+ len = EFI_ST_MAX_DATA_SIZE;
+ ret = runtime->get_variable(L"PlatformLangCodes", _vendor0,
, , data);
- if (ret != EFI_UNSUPPORTED) {
+ if (ret != EFI_SUCCESS) {
efi_st_error("GetVariable failed\n");
return EFI_ST_FAILURE;
}
memset(, 0, 16);
*varname = 0;
+ len = 2 * EFI_ST_MAX_VARNAME_SIZE;
ret = runtime->get_next_variable_name(, varname, );
- if (ret != EFI_UNSUPPORTED) {
+ if (ret != EFI_SUCCESS) {
efi_st_error("GetNextVariableName failed\n");
return EFI_ST_FAILURE;
}
--
2.27.0
[PATCH v3 15/17] efi_loader: use memory based variable storage
Saving UEFI variable as encoded U-Boot environment variables does not allow
implement run-time support.
Use a memory buffer for storing UEFI variables.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 556 ++
1 file changed, 93 insertions(+), 463 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index f2f787fc8d..13123e7e41 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -30,145 +30,6 @@ static bool efi_secure_boot;
static enum efi_secure_mode efi_secure_mode;
static u8 efi_vendor_keys;
-/*
- * Mapping between EFI variables and u-boot variables:
- *
- * efi_$guid_$varname = {attributes}(type)value
- *
- * For example:
- *
- * efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported=
- * "{ro,boot,run}(blob)"
- * efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder=
- * "(blob)0001"
- *
- * The attributes are a comma separated list of these possible
- * attributes:
- *
- * + ro - read-only
- * + boot - boot-services access
- * + run - runtime access
- *
- * NOTE: with current implementation, no variables are available after
- * ExitBootServices, and all are persisted (if possible).
- *
- * If not specified, the attributes default to "{boot}".
- *
- * The required type is one of:
- *
- * + utf8 - raw utf8 string
- * + blob - arbitrary length hex string
- *
- * Maybe a utf16 type would be useful to for a string value to be auto
- * converted to utf16?
- */
-
-#define PREFIX_LEN (strlen("efi_----_"))
-
-/**
- * efi_to_native() - convert the UEFI variable name and vendor GUID to U-Boot
- * variable name
- *
- * The U-Boot variable name is a concatenation of prefix 'efi', the hexstring
- * encoded vendor GUID, and the UTF-8 encoded UEFI variable name separated by
- * underscores, e.g. 'efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_BootOrder'.
- *
- * @native:pointer to pointer to U-Boot variable name
- * @variable_name: UEFI variable name
- * @vendor:vendor GUID
- * Return: status code
- */
-static efi_status_t efi_to_native(char **native, const u16 *variable_name,
- const efi_guid_t *vendor)
-{
- size_t len;
- char *pos;
-
- len = PREFIX_LEN + utf16_utf8_strlen(variable_name) + 1;
- *native = malloc(len);
- if (!*native)
- return EFI_OUT_OF_RESOURCES;
-
- pos = *native;
- pos += sprintf(pos, "efi_%pUl_", vendor);
- utf16_utf8_strcpy(, variable_name);
-
- return EFI_SUCCESS;
-}
-
-/**
- * prefix() - skip over prefix
- *
- * Skip over a prefix string.
- *
- * @str: string with prefix
- * @prefix:prefix string
- * Return: string without prefix, or NULL if prefix not found
- */
-static const char *prefix(const char *str, const char *prefix)
-{
- size_t n = strlen(prefix);
- if (!strncmp(prefix, str, n))
- return str + n;
- return NULL;
-}
-
-/**
- * parse_attr() - decode attributes part of variable value
- *
- * Convert the string encoded attributes of a UEFI variable to a bit mask.
- * TODO: Several attributes are not supported.
- *
- * @str: value of U-Boot variable
- * @attrp: pointer to UEFI attributes
- * @timep: pointer to time attribute
- * Return: pointer to remainder of U-Boot variable value
- */
-static const char *parse_attr(const char *str, u32 *attrp, u64 *timep)
-{
- u32 attr = 0;
- char sep = '{';
-
- if (*str != '{') {
- *attrp = EFI_VARIABLE_BOOTSERVICE_ACCESS;
- return str;
- }
-
- while (*str == sep) {
- const char *s;
-
- str++;
-
- if ((s = prefix(str, "ro"))) {
- attr |= EFI_VARIABLE_READ_ONLY;
- } else if ((s = prefix(str, "nv"))) {
- attr |= EFI_VARIABLE_NON_VOLATILE;
- } else if ((s = prefix(str, "boot"))) {
- attr |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
- } else if ((s = prefix(str, "run"))) {
- attr |= EFI_VARIABLE_RUNTIME_ACCESS;
- } else if ((s = prefix(str, "time="))) {
- attr |=
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS;
- hex2bin((u8 *)timep, s, sizeof(*timep));
- s += sizeof(*timep) * 2;
- } else if (*str == '}') {
- break;
- } else {
- printf("invalid attribute: %s\n", str);
- break;
- }
-
- str = s;
- sep = ',';
- }
-
- str++;
-
- *attrp = attr;
-
- return str;
-}
-
/**
* efi_set_secure_state - modify secure boot state variables
* @secure_boot: value of SecureBoot
@@
[PATCH v3 16/17] efi_loader: enable UEFI variables at runtime
Enable UEFI variables at runtime.
Signed-off-by: Heinrich Schuchardt
---
v3:
Use efi_var_mem_ins() when restoring variables from file.
Remove EFI_VARIABLE_READ_ONLY attribute in runtime GetVariable().
---
lib/efi_loader/efi_runtime.c | 2 ++
lib/efi_loader/efi_var_file.c | 6 +++---
lib/efi_loader/efi_variable.c | 14 --
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 5b6506fbdc..91a4551448 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -121,6 +121,8 @@ efi_status_t efi_init_runtime_supported(void)
rt_table->version = EFI_RT_PROPERTIES_TABLE_VERSION;
rt_table->length = sizeof(struct efi_rt_properties_table);
rt_table->runtime_services_supported =
+ EFI_RT_SUPPORTED_GET_VARIABLE |
+ EFI_RT_SUPPORTED_GET_NEXT_VARIABLE_NAME |
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
EFI_RT_SUPPORTED_CONVERT_POINTER;
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index b1b7532495..880c279aef 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -183,9 +183,9 @@ static efi_status_t __maybe_unused efi_var_restore(struct
efi_var_file *buf)
u16 *data = var->name + u16_strlen(var->name) + 1;
if (var->attr & EFI_VARIABLE_NON_VOLATILE && var->length) {
- ret = efi_set_variable_int(var->name, >guid,
- var->attr, var->length,
- data, true);
+ ret = efi_var_mem_ins(var->name, >guid, var->attr,
+ var->length, data, 0, NULL,
+ var->time);
if (ret != EFI_SUCCESS)
log_err("Failed to set EFI variable %ls\n",
var->name);
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 13123e7e41..c8fbcf396b 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -672,7 +672,16 @@ static efi_status_t __efi_runtime EFIAPI
efi_get_variable_runtime(u16 *variable_name, const efi_guid_t *vendor,
u32 *attributes, efi_uintn_t *data_size, void *data)
{
- return EFI_UNSUPPORTED;
+ efi_status_t ret;
+
+ ret = efi_get_variable_int(variable_name, vendor, attributes,
+ data_size, data, NULL);
+
+ /* Remove EFI_VARIABLE_READ_ONLY flag */
+ if (attributes)
+ *attributes &= EFI_VARIABLE_MASK;
+
+ return ret;
}
/**
@@ -688,7 +697,8 @@ static efi_status_t __efi_runtime EFIAPI
efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size,
u16 *variable_name, efi_guid_t *vendor)
{
- return EFI_UNSUPPORTED;
+ return efi_get_next_variable_name_int(variable_name_size, variable_name,
+ vendor);
}
/**
--
2.27.0
[PATCH v3 12/17] efi_loader: optional pointer for ConvertPointer
If the EFI_OPTIONAL_PTR is set in DebugDisposition, a NULL pointer does not
constitute an invalid parameter.
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h| 2 ++
lib/efi_loader/efi_runtime.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index 759d911875..5744f6aed8 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -251,6 +251,8 @@ struct efi_rt_properties_table {
u32 runtime_services_supported;
};
+#define EFI_OPTIONAL_PTR 0x0001
+
struct efi_runtime_services {
struct efi_table_hdr hdr;
efi_status_t (EFIAPI *get_time)(struct efi_time *time,
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 45baa2fd3e..a4aa1d8b6c 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -512,6 +512,12 @@ efi_convert_pointer(efi_uintn_t debug_disposition, void
**address)
ret = EFI_INVALID_PARAMETER;
goto out;
}
+ if (!*address) {
+ if (debug_disposition & EFI_OPTIONAL_PTR)
+ return EFI_SUCCESS;
+ else
+ return EFI_INVALID_PARAMETER;
+ }
addr = (uintptr_t)*address;
for (i = 0; i < efi_descriptor_count; i++) {
--
2.27.0
[PATCH v3 13/17] efi_loader: new function efi_memcpy_runtime()
Provide a memcpy() function that we can use at UEFI runtime.
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_runtime.c | 19 +++
2 files changed, 22 insertions(+)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index fe8774f133..bf03a89ca5 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -789,6 +789,9 @@ bool efi_secure_boot_enabled(void);
bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
WIN_CERTIFICATE **auth, size_t *auth_len);
+/* runtime implementation of memcpy() */
+void efi_memcpy_runtime(void *dest, const void *src, size_t n);
+
#else /* CONFIG_IS_ENABLED(EFI_LOADER) */
/* Without CONFIG_EFI_LOADER we don't have a runtime section, stub it out */
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index a4aa1d8b6c..5b6506fbdc 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -137,6 +137,25 @@ efi_status_t efi_init_runtime_supported(void)
return ret;
}
+/**
+ * efi_memcpy_runtime() - copy memory area
+ *
+ * At runtime memcpy() is not available.
+ *
+ * @dest: destination buffer
+ * @src: source buffer
+ * @n: number of bytes to copy
+ * Return: pointer to destination buffer
+ */
+void __efi_runtime efi_memcpy_runtime(void *dest, const void *src, size_t n)
+{
+ u8 *d = dest;
+ const u8 *s = src;
+
+ for (; n; --n)
+ *d++ = *s++;
+}
+
/**
* efi_update_table_header_crc32() - Update crc32 in table header
*
--
2.27.0
[PATCH v3 09/17] efi_loader: secure boot flag
In audit mode the UEFI variable SecureBoot is set to zero but the
efi_secure_boot flag is set to true.
The efi_secure_boot flag should match the UEFIvariable SecureBoot.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index b84b86672a..f8a50bb1be 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -190,6 +190,8 @@ static efi_status_t efi_set_secure_state(u8 secure_boot, u8
setup_mode,
const u32 attributes_rw = EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS;
+ efi_secure_boot = secure_boot;
+
ret = efi_set_variable_int(L"SecureBoot", _global_variable_guid,
attributes_ro, sizeof(secure_boot),
_boot, false);
@@ -240,8 +242,6 @@ static efi_status_t efi_transfer_secure_state(enum
efi_secure_mode mode)
ret = efi_set_secure_state(1, 0, 0, 1);
if (ret != EFI_SUCCESS)
goto err;
-
- efi_secure_boot = true;
} else if (mode == EFI_MODE_AUDIT) {
ret = efi_set_variable_int(L"PK", _global_variable_guid,
EFI_VARIABLE_BOOTSERVICE_ACCESS |
@@ -253,14 +253,10 @@ static efi_status_t efi_transfer_secure_state(enum
efi_secure_mode mode)
ret = efi_set_secure_state(0, 1, 1, 0);
if (ret != EFI_SUCCESS)
goto err;
-
- efi_secure_boot = true;
} else if (mode == EFI_MODE_USER) {
ret = efi_set_secure_state(1, 0, 0, 0);
if (ret != EFI_SUCCESS)
goto err;
-
- efi_secure_boot = true;
} else if (mode == EFI_MODE_SETUP) {
ret = efi_set_secure_state(0, 1, 0, 0);
if (ret != EFI_SUCCESS)
--
2.27.0
[PATCH v3 10/17] efi_loader: UEFI variable persistence
Persist non-volatile UEFI variables in a file on the EFI system partition.
The file is written whenever a non-volatile UEFI variable is changed after
initialization of the UEFI sub-system.
The file is read during the UEFI sub-system initialization to restore
non-volatile UEFI variables.
Signed-off-by: Heinrich Schuchardt
---
include/efi_variable.h| 62 +
lib/efi_loader/Kconfig| 8 ++
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_var_file.c | 239 ++
lib/efi_loader/efi_variable.c | 10 +-
5 files changed, 319 insertions(+), 1 deletion(-)
create mode 100644 lib/efi_loader/efi_var_file.c
diff --git a/include/efi_variable.h b/include/efi_variable.h
index 3ba274fce1..01054209c4 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -79,4 +79,66 @@ efi_status_t efi_query_variable_info_int(u32 attributes,
u64 *remaining_variable_storage_size,
u64 *maximum_variable_size);
+#define EFI_VAR_FILE_NAME "ubootefi.var"
+
+#define EFI_VAR_BUF_SIZE 0x4000
+
+#define EFI_VAR_FILE_MAGIC 0x0161566966456255 /* UbEfiVa, version 1 */
+
+/**
+ * struct efi_var_entry - UEFI variable file entry
+ *
+ * @length:length of enty, multiple of 8
+ * @attr: variable attributes
+ * @time: authentication time (seconds since start of epoch)
+ * @guid: vendor GUID
+ * @name: UTF16 variable name
+ */
+struct efi_var_entry {
+ u32 length;
+ u32 attr;
+ u64 time;
+ efi_guid_t guid;
+ u16 name[];
+};
+
+/**
+ * struct efi_var_file - file for storing UEFI variables
+ *
+ * @reserved: unused, may be overwritten by memory probing
+ * @magic: identifies file format
+ * @length:length including header
+ * @crc32: CRC32 without header
+ * @var: variables
+ */
+struct efi_var_file {
+ u64 reserved;
+ u64 magic;
+ u32 length;
+ u32 crc32;
+ struct efi_var_entry var[];
+};
+
+/**
+ * efi_var_to_file() - save non-volatile variables as file
+ *
+ * File ubootefi.var is created on the EFI system partion.
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_to_file(void);
+
+/**
+ * efi_var_from_file() - read variables from file
+ *
+ * File ubootefi.var is read from the EFI system partitions and the variables
+ * stored in the file are created.
+ *
+ * In case the file does not exist yet or a variable cannot be set EFI_SUCCESS
+ * is returned.
+ *
+ * Return: status code
+ */
+efi_status_t efi_var_from_file(void);
+
#endif
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 6c9df3a767..4324694d48 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -27,6 +27,14 @@ config EFI_LOADER
if EFI_LOADER
+config EFI_VARIABLE_FILE_STORE
+ bool "Store non-volatile UEFI variables as file"
+ depends on FAT_WRITE
+ default y
+ help
+ Select tis option if you want non-volatile UEFI variables to be stored
+ as file /ubootefi.var on the EFI system partition.
+
config EFI_GET_TIME
bool "GetTime() runtime service"
depends on DM_RTC
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 7eddd7ef37..c87b82db32 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -40,6 +40,7 @@ ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
obj-y += efi_variable_tee.o
else
obj-y += efi_variable.o
+obj-y += efi_var_file.o
endif
obj-y += efi_watchdog.o
obj-$(CONFIG_LCD) += efi_gop.o
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
new file mode 100644
index 00..b1b7532495
--- /dev/null
+++ b/lib/efi_loader/efi_var_file.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * File interface for UEFI variables
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#define LOG_CATEGORY LOGC_EFI
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PART_STR_LEN 10
+
+/**
+ * efi_set_blk_dev_to_system_partition() - select EFI system partition
+ *
+ * Set the EFI system partition as current block device.
+ *
+ * Return: status code
+ */
+static efi_status_t __maybe_unused efi_set_blk_dev_to_system_partition(void)
+{
+ char part_str[PART_STR_LEN];
+ int r;
+
+ if (!efi_system_partition.if_type) {
+ log_err("No EFI system partition\n");
+ return EFI_DEVICE_ERROR;
+ }
+ snprintf(part_str, PART_STR_LEN, "%u:%u",
+efi_system_partition.devnum, efi_system_partition.part);
+ r = fs_set_blk_dev(blk_get_if_type_name(efi_system_partition.if_type),
+ part_str, FS_TYPE_ANY);
+ if (r) {
+ log_err("Cannot read EFI system partition\n");
+ return EFI_DEVICE_ERROR;
+ }
+ return EFI_SUCCESS;
+}
+
+/**
+ * efi_var_collect() - collect non-volatile variables in buffer
+ *
+ *
[PATCH v3 11/17] efi_loader: export efi_convert_pointer()
We need ConvertPointer() to adjust pointers when implementing runtime
services within U-Boot.
After ExitBootServices() gd is not available anymore. So we should not use
EFI_ENTRY() and EFI_EXIT().
Signed-off-by: Heinrich Schuchardt
---
include/efi_loader.h | 3 +++
lib/efi_loader/efi_runtime.c | 8 +++-
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index fc9344c742..fe8774f133 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -397,6 +397,9 @@ efi_status_t efi_root_node_register(void);
efi_status_t efi_initialize_system_table(void);
/* efi_runtime_detach() - detach unimplemented runtime functions */
void efi_runtime_detach(void);
+/* efi_convert_pointer() - convert pointer to virtual address */
+efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t debug_disposition,
+ void **address);
/* Called by bootefi to make console interface available */
efi_status_t efi_console_register(void);
/* Called by bootefi to make all disk storage accessible as EFI objects */
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 121e2f65c6..45baa2fd3e 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -496,15 +496,13 @@ static __efi_runtime efi_status_t EFIAPI
efi_convert_pointer_runtime(
* @address: pointer to be converted
* Return: status code
*/
-static __efi_runtime efi_status_t EFIAPI efi_convert_pointer(
- efi_uintn_t debug_disposition, void **address)
+__efi_runtime efi_status_t EFIAPI
+efi_convert_pointer(efi_uintn_t debug_disposition, void **address)
{
efi_physical_addr_t addr;
efi_uintn_t i;
efi_status_t ret = EFI_NOT_FOUND;
- EFI_ENTRY("%zu %p", debug_disposition, address);
-
if (!efi_virtmap) {
ret = EFI_UNSUPPORTED;
goto out;
@@ -533,7 +531,7 @@ static __efi_runtime efi_status_t EFIAPI
efi_convert_pointer(
}
out:
- return EFI_EXIT(ret);
+ return ret;
}
static __efi_runtime void efi_relocate_runtime_table(ulong offset)
--
2.27.0
[PATCH v3 08/17] efi_loader: read-only AuditMode and DeployedMode
Set the read only property of the UEFI variables AuditMode and DeployedMode
conforming to the UEFI specification.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index e3b29663a0..b84b86672a 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -183,32 +183,36 @@ static const char *parse_attr(const char *str, u32
*attrp, u64 *timep)
static efi_status_t efi_set_secure_state(u8 secure_boot, u8 setup_mode,
u8 audit_mode, u8 deployed_mode)
{
- u32 attributes;
efi_status_t ret;
+ const u32 attributes_ro = EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY;
+ const u32 attributes_rw = EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS;
- attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
-EFI_VARIABLE_RUNTIME_ACCESS |
-EFI_VARIABLE_READ_ONLY;
ret = efi_set_variable_int(L"SecureBoot", _global_variable_guid,
- attributes, sizeof(secure_boot),
+ attributes_ro, sizeof(secure_boot),
_boot, false);
if (ret != EFI_SUCCESS)
goto err;
ret = efi_set_variable_int(L"SetupMode", _global_variable_guid,
- attributes, sizeof(setup_mode),
+ attributes_ro, sizeof(setup_mode),
_mode, false);
if (ret != EFI_SUCCESS)
goto err;
ret = efi_set_variable_int(L"AuditMode", _global_variable_guid,
- attributes, sizeof(audit_mode),
- _mode, false);
+ audit_mode || setup_mode ?
+ attributes_ro : attributes_rw,
+ sizeof(audit_mode), _mode, false);
if (ret != EFI_SUCCESS)
goto err;
ret = efi_set_variable_int(L"DeployedMode",
- _global_variable_guid, attributes,
+ _global_variable_guid,
+ audit_mode || deployed_mode || setup_mode ?
+ attributes_ro : attributes_rw,
sizeof(deployed_mode), _mode,
false);
err:
--
2.27.0
[PATCH v3 01/17] efi_loader: prepare for read only OP-TEE variables
We currently have two implementations of UEFI variables:
* variables provided via an OP-TEE module
* variables stored in the U-Boot environment
Read only variables are up to now only implemented in the U-Boot
environment implementation.
Provide a common interface for both implementations that allows handling
read-only variables.
As variable access is limited to very few source files put variable
related definitions into new include efi_variable.h instead of efi_loader.
Signed-off-by: Heinrich Schuchardt
---
doc/api/efi.rst | 2 +
include/efi_variable.h| 43
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_var_common.c | 78 +
lib/efi_loader/efi_variable.c | 175 --
lib/efi_loader/efi_variable_tee.c | 75 -
6 files changed, 193 insertions(+), 181 deletions(-)
create mode 100644 include/efi_variable.h
create mode 100644 lib/efi_loader/efi_var_common.c
diff --git a/doc/api/efi.rst b/doc/api/efi.rst
index d5114f05b3..cb2a1c897e 100644
--- a/doc/api/efi.rst
+++ b/doc/api/efi.rst
@@ -93,6 +93,8 @@ Runtime services
Variable services
~
+.. kernel-doc:: include/efi_variable.h
+ :internal:
.. kernel-doc:: lib/efi_loader/efi_variable.c
:internal:
diff --git a/include/efi_variable.h b/include/efi_variable.h
new file mode 100644
index 00..6789118eba
--- /dev/null
+++ b/include/efi_variable.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#ifndef _EFI_VARIABLE_H
+#define _EFI_VARIABLE_H
+
+#include
+
+#define EFI_VARIABLE_READ_ONLY BIT(31)
+
+/**
+ * efi_get_variable() - retrieve value of a UEFI variable
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer to which the variable value is copied
+ * @data: buffer to which the variable value is copied
+ * @timep: authentication time (seconds since start of epoch)
+ * Return: status code
+ */
+efi_status_t efi_get_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+ u32 *attributes, efi_uintn_t *data_size,
+ void *data, u64 *timep);
+
+/**
+ * efi_set_variable() - set value of a UEFI variable
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer with the variable value
+ * @data: buffer with the variable value
+ * @ro_check: check the read only read only bit in attributes
+ * Return: status code
+ */
+efi_status_t efi_set_variable_int(u16 *variable_name, const efi_guid_t *vendor,
+ u32 attributes, efi_uintn_t data_size,
+ const void *data, bool ro_check);
+
+#endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 57c7e66ea0..7eddd7ef37 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -35,6 +35,7 @@ obj-y += efi_root_node.o
obj-y += efi_runtime.o
obj-y += efi_setup.o
obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
+obj-y += efi_var_common.o
ifeq ($(CONFIG_EFI_MM_COMM_TEE),y)
obj-y += efi_variable_tee.o
else
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
new file mode 100644
index 00..6a4efa3f27
--- /dev/null
+++ b/lib/efi_loader/efi_var_common.c
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * UEFI runtime variable services
+ *
+ * Copyright (c) 2020, Heinrich Schuchardt
+ */
+
+#include
+#include
+#include
+
+/**
+ * efi_efi_get_variable() - retrieve value of a UEFI variable
+ *
+ * This function implements the GetVariable runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @variable_name: name of the variable
+ * @vendor:vendor GUID
+ * @attributes:attributes of the variable
+ * @data_size: size of the buffer to which the variable value is copied
+ * @data: buffer to which the variable value is copied
+ * Return: status code
+ */
+efi_status_t EFIAPI efi_get_variable(u16 *variable_name,
+const efi_guid_t *vendor, u32 *attributes,
+efi_uintn_t *data_size, void *data)
+{
+ efi_status_t ret;
+
+ EFI_ENTRY("\"%ls\" %pUl %p %p %p", variable_name, vendor, attributes,
+ data_size, data);
+
+ ret = efi_get_variable_int(variable_name, vendor, attributes,
+ data_size, data, NULL);
+
+ /* Remove EFI_VARIABLE_READ_ONLY flag */
+ if (attributes)
+ *attributes &=
[PATCH v3 07/17] efi_loader: value of VendorKeys
According to the UEFI specification the variable VendorKeys is 1 if the
"system is configured to use only vendor-provided keys".
As we do not supply any vendor keys yet the variable VendorKeys must be
zero.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 75 +++
1 file changed, 15 insertions(+), 60 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index a7de0b4022..e3b29663a0 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -282,45 +282,29 @@ err:
*/
static efi_status_t efi_init_secure_state(void)
{
- enum efi_secure_mode mode;
- efi_uintn_t size;
+ enum efi_secure_mode mode = EFI_MODE_SETUP;
+ efi_uintn_t size = 0;
efi_status_t ret;
- /*
-* TODO:
-* Since there is currently no "platform-specific" installation
-* method of Platform Key, we can't say if VendorKeys is 0 or 1
-* precisely.
-*/
-
- size = 0;
ret = efi_get_variable_int(L"PK", _global_variable_guid,
NULL, , NULL, NULL);
if (ret == EFI_BUFFER_TOO_SMALL) {
if (IS_ENABLED(CONFIG_EFI_SECURE_BOOT))
mode = EFI_MODE_USER;
- else
- mode = EFI_MODE_SETUP;
-
- efi_vendor_keys = 0;
- } else if (ret == EFI_NOT_FOUND) {
- mode = EFI_MODE_SETUP;
- efi_vendor_keys = 1;
- } else {
- goto err;
}
ret = efi_transfer_secure_state(mode);
- if (ret == EFI_SUCCESS)
- ret = efi_set_variable_int(L"VendorKeys",
- _global_variable_guid,
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS |
- EFI_VARIABLE_READ_ONLY,
- sizeof(efi_vendor_keys),
- _vendor_keys, false);
+ if (ret != EFI_SUCCESS)
+ return ret;
-err:
+ /* As we do not provide vendor keys this variable is always 0. */
+ ret = efi_set_variable_int(L"VendorKeys",
+ _global_variable_guid,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY,
+ sizeof(efi_vendor_keys),
+ _vendor_keys, false);
return ret;
}
@@ -998,39 +982,10 @@ out:
if (env_set(native_name, val)) {
ret = EFI_DEVICE_ERROR;
} else {
- bool vendor_keys_modified = false;
-
- if ((u16_strcmp(variable_name, L"PK") == 0 &&
-guidcmp(vendor, _global_variable_guid) == 0)) {
- ret = efi_transfer_secure_state(
- (delete ? EFI_MODE_SETUP :
- EFI_MODE_USER));
- if (ret != EFI_SUCCESS)
- goto err;
-
- if (efi_secure_mode != EFI_MODE_SETUP)
- vendor_keys_modified = true;
- } else if ((u16_strcmp(variable_name, L"KEK") == 0 &&
-guidcmp(vendor, _global_variable_guid) == 0)) {
- if (efi_secure_mode != EFI_MODE_SETUP)
- vendor_keys_modified = true;
- }
-
- /* update VendorKeys */
- if (vendor_keys_modified & efi_vendor_keys) {
- efi_vendor_keys = 0;
- ret = efi_set_variable_int(
- L"VendorKeys",
- _global_variable_guid,
- EFI_VARIABLE_BOOTSERVICE_ACCESS
-| EFI_VARIABLE_RUNTIME_ACCESS
-| EFI_VARIABLE_READ_ONLY,
- sizeof(efi_vendor_keys),
- _vendor_keys,
- false);
- } else {
+ if (!u16_strcmp(variable_name, L"PK"))
+ ret = efi_init_secure_state();
+ else
ret = EFI_SUCCESS;
- }
}
err:
--
2.27.0
[PATCH v3 03/17] efi_loader: separate UEFI variable API from implemementation
Separate the remaining UEFI variable API functions GetNextVariableName and
QueryVariableInfo() from internal functions implementing them.
Signed-off-by: Heinrich Schuchardt
---
v3:
avoid setting efi_runtime_services.set_variable twice
---
include/efi_variable.h| 39 +++
lib/efi_loader/efi_var_common.c | 62 +++
lib/efi_loader/efi_variable.c | 57
lib/efi_loader/efi_variable_tee.c | 55 +--
4 files changed, 134 insertions(+), 79 deletions(-)
diff --git a/include/efi_variable.h b/include/efi_variable.h
index 6789118eba..3ba274fce1 100644
--- a/include/efi_variable.h
+++ b/include/efi_variable.h
@@ -40,4 +40,43 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
u32 attributes, efi_uintn_t data_size,
const void *data, bool ro_check);
+/**
+ * efi_get_next_variable_name_int() - enumerate the current variable names
+ *
+ * @variable_name_size:size of variable_name buffer in byte
+ * @variable_name: name of uefi variable's name in u16
+ * @vendor:vendor's guid
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * Return: status code
+ */
+efi_status_t efi_get_next_variable_name_int(efi_uintn_t *variable_name_size,
+ u16 *variable_name,
+ efi_guid_t *vendor);
+
+/**
+ * efi_query_variable_info_int() - get information about EFI variables
+ *
+ * This function implements the QueryVariableInfo() runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @attributes:bitmask to select variables to
be
+ * queried
+ * @maximum_variable_storage_size: maximum size of storage area for the
+ * selected variable types
+ * @remaining_variable_storage_size: remaining size of storage are for the
+ * selected variable types
+ * @maximum_variable_size: maximum size of a variable of the
+ * selected type
+ * Returns:status code
+ */
+efi_status_t efi_query_variable_info_int(u32 attributes,
+u64 *maximum_variable_storage_size,
+u64 *remaining_variable_storage_size,
+u64 *maximum_variable_size);
+
#endif
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index 6a4efa3f27..1e2be1135b 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -76,3 +76,65 @@ efi_status_t EFIAPI efi_set_variable(u16 *variable_name,
return EFI_EXIT(ret);
}
+
+/**
+ * efi_get_next_variable_name() - enumerate the current variable names
+ *
+ * @variable_name_size:size of variable_name buffer in byte
+ * @variable_name: name of uefi variable's name in u16
+ * @vendor:vendor's guid
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * Return: status code
+ */
+efi_status_t EFIAPI efi_get_next_variable_name(efi_uintn_t *variable_name_size,
+ u16 *variable_name,
+ efi_guid_t *vendor)
+{
+ efi_status_t ret;
+
+ EFI_ENTRY("%p \"%ls\" %pUl", variable_name_size, variable_name, vendor);
+
+ ret = efi_get_next_variable_name_int(variable_name_size, variable_name,
+vendor);
+
+ return EFI_EXIT(ret);
+}
+
+/**
+ * efi_query_variable_info() - get information about EFI variables
+ *
+ * This function implements the QueryVariableInfo() runtime service.
+ *
+ * See the Unified Extensible Firmware Interface (UEFI) specification for
+ * details.
+ *
+ * @attributes:bitmask to select variables to
be
+ * queried
+ * @maximum_variable_storage_size: maximum size of storage area for the
+ * selected variable types
+ * @remaining_variable_storage_size: remaining size of storage are for the
+ * selected variable types
+ * @maximum_variable_size: maximum size of a variable of the
+ * selected type
+ * Returns:status code
+ */
+efi_status_t EFIAPI efi_query_variable_info(
+ u32 attributes, u64 *maximum_variable_storage_size,
+ u64 *remaining_variable_storage_size,
+ u64 *maximum_variable_size)
+{
+ efi_status_t ret;
+
+
[PATCH v3 05/17] efi_loader: simplify boot manager
Simplify the implementation of the UEFI boot manager:
* avoid EFI_CALL for SetVariable() and GetVariable()
* remove unnecessary type conversions
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_bootmgr.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index e268e9c4b8..e03198b57a 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
static const struct efi_boot_services *bs;
@@ -147,15 +148,14 @@ unsigned long efi_serialize_load_option(struct
efi_load_option *lo, u8 **data)
static void *get_var(u16 *name, const efi_guid_t *vendor,
efi_uintn_t *size)
{
- efi_guid_t *v = (efi_guid_t *)vendor;
efi_status_t ret;
void *buf = NULL;
*size = 0;
- EFI_CALL(ret = rs->get_variable(name, v, NULL, size, buf));
+ ret = efi_get_variable_int(name, vendor, NULL, size, buf, NULL);
if (ret == EFI_BUFFER_TOO_SMALL) {
buf = malloc(*size);
- EFI_CALL(ret = rs->get_variable(name, v, NULL, size, buf));
+ ret = efi_get_variable_int(name, vendor, NULL, size, buf, NULL);
}
if (ret != EFI_SUCCESS) {
@@ -219,10 +219,9 @@ static efi_status_t try_load_entry(u16 n, efi_handle_t
*handle)
attributes = EFI_VARIABLE_BOOTSERVICE_ACCESS |
EFI_VARIABLE_RUNTIME_ACCESS;
size = sizeof(n);
- ret = EFI_CALL(efi_set_variable(
- L"BootCurrent",
- (efi_guid_t *)_global_variable_guid,
- attributes, size, ));
+ ret = efi_set_variable_int(L"BootCurrent",
+ _global_variable_guid,
+ attributes, size, , false);
if (ret != EFI_SUCCESS) {
if (EFI_CALL(efi_unload_image(*handle))
!= EFI_SUCCESS)
@@ -262,22 +261,19 @@ efi_status_t efi_bootmgr_load(efi_handle_t *handle)
rs = systab.runtime;
/* BootNext */
- bootnext = 0;
size = sizeof(bootnext);
- ret = EFI_CALL(efi_get_variable(L"BootNext",
- (efi_guid_t *)_global_variable_guid,
- NULL, , ));
+ ret = efi_get_variable_int(L"BootNext",
+ _global_variable_guid,
+ NULL, , , NULL);
if (ret == EFI_SUCCESS || ret == EFI_BUFFER_TOO_SMALL) {
/* BootNext does exist here */
if (ret == EFI_BUFFER_TOO_SMALL || size != sizeof(u16))
log_err("BootNext must be 16-bit integer\n");
/* delete BootNext */
- ret = EFI_CALL(efi_set_variable(
- L"BootNext",
- (efi_guid_t *)_global_variable_guid,
- EFI_VARIABLE_NON_VOLATILE, 0,
- ));
+ ret = efi_set_variable_int(L"BootNext",
+ _global_variable_guid,
+ 0, 0, NULL, false);
/* load BootNext */
if (ret == EFI_SUCCESS) {
--
2.27.0
[PATCH v3 04/17] efi_loader: OsIndicationsSupported, PlatformLangCodes
UEFI variables OsIndicationsSupported, PlatformLangCodes should be read
only.
Avoid EFI_CALL() for SetVariable().
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_setup.c | 59 --
1 file changed, 31 insertions(+), 28 deletions(-)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index a3b05a4a9b..6196c0a06c 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#define OBJ_LIST_NOT_INITIALIZED 1
@@ -40,12 +41,13 @@ static efi_status_t efi_init_platform_lang(void)
* Variable PlatformLangCodes defines the language codes that the
* machine can support.
*/
- ret = EFI_CALL(efi_set_variable(L"PlatformLangCodes",
- _global_variable_guid,
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS,
- sizeof(CONFIG_EFI_PLATFORM_LANG_CODES),
- CONFIG_EFI_PLATFORM_LANG_CODES));
+ ret = efi_set_variable_int(L"PlatformLangCodes",
+ _global_variable_guid,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY,
+ sizeof(CONFIG_EFI_PLATFORM_LANG_CODES),
+ CONFIG_EFI_PLATFORM_LANG_CODES, false);
if (ret != EFI_SUCCESS)
goto out;
@@ -53,9 +55,9 @@ static efi_status_t efi_init_platform_lang(void)
* Variable PlatformLang defines the language that the machine has been
* configured for.
*/
- ret = EFI_CALL(efi_get_variable(L"PlatformLang",
- _global_variable_guid,
- NULL, _size, ));
+ ret = efi_get_variable_int(L"PlatformLang",
+ _global_variable_guid,
+ NULL, _size, , NULL);
if (ret == EFI_BUFFER_TOO_SMALL) {
/* The variable is already set. Do not change it. */
ret = EFI_SUCCESS;
@@ -70,12 +72,12 @@ static efi_status_t efi_init_platform_lang(void)
if (pos)
*pos = 0;
- ret = EFI_CALL(efi_set_variable(L"PlatformLang",
- _global_variable_guid,
- EFI_VARIABLE_NON_VOLATILE |
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS,
- 1 + strlen(lang), lang));
+ ret = efi_set_variable_int(L"PlatformLang",
+ _global_variable_guid,
+ EFI_VARIABLE_NON_VOLATILE |
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ 1 + strlen(lang), lang, false);
out:
if (ret != EFI_SUCCESS)
printf("EFI: cannot initialize platform language settings\n");
@@ -96,13 +98,13 @@ static efi_status_t efi_init_secure_boot(void)
};
efi_status_t ret;
- /* TODO: read-only */
- ret = EFI_CALL(efi_set_variable(L"SignatureSupport",
- _global_variable_guid,
- EFI_VARIABLE_BOOTSERVICE_ACCESS
-| EFI_VARIABLE_RUNTIME_ACCESS,
- sizeof(signature_types),
- _types));
+ ret = efi_set_variable_int(L"SignatureSupport",
+ _global_variable_guid,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY,
+ sizeof(signature_types),
+ _types, false);
if (ret != EFI_SUCCESS)
printf("EFI: cannot initialize SignatureSupport variable\n");
@@ -160,12 +162,13 @@ efi_status_t efi_init_obj_list(void)
goto out;
/* Indicate supported features */
- ret = EFI_CALL(efi_set_variable(L"OsIndicationsSupported",
- _global_variable_guid,
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS,
- sizeof(os_indications_supported),
- _indications_supported));
+ ret =
[PATCH v3 02/17] efi_loader: display RO attribute in printenv -e
Let the 'printenv -e' command display the read only flag.
If the variable is time authenticated write the time stamp.
Avoid EFI_CALL() when calling SetVariable() and GetVariable().
Signed-off-by: Heinrich Schuchardt
---
cmd/nvedit_efi.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index 29cad38e19..3f61d5d6cc 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -9,11 +9,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -34,6 +36,7 @@ static const struct {
{EFI_VARIABLE_RUNTIME_ACCESS, "RT"},
{EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS, "AW"},
{EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS, "AT"},
+ {EFI_VARIABLE_READ_ONLY, "RO"},
};
static const struct {
@@ -87,20 +90,22 @@ static void efi_dump_single_var(u16 *name, const efi_guid_t
*guid, bool verbose)
{
u32 attributes;
u8 *data;
+ u64 time;
+ struct rtc_time tm;
efi_uintn_t size;
int count, i;
efi_status_t ret;
data = NULL;
size = 0;
- ret = EFI_CALL(efi_get_variable(name, guid, , , data));
+ ret = efi_get_variable_int(name, guid, , , data, );
if (ret == EFI_BUFFER_TOO_SMALL) {
data = malloc(size);
if (!data)
goto out;
- ret = EFI_CALL(efi_get_variable(name, guid, , ,
- data));
+ ret = efi_get_variable_int(name, guid, , ,
+ data, );
}
if (ret == EFI_NOT_FOUND) {
printf("Error: \"%ls\" not defined\n", name);
@@ -109,13 +114,16 @@ static void efi_dump_single_var(u16 *name, const
efi_guid_t *guid, bool verbose)
if (ret != EFI_SUCCESS)
goto out;
- printf("%ls:\n%s:", name, efi_guid_to_str(guid));
+ rtc_to_tm(time, );
+ printf("%ls:\n%s:\n", name, efi_guid_to_str(guid));
+ if (attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)
+ printf("%04d-%02d-%02d %02d:%02d:%02d\n", tm.tm_year,
+ tm.tm_mon, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
+ printf("");
for (count = 0, i = 0; i < ARRAY_SIZE(efi_var_attrs); i++)
if (attributes & efi_var_attrs[i].mask) {
if (count)
putc('|');
- else
- putc(' ');
count++;
puts(efi_var_attrs[i].text);
}
@@ -592,8 +600,8 @@ int do_env_set_efi(struct cmd_tbl *cmdtp, int flag, int
argc,
p = var_name16;
utf8_utf16_strncpy(, var_name, len + 1);
- ret = EFI_CALL(efi_set_variable(var_name16, , attributes,
- size, value));
+ ret = efi_set_variable_int(var_name16, , attributes, size, value,
+ true);
unmap_sysmem(value);
if (ret == EFI_SUCCESS) {
ret = CMD_RET_SUCCESS;
--
2.27.0
[PATCH v3 06/17] efi_loader: keep attributes in efi_set_variable_int
Do not change the value of parameter attributes in function
efi_set_variable_int(). This allows to use it later.
Do not use variable attr for different purposes but declare separate
variables (attr and old_attr).
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6706438b26..a7de0b4022 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -827,7 +827,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
efi_uintn_t old_size;
bool append, delete;
u64 time = 0;
- u32 attr;
+ u32 old_attr;
efi_status_t ret = EFI_SUCCESS;
if (!variable_name || !*variable_name || !vendor ||
@@ -843,8 +843,8 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
/* check if a variable exists */
old_size = 0;
- attr = 0;
- ret = efi_get_variable_int(variable_name, vendor, ,
+ old_attr = 0;
+ ret = efi_get_variable_int(variable_name, vendor, _attr,
_size, NULL, );
append = !!(attributes & EFI_VARIABLE_APPEND_WRITE);
attributes &= ~(u32)EFI_VARIABLE_APPEND_WRITE;
@@ -852,15 +852,15 @@ efi_status_t efi_set_variable_int(u16 *variable_name,
const efi_guid_t *vendor,
/* check attributes */
if (old_size) {
- if (ro_check && (attr & EFI_VARIABLE_READ_ONLY)) {
+ if (ro_check && (old_attr & EFI_VARIABLE_READ_ONLY)) {
ret = EFI_WRITE_PROTECTED;
goto err;
}
/* attributes won't be changed */
if (!delete &&
- ((ro_check && attr != attributes) ||
-(!ro_check && ((attr & ~(u32)EFI_VARIABLE_READ_ONLY)
+ ((ro_check && old_attr != attributes) ||
+(!ro_check && ((old_attr & ~(u32)EFI_VARIABLE_READ_ONLY)
!= (attributes &
~(u32)EFI_VARIABLE_READ_ONLY) {
ret = EFI_INVALID_PARAMETER;
goto err;
@@ -902,7 +902,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS) {
ret = efi_variable_authenticate(variable_name, vendor,
_size, ,
- attributes, ,
+ attributes, _attr,
);
if (ret != EFI_SUCCESS)
goto err;
@@ -936,7 +936,7 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
goto err;
}
ret = efi_get_variable_int(variable_name, vendor,
- , _size, old_data, NULL);
+ _attr, _size, old_data,
NULL);
if (ret != EFI_SUCCESS)
goto err;
} else {
@@ -962,8 +962,8 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
EFI_VARIABLE_RUNTIME_ACCESS |
EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS);
s += sprintf(s, "{");
- while (attributes) {
- attr = 1 << (ffs(attributes) - 1);
+ for (u32 attr_rem = attributes; attr_rem;) {
+ u32 attr = 1 << (ffs(attr_rem) - 1);
if (attr == EFI_VARIABLE_READ_ONLY) {
s += sprintf(s, "ro");
@@ -979,8 +979,8 @@ efi_status_t efi_set_variable_int(u16 *variable_name, const
efi_guid_t *vendor,
s = bin2hex(s, (u8 *), sizeof(time));
}
- attributes &= ~attr;
- if (attributes)
+ attr_rem &= ~attr;
+ if (attr_rem)
s += sprintf(s, ",");
}
s += sprintf(s, "}");
--
2.27.0
[PATCH v3 00/17] efi_loader: non-volatile and runtime variables
Up to now UEFI variables where stored in U-Boot environment variables. Saving UEFI variables was not possible without saving the U-Boot environment variables. With this patch series file ubootefi.var in the EFI system partition is used for saving UEFI variables. Furthermore the UEFI variables are exposed for reading at runtime. v3: Use efi_var_mem_ins() when restoring variables from file. Remove EFI_VARIABLE_READ_ONLY attribute in runtime GetVariable(). Avoid setting efi_runtime_services.set_variable twice. v2: Rebase the series to consider OP-TEE based variables and authenticated variables. Do not enable SetVariable() at runtime as we cannot persist non-volatile variables at runtime. Display read-only attribute in printenv -e. Heinrich Schuchardt (17): efi_loader: prepare for read only OP-TEE variables efi_loader: display RO attribute in printenv -e efi_loader: separate UEFI variable API from implemementation efi_loader: OsIndicationsSupported, PlatformLangCodes efi_loader: simplify boot manager efi_loader: keep attributes in efi_set_variable_int efi_loader: value of VendorKeys efi_loader: read-only AuditMode and DeployedMode efi_loader: secure boot flag efi_loader: UEFI variable persistence efi_loader: export efi_convert_pointer() efi_loader: optional pointer for ConvertPointer efi_loader: new function efi_memcpy_runtime() efi_loader: memory buffer for variables efi_loader: use memory based variable storage efi_loader: enable UEFI variables at runtime efi_selftest: adjust runtime test for variables cmd/nvedit_efi.c | 24 +- doc/api/efi.rst | 2 + include/efi_api.h | 2 + include/efi_loader.h | 6 + include/efi_variable.h| 198 + lib/efi_loader/Kconfig| 8 + lib/efi_loader/Makefile | 3 + lib/efi_loader/efi_bootmgr.c | 28 +- lib/efi_loader/efi_runtime.c | 35 +- lib/efi_loader/efi_setup.c| 59 +- lib/efi_loader/efi_var_common.c | 140 +++ lib/efi_loader/efi_var_file.c | 239 + lib/efi_loader/efi_var_mem.c | 266 ++ lib/efi_loader/efi_variable.c | 831 -- lib/efi_loader/efi_variable_tee.c | 130 +-- .../efi_selftest_variables_runtime.c | 13 +- 16 files changed, 1162 insertions(+), 822 deletions(-) create mode 100644 include/efi_variable.h create mode 100644 lib/efi_loader/efi_var_common.c create mode 100644 lib/efi_loader/efi_var_file.c create mode 100644 lib/efi_loader/efi_var_mem.c -- 2.27.0
Re: test/py GPIO failure in u-boot/master
On Wed, Jul 08, 2020 at 09:50:06AM -0600, Stephen Warren wrote:
> Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
>
> > => ut dm gpio
> > Test: dm_test_gpio: gpio.c
> > extra-gpios: get_value: error: gpio b5 not reserved
> > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> > dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> > offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> > Test: dm_test_gpio: gpio.c (flat tree)
> > extra-gpios: get_value: error: gpio b5 not reserved
> > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> > dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> > offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> > Failures: 2
>
>
> > => ut dm gpio_leak
> > Test: dm_test_gpio_leak: gpio.c
> > extra-gpios: get_value: error: gpio b5 not reserved
> > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> > dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> > offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
> > dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
> > (1)
> > Test: dm_test_gpio_leak: gpio.c (flat tree)
> > extra-gpios: get_value: error: gpio b5 not reserved
> > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> > dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> > offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> > /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
> > dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1
> > (1)
> > Failures: 4
>
> This was introduced by one of the following changes; I'd assume due to
> the GPIO patch:
>
> > cmd: part: Add subcommand to list supported partition tables (detail)
> > cmd: fs: Add command to list supported fs types (detail)
> > cmd: dm: Fixed/Added DM driver listing subcommands (detail)
> > cmd: blkls: Add blkls command (detail)
> > image: Add support for ZSTD decompression (detail)
> > Actions: OWL: Calculate SDRAM size (detail)
> > arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs
> > (detail)
> > clk: actions: Add Ethernet clocks (detail)
> > net: phy: realtek: Add support for RTL8201F PHY module. (detail)
> > net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust
> > (detail)
> > net: designware: s700: Add glue code for S700 mac (detail)
> > arm: dts: s700: add node for ethernet controller (detail)
> > owl: Kconfig: Enable DM eth for OWL platform (detail)
> > configs: Enable mac and phy configs (detail)
> > gpio: search for gpio label if gpio is not found through bank name (detail)
> > test_sleep.py: make sleep time and margin configurable (detail)
> > fs: fat_write: fix short name creation. (detail)
> > trace: clang compatible handling of gd register (detail)
> > arm: remove outdated comment concerning -ffixed-x18 (detail)
> > arm: use correct argument size of special registers (detail)
> > arm: vexpress64: Fix counter frequency (detail)
> > net: dm: Remove warning about EEPROM provided MAC address (detail)
> > net: smc911x: Properly handle EEPROM MAC address (detail)
> > arm: juno: Enable DM_ETH (detail)
> > sata_sil: Enable DM_PCI operation (detail)
> > arm: juno: Enable PCI (detail)
> > arm: juno: Enable SATA controller (detail)
>
> I see what was probably an attempt to fix this:
>
> > commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
> > Author: Heiko Schocher
> > Date: Wed Jul 8 10:24:00 2020 +0200
> >
> > gpio: fix test.py for gpio label lookup
>
> ... but the tests are still failing after that. Did that patch edit the
> wrong defconfig, or is there an incremental build issue that prevented
> that patch being effective?
The tests are passing here and in GitLab again, so I'm not sure what's
happening on your end.
--
Tom
signature.asc
Description: PGP signature
test/py GPIO failure in u-boot/master
Latest u-boot/master is failing a couple test/py test_ut tests for GPIO:
> => ut dm gpio
> Test: dm_test_gpio: gpio.c
> extra-gpios: get_value: error: gpio b5 not reserved
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> Test: dm_test_gpio: gpio.c (flat tree)
> extra-gpios: get_value: error: gpio b5 not reserved
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> Failures: 2
> => ut dm gpio_leak
> Test: dm_test_gpio_leak: gpio.c
> extra-gpios: get_value: error: gpio b5 not reserved
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
> dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1 (1)
> Test: dm_test_gpio_leak: gpio.c (flat tree)
> extra-gpios: get_value: error: gpio b5 not reserved
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:137,
> dm_test_gpio (): 0 == gpio_lookup_name ("hog_input_active_low", & dev, &
> offset, & gpio): Expected 0x0 (0), got 0xffea (-22)
> /var/lib/jenkins/workspace/u-boot-denx_uboot-master-build/src/u-boot/test/dm/gpio.c:302,
> dm_test_gpio_leak (): 0 == dm_test_gpio (ut): Expected 0x0 ( 0), got 0x1 (1)
> Failures: 4
This was introduced by one of the following changes; I'd assume due to
the GPIO patch:
> cmd: part: Add subcommand to list supported partition tables (detail)
> cmd: fs: Add command to list supported fs types (detail)
> cmd: dm: Fixed/Added DM driver listing subcommands (detail)
> cmd: blkls: Add blkls command (detail)
> image: Add support for ZSTD decompression (detail)
> Actions: OWL: Calculate SDRAM size (detail)
> arm: actions: remove "CONFIG_SYS_SDRAM_SIZE" for Actions Owl Semi SoCs
> (detail)
> clk: actions: Add Ethernet clocks (detail)
> net: phy: realtek: Add support for RTL8201F PHY module. (detail)
> net: phy: realtek: Introduce PHY_RTL8201F_S700_RMII_TIMINGS to adjust (detail)
> net: designware: s700: Add glue code for S700 mac (detail)
> arm: dts: s700: add node for ethernet controller (detail)
> owl: Kconfig: Enable DM eth for OWL platform (detail)
> configs: Enable mac and phy configs (detail)
> gpio: search for gpio label if gpio is not found through bank name (detail)
> test_sleep.py: make sleep time and margin configurable (detail)
> fs: fat_write: fix short name creation. (detail)
> trace: clang compatible handling of gd register (detail)
> arm: remove outdated comment concerning -ffixed-x18 (detail)
> arm: use correct argument size of special registers (detail)
> arm: vexpress64: Fix counter frequency (detail)
> net: dm: Remove warning about EEPROM provided MAC address (detail)
> net: smc911x: Properly handle EEPROM MAC address (detail)
> arm: juno: Enable DM_ETH (detail)
> sata_sil: Enable DM_PCI operation (detail)
> arm: juno: Enable PCI (detail)
> arm: juno: Enable SATA controller (detail)
I see what was probably an attempt to fix this:
> commit 7012865e961ca2645d783adf4b75ca4abdbfe5a7 (u-boot/master)
> Author: Heiko Schocher
> Date: Wed Jul 8 10:24:00 2020 +0200
>
> gpio: fix test.py for gpio label lookup
... but the tests are still failing after that. Did that patch edit the
wrong defconfig, or is there an incremental build issue that prevented
that patch being effective?
Re: [PATCH] config: Enable USB Keyboard support on RPi4
On 05/05/2020 16:51, Nicolas Saenz Julienne wrote: Supporting USB keyboards out of the box is both handy for development and production. Notably if u-boot is used to boot into GRUB. Signed-off-by: Nicolas Saenz Julienne Applied to rpi-next now. I dropped the hunk for 32 bit for now, please resend once 32 bit support got accepted. Regards, Matthias --- Note that rpi_arm64_defconfig already supports USB keyboard. This is to be applied on top of Sylwester Nawrocki's PCIe/xHCI on RPi4 series. configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index dd7da1cf06..9c5ad7684e 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y +CONFIG_USB_KEYBOARD=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 6eeec4592e..1a92cd637e 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_USB=y CONFIG_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_PCI=y +CONFIG_USB_KEYBOARD=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525
Re: CONFIG_NR_DRAM_BANKS in configs/rpi_4* deleted
On Wed, Jul 08, 2020 at 05:21:59PM +0200, Matthias Brugger wrote:
> Hi Tom,
>
> I just realized that
> 88bd5b1793 ("configs: Resync with savedefconfig")
>
> Delete the CONFIG_NR_DRAM_BANKS entries as added in this patch, which leads
> to a regression in RPi4 (only one GB of memory visible to the kernel if you
> use Grub for booting).
>
> Is it generally wrong to add CONFIG_NR_DRAM_BANKS to the config files? What
> is the correct approach then?
So, if savedefconfig removes an entry from the file, it's not needed.
In this case we see:
config NR_DRAM_BANKS
int "Number of DRAM banks"
default 1 if ARCH_SUNXI || ARCH_OWL
default 4
help
This defines the number of DRAM banks.
In the top-level Kconfig file. Since you set it as 4 and 4 is the
default, that's what's used:
$ make O=/tmp/rpi_4 rpi_4_config -sj
$ grep NR_D /tmp/rpi_4/.config
CONFIG_NR_DRAM_BANKS=4
$ grep ARCH_FIX /tmp/rpi_4/.config
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
--
Tom
signature.asc
Description: PGP signature
CONFIG_NR_DRAM_BANKS in configs/rpi_4* deleted
Hi Tom,
I just realized that
88bd5b1793 ("configs: Resync with savedefconfig")
Delete the CONFIG_NR_DRAM_BANKS entries as added in this patch, which leads to a
regression in RPi4 (only one GB of memory visible to the kernel if you use Grub
for booting).
Is it generally wrong to add CONFIG_NR_DRAM_BANKS to the config files? What is
the correct approach then?
Regards,
Matthias
On 29/05/2020 16:42, matthias@kernel.org wrote:
From: Matthias Brugger
With the new RPi4 which has 8 GB of RAM, we can have up to four DRAM
banks. Bump up the configuration files to detect all the memory in
U-Boot.
Signed-off-by: Matthias Brugger
---
configs/rpi_4_32b_defconfig | 2 +-
configs/rpi_4_defconfig | 2 +-
configs/rpi_arm64_defconfig | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index b22316cbcb..f369bb93bd 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x8000
CONFIG_TARGET_RPI_4_32B=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 165e166bbd..9b90790f06 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_4=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_ARCH_FIXUP_FDT_MEMORY=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 0cc4efad70..db375eeba7 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -4,7 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0008
CONFIG_TARGET_RPI_ARM64=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
-CONFIG_NR_DRAM_BANKS=2
+CONFIG_NR_DRAM_BANKS=4
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_PREBOOT=y
Re: [PATCH v3 07/15] dt-bindings: memory: ns3: update GIC LPI address
Hi Simon, On Mon, Jul 6, 2020 at 11:53 AM Rayagonda Kokatanur wrote: > > On Mon, Jul 6, 2020 at 10:56 AM Simon Glass wrote: > > > > Hi Rayagonda, > > > > On Sun, 5 Jul 2020 at 12:21, Rayagonda Kokatanur > > wrote: > > > > > > Hi Simon, > > > > > > On Sun, Jul 5, 2020 at 12:20 AM Rayagonda Kokatanur > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Sat, Jul 4, 2020 at 1:20 PM Rayagonda Kokatanur > > > > wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote: > > > > > > > > > > > > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur > > > > > > wrote: > > > > > > > > > > > > > > Update NS3 GIC LPI address. > > > > > > > > > > > > > > Signed-off-by: Rayagonda Kokatanur > > > > > > > > > > > > > > --- > > > > > > > include/dt-bindings/memory/bcm-ns3-mc.h | 3 +++ > > > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > > > > > > > > > > Reviewed-by: Simon Glass > > > > > > > > > > > > Lower case hex > > > > > > > > > > > > Can these be in the device tree and use a driver, like syscon maybe? > > > > > > I will use dt and syscon to get the LPI base address. > > > This will require change in arch/arm/lib/gic-v3-its.c driver. > > > > > > Hope this is okay. Please let me know. I have changed arch/arm/lib/gic-v3-its.c driver to address these comments and pushed separate patches. Please review them. Best regards, Rayagonda > > > > Yes of course, change whatever you like. > > Thank you Simon. > > > > > Regards, > > SImon
Re: [PATCH v3 06/15] board: ns3: default reset type to L3
Hi Simon,
On Wed, Jul 8, 2020 at 8:31 PM Simon Glass wrote:
>
> Hi Rayagonda,
>
> On Wed, 8 Jul 2020 at 01:01, Rayagonda Kokatanur
> wrote:
> >
> > Hi Simon,
> >
> > On Fri, Jul 3, 2020 at 6:16 AM Simon Glass wrote:
> > >
> > > Hi Rayagonda,
> > >
> > > On Mon, 29 Jun 2020 at 22:43, Rayagonda Kokatanur
> > > wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote:
> > > > >
> > > > > Hi Rayagonda,
> > > > >
> > > > > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
> > > > > wrote:
> > > > > >
> > > > > > Default "reset" from u-boot to L3 reset.
> > > > >
> > > > > U-Boot
> > > >
> > > > Thank you, will fix this.
> > > > >
> > > > > > "reset" command with argument will trigger L1 reset.
> > > > > >
> > > > > > Signed-off-by: Rajesh Ravi
> > > > > > Signed-off-by: Bharat Kumar Reddy Gooty
> > > > > > Signed-off-by: Rayagonda Kokatanur
> > > > > >
> > > > > > ---
> > > > > > board/broadcom/bcmns3/ns3.c | 20 ++--
> > > > > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/board/broadcom/bcmns3/ns3.c
> > > > > > b/board/broadcom/bcmns3/ns3.c
> > > > > > index 5e644bd466..1221f26ddc 100644
> > > > > > --- a/board/broadcom/bcmns3/ns3.c
> > > > > > +++ b/board/broadcom/bcmns3/ns3.c
> > > > > > @@ -68,7 +68,23 @@ int dram_init_banksize(void)
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > -void reset_cpu(ulong addr)
> > > > > > +void reset_cpu(ulong level)
> > > > > > {
> > > > >
> > > > > This should be in a sysreset driver. It supports different reset
> > > > > types.
> > > >
> > > > I checked the sysreset driver and found a generic/common psci driver -
> > > > drivers/sysreset/sysreset_psci.c.
> > > > We could use this common driver in our platform.
> > > >
> > > > Right now this common driver uses the same command or function_id for
> > > > both WARM and COLD reset.
> > > > But in our case we should use different commands for WARM and COLD
> > > > reset.
> > > >
> > > > I am planning to add one kconfig option (USE_FN64_CMD) through which
> > > > we can select different commands or the same command for COLD reset.
> > > >
> > > > Something like this,
> > > >
> > > > static int psci_sysreset_request(struct udevice *dev, enum sysreset_t
> > > > type)
> > > > {
> > > > unsigned long function_id;
> > > >
> > > > switch (type) {
> > > > case SYSRESET_WARM:
> > > > function_id = PSCI_0_2_FN_SYSTEM_RESET;
> > > > break;
> > > >
> > > > case SYSRESET_COLD:
> > > > if (CONFIG_IS_ENABLED(USE_FN64_CMD))
> > > > function_id = PSCI_0_2_FN64_SYSTEM_RESET;
> > > > else
> > > > function_id = PSCI_0_2_FN_SYSTEM_RESET;
> > > > break;
> > > >
> > > > case SYSRESET_POWER_OFF:
> > > > function_id = PSCI_0_2_FN_SYSTEM_OFF;
> > > > break;
> > > >
> > > > default:
> > > > return -ENOSYS;
> > > > }
> > > >
> > > > invoke_psci_fn(function_id, 0, 0, 0);
> > > >
> > > > return -EINPROGRESS;
> > > > }
> > > >
> > > > This way any platform can define/select USE_FN64_CMD if they need
> > > > different commands for WARM reset.
> > > > Please let me know about this approach.
> > >
> > > It seems OK, but better would be to use the device tree to determine
> > > the command (e.g. compatible string or a property).
> >
> > I was checking linux psci drivers (drivers/firmware/psci/psci.c), they
> > are handling SYSTEM_RESET and SYSTEM_RESET2 without dt ie they read
> > psci capability, if it supports SYSTEM_RESET2 then they use it else
> > they use SYSTEM_RESET only.
> > I think, in U-Boot also we should handle in the same way.
> > This is a little bit more work, hence I am planning to handle this as
> > a separate patch set only.
> > So request you to allow this patch as it is.
> >
> > Please let me know.
>
> That's fine with me. So for now can we drop the Kconfig and just
> support SYSTEM_RESET?
For now I will keep this patch as it is, won't use UCLASS_SYSRESET.
Later I will push patch to,
-- use UCLASS_SYSRESET
-- Implement SYSTEM_RESET and SYSTEM_RESET2 as per linux.
Best regards,
Rayagonda
>
> Regards,
> Simon
Re: [PATCH v6 0/4] usb: xhci: Load Raspberry Pi 4 VL805's firmware
On 29/06/2020 18:37, Nicolas Saenz Julienne wrote:
Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
loaded explicitly. Earlier versions didn't need that as they where using
an EEPROM for that purpose. This series takes care of setting up the
relevant infrastructure and run the firmware loading routine at the
right moment.
Note that this builds on top of Sylwester Nawrocki's "USB host support
for Raspberry Pi 4 board" series.
This also depends on a DT/bindings patch available on the linux-mailing lists:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2205783.html
Here is the relevant bit for reference/discussion:
{
pci@1,0 {
#address-cells = <3>;
#size-cells = <2>;
ranges;
reg = <0 0 0 0 0>;
usb@1,0 {
reg = <0x1 0 0 0 0>;
resets = <
RASPBERRYPI_FIRMWARE_RESET_ID_USB>;
};
};
};
---
Changes since v5:
- Properly handle !CONFIG_IS_ENABLED(DM_RESET) in xchi code
Changes since v4:
- Correct DT PCI topology, I separated the root bridge and controller
DT nodes
- Get rid of PCI core patch as not needed with correct DT PCI topology
- Move reset support to xchi core
Changes since v3:
- Use reset controller
Changes since v2:
- Correct comment on patch #1
- Address Matthias' comments
Changes since v1:
- Rename function
- Use callback in xhci-pci.c
Nicolas Saenz Julienne (4):
arm: rpi: Add function to trigger VL805's firmware load
reset: Add Raspberry Pi 4 firmware reset controller
configs: Enable support for reset controllers on RPi4
usb: xhci: Add reset controller support
Applied now to rpi-next
Thanks!
arch/arm/mach-bcm283x/include/mach/mbox.h | 13
arch/arm/mach-bcm283x/include/mach/msg.h | 7 +++
arch/arm/mach-bcm283x/msg.c | 46 ++
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 1 +
drivers/reset/Kconfig | 10
drivers/reset/Makefile| 1 +
drivers/reset/reset-raspberrypi.c | 60 +++
drivers/usb/host/xhci-mem.c | 2 +
drivers/usb/host/xhci.c | 33 ++
.../reset/raspberrypi,firmware-reset.h| 13
include/usb/xhci.h| 2 +
13 files changed, 190 insertions(+)
create mode 100644 drivers/reset/reset-raspberrypi.c
create mode 100644 include/dt-bindings/reset/raspberrypi,firmware-reset.h
Re: [PATCH v4 0/9] USB host support for Raspberry Pi 4 board (64-bit)
On 25/05/2020 13:39, Sylwester Nawrocki wrote: Hi all, This patch series adds USB host support for Raspberry Pi 4 board. It includes the Broadcom STB PCIe controller driver ported from Linux kernel, a memory mapping update for the xHCI controller on PCIe bus for 64-bit builds and some related fixes and updates in the usb/xhci and the pci driver core code. The 32-bit ARM part has be excluded from the series and will be posted separately. The difference comparing to previous version is only in the config update patch "configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit)". The patch series is based on v2020.07-rc1 tree. Thanks, Sylwester Marek Szyprowski (3): rpi4: shorten a mapping for the DRAM rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit) configs: Enable support for the XHCI controller on RPI4 board (ARM 64-bit) Nicolas Saenz Julienne (1): linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian Sylwester Nawrocki (5): usb: xhci: Add missing cache flush in the scratchpad array initialization usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq pci: Move some PCIe register offset definitions to a common header pci: Add some PCI Express capability register offset definitions pci: Add driver for Broadcom BCM2711 SoC PCIe controller Applied now to rpi-next Thanks! arch/arm/mach-bcm283x/init.c | 20 +- configs/rpi_4_defconfig | 9 + configs/rpi_arm64_defconfig | 8 +- drivers/pci/Kconfig | 9 + drivers/pci/Makefile | 1 + drivers/pci/pci-rcar-gen3.c | 8 - drivers/pci/pcie_brcmstb.c| 623 ++ drivers/pci/pcie_intel_fpga.c | 3 - drivers/usb/host/xhci-mem.c | 3 + include/linux/bitfield.h | 52 include/pci.h | 22 +- include/usb/xhci.h| 8 - 12 files changed, 740 insertions(+), 26 deletions(-) create mode 100644 drivers/pci/pcie_brcmstb.c
[PATCH v2 1/2] spi: Remove unnecessary #ifdefs in header file
These prevent use of compile-time checks such as:
if (CONFIG_IS_ENABLED(DM_SPI))
since, for example, if CONFIG_SPL_DM_SPI is not enabled then the
definitions are not included by spi.h and the C code will not build.
The #ifdefs are unnecessary since there are no conflicts with the pre-DM
code. In any case we have almost switched over to driver model for SPI.
Drop these #ifdefs from spi.h to fix a build warning on chromebook_coral
in the following patch.
Signed-off-by: Simon Glass
---
Changes in v2:
- Add an #ifdef around spi_cs_de/activate() as these are static in many drivers
include/spi.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/spi.h b/include/spi.h
index 9b4fb8dc0b..a37900b2fd 100644
--- a/include/spi.h
+++ b/include/spi.h
@@ -39,7 +39,6 @@
#define SPI_DEFAULT_WORDLEN8
-#if CONFIG_IS_ENABLED(DM_SPI)
/* TODO(s...@chromium.org): Remove this and use max_hz from struct spi_slave */
struct dm_spi_bus {
uint max_hz;
@@ -65,8 +64,6 @@ struct dm_spi_slave_platdata {
uint mode;
};
-#endif /* CONFIG_DM_SPI */
-
/**
* enum spi_clock_phase - indicates the clock phase to use for SPI (CPHA)
*
@@ -317,6 +314,11 @@ void spi_flash_copy_mmap(void *data, void *offset, size_t
len);
*/
int spi_cs_is_valid(unsigned int bus, unsigned int cs);
+/*
+ * These names are used in several drivers and these declarations will be
+ * removed soon as part of the SPI DM migration. Drop them if driver model is
+ * enabled for SPI.
+ */
#if !CONFIG_IS_ENABLED(DM_SPI)
/**
* Activate a SPI chipselect.
@@ -335,6 +337,7 @@ void spi_cs_activate(struct spi_slave *slave);
* select to the device identified by "slave".
*/
void spi_cs_deactivate(struct spi_slave *slave);
+#endif
/**
* Set transfer speed.
@@ -343,7 +346,6 @@ void spi_cs_deactivate(struct spi_slave *slave);
* @hz:The transfer speed
*/
void spi_set_speed(struct spi_slave *slave, uint hz);
-#endif
/**
* Write 8 bits, then read 8 bits.
@@ -367,8 +369,6 @@ static inline int spi_w8r8(struct spi_slave *slave,
unsigned char byte)
return ret < 0 ? ret : din[1];
}
-#if CONFIG_IS_ENABLED(DM_SPI)
-
/**
* struct spi_cs_info - Information about a bus chip select
*
@@ -717,6 +717,5 @@ int dm_spi_get_mmap(struct udevice *dev, ulong *map_basep,
uint *map_sizep,
/* Access the operations for a SPI device */
#define spi_get_ops(dev) ((struct dm_spi_ops *)(dev)->driver->ops)
#define spi_emul_get_ops(dev) ((struct dm_spi_emul_ops *)(dev)->driver->ops)
-#endif /* CONFIG_DM_SPI */
#endif /* _SPI_H_ */
--
2.27.0.383.g050319c2ae-goog
Re: [PATCH v3 06/15] board: ns3: default reset type to L3
Hi Rayagonda,
On Wed, 8 Jul 2020 at 01:01, Rayagonda Kokatanur
wrote:
>
> Hi Simon,
>
> On Fri, Jul 3, 2020 at 6:16 AM Simon Glass wrote:
> >
> > Hi Rayagonda,
> >
> > On Mon, 29 Jun 2020 at 22:43, Rayagonda Kokatanur
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote:
> > > >
> > > > Hi Rayagonda,
> > > >
> > > > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur
> > > > wrote:
> > > > >
> > > > > Default "reset" from u-boot to L3 reset.
> > > >
> > > > U-Boot
> > >
> > > Thank you, will fix this.
> > > >
> > > > > "reset" command with argument will trigger L1 reset.
> > > > >
> > > > > Signed-off-by: Rajesh Ravi
> > > > > Signed-off-by: Bharat Kumar Reddy Gooty
> > > > > Signed-off-by: Rayagonda Kokatanur
> > > > > ---
> > > > > board/broadcom/bcmns3/ns3.c | 20 ++--
> > > > > 1 file changed, 18 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
> > > > > index 5e644bd466..1221f26ddc 100644
> > > > > --- a/board/broadcom/bcmns3/ns3.c
> > > > > +++ b/board/broadcom/bcmns3/ns3.c
> > > > > @@ -68,7 +68,23 @@ int dram_init_banksize(void)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -void reset_cpu(ulong addr)
> > > > > +void reset_cpu(ulong level)
> > > > > {
> > > >
> > > > This should be in a sysreset driver. It supports different reset types.
> > >
> > > I checked the sysreset driver and found a generic/common psci driver -
> > > drivers/sysreset/sysreset_psci.c.
> > > We could use this common driver in our platform.
> > >
> > > Right now this common driver uses the same command or function_id for
> > > both WARM and COLD reset.
> > > But in our case we should use different commands for WARM and COLD reset.
> > >
> > > I am planning to add one kconfig option (USE_FN64_CMD) through which
> > > we can select different commands or the same command for COLD reset.
> > >
> > > Something like this,
> > >
> > > static int psci_sysreset_request(struct udevice *dev, enum sysreset_t
> > > type)
> > > {
> > > unsigned long function_id;
> > >
> > > switch (type) {
> > > case SYSRESET_WARM:
> > > function_id = PSCI_0_2_FN_SYSTEM_RESET;
> > > break;
> > >
> > > case SYSRESET_COLD:
> > > if (CONFIG_IS_ENABLED(USE_FN64_CMD))
> > > function_id = PSCI_0_2_FN64_SYSTEM_RESET;
> > > else
> > > function_id = PSCI_0_2_FN_SYSTEM_RESET;
> > > break;
> > >
> > > case SYSRESET_POWER_OFF:
> > > function_id = PSCI_0_2_FN_SYSTEM_OFF;
> > > break;
> > >
> > > default:
> > > return -ENOSYS;
> > > }
> > >
> > > invoke_psci_fn(function_id, 0, 0, 0);
> > >
> > > return -EINPROGRESS;
> > > }
> > >
> > > This way any platform can define/select USE_FN64_CMD if they need
> > > different commands for WARM reset.
> > > Please let me know about this approach.
> >
> > It seems OK, but better would be to use the device tree to determine
> > the command (e.g. compatible string or a property).
>
> I was checking linux psci drivers (drivers/firmware/psci/psci.c), they
> are handling SYSTEM_RESET and SYSTEM_RESET2 without dt ie they read
> psci capability, if it supports SYSTEM_RESET2 then they use it else
> they use SYSTEM_RESET only.
> I think, in U-Boot also we should handle in the same way.
> This is a little bit more work, hence I am planning to handle this as
> a separate patch set only.
> So request you to allow this patch as it is.
>
> Please let me know.
That's fine with me. So for now can we drop the Kconfig and just
support SYSTEM_RESET?
Regards,
Simon
[PATCH v2 2/2] x86: apl: Re-enable loading of SPL
At present the SPL loader is not included in the TPL image so SPL cannot
be loaded. Fix it by including this file for both SPL and TPL.
Signed-off-by: Simon Glass
Fixes: c87f9ce2273 ("x86: Don't build some unused objects in TPL")
---
(no changes since v1)
arch/x86/cpu/apollolake/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/cpu/apollolake/Makefile b/arch/x86/cpu/apollolake/Makefile
index 11621256ae..3aa2a55676 100644
--- a/arch/x86/cpu/apollolake/Makefile
+++ b/arch/x86/cpu/apollolake/Makefile
@@ -3,6 +3,7 @@
# Copyright 2019 Google LLC
obj-$(CONFIG_SPL_BUILD) += cpu_spl.o
+obj-$(CONFIG_SPL_BUILD) += spl.o
obj-$(CONFIG_SPL_BUILD) += systemagent.o
obj-y += cpu_common.o
@@ -11,7 +12,6 @@ obj-y += cpu.o
obj-y += punit.o
obj-y += fsp_bindings.o
ifdef CONFIG_SPL_BUILD
-obj-y += spl.o
obj-y += fsp_m.o
endif
endif
--
2.27.0.383.g050319c2ae-goog
Re: [PATCH 1/2] spi: Remove unnecessary #ifdefs in header file
Hi Bin, On Tue, 7 Jul 2020 at 19:05, Bin Meng wrote: > > Hi Simon, > > On Tue, Jul 7, 2020 at 3:58 PM Bin Meng wrote: > > > > On Tue, Jul 7, 2020 at 3:56 PM Bin Meng wrote: > > > > > > On Mon, Jul 6, 2020 at 10:16 AM Simon Glass wrote: > > > > > > > > These prevent use of compile-time checks such as: > > > > > > > > if (CONFIG_IS_ENABLED(DM_SPI)) > > > > > > > > since, for example, if CONFIG_SPL_DM_SPI is not enabled then the > > > > definitions are not included by spi.h and the C code will not build. > > > > > > > > The #ifdefs are unnecessary since there are no conflicts with the pre-DM > > > > code. In any case we have almost switched over to driver model for SPI. > > > > > > > > Drop these #ifdefs from spi.h to fix a build warning on chromebook_coral > > > > in the following patch. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > include/spi.h | 8 > > > > 1 file changed, 8 deletions(-) > > > > > > > > > > Reviewed-by: Bin Meng > > > > applied to u-boot-x86, thanks! > > Unfortunately this breaks some boards. Could you please take a look? > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=250=logs=ed3f42d9-8790-5c10-89c6-b1feb81eb957=aa0bab01-4da3-5dc7-7237-a00778129ead Oh dear, the pre-DM functions conflict. I'll send a v2. Regards, SImon
Re: [PATCH v1 02/43] binman: Refactor binman_entry_find() to allow other nodes
On Wed, Jul 08, 2020 at 12:07:24PM +0800, Bin Meng wrote:
> +Tom,
>
> On Wed, Jul 8, 2020 at 10:23 AM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > On Mon, 29 Jun 2020 at 20:33, Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Jun 15, 2020 at 11:57 AM Simon Glass wrote:
> > > >
> > > > At present we can only read from a top-level binman node entry. Refactor
> > > > this function to produce a second local function which supports reading
> > > > from any node.
> > > >
> > > > Signed-off-by: Simon Glass
> > > > ---
> > > >
> > > > lib/binman.c | 18 --
> > > > 1 file changed, 12 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/lib/binman.c b/lib/binman.c
> > > > index dc3a880882..79d01230dd 100644
> > > > --- a/lib/binman.c
> > > > +++ b/lib/binman.c
> > > > @@ -29,25 +29,31 @@ struct binman_info {
> > > >
> > > > static struct binman_info *binman;
> > > >
> > > > -int binman_entry_find(const char *name, struct binman_entry *entry)
> > > > +int binman_entry_find_(ofnode node, const char *name, struct
> > > > binman_entry *entry)
> > >
> > > This one should be static. We really should agree on a naming
> > > convention for such internal APIs. I would prefer adding _internal
> > > suffix, or using __ prefix
> >
> > Well I think internal is too long and I like a trailing underscore.
> >
>
> The trailing underscore is easy to be misread.
>
> > The trailing double underscore is reserved for the compiler.
> >
>
> What I prefer is the leading double underscore which I think is allowed.
>
> > Another option is to drop the prefix, so:
> >
> > find_entry(...)
I don't like using _ as a suffix. Double leading underscore is what we
use elsewhere, so I think that's my preference as well.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 2/2] pwm: Add PWM driver for SiFive SoC
On Wed, Jul 08, 2020 at 06:30:28AM +0200, Heiko Schocher wrote:
> Hello Yash,
>
> Am 23.04.2020 um 13:27 schrieb Yash Shah:
> > Adds a PWM driver for PWM chip present in SiFive's HiFive Unleashed SoC
> > This driver is simple port of Linux pwm sifive driver from Linux v5.6
> >
> > commit: 9e37a53eb051 ("pwm: sifive: Add a driver for SiFive SoC PWM")
> >
> > Signed-off-by: Yash Shah
> > ---
> > drivers/pwm/Kconfig | 6 ++
> > drivers/pwm/Makefile | 1 +
> > drivers/pwm/pwm-sifive.c | 172
> > +++
> > 3 files changed, 179 insertions(+)
> > create mode 100644 drivers/pwm/pwm-sifive.c
>
> Reviewed-by: Heiko Schocher
>
> @Tom: Do you want to pick up this patch, or I can take it into
> u-boot-i2c tree (as I currently plan to send a pull request)?
Take it via your tree, thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] gpio: fix test.py for gpio label lookup
On Wed, Jul 08, 2020 at 10:24:00AM +0200, Heiko Schocher wrote:
> commit 2bd261dd1712 ("gpio: search for gpio label if gpio is not found
> through bank name")
>
> disabled DM_GPIO_LOOKUP_LABEL which is needed
> in sandbox defconfigs, as we have tests for this
> functionality.
>
> Signed-off-by: Heiko Schocher
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: Pull request: u-boot-rockchip-20200708
On Wed, Jul 08, 2020 at 09:29:09AM +0800, Kever Yang wrote: > Hi Tom, > > Please pull the rockchip updates: > - dts sync from kernel for rk3399 boards; > - Add Radxa Rock Pi N8, N10; > - Some feature update for Pinebook Pro; > > Gitlab ci: > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip/pipelines/3907 > > Thanks, > - Kever > > The following changes since commit 2f5fbb5b39f7b67044dda5c35e4a4b31685a3109: > > Prepare v2020.07 (2020-07-06 15:22:53 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git > tags/u-boot-rockchip-20200708 > > for you to fetch changes up to ad277eb4587ab1ac710ce8fd2b733874032d951f: > > ARM: dts: rockchip: Add Radxa Rock Pi N8 initial support (2020-07-07 > 19:45:57 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: 'next' now merged to 'master'
On Wed, Jul 08, 2020 at 08:30:51AM +0200, Heiko Schocher wrote: > Hi Tom, > > Am 07.07.2020 um 15:38 schrieb Tom Rini: > > Hey all, > > > > I have now merged the next branch back in to master and pushed that out. > > Unfortunately you changed patch: > > "gpio: search for gpio label if gpio is not found through bank name" > > [trini: Don't enable by default] > > and now travis/azure build fails now, see: > > https://dev.azure.com/hs0298/hs/_build/results?buildId=39=results > > We need this new functionality enabled in sandbox defconfigs > as I added tests in test.py for it ... > > I prepared a patch: > > https://github.com/hsdenx/u-boot-i2c/commit/d618c3c866fd58e31194675caa5fc17920be385f > > and after travis build works, I send it to list. Ah, thanks. CI was getting backed up and I didn't think it would fail like that, oops. > BTW: > If you want to look at the size changes for wandboard after merging > next branch: > > from > http://xeidos.ddns.net/ubtestresults/result/218 > u-boot.bin : 598240 bytes > > to > http://xeidos.ddns.net/ubtestresults/result/222 > u-boot.bin : 606728 bytes > > or in a graph: > > http://xeidos.ddns.net/ubtestresults/stats/wandboard_defconfig/30 > > at the end you got a graph with a list of functions with their > changes in size ... Looks about right, yeah. -- Tom signature.asc Description: PGP signature
[PULL u-boot] Please pull u-boot-amlogic-20200708
Hi Tom, This PR adds a proper board support for Odroid-N2 to get the MAC address from fuses and adds support for the new Odroid-C4 single board computer. The CI job is at https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/3944 Thanks, Neil The following changes since commit 2f5fbb5b39f7b67044dda5c35e4a4b31685a3109: Prepare v2020.07 (2020-07-06 15:22:53 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20200708 for you to fetch changes up to d9c967792b7830d51a1fe596f9a27ea6dfd4bcfe: ARM: dts: meson-sm1-odroid-c4: add ethernet PHY reset (2020-07-08 10:52:45 +0200) - Add proper Odroid-N2 board support code - Add support for Odroid-C4 single board computer Christian Hewitt (2): ARM: dts: sync amlogic G12A/G12B/SM1 DT from Linux 5.8-rc1 boards: amlogic: add Odroid C4 support Neil Armstrong (1): ARM: dts: meson-sm1-odroid-c4: add ethernet PHY reset Pascal Vizeli (1): board: amlogic: Add Odroid-N2 board support arch/arm/dts/Makefile| 1 + arch/arm/dts/meson-g12-common.dtsi | 13 +- arch/arm/dts/meson-g12.dtsi | 32 +-- arch/arm/dts/meson-g12b-khadas-vim3.dtsi | 22 +- arch/arm/dts/meson-g12b-s922x.dtsi | 15 + arch/arm/dts/meson-g12b.dtsi | 22 ++ arch/arm/dts/meson-khadas-vim3.dtsi | 4 +- arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi | 13 + arch/arm/dts/meson-sm1-odroid-c4.dts | 402 +++ arch/arm/dts/meson-sm1-sei610.dts| 2 +- arch/arm/dts/meson-sm1.dtsi | 24 ++ board/amlogic/odroid-n2/MAINTAINERS | 9 + board/amlogic/odroid-n2/Makefile | 6 + board/amlogic/odroid-n2/odroid-n2.c | 49 board/amlogic/w400/MAINTAINERS | 2 - configs/odroid-c4_defconfig | 62 + configs/odroid-n2_defconfig | 2 +- doc/board/amlogic/index.rst | 3 +- doc/board/amlogic/odroid-c4.rst | 134 + 19 files changed, 777 insertions(+), 40 deletions(-) create mode 100644 arch/arm/dts/meson-sm1-odroid-c4-u-boot.dtsi create mode 100644 arch/arm/dts/meson-sm1-odroid-c4.dts create mode 100644 board/amlogic/odroid-n2/MAINTAINERS create mode 100644 board/amlogic/odroid-n2/Makefile create mode 100644 board/amlogic/odroid-n2/odroid-n2.c create mode 100644 configs/odroid-c4_defconfig create mode 100644 doc/board/amlogic/odroid-c4.rst
Re: [PATCH 03/16] dh_imx6: Switch to full DM-aware
On Mon, Jun 22, 2020 at 3:09 PM 'Ludwig Zenz' via Amarula Linux wrote: > > On 6/13/20 3:55 PM, Jagan Teki wrote: > > Enable DM_SPI/DM_SPI_FLASH with a related config option. > > > > Build fine, but not tested. > > Hello, > > due to memory limitations in the SRAM of the i.MX6S in SPL we have not used > the device tree. Have the restrictions been removed in the meantime? We need > a single binary for the i.MX6 q/d/dl/s variants of our system on module. > > I think this patch breaks the board support for our module. Have you tried platdata on SPL side? Jagan.
Re: [PATCH 16/16] arm: Remove mx31pdk_defconfig board
On Sat, Jun 13, 2020 at 7:26 PM Jagan Teki wrote: > > DM, OF_CONTROL, DM_SPI and other driver model migration > deadlines are expired for this board. > > Remove it. > > Patch-cc: Magnus Lilja > Signed-off-by: Jagan Teki > --- Added board maintainer.
