Re: [PATCH v2 3/4] arm64: dts: imx8mm-u-boot.dtsi: use dash for node names
On Thu, 2022-01-13 at 15:22 +0100, Patrick Wildt wrote: > Some of the nodes were named using a underscore, so rectify this and > consistenly use dashes. > > Signed-off-by: Patrick Wildt Reviewed-by: Marcel Ziswiler [snip]
Re: [PATCH 1/1] configs: disable UEFI for Colibri VF610
On Fri, 2022-01-14 at 23:29 +0100, Heinrich Schuchardt wrote: > The size of the board file is limited to 520192 bytes. This conflicts with > the size requirement for the UEFI code. > > Signed-off-by: Heinrich Schuchardt Acked-by: Marcel Ziswiler > --- > configs/colibri_vf_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/colibri_vf_defconfig b/configs/colibri_vf_defconfig > index 350e1cf30e..c0a7e11a62 100644 > --- a/configs/colibri_vf_defconfig > +++ b/configs/colibri_vf_defconfig > @@ -106,4 +106,4 @@ CONFIG_VIDEO_FSL_DCU_FB=y > CONFIG_SPLASH_SCREEN_ALIGN=y > CONFIG_OF_LIBFDT_OVERLAY=y > CONFIG_FDT_FIXUP_PARTITIONS=y > -# CONFIG_EFI_UNICODE_CAPITALIZATION is not set > +# CONFIG_EFI_LOADER is not set
Re: [RFC PATCH] efi_loader: clean up uefi secure boot image verification logic
Hi Akashi-san,
On Tue, Jan 25, 2022 at 11:31:07AM +0900, AKASHI Takahiro wrote:
> Hi Ilias,
>
> On Mon, Jan 24, 2022 at 05:36:20PM +0200, Ilias Apalodimas wrote:
> > From: Ilias Apalodimas
> >
> > We currently distinguish between signed and non signed PE/COFF
> > executables while trying to authenticate signatures and/or sha256
> > hashes in db and dbx. That code duplication can be avoided.
>
> Thank you for cleaning up the code.
> The change you made here looks good.
> I want you to revise some wordings for clarification.
>
> > On sha256 hashes we don't really care if the image is signed or
> > not.
>
> The sentence above might sound a bit misleading?
I can change that to 'when checking for sha256 hashes in db' or something
along those lines
>
> > The logic can be implemented in
> > 1. Is the sha256 of the image in dbx
>
> Please explicitly mention that the image will be rejected
> in this case unlike the other cases below.
sure
>
> > 2. Is the image signed with a certificate that's found in db and
> > not in dbx
> > 3. The image carries a cert which is signed by a cert in db (and
> > not in dbx, and the image can be verified against the former)
>
> (2) and (3) are the rules applied only if the image is signed. So,
>2. If the image is signed,
> 2-1. ...
> 2-2. ...
>
> In addition, your (3) should be described in a similar way as (2).
> For instance,
>3. Is the image signed with a certificate that is carried in
> the image and the cert is signed by another cert in the image
> and so on, or in db (... ).
Doesn't the 'signed against the former' describes the same thing here?
>
> (although it is difficult to describe the logic precisely.)
>
> > 4. Is the sha256 of the image in db
> > So weed out the 'special' case handling unsigned images.
> >
> > While at it move the checking of a hash outside the certificate
> > verification loop which isn't really needed and check for the hash
> > only once.
>
> It might be my preference, but I would like to add
> assert(ret == false);
> before efi_signature_lookup_digest(regs, db) to indicate this is the last
> resort to authenticate the image.
I am not a fan of asserts myself. How about a comment or an EFI_PRINT?
>
> > Also allow a mix of signatures and hashes in db instead
> > of explicitly breaking out the sha verification loop if a signature
> > happens to be added first.
>
> I don't think that your change gives us an extra case of "allowing".
> Please elaborate if I misunderstand something.
This might actually be better of in a separated patch.
The patch for efi_signature.c changes the logic a bit.
Right now when we try to verify a hash and find a non supported algorithm
we stop processing db. But that assumes that the hashes are added first
and the signatures follow.
IOW if you add in db everything works fine when you
try to authenticate an image with it's hash. If the order is reversed the
code rejects the image (while it shouldn't)
>
> > It's worth noting that (2) only works if the certificate is self
> > signed, but that canb be fixed in a following patch.
>
> Yes, please.
>
> -Takahiro Akashi
Thanks
/Ilias
>
> > Signed-off-by: Ilias Apalodimas
> > ---
> > lib/efi_loader/efi_image_loader.c | 84 ++-
> > lib/efi_loader/efi_signature.c| 2 +-
> > 2 files changed, 15 insertions(+), 71 deletions(-)
> >
> > diff --git a/lib/efi_loader/efi_image_loader.c
> > b/lib/efi_loader/efi_image_loader.c
> > index 255613eb72ba..53d54ca42f5c 100644
> > --- a/lib/efi_loader/efi_image_loader.c
> > +++ b/lib/efi_loader/efi_image_loader.c
> > @@ -516,63 +516,16 @@ err:
> > }
> >
> > #ifdef CONFIG_EFI_SECURE_BOOT
> > -/**
> > - * efi_image_unsigned_authenticate() - authenticate unsigned image with
> > - * SHA256 hash
> > - * @regs: List of regions to be verified
> > - *
> > - * If an image is not signed, it doesn't have a signature. In this case,
> > - * its message digest is calculated and it will be compared with one of
> > - * hash values stored in signature databases.
> > - *
> > - * Return: true if authenticated, false if not
> > - */
> > -static bool efi_image_unsigned_authenticate(struct efi_image_regions *regs)
> > -{
> > - struct efi_signature_store *db = NULL, *dbx = NULL;
> > - bool ret = false;
> > -
> > - dbx = efi_sigstore_parse_sigdb(L"dbx");
> > - if (!dbx) {
> > - EFI_PRINT("Getting signature database(dbx) failed\n");
> > - goto out;
> > - }
> > -
> > - db = efi_sigstore_parse_sigdb(L"db");
> > - if (!db) {
> > - EFI_PRINT("Getting signature database(db) failed\n");
> > - goto out;
> > - }
> > -
> > - /* try black-list first */
> > - if (efi_signature_lookup_digest(regs, dbx)) {
> > - EFI_PRINT("Image is not signed and its digest found in
> > \"dbx\"\n");
> > - goto out;
> > - }
> > -
> > - /* try white-list */
> > - if (efi_signature_lookup_digest(regs,
Re: [PATCH 0/3] QEMU spike machine support for U-Boot
On Tue, Jan 25, 2022 at 10:40 AM Bin Meng wrote: > > On Tue, Jan 18, 2022 at 6:56 PM Anup Patel wrote: > > > > On Tue, Jan 18, 2022 at 3:41 PM Bin Meng wrote: > > > > > > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel > > > wrote: > > > > > > > > We can use same U-Boot binary compiled using > > > > qemu-riscv64_smode_defconfig > > > > on QEMU virt machine and QEMU spike machine. To achieve this, we need > > > > HTIF > > > > console support for U-Boot QEMU RISC-V board hence this series. > > > > > > > > To test this series with latest OpenSBI, we can use the following > > > > command: > > > > qemu-system-riscv64 -M spike -m 256M -display none -serial stdio \ > > > > -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel \ > > > > > > I think you forgot to mention this needs an updated QEMU too, due to > > > plain binary is now used for spike? > > > > Ahh, yes. I should have provided the link to the QEMU spike machine patch. > > > > QEMU patch link: > > https://lore.kernel.org/all/20220114160457.70134-1-apa...@ventanamicro.com/ > > > > Please also include a patch to update the QEMU riscv board doc, with > the updated instructions on QEMU for Spike machine. Okay, I will add a separate patch in the next revision. Regards, Anup > > Regards, > Bin
Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR
On Tue, Jan 25, 2022 at 10:33 AM Bin Meng wrote:
>
> On Sat, Jan 15, 2022 at 12:20 AM Anup Patel wrote:
> >
> > Currently, if MTD NOR is enabled then U-Boot tries to issue flash
> > commands even when CFI flash DT node is not present. This causes
> > access fault on RISC-V emulators or ISS which do not emulate CFI
> > flash. To handle this issue, we implement is_flash_available() for
> > qemu-riscv board which will return 1 only if CFI flash DT node is
> > present.
> >
> > Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> > Signed-off-by: Anup Patel
> > ---
> > board/emulation/qemu-riscv/qemu-riscv.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> > b/board/emulation/qemu-riscv/qemu-riscv.c
> > index b0d9dd59b1..cd02dae1ab 100644
> > --- a/board/emulation/qemu-riscv/qemu-riscv.c
> > +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -16,6 +17,22 @@
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > +#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
> > +int is_flash_available(void)
> > +{
> > + if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
>
> Why is this if statement needed?
>
> All QEMU riscv* defconfigs are using CONFIG_OF_BOARD, and there is no
> OF_SEPARATE use case since QEMU DTBs are always consumed by U-Boot.
I added the if statement for the case if someone disables CONFIG_OF_BOARD
but I can remove it if you insist.
>
> > + const void *fdt =
> > + (const void *)(uintptr_t)gd->arch.firmware_fdt_addr;
> > + int rc = fdt_node_offset_by_compatible(fdt, -1,
> > "cfi-flash");
> > +
> > + if (rc >= 0)
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> > int board_init(void)
> > {
> > /*
>
> Regards,
> Bin
Regards,
Anup
Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver
On Tue, Jan 25, 2022 at 10:22 AM Bin Meng wrote: > > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel wrote: > > > > Quite a few RISC-V emulators and ISS (including Spike) have host > > transfer interface (HTIF) based console. This patch adds HTIF > > based console driver for RISC-V platforms which depends totally > > on DT node for HTIF register base address. > > > > Signed-off-by: Anup Patel > > Reviewed-by: Philipp Tomsich > > --- > > drivers/serial/Kconfig | 8 ++ > > drivers/serial/Makefile | 1 + > > drivers/serial/serial_htif.c | 178 +++ > > 3 files changed, 187 insertions(+) > > create mode 100644 drivers/serial/serial_htif.c > > > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig > > index 6c8fdda9a0..345d1881f5 100644 > > --- a/drivers/serial/Kconfig > > +++ b/drivers/serial/Kconfig > > @@ -866,6 +866,14 @@ config PXA_SERIAL > > If you have a machine based on a Marvell XScale PXA2xx CPU you > > can enable its onboard serial ports by enabling this option. > > > > +config HTIF_CONSOLE > > + bool "RISC-V HTIF console support" > > + depends on DM_SERIAL && 64BIT > > Does this driver not work on 32-bit? Only putc() works but getc() does not work on 32-bit. Same issue is there with OpenSBI and BBL as well. That's why I have restricted this driver to 64-bit only. > > > + help > > + Select this to enable host transfer interface (HTIF) based serial > > + console. The HTIF device is quite common in RISC-V emulators and > > + RISC-V ISS so this driver allows using U-Boot on such platforms. > > + > > config SIFIVE_SERIAL > > bool "SiFive UART support" > > depends on DM_SERIAL > > Regards, > Bin Regards, Anup
Re: [PATCH 0/3] QEMU spike machine support for U-Boot
On Tue, Jan 18, 2022 at 6:56 PM Anup Patel wrote: > > On Tue, Jan 18, 2022 at 3:41 PM Bin Meng wrote: > > > > On Sat, Jan 15, 2022 at 12:20 AM Anup Patel wrote: > > > > > > We can use same U-Boot binary compiled using qemu-riscv64_smode_defconfig > > > on QEMU virt machine and QEMU spike machine. To achieve this, we need HTIF > > > console support for U-Boot QEMU RISC-V board hence this series. > > > > > > To test this series with latest OpenSBI, we can use the following command: > > > qemu-system-riscv64 -M spike -m 256M -display none -serial stdio \ > > > -bios opensbi/build/platform/generic/firmware/fw_jump.bin -kernel \ > > > > I think you forgot to mention this needs an updated QEMU too, due to > > plain binary is now used for spike? > > Ahh, yes. I should have provided the link to the QEMU spike machine patch. > > QEMU patch link: > https://lore.kernel.org/all/20220114160457.70134-1-apa...@ventanamicro.com/ > Please also include a patch to update the QEMU riscv board doc, with the updated instructions on QEMU for Spike machine. Regards, Bin
Re: [RESEND PATCH 3/3] Nokia RX-51: Convert documentation to rst format
On 1/24/22 20:45, Pali Rohár wrote:
Convert documentation to rst format
Signed-off-by: Pali Rohár
Thanks for converting to rst.
I guess I will simply add all 3 patches to my repo and add all typo
fixes to patch 3.
Acked-by: Heinrich Schuchardt
---
board/nokia/rx51/MAINTAINERS | 2 +-
doc/board/index.rst | 1 +
doc/board/nokia/index.rst | 9 ++
.../nokia/rx51.rst} | 144 +-
4 files changed, 87 insertions(+), 69 deletions(-)
create mode 100644 doc/board/nokia/index.rst
rename doc/{README.nokia_rx51 => board/nokia/rx51.rst} (32%)
diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index 58b16bf9a95c..25f8b3c5a9ad 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -4,5 +4,5 @@ S: Maintained
F:board/nokia/rx51/
F:include/configs/nokia_rx51.h
F:configs/nokia_rx51_defconfig
-F: doc/README.nokia_rx51
+F: doc/board/nokia/rx51.rst
F:test/nokia_rx51_test.sh
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 5607e1f94638..75c34c4a9998 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -22,6 +22,7 @@ Board-specific doc
intel/index
kontron/index
microchip/index
+ nokia/index
nxp/index
openpiton/index
qualcomm/index
diff --git a/doc/board/nokia/index.rst b/doc/board/nokia/index.rst
new file mode 100644
index ..b68c3c613164
--- /dev/null
+++ b/doc/board/nokia/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Nokia
+=
+
+.. toctree::
+ :maxdepth: 2
+
+ rx51
diff --git a/doc/README.nokia_rx51 b/doc/board/nokia/rx51.rst
similarity index 32%
rename from doc/README.nokia_rx51
rename to doc/board/nokia/rx51.rst
index e739b02088ea..7ab3a1686b1d 100644
--- a/doc/README.nokia_rx51
+++ b/doc/board/nokia/rx51.rst
@@ -1,6 +1,9 @@
-Board: Nokia RX-51 aka N900
+.. SPDX-License-Identifier: GPL-2.0+
-This board definition results in a u-boot.bin which can be chainloaded
+Nokia RX-51 aka N900
+
+
+This board definition results in a ``u-boot.bin`` which can be chainloaded
from NOLO in qemu or on a real N900. It does very little hardware config
because NOLO has already configured the board. Only needed is enabling
internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
@@ -8,64 +11,64 @@ internal eMMC memory via twl4030 regulator which is not
enabled by NOLO.
NOLO is expecting a kernel image and will treat any image it finds in
onenand as such. This u-boot is intended to be flashed to the N900 like
a kernel. In order to transparently boot the original kernel, it will be
-appended to u-boot.bin at 0x4. NOLO will load the entire image into
+appended to ``u-boot.bin`` at 0x4. NOLO will load the entire image into
(random) memory and execute u-boot, which saves hw revision, boot reason
and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
-uImage, zImage or boot.scr from a fat or ext2/3/4 filesystem on external
-SD card or internal eMMC memory. If this fails or keyboard is closed then
-the appended kernel image will be booted using some generated and some
-stored ATAGs (see boot order).
+``uImage``, ``zImage`` or ``boot.scr`` file from a fat or ext2/3/4 filesystem
+on external SD card or internal eMMC memory. If this fails or keyboard is
+closed then the appended kernel image will be booted using some generated
+and some stored ATAGs (see boot order).
For generating combined image of u-boot and kernel (either in uImage or zImage
-format) there is a simple script called u-boot-gen-combined. It is available in
-following repository:
+format) there is a simple script called ``u-boot-gen-combined``. It is
available
+in following repository:
- https://github.com/pali/u-boot-maemo
+ https://github.com/pali/u-boot-maemo
-To generate combined.bin image from u-boot.bin and kernel.bin (either uImage
-or zImage) use:
+To generate ``combined.bin`` image from ``u-boot.bin`` and ``kernel.bin``
+(either uImage or zImage format) use::
- sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin
+ $ sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin
Original Maemo Fremantle PR1.3 zImage kernel binary is available at:
-
http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
+
http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
-To unpack it (from DEB/AR, TAR and FIASCO) call commands:
+To unpack it (from DEB/AR, TAR and FIASCO) call commands::
- ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz
- tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco >
kernel_2.6.28-20103103+0m5.fiasco
- 0x -M kernel_2.6.28-20103103+0m5.fiasco -u
+ $ ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz
+ $ tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco
Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR
On Sat, Jan 15, 2022 at 12:20 AM Anup Patel wrote:
>
> Currently, if MTD NOR is enabled then U-Boot tries to issue flash
> commands even when CFI flash DT node is not present. This causes
> access fault on RISC-V emulators or ISS which do not emulate CFI
> flash. To handle this issue, we implement is_flash_available() for
> qemu-riscv board which will return 1 only if CFI flash DT node is
> present.
>
> Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> Signed-off-by: Anup Patel
> ---
> board/emulation/qemu-riscv/qemu-riscv.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
> b/board/emulation/qemu-riscv/qemu-riscv.c
> index b0d9dd59b1..cd02dae1ab 100644
> --- a/board/emulation/qemu-riscv/qemu-riscv.c
> +++ b/board/emulation/qemu-riscv/qemu-riscv.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -16,6 +17,22 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +#if IS_ENABLED(CONFIG_MTD_NOR_FLASH)
> +int is_flash_available(void)
> +{
> + if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
Why is this if statement needed?
All QEMU riscv* defconfigs are using CONFIG_OF_BOARD, and there is no
OF_SEPARATE use case since QEMU DTBs are always consumed by U-Boot.
> + const void *fdt =
> + (const void *)(uintptr_t)gd->arch.firmware_fdt_addr;
> + int rc = fdt_node_offset_by_compatible(fdt, -1, "cfi-flash");
> +
> + if (rc >= 0)
> + return 1;
> + }
> +
> + return 0;
> +}
> +#endif
> +
> int board_init(void)
> {
> /*
Regards,
Bin
Re: [RESEND PATCH 2/3] Nokia RX-51: Update documentation about flashing
On 1/24/22 20:45, Pali Rohár wrote: This change contains update for doc/README.nokia_rx51 documentation file with information how to load U-Boot image to device RAM without need to flash it and also how to flash it into OneNAND via 0x flasher. Signed-off-by: Pali Rohár --- doc/README.nokia_rx51 | 45 +++ 1 file changed, 45 insertions(+) diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51 index 1be077514f03..e739b02088ea 100644 --- a/doc/README.nokia_rx51 +++ b/doc/README.nokia_rx51 @@ -22,6 +22,51 @@ following repository: https://github.com/pali/u-boot-maemo +To generate combined.bin image from u-boot.bin and kernel.bin (either uImage +or zImage) use: Thank you for adding all this information. In the restructured text (patch 3), please use: .. code-block:: bash + + sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin + +Original Maemo Fremantle PR1.3 zImage kernel binary is available at: + + http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb + +To unpack it (from DEB/AR, TAR and FIASCO) call commands: .. code-block:: bash + + ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz + tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco > kernel_2.6.28-20103103+0m5.fiasco + 0x -M kernel_2.6.28-20103103+0m5.fiasco -u + +Flashed image must start with 2 kB "NOLO!img" header which contains size of %s/Flashed/The flashed/ %s/size/the size/ +the image. Header consist of bytes "NOLO!img\x02\x00\x00\x00\x00\x00\x00\x00" %/Header consist/The header consists/ +followed by 4 byte little endian size of the image and rest of the 2 kB header %s/4 byte/by the 4 byte/ %s/rest/the rest/ %s/kB/KiB/ +are just zero bytes. + +Nokia proprietary flasher and also open source 0x flasher automatically %s/Nokia/Nokia's/ ? +prepend required "NOLO!img" header and both applications expect that image %s/prepend required/prepends the required/ %s/that image/that the image/ +does not contain "NOLO!img" header. Adding "NOLO!img" header is required %s/contain/contain a/ %s/Adding/Adding a/ +only in case using "nandwrite" tool for flashing. %s/using/of using the/ + +Open source 0x flasher is available in following repository: %s/Open/The open/ %s/following/the following/ + + https://github.com/pali/0x + +It is possible to load u-boot.bin via USB to N900 RAM and boot it without +need to flashing it. Via 0x running at host PC it is done: + + 0x -m u-boot.bin -l -b + +0x support also flashing kernel image either via USB or directly on %s/support/supports/ +N900 device. Flashing u-boot/kernel/combined image is done as: + + 0x -m combined.bin -f + +Via 0x is possible to generate also standard flashable image in Nokia %s/is/it is/ %s/standard/a standard/ +FIASCO format which contains metadata information like device identification %s/identification/the identification/ +(RX-51) and version string (v2021.04): %s/and/and the/ Best regards Heinrich + + 0x -m RX-51:v2021.04:kernel:u-boot.bin -g u-boot.fiasco + There is support for hardware watchdog. Hardware watchdog is started by NOLO so u-boot must kick watchdog to prevent reboot device (but not very often, max every 2 seconds). There is also support for framebuffer display
Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver
On Sat, Jan 15, 2022 at 12:20 AM Anup Patel wrote: > > Quite a few RISC-V emulators and ISS (including Spike) have host > transfer interface (HTIF) based console. This patch adds HTIF > based console driver for RISC-V platforms which depends totally > on DT node for HTIF register base address. > > Signed-off-by: Anup Patel > Reviewed-by: Philipp Tomsich > --- > drivers/serial/Kconfig | 8 ++ > drivers/serial/Makefile | 1 + > drivers/serial/serial_htif.c | 178 +++ > 3 files changed, 187 insertions(+) > create mode 100644 drivers/serial/serial_htif.c > > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig > index 6c8fdda9a0..345d1881f5 100644 > --- a/drivers/serial/Kconfig > +++ b/drivers/serial/Kconfig > @@ -866,6 +866,14 @@ config PXA_SERIAL > If you have a machine based on a Marvell XScale PXA2xx CPU you > can enable its onboard serial ports by enabling this option. > > +config HTIF_CONSOLE > + bool "RISC-V HTIF console support" > + depends on DM_SERIAL && 64BIT Does this driver not work on 32-bit? > + help > + Select this to enable host transfer interface (HTIF) based serial > + console. The HTIF device is quite common in RISC-V emulators and > + RISC-V ISS so this driver allows using U-Boot on such platforms. > + > config SIFIVE_SERIAL > bool "SiFive UART support" > depends on DM_SERIAL Regards, Bin
Re: [RESEND PATCH 1/3] Nokia RX-51: Update documentation about ext2/3/4
On 1/24/22 20:45, Pali Rohár wrote:
Since commit 25c5b6517854 ("Nokia RX-51: Do not try calling both ext2load
and ext4load") command ext4load is used for all ext2/3/4 fs variants.
Signed-off-by: Pali Rohár
Reviewed-by: Heinrich Schuchardt
---
doc/README.nokia_rx51 | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index 7f22ed49bd75..1be077514f03 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -44,8 +44,7 @@ Boot from SD or eMMC in this order:
* 1.2 find uImage on first fat partition
* 1.3 find zImage on first fat partition
* 1.4 same order for 2. - 4. fat partition
- * 2. same as 1. but for ext2/3 partition
- * 3. same as 1. but for ext4 partition
+ * 2. same as 1. but for ext2/3/4 partition
Available additional commands/variables:
@@ -70,7 +69,7 @@ Additional variables for loading files from mmc:
* mmc ${mmcnum} (0 - external, 1 - internal)
* partition number ${mmcpart} (1 - 4)
- * parition type ${mmctype} (fat, ext2, ext4)
+ * partition type ${mmctype} (fat, ext2, ext4; ext2 is just alias for ext4)
Additional variables for booting kernel:
Re: [PATCH 3/3] efi: Drop unnecessary calls to blk_find_device()
On 1/22/22 02:16, Simon Glass wrote:
When we have the block descriptor we can simply access the device. Drop
the unnecessary function call.
Signed-off-by: Simon Glass
---
lib/efi_loader/efi_device_path.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index a838a32b810..f415741d528 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -768,13 +768,8 @@ __maybe_unused static void *dp_fill(void *buf, struct
udevice *dev)
static unsigned dp_part_size(struct blk_desc *desc, int part)
{
unsigned dpsize;
- struct udevice *dev;
- int ret;
+ struct udevice *dev = desc->bdev;
drivers/block/blk_legacy.c still exists but it does not set bdev.
CONFIG_EFI_LOADER does not require CONFIG_BLK.
Are all non-DM block devices eliminated by now?
Best regards
Heinrich
- ret = blk_find_device(desc->if_type, desc->devnum, );
-
- if (ret)
- dev = desc->bdev->parent;
dpsize = dp_size(dev);
if (part == 0) /* the actual disk, not a partition */
@@ -865,13 +860,8 @@ static void *dp_part_node(void *buf, struct blk_desc
*desc, int part)
*/
static void *dp_part_fill(void *buf, struct blk_desc *desc, int part)
{
- struct udevice *dev;
- int ret;
-
- ret = blk_find_device(desc->if_type, desc->devnum, );
+ struct udevice *dev = desc->bdev;
- if (ret)
- dev = desc->bdev->parent;
buf = dp_fill(buf, dev);
if (part == 0) /* the actual disk, not a partition */
Re: [PATCH 2/3] efi: Use device_get_uclass_id() where appropriate
On 1/22/22 02:16, Simon Glass wrote:
Use this function rather than following the pointers, since it is there
for this purpose.
Add the uclass name to the debug call at the end of dp_fill() since it is
quite useful.
Signed-off-by: Simon Glass
---
lib/efi_loader/efi_device_path.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index c61f4859330..a838a32b810 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -494,7 +494,7 @@ __maybe_unused static unsigned int dp_size(struct udevice
*dev)
if (!dev || !dev->driver)
return sizeof(ROOT);
- switch (dev->driver->id) {
+ switch (device_get_uclass_id(dev)) {
case UCLASS_ROOT:
case UCLASS_SIMPLE_BUS:
/* stop traversing parents at this point: */
@@ -579,7 +579,7 @@ __maybe_unused static void *dp_fill(void *buf, struct
udevice *dev)
if (!dev || !dev->driver)
return buf;
- switch (dev->driver->id) {
+ switch (device_get_uclass_id(dev)) {
case UCLASS_ROOT:
case UCLASS_SIMPLE_BUS: {
/* stop traversing parents at this point: */
@@ -759,9 +759,8 @@ __maybe_unused static void *dp_fill(void *buf, struct
udevice *dev)
return [1];
}
default:
- debug("%s(%u) %s: unhandled device class: %s (%u)\n",
- __FILE__, __LINE__, __func__,
- dev->name, dev->driver->id);
+ log_debug("unhandled device class: %s (%u:%s)\n", dev->name,
+ device_get_uclass_id(dev), dev_get_uclass_name(dev));
The uclass id is hidden in enum uclass_id. I can't grep for it. The
uclass name seems enough.
Best regards
Heinrich
return dp_fill(buf, dev->parent);
}
}
Re: [PATCH 1/3] efi: Add debugging to efi_set_bootdev()
On 1/22/22 02:16, Simon Glass wrote:
The operation of this function can be confusing. Add some debugging so
we can see what it is doing and when it is called.
Also drop the preprocessor usage.
Signed-off-by: Simon Glass
---
cmd/bootefi.c | 32 +---
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3a8b2b60618..d8685f0e878 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -65,6 +65,9 @@ void efi_set_bootdev(const char *dev, const char *devnr,
const char *path,
struct efi_device_path *device, *image;
efi_status_t ret;
+ log_debug("dev=%s, devnr=%s, path=%s, buffer=%p, size=%zx\n", dev,
+ devnr, path, buffer, buffer_size);
+
/* Forget overwritten image */
if (buffer + buffer_size >= image_addr &&
image_addr + image_size >= buffer)
@@ -72,18 +75,19 @@ void efi_set_bootdev(const char *dev, const char *devnr,
const char *path,
/* Remember only PE-COFF and FIT images */
if (efi_check_pe(buffer, buffer_size, NULL) != EFI_SUCCESS) {
-#ifdef CONFIG_FIT
- if (fit_check_format(buffer, IMAGE_SIZE_INVAL))
+ if (IS_ENABLED(CONFIG_FIT) &&
+ !fit_check_format(buffer, IMAGE_SIZE_INVAL)) {
This looks ok.
+ /*
+* FIT images of type EFI_OS are started via command
+* bootm. We should not use their boot device with the
+* bootefi command.
+*/
+ buffer = 0;
+ buffer_size = 0;
+ } else {
+ log_debug("- invalid image\n");
This function is called by the 'load' command. When loading a perfectly
valid device-tree or initial RAM disk the message would confuse me.
What is that '- ' good for?
Best regards
Heinrich
return;
- /*
-* FIT images of type EFI_OS are started via command bootm.
-* We should not use their boot device with the bootefi command.
-*/
- buffer = 0;
- buffer_size = 0;
-#else
- return;
-#endif
+ }
}
/* efi_set_bootdev() is typically called repeatedly, recover memory */
@@ -103,7 +107,11 @@ void efi_set_bootdev(const char *dev, const char *devnr,
const char *path,
efi_free_pool(image_tmp);
}
bootefi_image_path = image;
+ log_debug("- recorded device %ls\n", efi_dp_str(device));
+ if (image)
+ log_debug("- and image %ls\n", efi_dp_str(image));
} else {
+ log_debug("- efi_dp_from_name() failed, err=%lx\n", ret);
efi_clear_bootdev();
}
}
@@ -451,6 +459,7 @@ efi_status_t efi_run_image(void *source_buffer, efi_uintn_t
source_size)
u16 *load_options;
if (!bootefi_device_path || !bootefi_image_path) {
+ log_debug("Not loaded from disk\n");
/*
* Special case for efi payload not loaded from disk,
* such as 'bootefi hello' or for example payload
@@ -476,6 +485,7 @@ efi_status_t efi_run_image(void *source_buffer, efi_uintn_t
source_size)
file_path = efi_dp_append(bootefi_device_path,
bootefi_image_path);
msg_path = bootefi_image_path;
+ log_debug("Loaded from disk\n");
}
log_info("Booting %pD\n", msg_path);
Re: [PATCH 5/5] sunxi-common.h: remove pointless #ifdefs
On 1/24/22 7:15 PM, Andre Przywara wrote: > Remove some pointless #ifdefs from this file, as there are quite too > many of them already. > > Some definitions don't really hurt to have in any case, so remove the > pointless CONFIG_MMC guard around CONFIG_MMC_SUNXI_SLOT. > > The BOARD_SIZE_LIMIT applies regardless of ARM64 or not (now), so remove > that guard as well. The maximum number of MMC devices does not depend on > CONFIG_ENV_IS_IN_MMC, so move that out to simplify the file. > > Last but not least CONFIG_SPL_BOARD_LOAD_IMAGE serves no real purpose > anymore: it's unconditionally defined for all sunxi boards, and protects > nothing applicable outside of sunxi code anymore. Just remove it. > > Signed-off-by: Andre Przywara Reviewed-by: Samuel Holland
Re: [PATCH 4/5] armv8: remove no longer needed lowlevel_init.S
On 1/24/22 7:15 PM, Andre Przywara wrote:
> When we added Allwinner SoC support to ARMv8, we needed to pull in an
> implementation of lowlevel_init, as sunxi required it at this time.
>
> The last few patches got rid of this bogus requirement, and as sunxi was
> still the only user, we can now remove lowlevel_init from ARMv8
> altogether.
Well, we are removing lowlevel_init.S anyway. There is still a weak definition
of lowlevel_init in arch/arm/cpu/armv8/start.S, which we are now picking up.
> Signed-off-by: Andre Przywara
Reviewed-by: Samuel Holland
> ---
> arch/arm/cpu/armv8/Makefile| 1 -
> arch/arm/cpu/armv8/lowlevel_init.S | 43 --
> arch/arm/mach-sunxi/board.c| 4 ---
> 3 files changed, 48 deletions(-)
> delete mode 100644 arch/arm/cpu/armv8/lowlevel_init.S
>
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index d85ddde430a..85fe0475c86 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -42,6 +42,5 @@ obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
> obj-$(CONFIG_S32V234) += s32v234/
> obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
> obj-$(CONFIG_ARMV8_PSCI) += psci.o
> -obj-$(CONFIG_ARCH_SUNXI) += lowlevel_init.o
> obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/
> obj-$(CONFIG_XEN) += xen/
> diff --git a/arch/arm/cpu/armv8/lowlevel_init.S
> b/arch/arm/cpu/armv8/lowlevel_init.S
> deleted file mode 100644
> index f4f0cdce9b3..000
> --- a/arch/arm/cpu/armv8/lowlevel_init.S
> +++ /dev/null
> @@ -1,43 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * A lowlevel_init function that sets up the stack to call a C function to
> - * perform further init.
> - */
> -
> -#include
> -#include
> -#include
> -
> -ENTRY(lowlevel_init)
> - /*
> - * Setup a temporary stack. Global data is not available yet.
> - */
> -#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
> - ldr w0, =CONFIG_SPL_STACK
> -#else
> - ldr w0, =CONFIG_SYS_INIT_SP_ADDR
> -#endif
> - bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
> -
> - /*
> - * Save the old LR(passed in x29) and the current LR to stack
> - */
> - stp x29, x30, [sp, #-16]!
> -
> - /*
> - * Call the very early init function. This should do only the
> - * absolute bare minimum to get started. It should not:
> - *
> - * - set up DRAM
> - * - use global_data
> - * - clear BSS
> - * - try to start a console
> - *
> - * For boards with SPL this should be empty since SPL can do all of
> - * this init in the SPL board_init_f() function which is called
> - * immediately after this.
> - */
> - bl s_init
> - ldp x29, x30, [sp]
> - ret
> -ENDPROC(lowlevel_init)
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 42ec02d96e3..a60dc6b299c 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -184,10 +184,6 @@ static int spl_board_load_image(struct spl_image_info
> *spl_image,
> SPL_LOAD_IMAGE_METHOD("FEL", 0, BOOT_DEVICE_BOARD, spl_board_load_image);
> #endif
>
> -void s_init(void)
> -{
> -}
> -
> #define SUNXI_INVALID_BOOT_SOURCE-1
>
> static int sunxi_get_boot_source(void)
>
Re: [PATCH 3/5] sunxi: move early "SRAM setup" into separate file
On 1/24/22 7:15 PM, Andre Przywara wrote:
> Currently we do some magic "SRAM setup" MMIO writes in s_init(), copied
> from the original BSP U-Boot. The comment speaks of this being required
> before DRAM access gets enabled, but there is no indication that this
> would actually be required that early.
>
> Move this out of s_init(), into board_init_f(). Since this actually only
> affects a very few older SoCs, the actual code goes into the cpu/armv7
> directory, to move it out of the way for all other SoCs.
>
> This also uses the opportunity to convert some #ifdefs over to the fancy
> IS_ENABLED() macros used in actual C code.
>
> We keep the s_init() stub around for now, since armv8's lowlevel_init
> still relies on it.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/cpu/armv7/sunxi/Makefile | 3 +++
> arch/arm/cpu/armv7/sunxi/sram.c | 45 +++
> arch/arm/mach-sunxi/board.c | 38 +-
> 3 files changed, 54 insertions(+), 32 deletions(-)
> create mode 100644 arch/arm/cpu/armv7/sunxi/sram.c
>
> diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
> b/arch/arm/cpu/armv7/sunxi/Makefile
> index 1d40d6a18dc..ad11be78632 100644
> --- a/arch/arm/cpu/armv7/sunxi/Makefile
> +++ b/arch/arm/cpu/armv7/sunxi/Makefile
> @@ -10,6 +10,9 @@ obj-y += timer.o
> obj-$(CONFIG_MACH_SUN6I) += tzpc.o
> obj-$(CONFIG_MACH_SUN8I_H3) += tzpc.o
>
> +obj-$(CONFIG_MACH_SUN6I) += sram.o
> +obj-$(CONFIG_MACH_SUN8I) += sram.o
> +
> ifndef CONFIG_SPL_BUILD
> obj-$(CONFIG_ARMV7_PSCI) += psci.o
> endif
> diff --git a/arch/arm/cpu/armv7/sunxi/sram.c b/arch/arm/cpu/armv7/sunxi/sram.c
> new file mode 100644
> index 000..19395cce17c
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/sunxi/sram.c
> @@ -0,0 +1,45 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2012 Henrik Nordstrom
> + *
> + * (C) Copyright 2007-2011
> + * Allwinner Technology Co., Ltd.
> + * Tom Cubie
> + *
> + * SRAM init for older sunxi SoCs.
> + */
> +
> +#include
> +#include
> +#include
> +
> +void sunxi_sram_init(void)
> +{
> + /*
> + * Undocumented magic taken from boot0, without this DRAM
> + * access gets messed up (seems cache related).
> + * The boot0 sources describe this as: "config ema for cache sram"
> + * Newer SoCs (A83T, H3 and anything beyond) don't need this anymore.
> + */
> + if (IS_ENABLED(CONFIG_MACH_SUN6I))
> + setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
> +
> + if (IS_ENABLED(CONFIG_MACH_SUN8I)) {
> + uint version;
> +
> + /* Unlock sram version info reg, read it, relock */
> + setbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
> + version = readl(SUNXI_SRAMC_BASE + 0x24) >> 16;
> + clrbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
This is an open-coded version of sunxi_get_sram_id().
> +
> + if (IS_ENABLED(CONFIG_MACH_SUN8I_A23)) {
> + if (version == 0x1650)
> + setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
> + else /* 0x1661 ? */
> + setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
> + } else if (IS_ENABLED(CONFIG_MACH_SUN8I_A33)) {
> + if (version != 0x1667)
> + setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
> + }
> + }
> +}
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 8667ddf58e3..42ec02d96e3 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -186,38 +186,6 @@ SPL_LOAD_IMAGE_METHOD("FEL", 0, BOOT_DEVICE_BOARD,
> spl_board_load_image);
>
> void s_init(void)
> {
> - /*
> - * Undocumented magic taken from boot0, without this DRAM
> - * access gets messed up (seems cache related).
> - * The boot0 sources describe this as: "config ema for cache sram"
> - */
> -#if defined CONFIG_MACH_SUN6I
> - setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
> -#elif defined CONFIG_MACH_SUN8I
> - __maybe_unused uint version;
> -
> - /* Unlock sram version info reg, read it, relock */
> - setbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
> - version = readl(SUNXI_SRAMC_BASE + 0x24) >> 16;
> - clrbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
> -
> - /*
> - * Ideally this would be a switch case, but we do not know exactly
> - * which versions there are and which version needs which settings,
> - * so reproduce the per SoC code from the BSP.
> - */
> -#if defined CONFIG_MACH_SUN8I_A23
> - if (version == 0x1650)
> - setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
> - else /* 0x1661 ? */
> - setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
> -#elif defined CONFIG_MACH_SUN8I_A33
> - if (version != 0x1667)
> - setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
> -#endif
> - /* A83T BSP never
[PATCH] arm64: dts: imx8mm: Add missing MX8MM_IOMUXC_NAND_READY_B_SD3_RESET_B
The i.MX8M Mini Application Processor Reference Manual, Rev. 3, 11/2020 documents AF MX8MM_IOMUXC_NAND_READY_B_SD3_RESET_B , add it into the pinmux tables. Signed-off-by: Marek Vasut Cc: Fabio Estevam Cc: Stefano Babic --- arch/arm/dts/imx8mm-pinfunc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm-pinfunc.h index a003e6af335..a7411c800be 100644 --- a/arch/arm/dts/imx8mm-pinfunc.h +++ b/arch/arm/dts/imx8mm-pinfunc.h @@ -248,6 +248,7 @@ #define MX8MM_IOMUXC_NAND_RE_B_GPIO3_IO15 0x130 0x398 0x000 0x5 0x0 #define MX8MM_IOMUXC_NAND_RE_B_SIM_M_HADDR11 0x130 0x398 0x000 0x7 0x0 #define MX8MM_IOMUXC_NAND_READY_B_RAWNAND_READY_B 0x134 0x39C 0x000 0x0 0x0 +#define MX8MM_IOMUXC_NAND_READY_B_SD3_RESET_B 0x134 0x39C 0x000 0x2 0x0 #define MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16 0x134 0x39C 0x000 0x5 0x0 #define MX8MM_IOMUXC_NAND_READY_B_SIM_M_HADDR12 0x134 0x39C 0x000 0x7 0x0 #define MX8MM_IOMUXC_NAND_WE_B_RAWNAND_WE_B 0x138 0x3A0 0x000 0x0 0x0 -- 2.34.1
[PATCH] arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0
From: Oliver Stäbler
Fix address of the pad control register
(IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems
to be a typo but it leads to an exception when pinctrl is applied due to
wrong memory address access.
Signed-off-by: Oliver Stäbler
Reviewed-by: Fabio Estevam
Acked-by: Rob Herring
Fixes: c1c9d41319c3 ("dt-bindings: imx: Add pinctrl binding doc for imx8mm")
Fixes: 748f908cc882 ("arm64: add basic DTS for i.MX8MQ")
Signed-off-by: Shawn Guo
Signed-off-by: Marek Vasut # Picked from Linux 5cfad4f45806f
("arm64: dts: imx8mm/q: Fix pad control of SD1_DATA0")
---
arch/arm/dts/imx8mm-pinfunc.h | 2 +-
arch/arm/dts/imx8mq-pinfunc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/imx8mm-pinfunc.h b/arch/arm/dts/imx8mm-pinfunc.h
index 5ccc4cc9195..a003e6af335 100644
--- a/arch/arm/dts/imx8mm-pinfunc.h
+++ b/arch/arm/dts/imx8mm-pinfunc.h
@@ -124,7 +124,7 @@
#define MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD
0x0A4 0x30C 0x000 0x0 0x0
#define MX8MM_IOMUXC_SD1_CMD_GPIO2_IO1
0x0A4 0x30C 0x000 0x5 0x0
#define MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0
0x0A8 0x310 0x000 0x0 0x0
-#define MX8MM_IOMUXC_SD1_DATA0_GPIO2_IO2
0x0A8 0x31 0x000 0x5 0x0
+#define MX8MM_IOMUXC_SD1_DATA0_GPIO2_IO2
0x0A8 0x310 0x000 0x5 0x0
#define MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1
0x0AC 0x314 0x000 0x0 0x0
#define MX8MM_IOMUXC_SD1_DATA1_GPIO2_IO3
0x0AC 0x314 0x000 0x5 0x0
#define MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2
0x0B0 0x318 0x000 0x0 0x0
diff --git a/arch/arm/dts/imx8mq-pinfunc.h b/arch/arm/dts/imx8mq-pinfunc.h
index b94b02080a3..68e8fa17297 100644
--- a/arch/arm/dts/imx8mq-pinfunc.h
+++ b/arch/arm/dts/imx8mq-pinfunc.h
@@ -130,7 +130,7 @@
#define MX8MQ_IOMUXC_SD1_CMD_USDHC1_CMD
0x0A4 0x30C 0x000 0x0 0x0
#define MX8MQ_IOMUXC_SD1_CMD_GPIO2_IO1
0x0A4 0x30C 0x000 0x5 0x0
#define MX8MQ_IOMUXC_SD1_DATA0_USDHC1_DATA0
0x0A8 0x310 0x000 0x0 0x0
-#define MX8MQ_IOMUXC_SD1_DATA0_GPIO2_IO2
0x0A8 0x31 0x000 0x5 0x0
+#define MX8MQ_IOMUXC_SD1_DATA0_GPIO2_IO2
0x0A8 0x310 0x000 0x5 0x0
#define MX8MQ_IOMUXC_SD1_DATA1_USDHC1_DATA1
0x0AC 0x314 0x000 0x0 0x0
#define MX8MQ_IOMUXC_SD1_DATA1_GPIO2_IO3
0x0AC 0x314 0x000 0x5 0x0
#define MX8MQ_IOMUXC_SD1_DATA2_USDHC1_DATA2
0x0B0 0x318 0x000 0x0 0x0
--
2.34.1
[PATCH 2/2] ARM: imx: imx8m: Add PLL 1.4 GHz, 1.5 GHz, 1.6 GHz, 1.8 GHz options
Add PLL 1.4 GHz, 1.5 GHz, 1.6 GHz, 1.8 GHz options for iMX8M SoCs in case they should be operated faster, e.g. to improve boot time. Signed-off-by: Marek Vasut Cc: Peng Fan Cc: Stefano Babic --- arch/arm/mach-imx/imx8m/clock_imx8mm.c | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c index 2ca3bf68e74..76132defc21 100644 --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c @@ -248,6 +248,26 @@ int intpll_configure(enum pll_clocks pll, ulong freq) pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0x12c) | INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(1); break; + case MHZ(1400): + /* 24 * 0x15e / 3 / 2 ^ 1 */ + pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0x15e) | + INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(1); + break; + case MHZ(1500): + /* 24 * 0x177 / 3 / 2 ^ 1 */ + pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0x177) | + INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(1); + break; + case MHZ(1600): + /* 24 * 0xc8 / 3 / 2 ^ 0 */ + pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0xc8) | + INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(0); + break; + case MHZ(1800): + /* 24 * 0xe1 / 3 / 2 ^ 0 */ + pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0xe1) | + INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(0); + break; case MHZ(2000): /* 24 * 0xfa / 3 / 2 ^ 0 */ pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0xfa) | -- 2.34.1
[PATCH 1/2] ARM: imx: imx8m: Align PLL 1.2 GHz option with Linux
Linux uses slightly different divider settings for the 1.2 GHz PLL configuration, adjust the coefficients to match Linux. Signed-off-by: Marek Vasut Cc: Peng Fan Cc: Stefano Babic --- arch/arm/mach-imx/imx8m/clock_imx8mm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c b/arch/arm/mach-imx/imx8m/clock_imx8mm.c index f8e4ec0d905..2ca3bf68e74 100644 --- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c +++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c @@ -244,9 +244,9 @@ int intpll_configure(enum pll_clocks pll, ulong freq) INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(1); break; case MHZ(1200): - /* 24 * 0xc8 / 2 / 2 ^ 1 */ - pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0xc8) | - INTPLL_PRE_DIV_VAL(2) | INTPLL_POST_DIV_VAL(1); + /* 24 * 0x12c / 3 / 2 ^ 1 */ + pll_div_ctl_val = INTPLL_MAIN_DIV_VAL(0x12c) | + INTPLL_PRE_DIV_VAL(3) | INTPLL_POST_DIV_VAL(1); break; case MHZ(2000): /* 24 * 0xfa / 3 / 2 ^ 0 */ -- 2.34.1
Re: [PATCH 2/5] sunxi: move Cortex SMPEN setting into start.S
On 1/24/22 7:15 PM, Andre Przywara wrote: > According to their TRMs, Cortex ARMv7 CPUs with SMP support require the > ACTLR.SMPEN bit to be set as early as possible, before any cache or TLB > maintenance operations are done. As we do those things still in start.S, > we need to move the SMPEN bit setting there, too. > > This introduces a new ARMv7 wide symbol and code to set bit 6 in ACTLR > very early in start.S, and moves sunxi boards over to use that instead > of the custom code we had in our board.c file (where it was called > technically too late). > > In practice we got away with this so far, because at this point all the > other cores were still in reset, so any broadcasting would have been > ignored anyway. But it is architecturally cleaner to do it early, and > we move a core specific piece of code out of board.c. > > This also gets rid of the ARM_CORTEX_CPU_IS_UP kludge I introduced a few > years back, and moves the respective logic into the new Kconfig entry. > > Signed-off-by: Andre Przywara > --- > arch/arm/Kconfig| 3 --- > arch/arm/cpu/armv7/Kconfig | 7 +++ > arch/arm/cpu/armv7/start.S | 11 +++ > arch/arm/mach-sunxi/Kconfig | 2 -- > arch/arm/mach-sunxi/board.c | 9 - > 5 files changed, 18 insertions(+), 14 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 6b11c3a50d9..7893d74fab2 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -452,9 +452,6 @@ config ENABLE_ARM_SOC_BOOT0_HOOK > values, then choose this option, and create a file included as > which contains the required assembler code. > > -config ARM_CORTEX_CPU_IS_UP > - bool > - > config USE_ARCH_MEMCPY > bool "Use an assembly optimized implementation of memcpy" > default y if !ARM64 > diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig > index 60bb0a9e1ec..85e5229a060 100644 > --- a/arch/arm/cpu/armv7/Kconfig > +++ b/arch/arm/cpu/armv7/Kconfig > @@ -76,4 +76,11 @@ config ARMV7_LPAE > Say Y here to use the long descriptor page table format. This is > required if U-Boot runs in HYP mode. > > +config ARMV7_SET_CORTEX_SMPEN > + bool "Enable ACTLR.SMP bit" > + default n if MACH_SUN4I || MACH_SUN5I > + default y if ARCH_SUNXI && !ARM64 If this is required by the CPU, why is it shown to the user? Shouldn't it be selected by MACH_SUN6/7/8/9I? That is what I see platforms doing with ARMV8_SET_SMPEN. > + help > + Enable the ARM Cortex ACTLR.SMP enable bit on startup. > + > endif > diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S > index 698e15b8e18..af87a5432ae 100644 > --- a/arch/arm/cpu/armv7/start.S > +++ b/arch/arm/cpu/armv7/start.S > @@ -173,6 +173,17 @@ ENDPROC(switch_to_hypervisor) > * > */ > ENTRY(cpu_init_cp15) > + > +#if CONFIG_IS_ENABLED(ARMV7_SET_CORTEX_SMPEN) > + /* > + * The Arm Cortex-A7 TRM says this bit must be enabled before > + * "any cache or TLB maintenance operations are performed". > + */ > + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register > + orr r0, r0, #1 << 6 @ set SMP bit to enable coherency > + mcr p15, 0, r0, c1, c0, 1 @ write auxilary control register > +#endif > + > /* >* Invalidate L1 I/D >*/ > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig > index 2c18cf02d1a..4e49ad4f0c0 100644 > --- a/arch/arm/mach-sunxi/Kconfig > +++ b/arch/arm/mach-sunxi/Kconfig > @@ -186,7 +186,6 @@ choice > config MACH_SUN4I > bool "sun4i (Allwinner A10)" > select CPU_V7A > - select ARM_CORTEX_CPU_IS_UP > select PHY_SUN4I_USB > select DRAM_SUN4I > select SUNXI_GEN_SUN4I > @@ -197,7 +196,6 @@ config MACH_SUN4I > config MACH_SUN5I > bool "sun5i (Allwinner A13)" > select CPU_V7A > - select ARM_CORTEX_CPU_IS_UP > select DRAM_SUN4I > select PHY_SUN4I_USB > select SUNXI_GEN_SUN4I > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c > index 390c9f8850d..8667ddf58e3 100644 > --- a/arch/arm/mach-sunxi/board.c > +++ b/arch/arm/mach-sunxi/board.c > @@ -218,15 +218,6 @@ void s_init(void) > /* A83T BSP never modifies SUNXI_SRAMC_BASE + 0x44 */ > /* No H3 BSP, boot0 seems to not modify SUNXI_SRAMC_BASE + 0x44 */ > #endif > - > -#if !defined(CONFIG_ARM_CORTEX_CPU_IS_UP) && !defined(CONFIG_ARM64) > - /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */ > - asm volatile( > - "mrc p15, 0, r0, c1, c0, 1\n" > - "orr r0, r0, #1 << 6\n" > - "mcr p15, 0, r0, c1, c0, 1\n" > - ::: "r0"); > -#endif > } > > #define SUNXI_INVALID_BOOT_SOURCE-1 >
[PATCH] regulator: bd718x7: Bypass bogus warnings
When regulator consumer attempts to set enabled DVS regulator voltage,
the driver aborts with "Only DVS bucks can be changed when enabled".
In case the regulator is already set to specified voltage, do nothing
instead of failing outright.
When regulator consumer attempts to set enables regulator which cannot
be controlled because it is already always enabled, the driver aborts
with -EINVAL. Again, do nothing in such case and return 0, because the
request is really fulfilled, the regulator is enabled.
Signed-off-by: Marek Vasut
Cc: Matti Vaittinen
---
drivers/power/regulator/bd71837.c | 69 ---
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/power/regulator/bd71837.c
b/drivers/power/regulator/bd71837.c
index 74011d62985..d4f8da80ad7 100644
--- a/drivers/power/regulator/bd71837.c
+++ b/drivers/power/regulator/bd71837.c
@@ -306,7 +306,7 @@ static int bd71837_set_enable(struct udevice *dev, bool
enable)
* reseted to snvs state. Hence we can't set the state here.
*/
if (plat->enablemask == HW_STATE_CONTROL)
- return -EINVAL;
+ return enable ? 0 : -EINVAL;
if (enable)
val = plat->enablemask;
@@ -315,6 +315,38 @@ static int bd71837_set_enable(struct udevice *dev, bool
enable)
val);
}
+static int bd71837_get_value(struct udevice *dev)
+{
+ unsigned int reg, range;
+ unsigned int tmp;
+ struct bd71837_plat *plat = dev_get_plat(dev);
+ int i;
+
+ reg = pmic_reg_read(dev->parent, plat->volt_reg);
+ if (((int)reg) < 0)
+ return reg;
+
+ range = reg & plat->rangemask;
+
+ reg &= plat->volt_mask;
+ reg >>= ffs(plat->volt_mask) - 1;
+
+ for (i = 0; i < plat->numranges; i++) {
+ struct bd71837_vrange *r = >ranges[i];
+
+ if (plat->rangemask && ((plat->rangemask & range) !=
+ r->rangeval))
+ continue;
+
+ if (!vrange_find_value(r, reg, ))
+ return tmp;
+ }
+
+ pr_err("Unknown voltage value read from pmic\n");
+
+ return -EINVAL;
+}
+
static int bd71837_set_value(struct udevice *dev, int uvolt)
{
unsigned int sel;
@@ -330,6 +362,9 @@ static int bd71837_set_value(struct udevice *dev, int uvolt)
*/
if (!plat->dvs)
if (bd71837_get_enable(dev)) {
+ /* If the value is already set, skip the warning. */
+ if (bd71837_get_value(dev) == uvolt)
+ return 0;
pr_err("Only DVS bucks can be changed when enabled\n");
return -EINVAL;
}
@@ -365,38 +400,6 @@ static int bd71837_set_value(struct udevice *dev, int
uvolt)
plat->rangemask, sel);
}
-static int bd71837_get_value(struct udevice *dev)
-{
- unsigned int reg, range;
- unsigned int tmp;
- struct bd71837_plat *plat = dev_get_plat(dev);
- int i;
-
- reg = pmic_reg_read(dev->parent, plat->volt_reg);
- if (((int)reg) < 0)
- return reg;
-
- range = reg & plat->rangemask;
-
- reg &= plat->volt_mask;
- reg >>= ffs(plat->volt_mask) - 1;
-
- for (i = 0; i < plat->numranges; i++) {
- struct bd71837_vrange *r = >ranges[i];
-
- if (plat->rangemask && ((plat->rangemask & range) !=
- r->rangeval))
- continue;
-
- if (!vrange_find_value(r, reg, ))
- return tmp;
- }
-
- pr_err("Unknown voltage value read from pmic\n");
-
- return -EINVAL;
-}
-
static int bd71837_regulator_probe(struct udevice *dev)
{
struct bd71837_plat *plat = dev_get_plat(dev);
--
2.34.1
Re: [PATCH 1/5] sunxi: move non-essential code out of s_init()
On 1/24/22 7:15 PM, Andre Przywara wrote:
> So far all Allwinner based boards were doing some not-so-lowlevel-setup
> in lowlevel's s_init() routine.
> This includes the initial clock, timer and pinmux setup, among other
> things. This is clearly out of the "absolute bare minimum to get started"
> scope that lowlevel_init.S suggests for this function.
>
> Since we have an SPL, which is called right after s_init(), move those
> calls to our board_init_f() function. As we overwrite this only for
> the SPL, this has the added benefit of not doing this setup *again*
> shortly afterwards, when running U-Boot proper.
>
> This makes gpio_init() to be called from the SPL only, so pull this code
> into a CONFIG_SPL_BUILD protected part to avoid build warnings.
>
> Signed-off-by: Andre Przywara
Reviewed-by: Samuel Holland
> ---
> arch/arm/mach-sunxi/board.c | 27 ++-
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index 3ef179742c5..390c9f8850d 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -75,6 +75,7 @@ ulong board_get_usable_ram_top(ulong total_size)
> }
> #endif
>
> +#ifdef CONFIG_SPL_BUILD
> static int gpio_init(void)
> {
> __maybe_unused uint val;
> @@ -172,7 +173,6 @@ static int gpio_init(void)
> return 0;
> }
>
> -#if defined(CONFIG_SPL_BOARD_LOAD_IMAGE) && defined(CONFIG_SPL_BUILD)
As far as I can tell, this is the _only_ place that checks
CONFIG_SPL_BOARD_LOAD_IMAGE, so that definition could be removed from everywhere
now.
> static int spl_board_load_image(struct spl_image_info *spl_image,
> struct spl_boot_device *bootdev)
> {
> @@ -227,18 +227,6 @@ void s_init(void)
> "mcr p15, 0, r0, c1, c0, 1\n"
> ::: "r0");
> #endif
> -#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
> - /* Enable non-secure access to some peripherals */
> - tzpc_init();
> -#endif
> -
> - clock_init();
> - timer_init();
> - gpio_init();
> -#if !CONFIG_IS_ENABLED(DM_I2C)
> - i2c_init_board();
> -#endif
> - eth_init_board();
> }
>
> #define SUNXI_INVALID_BOOT_SOURCE-1
> @@ -335,6 +323,19 @@ u32 spl_boot_device(void)
>
> void board_init_f(ulong dummy)
> {
> +#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
> + /* Enable non-secure access to some peripherals */
> + tzpc_init();
> +#endif
> +
> + clock_init();
> + timer_init();
> + gpio_init();
> +#if !CONFIG_IS_ENABLED(DM_I2C)
> + i2c_init_board();
You could move this down a few lines, near the call to i2c_init, inside the
existing #if.
> +#endif
> + eth_init_board();
> +
> spl_init();
> preloader_console_init();
>
>
Re: [RFC PATCH] efi_loader: clean up uefi secure boot image verification logic
Hi Ilias,
On Mon, Jan 24, 2022 at 05:36:20PM +0200, Ilias Apalodimas wrote:
> From: Ilias Apalodimas
>
> We currently distinguish between signed and non signed PE/COFF
> executables while trying to authenticate signatures and/or sha256
> hashes in db and dbx. That code duplication can be avoided.
Thank you for cleaning up the code.
The change you made here looks good.
I want you to revise some wordings for clarification.
> On sha256 hashes we don't really care if the image is signed or
> not.
The sentence above might sound a bit misleading?
> The logic can be implemented in
> 1. Is the sha256 of the image in dbx
Please explicitly mention that the image will be rejected
in this case unlike the other cases below.
> 2. Is the image signed with a certificate that's found in db and
> not in dbx
> 3. The image carries a cert which is signed by a cert in db (and
> not in dbx, and the image can be verified against the former)
(2) and (3) are the rules applied only if the image is signed. So,
2. If the image is signed,
2-1. ...
2-2. ...
In addition, your (3) should be described in a similar way as (2).
For instance,
3. Is the image signed with a certificate that is carried in
the image and the cert is signed by another cert in the image
and so on, or in db (... ).
(although it is difficult to describe the logic precisely.)
> 4. Is the sha256 of the image in db
> So weed out the 'special' case handling unsigned images.
>
> While at it move the checking of a hash outside the certificate
> verification loop which isn't really needed and check for the hash
> only once.
It might be my preference, but I would like to add
assert(ret == false);
before efi_signature_lookup_digest(regs, db) to indicate this is the last
resort to authenticate the image.
> Also allow a mix of signatures and hashes in db instead
> of explicitly breaking out the sha verification loop if a signature
> happens to be added first.
I don't think that your change gives us an extra case of "allowing".
Please elaborate if I misunderstand something.
> It's worth noting that (2) only works if the certificate is self
> signed, but that canb be fixed in a following patch.
Yes, please.
-Takahiro Akashi
> Signed-off-by: Ilias Apalodimas
> ---
> lib/efi_loader/efi_image_loader.c | 84 ++-
> lib/efi_loader/efi_signature.c| 2 +-
> 2 files changed, 15 insertions(+), 71 deletions(-)
>
> diff --git a/lib/efi_loader/efi_image_loader.c
> b/lib/efi_loader/efi_image_loader.c
> index 255613eb72ba..53d54ca42f5c 100644
> --- a/lib/efi_loader/efi_image_loader.c
> +++ b/lib/efi_loader/efi_image_loader.c
> @@ -516,63 +516,16 @@ err:
> }
>
> #ifdef CONFIG_EFI_SECURE_BOOT
> -/**
> - * efi_image_unsigned_authenticate() - authenticate unsigned image with
> - * SHA256 hash
> - * @regs:List of regions to be verified
> - *
> - * If an image is not signed, it doesn't have a signature. In this case,
> - * its message digest is calculated and it will be compared with one of
> - * hash values stored in signature databases.
> - *
> - * Return: true if authenticated, false if not
> - */
> -static bool efi_image_unsigned_authenticate(struct efi_image_regions *regs)
> -{
> - struct efi_signature_store *db = NULL, *dbx = NULL;
> - bool ret = false;
> -
> - dbx = efi_sigstore_parse_sigdb(L"dbx");
> - if (!dbx) {
> - EFI_PRINT("Getting signature database(dbx) failed\n");
> - goto out;
> - }
> -
> - db = efi_sigstore_parse_sigdb(L"db");
> - if (!db) {
> - EFI_PRINT("Getting signature database(db) failed\n");
> - goto out;
> - }
> -
> - /* try black-list first */
> - if (efi_signature_lookup_digest(regs, dbx)) {
> - EFI_PRINT("Image is not signed and its digest found in
> \"dbx\"\n");
> - goto out;
> - }
> -
> - /* try white-list */
> - if (efi_signature_lookup_digest(regs, db))
> - ret = true;
> - else
> - EFI_PRINT("Image is not signed and its digest not found in
> \"db\" or \"dbx\"\n");
> -
> -out:
> - efi_sigstore_free(db);
> - efi_sigstore_free(dbx);
> -
> - return ret;
> -}
> -
> /**
> * efi_image_authenticate() - verify a signature of signed image
> * @efi: Pointer to image
> * @efi_size:Size of @efi
> *
> - * A signed image should have its signature stored in a table of its PE
> header.
> + * An image should have its signature stored in a table of its PE header.
> * So if an image is signed and only if if its signature is verified using
> - * signature databases, an image is authenticated.
> - * If an image is not signed, its validity is checked by using
> - * efi_image_unsigned_authenticated().
> + * signature databases or if it's sha256 is found in db an image is
> + * authenticated.
> + *
> * TODO:
> * When AuditMode==0, if the image's signature is not found in
> * the
Re: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR
> From: Anup Patel
> Sent: Saturday, January 15, 2022 12:20 AM
> To: Rick Jian-Zhi Chen(陳建志) ; Bin Meng
>
> Cc: Atish Patra ; Alistair Francis
> ; Anup Patel ; U-Boot Mailing
> List ; Anup Patel
> Subject: [PATCH 3/3] riscv: qemu: Implement is_flash_available() for MTD NOR
>
> Currently, if MTD NOR is enabled then U-Boot tries to issue flash commands
> even when CFI flash DT node is not present. This causes access fault on
> RISC-V emulators or ISS which do not emulate CFI flash. To handle this issue,
> we implement is_flash_available() for qemu-riscv board which will return 1
> only if CFI flash DT node is present.
>
> Fixes: d248627f9d42 ("riscv: qemu: Enable MTD NOR flash support")
> Signed-off-by: Anup Patel
> ---
> board/emulation/qemu-riscv/qemu-riscv.c | 17 +
> 1 file changed, 17 insertions(+)
Reviewed-by: Rick Chen
Re: [PATCH 2/3] riscv: qemu: Enable HTIF console support
> From: Anup Patel > Sent: Saturday, January 15, 2022 12:20 AM > To: Rick Jian-Zhi Chen(陳建志) ; Bin Meng > > Cc: Atish Patra ; Alistair Francis > ; Anup Patel ; U-Boot Mailing > List ; Anup Patel ; Philipp > Tomsich > Subject: [PATCH 2/3] riscv: qemu: Enable HTIF console support > > Enable support for HTIF console so that we can use QEMU RISC-V U-Boot on > RISC-V emulators and ISS having it. > > Signed-off-by: Anup Patel > Reviewed-by: Philipp Tomsich > --- > board/emulation/qemu-riscv/Kconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rick Chen
[PATCH 5/5] sunxi-common.h: remove pointless #ifdefs
Remove some pointless #ifdefs from this file, as there are quite too many of them already. Some definitions don't really hurt to have in any case, so remove the pointless CONFIG_MMC guard around CONFIG_MMC_SUNXI_SLOT. The BOARD_SIZE_LIMIT applies regardless of ARM64 or not (now), so remove that guard as well. The maximum number of MMC devices does not depend on CONFIG_ENV_IS_IN_MMC, so move that out to simplify the file. Last but not least CONFIG_SPL_BOARD_LOAD_IMAGE serves no real purpose anymore: it's unconditionally defined for all sunxi boards, and protects nothing applicable outside of sunxi code anymore. Just remove it. Signed-off-by: Andre Przywara --- include/configs/sunxi-common.h | 7 --- 1 file changed, 7 deletions(-) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 7260eb72a40..01c3cfced20 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -93,13 +93,9 @@ #endif /* mmc config */ -#ifdef CONFIG_MMC #define CONFIG_MMC_SUNXI_SLOT 0 -#endif #if defined(CONFIG_ENV_IS_IN_MMC) - -#ifdef CONFIG_ARM64 /* * This is actually (CONFIG_ENV_OFFSET - * (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)), but the value will be used @@ -109,7 +105,6 @@ #endif #define CONFIG_SYS_MMC_MAX_DEVICE 4 -#endif /* * Miscellaneous configurable options @@ -124,8 +119,6 @@ #define CONFIG_SYS_MONITOR_LEN (768 << 10) /* 768 KiB */ -#define CONFIG_SPL_BOARD_LOAD_IMAGE - /* * We cannot use expressions here, because expressions won't be evaluated in * autoconf.mk. -- 2.17.6
[PATCH 4/5] armv8: remove no longer needed lowlevel_init.S
When we added Allwinner SoC support to ARMv8, we needed to pull in an
implementation of lowlevel_init, as sunxi required it at this time.
The last few patches got rid of this bogus requirement, and as sunxi was
still the only user, we can now remove lowlevel_init from ARMv8
altogether.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv8/Makefile| 1 -
arch/arm/cpu/armv8/lowlevel_init.S | 43 --
arch/arm/mach-sunxi/board.c| 4 ---
3 files changed, 48 deletions(-)
delete mode 100644 arch/arm/cpu/armv8/lowlevel_init.S
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index d85ddde430a..85fe0475c86 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -42,6 +42,5 @@ obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
obj-$(CONFIG_S32V234) += s32v234/
obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
obj-$(CONFIG_ARMV8_PSCI) += psci.o
-obj-$(CONFIG_ARCH_SUNXI) += lowlevel_init.o
obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/
obj-$(CONFIG_XEN) += xen/
diff --git a/arch/arm/cpu/armv8/lowlevel_init.S
b/arch/arm/cpu/armv8/lowlevel_init.S
deleted file mode 100644
index f4f0cdce9b3..000
--- a/arch/arm/cpu/armv8/lowlevel_init.S
+++ /dev/null
@@ -1,43 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * A lowlevel_init function that sets up the stack to call a C function to
- * perform further init.
- */
-
-#include
-#include
-#include
-
-ENTRY(lowlevel_init)
- /*
-* Setup a temporary stack. Global data is not available yet.
-*/
-#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
- ldr w0, =CONFIG_SPL_STACK
-#else
- ldr w0, =CONFIG_SYS_INIT_SP_ADDR
-#endif
- bic sp, x0, #0xf/* 16-byte alignment for ABI compliance */
-
- /*
-* Save the old LR(passed in x29) and the current LR to stack
-*/
- stp x29, x30, [sp, #-16]!
-
- /*
-* Call the very early init function. This should do only the
-* absolute bare minimum to get started. It should not:
-*
-* - set up DRAM
-* - use global_data
-* - clear BSS
-* - try to start a console
-*
-* For boards with SPL this should be empty since SPL can do all of
-* this init in the SPL board_init_f() function which is called
-* immediately after this.
-*/
- bl s_init
- ldp x29, x30, [sp]
- ret
-ENDPROC(lowlevel_init)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 42ec02d96e3..a60dc6b299c 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -184,10 +184,6 @@ static int spl_board_load_image(struct spl_image_info
*spl_image,
SPL_LOAD_IMAGE_METHOD("FEL", 0, BOOT_DEVICE_BOARD, spl_board_load_image);
#endif
-void s_init(void)
-{
-}
-
#define SUNXI_INVALID_BOOT_SOURCE -1
static int sunxi_get_boot_source(void)
--
2.17.6
[PATCH 3/5] sunxi: move early "SRAM setup" into separate file
Currently we do some magic "SRAM setup" MMIO writes in s_init(), copied
from the original BSP U-Boot. The comment speaks of this being required
before DRAM access gets enabled, but there is no indication that this
would actually be required that early.
Move this out of s_init(), into board_init_f(). Since this actually only
affects a very few older SoCs, the actual code goes into the cpu/armv7
directory, to move it out of the way for all other SoCs.
This also uses the opportunity to convert some #ifdefs over to the fancy
IS_ENABLED() macros used in actual C code.
We keep the s_init() stub around for now, since armv8's lowlevel_init
still relies on it.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv7/sunxi/Makefile | 3 +++
arch/arm/cpu/armv7/sunxi/sram.c | 45 +++
arch/arm/mach-sunxi/board.c | 38 +-
3 files changed, 54 insertions(+), 32 deletions(-)
create mode 100644 arch/arm/cpu/armv7/sunxi/sram.c
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index 1d40d6a18dc..ad11be78632 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -10,6 +10,9 @@ obj-y += timer.o
obj-$(CONFIG_MACH_SUN6I) += tzpc.o
obj-$(CONFIG_MACH_SUN8I_H3)+= tzpc.o
+obj-$(CONFIG_MACH_SUN6I) += sram.o
+obj-$(CONFIG_MACH_SUN8I) += sram.o
+
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_ARMV7_PSCI) += psci.o
endif
diff --git a/arch/arm/cpu/armv7/sunxi/sram.c b/arch/arm/cpu/armv7/sunxi/sram.c
new file mode 100644
index 000..19395cce17c
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/sram.c
@@ -0,0 +1,45 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2012 Henrik Nordstrom
+ *
+ * (C) Copyright 2007-2011
+ * Allwinner Technology Co., Ltd.
+ * Tom Cubie
+ *
+ * SRAM init for older sunxi SoCs.
+ */
+
+#include
+#include
+#include
+
+void sunxi_sram_init(void)
+{
+ /*
+* Undocumented magic taken from boot0, without this DRAM
+* access gets messed up (seems cache related).
+* The boot0 sources describe this as: "config ema for cache sram"
+* Newer SoCs (A83T, H3 and anything beyond) don't need this anymore.
+*/
+ if (IS_ENABLED(CONFIG_MACH_SUN6I))
+ setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
+
+ if (IS_ENABLED(CONFIG_MACH_SUN8I)) {
+ uint version;
+
+ /* Unlock sram version info reg, read it, relock */
+ setbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
+ version = readl(SUNXI_SRAMC_BASE + 0x24) >> 16;
+ clrbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
+
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_A23)) {
+ if (version == 0x1650)
+ setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
+ else /* 0x1661 ? */
+ setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
+ } else if (IS_ENABLED(CONFIG_MACH_SUN8I_A33)) {
+ if (version != 0x1667)
+ setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
+ }
+ }
+}
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 8667ddf58e3..42ec02d96e3 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -186,38 +186,6 @@ SPL_LOAD_IMAGE_METHOD("FEL", 0, BOOT_DEVICE_BOARD,
spl_board_load_image);
void s_init(void)
{
- /*
-* Undocumented magic taken from boot0, without this DRAM
-* access gets messed up (seems cache related).
-* The boot0 sources describe this as: "config ema for cache sram"
-*/
-#if defined CONFIG_MACH_SUN6I
- setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
-#elif defined CONFIG_MACH_SUN8I
- __maybe_unused uint version;
-
- /* Unlock sram version info reg, read it, relock */
- setbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
- version = readl(SUNXI_SRAMC_BASE + 0x24) >> 16;
- clrbits_le32(SUNXI_SRAMC_BASE + 0x24, (1 << 15));
-
- /*
-* Ideally this would be a switch case, but we do not know exactly
-* which versions there are and which version needs which settings,
-* so reproduce the per SoC code from the BSP.
-*/
-#if defined CONFIG_MACH_SUN8I_A23
- if (version == 0x1650)
- setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0x1800);
- else /* 0x1661 ? */
- setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
-#elif defined CONFIG_MACH_SUN8I_A33
- if (version != 0x1667)
- setbits_le32(SUNXI_SRAMC_BASE + 0x44, 0xc0);
-#endif
- /* A83T BSP never modifies SUNXI_SRAMC_BASE + 0x44 */
- /* No H3 BSP, boot0 seems to not modify SUNXI_SRAMC_BASE + 0x44 */
-#endif
}
#define SUNXI_INVALID_BOOT_SOURCE -1
@@ -312,8 +280,14 @@ u32 spl_boot_device(void)
return sunxi_get_boot_device();
}
[PATCH 2/5] sunxi: move Cortex SMPEN setting into start.S
According to their TRMs, Cortex ARMv7 CPUs with SMP support require the ACTLR.SMPEN bit to be set as early as possible, before any cache or TLB maintenance operations are done. As we do those things still in start.S, we need to move the SMPEN bit setting there, too. This introduces a new ARMv7 wide symbol and code to set bit 6 in ACTLR very early in start.S, and moves sunxi boards over to use that instead of the custom code we had in our board.c file (where it was called technically too late). In practice we got away with this so far, because at this point all the other cores were still in reset, so any broadcasting would have been ignored anyway. But it is architecturally cleaner to do it early, and we move a core specific piece of code out of board.c. This also gets rid of the ARM_CORTEX_CPU_IS_UP kludge I introduced a few years back, and moves the respective logic into the new Kconfig entry. Signed-off-by: Andre Przywara --- arch/arm/Kconfig| 3 --- arch/arm/cpu/armv7/Kconfig | 7 +++ arch/arm/cpu/armv7/start.S | 11 +++ arch/arm/mach-sunxi/Kconfig | 2 -- arch/arm/mach-sunxi/board.c | 9 - 5 files changed, 18 insertions(+), 14 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 6b11c3a50d9..7893d74fab2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -452,9 +452,6 @@ config ENABLE_ARM_SOC_BOOT0_HOOK values, then choose this option, and create a file included as which contains the required assembler code. -config ARM_CORTEX_CPU_IS_UP - bool - config USE_ARCH_MEMCPY bool "Use an assembly optimized implementation of memcpy" default y if !ARM64 diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig index 60bb0a9e1ec..85e5229a060 100644 --- a/arch/arm/cpu/armv7/Kconfig +++ b/arch/arm/cpu/armv7/Kconfig @@ -76,4 +76,11 @@ config ARMV7_LPAE Say Y here to use the long descriptor page table format. This is required if U-Boot runs in HYP mode. +config ARMV7_SET_CORTEX_SMPEN + bool "Enable ACTLR.SMP bit" + default n if MACH_SUN4I || MACH_SUN5I + default y if ARCH_SUNXI && !ARM64 + help + Enable the ARM Cortex ACTLR.SMP enable bit on startup. + endif diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 698e15b8e18..af87a5432ae 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -173,6 +173,17 @@ ENDPROC(switch_to_hypervisor) * */ ENTRY(cpu_init_cp15) + +#if CONFIG_IS_ENABLED(ARMV7_SET_CORTEX_SMPEN) + /* +* The Arm Cortex-A7 TRM says this bit must be enabled before +* "any cache or TLB maintenance operations are performed". +*/ + mrc p15, 0, r0, c1, c0, 1 @ read auxilary control register + orr r0, r0, #1 << 6 @ set SMP bit to enable coherency + mcr p15, 0, r0, c1, c0, 1 @ write auxilary control register +#endif + /* * Invalidate L1 I/D */ diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 2c18cf02d1a..4e49ad4f0c0 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -186,7 +186,6 @@ choice config MACH_SUN4I bool "sun4i (Allwinner A10)" select CPU_V7A - select ARM_CORTEX_CPU_IS_UP select PHY_SUN4I_USB select DRAM_SUN4I select SUNXI_GEN_SUN4I @@ -197,7 +196,6 @@ config MACH_SUN4I config MACH_SUN5I bool "sun5i (Allwinner A13)" select CPU_V7A - select ARM_CORTEX_CPU_IS_UP select DRAM_SUN4I select PHY_SUN4I_USB select SUNXI_GEN_SUN4I diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 390c9f8850d..8667ddf58e3 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -218,15 +218,6 @@ void s_init(void) /* A83T BSP never modifies SUNXI_SRAMC_BASE + 0x44 */ /* No H3 BSP, boot0 seems to not modify SUNXI_SRAMC_BASE + 0x44 */ #endif - -#if !defined(CONFIG_ARM_CORTEX_CPU_IS_UP) && !defined(CONFIG_ARM64) - /* Enable SMP mode for CPU0, by setting bit 6 of Auxiliary Ctl reg */ - asm volatile( - "mrc p15, 0, r0, c1, c0, 1\n" - "orr r0, r0, #1 << 6\n" - "mcr p15, 0, r0, c1, c0, 1\n" - ::: "r0"); -#endif } #define SUNXI_INVALID_BOOT_SOURCE -1 -- 2.17.6
[PATCH 1/5] sunxi: move non-essential code out of s_init()
So far all Allwinner based boards were doing some not-so-lowlevel-setup
in lowlevel's s_init() routine.
This includes the initial clock, timer and pinmux setup, among other
things. This is clearly out of the "absolute bare minimum to get started"
scope that lowlevel_init.S suggests for this function.
Since we have an SPL, which is called right after s_init(), move those
calls to our board_init_f() function. As we overwrite this only for
the SPL, this has the added benefit of not doing this setup *again*
shortly afterwards, when running U-Boot proper.
This makes gpio_init() to be called from the SPL only, so pull this code
into a CONFIG_SPL_BUILD protected part to avoid build warnings.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/board.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 3ef179742c5..390c9f8850d 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -75,6 +75,7 @@ ulong board_get_usable_ram_top(ulong total_size)
}
#endif
+#ifdef CONFIG_SPL_BUILD
static int gpio_init(void)
{
__maybe_unused uint val;
@@ -172,7 +173,6 @@ static int gpio_init(void)
return 0;
}
-#if defined(CONFIG_SPL_BOARD_LOAD_IMAGE) && defined(CONFIG_SPL_BUILD)
static int spl_board_load_image(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev)
{
@@ -227,18 +227,6 @@ void s_init(void)
"mcr p15, 0, r0, c1, c0, 1\n"
::: "r0");
#endif
-#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
- /* Enable non-secure access to some peripherals */
- tzpc_init();
-#endif
-
- clock_init();
- timer_init();
- gpio_init();
-#if !CONFIG_IS_ENABLED(DM_I2C)
- i2c_init_board();
-#endif
- eth_init_board();
}
#define SUNXI_INVALID_BOOT_SOURCE -1
@@ -335,6 +323,19 @@ u32 spl_boot_device(void)
void board_init_f(ulong dummy)
{
+#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I_H3
+ /* Enable non-secure access to some peripherals */
+ tzpc_init();
+#endif
+
+ clock_init();
+ timer_init();
+ gpio_init();
+#if !CONFIG_IS_ENABLED(DM_I2C)
+ i2c_init_board();
+#endif
+ eth_init_board();
+
spl_init();
preloader_console_init();
--
2.17.6
[PATCH 0/5] sunxi: remove lowlevel_init
For a long time the Allwinner platform was using the lowlevel_init() routine in U-Boot's boot process, even though there did not seem to be a real need for that. The README file suggests it should only be used for "bare minimum" tasks to reach board_init_f(). The routines called in arch/arm/mach-sunxi/board.c:s_init() did nothing that really warranted the early and special execution. Since we always run with an SPL, the board_init_f() routine in there seems to be the right place for early peripherals initialisation. Having those routines in s_init() actually forced other parts of U-Boot to follow suit: for instance we added a lowlevel_init() function to the armv8 side, just for sunxi. The same game seems to repeat for the ARM9 support we need for the F1C100s chip, and possibly for the RISC-V part as well. To avoid this and to cleanup some code on the way, remove the need for lowlevel_init for sunxi completely, by: - moving the early peripheral init (clocks, timer, pinmux) to board_init_f(). This also avoids executing those bits a second time when we boot up U-Boot proper. (patch 1/5) - move the "SRAM setup" bits for just a few old SoCs into a separate file, and include this only if needed. (patch 3/5) - move the ACTLR.SMPEN bit setting from board.c into start.S, because we actually need to set this bit early. Other platforms should be able to scrap their own copies and piggy back on this change. (patch 2/5) This allows us to actually remove the lowlevel_init.S file from armv8 in patch 4/5, as sunxi was the only user. For good measure, we also clean up some bits in sunxi_common.h. (patch 5/5) I compile tested this for all sunxi boards, and boot tested (into Linux) on Pine64, PineH64, BananaPi M1, OrangePi Zero. But there is a high chance of something breaking, so please give it a good shake on whatever Allwinner hardware you have access to. Thanks, Andre Andre Przywara (5): sunxi: move non-essential code out of s_init() sunxi: move Cortex SMPEN setting into start.S sunxi: move early "SRAM setup" into separate file armv8: remove no longer needed lowlevel_init.S sunxi-common.h: remove pointless #ifdefs arch/arm/Kconfig | 3 -- arch/arm/cpu/armv7/Kconfig | 7 +++ arch/arm/cpu/armv7/start.S | 11 + arch/arm/cpu/armv7/sunxi/Makefile | 3 ++ arch/arm/cpu/armv7/sunxi/sram.c| 45 + arch/arm/cpu/armv8/Makefile| 1 - arch/arm/cpu/armv8/lowlevel_init.S | 43 arch/arm/mach-sunxi/Kconfig| 2 - arch/arm/mach-sunxi/board.c| 78 -- include/configs/sunxi-common.h | 7 --- 10 files changed, 86 insertions(+), 114 deletions(-) create mode 100644 arch/arm/cpu/armv7/sunxi/sram.c delete mode 100644 arch/arm/cpu/armv8/lowlevel_init.S -- 2.17.6
Re: [PATCH 1/3] serial: Add RISC-V HTIF console driver
> From: Anup Patel > Sent: Saturday, January 15, 2022 12:20 AM > To: Rick Jian-Zhi Chen(陳建志) ; Bin Meng > > Cc: Atish Patra ; Alistair Francis > ; Anup Patel ; U-Boot Mailing > List ; Anup Patel ; Philipp > Tomsich > Subject: [PATCH 1/3] serial: Add RISC-V HTIF console driver > > Quite a few RISC-V emulators and ISS (including Spike) have host transfer > interface (HTIF) based console. This patch adds HTIF based console driver for > RISC-V platforms which depends totally on DT node for HTIF register base > address. > > Signed-off-by: Anup Patel > Reviewed-by: Philipp Tomsich > --- > drivers/serial/Kconfig | 8 ++ > drivers/serial/Makefile | 1 + > drivers/serial/serial_htif.c | 178 +++ > 3 files changed, 187 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v5 3/3] arm: kirkwood: Pogoplug-V4 : Add board implementation files
Hi Stefan, On Mon, Jan 24, 2022 at 2:25 AM Tony Dinh wrote: > > Hi Stefan, > > On Mon, Jan 24, 2022 at 1:41 AM Stefan Roese wrote: > > > > On 1/24/22 07:17, Tony Dinh wrote: > > > Add board header, defconfig, and implementation files for Pogoplug V4. > > > > > > Signed-off-by: Tony Dinh > > > --- > > > > > > Changes in v5: > > > - Currently, CONFIG_RESET_PHY_R symbol is used in > > > arch/arm/mach-kirkwood/include/mach/config.h for all Kirkwood > > > boards with mv8831116 PHY, with each board defines the function > > > reset_phy(). Undefine it for this board. > > > - Add board_eth_init() to use uclass mvgbe to handle all Ethernet > > > PHY configuration and bring up the network. > > > > Okay, good. I'm a bit puzzled that you don't need (want) to enable the > > Marvell ethernet PHY driver for this as well. But perhaps this is an > > optimization for some follow-up patches - also for some other Kirkwood > > boards. > > Exactly! For Kirkwood boards with MV88E1116 PHY (about 6 boards), it > is enough to let the uclass mvgbe handle all the PHY config and bring > up the Gbits network using the PHY default genphy_config(). And it > will run in gmii phy-mode. > > The optimization will come in a follow-up patch, where we will enable > rgmii phy-mode in the DTS. I'll submit a follow-up patch in which > we'll use u-boot.dtsi to add phy-mode="rgmii". And then I'll follow up > with patches for other Kirkwood boards to use the same approach. > Follow up on my thinking above about using the DTS to optimize. I was wrong, the DTS just does not have enough to do what I thought we could. So I'll send a follow up patch using the Marvell driver config for this. Thanks, Tony > > > > So for now: > > > > Reviewed-by: Stefan Roese > > > > Thanks, > > Stefan > > > > > > > Changes in v4: > > > - Remove CONFIG_FEATURE_COMMAND_EDITING and ifdefs for CMD_NET > > > in include header > > > > > > Changes in v3: > > > - Squash board file small patches into one patch > > > - Migrate config symbols from board include header to defconfig > > > - Remove obsolete config symbols from header file > > > - Don't use ifdefs for unselectable config symbols in header file > > > > > > Changes in v2: > > > - Move constants to .c file and remove header file > > > - Use canonical format for defconfig file > > > > > > board/cloudengines/pogo_v4/MAINTAINERS | 6 + > > > board/cloudengines/pogo_v4/Makefile | 10 ++ > > > board/cloudengines/pogo_v4/kwbimage.cfg | 148 > > > board/cloudengines/pogo_v4/pogo_v4.c| 148 > > > configs/pogo_v4_defconfig | 79 + > > > include/configs/pogo_v4.h | 56 + > > > 6 files changed, 447 insertions(+) > > > create mode 100644 board/cloudengines/pogo_v4/MAINTAINERS > > > create mode 100644 board/cloudengines/pogo_v4/Makefile > > > create mode 100644 board/cloudengines/pogo_v4/kwbimage.cfg > > > create mode 100644 board/cloudengines/pogo_v4/pogo_v4.c > > > create mode 100644 configs/pogo_v4_defconfig > > > create mode 100644 include/configs/pogo_v4.h > > > > > > diff --git a/board/cloudengines/pogo_v4/MAINTAINERS > > > b/board/cloudengines/pogo_v4/MAINTAINERS > > > new file mode 100644 > > > index 00..35fd7858b7 > > > --- /dev/null > > > +++ b/board/cloudengines/pogo_v4/MAINTAINERS > > > @@ -0,0 +1,6 @@ > > > +POGO_V4 BOARD > > > +M: Tony Dinh > > > +S: Maintained > > > +F: board/cloudengines/pogo_v4/ > > > +F: include/configs/pogo_v4.h > > > +F: configs/pogo_v4_defconfig > > > diff --git a/board/cloudengines/pogo_v4/Makefile > > > b/board/cloudengines/pogo_v4/Makefile > > > new file mode 100644 > > > index 00..511bf5ff7e > > > --- /dev/null > > > +++ b/board/cloudengines/pogo_v4/Makefile > > > @@ -0,0 +1,10 @@ > > > +# SPDX-License-Identifier: GPL-2.0+ > > > +# > > > +# (C) Copyright 2014-2021 Tony Dinh > > > +# > > > +# Based on > > > +# Marvell Semiconductor > > > +# Written-by: Prafulla Wadaskar > > > +# > > > + > > > +obj-y:= pogo_v4.o > > > diff --git a/board/cloudengines/pogo_v4/kwbimage.cfg > > > b/board/cloudengines/pogo_v4/kwbimage.cfg > > > new file mode 100644 > > > index 00..f6294fe313 > > > --- /dev/null > > > +++ b/board/cloudengines/pogo_v4/kwbimage.cfg > > > @@ -0,0 +1,148 @@ > > > +# SPDX-License-Identifier: GPL-2.0+ > > > +# > > > +# Copyright (C) 2012 > > > +# David Purdy > > > +# > > > +# Based on Kirkwood support: > > > +# (C) Copyright 2009 > > > +# Marvell Semiconductor > > > +# Written-by: Prafulla Wadaskar marvell.com> > > > + > > > +# Boot Media configurations (DONE) > > > +BOOT_FROMnand > > > +NAND_ECC_MODEdefault > > > +NAND_PAGE_SIZE 0x0800 > > > + > > > +# SOC registers configuration using bootrom header extension > > > +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed > > > + > > > +# Configure RGMII-0 interface pad voltage to 1.8V (SHOULD BE SAME) > > > +DATA 0xffd100e0 0x1b1b1b9b
Re: [PATCH v4 1/4] checkpatch: Support wide strings
On Sun, 2022-01-23 at 13:12 -0700, Simon Glass wrote: > Hi Joe, > > On Sun, 23 Jan 2022 at 09:27, Joe Perches wrote: > > > > On Sun, 2022-01-23 at 11:19 -0500, Tom Rini wrote: > > > On Sun, Jan 23, 2022 at 08:10:37AM -0800, Joe Perches wrote: > > > > On Sun, 2022-01-23 at 09:03 -0700, Simon Glass wrote: > > > > > > > > > Do you think we > > > > > should try to send the U-Boot things upstream? > > > > > > > > No idea. What are the U-Boot things that could or should be generic ? > > > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/master/scripts/checkpatch.pl > > > > > > Honestly? > > > > Do you honestly think I normally look at or care about u-boot ? > > > > > I think we got everything that was generic pushed upstream > > > first these days and it's just U-Boot centric checks in the u_boot_* > > > functions. > > > > Fine by me. > > > > It is just one perl function enabled by a --u-boot flag, so if you > don't mind, it would be convenient to upstream it. You could send a patch for review.
Re: [PATCH 6/8] cmd: efidebug: simplify printing GUIDs
On Mon, Jan 24, 2022 at 09:25:34AM +0100, Heinrich Schuchardt wrote: > On 1/24/22 08:23, AKASHI Takahiro wrote: > > On Fri, Jan 21, 2022 at 05:03:03PM +0100, Heinrich Schuchardt wrote: > > > On 1/21/22 16:20, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Sun, 16 Jan 2022 at 08:14, Heinrich Schuchardt > > > > wrote: > > > > > > > > > > Use "%pS" to print text representations of GUIDs. > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > --- > > > > >cmd/efidebug.c | 160 > > > > > ++--- > > > > >include/efi_api.h | 8 +++ > > > > >include/efi_dt_fixup.h | 4 -- > > > > >include/efi_rng.h | 4 -- > > > > >lib/uuid.c | 116 ++ > > > > >5 files changed, 128 insertions(+), 164 deletions(-) > > > > > > > > > > > > > Does this blow up the image size? These strings only in the debug side > > > > before. > > > > > > It was to avoid image size increase that I added > > > +#ifdef CONFIG_CMD_EFIDEBUG > > > > > > > > > > > Having said that, I would much rather see a string than a guid, which > > > > I consider to be little more than an obfuscation. > > > > > > That was my motivation. When debugging a boot failure I set DEBUG in > > > lib/efi_loader/efi_boottime.c and reading GUIDs in the debug output was > > > not > > > helpful. > > > > But setting DEBUG in efi_boottime.c doesn't lead to CONFIG_CMD_EFIDEBUG > > being on in uuid.c. Do we want to have a more direct CONFIG? > > We could use CONFIG_LOGLEVEL >= LOGL_DEBUG because once that loglevel is > set you can use the log command to log one of the EFI related functions. I'm not sure the log level is the best choice for controlling messages. Showing a human-readable GUID would also be a help in case of errors. > Overall the EFI debugging requires rethinking: I definitely agree, no specific idea though. -Takahiro Akashi > If you simply add '#define DEFINE 1' to the top of > lib/efi_loader/efi_boottime your screen will be flooded by function > calls related to timer events. Probably those high frequency events > should use LOGL_DEBUG_IO. > > Best regards > > Heinrich > > > > > -Takahiro Akashi > > > > > Best regards > > > > > > Heinrich > > > > > > > > > > > Regards, > > > > Simon >
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
Hi Rasmus, On Mon, 24 Jan 2022 at 15:15, Rasmus Villemoes wrote: > > On 24/01/2022 18.57, Simon Glass wrote: > > >> And the thing about "adding the signature" - yes, indeed, _signing_ can > >> and should be done after building. But that is not at all what this > >> started with, this is about embedding the metadata that U-Boot (or SPL) > >> will need for _verifying_ during the build itself - when the private key > >> may not even be available. Again, I think that it's a fundamental design > >> bug that generating and adding that metadata in the form needed by > >> U-Boot can only be done as a side effect of signing some unrelated image. > > > > It is a side effect of signing *the same* image, i.e. the image that > > holds the signature and the public key. There is only one image, the > > firmware image produced by binman. > > Huh? Are we talking about the same thing? What you write makes no sense > at all. Perhaps it is a terminology thing. For me: image: the final firmware image with everything in it binary: a component of the image So there is only one image. Regards, Simon
Re: [PATCH V2] mkimage: fix segfault on MacOS arm64
On Mon, Jan 17, 2022 at 02:07:13AM +0300, Sergey V. Lobanov wrote:
> mkimage segfaults due ASLR mechasim on MacOS arm64
>
> It is required to use _dyld_get_image_vmaddr_slide()
> to prevent segfault on MacOS arm64
>
> This patch ased on the discussion
> https://github.com/u-boot/u-boot/commit/3b142045e8a7f0ab17b6099e9226296af45967d0
>
> Thanks to Ronny Kotzschmar and ptpt52 github user
>
> Signed-off-by: Sergey V. Lobanov
> ---
> tools/imagetool.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index e229a34ffc..a0985d93d2 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -271,11 +271,13 @@ int rockchip_copy_image(int fd, struct
> image_tool_params *mparams);
> * b) we need a API call to get the respective section symbols */
> #if defined(__MACH__)
> #include
> +#include
>
> #define INIT_SECTION(name) do { \
> unsigned long name ## _len; \
> char *__cat(pstart_, name) = getsectdata("__DATA", \
> #name, &__cat(name, _len)); \
> + __cat(pstart_, name) += _dyld_get_image_vmaddr_slide(0);\
> char *__cat(pstop_, name) = __cat(pstart_, name) + \
> __cat(name, _len); \
> __cat(__start_, name) = (void *)__cat(pstart_, name); \
This now seems sensible to me, thanks for fixing my mess.
Reviewed-by: Jessica Clarke
(though you may want to clean up your commit message; "ased" is missing
the leading b and you're still missing the verb "is", plus "mechasim"
should be "mechanism" and it should be "due to the", not just "due")
Jess
Re: [PATCH V2] mkimage: fix segfault on MacOS arm64
Thank you, Jessica.
I have rebased on current master, added Reviewed-by tag, fixed grammar/typos
and sent v3
> On 25 Jan 2022, at 02:00, Jessica Clarke wrote:
>
> On Mon, Jan 17, 2022 at 02:07:13AM +0300, Sergey V. Lobanov wrote:
>> mkimage segfaults due ASLR mechasim on MacOS arm64
>>
>> It is required to use _dyld_get_image_vmaddr_slide()
>> to prevent segfault on MacOS arm64
>>
>> This patch ased on the discussion
>> https://github.com/u-boot/u-boot/commit/3b142045e8a7f0ab17b6099e9226296af45967d0
>>
>> Thanks to Ronny Kotzschmar and ptpt52 github user
>>
>> Signed-off-by: Sergey V. Lobanov
>> ---
>> tools/imagetool.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/imagetool.h b/tools/imagetool.h
>> index e229a34ffc..a0985d93d2 100644
>> --- a/tools/imagetool.h
>> +++ b/tools/imagetool.h
>> @@ -271,11 +271,13 @@ int rockchip_copy_image(int fd, struct
>> image_tool_params *mparams);
>> * b) we need a API call to get the respective section symbols */
>> #if defined(__MACH__)
>> #include
>> +#include
>>
>> #define INIT_SECTION(name) do { \
>> unsigned long name ## _len; \
>> char *__cat(pstart_, name) = getsectdata("__DATA", \
>> #name, &__cat(name, _len)); \
>> +__cat(pstart_, name) += _dyld_get_image_vmaddr_slide(0);\
>> char *__cat(pstop_, name) = __cat(pstart_, name) + \
>> __cat(name, _len); \
>> __cat(__start_, name) = (void *)__cat(pstart_, name); \
>
> This now seems sensible to me, thanks for fixing my mess.
>
> Reviewed-by: Jessica Clarke
>
> (though you may want to clean up your commit message; "ased" is missing
> the leading b and you're still missing the verb "is", plus "mechasim"
> should be "mechanism" and it should be "due to the", not just "due")
>
> Jess
[PATCH v3] mkimage: fix segfault on MacOS arm64
mkimage segfaults due to the ASLR mechanism on MacOS arm64
It is required to use _dyld_get_image_vmaddr_slide()
to prevent segfault on MacOS arm64
This patch is based on the discussion
https://github.com/u-boot/u-boot/commit/3b142045e8a7f0ab17b6099e9226296af45967d0
Thanks to Jessica Clarke, Ronny Kotzschmar and ptpt52 github user
Reviewed-by: Jessica Clarke
Signed-off-by: Sergey V. Lobanov
---
Changes since version 2:
- Rebased on current master
- Added Reviewed-by tag
- Fixed typos and grammatical errors
tools/imagetool.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/imagetool.h b/tools/imagetool.h
index b7ac3a23d0..45eaada4b5 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -272,11 +272,13 @@ int rockchip_copy_image(int fd, struct image_tool_params
*mparams);
* b) we need a API call to get the respective section symbols */
#if defined(__MACH__)
#include
+#include
#define INIT_SECTION(name) do { \
unsigned long name ## _len; \
char *__cat(pstart_, name) = getsectdata("__DATA", \
#name, &__cat(name, _len)); \
+ __cat(pstart_, name) += _dyld_get_image_vmaddr_slide(0);\
char *__cat(pstop_, name) = __cat(pstart_, name) + \
__cat(name, _len); \
__cat(__start_, name) = (void *)__cat(pstart_, name); \
--
2.32.0 (Apple Git-132)
Re: [PATCH V2] mkimage: fix segfault on MacOS arm64
CC: Jessica Clarke
> On 17 Jan 2022, at 02:07, Sergey V. Lobanov wrote:
>
> mkimage segfaults due ASLR mechasim on MacOS arm64
>
> It is required to use _dyld_get_image_vmaddr_slide()
> to prevent segfault on MacOS arm64
>
> This patch ased on the discussion
> https://github.com/u-boot/u-boot/commit/3b142045e8a7f0ab17b6099e9226296af45967d0
>
> Thanks to Ronny Kotzschmar and ptpt52 github user
>
> Signed-off-by: Sergey V. Lobanov
> ---
> tools/imagetool.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index e229a34ffc..a0985d93d2 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -271,11 +271,13 @@ int rockchip_copy_image(int fd, struct
> image_tool_params *mparams);
> * b) we need a API call to get the respective section symbols */
> #if defined(__MACH__)
> #include
> +#include
>
> #define INIT_SECTION(name) do { \
> unsigned long name ## _len; \
> char *__cat(pstart_, name) = getsectdata("__DATA", \
> #name, &__cat(name, _len)); \
> + __cat(pstart_, name) += _dyld_get_image_vmaddr_slide(0);\
> char *__cat(pstop_, name) = __cat(pstart_, name) + \
> __cat(name, _len); \
> __cat(__start_, name) = (void *)__cat(pstart_, name); \
> --
> 2.32.0 (Apple Git-132)
>
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
On 24/01/2022 18.57, Simon Glass wrote: >> And the thing about "adding the signature" - yes, indeed, _signing_ can >> and should be done after building. But that is not at all what this >> started with, this is about embedding the metadata that U-Boot (or SPL) >> will need for _verifying_ during the build itself - when the private key >> may not even be available. Again, I think that it's a fundamental design >> bug that generating and adding that metadata in the form needed by >> U-Boot can only be done as a side effect of signing some unrelated image. > > It is a side effect of signing *the same* image, i.e. the image that > holds the signature and the public key. There is only one image, the > firmware image produced by binman. Huh? Are we talking about the same thing? What you write makes no sense at all. Rasmus
Re: [RFC PATCH] dts: automatically build necessary .dtb files
On 24/01/2022 18.57, Simon Glass wrote: > Hi, > > On Mon, 24 Jan 2022 at 09:02, Tom Rini wrote: >> >> On Mon, Jan 10, 2022 at 02:34:41PM +0100, Rasmus Villemoes wrote: >> >>> When building for a custom board, it is quite common to maintain a >>> private branch which include some defconfig and .dts files. But to >>> hook up those .dts files requires modifying a file "belonging" to >>> upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch >>> to a newer upstream then often results in a conflict which, while it >>> is trivial to resolve by hand, makes it harder to have a CI do "try to >>> build our board against latest upstream". >>> >>> The .config usually includes information on precisely what .dtb(s) are >>> needed, so to avoid having to modify the Makefile, simply add the >>> files in (SPL_)OF_LIST to dtb-y. >>> >>> A technicality is that (SPL_)OF_LIST is not always defined, so rework >>> the Kconfig symbols so that (SPL_)OF_LIST is always defined (when >>> (SPL_)OF_CONTROL), but only prompted for in the cases which used to be >>> their "depends on". >>> >>> nios2 and microblaze already have something like this in their >>> dts/Makefile, and the rationale in commit 41f59f68539 is similar to >>> the above. So this simply generalizes existing practice. Followup >>> patches could remove the logic in those two makefiles, just as there's >>> potential for moving some common boilerplate from all the >>> arch/*/dts/Makefile files to the new scripts/Makefile.dts. >>> >>> Signed-off-by: Rasmus Villemoes >>> --- >>> arch/arc/dts/Makefile| 2 ++ >>> arch/arm/dts/Makefile| 2 ++ >>> arch/m68k/dts/Makefile | 2 ++ >>> arch/microblaze/dts/Makefile | 2 ++ >>> arch/mips/dts/Makefile | 2 ++ >>> arch/nds32/dts/Makefile | 2 ++ >>> arch/nios2/dts/Makefile | 2 ++ >>> arch/powerpc/dts/Makefile| 2 ++ >>> arch/riscv/dts/Makefile | 2 ++ >>> arch/sandbox/dts/Makefile| 2 ++ >>> arch/sh/dts/Makefile | 2 ++ >>> arch/x86/dts/Makefile| 2 ++ >>> arch/xtensa/dts/Makefile | 2 ++ >>> dts/Kconfig | 8 >>> scripts/Makefile.dts | 3 +++ >>> 15 files changed, 33 insertions(+), 4 deletions(-) >>> create mode 100644 scripts/Makefile.dts >>> >>> diff --git a/arch/arc/dts/Makefile b/arch/arc/dts/Makefile >>> index 515fe1fe53..532a8131c5 100644 >>> --- a/arch/arc/dts/Makefile >>> +++ b/arch/arc/dts/Makefile >>> @@ -8,6 +8,8 @@ dtb-$(CONFIG_TARGET_EMSDP) += emsdp.dtb >>> dtb-$(CONFIG_TARGET_HSDK) += hsdk.dtb hsdk-4xd.dtb >>> dtb-$(CONFIG_TARGET_IOT_DEVKIT) += iot_devkit.dtb >>> >>> +include $(srctree)/scripts/Makefile.dts >>> + >>> targets += $(dtb-y) >>> >>> DTC_FLAGS += -R 4 -p 0x1000 >>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile >>> index b3e2a9c9d7..ef58be0381 100644 >>> --- a/arch/arm/dts/Makefile >>> +++ b/arch/arm/dts/Makefile >>> @@ -1163,6 +1163,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += >>> imx8mm-cl-iot-gate-optee.dtb >>> >>> dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb >>> >>> +include $(srctree)/scripts/Makefile.dts >>> + >>> targets += $(dtb-y) >>> >>> # Add any required device tree compiler flags here >>> diff --git a/arch/m68k/dts/Makefile b/arch/m68k/dts/Makefile >>> index fdd435bc34..7988522eb9 100644 >>> --- a/arch/m68k/dts/Makefile >>> +++ b/arch/m68k/dts/Makefile >>> @@ -18,6 +18,8 @@ dtb-$(CONFIG_TARGET_M5373EVB) += M5373EVB.dtb >>> dtb-$(CONFIG_TARGET_AMCORE) += amcore.dtb >>> dtb-$(CONFIG_TARGET_STMARK2) += stmark2.dtb >>> >>> +include $(srctree)/scripts/Makefile.dts >>> + >>> targets += $(dtb-y) >>> >>> DTC_FLAGS += -R 4 -p 0x1000 >>> diff --git a/arch/microblaze/dts/Makefile b/arch/microblaze/dts/Makefile >>> index 4690dc1b9f..427a8f9aac 100644 >>> --- a/arch/microblaze/dts/Makefile >>> +++ b/arch/microblaze/dts/Makefile >>> @@ -2,6 +2,8 @@ >>> >>> dtb-y += $(shell echo $(CONFIG_DEFAULT_DEVICE_TREE)).dtb >>> >>> +include $(srctree)/scripts/Makefile.dts >>> + >>> targets += $(dtb-y) >>> >>> DTC_FLAGS += -R 4 -p 0x1000 >>> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile >>> index 215283cfa0..95144b24dc 100644 >>> --- a/arch/mips/dts/Makefile >>> +++ b/arch/mips/dts/Makefile >>> @@ -34,6 +34,8 @@ dtb-$(CONFIG_SOC_JR2) += jr2_pcb110.dtb jr2_pcb111.dtb >>> serval2_pcb112.dtb >>> dtb-$(CONFIG_SOC_SERVALT) += servalt_pcb116.dtb >>> dtb-$(CONFIG_SOC_SERVAL) += serval_pcb105.dtb serval_pcb106.dtb >>> >>> +include $(srctree)/scripts/Makefile.dts >>> + >>> targets += $(dtb-y) >>> >>> # Add any required device tree compiler flags here >>> diff --git a/arch/nds32/dts/Makefile b/arch/nds32/dts/Makefile >>> index a8e23ad9ad..5a09e3b45b 100644 >>> --- a/arch/nds32/dts/Makefile >>> +++ b/arch/nds32/dts/Makefile >>> @@ -2,6 +2,8 @@ >>> >>> dtb-$(CONFIG_TARGET_ADP_AG101P) += ag101p.dtb >>> dtb-$(CONFIG_TARGET_ADP_AE3XX) += ae3xx.dtb >>> +include $(srctree)/scripts/Makefile.dts >>> + >>> targets += $(dtb-y) >>> >>> DTC_FLAGS
Re: [PATCH] scripts: setlocalversion: remove quotes around localversion from config
On Fri, Jan 14, 2022 at 12:26:30AM +0300, Nikita Maslov wrote:
> From: Nikita Maslov
> Date: Fri, 14 Jan 2022 00:13:39 +0300
> Subject: [PATCH] scripts: setlocalversion: remove quotes around
> localversion from config
>
> After replacing of include/config/auto.conf sourcing with
> extraction of CONFIG_LOCALVERSION, resulting version string
> contains quotes around localversion part which are always
> present in auto.conf (even if localversion is empty).
>
> This patch fixes this script so it removes quotes now.
>
> Signed-off-by: Nikita Maslov
> Cc: Philipp Tomsich
> Cc: Tom Rini
> Reviewed-by: Simon Glass
> ---
>
> scripts/setlocalversion | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> '=' '/^CONFIG_LOCALVERSION_AUTO=/ {print $2}' | xargs echo`
> else
> echo "Error: kernelrelease not valid - run 'make prepare' to
> update it" >&2
> exit 1
> --
>
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index c1c0435267..4a63143706 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -153,8 +153,9 @@ if test -e include/config/auto.conf; then
> # We are interested only in CONFIG_LOCALVERSION and
> # CONFIG_LOCALVERSION_AUTO, so extract these in a safe
> # way (i.e. w/o sourcing auto.conf)
> - CONFIG_LOCALVERSION=`cat include/config/auto.conf | awk -F '='
> '/^CONFIG_LOCALVERSION=/ {print $2}'`
> - CONFIG_LOCALVERSION_AUTO=`cat include/config/auto.conf | awk -F
> '=' '/^CONFIG_LOCALVERSION_AUTO=/ {print $2}'`
> + # xargs echo removes quotes
> + CONFIG_LOCALVERSION=`cat include/config/auto.conf | awk -F '='
> '/^CONFIG_LOCALVERSION=/ {print $2}' | xargs echo`
> + CONFIG_LOCALVERSION_AUTO=`cat include/config/auto.conf | awk -F
Can you please re-post this? The whitespace was rather badly destroyed,
thanks.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] gpio: rgpio2p: Enhance reading of GPIO pin value
On Mon, Jan 24, 2022 at 5:50 PM Fabio Estevam wrote:
>
> [Adding the NXP folks to help reviewing it]
Sorry, added the NXP Linux folks instead of the NXP U-Boot folks.
>
> On Mon, Jan 24, 2022 at 5:46 PM Christoph Fritz
> wrote:
> >
> > Add support for reading GPIO pin value when function is output.
> > With this patch applied, gpio toggle command is working.
> >
> > Signed-off-by: Christoph Fritz
> > ---
> > drivers/gpio/imx_rgpio2p.c | 14 +-
> > 1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/imx_rgpio2p.c b/drivers/gpio/imx_rgpio2p.c
> > index 0e2874ca95c..175e460aff5 100644
> > --- a/drivers/gpio/imx_rgpio2p.c
> > +++ b/drivers/gpio/imx_rgpio2p.c
> > @@ -39,6 +39,14 @@ static int imx_rgpio2p_is_output(struct gpio_regs *regs,
> > int offset)
> > return val & (1 << offset) ? 1 : 0;
> > }
> >
> > +static int imx_rgpio2p_bank_get_direction(struct gpio_regs *regs, int
> > offset)
> > +{
> > + if ((readl(>gpio_pddr) >> offset) & 0x01)
> > + return IMX_RGPIO2P_DIRECTION_OUT;
> > +
> > + return IMX_RGPIO2P_DIRECTION_IN;
> > +}
> > +
> > static void imx_rgpio2p_bank_direction(struct gpio_regs *regs, int offset,
> > enum imx_rgpio2p_direction direction)
> > {
> > @@ -67,7 +75,11 @@ static void imx_rgpio2p_bank_set_value(struct gpio_regs
> > *regs, int offset,
> >
> > static int imx_rgpio2p_bank_get_value(struct gpio_regs *regs, int offset)
> > {
> > - return (readl(>gpio_pdir) >> offset) & 0x01;
> > + if (imx_rgpio2p_bank_get_direction(regs, offset) ==
> > + IMX_RGPIO2P_DIRECTION_IN)
> > + return (readl(>gpio_pdir) >> offset) & 0x01;
> > +
> > + return (readl(>gpio_pdor) >> offset) & 0x01;
> > }
> >
> > static int imx_rgpio2p_direction_input(struct udevice *dev, unsigned
> > offset)
> > --
> > 2.30.2
> >
> >
> >
Re: [PATCH] gpio: rgpio2p: Enhance reading of GPIO pin value
[Adding the NXP folks to help reviewing it]
On Mon, Jan 24, 2022 at 5:46 PM Christoph Fritz
wrote:
>
> Add support for reading GPIO pin value when function is output.
> With this patch applied, gpio toggle command is working.
>
> Signed-off-by: Christoph Fritz
> ---
> drivers/gpio/imx_rgpio2p.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/imx_rgpio2p.c b/drivers/gpio/imx_rgpio2p.c
> index 0e2874ca95c..175e460aff5 100644
> --- a/drivers/gpio/imx_rgpio2p.c
> +++ b/drivers/gpio/imx_rgpio2p.c
> @@ -39,6 +39,14 @@ static int imx_rgpio2p_is_output(struct gpio_regs *regs,
> int offset)
> return val & (1 << offset) ? 1 : 0;
> }
>
> +static int imx_rgpio2p_bank_get_direction(struct gpio_regs *regs, int offset)
> +{
> + if ((readl(>gpio_pddr) >> offset) & 0x01)
> + return IMX_RGPIO2P_DIRECTION_OUT;
> +
> + return IMX_RGPIO2P_DIRECTION_IN;
> +}
> +
> static void imx_rgpio2p_bank_direction(struct gpio_regs *regs, int offset,
> enum imx_rgpio2p_direction direction)
> {
> @@ -67,7 +75,11 @@ static void imx_rgpio2p_bank_set_value(struct gpio_regs
> *regs, int offset,
>
> static int imx_rgpio2p_bank_get_value(struct gpio_regs *regs, int offset)
> {
> - return (readl(>gpio_pdir) >> offset) & 0x01;
> + if (imx_rgpio2p_bank_get_direction(regs, offset) ==
> + IMX_RGPIO2P_DIRECTION_IN)
> + return (readl(>gpio_pdir) >> offset) & 0x01;
> +
> + return (readl(>gpio_pdor) >> offset) & 0x01;
> }
>
> static int imx_rgpio2p_direction_input(struct udevice *dev, unsigned offset)
> --
> 2.30.2
>
>
>
[PATCH] imx8m: lock id_swap_bypass bit in tzc380 enable
According to TRM for i.MX8M Nano and Plus, GPR10 register contains lock
bit for TZASC_ID_SWAP_BYPASS bit. This bit is required to be set in
order to avoid AXI bus errors when GPU is enabled on the platform.
TZASC_ID_SWAP_BYPASS bit is alread set for all imx8m applicable
derivatives, but is missing a lock settings to be applied.
Set the TZASC_ID_SWAP_BYPASS_LOCK bit for those derivatives which have
it implemented.
Since we're here, provide also names to bits from TRM instead of using
BIT() macro in the code.
Fixes: deca6cfbf5d7 ("imx8mn: set BYPASS ID SWAP to avoid AXI bus errors")
Fixes: a07c7181296f ("imx8mp: set BYPASS ID SWAP to avoid AXI bus errors")
Signed-off-by: Andrey Zhizhikin
Cc: Peng Fan
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 6 --
arch/arm/mach-imx/imx8m/soc.c | 15 ++-
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index b800da13a1..45d95a7c19 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -80,8 +80,10 @@
#include
#include
-#define GPR_TZASC_EN BIT(0)
-#define GPR_TZASC_EN_LOCK BIT(16)
+#define GPR_TZASC_EN BIT(0)
+#define GPR_TZASC_ID_SWAP_BYPASS BIT(1)
+#define GPR_TZASC_EN_LOCK BIT(16)
+#define GPR_TZASC_ID_SWAP_BYPASS_LOCK BIT(17)
#define SRC_SCR_M4_ENABLE_OFFSET 3
#define SRC_SCR_M4_ENABLE_MASK BIT(3)
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 863508776d..5f5175b4dd 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -66,8 +66,21 @@ void enable_tzc380(void)
/* Enable TZASC and lock setting */
setbits_le32(>gpr[10], GPR_TZASC_EN);
setbits_le32(>gpr[10], GPR_TZASC_EN_LOCK);
+
+ /*
+* According to TRM, TZASC_ID_SWAP_BYPASS should be set in
+* order to avoid AXI Bus errors when GPU is in use
+*/
if (is_imx8mm() || is_imx8mn() || is_imx8mp())
- setbits_le32(>gpr[10], BIT(1));
+ setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS);
+
+ /*
+* imx8mn and imx8mp implements the lock bit for
+* TZASC_ID_SWAP_BYPASS, enable it to lock settings
+*/
+ if (is_imx8mn() || is_imx8mp())
+ setbits_le32(>gpr[10], GPR_TZASC_ID_SWAP_BYPASS_LOCK);
+
/*
* set Region 0 attribute to allow secure and non-secure
* read/write permission. Found some masters like usb dwc3
base-commit: 21a1439d986a889cefbc2ed785c3f592fc9266de
--
2.25.1
[PATCH] gpio: rgpio2p: Enhance reading of GPIO pin value
Add support for reading GPIO pin value when function is output.
With this patch applied, gpio toggle command is working.
Signed-off-by: Christoph Fritz
---
drivers/gpio/imx_rgpio2p.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/imx_rgpio2p.c b/drivers/gpio/imx_rgpio2p.c
index 0e2874ca95c..175e460aff5 100644
--- a/drivers/gpio/imx_rgpio2p.c
+++ b/drivers/gpio/imx_rgpio2p.c
@@ -39,6 +39,14 @@ static int imx_rgpio2p_is_output(struct gpio_regs *regs, int
offset)
return val & (1 << offset) ? 1 : 0;
}
+static int imx_rgpio2p_bank_get_direction(struct gpio_regs *regs, int offset)
+{
+ if ((readl(>gpio_pddr) >> offset) & 0x01)
+ return IMX_RGPIO2P_DIRECTION_OUT;
+
+ return IMX_RGPIO2P_DIRECTION_IN;
+}
+
static void imx_rgpio2p_bank_direction(struct gpio_regs *regs, int offset,
enum imx_rgpio2p_direction direction)
{
@@ -67,7 +75,11 @@ static void imx_rgpio2p_bank_set_value(struct gpio_regs
*regs, int offset,
static int imx_rgpio2p_bank_get_value(struct gpio_regs *regs, int offset)
{
- return (readl(>gpio_pdir) >> offset) & 0x01;
+ if (imx_rgpio2p_bank_get_direction(regs, offset) ==
+ IMX_RGPIO2P_DIRECTION_IN)
+ return (readl(>gpio_pdir) >> offset) & 0x01;
+
+ return (readl(>gpio_pdor) >> offset) & 0x01;
}
static int imx_rgpio2p_direction_input(struct udevice *dev, unsigned offset)
--
2.30.2
Re: [PATCH v2 1/2] cmd: source: Use script from default config
Hi Tom, Thanks for the pointers. I understand your concerns about the growth in size. I'll look into it. Best regards, Sven On 1/24/22 19:08, Tom Rini wrote: On Sat, Jan 22, 2022 at 09:36:58PM +0100, Sven Schwermer wrote: Hi Tom, I didn't think this would result in a size increase. Could you elaborate? Alright. So for background, if you build with tools/buildman/buildman rather than just "make" directly there's some handy tools like "bloat" detection, which shows function size changes from build A to build B. Doing something like this will show the changes for pine64_plus for example export SOURCE_DATE_EPOCH=`date +%s` ./tools/buildman/buildman -o /tmp/pine64_plus -devl -SBC pine64_plus ./tools/buildman/buildman -o /tmp/pine64_plus -devl -SsB pine64_plus That shows in the end: aarch64: (for 1/1 boards) all +551.0 rodata +107.0 text +444.0 pine64_plus: all +551 rodata +107 text +444 u-boot: add: 2/0, grow: 0/-1 bytes: 452/-8 (444) function old new delta fit_find_config_node - 264+264 board_fit_config_name_match - 188+188 image_source_script520 512 -8 And it's that growth, over 722 configs, that I'm concerned with.
[RESEND PATCH 3/3] Nokia RX-51: Convert documentation to rst format
Convert documentation to rst format
Signed-off-by: Pali Rohár
---
board/nokia/rx51/MAINTAINERS | 2 +-
doc/board/index.rst | 1 +
doc/board/nokia/index.rst | 9 ++
.../nokia/rx51.rst} | 144 +-
4 files changed, 87 insertions(+), 69 deletions(-)
create mode 100644 doc/board/nokia/index.rst
rename doc/{README.nokia_rx51 => board/nokia/rx51.rst} (32%)
diff --git a/board/nokia/rx51/MAINTAINERS b/board/nokia/rx51/MAINTAINERS
index 58b16bf9a95c..25f8b3c5a9ad 100644
--- a/board/nokia/rx51/MAINTAINERS
+++ b/board/nokia/rx51/MAINTAINERS
@@ -4,5 +4,5 @@ S: Maintained
F: board/nokia/rx51/
F: include/configs/nokia_rx51.h
F: configs/nokia_rx51_defconfig
-F: doc/README.nokia_rx51
+F: doc/board/nokia/rx51.rst
F: test/nokia_rx51_test.sh
diff --git a/doc/board/index.rst b/doc/board/index.rst
index 5607e1f94638..75c34c4a9998 100644
--- a/doc/board/index.rst
+++ b/doc/board/index.rst
@@ -22,6 +22,7 @@ Board-specific doc
intel/index
kontron/index
microchip/index
+ nokia/index
nxp/index
openpiton/index
qualcomm/index
diff --git a/doc/board/nokia/index.rst b/doc/board/nokia/index.rst
new file mode 100644
index ..b68c3c613164
--- /dev/null
+++ b/doc/board/nokia/index.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+Nokia
+=
+
+.. toctree::
+ :maxdepth: 2
+
+ rx51
diff --git a/doc/README.nokia_rx51 b/doc/board/nokia/rx51.rst
similarity index 32%
rename from doc/README.nokia_rx51
rename to doc/board/nokia/rx51.rst
index e739b02088ea..7ab3a1686b1d 100644
--- a/doc/README.nokia_rx51
+++ b/doc/board/nokia/rx51.rst
@@ -1,6 +1,9 @@
-Board: Nokia RX-51 aka N900
+.. SPDX-License-Identifier: GPL-2.0+
-This board definition results in a u-boot.bin which can be chainloaded
+Nokia RX-51 aka N900
+
+
+This board definition results in a ``u-boot.bin`` which can be chainloaded
from NOLO in qemu or on a real N900. It does very little hardware config
because NOLO has already configured the board. Only needed is enabling
internal eMMC memory via twl4030 regulator which is not enabled by NOLO.
@@ -8,64 +11,64 @@ internal eMMC memory via twl4030 regulator which is not
enabled by NOLO.
NOLO is expecting a kernel image and will treat any image it finds in
onenand as such. This u-boot is intended to be flashed to the N900 like
a kernel. In order to transparently boot the original kernel, it will be
-appended to u-boot.bin at 0x4. NOLO will load the entire image into
+appended to ``u-boot.bin`` at 0x4. NOLO will load the entire image into
(random) memory and execute u-boot, which saves hw revision, boot reason
and boot mode ATAGs set by NOLO. Then the bootscripts will attempt to load
-uImage, zImage or boot.scr from a fat or ext2/3/4 filesystem on external
-SD card or internal eMMC memory. If this fails or keyboard is closed then
-the appended kernel image will be booted using some generated and some
-stored ATAGs (see boot order).
+``uImage``, ``zImage`` or ``boot.scr`` file from a fat or ext2/3/4 filesystem
+on external SD card or internal eMMC memory. If this fails or keyboard is
+closed then the appended kernel image will be booted using some generated
+and some stored ATAGs (see boot order).
For generating combined image of u-boot and kernel (either in uImage or zImage
-format) there is a simple script called u-boot-gen-combined. It is available in
-following repository:
+format) there is a simple script called ``u-boot-gen-combined``. It is
available
+in following repository:
- https://github.com/pali/u-boot-maemo
+ https://github.com/pali/u-boot-maemo
-To generate combined.bin image from u-boot.bin and kernel.bin (either uImage
-or zImage) use:
+To generate ``combined.bin`` image from ``u-boot.bin`` and ``kernel.bin``
+(either uImage or zImage format) use::
- sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin
+ $ sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin
Original Maemo Fremantle PR1.3 zImage kernel binary is available at:
-
http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
+
http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb
-To unpack it (from DEB/AR, TAR and FIASCO) call commands:
+To unpack it (from DEB/AR, TAR and FIASCO) call commands::
- ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz
- tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco >
kernel_2.6.28-20103103+0m5.fiasco
- 0x -M kernel_2.6.28-20103103+0m5.fiasco -u
+ $ ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz
+ $ tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco >
kernel_2.6.28-20103103+0m5.fiasco
+ $ 0x -M kernel_2.6.28-20103103+0m5.fiasco -u
-Flashed image must start with 2 kB "NOLO!img" header which contains size of
-the image. Header consist of bytes
[RESEND PATCH 2/3] Nokia RX-51: Update documentation about flashing
This change contains update for doc/README.nokia_rx51 documentation file with information how to load U-Boot image to device RAM without need to flash it and also how to flash it into OneNAND via 0x flasher. Signed-off-by: Pali Rohár --- doc/README.nokia_rx51 | 45 +++ 1 file changed, 45 insertions(+) diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51 index 1be077514f03..e739b02088ea 100644 --- a/doc/README.nokia_rx51 +++ b/doc/README.nokia_rx51 @@ -22,6 +22,51 @@ following repository: https://github.com/pali/u-boot-maemo +To generate combined.bin image from u-boot.bin and kernel.bin (either uImage +or zImage) use: + + sh u-boot-gen-combined u-boot.bin kernel.bin combined.bin + +Original Maemo Fremantle PR1.3 zImage kernel binary is available at: + + http://repository.maemo.org/pool/maemo5.0/free/k/kernel/kernel_2.6.28-20103103+0m5_armel.deb + +To unpack it (from DEB/AR, TAR and FIASCO) call commands: + + ar x kernel_2.6.28-20103103+0m5_armel.deb data.tar.gz + tar -O -xf data.tar.gz ./boot/zImage-2.6.28-20103103+0m5.fiasco > kernel_2.6.28-20103103+0m5.fiasco + 0x -M kernel_2.6.28-20103103+0m5.fiasco -u + +Flashed image must start with 2 kB "NOLO!img" header which contains size of +the image. Header consist of bytes "NOLO!img\x02\x00\x00\x00\x00\x00\x00\x00" +followed by 4 byte little endian size of the image and rest of the 2 kB header +are just zero bytes. + +Nokia proprietary flasher and also open source 0x flasher automatically +prepend required "NOLO!img" header and both applications expect that image +does not contain "NOLO!img" header. Adding "NOLO!img" header is required +only in case using "nandwrite" tool for flashing. + +Open source 0x flasher is available in following repository: + + https://github.com/pali/0x + +It is possible to load u-boot.bin via USB to N900 RAM and boot it without +need to flashing it. Via 0x running at host PC it is done: + + 0x -m u-boot.bin -l -b + +0x support also flashing kernel image either via USB or directly on +N900 device. Flashing u-boot/kernel/combined image is done as: + + 0x -m combined.bin -f + +Via 0x is possible to generate also standard flashable image in Nokia +FIASCO format which contains metadata information like device identification +(RX-51) and version string (v2021.04): + + 0x -m RX-51:v2021.04:kernel:u-boot.bin -g u-boot.fiasco + There is support for hardware watchdog. Hardware watchdog is started by NOLO so u-boot must kick watchdog to prevent reboot device (but not very often, max every 2 seconds). There is also support for framebuffer display -- 2.20.1
[RESEND PATCH 1/3] Nokia RX-51: Update documentation about ext2/3/4
Since commit 25c5b6517854 ("Nokia RX-51: Do not try calling both ext2load
and ext4load") command ext4load is used for all ext2/3/4 fs variants.
Signed-off-by: Pali Rohár
---
doc/README.nokia_rx51 | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/doc/README.nokia_rx51 b/doc/README.nokia_rx51
index 7f22ed49bd75..1be077514f03 100644
--- a/doc/README.nokia_rx51
+++ b/doc/README.nokia_rx51
@@ -44,8 +44,7 @@ Boot from SD or eMMC in this order:
* 1.2 find uImage on first fat partition
* 1.3 find zImage on first fat partition
* 1.4 same order for 2. - 4. fat partition
- * 2. same as 1. but for ext2/3 partition
- * 3. same as 1. but for ext4 partition
+ * 2. same as 1. but for ext2/3/4 partition
Available additional commands/variables:
@@ -70,7 +69,7 @@ Additional variables for loading files from mmc:
* mmc ${mmcnum} (0 - external, 1 - internal)
* partition number ${mmcpart} (1 - 4)
- * parition type ${mmctype} (fat, ext2, ext4)
+ * partition type ${mmctype} (fat, ext2, ext4; ext2 is just alias for ext4)
Additional variables for booting kernel:
--
2.20.1
Re: [PATCH v2 1/2] cmd: source: Use script from default config
On Sat, Jan 22, 2022 at 09:36:58PM +0100, Sven Schwermer wrote: > Hi Tom, > > I didn't think this would result in a size increase. Could you elaborate? Alright. So for background, if you build with tools/buildman/buildman rather than just "make" directly there's some handy tools like "bloat" detection, which shows function size changes from build A to build B. Doing something like this will show the changes for pine64_plus for example export SOURCE_DATE_EPOCH=`date +%s` ./tools/buildman/buildman -o /tmp/pine64_plus -devl -SBC pine64_plus ./tools/buildman/buildman -o /tmp/pine64_plus -devl -SsB pine64_plus That shows in the end: aarch64: (for 1/1 boards) all +551.0 rodata +107.0 text +444.0 pine64_plus: all +551 rodata +107 text +444 u-boot: add: 2/0, grow: 0/-1 bytes: 452/-8 (444) function old new delta fit_find_config_node - 264+264 board_fit_config_name_match - 188+188 image_source_script520 512 -8 And it's that growth, over 722 configs, that I'm concerned with. -- Tom signature.asc Description: PGP signature
Re: [PATCH] armv8: start.S: remove CONFIG_SYS_RESET_SCTRL code
Am 2022-01-24 18:17, schrieb Andre Przywara: There is some code that tries to "reset" the SCTLR_ELx register early in the boot process. The idea seems to be to guarantee some sane settings that U-Boot actually relies on, for instance running in little-endian mode, with the MMU off initially. However the current code has multiple problems: - For a start, no platform or config defines the symbol that would enable that code. - The code itself really only works if the bits that it tries to clear are already cleared: - If we run in big-endian mode initially, any previous loads would have been wrong already. That applies to the (optional) relocation code, but more prominently to the mask that it uses to clear those bits: "ldr x1, =0xfdfa" looks innocent, but actually involves a memory access to the literal pool, using the current endianess. - If we run with the MMU enabled, we are probably doomed already. We *could* hope that we are running with an identity mapping, but would need to do some cache maintenance to avoid losing dirty cache lines. - The idea of doing a read-modify-write of SCTLR is somewhat questionable to begin with, because as the owner of the current exception level we should initialise all bits of this register with a certain fixed value. - The code is unnecessarily complicated, and the function name is misspelled. While those problems *could* admittedly be fixed, the point that is does not seem to be used at all at the moment tells me we should just remove this code, and be it to not give a bad example. If people care, I could introduce some proper SCTLR initialisation code. We are about to work this out for the boot-wrapper[1] as we speak, but apparently we got away without doing this in U-Boot ever since, so it might not be worth the potential trouble. [1] https://lore.kernel.org/linux-arm-kernel/20220114105653.3003399-7-mark.rutl...@arm.com/ Signed-off-by: Andre Przywara Maybe its used in the cavium u-boot vendor tree; but in mainline it seems like it was always dead code. I'm fine with removing it. -michael
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
Hi Rasmus,
On Mon, 24 Jan 2022 at 03:42, Rasmus Villemoes
wrote:
>
> On 14/01/2022 17.51, Simon Glass wrote:
> > Hi Rasmus,
> >
> > On Tue, 26 Oct 2021 at 02:08, Rasmus Villemoes
> > wrote:
> >>
> >> On 26/10/2021 03.28, Simon Glass wrote:
> >>> Hi Rasmus,
> >>>
> >>> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes
> >>> wrote:
>
> The build system already automatically looks for and includes an
> in-tree *-u-boot.dtsi when building the control .dtb. However, there
> are some things that are awkward to maintain in such an in-tree file,
> most notably the metadata associated to public keys used for verified
> boot.
>
> The only "official" API to get that metadata into the .dtb is via
> mkimage, as a side effect of building an actual signed image. But
> there are multiple problems with that. First of all, the final U-Boot
> (be it U-Boot proper or an SPL) image is built based on a binary
> image, the .dtb, and possibly some other binary artifacts. So
> modifying the .dtb after the build requires the meta-buildsystem
> (Yocto, buildroot, whatnot) to know about and repeat some of the steps
> that are already known to and handled by U-Boot's build system,
> resulting in needless duplication of code. It's also somewhat annoying
> and inconsistent to have a .dtb file in the build folder which is not
> generated by the command listed in the corresponding .cmd file (that
> of course applies to any generated file).
>
> So the contents of the /signature node really needs to be baked into
> the .dtb file when it is first created, which means providing the
> relevant data in the form of a .dtsi file. One could in theory put
> that data into the *-u-boot.dtsi file, but it's more convenient to be
> able to provide it externally: For example, when developing for a
> customer, it's common to use a set of dummy keys for development,
> while the consultants do not (and should not) have access to the
> actual keys used in production. For such a setup, it's easier if the
> keys used are chosen via the meta-buildsystem and the path(s) patched
> in during the configure step. And of course, nothing prevents anybody
> from having DEVICE_TREE_INCLUDES point at files maintained in git, or
> for that matter from including the public key metadata in the
> *-u-boot.dtsi directly and ignore this feature.
>
> There are other uses for this, e.g. in combination with ENV_IMPORT_FDT
> it can be used for providing the contents of the /config/environment
> node, so I don't want to tie this exclusively to use for verified
> boot.
>
> Signed-off-by: Rasmus Villemoes
> ---
>
> Getting the public key metadata into .dtsi form can be done with a
> little scripting (roughly 'mkimage -K' of a dummy image followed by
> 'dtc -I dtb -O dts'). I have a script that does that, along with
> options to set 'required' and 'required-mode' properties, include
> u-boot,dm-spl properties in case one wants to check U-Boot proper from
> SPL with the verified boot mechanism, etc. I'm happy to share that
> script if this gets accepted, but it's moot if this is rejected.
>
> I have previously tried to get an fdt_add_pubkey tool accepted [1,2]
> to disentangle the kernel and u-boot builds (or u-boot and SPL builds
> for that matter!), but as I've since realized, that isn't quite enough
> - the above points re modifying the .dtb after it is created but
> before that is used to create further build artifacts still
> stand. However, such a tool could still be useful for creating the
> .dtsi info without the private keys being present, and my key2dtsi.sh
> script could easily be modified to use a tool like that should it ever
> appear.
>
> [1]
> https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villem...@prevas.dk/
> [2]
> https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205fee...@kaspersky.com/
>
> dts/Kconfig | 9 +
> scripts/Makefile.lib | 2 ++
> 2 files changed, 11 insertions(+)
> >>>
> >>> Reviewed-by: Simon Glass
> >>>
> >>> I suggest adding this to the documentation somewhere in
> >>> doc/develop/devicetree/
> >>
> >> Will do.
> >>
> >>> Getting the key into the U-Boot .dtb is normally done with mkimage, as
> >>> you say. I don't really understand why this approach is easier.
> >>
> >> I think I explained that in the commit message, but let me try with a
> >> more concrete example. I'm building, using Yocto as the umbrella build
> >> system, for a SOC that needs an SPL + U-Boot proper.
> >>
> >> So I have a U-Boot recipe that handles the configuration and
> >> compilation. That's mostly a matter of "make foo_defconfig" followed by
> >> "make ${UBOOT_TARGETS}" where UBOOT_TARGETS is
Re: [RFC PATCH] dts: automatically build necessary .dtb files
Hi, On Mon, 24 Jan 2022 at 09:02, Tom Rini wrote: > > On Mon, Jan 10, 2022 at 02:34:41PM +0100, Rasmus Villemoes wrote: > > > When building for a custom board, it is quite common to maintain a > > private branch which include some defconfig and .dts files. But to > > hook up those .dts files requires modifying a file "belonging" to > > upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch > > to a newer upstream then often results in a conflict which, while it > > is trivial to resolve by hand, makes it harder to have a CI do "try to > > build our board against latest upstream". > > > > The .config usually includes information on precisely what .dtb(s) are > > needed, so to avoid having to modify the Makefile, simply add the > > files in (SPL_)OF_LIST to dtb-y. > > > > A technicality is that (SPL_)OF_LIST is not always defined, so rework > > the Kconfig symbols so that (SPL_)OF_LIST is always defined (when > > (SPL_)OF_CONTROL), but only prompted for in the cases which used to be > > their "depends on". > > > > nios2 and microblaze already have something like this in their > > dts/Makefile, and the rationale in commit 41f59f68539 is similar to > > the above. So this simply generalizes existing practice. Followup > > patches could remove the logic in those two makefiles, just as there's > > potential for moving some common boilerplate from all the > > arch/*/dts/Makefile files to the new scripts/Makefile.dts. > > > > Signed-off-by: Rasmus Villemoes > > --- > > arch/arc/dts/Makefile| 2 ++ > > arch/arm/dts/Makefile| 2 ++ > > arch/m68k/dts/Makefile | 2 ++ > > arch/microblaze/dts/Makefile | 2 ++ > > arch/mips/dts/Makefile | 2 ++ > > arch/nds32/dts/Makefile | 2 ++ > > arch/nios2/dts/Makefile | 2 ++ > > arch/powerpc/dts/Makefile| 2 ++ > > arch/riscv/dts/Makefile | 2 ++ > > arch/sandbox/dts/Makefile| 2 ++ > > arch/sh/dts/Makefile | 2 ++ > > arch/x86/dts/Makefile| 2 ++ > > arch/xtensa/dts/Makefile | 2 ++ > > dts/Kconfig | 8 > > scripts/Makefile.dts | 3 +++ > > 15 files changed, 33 insertions(+), 4 deletions(-) > > create mode 100644 scripts/Makefile.dts > > > > diff --git a/arch/arc/dts/Makefile b/arch/arc/dts/Makefile > > index 515fe1fe53..532a8131c5 100644 > > --- a/arch/arc/dts/Makefile > > +++ b/arch/arc/dts/Makefile > > @@ -8,6 +8,8 @@ dtb-$(CONFIG_TARGET_EMSDP) += emsdp.dtb > > dtb-$(CONFIG_TARGET_HSDK) += hsdk.dtb hsdk-4xd.dtb > > dtb-$(CONFIG_TARGET_IOT_DEVKIT) += iot_devkit.dtb > > > > +include $(srctree)/scripts/Makefile.dts > > + > > targets += $(dtb-y) > > > > DTC_FLAGS += -R 4 -p 0x1000 > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index b3e2a9c9d7..ef58be0381 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -1163,6 +1163,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += > > imx8mm-cl-iot-gate-optee.dtb > > > > dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb > > > > +include $(srctree)/scripts/Makefile.dts > > + > > targets += $(dtb-y) > > > > # Add any required device tree compiler flags here > > diff --git a/arch/m68k/dts/Makefile b/arch/m68k/dts/Makefile > > index fdd435bc34..7988522eb9 100644 > > --- a/arch/m68k/dts/Makefile > > +++ b/arch/m68k/dts/Makefile > > @@ -18,6 +18,8 @@ dtb-$(CONFIG_TARGET_M5373EVB) += M5373EVB.dtb > > dtb-$(CONFIG_TARGET_AMCORE) += amcore.dtb > > dtb-$(CONFIG_TARGET_STMARK2) += stmark2.dtb > > > > +include $(srctree)/scripts/Makefile.dts > > + > > targets += $(dtb-y) > > > > DTC_FLAGS += -R 4 -p 0x1000 > > diff --git a/arch/microblaze/dts/Makefile b/arch/microblaze/dts/Makefile > > index 4690dc1b9f..427a8f9aac 100644 > > --- a/arch/microblaze/dts/Makefile > > +++ b/arch/microblaze/dts/Makefile > > @@ -2,6 +2,8 @@ > > > > dtb-y += $(shell echo $(CONFIG_DEFAULT_DEVICE_TREE)).dtb > > > > +include $(srctree)/scripts/Makefile.dts > > + > > targets += $(dtb-y) > > > > DTC_FLAGS += -R 4 -p 0x1000 > > diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile > > index 215283cfa0..95144b24dc 100644 > > --- a/arch/mips/dts/Makefile > > +++ b/arch/mips/dts/Makefile > > @@ -34,6 +34,8 @@ dtb-$(CONFIG_SOC_JR2) += jr2_pcb110.dtb jr2_pcb111.dtb > > serval2_pcb112.dtb > > dtb-$(CONFIG_SOC_SERVALT) += servalt_pcb116.dtb > > dtb-$(CONFIG_SOC_SERVAL) += serval_pcb105.dtb serval_pcb106.dtb > > > > +include $(srctree)/scripts/Makefile.dts > > + > > targets += $(dtb-y) > > > > # Add any required device tree compiler flags here > > diff --git a/arch/nds32/dts/Makefile b/arch/nds32/dts/Makefile > > index a8e23ad9ad..5a09e3b45b 100644 > > --- a/arch/nds32/dts/Makefile > > +++ b/arch/nds32/dts/Makefile > > @@ -2,6 +2,8 @@ > > > > dtb-$(CONFIG_TARGET_ADP_AG101P) += ag101p.dtb > > dtb-$(CONFIG_TARGET_ADP_AE3XX) += ae3xx.dtb > > +include $(srctree)/scripts/Makefile.dts > > + > > targets += $(dtb-y) > > > > DTC_FLAGS += -R 4 -p 0x1000 > > diff --git
Re: [PATCH v2 1/1] serial: npcm: Add support for Nuvoton NPCM SoCs
On Sun, 23 Jan 2022 at 21:48, Stanley Chu wrote: > > Add Nuvoton BMC NPCM7xx/NPCM8xx uart driver > > Signed-off-by: Stanley Chu > --- > Changes in v2: > Drop unnecessary outer brackets. > Return -EAGAIN if not ready for tx/rx. > Add comments. > --- > drivers/serial/Kconfig | 9 +++ > drivers/serial/Makefile | 1 + > drivers/serial/serial_npcm.c | 150 +++ > 3 files changed, 160 insertions(+) > create mode 100644 drivers/serial/serial_npcm.c Reviewed-by: Simon Glass
Re: [PATCH] binman: doc: fix typo for u-boot-tpl
On Mon, 24 Jan 2022 at 00:11, Heiko Thiery wrote: > > Cc: Simon Glass > Signed-off-by: Heiko Thiery > --- > tools/binman/binman.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [RFC PATCH] efi_loader: clean up uefi secure boot image verification logic
On 1/24/22 16:36, Ilias Apalodimas wrote:
From: Ilias Apalodimas
We currently distinguish between signed and non signed PE/COFF
executables while trying to authenticate signatures and/or sha256
hashes in db and dbx. That code duplication can be avoided.
On sha256 hashes we don't really care if the image is signed or
not. The logic can be implemented in
1. Is the sha256 of the image in dbx
2. Is the image signed with a certificate that's found in db and
not in dbx
3. The image carries a cert which is signed by a cert in db (and
not in dbx, and the image can be verified against the former)
4. Is the sha256 of the image in db
So weed out the 'special' case handling unsigned images.
While at it move the checking of a hash outside the certificate
verification loop which isn't really needed and check for the hash
only once. Also allow a mix of signatures and hashes in db instead
of explicitly breaking out the sha verification loop if a signature
happens to be added first.
It's worth noting that (2) only works if the certificate is self
signed, but that canb be fixed in a following patch.
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_image_loader.c | 84 ++-
lib/efi_loader/efi_signature.c| 2 +-
2 files changed, 15 insertions(+), 71 deletions(-)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 255613eb72ba..53d54ca42f5c 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -516,63 +516,16 @@ err:
}
#ifdef CONFIG_EFI_SECURE_BOOT
-/**
- * efi_image_unsigned_authenticate() - authenticate unsigned image with
- * SHA256 hash
- * @regs: List of regions to be verified
- *
- * If an image is not signed, it doesn't have a signature. In this case,
- * its message digest is calculated and it will be compared with one of
- * hash values stored in signature databases.
- *
- * Return: true if authenticated, false if not
- */
-static bool efi_image_unsigned_authenticate(struct efi_image_regions *regs)
-{
- struct efi_signature_store *db = NULL, *dbx = NULL;
- bool ret = false;
-
- dbx = efi_sigstore_parse_sigdb(L"dbx");
- if (!dbx) {
- EFI_PRINT("Getting signature database(dbx) failed\n");
- goto out;
- }
-
- db = efi_sigstore_parse_sigdb(L"db");
- if (!db) {
- EFI_PRINT("Getting signature database(db) failed\n");
- goto out;
- }
-
- /* try black-list first */
- if (efi_signature_lookup_digest(regs, dbx)) {
- EFI_PRINT("Image is not signed and its digest found in
\"dbx\"\n");
- goto out;
- }
-
- /* try white-list */
- if (efi_signature_lookup_digest(regs, db))
- ret = true;
- else
- EFI_PRINT("Image is not signed and its digest not found in \"db\" or
\"dbx\"\n");
-
-out:
- efi_sigstore_free(db);
- efi_sigstore_free(dbx);
-
- return ret;
-}
-
/**
* efi_image_authenticate() - verify a signature of signed image
* @efi: Pointer to image
* @efi_size: Size of @efi
*
- * A signed image should have its signature stored in a table of its PE header.
+ * An image should have its signature stored in a table of its PE header.
The signature must be stored in the "Certificate Table". See PE-COFF
specification. The PE header only contains the Optional Header Data
Directory that points to the table.
Best regards
Heinrich
* So if an image is signed and only if if its signature is verified using
- * signature databases, an image is authenticated.
- * If an image is not signed, its validity is checked by using
- * efi_image_unsigned_authenticated().
+ * signature databases or if it's sha256 is found in db an image is
+ * authenticated.
+ *
* TODO:
* When AuditMode==0, if the image's signature is not found in
* the authorized database, or is found in the forbidden database,
@@ -608,14 +561,7 @@ static bool efi_image_authenticate(void *efi, size_t
efi_size)
if (!efi_image_parse(new_efi, efi_size, , ,
_len)) {
EFI_PRINT("Parsing PE executable image failed\n");
- goto err;
- }
-
- if (!wincerts) {
- /* The image is not signed */
- ret = efi_image_unsigned_authenticate(regs);
-
- goto err;
+ goto out;
}
/*
@@ -624,18 +570,18 @@ static bool efi_image_authenticate(void *efi, size_t
efi_size)
db = efi_sigstore_parse_sigdb(L"db");
if (!db) {
EFI_PRINT("Getting signature database(db) failed\n");
- goto err;
+ goto out;
}
dbx = efi_sigstore_parse_sigdb(L"dbx");
if (!dbx) {
EFI_PRINT("Getting signature database(dbx) failed\n");
- goto err;
+ goto out;
}
[PATCH] armv8: start.S: remove CONFIG_SYS_RESET_SCTRL code
There is some code that tries to "reset" the SCTLR_ELx register early in the boot process. The idea seems to be to guarantee some sane settings that U-Boot actually relies on, for instance running in little-endian mode, with the MMU off initially. However the current code has multiple problems: - For a start, no platform or config defines the symbol that would enable that code. - The code itself really only works if the bits that it tries to clear are already cleared: - If we run in big-endian mode initially, any previous loads would have been wrong already. That applies to the (optional) relocation code, but more prominently to the mask that it uses to clear those bits: "ldr x1, =0xfdfa" looks innocent, but actually involves a memory access to the literal pool, using the current endianess. - If we run with the MMU enabled, we are probably doomed already. We *could* hope that we are running with an identity mapping, but would need to do some cache maintenance to avoid losing dirty cache lines. - The idea of doing a read-modify-write of SCTLR is somewhat questionable to begin with, because as the owner of the current exception level we should initialise all bits of this register with a certain fixed value. - The code is unnecessarily complicated, and the function name is misspelled. While those problems *could* admittedly be fixed, the point that is does not seem to be used at all at the moment tells me we should just remove this code, and be it to not give a bad example. If people care, I could introduce some proper SCTLR initialisation code. We are about to work this out for the boot-wrapper[1] as we speak, but apparently we got away without doing this in U-Boot ever since, so it might not be worth the potential trouble. [1] https://lore.kernel.org/linux-arm-kernel/20220114105653.3003399-7-mark.rutl...@arm.com/ Signed-off-by: Andre Przywara --- arch/arm/cpu/armv8/start.S | 37 - 1 file changed, 37 deletions(-) diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S index b3eef705a5..91b00a46cc 100644 --- a/arch/arm/cpu/armv8/start.S +++ b/arch/arm/cpu/armv8/start.S @@ -104,10 +104,6 @@ pie_skip_reloc: pie_fixup_done: #endif -#ifdef CONFIG_SYS_RESET_SCTRL - bl reset_sctrl -#endif - #if defined(CONFIG_ARMV8_SPL_EXCEPTION_VECTORS) || !defined(CONFIG_SPL_BUILD) .macro set_vbar, regname, reg msr \regname, \reg @@ -195,39 +191,6 @@ slave_cpu: master_cpu: bl _main -#ifdef CONFIG_SYS_RESET_SCTRL -reset_sctrl: - switch_el x1, 3f, 2f, 1f -3: - mrs x0, sctlr_el3 - b 0f -2: - mrs x0, sctlr_el2 - b 0f -1: - mrs x0, sctlr_el1 - -0: - ldr x1, =0xfdfa - and x0, x0, x1 - - switch_el x1, 6f, 5f, 4f -6: - msr sctlr_el3, x0 - b 7f -5: - msr sctlr_el2, x0 - b 7f -4: - msr sctlr_el1, x0 - -7: - dsb sy - isb - b __asm_invalidate_tlb_all - ret -#endif - /*---*/ WEAK(apply_core_errata) -- 2.25.1
Re: [PATCH 2/7] sunxi: Kconfig: Fix up SPI configuration
On Tue, 11 Jan 2022 12:46:02 +
Andre Przywara wrote:
Hi Jagan,
can you please have a look at this patch?
It seems like a nice cleanup to me, but I would like to hear your opinion.
Cheers,
Andre
> Commit 7945caf22c44 ("arm: sunxi: Enable SPI/SPI-FLASH support for A64")
> selected CONFIG_SPI by default on all Allwinner A64 boards, even though
> only 4 out of the 14 A64 boards have a SPI flash chip. All other SoCs
> had to manually select DM_SPI and friends, even though they are a
> platform property (the sunxi SPI driver is DM_SPI only).
>
> Clean this up to allow easy selection of SPI flash support in U-Boot
> proper, by selecting DM_SPI and DM_SPI_FLASH *if* CONFIG_SPI is
> selected, for *all* Allwinner SoCs. This simplifies the defconfig for
> two Libretech boards already.
>
> Also remove the forced CONFIG_SPI from the A64 Kconfig, instead let the
> four boards which allow SPI booting select this explicitly.
>
> Any board wishing to support SPI flash in U-Boot proper now just defines
> CONFIG_SPI and CONFIG_SPI_FLASH_ in its defconfig, Kconfig takes
> care of the rest.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/Kconfig | 2 ++
> arch/arm/mach-sunxi/Kconfig | 3 ---
> configs/libretech_all_h3_it_h5_defconfig | 2 --
> configs/libretech_all_h5_cc_h5_defconfig | 2 --
> configs/oceanic_5205_5inmfd_defconfig| 1 +
> configs/orangepi_win_defconfig | 1 +
> configs/pine64-lts_defconfig | 1 +
> configs/sopine_baseboard_defconfig | 1 +
> 8 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 7264d72bde..0f63bfdded 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1055,6 +1055,8 @@ config ARCH_SUNXI
> select DM_ETH
> select DM_GPIO
> select DM_I2C if I2C
> + select DM_SPI if SPI
> + select DM_SPI_FLASH if SPI
> select DM_KEYBOARD
> select DM_MMC if MMC
> select DM_SCSI if SCSI
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 2c18cf02d1..56ff1e197c 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -324,9 +324,6 @@ config MACH_SUN9I
> config MACH_SUN50I
> bool "sun50i (Allwinner A64)"
> select ARM64
> - select SPI
> - select DM_SPI if SPI
> - select DM_SPI_FLASH
> select PHY_SUN4I_USB
> select SUN6I_PRCM
> select SUNXI_DE2
> diff --git a/configs/libretech_all_h3_it_h5_defconfig
> b/configs/libretech_all_h3_it_h5_defconfig
> index 7f0e0be50b..cb7ffb4d7d 100644
> --- a/configs/libretech_all_h3_it_h5_defconfig
> +++ b/configs/libretech_all_h3_it_h5_defconfig
> @@ -7,9 +7,7 @@ CONFIG_DRAM_CLK=672
> CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> CONFIG_SPL_SPI_SUNXI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> -CONFIG_DM_SPI_FLASH=y
> CONFIG_SPI_FLASH_XMC=y
> CONFIG_SPI=y
> -CONFIG_DM_SPI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> diff --git a/configs/libretech_all_h5_cc_h5_defconfig
> b/configs/libretech_all_h5_cc_h5_defconfig
> index 25bfe52b32..c3aa4b1061 100644
> --- a/configs/libretech_all_h5_cc_h5_defconfig
> +++ b/configs/libretech_all_h5_cc_h5_defconfig
> @@ -7,10 +7,8 @@ CONFIG_DRAM_CLK=672
> CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> CONFIG_SPL_SPI_SUNXI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> -CONFIG_DM_SPI_FLASH=y
> CONFIG_SPI_FLASH_XMC=y
> CONFIG_SUN8I_EMAC=y
> CONFIG_SPI=y
> -CONFIG_DM_SPI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> diff --git a/configs/oceanic_5205_5inmfd_defconfig
> b/configs/oceanic_5205_5inmfd_defconfig
> index 9ba115c97d..7ce63ba665 100644
> --- a/configs/oceanic_5205_5inmfd_defconfig
> +++ b/configs/oceanic_5205_5inmfd_defconfig
> @@ -11,5 +11,6 @@ CONFIG_MMC0_CD_PIN=""
> CONFIG_SPL_SPI_SUNXI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_SUN8I_EMAC=y
> +CONFIG_SPI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> diff --git a/configs/orangepi_win_defconfig b/configs/orangepi_win_defconfig
> index 8c2179ba8b..133755291a 100644
> --- a/configs/orangepi_win_defconfig
> +++ b/configs/orangepi_win_defconfig
> @@ -9,5 +9,6 @@ CONFIG_SPL_SPI_SUNXI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_PHY_REALTEK=y
> CONFIG_SUN8I_EMAC=y
> +CONFIG_SPI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig
> index 6209e68e2d..75a77acc44 100644
> --- a/configs/pine64-lts_defconfig
> +++ b/configs/pine64-lts_defconfig
> @@ -11,5 +11,6 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> CONFIG_SPL_SPI_SUNXI=y
> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> CONFIG_SUN8I_EMAC=y
> +CONFIG_SPI=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_OHCI_HCD=y
> diff --git a/configs/sopine_baseboard_defconfig
> b/configs/sopine_baseboard_defconfig
> index 0093076dc5..982f7b0b67 100644
> --- a/configs/sopine_baseboard_defconfig
> +++ b/configs/sopine_baseboard_defconfig
> @@ -13,5 +13,6 @@
Re: [PATCH] vexpress64: semi_defconfig: disable CRC32 support
On Fri, Jan 21, 2022 at 04:36:04PM +, Andre Przywara wrote:
> Commit 270f8710f92f ("crc32: Add crc32 implementation using
> __builtin_aarch64_crc32b") enabled the usage of ARMv8 CRC instructions
> by default, for all arm64 builds. And indeed all Arm Ltd. v8 Cortex-A
> cores support the instructions, and they are mandatory starting with
> architecture revision v8.1, so realistically every known hardware
> implementation should support them.
>
> The Arm Fastmodel however defaults to the bare minimum ARMv8 feature set
> by default, which means v8.0 without the CRC instructions, so U-Boot
> hangs very early at the moment, without any output (the boot-wrapper or
> TF-A printing the last visible lines).
>
> Support for those instructions can be enabled on the model command line
> by either:
> -C cluster0.cpu0.enable_crc32=1 (for each core)
> or by using a higher architecture revision by default:
> -C cluster0.has_arm_v8-1=1(for each cluster)
> Of course any arch revision higher than v8.1 would work as well.
>
> But for the sake of a smooth out-of-the-box experience, let's just
> disable the usage of those instructions in the defconfig, to avoid
> random hangs without any clues.
>
> Reported-by: Ross Burton
> Signed-off-by: Andre Przywara
> Acked-by: Marek Vasut
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] MAINTAINERS: Update e-mail in Xen maintainership
On Wed, Jan 19, 2022 at 10:49:21PM +0200, Anastasiia Lukianenko wrote: > Changing e-mail because of leaving EPAM. > > Signed-off-by: Anastasiia Lukianenko > Reviewed-by: Oleksandr Andrushchenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] cmd: Add Kconfig option for multiprocessor cmds
On Mon, Jan 17, 2022 at 10:16:50AM +0100, Michal Simek wrote: > From: Ashok Reddy Soma > > Add Kconfig option(CONFIG_CMD_MP) to enable or disable multiprocessor > commands. Compile cmd/mp.c based on CONFIG_CMD_MP. > > Signed-off-by: Ashok Reddy Soma > Signed-off-by: Michal Simek Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] misc: mark write buffer const
On Tue, Jan 11, 2022 at 05:04:49PM +, John Keeping wrote: > The write operation in misc_ops already takes a "const void *" buffer, > but misc_write() takes a mutable "void *". There's no reason for this, > so make misc_write() consistent with the standard write() prototype. > > Signed-off-by: John Keeping > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] mkimage: struct stat.st_size may not be long
On Sat, Jan 15, 2022 at 08:12:56PM +0100, Heinrich Schuchardt wrote:
> The component st_size of struct stat is of type off_t. Depending on the
> system printing it it with %ld leads to a warning:
>
> tools/mkimage.c:438:54: warning: format '%ld' expects argument of type
> 'long int', but argument 5 has type
> 'off_t' {aka 'long long int'} [-Wformat=]
> 438 | "%s: Bad size: \"%s\" is not valid image: size %ld < %u\n",
> |~~^
> | |
> | long int
> |%lld
>
> When comparing an off_t value to a 32bit integer we should not convert to
> uint32_t but to off_t which may be wider.
>
> Reported-by: Milan P. Stanić
> Fixes: 331f0800f1a3 ("mkimage: allow -l to work on block devices on Linux")
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Mark Kettenis
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [resent][PATCH 3/3] mkimage: Allow to specify the signature algorithm on the command line
On Fri, Jan 14, 2022 at 10:21:19AM +0100, Jan Kiszka wrote: > From: Jan Kiszka > > This permits to prepare FIT image description that do not hard-code the > final choice of the signature algorithm, possibly requiring the user to > patch the sources. > > When -o is specified, this information is used in favor of the > 'algo' property in the signature node. Furthermore, that property is set > accordingly when writing the image. > > Signed-off-by: Jan Kiszka Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [resent][PATCH 2/3] mkimage: Drop unused OPT_STRING constant
On Fri, Jan 14, 2022 at 10:21:18AM +0100, Jan Kiszka wrote: > From: Jan Kiszka > > The actual opt string is inlined - and different. Seems this was a > left-over from older versions of 603e26f76346. > > Signed-off-by: Jan Kiszka > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [resent][PATCH 1/3] image-fit: Make string of algo parameter constant
On Fri, Jan 14, 2022 at 10:21:17AM +0100, Jan Kiszka wrote: > From: Jan Kiszka > > Modifications would be invalid. > > Signed-off-by: Jan Kiszka > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] tools/fitimage: make sure dumpimage still works when "@" are detected
On Mon, Jan 10, 2022 at 06:48:32PM +0100, Stefan Eichenberger wrote: > fit_verify_header fails if it detects unit addresses "@". However, this > will break tools like dumpimage on fit images which worked with previous > versions of the tool (e.g. 2020.04 vs 2021.07). As an example the output > of: > dumpimage -l > is: > FIT description: U-Boot fitImage for Linux Distribution > Created: Thu Jan 1 01:00:00 1970 > Image 0 (kernel@1) > Description: Linux kernel > Created: Thu Jan 1 01:00:00 1970 > Type: Kernel Image > Compression: gzip compressed > Data Size:6442456 Bytes = 6291.46 KiB = 6.14 MiB > Architecture: AArch64 > OS: Linux > Load Address: 0x8008 > Entry Point: 0x8008 > Hash algo:sha256 > Hash value: ... > Image 1 (fdt@freescale_fsl-s32g274a-evb.dtb) > Description: Flattened Device Tree blob > Created: Thu Jan 1 01:00:00 1970 > Type: Flat Device Tree > Compression: uncompressed > Data Size:39661 Bytes = 38.73 KiB = 0.04 MiB > Architecture: AArch64 > Hash algo:sha256 > Hash value: ... > Default Configuration: 'conf@freescale_fsl-s32g274a-evb.dtb' > Configuration 0 (conf@freescale_fsl-s32g274a-evb.dtb) > Description: 1 Linux kernel, FDT blob > Kernel: kernel@1 > FDT: fdt@freescale_fsl-s32g274a-evb.dtb > Hash algo:sha256 > Hash value: unavailable > > But with newer version it shows: > dumpimage -l > GP Header: Size d00dfeed LoadAddr 62f0a4 > > This commit will output a warning that unit addresses were detected but > will not fail: > dumpimage -l > Image contains unit addresses @, this will break signing > ... > > Signed-off-by: Stefan Eichenberger > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] tools/fitimage: remove redundant format check
On Mon, Jan 10, 2022 at 06:48:31PM +0100, Stefan Eichenberger wrote: > fit_extract_contents does a fit_check_format even thought it was already > checked during imagetool_verify_print_header. > Therefore, this check is not necessary. This commit removes the > redundancy. > > Signed-off-by: Stefan Eichenberger > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH] dts: automatically build necessary .dtb files
On Mon, Jan 10, 2022 at 02:34:41PM +0100, Rasmus Villemoes wrote: > When building for a custom board, it is quite common to maintain a > private branch which include some defconfig and .dts files. But to > hook up those .dts files requires modifying a file "belonging" to > upstream U-Boot, the arch/*/dts/Makefile. Forward-porting that branch > to a newer upstream then often results in a conflict which, while it > is trivial to resolve by hand, makes it harder to have a CI do "try to > build our board against latest upstream". > > The .config usually includes information on precisely what .dtb(s) are > needed, so to avoid having to modify the Makefile, simply add the > files in (SPL_)OF_LIST to dtb-y. > > A technicality is that (SPL_)OF_LIST is not always defined, so rework > the Kconfig symbols so that (SPL_)OF_LIST is always defined (when > (SPL_)OF_CONTROL), but only prompted for in the cases which used to be > their "depends on". > > nios2 and microblaze already have something like this in their > dts/Makefile, and the rationale in commit 41f59f68539 is similar to > the above. So this simply generalizes existing practice. Followup > patches could remove the logic in those two makefiles, just as there's > potential for moving some common boilerplate from all the > arch/*/dts/Makefile files to the new scripts/Makefile.dts. > > Signed-off-by: Rasmus Villemoes > --- > arch/arc/dts/Makefile| 2 ++ > arch/arm/dts/Makefile| 2 ++ > arch/m68k/dts/Makefile | 2 ++ > arch/microblaze/dts/Makefile | 2 ++ > arch/mips/dts/Makefile | 2 ++ > arch/nds32/dts/Makefile | 2 ++ > arch/nios2/dts/Makefile | 2 ++ > arch/powerpc/dts/Makefile| 2 ++ > arch/riscv/dts/Makefile | 2 ++ > arch/sandbox/dts/Makefile| 2 ++ > arch/sh/dts/Makefile | 2 ++ > arch/x86/dts/Makefile| 2 ++ > arch/xtensa/dts/Makefile | 2 ++ > dts/Kconfig | 8 > scripts/Makefile.dts | 3 +++ > 15 files changed, 33 insertions(+), 4 deletions(-) > create mode 100644 scripts/Makefile.dts > > diff --git a/arch/arc/dts/Makefile b/arch/arc/dts/Makefile > index 515fe1fe53..532a8131c5 100644 > --- a/arch/arc/dts/Makefile > +++ b/arch/arc/dts/Makefile > @@ -8,6 +8,8 @@ dtb-$(CONFIG_TARGET_EMSDP) += emsdp.dtb > dtb-$(CONFIG_TARGET_HSDK) += hsdk.dtb hsdk-4xd.dtb > dtb-$(CONFIG_TARGET_IOT_DEVKIT) += iot_devkit.dtb > > +include $(srctree)/scripts/Makefile.dts > + > targets += $(dtb-y) > > DTC_FLAGS += -R 4 -p 0x1000 > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > index b3e2a9c9d7..ef58be0381 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -1163,6 +1163,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) += > imx8mm-cl-iot-gate-optee.dtb > > dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb > > +include $(srctree)/scripts/Makefile.dts > + > targets += $(dtb-y) > > # Add any required device tree compiler flags here > diff --git a/arch/m68k/dts/Makefile b/arch/m68k/dts/Makefile > index fdd435bc34..7988522eb9 100644 > --- a/arch/m68k/dts/Makefile > +++ b/arch/m68k/dts/Makefile > @@ -18,6 +18,8 @@ dtb-$(CONFIG_TARGET_M5373EVB) += M5373EVB.dtb > dtb-$(CONFIG_TARGET_AMCORE) += amcore.dtb > dtb-$(CONFIG_TARGET_STMARK2) += stmark2.dtb > > +include $(srctree)/scripts/Makefile.dts > + > targets += $(dtb-y) > > DTC_FLAGS += -R 4 -p 0x1000 > diff --git a/arch/microblaze/dts/Makefile b/arch/microblaze/dts/Makefile > index 4690dc1b9f..427a8f9aac 100644 > --- a/arch/microblaze/dts/Makefile > +++ b/arch/microblaze/dts/Makefile > @@ -2,6 +2,8 @@ > > dtb-y += $(shell echo $(CONFIG_DEFAULT_DEVICE_TREE)).dtb > > +include $(srctree)/scripts/Makefile.dts > + > targets += $(dtb-y) > > DTC_FLAGS += -R 4 -p 0x1000 > diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile > index 215283cfa0..95144b24dc 100644 > --- a/arch/mips/dts/Makefile > +++ b/arch/mips/dts/Makefile > @@ -34,6 +34,8 @@ dtb-$(CONFIG_SOC_JR2) += jr2_pcb110.dtb jr2_pcb111.dtb > serval2_pcb112.dtb > dtb-$(CONFIG_SOC_SERVALT) += servalt_pcb116.dtb > dtb-$(CONFIG_SOC_SERVAL) += serval_pcb105.dtb serval_pcb106.dtb > > +include $(srctree)/scripts/Makefile.dts > + > targets += $(dtb-y) > > # Add any required device tree compiler flags here > diff --git a/arch/nds32/dts/Makefile b/arch/nds32/dts/Makefile > index a8e23ad9ad..5a09e3b45b 100644 > --- a/arch/nds32/dts/Makefile > +++ b/arch/nds32/dts/Makefile > @@ -2,6 +2,8 @@ > > dtb-$(CONFIG_TARGET_ADP_AG101P) += ag101p.dtb > dtb-$(CONFIG_TARGET_ADP_AE3XX) += ae3xx.dtb > +include $(srctree)/scripts/Makefile.dts > + > targets += $(dtb-y) > > DTC_FLAGS += -R 4 -p 0x1000 > diff --git a/arch/nios2/dts/Makefile b/arch/nios2/dts/Makefile > index 0014acfdfb..2b29fa90f6 100644 > --- a/arch/nios2/dts/Makefile > +++ b/arch/nios2/dts/Makefile > @@ -2,6 +2,8 @@ > > dtb-y += $(CONFIG_DEFAULT_DEVICE_TREE:"%"=%).dtb > > +include $(srctree)/scripts/Makefile.dts > + > targets
[RFC PATCH] efi_loader: clean up uefi secure boot image verification logic
From: Ilias Apalodimas
We currently distinguish between signed and non signed PE/COFF
executables while trying to authenticate signatures and/or sha256
hashes in db and dbx. That code duplication can be avoided.
On sha256 hashes we don't really care if the image is signed or
not. The logic can be implemented in
1. Is the sha256 of the image in dbx
2. Is the image signed with a certificate that's found in db and
not in dbx
3. The image carries a cert which is signed by a cert in db (and
not in dbx, and the image can be verified against the former)
4. Is the sha256 of the image in db
So weed out the 'special' case handling unsigned images.
While at it move the checking of a hash outside the certificate
verification loop which isn't really needed and check for the hash
only once. Also allow a mix of signatures and hashes in db instead
of explicitly breaking out the sha verification loop if a signature
happens to be added first.
It's worth noting that (2) only works if the certificate is self
signed, but that canb be fixed in a following patch.
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_image_loader.c | 84 ++-
lib/efi_loader/efi_signature.c| 2 +-
2 files changed, 15 insertions(+), 71 deletions(-)
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 255613eb72ba..53d54ca42f5c 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -516,63 +516,16 @@ err:
}
#ifdef CONFIG_EFI_SECURE_BOOT
-/**
- * efi_image_unsigned_authenticate() - authenticate unsigned image with
- * SHA256 hash
- * @regs: List of regions to be verified
- *
- * If an image is not signed, it doesn't have a signature. In this case,
- * its message digest is calculated and it will be compared with one of
- * hash values stored in signature databases.
- *
- * Return: true if authenticated, false if not
- */
-static bool efi_image_unsigned_authenticate(struct efi_image_regions *regs)
-{
- struct efi_signature_store *db = NULL, *dbx = NULL;
- bool ret = false;
-
- dbx = efi_sigstore_parse_sigdb(L"dbx");
- if (!dbx) {
- EFI_PRINT("Getting signature database(dbx) failed\n");
- goto out;
- }
-
- db = efi_sigstore_parse_sigdb(L"db");
- if (!db) {
- EFI_PRINT("Getting signature database(db) failed\n");
- goto out;
- }
-
- /* try black-list first */
- if (efi_signature_lookup_digest(regs, dbx)) {
- EFI_PRINT("Image is not signed and its digest found in
\"dbx\"\n");
- goto out;
- }
-
- /* try white-list */
- if (efi_signature_lookup_digest(regs, db))
- ret = true;
- else
- EFI_PRINT("Image is not signed and its digest not found in
\"db\" or \"dbx\"\n");
-
-out:
- efi_sigstore_free(db);
- efi_sigstore_free(dbx);
-
- return ret;
-}
-
/**
* efi_image_authenticate() - verify a signature of signed image
* @efi: Pointer to image
* @efi_size: Size of @efi
*
- * A signed image should have its signature stored in a table of its PE header.
+ * An image should have its signature stored in a table of its PE header.
* So if an image is signed and only if if its signature is verified using
- * signature databases, an image is authenticated.
- * If an image is not signed, its validity is checked by using
- * efi_image_unsigned_authenticated().
+ * signature databases or if it's sha256 is found in db an image is
+ * authenticated.
+ *
* TODO:
* When AuditMode==0, if the image's signature is not found in
* the authorized database, or is found in the forbidden database,
@@ -608,14 +561,7 @@ static bool efi_image_authenticate(void *efi, size_t
efi_size)
if (!efi_image_parse(new_efi, efi_size, , ,
_len)) {
EFI_PRINT("Parsing PE executable image failed\n");
- goto err;
- }
-
- if (!wincerts) {
- /* The image is not signed */
- ret = efi_image_unsigned_authenticate(regs);
-
- goto err;
+ goto out;
}
/*
@@ -624,18 +570,18 @@ static bool efi_image_authenticate(void *efi, size_t
efi_size)
db = efi_sigstore_parse_sigdb(L"db");
if (!db) {
EFI_PRINT("Getting signature database(db) failed\n");
- goto err;
+ goto out;
}
dbx = efi_sigstore_parse_sigdb(L"dbx");
if (!dbx) {
EFI_PRINT("Getting signature database(dbx) failed\n");
- goto err;
+ goto out;
}
if (efi_signature_lookup_digest(regs, dbx)) {
EFI_PRINT("Image's digest was found in \"dbx\"\n");
- goto err;
+ goto out;
}
/*
@@ -729,20 +675,18 @@ static bool efi_image_authenticate(void *efi,
Re: [PULL] Pull request for u-boot/master v2024.01 = u-boot-stm32-20220124
On Mon, Jan 24, 2022 at 01:21:33PM +0100, Patrice CHOTARD wrote: > Hi Tom > > Please pull the STM32 related patches for u-boot/master, v2022.04: > u-boot-stm32-20220124 > > CI status: > https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/10748 > > Thanks > Patrice > > The following changes since commit d323242b62920be08e3a2efb1a61bd9bdf9ed583: > > Merge https://source.denx.de/u-boot/custodians/u-boot-sh (2022-01-23 > 09:54:49 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20220124 > > for you to fetch changes up to 22c0815ecaa538de51a5204caceec850d5965126: > > configs: stm32mp15: Enable OF_BOARD flag (2022-01-24 11:03:21 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] imx: imx8mn_beacon: Enable TrustZone
When the board was added, enabling tzc380 was left off by mistake. Signed-off-by: Adam Ford diff --git a/board/beacon/imx8mn/spl.c b/board/beacon/imx8mn/spl.c index b5263ccfd7..bb51be01c5 100644 --- a/board/beacon/imx8mn/spl.c +++ b/board/beacon/imx8mn/spl.c @@ -122,6 +122,8 @@ void board_init_f(ulong dummy) hang(); } + enable_tzc380(); + /* DDR initialization */ spl_dram_init(); -- 2.32.0
Re: [PATCH 17/23] video: Convert CONFIG_VIDEO_LOGO to Kconfig
On Mon, Jan 24, 2022 at 10:39:27AM +0100, Merlijn Wajer wrote: > Hi Pali, Tom, Simon, > > On 23/01/2022 16:11, Pali Rohár wrote: > > > > > > But I didn't see anything about the USB DM conversion. > > > > > > > > Of course, as there are waiting other patches and other emails without > > > > replies, it is not a wise idea to start working on something other or > > > > starting discussion about something totally new if existing things are > > > > waiting for maintainers... > > > > > > I believe it was someone else that is interested in N900 that said they > > > would look at it. > > > > Yea, for USB it was Merlijn. He wrote me that would reply later to this > > thread. This thread started about video and not USB, so there is just > > big mix of things and I forgot about what we are talking here... > > I have a tight deadline in the next two weeks, but after that I can pick up > this work (USB DM conversion for the N900). I assume it won't take much more > than a week or two to then get this ready, so let's say I can try to send a > RFC patch by mid February? Does that block/conflict u-boot release/merge > planning? If sooner is required, please let me know and I'll try my best to > accommodate that somehow. That timing is probably fine, but please speak up if you're not able to pick up the work again when you expect to as that sounds about like what you said for having things around November? But stuff comes up and I understand that. Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] usb: xhci: reset endpoint on USB stall
Hi Bin, On 2022-01-05 02:21, Bin Meng wrote: > Hi Stefan, > > On Wed, Jan 5, 2022 at 3:48 AM Stefan Agner wrote: >> >> Bin Meng, >> >> On 2021-09-27 17:14, Marek Vasut wrote: >> > On 9/27/21 2:42 PM, Stefan Agner wrote: >> >> There are devices which cause a USB stall when trying to read strings. >> >> Specifically Arduino Mega R3 stalls when trying to read the product >> >> string. >> >> >> >> The stall currently remains unhandled, and subsequent retries submit new >> >> transfers on a stopped endpoint which ultimately cause a crash in >> >> abort_td(): >> >> WARN halted endpoint, queueing URB anyway. >> >> XHCI control transfer timed out, aborting... >> >> Unexpected XHCI event TRB, skipping... (3affe040 1300 >> >> 02008401) >> >> BUG at drivers/usb/host/xhci-ring.c:505/abort_td()! >> >> BUG! >> >> resetting ... >> >> >> >> Linux seems to be able to recover from the stall by issuing a >> >> TRB_RESET_EP command. >> >> >> >> Introduce reset_ep() which issues a TRB_RESET_EP followed by setting the >> >> transfer ring dequeue pointer via TRB_SET_DEQ. This allows to properly >> >> recover from a USB stall error and continue communicating with the USB >> >> device. >> >> >> >> Signed-off-by: Stefan Agner >> > >> > I hope to get AB/RB from Bin here, then it can go into this release I >> > think. >> >> Any chance you could have a look at this to get it into this release :) >> > > Sorry I missed this. I suspect it's too late for 2022.01 to include > such big changes :( I understand. Now that 2022.01 is out, could you have a look at this? -- Stefan
Re: [PATCH 00/16] tools: Add support for signing devicetree blobs
Hi Rasmus,
On Fri, 26 Nov 2021 at 01:36, Rasmus Villemoes
wrote:
>
> On 12/11/2021 20.28, Simon Glass wrote:
> > At present mkimage supports signing FITs, the standard U-Boot image type.
> >
> > Various people are opposed to using FIT since:
> >
> > a) it requires adding support for FIT into other bootloaders, notably
> >UEFI
> > b) it requires packaging a kernel in this standard U-Boot format, meaning
> >that distros must run 'mkimage' and deal with the kernel and initrd
> >being inside a FIT
> >
> > The kernel and initrd can be dealt with in other ways. But without FIT,
> > we have no standard way of signing and grouping FDT files. Instead we must
> > include them in the distro as separate files.
> >
> > In particular, some sort of mechanism for verifying FDT files is needed.
> > One option would be to tack a signature on before or after the file,
> > processing it accordingly. But due to the nature of the FDT binary format,
> > it is possible to embed a signature inside the FDT itself, which is very
> > convenient.
> >
> > This series provides a tool, fdt_sign, which can add a signature to an
> > FDT. The signature can be checked later, preventing any change to the FDT,
> > other than in permitted nodes (e.g. /chosen).
> >
> > This series also provides a fdt_check_sign tool, used to check signatures.
>
> This could be useful. Not because I'm interested in signing device-tree
> blobs as such, but as a replacement for the current incomprehensible way
> FIT images are signed and verified. This seems to be a much better and
> simpler scheme, that avoids (can avoid) the overly simplistic approach
> of signing just image nodes, and the way too complex
> signing-configurations-and-then-add-a-property-saying-which-nodes-I-signed-and-sign-that-as-well.
That property is not actually signed. It is just a hint.
>
> In order not to hard-code anything in the tool about /chosen or whatnot,
> make the rule be that the blob (I'll use that word, because it can as
> well be a FIT image containing kernel image+initramfs etc., or a FIT
> containing a U-Boot script) has a property in the top node
>
> unsigned-nodes = "/chosen", "/signatures";
>
> (maybe it could be
>
> unsigned-nodes = < >
>
> but that may make the implementation a little more complex). That
> property itself is by definition part of what gets signed. The verifier
> can and should choose to reject the whole thing if "/" is mentioned.
If you list unsigned nodes, then the signature will become invalid if
a new image or config is added later.
>
> Then, please, for debugging, inside the /signatures node, beside the
> signature data, also add a copy of the offset/len pairs that were
> actually hashed, and that hash value.
>
> /signatures {
> hashed-regions = ;
> hash-1 {
> value = 0xabcd;
> algo = "sha256";
> };
> signature-1 {
>...
> };
> ...
The offsets may change whenever the devicetree is modified.
>
> And make the tool start by adding dummy properties, so those strings
> "hashed-regions", "value", "algo", "signer" and whatever other property
> names are used already exist in the string table. After that, fill in
> the actual values - and have the rule that the entire string table is
> hashed, not just some initial part of it.
The hashed part of the string table is the part used for each
signature. It is in fact the whole table at the time that signing
takes place. It's just that the table may expand late.
>
> The verifier will of course not rely on /signatures/hashed-regions, but
> will compute the regions itself based on /unsigned-nodes (and implicitly
> add a region consisting of the string table and the memreserve table).
>
> Then we'd have a generic scheme for signing blobs, disentangled from
> whether they are actually describing hardware or used as a generic
> container format. And instead of "image" or "conf", we could mark a
> public key as being required for "whole-blob" (bikeshedding welcome),
> using that same scheme for verifying a container with a boot script and
> a container with kernel+initramfs+dtbs.
What does this 'whole blob' help with?
> > For now there is absolutely no configurability in the signature mechanism.
> > It would of course be possible to adjust which nodes are signed, as is
>
> Yes, let the blob itself define that. And don't add any ad hoc "oh, skip
> a property if it is called data-offset or data or...".
We don't want to sign the data because it is already hashed once.
There is no point and it just makes verification slower.
For data-offset we want tools to be able to move the data around, e.g.
for memory-allocation reasons.
Overall I can grant that you are describing another way of doing
things, but I'm not sure what it would bring us.
The scheme in this series is aimed at a different purpose: signing a
devicetree blob, rather than a FIT.
Regards,
Simon
[PATCH] clk: ccf: correct the test on the parent uclass in clk_enable/clk_disable
It is safe to check if the uclass id on the device is UCLASS_CLK
before to call the clk_ functions, but today this comparison is
not done on the device used in API: clkp->dev->parent
but on the device himself: clkp->dev.
This patch corrects this behavior and tests if the parent device
is a clock device before to call the clock API, clk_enable or
clk_disable, on this device.
Fixes: 0520be0f67e3 ("clk: prograte clk enable/disable to parent")
Signed-off-by: Patrick Delaunay
---
drivers/clk/clk-uclass.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index d245b672fa..8b6981a307 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -652,7 +652,7 @@ int clk_enable(struct clk *clk)
return 0;
}
if (clkp->dev->parent &&
- device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
+ device_get_uclass_id(clkp->dev->parent) ==
UCLASS_CLK) {
ret =
clk_enable(dev_get_clk_ptr(clkp->dev->parent));
if (ret) {
printf("Enable %s failed\n",
@@ -726,7 +726,7 @@ int clk_disable(struct clk *clk)
}
if (clkp && clkp->dev->parent &&
- device_get_uclass_id(clkp->dev) == UCLASS_CLK) {
+ device_get_uclass_id(clkp->dev->parent) == UCLASS_CLK) {
ret = clk_disable(dev_get_clk_ptr(clkp->dev->parent));
if (ret) {
printf("Disable %s failed\n",
--
2.25.1
[PATCH 06/14] video: Drop CONFIG_VIDEO_BMP_LOGO
This option is not implemented anymore. Drop it. Signed-off-by: Simon Glass --- README| 1 - include/configs/T102xRDB.h| 1 - include/configs/T104xRDB.h| 1 - include/configs/apalis_imx6.h | 1 - include/configs/aristainetos2.h | 1 - include/configs/cm_fx6.h | 2 -- include/configs/colibri-imx6ull.h | 1 - include/configs/colibri_imx6.h| 1 - include/configs/colibri_imx7.h| 4 include/configs/colibri_vf.h | 1 - include/configs/embestmx6boards.h | 1 - include/configs/gw_ventana.h | 1 - include/configs/imx6-engicam.h| 2 -- include/configs/imxrt1050-evk.h | 2 -- include/configs/ls1021aqds.h | 2 -- include/configs/ls1021atwr.h | 2 -- include/configs/mx6cuboxi.h | 1 - include/configs/mx6sabre_common.h | 1 - include/configs/mx6sxsabresd.h| 1 - include/configs/mx6ul_14x14_evk.h | 1 - include/configs/mx7dsabresd.h | 4 include/configs/opos6uldev.h | 1 - include/configs/pico-imx6.h | 1 - include/configs/pico-imx6ul.h | 1 - include/configs/pico-imx7d.h | 4 include/configs/pxm2.h| 1 - include/configs/rut.h | 1 - include/configs/wandboard.h | 1 - scripts/config_whitelist.txt | 1 - 29 files changed, 43 deletions(-) diff --git a/README b/README index 4fa369c4dd8..816d9c4dfb2 100644 --- a/README +++ b/README @@ -1016,7 +1016,6 @@ The following options need to be configured: CONFIG_VIDEO CONFIG_VIDEO_SW_CURSOR CONFIG_VGA_AS_SINGLE_DEVICE - CONFIG_VIDEO_BMP_LOGO The DIU driver will look for the 'video-mode' environment variable, and if defined, enable the DIU as a console during diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h index d24cfce8b3b..71c96102dd4 100644 --- a/include/configs/T102xRDB.h +++ b/include/configs/T102xRDB.h @@ -372,7 +372,6 @@ #undef CONFIG_FSL_DIU_FB /* RDB doesn't support DIU */ #ifdef CONFIG_FSL_DIU_FB #define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x18) -#define CONFIG_VIDEO_BMP_LOGO #define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS /* * With CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS, flash I/O is really slow, so diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index f60010f7876..0a8694f186e 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -361,7 +361,6 @@ #ifdef CONFIG_FSL_DIU_FB #define CONFIG_FSL_DIU_CH7301 #define CONFIG_SYS_DIU_ADDR(CONFIG_SYS_CCSRBAR + 0x18) -#define CONFIG_VIDEO_BMP_LOGO #endif #endif diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h index c165f618be9..0a4ad980801 100644 --- a/include/configs/apalis_imx6.h +++ b/include/configs/apalis_imx6.h @@ -45,7 +45,6 @@ #define CONFIG_USBD_HS /* Framebuffer and LCD */ -#define CONFIG_VIDEO_BMP_LOGO #define CONFIG_IMX_HDMI #define CONFIG_IMX_VIDEO_SKIP diff --git a/include/configs/aristainetos2.h b/include/configs/aristainetos2.h index e6397378e45..14163ae8b81 100644 --- a/include/configs/aristainetos2.h +++ b/include/configs/aristainetos2.h @@ -443,7 +443,6 @@ /* Framebuffer */ /* check this console not needed, after test remove it */ #define CONFIG_IMX_VIDEO_SKIP -#define CONFIG_VIDEO_BMP_LOGO #define CONFIG_IMX6_PWM_PER_CLK6600 diff --git a/include/configs/cm_fx6.h b/include/configs/cm_fx6.h index 40bc8215480..df9c7d37221 100644 --- a/include/configs/cm_fx6.h +++ b/include/configs/cm_fx6.h @@ -176,8 +176,6 @@ /* Display */ #define CONFIG_IMX_HDMI -#define CONFIG_VIDEO_BMP_LOGO - /* EEPROM */ #endif /* __CONFIG_CM_FX6_H */ diff --git a/include/configs/colibri-imx6ull.h b/include/configs/colibri-imx6ull.h index 787fe33941b..db8807a5569 100644 --- a/include/configs/colibri-imx6ull.h +++ b/include/configs/colibri-imx6ull.h @@ -164,7 +164,6 @@ #if defined(CONFIG_DM_VIDEO) #define MXS_LCDIF_BASE MX6UL_LCDIF1_BASE_ADDR -#define CONFIG_VIDEO_BMP_LOGO #endif #endif /* __COLIBRI_IMX6ULL_CONFIG_H */ diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h index c8e733bc366..d03263c96c6 100644 --- a/include/configs/colibri_imx6.h +++ b/include/configs/colibri_imx6.h @@ -35,7 +35,6 @@ #define CONFIG_USBD_HS /* Framebuffer and LCD */ -#define CONFIG_VIDEO_BMP_LOGO #define CONFIG_IMX_HDMI #define CONFIG_IMX_VIDEO_SKIP diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h index faf27ba4fa3..876e2d84884 100644 --- a/include/configs/colibri_imx7.h +++ b/include/configs/colibri_imx7.h @@ -196,8 +196,4 @@ #define CONFIG_USBD_HS -#if defined(CONFIG_DM_VIDEO) -#define CONFIG_VIDEO_BMP_LOGO -#endif - #endif diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h index 62f85185b76..3711e429a70 100644 --- a/include/configs/colibri_vf.h +++ b/include/configs/colibri_vf.h @@ -15,7 +15,6 @@ #include
[PATCH 00/14] video: Drop old CFB code
There is still quite a bit of cruft in the video subsystem. Mainly this is users of the now-removed CONFIG_VIDEO, cfb_console and CONFIG_LCD. This series removes most of the first two. The exception is videomodes.c and its header, since these are used by sunxi. It looks like the code could be removed, but I did not attempt it. This is left for the sunxi maintainer. The LCD clean-up can come later. Once done, we can rename CONFIG_DM_VIDEO to CONFIG_VIDEO, thus completing the migration. Simon Glass (14): video: Drop cfg_console video: nokia_rx51: Drop obsolete video code video: siemens: Drop unused video code video: nexell: Drop unused and invalid code video: Drop video_fb header video: Drop CONFIG_VIDEO_BMP_LOGO video: Drop references to CONFIG_VIDEO et al video: Clean up the uclass header video: Drop da8xx-fb video: fsl: colibri_vf: Drop FSL DCU driver video: Drop FSL DIU driver video: mxs: Drop old video code video: Convert CONFIG_VIDEO_BCM2835 to Kconfig video: Drop formike driver README| 18 - arch/arm/cpu/armv7/ls102xa/soc.c |4 - arch/arm/include/asm/arch-ls102xa/config.h|1 - arch/arm/include/asm/mach-imx/mx5_video.h |5 - .../mach-nexell/include/mach/display_dev.h|7 +- board/aristainetos/aristainetos.c |1 - board/freescale/common/Makefile |4 - board/freescale/common/dcu_sii9022a.c | 248 --- board/freescale/common/dcu_sii9022a.h | 12 - board/freescale/common/diu_ch7301.c | 217 -- board/freescale/common/diu_ch7301.h | 12 - board/freescale/ls1021aiot/Makefile |1 - board/freescale/ls1021aiot/dcu.c | 48 - board/freescale/ls1021aqds/Makefile |1 - board/freescale/ls1021aqds/dcu.c | 110 - board/freescale/ls1021atwr/Makefile |1 - board/freescale/ls1021atwr/dcu.c | 48 - board/freescale/mx51evk/Makefile |1 - board/freescale/mx53loco/Makefile |1 - board/freescale/t104xrdb/Makefile |1 - board/freescale/t104xrdb/diu.c| 84 - board/kosagi/novena/novena_spl.c | 23 - board/nokia/rx51/rx51.c | 19 - board/siemens/common/board.c |3 - board/siemens/common/factoryset.c |7 - board/siemens/common/factoryset.h |3 - board/siemens/pxm2/board.c| 189 -- board/siemens/rut/board.c | 247 --- board/socrates/socrates.c |1 - board/toradex/colibri_vf/Makefile |1 - board/toradex/colibri_vf/colibri_vf.c | 62 - board/toradex/colibri_vf/dcu.c| 38 - cmd/Kconfig |2 +- cmd/bdinfo.c |2 +- cmd/bmp.c |4 +- cmd/cls.c |2 - common/fdt_support.c |2 +- common/stdio.c|4 +- configs/colibri_vf_defconfig |1 - configs/nokia_rx51_defconfig |3 - configs/rpi_0_w_defconfig |1 + configs/rpi_2_defconfig |1 + configs/rpi_3_32b_defconfig |1 + configs/rpi_3_b_plus_defconfig|1 + configs/rpi_3_defconfig |1 + configs/rpi_4_32b_defconfig |1 + configs/rpi_4_defconfig |1 + configs/rpi_arm64_defconfig |1 + configs/rpi_defconfig |1 + doc/usage/bootmenu.rst|5 - drivers/pci/pci_rom.c |1 - drivers/video/Kconfig | 129 +- drivers/video/Makefile|5 - drivers/video/cfb_console.c | 1865 - drivers/video/da8xx-fb.c | 1048 - drivers/video/da8xx-fb.h | 115 - drivers/video/formike.c | 513 - drivers/video/fsl_dcu_fb.c| 549 - drivers/video/fsl_diu_fb.c| 416 drivers/video/imx/mxc_ipuv3_fb.c |1 - drivers/video/mxsfb.c | 90 - drivers/video/nexell_display.c| 18 +- drivers/video/omap3_dss.c | 29 - drivers/video/sunxi/sunxi_display.c |1 - include/asm-generic/global_data.h |2 +- include/configs/T102xRDB.h| 13 - include/configs/T104xRDB.h| 20 - include/configs/apalis_imx6.h |1 - include/configs/aristainetos2.h |1 - include/configs/cm_fx6.h |
[PATCH v2] Allow colon in PXE bootfile URLs
- U-boot's PXE flow supports prefixing your bootfile name with an
IP address to fetch from a server other than the DHCP server,
e.g. `hostIPaddr:bootfilename`:
https://github.com/u-boot/u-boot/commit/a93907c43f847f076dd0e34ee3b69b5e8e6d0d29
- However, this breaks bootfile paths which contain a colon, e.g.
`f0:ad:4e:10:1b:87/7/pxelinux.cfg/default`
- This patch checks whether the `hostIPaddr` prefix is a valid
IP address before overriding the serverIP otherwise the whole
bootfile path is preserved
Signed-off-by: Lyle Franklin
---
net/net.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/net.c b/net/net.c
index 072a82d8f9..57ed77795a 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1538,14 +1538,18 @@ int is_serverip_in_cmd(void)
int net_parse_bootfile(struct in_addr *ipaddr, char *filename, int max_len)
{
char *colon;
+ struct in_addr ip;
if (net_boot_file_name[0] == '\0')
return 0;
colon = strchr(net_boot_file_name, ':');
if (colon) {
- if (ipaddr)
- *ipaddr = string_to_ip(net_boot_file_name);
+ ip = string_to_ip(net_boot_file_name);
+ if (ipaddr && ip.s_addr)
+ *ipaddr = ip;
+ }
+ if (ip.s_addr) {
strncpy(filename, colon + 1, max_len);
} else {
strncpy(filename, net_boot_file_name, max_len);
--
2.31.1
[PULL] Pull request for u-boot/master v2024.01 = u-boot-stm32-20220124
Hi Tom
Please pull the STM32 related patches for u-boot/master, v2022.04:
u-boot-stm32-20220124
CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/10748
Thanks
Patrice
The following changes since commit d323242b62920be08e3a2efb1a61bd9bdf9ed583:
Merge https://source.denx.de/u-boot/custodians/u-boot-sh (2022-01-23 09:54:49
-0500)
are available in the Git repository at:
https://source.denx.de/u-boot/custodians/u-boot-stm.git
tags/u-boot-stm32-20220124
for you to fetch changes up to 22c0815ecaa538de51a5204caceec850d5965126:
configs: stm32mp15: Enable OF_BOARD flag (2022-01-24 11:03:21 +0100)
- stm32mp15: sync DT with kernel v5.16
- stm32mp15: Enable OF_BOARD config flag
- DHCOM: sync DT with kernel 5.15.12
- stm32mp: Fix USB boot device
- stm32mp: Remove bootcount activation
- stm32mp: Fix board_get_alt_info_mmc()
- board: stm32mp1: solve compilation issue when ENV_IS_IN_MMC is deactivated
- stm32prog: add partition name in treat_partition_list error messages
Heinrich Schuchardt (1):
stm32mp: fix board_get_alt_info_mmc()
Marek Vasut (4):
arm: stm32mp: Fix USB boot device report
ARM: dts: stm32: Add DFU support for DHCOR recovery
ARM: dts: stm32: Synchronize DHCOR DTs with Linux 5.15.12
ARM: dts: stm32: Synchronize DHCOM DTs with Linux 5.15.12
Patrice Chotard (1):
configs: stm32mp15: Enable OF_BOARD flag
Patrick Delaunay (5):
stm32mp: remove the bootcount activation
stm32mp: correct the dependency for bootcount configs
arm: dts: stm32mp15: alignment with v5.16
board: stm32mp1: solve compilation issue when ENV_IS_IN_MMC is deactivated
stm32prog: add partition name in treat_partition_list error messages
arch/arm/dts/Makefile | 1 -
arch/arm/dts/stm32mp15-pinctrl.dtsi| 8 +-
arch/arm/dts/stm32mp151.dtsi | 19 +-
arch/arm/dts/stm32mp157a-avenger96.dts | 8 -
arch/arm/dts/stm32mp157a-dhcor-avenger96.dts | 38 ++
arch/arm/dts/stm32mp15xx-dhcom-drc02.dts | 162 +---
arch/arm/dts/stm32mp15xx-dhcom-drc02.dtsi | 165
arch/arm/dts/stm32mp15xx-dhcom-pdk2-u-boot.dtsi| 4 +
arch/arm/dts/stm32mp15xx-dhcom-pdk2.dts| 14 +-
arch/arm/dts/stm32mp15xx-dhcom-pdk2.dtsi | 325
arch/arm/dts/stm32mp15xx-dhcom-picoitx-u-boot.dtsi | 6 +-
arch/arm/dts/stm32mp15xx-dhcom-picoitx.dts | 88 +
arch/arm/dts/stm32mp15xx-dhcom-picoitx.dtsi| 147 +++
...p15xx-dhcom.dtsi => stm32mp15xx-dhcom-som.dtsi} | 387 ++
arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 43 +-
.../dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi| 2 +
arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 202 +-
arch/arm/dts/stm32mp15xx-dhcor-avenger96.dtsi | 431 +
arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi | 7 +-
...dhcor-io3v3.dtsi => stm32mp15xx-dhcor-som.dtsi} | 30 +-
arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 50 +++
arch/arm/dts/stm32mp15xx-dkx.dtsi | 2 +-
arch/arm/mach-stm32mp/Kconfig | 11 +-
arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c| 12 +-
arch/arm/mach-stm32mp/spl.c| 2 +-
board/st/common/stm32mp_dfu.c | 2 +-
board/st/stm32mp1/stm32mp1.c | 6 +-
configs/stm32mp15_dhcor_basic_defconfig| 14 +-
include/configs/stm32mp15_common.h | 1 -
include/configs/stm32mp15_dh_dhsom.h | 7 +
30 files changed, 1510 insertions(+), 684 deletions(-)
delete mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
create mode 100644 arch/arm/dts/stm32mp157a-dhcor-avenger96.dts
create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-drc02.dtsi
create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-pdk2.dtsi
create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-picoitx.dtsi
rename arch/arm/dts/{stm32mp15xx-dhcom.dtsi => stm32mp15xx-dhcom-som.dtsi}
(56%)
create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dtsi
rename arch/arm/dts/{stm32mp15xx-dhcor-io3v3.dtsi =>
stm32mp15xx-dhcor-som.dtsi} (91%)
Re: [PATCH] configs: stm32mp15: Enable OF_BOARD flag
On 1/20/22 08:19, Patrice Chotard wrote:
> Since commit 985503439762 ("fdt: Don't call board_fdt_blob_setup()
> without OF_BOARD") board_fdt_blob_setup() is no more called on
> STM32MP platforms in trusted boot which hangs during boot process.
>
> Enable OF_BOARD flag to fix this issue.
>
> Signed-off-by: Patrice Chotard
> ---
>
> arch/arm/mach-stm32mp/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
> index a6c7fc5bfd..1ef426c0e0 100644
> --- a/arch/arm/mach-stm32mp/Kconfig
> +++ b/arch/arm/mach-stm32mp/Kconfig
> @@ -40,6 +40,7 @@ config STM32MP15x
> select CPU_V7A
> select CPU_V7_HAS_NONSEC
> select CPU_V7_HAS_VIRT
> + select OF_BOARD if TFABOOT
> select OF_BOARD_SETUP
> select PINCTRL_STM32
> select STM32_RCC
Applied to u-boot-stm/master
Thanks
Patrice
Re: [PATCH] stm32prog: add partition name in treat_partition_list error messages
Hi Patrick
On 1/18/22 10:33, Patrick Delaunay wrote:
> Add the partition name and remove the line number in error messages
> of treat_partition_list() to provide correct information to user of
> STM32CubeProgrammer.
>
> The "line number" value was confusing because it is incorrect here;
> the index in part_array[] is not aligned with the line number in
> the parsed Layout file, because the empty lines and the lines beginning
> by '#' are skipped during the first parsing in parse_flash_layout().
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> index 3b6ca4e773..61cba157fd 100644
> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/stm32prog.c
> @@ -835,8 +835,8 @@ static int treat_partition_list(struct stm32prog_data
> *data)
> /* skip partition with IP="none" */
> if (part->target == STM32PROG_NONE) {
> if (IS_SELECT(part)) {
> - stm32prog_err("Layout: selected none phase =
> 0x%x",
> - part->id);
> + stm32prog_err("Layout: selected none phase =
> 0x%x for part %s",
> + part->id, part->name);
> return -EINVAL;
> }
> continue;
> @@ -844,14 +844,14 @@ static int treat_partition_list(struct stm32prog_data
> *data)
>
> if (part->id == PHASE_FLASHLAYOUT ||
> part->id > PHASE_LAST_USER) {
> - stm32prog_err("Layout: invalid phase = 0x%x",
> - part->id);
> + stm32prog_err("Layout: invalid phase = 0x%x for part
> %s",
> + part->id, part->name);
> return -EINVAL;
> }
> for (j = i + 1; j < data->part_nb; j++) {
> if (part->id == data->part_array[j].id) {
> - stm32prog_err("Layout: duplicated phase 0x%x at
> line %d and %d",
> - part->id, i, j);
> + stm32prog_err("Layout: duplicated phase 0x%x
> for part %s and %s",
> + part->id, part->name,
> data->part_array[j].name);
> return -EINVAL;
> }
> }
Applied to u-boot-stm/master
Thanks
Patrice
Re: [PATCH] board: stm32mp1: solve compilation issue when ENV_IS_IN_MMC is deactivated
Hi Patrick
On 1/11/22 16:37, Patrick Delaunay wrote:
> Solve compilation issue on undefined CONFIG_SYS_MMC_ENV_DEV when
> CONFIG_ENV_IS_IN_MMC is deactivated on STMicroelectronics boards
> defconfig
>
> Fixes: 9f97193616f1 ("board: stm32mp1: use CONFIG_SYS_MMC_ENV_DEV when
> available")
> Signed-off-by: Patrick Delaunay
> ---
>
> board/st/stm32mp1/stm32mp1.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 45f2ca81a6..fff1880e5b 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -890,8 +890,10 @@ const char *env_ext4_get_dev_part(void)
>
> int mmc_get_env_dev(void)
> {
> - if (CONFIG_SYS_MMC_ENV_DEV >= 0)
> - return CONFIG_SYS_MMC_ENV_DEV;
> + const int mmc_env_dev = CONFIG_IS_ENABLED(ENV_IS_IN_MMC,
> (CONFIG_SYS_MMC_ENV_DEV), (-1));
> +
> + if (mmc_env_dev >= 0)
> + return mmc_env_dev;
>
> /* use boot instance to select the correct mmc device identifier */
> return mmc_get_boot();
Applied to u-boot-stm/master
Thanks
Patrice
Re: [PATCH 2/2] ARM: dts: stm32: Synchronize DHCOM DTs with Linux 5.15.12
Hi Marek
On 12/30/21 23:46, Marek Vasut wrote:
> Synchronize DH DHCOM DTs with Linux commit 25960cafa06e ("Linux 5.15.12").
> There is no functional change to the resulting DTs. The eeprom0 alias and
> PHY reset GPIO are now reinstated in SoM u-boot dtsi.
>
> Signed-off-by: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> ---
> arch/arm/dts/stm32mp15xx-dhcom-drc02.dts | 162 +---
> arch/arm/dts/stm32mp15xx-dhcom-drc02.dtsi | 165
> .../dts/stm32mp15xx-dhcom-pdk2-u-boot.dtsi| 4 +
> arch/arm/dts/stm32mp15xx-dhcom-pdk2.dts | 14 +-
> arch/arm/dts/stm32mp15xx-dhcom-pdk2.dtsi | 325 +++
> .../dts/stm32mp15xx-dhcom-picoitx-u-boot.dtsi | 6 +-
> arch/arm/dts/stm32mp15xx-dhcom-picoitx.dts| 88 +---
> arch/arm/dts/stm32mp15xx-dhcom-picoitx.dtsi | 147 +++
> ...-dhcom.dtsi => stm32mp15xx-dhcom-som.dtsi} | 387 +++---
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi| 43 +-
> 10 files changed, 917 insertions(+), 424 deletions(-)
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-drc02.dtsi
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-pdk2.dtsi
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-picoitx.dtsi
> rename arch/arm/dts/{stm32mp15xx-dhcom.dtsi => stm32mp15xx-dhcom-som.dtsi}
> (56%)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> b/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> index 4948ccd4014..1ef9ac29cea 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> @@ -2,166 +2,14 @@
> /*
> * Copyright (C) 2020 Marek Vasut
> */
> +/dts-v1/;
>
> -#include "stm32mp15xx-dhcom.dtsi"
> +#include "stm32mp151.dtsi"
> +#include "stm32mp15xc.dtsi"
> +#include "stm32mp15xx-dhcom-som.dtsi"
> +#include "stm32mp15xx-dhcom-drc02.dtsi"
>
> / {
> model = "DH Electronics STM32MP15xx DHCOM DRC02";
> compatible = "dh,stm32mp15xx-dhcom-drc02", "st,stm32mp1xx";
> -
> - aliases {
> - serial0 =
> - serial1 =
> - serial2 =
> - };
> -
> - chosen {
> - stdout-path = "serial0:115200n8";
> - };
> -};
> -
> - {
> - status = "disabled";
> -};
> -
> - {
> - status = "disabled";
> -};
> -
> - {
> - /*
> - * NOTE: On DRC02, the RS485_RX_En is controlled by a separate
> - * GPIO line, however the STM32 UART driver assumes RX happens
> - * during TX anyway and that it only controls drive enable DE
> - * line. Hence, the RX is always enabled here.
> - */
> - usb-hub {
> - gpio-hog;
> - gpios = <8 0>;
> - output-high;
> - line-name = "rs485-rx-en";
> - };
> -};
> -
> - {
> - gpio-line-names = "", "", "", "",
> - "", "", "", "",
> - "", "", "", "Out1",
> - "Out2", "", "", "";
> -};
> -
> - {
> - gpio-line-names = "In1", "", "", "",
> - "", "", "", "",
> - "In2", "", "", "",
> - "", "", "", "";
> -
> - /*
> - * NOTE: The USB Hub on the DRC02 needs a reset signal to be
> - * pulled high in order to be detected by the USB Controller.
> - * This signal should be handled by USB power sequencing in
> - * order to reset the Hub when USB bus is powered down, but
> - * so far there is no such functionality.
> - */
> - usb-hub {
> - gpio-hog;
> - gpios = <2 0>;
> - output-high;
> - line-name = "usb-hub-reset";
> - };
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins_a>;
> - i2c-scl-rising-time-ns = <185>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> - /* spare dmas for other usage */
> - /delete-property/dmas;
> - /delete-property/dma-names;
> - status = "okay";
> -
> - eeprom@50 {
> - compatible = "atmel,24c04";
> - reg = <0x50>;
> - pagesize = <16>;
> - };
> -};
> -
> - { /* TP7/TP8 */
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins_a>;
> - i2c-scl-rising-time-ns = <185>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> - /* spare dmas for other usage */
> - /delete-property/dmas;
> - /delete-property/dma-names;
> -};
> -
> - {
> - /*
> - * On DRC02, the SoM does not have SDIO WiFi. The pins
> - * are used for on-board microSD slot instead.
> - */
> - pinctrl-names = "default", "opendrain", "sleep";
> - pinctrl-0 = <_b4_pins_a>;
> - pinctrl-1 = <_b4_od_pins_a>;
> - pinctrl-2 = <_b4_sleep_pins_a>;
> - cd-gpios = < 10 GPIO_ACTIVE_HIGH>;
> - disable-wp;
> - st,neg-edge;
> - bus-width = <4>;
> - vmmc-supply = <>;
> - vqmmc-supply = <>;
> - mmc-ddr-3_3v;
> - status = "okay";
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins_a>;
> -
Re: [PATCH 2/2] ARM: dts: stm32: Synchronize DHCOM DTs with Linux 5.15.12
Hi Marek
On 12/30/21 23:46, Marek Vasut wrote:
> Synchronize DH DHCOM DTs with Linux commit 25960cafa06e ("Linux 5.15.12").
> There is no functional change to the resulting DTs. The eeprom0 alias and
> PHY reset GPIO are now reinstated in SoM u-boot dtsi.
>
> Signed-off-by: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> ---
> arch/arm/dts/stm32mp15xx-dhcom-drc02.dts | 162 +---
> arch/arm/dts/stm32mp15xx-dhcom-drc02.dtsi | 165
> .../dts/stm32mp15xx-dhcom-pdk2-u-boot.dtsi| 4 +
> arch/arm/dts/stm32mp15xx-dhcom-pdk2.dts | 14 +-
> arch/arm/dts/stm32mp15xx-dhcom-pdk2.dtsi | 325 +++
> .../dts/stm32mp15xx-dhcom-picoitx-u-boot.dtsi | 6 +-
> arch/arm/dts/stm32mp15xx-dhcom-picoitx.dts| 88 +---
> arch/arm/dts/stm32mp15xx-dhcom-picoitx.dtsi | 147 +++
> ...-dhcom.dtsi => stm32mp15xx-dhcom-som.dtsi} | 387 +++---
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi| 43 +-
> 10 files changed, 917 insertions(+), 424 deletions(-)
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-drc02.dtsi
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-pdk2.dtsi
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcom-picoitx.dtsi
> rename arch/arm/dts/{stm32mp15xx-dhcom.dtsi => stm32mp15xx-dhcom-som.dtsi}
> (56%)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> b/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> index 4948ccd4014..1ef9ac29cea 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-drc02.dts
> @@ -2,166 +2,14 @@
> /*
> * Copyright (C) 2020 Marek Vasut
> */
> +/dts-v1/;
>
> -#include "stm32mp15xx-dhcom.dtsi"
> +#include "stm32mp151.dtsi"
> +#include "stm32mp15xc.dtsi"
> +#include "stm32mp15xx-dhcom-som.dtsi"
> +#include "stm32mp15xx-dhcom-drc02.dtsi"
>
> / {
> model = "DH Electronics STM32MP15xx DHCOM DRC02";
> compatible = "dh,stm32mp15xx-dhcom-drc02", "st,stm32mp1xx";
> -
> - aliases {
> - serial0 =
> - serial1 =
> - serial2 =
> - };
> -
> - chosen {
> - stdout-path = "serial0:115200n8";
> - };
> -};
> -
> - {
> - status = "disabled";
> -};
> -
> - {
> - status = "disabled";
> -};
> -
> - {
> - /*
> - * NOTE: On DRC02, the RS485_RX_En is controlled by a separate
> - * GPIO line, however the STM32 UART driver assumes RX happens
> - * during TX anyway and that it only controls drive enable DE
> - * line. Hence, the RX is always enabled here.
> - */
> - usb-hub {
> - gpio-hog;
> - gpios = <8 0>;
> - output-high;
> - line-name = "rs485-rx-en";
> - };
> -};
> -
> - {
> - gpio-line-names = "", "", "", "",
> - "", "", "", "",
> - "", "", "", "Out1",
> - "Out2", "", "", "";
> -};
> -
> - {
> - gpio-line-names = "In1", "", "", "",
> - "", "", "", "",
> - "In2", "", "", "",
> - "", "", "", "";
> -
> - /*
> - * NOTE: The USB Hub on the DRC02 needs a reset signal to be
> - * pulled high in order to be detected by the USB Controller.
> - * This signal should be handled by USB power sequencing in
> - * order to reset the Hub when USB bus is powered down, but
> - * so far there is no such functionality.
> - */
> - usb-hub {
> - gpio-hog;
> - gpios = <2 0>;
> - output-high;
> - line-name = "usb-hub-reset";
> - };
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins_a>;
> - i2c-scl-rising-time-ns = <185>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> - /* spare dmas for other usage */
> - /delete-property/dmas;
> - /delete-property/dma-names;
> - status = "okay";
> -
> - eeprom@50 {
> - compatible = "atmel,24c04";
> - reg = <0x50>;
> - pagesize = <16>;
> - };
> -};
> -
> - { /* TP7/TP8 */
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins_a>;
> - i2c-scl-rising-time-ns = <185>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> - /* spare dmas for other usage */
> - /delete-property/dmas;
> - /delete-property/dma-names;
> -};
> -
> - {
> - /*
> - * On DRC02, the SoM does not have SDIO WiFi. The pins
> - * are used for on-board microSD slot instead.
> - */
> - pinctrl-names = "default", "opendrain", "sleep";
> - pinctrl-0 = <_b4_pins_a>;
> - pinctrl-1 = <_b4_od_pins_a>;
> - pinctrl-2 = <_b4_sleep_pins_a>;
> - cd-gpios = < 10 GPIO_ACTIVE_HIGH>;
> - disable-wp;
> - st,neg-edge;
> - bus-width = <4>;
> - vmmc-supply = <>;
> - vqmmc-supply = <>;
> - mmc-ddr-3_3v;
> - status = "okay";
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins_a>;
> -
Re: [PATCH 1/2] ARM: dts: stm32: Synchronize DHCOR DTs with Linux 5.15.12
Hi Marek
On 12/30/21 23:46, Marek Vasut wrote:
> Synchronize DH DHCOR DTs with Linux commit 25960cafa06e ("Linux 5.15.12").
> There is no functional change to the resulting DTs. The eeprom0 alias is
> now reinstated in SoM u-boot dtsi, the PHY reset GPIO is reinstated in AV96
> u-boot dtsi.
>
> Signed-off-by: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> ---
> arch/arm/dts/Makefile | 1 -
> arch/arm/dts/stm32mp157a-avenger96.dts| 8 -
> arch/arm/dts/stm32mp157a-dhcor-avenger96.dts | 38 ++
> .../stm32mp15xx-dhcor-avenger96-u-boot.dtsi | 2 +
> arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts | 202 +---
> arch/arm/dts/stm32mp15xx-dhcor-avenger96.dtsi | 431 ++
> arch/arm/dts/stm32mp15xx-dhcor-io1v8.dtsi | 7 +-
> ...-io3v3.dtsi => stm32mp15xx-dhcor-som.dtsi} | 30 +-
> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi| 8 +
> 9 files changed, 503 insertions(+), 224 deletions(-)
> delete mode 100644 arch/arm/dts/stm32mp157a-avenger96.dts
> create mode 100644 arch/arm/dts/stm32mp157a-dhcor-avenger96.dts
> create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dtsi
> rename arch/arm/dts/{stm32mp15xx-dhcor-io3v3.dtsi =>
> stm32mp15xx-dhcor-som.dtsi} (91%)
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b3e2a9c9d77..03064632999 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1098,7 +1098,6 @@ dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
>
> dtb-$(CONFIG_STM32MP15x) += \
> stm32mp157a-dk1.dtb \
> - stm32mp157a-avenger96.dtb \
> stm32mp157a-icore-stm32mp1-ctouch2.dtb \
> stm32mp157a-icore-stm32mp1-edimm2.2.dtb \
> stm32mp157a-microgea-stm32mp1-microdev2.0.dtb \
> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
> b/arch/arm/dts/stm32mp157a-avenger96.dts
> deleted file mode 100644
> index 9c165104fbe..000
> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> -/*
> - * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
> - * Author: Manivannan Sadhasivam
> - */
> -
> -/* This is kept for backward compatibility and will be removed */
> -#include "stm32mp15xx-dhcor-avenger96.dts"
> diff --git a/arch/arm/dts/stm32mp157a-dhcor-avenger96.dts
> b/arch/arm/dts/stm32mp157a-dhcor-avenger96.dts
> new file mode 100644
> index 000..2e3c9fbb4eb
> --- /dev/null
> +++ b/arch/arm/dts/stm32mp157a-dhcor-avenger96.dts
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> +/*
> + * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
> + * Author: Manivannan Sadhasivam
> + * Copyright (C) 2020 Marek Vasut
> + *
> + * DHCOR STM32MP1 variant:
> + * DHCR-STM32MP157A-C065-R102-V18-SPI-C-01LG
> + * DHCOR PCB number: 586-100 or newer
> + * Avenger96 PCB number: 588-200 or newer
> + */
> +
> +/dts-v1/;
> +
> +#include "stm32mp157.dtsi"
> +#include "stm32mp15xc.dtsi"
> +#include "stm32mp15xx-dhcor-som.dtsi"
> +#include "stm32mp15xx-dhcor-avenger96.dtsi"
> +
> +/ {
> + model = "Arrow Electronics STM32MP157A Avenger96 board";
> + compatible = "arrow,stm32mp157a-avenger96", "dh,stm32mp157a-dhcor-som",
> + "st,stm32mp157";
> +};
> +
> +_can1 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_can1_pins_b>;
> + pinctrl-1 = <_can1_sleep_pins_b>;
> + status = "disabled";
> +};
> +
> +_can2 {
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_can2_pins_a>;
> + pinctrl-1 = <_can2_sleep_pins_a>;
> + status = "disabled";
> +};
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
> index c96eba99c5e..6e6543b5e4a 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
> @@ -21,6 +21,8 @@
>
>
> {
> + phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> +
> mdio0 {
> ethernet-phy@7 {
> reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
> b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
> index 0e860e5cf88..76ac5a873c1 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
> @@ -7,206 +7,12 @@
>
> /dts-v1/;
>
> -#include "stm32mp15xx-dhcor-io1v8.dtsi"
> -#include "stm32mp15xx-dhcor-avenger96-u-boot.dtsi"
> +#include "stm32mp151.dtsi"
> +#include "stm32mp15xc.dtsi"
> +#include "stm32mp15xx-dhcor-som.dtsi"
> +#include "stm32mp15xx-dhcor-avenger96.dtsi"
>
> / {
> model = "Arrow Electronics STM32MP15xx Avenger96 board";
> compatible = "arrow,stm32mp15xx-avenger96", "st,stm32mp15x";
> -
> - aliases {
> - eeprom0 =
> - ethernet0 =
> - mmc0 =
> - serial0 =
> - serial1 =
> - };
> -
> - chosen {
> -
Re: [PATCH] arm: dts: stm32mp15: alignment with v5.16
Hi Patrick
On 12/17/21 16:30, Patrick Delaunay wrote:
> Device tree alignment with Linux kernel v5.16-rc5
> - ARM: dts: stm32: set otg-rev on stm32mp151
> - ARM: dts: stm32: use usbphyc ck_usbo_48m as USBH OHCI clock on stm32mp151
> - ARM: dts: stm32: fix AV96 board SAI2 pin muxing on stm32mp15
> - ARM: dts: stm32: fix SAI sub nodes register range
> - ARM: dts: stm32: fix STUSB1600 Type-C irq level on stm32mp15xx-dkx
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp15-pinctrl.dtsi | 8
> arch/arm/dts/stm32mp151.dtsi| 19 ++-
> arch/arm/dts/stm32mp15xx-dkx.dtsi | 2 +-
> 3 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> index 5b60ecbd71..d3553e0f01 100644
> --- a/arch/arm/dts/stm32mp15-pinctrl.dtsi
> +++ b/arch/arm/dts/stm32mp15-pinctrl.dtsi
> @@ -1179,7 +1179,7 @@
> };
> };
>
> - sai2a_pins_c: sai2a-4 {
> + sai2a_pins_c: sai2a-2 {
> pins {
> pinmux = , /* SAI2_SCK_A */
>, /* SAI2_SD_A */
> @@ -1190,7 +1190,7 @@
> };
> };
>
> - sai2a_sleep_pins_c: sai2a-5 {
> + sai2a_sleep_pins_c: sai2a-sleep-2 {
> pins {
> pinmux = , /* SAI2_SCK_A
> */
>, /* SAI2_SD_A
> */
> @@ -1235,14 +1235,14 @@
> };
> };
>
> - sai2b_pins_c: sai2a-4 {
> + sai2b_pins_c: sai2b-2 {
> pins1 {
> pinmux = ; /* SAI2_SD_B */
> bias-disable;
> };
> };
>
> - sai2b_sleep_pins_c: sai2a-sleep-5 {
> + sai2b_sleep_pins_c: sai2b-sleep-2 {
> pins {
> pinmux = ; /* SAI2_SD_B
> */
> };
> diff --git a/arch/arm/dts/stm32mp151.dtsi b/arch/arm/dts/stm32mp151.dtsi
> index 8e0a0bc1dd..5a2be00758 100644
> --- a/arch/arm/dts/stm32mp151.dtsi
> +++ b/arch/arm/dts/stm32mp151.dtsi
> @@ -842,7 +842,7 @@
> #sound-dai-cells = <0>;
>
> compatible = "st,stm32-sai-sub-a";
> - reg = <0x4 0x1c>;
> + reg = <0x4 0x20>;
> clocks = < SAI1_K>;
> clock-names = "sai_ck";
> dmas = < 87 0x400 0x01>;
> @@ -852,7 +852,7 @@
> sai1b: audio-controller@4400a024 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-b";
> - reg = <0x24 0x1c>;
> + reg = <0x24 0x20>;
> clocks = < SAI1_K>;
> clock-names = "sai_ck";
> dmas = < 88 0x400 0x01>;
> @@ -873,7 +873,7 @@
> sai2a: audio-controller@4400b004 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-a";
> - reg = <0x4 0x1c>;
> + reg = <0x4 0x20>;
> clocks = < SAI2_K>;
> clock-names = "sai_ck";
> dmas = < 89 0x400 0x01>;
> @@ -883,7 +883,7 @@
> sai2b: audio-controller@4400b024 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-b";
> - reg = <0x24 0x1c>;
> + reg = <0x24 0x20>;
> clocks = < SAI2_K>;
> clock-names = "sai_ck";
> dmas = < 90 0x400 0x01>;
> @@ -904,7 +904,7 @@
> sai3a: audio-controller@4400c004 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-a";
> - reg = <0x04 0x1c>;
> + reg = <0x04 0x20>;
> clocks = < SAI3_K>;
> clock-names = "sai_ck";
> dmas = < 113 0x400 0x01>;
> @@ -914,7 +914,7 @@
> sai3b: audio-controller@4400c024 {
> #sound-dai-cells = <0>;
> compatible = "st,stm32-sai-sub-b";
> - reg = <0x24 0x1c>;
> + reg = <0x24 0x20>;
> clocks = < SAI3_K>;
> clock-names = "sai_ck";
> dmas = < 114 0x400 0x01>;
> @@ -1103,6 +1103,7 @@
> g-np-tx-fifo-size = <32>;
> g-tx-fifo-size = <256 16 16 16 16 16 16 16>;
>
Re: [PATCH 1/1] stm32mp: fix board_get_alt_info_mmc()
Hi Heinrich
On 1/11/22 15:58, Heinrich Schuchardt wrote:
> MAX_SEARCH_PARTITIONS is the highest possible partition number.
> Do not skip the last partition in board_get_alt_info_mmc().
>
> Signed-off-by: Heinrich Schuchardt
> ---
> board/st/common/stm32mp_dfu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
> index a3f0da5b5b..fa48b2a35e 100644
> --- a/board/st/common/stm32mp_dfu.c
> +++ b/board/st/common/stm32mp_dfu.c
> @@ -57,7 +57,7 @@ static void board_get_alt_info_mmc(struct udevice *dev,
> char *buf)
> first = false;
> }
>
> - for (p = 1; p < MAX_SEARCH_PARTITIONS; p++) {
> + for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) {
> if (part_get_info(desc, p, ))
> continue;
> if (!first)
Applied to u-boot-stm/master
Thanks
Patrice
Re: [PATCH 2/2] stm32mp: correct the dependency for bootcount configs
Hi Patrick On 12/7/21 10:05, Patrick Delaunay wrote: > Default value for CONFIG_SYS_BOOTCOUNT_SINGLEWORD and > CONFIG_SYS_BOOTCOUNT_ADDR are only needed when > CONFIG_BOOTCOUNT_GENERIC is used. > > This patch avoids to define these configs when an other bootcount backend > is activated, for example for CONFIG_BOOTCOUNT_ENV. > > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig > index 2fa4ea4d5c..2819944df3 100644 > --- a/arch/arm/mach-stm32mp/Kconfig > +++ b/arch/arm/mach-stm32mp/Kconfig > @@ -194,7 +194,7 @@ config PRE_CON_BUF_SZ > config BOOTSTAGE_STASH_ADDR > default 0xC300 > > -if BOOTCOUNT_LIMIT > +if BOOTCOUNT_GENERIC > config SYS_BOOTCOUNT_SINGLEWORD > default y > Applied to u-boot-stm/master Thanks Patrice
Re: [PATCH 1/2] stm32mp: remove the bootcount activation
Hi Patrick On 12/7/21 10:05, Patrick Delaunay wrote: > Today the bootcount is not managed by the Linux kernel for STM32MP15 as > we don't have driver to update the used backup register in TAMP and the > recovery command still executes the normal bootcmd with > 'altbootcmd=run bootcmd'. > > So the bootcount feature is never used, the config CONFIG_BOOTCOUNT_LIMIT > and the associated environment variable 'altbootcmd' can be removed to > reduce the U-Boot size. > > Each boards can re-enable this feature later in their defconfig, if it is > needed, with the expected backend, for example CONFIG_BOOTCOUNT_GENERIC > or CONFIG_BOOTCOUNT_ENV. > > CC: Marek Vasut > Signed-off-by: Patrick Delaunay > --- > > arch/arm/mach-stm32mp/Kconfig | 8 > include/configs/stm32mp15_common.h | 1 - > 2 files changed, 9 deletions(-) > > diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig > index a6c7fc5bfd..2fa4ea4d5c 100644 > --- a/arch/arm/mach-stm32mp/Kconfig > +++ b/arch/arm/mach-stm32mp/Kconfig > @@ -68,9 +68,7 @@ choice > config TARGET_ST_STM32MP15x > bool "STMicroelectronics STM32MP15x boards" > select STM32MP15x > - imply BOOTCOUNT_LIMIT > imply BOOTSTAGE > - imply CMD_BOOTCOUNT > imply CMD_BOOTSTAGE > imply CMD_CLS if CMD_BMP > imply DISABLE_CONSOLE > @@ -85,9 +83,7 @@ config TARGET_ST_STM32MP15x > config TARGET_MICROGEA_STM32MP1 > bool "Engicam MicroGEA STM32MP1 SOM" > select STM32MP15x > - imply BOOTCOUNT_LIMIT > imply BOOTSTAGE > - imply CMD_BOOTCOUNT > imply CMD_BOOTSTAGE > imply CMD_CLS if CMD_BMP > imply DISABLE_CONSOLE > @@ -112,9 +108,7 @@ config TARGET_MICROGEA_STM32MP1 > config TARGET_ICORE_STM32MP1 > bool "Engicam i.Core STM32MP1 SOM" > select STM32MP15x > - imply BOOTCOUNT_LIMIT > imply BOOTSTAGE > - imply CMD_BOOTCOUNT > imply CMD_BOOTSTAGE > imply CMD_CLS if CMD_BMP > imply DISABLE_CONSOLE > @@ -136,8 +130,6 @@ config TARGET_ICORE_STM32MP1 > config TARGET_DH_STM32MP1_PDK2 > bool "DH STM32MP1 PDK2" > select STM32MP15x > - imply BOOTCOUNT_LIMIT > - imply CMD_BOOTCOUNT > help > Target the DH PDK2 development kit with STM32MP15x SoM. > > diff --git a/include/configs/stm32mp15_common.h > b/include/configs/stm32mp15_common.h > index dab679f71e..8cf97d73ad 100644 > --- a/include/configs/stm32mp15_common.h > +++ b/include/configs/stm32mp15_common.h > @@ -138,7 +138,6 @@ > #endif > > #define STM32MP_EXTRA \ > - "altbootcmd=run bootcmd\0" \ > "env_check=if env info -p -d -q; then env save; fi\0" \ > "boot_net_usb_start=true\0" > Applied to u-boot-stm/master Thanks Patrice
Re: [PATCH 2/2] ARM: dts: stm32: Add DFU support for DHCOR recovery
Hi Marek
On 12/6/21 21:58, Marek Vasut wrote:
> This patch configures U-Boot SPL for DHCOR SoM to permit DFU upload of
> SPL and subsequent u-boot.itb for recovery or commissioning purposes.
>
> To start U-Boot on DHCOR based board, e.g. Avenger96, proceed as follows:
> - Install dfu-util on the host PC (in debian this is package 'dfu-util')
>
> - Power off the Avenger96 board.
> - Connect both USB-serial console and USB-OTG microB ports to host PC.
> - Switch Avenger96 to USB boot mode -- BOOT0..2 switches all set to 0.
> - Power on the Avenger96 board.
> - Verify using '$ dmesg' that a new device has been detected as follows:
> New USB device found, idVendor=0483, idProduct=df11, bcdDevice= 2.00
> New USB device strings: Mfr=1, Product=2, SerialNumber=3
> Product: DFU in HS Mode @Device ID /0x500, @Revision ID /0x
> Manufacturer: STMicroelectronics
>
> - Upload U-Boot SPL:
> $ dfu-util -a 1 -D u-boot-spl.stm32
> - Upload U-Boot proper:
> $ dfu-util -a 0 -D u-boot.itb
>
> - At this point, SPL will wait for user to press "Ctrl-C" on serial
> console. When ready to interact with U-Boot, press Ctrl-C to start
> the bootloader.
>
> Signed-off-by: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> ---
> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 42 ++
> configs/stm32mp15_dhcor_basic_defconfig| 14 ++--
> include/configs/stm32mp15_dh_dhsom.h | 7
> 3 files changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> index 502cd95da05..71375510b4a 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> @@ -27,6 +27,7 @@
>
> {
> u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> };
>
> _pins_a {
> @@ -38,6 +39,15 @@
>
> {
> u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +
> + regulators {
> + u-boot,dm-spl;
> + };
> +};
> +
> +_regulators {
> + u-boot,dm-spl;
> };
>
> {
> @@ -152,3 +162,35 @@
> u-boot,dm-pre-reloc;
> };
> };
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_hs {
> + u-boot,dm-spl;
> +};
> +
> + {
> + u-boot,dm-spl;
> +};
> +
> +_port0 {
> + u-boot,dm-spl;
> +};
> +
> +_port1 {
> + u-boot,dm-spl;
> +};
> +
> +_io {
> + u-boot,dm-spl;
> +};
> +
> +_usb {
> + u-boot,dm-spl;
> +};
> diff --git a/configs/stm32mp15_dhcor_basic_defconfig
> b/configs/stm32mp15_dhcor_basic_defconfig
> index 2356de76baf..87980d2570d 100644
> --- a/configs/stm32mp15_dhcor_basic_defconfig
> +++ b/configs/stm32mp15_dhcor_basic_defconfig
> @@ -16,6 +16,7 @@ CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0xc200
> CONFIG_FIT=y
> CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_LOAD_FIT_ADDRESS=0xc100
> CONFIG_SPL_FIT_SOURCE="board/dhelectronics/dh_stm32mp1/u-boot-dhcor.its"
> # CONFIG_USE_SPL_FIT_GENERATOR is not set
> CONFIG_BOOTDELAY=1
> @@ -25,12 +26,17 @@ CONFIG_BOARD_EARLY_INIT_F=y
> CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=3
> +CONFIG_SPL_ENV_SUPPORT=y
> CONFIG_SPL_I2C=y
> CONFIG_SPL_MTD_SUPPORT=y
> CONFIG_SPL_DM_SPI_FLASH=y
> CONFIG_SPL_POWER=y
> +CONFIG_SPL_RAM_SUPPORT=y
> +CONFIG_SPL_RAM_DEVICE=y
> CONFIG_SPL_SPI_FLASH_MTD=y
> CONFIG_SYS_SPI_U_BOOT_OFFS=0x8
> +CONFIG_SPL_USB_GADGET=y
> +CONFIG_SPL_DFU=y
> CONFIG_SYS_PROMPT="STM32MP> "
> # CONFIG_CMD_ELF is not set
> # CONFIG_CMD_EXPORTENV is not set
> @@ -76,6 +82,7 @@ CONFIG_USE_ENV_SPI_MODE=y
> CONFIG_ENV_SPI_MODE=0x0
> CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SPL_ENV_IS_NOWHERE=y
> CONFIG_NET_RANDOM_ETHADDR=y
> CONFIG_IP_DEFRAG=y
> CONFIG_TFTP_BLOCKSIZE=1536
> @@ -84,7 +91,6 @@ CONFIG_SPL_BLOCK_CACHE=y
> CONFIG_DFU_MMC=y
> CONFIG_DFU_MTD=y
> CONFIG_DFU_RAM=y
> -CONFIG_DFU_VIRT=y
> CONFIG_GPIO_HOG=y
> CONFIG_DM_HWSPINLOCK=y
> CONFIG_HWSPINLOCK_STM32=y
> @@ -113,18 +119,20 @@ CONFIG_PHY_MICREL_KSZ90X1=y
> CONFIG_DM_ETH=y
> CONFIG_DWC_ETH_QOS=y
> CONFIG_PHY=y
> +CONFIG_SPL_PHY=y
> CONFIG_PHY_STM32_USBPHYC=y
> CONFIG_PINCONF=y
> # CONFIG_SPL_PINCTRL_FULL is not set
> CONFIG_PINCTRL_STMFX=y
> CONFIG_DM_PMIC=y
> -# CONFIG_SPL_PMIC_CHILDREN is not set
> CONFIG_PMIC_STPMIC1=y
> CONFIG_DM_REGULATOR=y
> +CONFIG_SPL_DM_REGULATOR=y
> CONFIG_DM_REGULATOR_FIXED=y
> CONFIG_DM_REGULATOR_GPIO=y
> CONFIG_DM_REGULATOR_STM32_VREFBUF=y
> CONFIG_DM_REGULATOR_STPMIC1=y
> +CONFIG_SPL_DM_REGULATOR_STPMIC1=y
> CONFIG_REMOTEPROC_STM32_COPRO=y
> CONFIG_DM_RTC=y
> CONFIG_RTC_STM32=y
> @@ -136,8 +144,10 @@ CONFIG_STM32_SPI=y
> CONFIG_SYSRESET_SYSCON=y
> CONFIG_USB=y
> CONFIG_DM_USB_GADGET=y
> +CONFIG_SPL_DM_USB_GADGET=y
> CONFIG_USB_EHCI_HCD=y
> CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_DWC2=y
> CONFIG_USB_HOST_ETHER=y
> CONFIG_USB_ETHER_ASIX=y
> CONFIG_USB_GADGET=y
Re: [PATCH 1/2] arm: stm32mp: Fix USB boot device report
Hi Marek On 12/6/21 21:58, Marek Vasut wrote: > In case the SoC reports the boot device type is USB, it means the SPL was > loaded via BootROM DFU mode. Currently the spl_boot_device() returns boot > device as USB host, change it to DFU instead, so the SPL can continue the > DFU boot and load U-Boot via DFU. > > Signed-off-by: Marek Vasut > Cc: Patrice Chotard > Cc: Patrick Delaunay > --- > arch/arm/mach-stm32mp/spl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c > index 405eff68a3b..51fe0698fab 100644 > --- a/arch/arm/mach-stm32mp/spl.c > +++ b/arch/arm/mach-stm32mp/spl.c > @@ -43,7 +43,7 @@ u32 spl_boot_device(void) > case BOOT_SERIAL_UART_8: > return BOOT_DEVICE_UART; > case BOOT_SERIAL_USB_OTG: > - return BOOT_DEVICE_USB; > + return BOOT_DEVICE_DFU; > case BOOT_FLASH_NAND_FMC: > return BOOT_DEVICE_NAND; > case BOOT_FLASH_NOR_QSPI: Applied to u-boot-stm/master Thanks Patrice
Re: [PATCH 13/14] video: Convert CONFIG_VIDEO_BCM2835 to Kconfig
On 23/01/2022 15:04, Simon Glass wrote: This converts the following to Kconfig: CONFIG_VIDEO_BCM2835 This is the final ad-hoc CONFIG_VIDEO_... to convert. Signed-off-by: Simon Glass Acked-by: Matthias Brugger --- configs/rpi_0_w_defconfig | 1 + configs/rpi_2_defconfig| 1 + configs/rpi_3_32b_defconfig| 1 + configs/rpi_3_b_plus_defconfig | 1 + configs/rpi_3_defconfig| 1 + configs/rpi_4_32b_defconfig| 1 + configs/rpi_4_defconfig| 1 + configs/rpi_arm64_defconfig| 1 + configs/rpi_defconfig | 1 + drivers/video/Kconfig | 8 include/configs/rpi.h | 1 - scripts/config_whitelist.txt | 1 - 12 files changed, 17 insertions(+), 2 deletions(-) diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig index 195541c6e76..819618280f7 100644 --- a/configs/rpi_0_w_defconfig +++ b/configs/rpi_0_w_defconfig @@ -41,6 +41,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig index eb63fbdd8d9..9ccd69cbd88 100644 --- a/configs/rpi_2_defconfig +++ b/configs/rpi_2_defconfig @@ -42,6 +42,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig index 46102899f03..de4a14e69ce 100644 --- a/configs/rpi_3_32b_defconfig +++ b/configs/rpi_3_32b_defconfig @@ -45,6 +45,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_3_b_plus_defconfig b/configs/rpi_3_b_plus_defconfig index 91b63b62721..1d4346c0ec8 100644 --- a/configs/rpi_3_b_plus_defconfig +++ b/configs/rpi_3_b_plus_defconfig @@ -44,6 +44,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig index 528b12ea5b5..c7615403d33 100644 --- a/configs/rpi_3_defconfig +++ b/configs/rpi_3_defconfig @@ -44,6 +44,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 8f87a4336d2..d9d9331f580 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -59,6 +59,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_ADDR_MAP=y diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 461a7655ab9..eac55ccbcb8 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -59,6 +59,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 351d247daeb..a0cbdbef02f 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -51,6 +51,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig index 0baef3b6abf..bd4e3dc42d7 100644 --- a/configs/rpi_defconfig +++ b/configs/rpi_defconfig @@ -41,6 +41,7 @@ CONFIG_DM_VIDEO=y # CONFIG_VIDEO_BPP8 is not set # CONFIG_VIDEO_BPP16 is not set CONFIG_SYS_WHITE_ON_BLACK=y +CONFIG_VIDEO_BCM2835=y CONFIG_CONSOLE_SCROLL_LINES=10 CONFIG_PHYS_TO_BUS=y CONFIG_OF_LIBFDT_OVERLAY=y diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index e74a3dd9285..2fba1f2e122 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -421,6 +421,14 @@ config VIDEO_LCD_ANX9804 from a parallel LCD interface and translate it on the fy into a DP interface for driving eDP TFT displays. It uses I2C for configuration. +config VIDEO_BCM2835 + bool "Display support for BCM2835" + help + The graphics processor already sets up the display so this driver + simply checks the
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
On 14/01/2022 17.51, Simon Glass wrote:
> Hi Rasmus,
>
> On Tue, 26 Oct 2021 at 02:08, Rasmus Villemoes
> wrote:
>>
>> On 26/10/2021 03.28, Simon Glass wrote:
>>> Hi Rasmus,
>>>
>>> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes
>>> wrote:
The build system already automatically looks for and includes an
in-tree *-u-boot.dtsi when building the control .dtb. However, there
are some things that are awkward to maintain in such an in-tree file,
most notably the metadata associated to public keys used for verified
boot.
The only "official" API to get that metadata into the .dtb is via
mkimage, as a side effect of building an actual signed image. But
there are multiple problems with that. First of all, the final U-Boot
(be it U-Boot proper or an SPL) image is built based on a binary
image, the .dtb, and possibly some other binary artifacts. So
modifying the .dtb after the build requires the meta-buildsystem
(Yocto, buildroot, whatnot) to know about and repeat some of the steps
that are already known to and handled by U-Boot's build system,
resulting in needless duplication of code. It's also somewhat annoying
and inconsistent to have a .dtb file in the build folder which is not
generated by the command listed in the corresponding .cmd file (that
of course applies to any generated file).
So the contents of the /signature node really needs to be baked into
the .dtb file when it is first created, which means providing the
relevant data in the form of a .dtsi file. One could in theory put
that data into the *-u-boot.dtsi file, but it's more convenient to be
able to provide it externally: For example, when developing for a
customer, it's common to use a set of dummy keys for development,
while the consultants do not (and should not) have access to the
actual keys used in production. For such a setup, it's easier if the
keys used are chosen via the meta-buildsystem and the path(s) patched
in during the configure step. And of course, nothing prevents anybody
from having DEVICE_TREE_INCLUDES point at files maintained in git, or
for that matter from including the public key metadata in the
*-u-boot.dtsi directly and ignore this feature.
There are other uses for this, e.g. in combination with ENV_IMPORT_FDT
it can be used for providing the contents of the /config/environment
node, so I don't want to tie this exclusively to use for verified
boot.
Signed-off-by: Rasmus Villemoes
---
Getting the public key metadata into .dtsi form can be done with a
little scripting (roughly 'mkimage -K' of a dummy image followed by
'dtc -I dtb -O dts'). I have a script that does that, along with
options to set 'required' and 'required-mode' properties, include
u-boot,dm-spl properties in case one wants to check U-Boot proper from
SPL with the verified boot mechanism, etc. I'm happy to share that
script if this gets accepted, but it's moot if this is rejected.
I have previously tried to get an fdt_add_pubkey tool accepted [1,2]
to disentangle the kernel and u-boot builds (or u-boot and SPL builds
for that matter!), but as I've since realized, that isn't quite enough
- the above points re modifying the .dtb after it is created but
before that is used to create further build artifacts still
stand. However, such a tool could still be useful for creating the
.dtsi info without the private keys being present, and my key2dtsi.sh
script could easily be modified to use a tool like that should it ever
appear.
[1]
https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villem...@prevas.dk/
[2]
https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205fee...@kaspersky.com/
dts/Kconfig | 9 +
scripts/Makefile.lib | 2 ++
2 files changed, 11 insertions(+)
>>>
>>> Reviewed-by: Simon Glass
>>>
>>> I suggest adding this to the documentation somewhere in
>>> doc/develop/devicetree/
>>
>> Will do.
>>
>>> Getting the key into the U-Boot .dtb is normally done with mkimage, as
>>> you say. I don't really understand why this approach is easier.
>>
>> I think I explained that in the commit message, but let me try with a
>> more concrete example. I'm building, using Yocto as the umbrella build
>> system, for a SOC that needs an SPL + U-Boot proper.
>>
>> So I have a U-Boot recipe that handles the configuration and
>> compilation. That's mostly a matter of "make foo_defconfig" followed by
>> "make ${UBOOT_TARGETS}" where UBOOT_TARGETS is something set in the
>> machine config. That results in two artifacts, say SPL and u-boot.itb
>> (the names don't really matter) that are almost ready to be written to
>> whatever storage is used for them. Most likely, the SPL binary is built
>> from a
Re: [PATCH v5 3/3] arm: kirkwood: Pogoplug-V4 : Add board implementation files
Hi Stefan, On Mon, Jan 24, 2022 at 1:41 AM Stefan Roese wrote: > > On 1/24/22 07:17, Tony Dinh wrote: > > Add board header, defconfig, and implementation files for Pogoplug V4. > > > > Signed-off-by: Tony Dinh > > --- > > > > Changes in v5: > > - Currently, CONFIG_RESET_PHY_R symbol is used in > > arch/arm/mach-kirkwood/include/mach/config.h for all Kirkwood > > boards with mv8831116 PHY, with each board defines the function > > reset_phy(). Undefine it for this board. > > - Add board_eth_init() to use uclass mvgbe to handle all Ethernet > > PHY configuration and bring up the network. > > Okay, good. I'm a bit puzzled that you don't need (want) to enable the > Marvell ethernet PHY driver for this as well. But perhaps this is an > optimization for some follow-up patches - also for some other Kirkwood > boards. Exactly! For Kirkwood boards with MV88E1116 PHY (about 6 boards), it is enough to let the uclass mvgbe handle all the PHY config and bring up the Gbits network using the PHY default genphy_config(). And it will run in gmii phy-mode. The optimization will come in a follow-up patch, where we will enable rgmii phy-mode in the DTS. I'll submit a follow-up patch in which we'll use u-boot.dtsi to add phy-mode="rgmii". And then I'll follow up with patches for other Kirkwood boards to use the same approach. Thanks, Tony > > So for now: > > Reviewed-by: Stefan Roese > > Thanks, > Stefan > > > > Changes in v4: > > - Remove CONFIG_FEATURE_COMMAND_EDITING and ifdefs for CMD_NET > > in include header > > > > Changes in v3: > > - Squash board file small patches into one patch > > - Migrate config symbols from board include header to defconfig > > - Remove obsolete config symbols from header file > > - Don't use ifdefs for unselectable config symbols in header file > > > > Changes in v2: > > - Move constants to .c file and remove header file > > - Use canonical format for defconfig file > > > > board/cloudengines/pogo_v4/MAINTAINERS | 6 + > > board/cloudengines/pogo_v4/Makefile | 10 ++ > > board/cloudengines/pogo_v4/kwbimage.cfg | 148 > > board/cloudengines/pogo_v4/pogo_v4.c| 148 > > configs/pogo_v4_defconfig | 79 + > > include/configs/pogo_v4.h | 56 + > > 6 files changed, 447 insertions(+) > > create mode 100644 board/cloudengines/pogo_v4/MAINTAINERS > > create mode 100644 board/cloudengines/pogo_v4/Makefile > > create mode 100644 board/cloudengines/pogo_v4/kwbimage.cfg > > create mode 100644 board/cloudengines/pogo_v4/pogo_v4.c > > create mode 100644 configs/pogo_v4_defconfig > > create mode 100644 include/configs/pogo_v4.h > > > > diff --git a/board/cloudengines/pogo_v4/MAINTAINERS > > b/board/cloudengines/pogo_v4/MAINTAINERS > > new file mode 100644 > > index 00..35fd7858b7 > > --- /dev/null > > +++ b/board/cloudengines/pogo_v4/MAINTAINERS > > @@ -0,0 +1,6 @@ > > +POGO_V4 BOARD > > +M: Tony Dinh > > +S: Maintained > > +F: board/cloudengines/pogo_v4/ > > +F: include/configs/pogo_v4.h > > +F: configs/pogo_v4_defconfig > > diff --git a/board/cloudengines/pogo_v4/Makefile > > b/board/cloudengines/pogo_v4/Makefile > > new file mode 100644 > > index 00..511bf5ff7e > > --- /dev/null > > +++ b/board/cloudengines/pogo_v4/Makefile > > @@ -0,0 +1,10 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# > > +# (C) Copyright 2014-2021 Tony Dinh > > +# > > +# Based on > > +# Marvell Semiconductor > > +# Written-by: Prafulla Wadaskar > > +# > > + > > +obj-y:= pogo_v4.o > > diff --git a/board/cloudengines/pogo_v4/kwbimage.cfg > > b/board/cloudengines/pogo_v4/kwbimage.cfg > > new file mode 100644 > > index 00..f6294fe313 > > --- /dev/null > > +++ b/board/cloudengines/pogo_v4/kwbimage.cfg > > @@ -0,0 +1,148 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# > > +# Copyright (C) 2012 > > +# David Purdy > > +# > > +# Based on Kirkwood support: > > +# (C) Copyright 2009 > > +# Marvell Semiconductor > > +# Written-by: Prafulla Wadaskar marvell.com> > > + > > +# Boot Media configurations (DONE) > > +BOOT_FROMnand > > +NAND_ECC_MODEdefault > > +NAND_PAGE_SIZE 0x0800 > > + > > +# SOC registers configuration using bootrom header extension > > +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed > > + > > +# Configure RGMII-0 interface pad voltage to 1.8V (SHOULD BE SAME) > > +DATA 0xffd100e0 0x1b1b1b9b > > + > > +#Dram initalization for SINGLE x16 CL=3 @ 200MHz (need CL=3 @ 200MHz?) > > +DATA 0xffd01400 0x43000618 # DDR Configuration register > > +# bit13-0: 0x200 (200 DDR2 clks refresh rate) > > +# bit23-14: zero > > +# bit24: 1= enable exit self refresh mode on DDR access > > +# bit25: 1 required > > +# bit29-26: zero > > +# bit31-30: 01 > > + > > +DATA 0xffd01404 0x34143000 # DDR Controller Control Low > > +# bit 4:0=addr/cmd in smame cycle > > +# bit 5:0=clk is driven during self refresh, we don't care for
