Re: [PATCH v4 3/3] board: toradex: add verdin am62 support
Hi Marcel
On 29/07/23 02:24, Marcel Ziswiler wrote:
From: Marcel Ziswiler
This adds initial support for the Toradex Verdin AM62 Quad 1GB WB IT
V1.0A module and subsequent V1.1 launch configuration SKUs. They are
strapped to boot from their on-module eMMC. U-Boot supports booting
from the on-module eMMC only, DFU support is disabled for now due to
missing AM62x USB support.
Boot sequence is:
SYSFW ---> R5 SPL (both in tiboot3.bin) ---> ATF (TF-A) ---> OP-TEE
---> A53 SPL (part of tispl.bin) ---> U-boot proper (u-boot.img)
Signed-off-by: Marcel Ziswiler
---
[...]
+ mbox-names = "rx", "tx", "notify";
+ ti,host-id = <35>;
+ ti,secure-host;
+};
diff --git a/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
new file mode 100644
index 000..e8c926f48b9
--- /dev/null
+++ b/arch/arm/dts/k3-am625-verdin-wifi-dev-binman.dtsi
@@ -0,0 +1,570 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2023 Toradex
+ */
+
+#include "k3-binman.dtsi"
+
+ {
+ custMpk {
+ filename = "custMpk.pem";
+ blob-ext {
+ filename = "../../ti/keys/custMpk.pem";
+ };
+ };
+
+ ti-degenerate-key {
+ filename = "ti-degenerate-key.pem";
+ blob-ext {
+ filename = "../../ti/keys/ti-degenerate-key.pem";
+ };
+ };
+};
+
+#ifndef CONFIG_ARM64
+
+ {
+ board-cfg {
+ filename = "board-cfg.bin";
+ bcfg_yaml: ti-board-config {
+ config = "board-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ pm-cfg {
+ filename = "pm-cfg.bin";
+ rcfg_yaml: ti-board-config {
+ config = "pm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ rm-cfg {
+ filename = "rm-cfg.bin";
+ pcfg_yaml: ti-board-config {
+ config = "rm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ sec-cfg {
+ filename = "sec-cfg.bin";
+ scfg_yaml: ti-board-config {
+ config = "sec-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ combined-tifs-cfg {
+ filename = "combined-tifs-cfg.bin";
+ ti-board-config {
+ bcfg_yaml_tifs: board-cfg {
+ config = "board-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ scfg_yaml_tifs: sec-cfg {
+ config = "sec-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ pcfg_yaml_tifs: pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ rcfg_yaml_tifs: rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ };
+ combined-dm-cfg {
+ filename = "combined-dm-cfg.bin";
+ ti-board-config {
+ pcfg_yaml_dm: pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ rcfg_yaml_dm: rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ };
+ combined-sysfw-cfg {
+ filename = "combined-sysfw-cfg.bin";
+ ti-board-config {
+ board-cfg {
+ config = "board-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ sec-cfg {
+ config = "sec-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../../ti/common/schema.yaml";
+ };
+ };
+ };
+};
+
^ If you are already including k3-binman.dtsi, why are you redefining these?
+#endif /*
Re: [PATCH 1/2] configs: am65x: Merge the HS and non-HS defconfigs
Hi Andrew,
On 09:54-20230803, Andrew Davis wrote:
> K3 devices have runtime type board detection. Make the default defconfig
> include the secure configuration. Then remove the HS specific config.
>
> Non-HS devices will continue to boot due to runtime device type detection.
>
> Signed-off-by: Andrew Davis
> ---
> MAINTAINERS | 2 -
> configs/am65x_evm_a53_defconfig | 3 +-
> configs/am65x_evm_r5_defconfig| 1 +
> configs/am65x_evm_r5_usbdfu_defconfig | 1 +
> configs/am65x_evm_r5_usbmsc_defconfig | 1 +
> configs/am65x_hs_evm_a53_defconfig| 158 --
> configs/am65x_hs_evm_r5_defconfig | 135 --
> 7 files changed, 5 insertions(+), 296 deletions(-)
> delete mode 100644 configs/am65x_hs_evm_a53_defconfig
> delete mode 100644 configs/am65x_hs_evm_r5_defconfig
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 47581cf6fbb..d3b9f4cc6c4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1506,8 +1506,6 @@ F: configs/k2hk_hs_evm_defconfig
> F: configs/k2e_hs_evm_defconfig
> F: configs/k2g_hs_evm_defconfig
> F: configs/k2l_hs_evm_defconfig
> -F: configs/am65x_hs_evm_r5_defconfig
> -F: configs/am65x_hs_evm_a53_defconfig
While merging these defconfigs for other boards I had faced an issue
where the multi DTB detection wasn't working for HS devices and we were
hitting a firewall exception while trying to access the EEPROM
Scratchpad before the firewalls were opened. I see that AM65x still uses
the old Scratchpad address in the Kconfig which had triggered exceptions
for other K3 devices.
config SYS_K3_MCU_SCRATCHPAD_BASE
hex
default 0x4028 if SOC_K3_AM654
default 0x41cff9fc if SOC_K3_J721S2
default 0x41cff9fc if SOC_K3_J721E
Can you double check if this also needs a change along with the merged
defconfigs?
Regards,
Manorit
>
> TPM DRIVERS
> M: Ilias Apalodimas
> diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig
> index 4301553af8d..55c1b23c8db 100644
> --- a/configs/am65x_evm_a53_defconfig
> +++ b/configs/am65x_evm_a53_defconfig
> @@ -1,6 +1,7 @@
> CONFIG_ARM=y
> CONFIG_SKIP_LOWLEVEL_INIT=y
> CONFIG_ARCH_K3=y
> +CONFIG_TI_SECURE_DEVICE=y
> CONFIG_SYS_MALLOC_LEN=0x200
> CONFIG_SYS_MALLOC_F_LEN=0x8000
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> @@ -34,7 +35,7 @@ CONFIG_SPL_LOAD_FIT=y
> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
> CONFIG_OF_SYSTEM_SETUP=y
> CONFIG_DISTRO_DEFAULTS=y
> -CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
> boot_rprocs; run get_kern_${boot}; run get_fdt_${boot}; run
> get_overlay_${boot}; run run_kern"
> +CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
> boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
> get_overlaystring; run run_fit; else; run get_kern_${boot}; run
> get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
> CONFIG_LOGLEVEL=7
> CONFIG_CONSOLE_MUX=y
> CONFIG_SPL_MAX_SIZE=0x58000
> diff --git a/configs/am65x_evm_r5_defconfig b/configs/am65x_evm_r5_defconfig
> index d5196c2024e..b9b69b921be 100644
> --- a/configs/am65x_evm_r5_defconfig
> +++ b/configs/am65x_evm_r5_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ARCH_K3=y
> +CONFIG_TI_SECURE_DEVICE=y
> CONFIG_SYS_MALLOC_LEN=0x200
> CONFIG_SYS_MALLOC_F_LEN=0x55000
> CONFIG_SPL_GPIO=y
> diff --git a/configs/am65x_evm_r5_usbdfu_defconfig
> b/configs/am65x_evm_r5_usbdfu_defconfig
> index 88f68aa70e4..fb93024bda9 100644
> --- a/configs/am65x_evm_r5_usbdfu_defconfig
> +++ b/configs/am65x_evm_r5_usbdfu_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ARCH_K3=y
> +CONFIG_TI_SECURE_DEVICE=y
> CONFIG_SYS_MALLOC_LEN=0x200
> CONFIG_SYS_MALLOC_F_LEN=0x55000
> CONFIG_SPL_GPIO=y
> diff --git a/configs/am65x_evm_r5_usbmsc_defconfig
> b/configs/am65x_evm_r5_usbmsc_defconfig
> index 8da49c78c82..931b756ab52 100644
> --- a/configs/am65x_evm_r5_usbmsc_defconfig
> +++ b/configs/am65x_evm_r5_usbmsc_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ARCH_K3=y
> +CONFIG_TI_SECURE_DEVICE=y
> CONFIG_SYS_MALLOC_LEN=0x200
> CONFIG_SYS_MALLOC_F_LEN=0x55000
> CONFIG_SPL_GPIO=y
> diff --git a/configs/am65x_hs_evm_a53_defconfig
> b/configs/am65x_hs_evm_a53_defconfig
> deleted file mode 100644
> index 3f9626e4550..000
> --- a/configs/am65x_hs_evm_a53_defconfig
> +++ /dev/null
> @@ -1,158 +0,0 @@
> -CONFIG_ARM=y
> -CONFIG_SKIP_LOWLEVEL_INIT=y
> -CONFIG_ARCH_K3=y
> -CONFIG_TI_SECURE_DEVICE=y
> -CONFIG_SYS_MALLOC_LEN=0x200
> -CONFIG_SYS_MALLOC_F_LEN=0x8000
> -CONFIG_SPL_LIBCOMMON_SUPPORT=y
>
Re: [RFC PATCH] env: Export environment config to OS devicetree
Hi,
On Thu, 3 Aug 2023 at 07:21, Stefano Babic wrote:
>
> Hi Frieder,
>
> On 03.08.23 14:51, Frieder Schrempf wrote:
> > Hi Stefano,
> >
> > On 03.08.23 10:14, Stefano Babic wrote:
> >> Hi Frieder,
> >>
> >> On 01.08.23 16:46, Frieder Schrempf wrote:
> >>> From: Frieder Schrempf
> >>>
> >>> There are plenty of cases where the OS wants to know where the
> >>> persistent environment is stored in order to print or manipulate it.
> >>>
> >>> In most cases a userspace tool like libubootenv [1] is used to handle
> >>> the environment. It uses hardcoded settings in a config file in the
> >>> rootfs to determine the exact location of the environment.
> >>>
> >>
> >> ...or the configuration file is generated, or it is located on a rw
> >> (overlayfs) partition.
> >>
> >>> In order to make systems more flexible and let userspace tools
> >>> detect the location of the environment currently in use, let's
> >>> add an option to export the runtime configuration to the FDT passed
> >>> to the OS.
> This is especially useful when your device is able to use multiple
> >>> locations for the environment and the rootfs containing the
> >>> fw_env.config file should be kept universal.
> >>
> >> Ok
> >>
> >> One possible issue is there is a hard dependency between the properties
> >> set in DT and the user space tool. The tool in user space is bound to
> >> the list of properties, and changes / extensions for the user tool
> >> requires changes in DT semantics (which properties, their path, etc).
> >>
> >> The same hard dependency is set by fw_env.config with its strong
> >> hardcoded and position dependent syntax. This one of the reason I
> >> introduced YAML support in libubootenv, so that the user tool is
> >> independent and can add own properties.
> >>
> >> I am just asking if this use case requires a new interface, or it is
> >> already available in some way. I mean, the configuration is YAML instead
> >> of fw_env.config and contains multiple setup ("namespaces"), like:
> >>
> >> mmc:
> >>size : 0x10
> >>lockfile : /var/lock/fw_printenv.lock
> >>devices:
> >> - path : /dev/mmcblk0boot0
> >>offset : 0x1E
> >>sectorsize : 0x10
> >> - path : /dev/mmcblk0boot0
> >>offset : 0x1E
> >>sectorsize : 0x10
> >> spi:
> >>size : 0x10
> >>lockfile : /var/lock/fw_printenv.lock
> >>devices:
> >> - path : /dev/mtd0
> >>offset : 0x1E
> >>sectorsize : 0x10
> >> - path : /dev/mtd0
> >>offset : 0x1F
> >>sectorsize : 0x10
> >>
> >> This configuration file can safely stored in your common rootfs and
> >> covers all possible storage for environment. It does not cover "runtime"
> >> changes, but well, I do not think this is a use case.
> >>
> >> An advantage here is that new options, useful for the User Space tool,
> >> can be simply introduced for the tool without the need to synchronize
> >> with DT spec and U-Boot.
> >>
> >> A mapping between location index and device path is not required. What
> >> is still required is a selector, and this can be implemented in DT or as
> >> kernel parameter.
> >>
> >> Does this already cover your use case or do we need the introduction of
> >> this new interface ?
> >
> > Thanks for the feedback! I've seen the YAML configuration feature in
> > libubootenv but I missed the fact, that it already supports something
> > like the namespace parameter for selecting different configurations.
> >
> > Indeed this would solve one part of the issue. And yes, I think we could
> > use the DT or a kernel parameter to pass a selector from U-Boot to
> > userspace.
>
> Exactly.
>
> >
> > Do you think we could add something to libubootenv to automatically
> > select the default namespace based on some DT property or kernel parameter?
>
> Yes, we just need to add a way to set up a default "namespace". There is
> currently a default "uboot" namespace, and we just need a way to pass
> the information to the library. Maybe with an env ?
>
> >
> > If yes, I think this would be a viable solution for me.
>
> Fine !
>
> >
> >>
> >>>
> >>> Currently the general information like location/type, size, offset
> >>> and redundancy are exported. Userspace tools might already be able
> >>> to guess the correct device to access based on this information.
> >>>
> >>> For further device-specific information two additional properties
> >>> 'id1' and 'id2' are used. The current implementation uses them for
> >>> MMC and SPI FLASH like this:
> >>>
> >>> | Type | id1| id2|
> >>> | -- | -- | -- |
> >>> | MMC| MMC device index in U-Boot | MMC hwpart index in U-Boot |
> >>> | SPI FLASH | SPI bus index in U-Boot| SPI CS index in U-Boot |
> >>>
> >>> Further extensions for other environment devices are possible.
> >>>
> >>> We add the necessary information to the '/chosen'
Re: [PATCH 4/9] Revert "x86: Switch QEMU over to use the bochs driver"
Hi Bin, On Mon, 31 Jul 2023 at 11:07, Simon Glass wrote: > > Hi Bin, > > On Mon, 31 Jul 2023 at 08:46, Bin Meng wrote: > > > > Hi Simon, > > > > On Mon, Jul 31, 2023 at 10:37 PM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Mon, 31 Jul 2023 at 08:32, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Sat, Jul 29, 2023 at 1:32 AM Simon Glass wrote: > > > > > > > > > > Hi Bin, > > > > > > > > > > On Fri, 28 Jul 2023 at 09:46, Bin Meng wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Mon, Jul 24, 2023 at 10:52 PM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Unfortunately the bochs driver does not currently work with > > > > > > > distros. It > > > > > > > causes a hang sometime between grub menu selection and the OS > > > > > > > displaying > > > > > > > something. > > > > > > > > > > > > Does this reproduce reliably? > > > > > > > > > > Yes, it does. > > > > > > > > > > BTW I've also hit another problem with '-M accel-kvm' which hangs on > > > > > the move to 64-bit mode. Oddly if I boot U-Boot from coreboot, the > > > > > problem goes away. So perhaps coreboot is doing some x86 init which > > > > > U-Boot is missing. > > > > > > > > This indicates a kvm-x86 bug. I think you can simplify a test case and > > > > report it to the KVM mailing list. > > > > > > Firstly it doesn't really matter, since it doesn't work, so we do need > > > to revert. > > > > Agreed, but before we revert this, I would like to see we investigate > > this issue a little bit further. > > > > I enabled the grub debug output today and not sure if grub jumps to > > the kernel entry yet: > > > > kern/verifiers.c:214: string: boot, type: 2 > > loader/efi/linux_sb.c:55: kernel_addr: 0x100 handover_offset: 0x190 > > params: > > 0x7ce63000 > > > > > > > > Secondly I am not sure it kvm's fault, since the problem does not > > > happen with coreboot. I will see if I can isolate what coreboot is > > > doing differently, but not sure that that fix will make the release. > > > > Does the 64-bit mode switch ever work on a real x86 board? If yes, > > then it's very likely a KVM bug. > > Yes it works fine on chromebook_link64, for example. > > > > > If not, then we can check the coreboot to find out the difference. > > Yes...do you have any ideas? > > If it helps, I am using something like this: > > qemu-system-x86_64 -m 8G -smp 4 -bios /tmp/b/qemu-x86_64/u-boot.rom > -drive id=fdisk,file=root.img,if=virtio,driver=raw -drive \ > > file=/vid/software/linux/ubuntu/ubuntu-23.04-desktop-amd64.iso,if=virtio,driver=raw > \ > -serial mon:stdio > > For coreboot my script is: > > UBTEST=/vid/software/devel/ubtest/ > BUILD_DIR=/tmp/b/coreboot64 > DISK=/vid/software/linux/ubuntu/ubuntu-23.04-desktop-amd64.iso > > cp $UBTEST/coreboot.rom.in $BUILD_DIR/coreboot.rom > cbfstool $BUILD_DIR/coreboot.rom add-flat-binary \ > -f $BUILD_DIR/u-boot-x86-with-spl.bin \ > -n fallback/payload -c LZMA -l 0x111 -e 0x111 > > Add this in below: > #-M accel=kvm > > qemu-system-x86_64 -m 2G -smp 4 -bios $BUILD_DIR/coreboot.rom -serial > mon:stdio \ > -drive id=disk,file=$DISK,if=none \ > -device ahci,id=ahci \ > -device ide-hd,drive=disk,bus=ahci.0 I haven't looked into the problem here, but I did notice this coreboot commit: https://review.coreboot.org/c/coreboot/+/49228 I am not sure it is related though, since we already have page tables in RAM. Regards, Simon
Re: [PATCH 1/1] video: avoid build failure on veyron board
Hi,
On Thu, 3 Aug 2023 at 18:37, Alvaro Fernando García
wrote:
>
> 533ad9dc avoided an overflow but causes compilation
> failure on 32bit boards (eg. veyron speedy)
>
> this commit uses div_u64 which has a fallback codepath
> for 32bit platforms
>
> Signed-off-by: Alvaro Fernando García
> ---
>
> drivers/video/pwm_backlight.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
Tested-by: Simon Glass # chromebook_jerry
Can you please advise which toolchain you are using and what the
warning actually says? I don't see this on my board.
>
> diff --git a/drivers/video/pwm_backlight.c b/drivers/video/pwm_backlight.c
> index 46c16a8f44..aa0e292866 100644
> --- a/drivers/video/pwm_backlight.c
> +++ b/drivers/video/pwm_backlight.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> /**
> @@ -59,12 +60,14 @@ struct pwm_backlight_priv {
>
> static int set_pwm(struct pwm_backlight_priv *priv)
> {
> + u64 width;
> uint duty_cycle;
> int ret;
>
> if (priv->period_ns) {
> - duty_cycle = (u64)priv->period_ns * (priv->cur_level -
> priv->min_level) /
> - (priv->max_level - priv->min_level);
> + width = priv->period_ns * (priv->cur_level - priv->min_level);
> + duty_cycle = div_u64(width,
> +(priv->max_level - priv->min_level));
> ret = pwm_set_config(priv->pwm, priv->channel,
> priv->period_ns,
> duty_cycle);
> } else {
> --
> 2.41.0
>
Regards,
Simon
Re: [PATCH 00/16] bootstd: Improve ChromiumOS support
Hi Alper, On Thu, 3 Aug 2023 at 15:31, Alper Nebi Yasak wrote: > > Hi Simon, > > On 2023-07-30 20:16 +03:00, Simon Glass wrote: > > The ChromiumOS bootmeth is fairly basic at present. It is able to boot > > only x86 kernels and contains quite a few hard-coded offsets. > > > > This series tidies it up by bringing in some vboot structures and adding > > support for ARM. > > > > It adds a few more features to bootstd, including display of x86 setup > > information. > > Can't do a detailed review or test for a while, but had a cursory look > now and wanted to reply. I'm not sure if you heard of it, but I maintain > an alternate implementation of ChromiumOS verified boot userspace called > depthcharge-tools [1]. Its main purpose is booting ordinary distros on > Chromebooks, but it would be nice if your U-Boot implementation was also > compatible with images produced from that. > > I guess it boils down to: > > - Enable booting from any chromeos_kernel partition (not just 2 & 4) How do you know which ones hold kernels, and which root disks correspond to each kernel? > - Fixup the ramdisk addr/size in x86 setup info after reading the kernel But ChromeOS doesn't use ramdisk, right? > - Replace %U with chromeos_kernel PARTUUID (you probably already do?) Yes. > - Prepend cros_secure to kernel cmdline Does it have to be at the start of the cmdline? Also, the cmdline comes from cros at present, so does include that normally. I think the best way is for you to give it a try and see what is needed. > > There's a ready made debian-installer image if you want to test [2]. Has > a partitioning bug defaulting to MBR, but otherwise can install for CrOS > verified boot as well. (It's what took my last year away from U-Boot). > > [1] depthcharge-tools -- Tools to manage the Chrome OS bootloader > https://github.com/alpernebbi/depthcharge-tools > > [2] Debian Installer netboot image for amd64 Chromebooks > https://d-i.debian.org/daily-images/amd64/daily/netboot/depthcharge/ I see the installer, but how do I actually run it on bob, say? > > > So far this does not actually boot correctly on any ARM Chromebook: > > > >jerry - hangs when booting kernel > >bob - Bad Linux ARM64 Image magic! with lz4-compressed kernel > > > > Further work can address these issues. > > I haven't been able to boot recent kernels with extlinux.conf on my > pre-bootstd kevin U-Boot builds which I remember were working with older > kernels. And I've heard people not being boot with extlinux.conf on > veyrons as well. Might be the same, maybe try an older kernel for jerry? Ah OK I haven't tried that. > > Again, there's a debian-installer arm64 image if you want to test [3], > which could work fine on bob (not with depthcharge's size limit though), > but kernel support is missing for anything else. > > Oh, and postmarketOS also supports CrOS verified boot [4] via > depthcharge-tools, but they don't have pre-built images and it's a bit > of a hassle. > > [3] Debian Installer netboot image for arm64 Chromebooks > https://d-i.debian.org/daily-images/arm64/daily/netboot/depthcharge/ > > [4] postmarketOS Wiki - Chrome OS devices > https://wiki.postmarketos.org/wiki/Chrome_OS_devices > > Anyway, I'm glad you're working on this, looking forward to testing it > myself when I get the chance! Great! I hope that the bootmeth can expand to be more useful over time. Regards, Simon > > > Simon Glass (16): > > bootstd: cros: Correct reporting of I/O errors > > bootstd: cros: Move partition reading into a function > > bootstd: cros: Bring in some ChromiumOS structures > > bootstd: cros: Support a kernel on either partition > > bootstd: cros: Decode some kernel preamble fields > > bootstd: cros: Simplify setup and cmdline expressions > > bootstd: Move common zimage functions to bootm.h > > bootstd: cros: Add docs for the kernel layout > > bootstd: cros: Add private info for ChromiumOS > > bootstd: Add private bootmeth data to the bootflow > > bootstd: cros: Add a function to read info from partition > > bootstd: cros: Add a function to read a kernel > > bootstd: cros: Split up reading info and kernel > > bootstd: Allow display of the x86 setup information > > bootstd: Add a command to read all files for a bootflow > > bootstd: cros: Add ARM support > > > > arch/x86/include/asm/zimage.h | 37 > > arch/x86/lib/zimage.c | 8 +- > > boot/Kconfig | 4 +- > > boot/bootflow.c | 15 ++ > > boot/bootm.c | 37 > > boot/bootmeth-uclass.c| 10 + > > boot/bootmeth_cros.c | 363 -- > > boot/bootmeth_cros.h | 197 ++ > > cmd/bootflow.c| 47 - > > doc/usage/cmd/bootflow.rst| 139 - > > include/bootflow.h| 15 +- > > include/bootm.h | 47 + > > include/bootmeth.h| 23 +++ > > 13 files changed, 836
Re: [PATCH] video: vidconsole: Fix null dereference of ops->measure
On Thu, 3 Aug 2023 at 03:32, Bin Meng wrote:
>
> At present vidconsole_measure() tests ops->select_font before calling
> ops->measure, which would result in a null dereference when the console
> driver provides no ops for measure.
>
> Fixes: b828ed7d7929 ("console: Allow measuring the bounding box of text")
> Signed-off-by: Bin Meng
> ---
>
> drivers/video/vidconsole-uclass.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Simon Glass
Re: [PATCH] bootmeth: efi: Make distro_efi_boot() static
On Thu, 3 Aug 2023 at 03:30, Bin Meng wrote: > > As it is only called in bootmeth_efi.c > > Signed-off-by: Bin Meng > --- > > boot/bootmeth_efi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH v6 6/9] binman: capsule: Add support for generating EFI capsules
Hi Sughosh,
On Thu, 3 Aug 2023 at 05:08, Sughosh Ganu wrote:
>
> hi Simon,
>
> On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote:
> >
> > Hi Sughosh,
> >
> > On Tue, 1 Aug 2023 at 11:41, Sughosh Ganu wrote:
> > >
> > > Add support in binman for generating EFI capsules. The capsule
> > > parameters can be specified through the capsule binman entry. Also add
> > > test cases in binman for testing capsule generation.
> > >
> > > Signed-off-by: Sughosh Ganu
> > > ---
> > > Changes since V5:
> > > * Add support for the oemflag parameter used in FWU A/B updates. This
> > > was missed in the earlier version.
> > > * Use a single function, generate_capsule in the mkeficapsule bintool,
> > > instead of the multiple functions in earlier version.
> > > * Remove the logic for generating capsules from config file as
> > > suggested by Simon.
> > > * Use required_props for image index and GUID parameters.
> > > * Use a subnode for the capsule payload instead of using a filename
> > > for the payload, as suggested by Simon.
> > > * Add a capsule generation test with oemflag parameter being passed.
> > >
> > >
> > > configs/sandbox_spl_defconfig | 1 +
> >
> > move to a later commit
>
> Okay. I think it'd be better to have this change before adding support
> for efi_capsule entry in binman.
OK, I see that it is currently only built for tools-only and a
smattering of other boards. Tools should be built for all boards. I
suppose for now you can create a patch to enable it for all sandbox
boards, e.g. 'default y if SANDBOX' in the Kconfing, in a patch before
this one.
>
>
> >
> > > tools/binman/btool/mkeficapsule.py| 101 +++
> >
> > nit: Please split this into its own commit, with the etype in the
> > second commit.
>
> Okay
>
> >
> > > tools/binman/entries.rst | 64 +++
> > > tools/binman/etype/efi_capsule.py | 160 ++
> > > tools/binman/ftest.py | 122 +
> > > tools/binman/test/307_capsule.dts | 21 +++
> > > tools/binman/test/308_capsule_signed.dts | 23 +++
> > > tools/binman/test/309_capsule_version.dts | 22 +++
> > > tools/binman/test/310_capsule_signed_ver.dts | 24 +++
> > > tools/binman/test/311_capsule_oemflags.dts| 22 +++
> > > tools/binman/test/312_capsule_missing_key.dts | 22 +++
> > > .../binman/test/313_capsule_missing_index.dts | 20 +++
> > > .../binman/test/314_capsule_missing_guid.dts | 19 +++
> > > .../test/315_capsule_missing_payload.dts | 17 ++
> > > 14 files changed, 638 insertions(+)
> > > create mode 100644 tools/binman/btool/mkeficapsule.py
> > > create mode 100644 tools/binman/etype/efi_capsule.py
> > > create mode 100644 tools/binman/test/307_capsule.dts
> > > create mode 100644 tools/binman/test/308_capsule_signed.dts
> > > create mode 100644 tools/binman/test/309_capsule_version.dts
> > > create mode 100644 tools/binman/test/310_capsule_signed_ver.dts
> > > create mode 100644 tools/binman/test/311_capsule_oemflags.dts
> > > create mode 100644 tools/binman/test/312_capsule_missing_key.dts
> > > create mode 100644 tools/binman/test/313_capsule_missing_index.dts
> > > create mode 100644 tools/binman/test/314_capsule_missing_guid.dts
> > > create mode 100644 tools/binman/test/315_capsule_missing_payload.dts
> > >
> > > diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig
> > > index 8d50162b27..65223475ab 100644
> > > --- a/configs/sandbox_spl_defconfig
> > > +++ b/configs/sandbox_spl_defconfig
> > > @@ -249,3 +249,4 @@ CONFIG_UNIT_TEST=y
> > > CONFIG_SPL_UNIT_TEST=y
> > > CONFIG_UT_TIME=y
> > > CONFIG_UT_DM=y
> > > +CONFIG_TOOLS_MKEFICAPSULE=y
[..]
> > > +def ReadEntries(self):
> > > +"""Read the subnode to get the payload for this capsule"""
> > > +# We can have a single payload per capsule
> > > +if len(self._node.subnodes) != 1:
> > > +self.Raise('The capsule entry expects a single subnode for
> > > payload')
> >
> > No, we mustn't restruit this. Why would we?
>
> The mkeficapsule tool that generates the capsule expects a single
> image as it's input payload. Why do you see the need to support
> multiple entries as payload?
That's how binman works...it isn't the entry type's job to decide how
the image is laid out. The user could add a section in any cases and
get around any restriction you put here. But the restriction isn't
necessary and is just strange.
>
> mkeficapsule [options]
>
>
> >
> > > +
> > > +for node in self._node.subnodes:
> > > +entry = Entry.Create(self, node)
> > > +entry.ReadNode()
> > > +self._entries[entry.name] = entry
> > > +
> > > +def _GenCapsule(self):
> > > +return self.mkeficapsule.generate_capsule(self.image_index,
> > > + self.image_guid,
> > > +
Re: [PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
Hi Sughosh, On Thu, 3 Aug 2023 at 05:18, Sughosh Ganu wrote: > > hi Simon, > > On Wed, 2 Aug 2023 at 18:23, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Tue, 1 Aug 2023 at 11:41, Sughosh Ganu wrote: > > > > > > The EFI capsule files can now be generated as part of u-boot > > > build. This is done through binman. Add capsule entry nodes in the > > > u-boot.dtsi for the sandbox architecture for generating the > > > capsules. Remove the corresponding generation of capsules from the > > > capsule update conftest file. > > > > > > The capsules are generated through the config file for the sandbox > > > variant, and through explicit parameters for the sandbox_flattree > > > variant. > > > > > > Also generate the FIT image used for testing the capsule update > > > feature on the sandbox_flattree variant through binman. Remove the now > > > superfluous its file which was used for generating this FIT image. > > > > > > Signed-off-by: Sughosh Ganu > > > --- > > > Changes since V5: > > > * Use the public key ESL file and other input files from the tree > > > instead of the /tmp/capsules/ directory being used in previous > > > version. > > > * Use macros for other input files and certs. > > > > > > arch/sandbox/dts/u-boot.dtsi | 347 ++ > > > test/py/tests/test_efi_capsule/conftest.py| 128 +-- > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > > 3 files changed, 348 insertions(+), 163 deletions(-) > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > > > > I want to get the binman stuff right before diving into this, but the > > binman stuff seems fairly close, so I'll just mention...do you really > > need all these combinations of tests? It seems to me that one test is > > enough. You know that the binman tests will protect the code there, so > > why test it all over again here? > > These are capsules that are needed for testing the EFI capsule update > functionality. Currently, the capsules used for testing the feature > are generated after u-boot has been built. Same for embedding the > public key in the dtb. I think it is better to have the same flow of > generating capsules and the associated logic(public key embedding) > that is being supported in u-boot rather than having two divergent > flows. This also serves as an example for potential users who would > want to generate capsules as part of the build flow. But my question was why you need more than one test here? Are you testing that U-Boot can decode a capsule file of various types? That should be done in unit tests. Now I see the tests you are referring to in test_capsule_firmware_signed_raw.py (please shorten the name!) These tests all have the reboot problem we need to fix, but anyway, at least I understand it. It looks like you are writing the test files into the source tree? They should be written to the output tree. Regards, Simon
Re: [PATCH] arm: dts: medaitek: convert gmac link mode to 2500base-x for mt7986a-bpi-r3-sd
On Fri, 2023-08-04 at 03:34 +0100, Daniel Golle wrote:
> On Fri, Aug 04, 2023 at 09:01:55AM +0800, Weijie Gao wrote:
> > The mt7531 of bpi-r3 is connected to mt7986 with 2.5Gbps HSGMII,
> not the
> > regular 1Gbps SGMII.
> >
> > Signed-off-by: Weijie Gao
>
> Reviewed-by: Daniel Golle
Frank has already sent one:
https://patchwork.ozlabs.org/project/uboot/patch/20230803165258.14744-1-li...@fw-web.de/
>
> > ---
> > This is a supplement to commit:
> > aef54ea1 (arm: dts: medaitek: convert gmac link mode to 2500base-x)
> > ---
> > arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> > index 15256302b8..c156a81363 100644
> > --- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> > +++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> > @@ -76,12 +76,12 @@
> > {
> > status = "okay";
> > mediatek,gmac-id = <0>;
> > -phy-mode = "sgmii";
> > +phy-mode = "2500base-x";
> > mediatek,switch = "mt7531";
> > reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
> >
> > fixed-link {
> > -speed = <1000>;
> > +speed = <2500>;
> > full-duplex;
> > };
> > };
> > --
> > 2.17.1
> >
[PATCH v1] doc: Add the link for the documentation of the .its
Provide the link for the .its related documentation for Arria10. Signed-off-by: Jit Loon Lim --- doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt index da210bfc86..1381bdcd16 100644 --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt @@ -41,3 +41,6 @@ Example: Bundles both peripheral bitstream and core bitstream into FIT image resets = < FPGAMGR_RESET>; altr,bitstream = "fit_spl_fpga.itb"; }; + +- The .its related documentations can be found here + - Appendix - Reducing Arria 10 Fabric Configuration Time - https://rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10 -- 2.26.2
[PATCH v1] drivers: spi: Add MT25U01G part number for SPI NOR Flash
MT25QU01 OPN with 4B OPCODE support is currently not supported in
source code and the driver reuses the definition for "n25q00a"
which has the same silicon ID but is a slower part.
Adding mt25u01g definition to the source code to support a faster
read response for MT25QU01 QSPI NOR Flash device.
Signed-off-by: Jit Loon Lim
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3ca46330bb..1b2e88cd26 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -311,6 +311,8 @@ const struct flash_info spi_nor_ids[] = {
{ INFO6("mt25ql512a", 0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K |
USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ) },
{ INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
+ { INFO6("mt25qu01g", 0x20bb21, 0x104400, 64 * 1024, 2048, SECT_4K |
USE_FSR |
+SPI_NOR_QUAD_READ | NO_CHIP_ERASE | SPI_NOR_4B_OPCODES) },
{ INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25ql01g", 0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
{ INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR |
SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
--
2.26.2
[PATCH v1] drivers: mtd: spi: Add support for GD55LB02GEBIR SPI NOR flash
From: Teik Heng Chong
Add Support for GigaDevice GD55LB02GEBIR SPI NOR flash as QSPI
configuration flash
Signed-off-by: Teik Heng Chong
---
drivers/mtd/spi/spi-nor-ids.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3f8b796789..3ca46330bb 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -200,6 +200,11 @@ const struct flash_info spi_nor_ids[] = {
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
{INFO("gd55lx02g", 0xc8681C, 0, 64 * 1024, 4096,SECT_4K |
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES)},
+ {
+ INFO("gd55lb02ge", 0xc8671c, 0, 64 * 1024, 4096,
+SECT_4K | SPI_NOR_QUAD_READ |
+SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
#endif
#ifdef CONFIG_SPI_FLASH_ISSI /* ISSI */
/* ISSI */
--
2.26.2
Re: [PATCH] video: kconfig: Fix a typo in SPL_VIDEO_REMOVE
On Thu, 3 Aug 2023 at 04:40, Bin Meng wrote: > > From: Bin Meng > > Add one space between 'before' and 'loading'. > > Signed-off-by: Bin Meng > --- > > drivers/video/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH] rockchip: rk356x: Enable poweroff command
Hi Jonas, On 2023/8/4 03:54, Jonas Karlman wrote: With PMIC_RK8XX, SYSRESET and CMD_POWEROFF options enabled it is possible to power down a board using the poweroff command and turn the board back on using a power button. I'm confuse about the use case, when will people need to do this(other than just test)? Usually people do the power on/off or reboot/reset both by software only or by hardware only, but very little chance need to do these ops by both software and hardware. What's more, we usually enable the power off cmd in kernel, not in bootloader. Thanks, - Kever Enable the poweroff command on RK356x boards that have a button wired to PMIC pwron. Also update to use PMIC poweroff when PMIC_RK8XX is enabled to avoid also having to enable the SYSRESET_CMD_POWEROFF option. Signed-off-by: Jonas Karlman --- configs/quartz64-a-rk3566_defconfig | 1 + configs/quartz64-b-rk3566_defconfig | 1 + configs/rock-3a-rk3568_defconfig | 1 + configs/soquartz-model-a-rk3566_defconfig | 1 + drivers/power/pmic/Kconfig| 1 + 5 files changed, 5 insertions(+) diff --git a/configs/quartz64-a-rk3566_defconfig b/configs/quartz64-a-rk3566_defconfig index d55b224feacd..6853cd6c44b4 100644 --- a/configs/quartz64-a-rk3566_defconfig +++ b/configs/quartz64-a-rk3566_defconfig @@ -52,6 +52,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/configs/quartz64-b-rk3566_defconfig b/configs/quartz64-b-rk3566_defconfig index b98c81f9dcef..aa29fff14643 100644 --- a/configs/quartz64-b-rk3566_defconfig +++ b/configs/quartz64-b-rk3566_defconfig @@ -50,6 +50,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig index 44ff054df665..409aa95acf06 100644 --- a/configs/rock-3a-rk3568_defconfig +++ b/configs/rock-3a-rk3568_defconfig @@ -49,6 +49,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/configs/soquartz-model-a-rk3566_defconfig b/configs/soquartz-model-a-rk3566_defconfig index c3958579db73..a0884a797d58 100644 --- a/configs/soquartz-model-a-rk3566_defconfig +++ b/configs/soquartz-model-a-rk3566_defconfig @@ -43,6 +43,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig index 176fb07c651a..4a6f0ce093ad 100644 --- a/drivers/power/pmic/Kconfig +++ b/drivers/power/pmic/Kconfig @@ -233,6 +233,7 @@ config PMIC_QCOM config PMIC_RK8XX bool "Enable support for Rockchip PMIC RK8XX" + select SYSRESET_CMD_POWEROFF if SYSRESET && CMD_POWEROFF ---help--- The Rockchip RK808 PMIC provides four buck DC-DC convertors, 8 LDOs, an RTC and two low Rds (resistance (drain to source)) switches. It is
Re: [PATCH 1/4] config: rock64: start USB to make storage usable
Hi Peter, On 2023/8/3 15:44, Peter Robinson wrote: On Tue, Aug 1, 2023 at 4:17 AM Kever Yang wrote: Hi Peter, Could you update the patchset with patches you still want to send? Can you just drop this patch and take the rest from the set? Yes, it's OK if there no other change, I can fix the typo in 3/4. Thanks, - Kever Thanks, - Kever On 2023/6/14 20:43, Peter Robinson wrote: Start the USB stack so usb storage can be used. Adding the command as usb keyboard isn't enabled as there's not currently display output. Signed-off-by: Peter Robinson --- configs/rock64-rk3328_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 5e36612bb80..1da9b0545a5 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -23,6 +23,8 @@ CONFIG_DEBUG_UART_BASE=0xFF13 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="usb start" # CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_FIT_VERBOSE=y
Re: [PATCH 3/3] dts: rockchip: rk3308: Avoid warning for serial probe on prereloc
On 2023/8/3 19:08, Massimo Pegorer wrote:
Make device tree complete and consistent for pre relocation phase. Some
nodes are missing, causing warnings to be issued on serial port probing
during pre relocation phase (uclass_get_device_by_phandle_id fails when
called by pinctrl_select_state_full: none of these failures is fatal
nor causing issues). Add to *-u-boot.dtsi all required nodes with the
'bootph-some-ram' attribute.
Signed-off-by: Massimo Pegorer
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
index 61415559b7..d88dee8057 100644
--- a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
@@ -13,3 +13,30 @@
{
bootph-all;
};
+
+ {
+ bootph-some-ram;
+
+ uart0 {
+ bootph-some-ram;
+ };
+ rtc {
+ bootph-some-ram;
+ };
+};
+
+_xfer {
+ bootph-some-ram;
+};
+
+_cts {
+ bootph-some-ram;
+};
+
+_rts {
+ bootph-some-ram;
+};
+
+_32k {
+ bootph-some-ram;
+};
Re: [PATCH 2/3] clk: rockchip: rk3308: Support reading UART rate and clock registers
On 2023/8/3 19:08, Massimo Pegorer wrote:
Add support to read RK3308 registers used to configure UART clocks, and
thus to get UART rate and baudrate. This fixes clock_get_rate returning
error on serial device probing. Moreover, there is no need anymore to
use 'clock-frequency' property for UART nodes in *-u-boot.dtsi files
for all cases where UART is not inited by U-Boot proper or by SPL o by
TPL code but by a preliminary external boot phase (for Rock PI S, UART
is inited by external TPL).
Signed-off-by: Massimo Pegorer
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi | 2 -
arch/arm/include/asm/arch-rk3308/cru_rk3308.h | 15 +
drivers/clk/rockchip/clk_rk3308.c | 59 +++
3 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
index 09694b41e5..61415559b7 100644
--- a/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
+++ b/arch/arm/dts/rk3308-rock-pi-s-u-boot.dtsi
@@ -12,6 +12,4 @@
{
bootph-all;
- clock-frequency = <2400>;
- status = "okay";
};
diff --git a/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
b/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
index 86c906bb0e..84b63e4d56 100644
--- a/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
+++ b/arch/arm/include/asm/arch-rk3308/cru_rk3308.h
@@ -189,6 +189,21 @@ enum {
DCLK_VOP_DIV_SHIFT = 0,
DCLK_VOP_DIV_MASK = 0xff,
+ /* CRU_CLKSEL_CON10 */
+ /* CRU_CLKSEL_CON13 */
+ /* CRU_CLKSEL_CON16 */
+ /* CRU_CLKSEL_CON19 */
+ /* CRU_CLKSEL_CON22 */
+ CLK_UART_PLL_SEL_SHIFT = 13,
+ CLK_UART_PLL_SEL_MASK = 0x7 << CLK_UART_PLL_SEL_SHIFT,
+ CLK_UART_PLL_SEL_DPLL = 0,
+ CLK_UART_PLL_SEL_VPLL0,
+ CLK_UART_PLL_SEL_VPLL1,
+ CLK_UART_PLL_SEL_480M,
+ CLK_UART_PLL_SEL_24M,
+ CLK_UART_DIV_CON_SHIFT = 0,
+ CLK_UART_DIV_CON_MASK = 0x1f << CLK_UART_DIV_CON_SHIFT,
+
/* CRU_CLK_SEL25_CON */
/* CRU_CLK_SEL26_CON */
/* CRU_CLK_SEL27_CON */
diff --git a/drivers/clk/rockchip/clk_rk3308.c
b/drivers/clk/rockchip/clk_rk3308.c
index d27673c454..d0a3f65446 100644
--- a/drivers/clk/rockchip/clk_rk3308.c
+++ b/drivers/clk/rockchip/clk_rk3308.c
@@ -451,6 +451,58 @@ static ulong rk3308_pwm_set_clk(struct clk *clk, uint hz)
return rk3308_pwm_get_clk(clk);
}
+static ulong rk3308_uart_get_clk(struct clk *clk)
+{
+ struct rk3308_clk_priv *priv = dev_get_priv(clk->dev);
+ struct rk3308_cru *cru = priv->cru;
+ u32 div, pll_sel, con, con_id, parent;
+
+ switch (clk->id) {
+ case SCLK_UART0:
+ con_id = 10;
+ break;
+ case SCLK_UART1:
+ con_id = 13;
+ break;
+ case SCLK_UART2:
+ con_id = 16;
+ break;
+ case SCLK_UART3:
+ con_id = 19;
+ break;
+ case SCLK_UART4:
+ con_id = 22;
+ break;
+ default:
+ printf("do not support this uart interface\n");
+ return -EINVAL;
+ }
+
+ con = readl(>clksel_con[con_id]);
+ pll_sel = (con & CLK_UART_PLL_SEL_MASK) >> CLK_UART_PLL_SEL_SHIFT;
+ div = (con & CLK_UART_DIV_CON_MASK) >> CLK_UART_DIV_CON_SHIFT;
+
+ switch (pll_sel) {
+ case CLK_UART_PLL_SEL_DPLL:
+ parent = priv->dpll_hz;
+ break;
+ case CLK_UART_PLL_SEL_VPLL0:
+ parent = priv->vpll0_hz;
+ break;
+ case CLK_UART_PLL_SEL_VPLL1:
+ parent = priv->vpll0_hz;
+ break;
+ case CLK_UART_PLL_SEL_24M:
+ parent = OSC_HZ;
+ break;
+ default:
+ printf("do not support this uart pll sel\n");
+ return -EINVAL;
+ }
+
+ return DIV_TO_RATE(parent, div);
+}
+
static ulong rk3308_vop_get_clk(struct clk *clk)
{
struct rk3308_clk_priv *priv = dev_get_priv(clk->dev);
@@ -813,6 +865,13 @@ static ulong rk3308_clk_get_rate(struct clk *clk)
case SCLK_EMMC_SAMPLE:
rate = rk3308_mmc_get_clk(clk);
break;
+ case SCLK_UART0:
+ case SCLK_UART1:
+ case SCLK_UART2:
+ case SCLK_UART3:
+ case SCLK_UART4:
+ rate = rk3308_uart_get_clk(clk);
+ break;
case SCLK_I2C0:
case SCLK_I2C1:
case SCLK_I2C2:
Re: [PATCH 1/3] clk: rockchip: rk3308: Fix ordering between masking and shifting
On 2023/8/3 19:08, Massimo Pegorer wrote: As per definitions of masks and shift offsets in cru_rk3308.h, values read from registers must be first masked and then shifted. By the way, this fix is binary invariant, because in all of fixed cases the shift offset is zero. Signed-off-by: Massimo Pegorer Reviewed-by: Kever Yang Thanks, - Kever --- drivers/clk/rockchip/clk_rk3308.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/clk/rockchip/clk_rk3308.c b/drivers/clk/rockchip/clk_rk3308.c index 64f33587e2..d27673c454 100644 --- a/drivers/clk/rockchip/clk_rk3308.c +++ b/drivers/clk/rockchip/clk_rk3308.c @@ -150,7 +150,7 @@ static ulong rk3308_i2c_get_clk(struct clk *clk) } con = readl(>clksel_con[con_id]); - div = con >> CLK_I2C_DIV_CON_SHIFT & CLK_I2C_DIV_CON_MASK; + div = (con & CLK_I2C_DIV_CON_MASK) >> CLK_I2C_DIV_CON_SHIFT; return DIV_TO_RATE(priv->dpll_hz, div); } @@ -314,7 +314,7 @@ static ulong rk3308_saradc_get_clk(struct clk *clk) u32 div, con; con = readl(>clksel_con[34]); - div = con >> CLK_SARADC_DIV_CON_SHIFT & CLK_SARADC_DIV_CON_MASK; + div = (con & CLK_SARADC_DIV_CON_MASK) >> CLK_SARADC_DIV_CON_SHIFT; return DIV_TO_RATE(OSC_HZ, div); } @@ -342,7 +342,7 @@ static ulong rk3308_tsadc_get_clk(struct clk *clk) u32 div, con; con = readl(>clksel_con[33]); - div = con >> CLK_SARADC_DIV_CON_SHIFT & CLK_SARADC_DIV_CON_MASK; + div = (con & CLK_SARADC_DIV_CON_MASK) >> CLK_SARADC_DIV_CON_SHIFT; return DIV_TO_RATE(OSC_HZ, div); } @@ -385,7 +385,7 @@ static ulong rk3308_spi_get_clk(struct clk *clk) } con = readl(>clksel_con[con_id]); - div = con >> CLK_SPI_DIV_CON_SHIFT & CLK_SPI_DIV_CON_MASK; + div = (con & CLK_SPI_DIV_CON_MASK) >> CLK_SPI_DIV_CON_SHIFT; return DIV_TO_RATE(priv->dpll_hz, div); } @@ -429,7 +429,7 @@ static ulong rk3308_pwm_get_clk(struct clk *clk) u32 div, con; con = readl(>clksel_con[29]); - div = con >> CLK_PWM_DIV_CON_SHIFT & CLK_PWM_DIV_CON_MASK; + div = (con & CLK_PWM_DIV_CON_MASK) >> CLK_PWM_DIV_CON_SHIFT; return DIV_TO_RATE(priv->dpll_hz, div); }
Re: [PATCH] ram: mediatek: mt7629: include
On Mon, 2023-07-31 at 19:34 +0100, Daniel Golle wrote: > Something between U-Boot 2023.04 and 2023.07.02 resulted in no > longer > implicitely including in the DDR3 RAM driver for the > MT7929 SoC. The result is a build failure: > drivers/ram/mediatek/ddr3-mt7629.c: In function 'mtk_ddr3_get_info': > drivers/ram/mediatek/ddr3-mt7629.c:734:30: error: 'SZ_128M' > undeclared (first use in this function) > 734 | info->size = SZ_128M; > | ^~~ > drivers/ram/mediatek/ddr3-mt7629.c:734:30: note: each undeclared > identifier is reported only once for each function it appears in > drivers/ram/mediatek/ddr3-mt7629.c:737:30: error: 'SZ_256M' > undeclared (first use in this function) > 737 | info->size = SZ_256M; > | ^~~ > drivers/ram/mediatek/ddr3-mt7629.c:740:30: error: 'SZ_512M' > undeclared (first use in this function) > 740 | info->size = SZ_512M; > | ^~~ > drivers/ram/mediatek/ddr3-mt7629.c:743:30: error: 'SZ_1G' undeclared > (first use in this function) > 743 | info->size = SZ_1G; > | ^ > > Include so SZ_* is defined. > > Reported-by: Tianling Shen > Signed-off-by: Daniel Golle > --- > Reviewed-by: Weijie Gao
[PATCH] arm: dts: medaitek: convert gmac link mode to 2500base-x for mt7986a-bpi-r3-sd
The mt7531 of bpi-r3 is connected to mt7986 with 2.5Gbps HSGMII, not the
regular 1Gbps SGMII.
Signed-off-by: Weijie Gao
---
This is a supplement to commit:
aef54ea1 (arm: dts: medaitek: convert gmac link mode to 2500base-x)
---
arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
index 15256302b8..c156a81363 100644
--- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
+++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
@@ -76,12 +76,12 @@
{
status = "okay";
mediatek,gmac-id = <0>;
- phy-mode = "sgmii";
+ phy-mode = "2500base-x";
mediatek,switch = "mt7531";
reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
fixed-link {
- speed = <1000>;
+ speed = <2500>;
full-duplex;
};
};
--
2.17.1
[PATCH 1/1] video: avoid build failure on veyron board
533ad9dc avoided an overflow but causes compilation
failure on 32bit boards (eg. veyron speedy)
this commit uses div_u64 which has a fallback codepath
for 32bit platforms
Signed-off-by: Alvaro Fernando García
---
drivers/video/pwm_backlight.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/pwm_backlight.c b/drivers/video/pwm_backlight.c
index 46c16a8f44..aa0e292866 100644
--- a/drivers/video/pwm_backlight.c
+++ b/drivers/video/pwm_backlight.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
/**
@@ -59,12 +60,14 @@ struct pwm_backlight_priv {
static int set_pwm(struct pwm_backlight_priv *priv)
{
+ u64 width;
uint duty_cycle;
int ret;
if (priv->period_ns) {
- duty_cycle = (u64)priv->period_ns * (priv->cur_level -
priv->min_level) /
- (priv->max_level - priv->min_level);
+ width = priv->period_ns * (priv->cur_level - priv->min_level);
+ duty_cycle = div_u64(width,
+(priv->max_level - priv->min_level));
ret = pwm_set_config(priv->pwm, priv->channel, priv->period_ns,
duty_cycle);
} else {
--
2.41.0
[PATCH 0/1] Avoid build failure on veyron board
I noticed that u-boot stopped building for Veyron boards since commit 533ad9dc, which may also affect other 32bit boards. This series fixes compilation by using div_u64 operation. I apologize for any inconvenient, this is my first patch. Alvaro Fernando García (1): video: avoid build failure on veyron board drivers/video/pwm_backlight.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) -- 2.41.0
Re: [PATCH 1/2] dm: core: ofnode: Add ofnode_read_bootscript_flash()
On Thu, 3 Aug 2023 at 07:36, Michal Simek wrote: > > ofnode_read_bootscript_flash() reads bootscript address from > /options/u-boot DT node. bootscr-flash-offset and bootscr-flash-size > properties are read and values are filled. When bootscr-flash-size is not > defined, bootscr-flash-offset property is unusable that's why cleaned. > Both of these properties should be defined to function properly. > > Also add test to cover this new function. > > Signed-off-by: Michal Simek > --- > > arch/sandbox/dts/test.dts | 2 ++ > drivers/core/ofnode.c | 34 ++ > include/dm/ofnode.h | 27 +++ > test/dm/ofnode.c | 9 +++-- > 4 files changed, 70 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCH v6 3/9] capsule: authenticate: Add capsule public key in platform's dtb
Hi Sughosh,
On Thu, 3 Aug 2023 at 05:12, Sughosh Ganu wrote:
>
> hi Simon,
>
> On Wed, 2 Aug 2023 at 19:04, Simon Glass wrote:
> >
> > Hi Sughosh,
> >
> > On Wed, 2 Aug 2023 at 06:52, Simon Glass wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Tue, 1 Aug 2023 at 11:40, Sughosh Ganu wrote:
> > > >
> > > > The EFI capsule authentication logic in u-boot expects the public key
> > > > in the form of an EFI Signature List(ESL) to be provided as part of
> > > > the platform's dtb. Currently, the embedding of the ESL file into the
> > > > dtb needs to be done manually.
> > > >
> > > > Add a signature node in the u-boot dtsi file and include the public
> > > > key through the capsule-key property. This file is per architecture,
> > > > and is currently being added for sandbox and arm architectures. It
> > > > will have to be added for other architectures which need to enable
> > > > capsule authentication support.
> > > >
> > > > The path to the ESL file is specified through the
> > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V5:
> > > > * None
> > > >
> > > > arch/arm/dts/u-boot.dtsi | 14 ++
> > > > arch/sandbox/dts/u-boot.dtsi | 17 +
> > > > lib/efi_loader/Kconfig | 9 +
> > > > 3 files changed, 40 insertions(+)
> > > > create mode 100644 arch/arm/dts/u-boot.dtsi
> > > > create mode 100644 arch/sandbox/dts/u-boot.dtsi
> > > >
> > > > diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
> > > > new file mode 100644
> > > > index 00..4f31da4521
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/u-boot.dtsi
> > > > @@ -0,0 +1,14 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/**
> > > > + * Devicetree file with miscellaneous nodes that will be included
> > > > + * at build time into the DTB. Currently being used for including
> > > > + * capsule related information.
> > > > + */
> > > > +
> > > > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > > > +/ {
> > > > + signature {
> > > > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > + };
> > > > +};
> > > > +#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
> >
> > Ilias mentioned that this binding can cause problems if it not
> > upstream, causing the platform to fail validation. So we need to agree
> > a binding for it in dt-schema. Can you send a patch to we can discuss
> > it there?
>
> There was an effort from Jassi earlier [1] to upstream one such
> binding for the FWU node. But Rob had asked to remove this in u-boot
> before the DT was passed over to the kernel.
I don't like that idea...U-Boot's DT needs to pass validation too, of course!
- Simon
>
> -sughosh
>
> [1] -
> https://lore.kernel.org/u-boot/cal_jsqjn4fehoml7z3yj0wj9bpx1ose7zf26l_gv2os6cg-...@mail.gmail.com/
>
> >
> > Regards,
> > Simon
Re: [PATCH v2 9/9] x86: Update qemu documentation
Hi Soeren, On Sun, 30 Jul 2023 at 11:38, Soeren Moch wrote: > > On 30.07.23 19:16, Simon Glass wrote: > > Add some hints and observations related to booting distros on QEMU on x86. > > > > Signed-off-by: Simon Glass > Simon, > > you cc'd me on this patch (both versions), but I never used u-boot on > x86. What do you expect from my side here? This is automatic with get_maintainers.pl but I am not sure why it added you. Regards, Simon > > > > (no changes since v1) > > > > doc/board/emulation/qemu-x86.rst | 88 ++-- > > 1 file changed, 84 insertions(+), 4 deletions(-) > > > > diff --git a/doc/board/emulation/qemu-x86.rst > > b/doc/board/emulation/qemu-x86.rst > > index e7dd4e994d38..15f56b6bc706 100644 > > --- a/doc/board/emulation/qemu-x86.rst > > +++ b/doc/board/emulation/qemu-x86.rst > > @@ -113,7 +113,87 @@ sure the specified CPU supports 64-bit like '-cpu > > core2duo'. Conversely > > '-cpu pentium' won't work for obvious reasons that the processor only > > supports 32-bit. > > > > -Note 64-bit support is very preliminary at this point. Lots of features > > -are missing in the 64-bit world. One notable feature is the VGA console > > -support which is currently missing, so that you must specify '-nographic' > > -to get 64-bit U-Boot up and running. > > +Booting distros > > +--- > > + > > +It is possible to install and boot a standard Linux distribution using > > +qemu-x86_64 by setting up a root disk:: > > + > > + qemu-img create root.img 10G > > + > > +then using the installer to install. For example, with Ubuntu 2023.04:: > > + > > + qemu-system-x86_64 -m 8G -smp 4 -bios /tmp/b/qemu-x86_64/u-boot.rom \ > > + -drive file=root.img,if=virtio,driver=raw \ > > + -drive file=ubuntu-23.04-desktop-amd64.iso,if=virtio,driver=raw > > + > > +You can also add `-serial mon:stdio` if you want the serial console to > > show as > > +well as the video. > > + > > +The output will be something like this:: > > + > > + U-Boot SPL 2023.07 (Jul 23 2023 - 08:00:12 -0600) > > + Trying to boot from SPI > > + Jumping to 64-bit U-Boot: Note many features are missing > > + > > + > > + U-Boot 2023.07 (Jul 23 2023 - 08:00:12 -0600) > > + > > + CPU: QEMU Virtual CPU version 2.5+ > > + DRAM: 8 GiB > > + Core: 20 devices, 13 uclasses, devicetree: separate > > + Loading Environment from nowhere... OK > > + Model: QEMU x86 (I440FX) > > + Net: e1000: 52:54:00:12:34:56 > > + eth0: e1000#0 > > + Hit any key to stop autoboot: 0 > > + Scanning for bootflows in all bootdevs > > + Seq Method State UclassPart Name > > Filename > > + --- --- -- > > > > + Scanning global bootmeth 'efi_mgr': > > + Hunting with: nvme > > + Hunting with: qfw > > + Hunting with: scsi > > + scanning bus for devices... > > + Hunting with: virtio > > + Scanning bootdev 'qfw_pio.bootdev': > > + fatal: no kernel available > > + Scanning bootdev 'virtio-blk#0.bootdev': > > + Scanning bootdev 'virtio-blk#1.bootdev': > > + 0 efi ready virtio 2 virtio-blk#1.bootdev.part > > efi/boot/bootx64.efi > > + ** Booting bootflow 'virtio-blk#1.bootdev.part_2' with efi > > + EFI using ACPI tables at f0060 > > +efi_install_fdt() WARNING: Can't have ACPI table and device tree - > > ignoring DT. > > + efi_run_image() Booting /efi\boot\bootx64.efi > > + error: file `/boot/' not found. > > + > > +Standard boot looks through various available devices and finds the virtio > > +disks, then boots from the first one. After a second or so the grub menu > > appears > > +and you can work through the installer flow normally. > > + > > +Note that standard boot will not find 32-bit distros, since it looks for a > > +different filename. > > + > > +Current limitations > > +--- > > + > > +Only qemu-x86-64 can be used for booting distros, since qemu-x86 (the > > 32-bit > > +version of U-Boot) seems to have an EFI bug leading to the boot handing > > after > > +Linux is selected from grub, e.g. with `debian-12.1.0-i386-netinst.iso`:: > > + > > + ** Booting bootflow 'virtio-blk#1.bootdev.part_2' with efi > > + EFI using ACPI tables at f0180 > > +efi_install_fdt() WARNING: Can't have ACPI table and device tree - > > ignoring DT. > > + efi_run_image() Booting /efi\boot\bootia32.efi > > + Failed to open efi\boot\root=/dev/sdb3 - Not Found > > + Failed to load image 큀緃: Not Found > > + start_image() returned Not Found, falling back to default loader > > + Welcome to GRUB! > > + > > +The bochs video driver also seems to cause problems before the OS is able > > to > > +show a display. > > + > > +Finally, the use of `-M accel=kvm` is intended to use the native CPU's > > +virtual-machine features to accelerate operation, but this causes U-Boot > > to hang > > +when jumping 64-bit
Re: [PATCH] pinctrl: rockchip: Fix drive and input schmitt on RK3568
On Thu, 3 Aug 2023 at 11:44, Jonas Karlman wrote:
>
> rk3568_set_drive configures a second reg for specific pins. Mainline
> linux does not do this and vendor U-Boot only run similar code when bit
> 14 and 15 are both 0 in PMU_GRF_SOC_CON0. Something that presumably only
> early revisions of the SoC have, all my RK3566/RK3568 boards read back
> bit 15 as 1, even on boards dated back to 21H1.
>
> This cause e.g. ethernet PHY on Radxa CM3-IO board not to work after
> drive is configured according to the device tree.
>
> Input schmitt is configured in 2-bit fields on RK3568 compared to earlier
> generation and 2'b10 should be used to enable input schmitt.
>
> Remove the code that presumably was intended for early pre-production
> revisions of the SoC and write correct values for input schmitt setting.
> Also change to use regmap_update_bits to closer match linux driver.
>
> Fixes: 1977d746aa54 ("rockchip: rk3568: add rk3568 pinctrl driver")
> Signed-off-by: Jonas Karlman
> ---
> drivers/pinctrl/rockchip/pinctrl-rk3568.c | 52 ++-
> 1 file changed, 14 insertions(+), 38 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH] rockchip: rk356x: Enable poweroff command
On Thu, 3 Aug 2023 at 13:54, Jonas Karlman wrote: > > With PMIC_RK8XX, SYSRESET and CMD_POWEROFF options enabled it is > possible to power down a board using the poweroff command and turn the > board back on using a power button. > > Enable the poweroff command on RK356x boards that have a button wired > to PMIC pwron. Also update to use PMIC poweroff when PMIC_RK8XX is > enabled to avoid also having to enable the SYSRESET_CMD_POWEROFF option. > > Signed-off-by: Jonas Karlman > --- > configs/quartz64-a-rk3566_defconfig | 1 + > configs/quartz64-b-rk3566_defconfig | 1 + > configs/rock-3a-rk3568_defconfig | 1 + > configs/soquartz-model-a-rk3566_defconfig | 1 + > drivers/power/pmic/Kconfig| 1 + > 5 files changed, 5 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 2/2] spl: move SPL_CRC32 option to lib/Kconfig
On Thu, 3 Aug 2023 at 10:05, Oleksandr Suvorov wrote: > > All SPL hash algorithm options are collected in lib/Kconfig. Move > SPL_CRC32 there as well. > > Signed-off-by: Oleksandr Suvorov > --- > > Changes in v2: > - add a related commit to the series. > > common/spl/Kconfig | 11 --- > lib/Kconfig| 11 +++ > 2 files changed, 11 insertions(+), 11 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
Hi Bin,
On Thu, 3 Aug 2023 at 08:19, Bin Meng wrote:
>
> Hi Tom, Simon,
>
> On Thu, Aug 3, 2023 at 9:13 PM Tom Rini wrote:
> >
> > On Thu, Aug 03, 2023 at 07:03:47PM +0800, Bin Meng wrote:
> > > On Thu, Aug 3, 2023 at 6:37 PM Bin Meng wrote:
> > > >
> > > > On Tue, Aug 1, 2023 at 12:00 AM Simon Glass wrote:
> > > > >
> > > > > When the video framebuffer comes from the bloblist, we should not
> > > > > change
> > > > > relocaddr to this address, since it interfers with the normal memory
> > > >
> > > > typo: interferes
> > > >
> > > > > allocation.
> > > > >
> > > > > This fixes a boot loop in qemu-x86_64
> > > > >
> > > > > Signed-off-by: Simon Glass
> > > > > Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL
> > > > > to u-boot")
> > > > > Suggested-by: Nikhil M Jain
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > > - Reword the Kconfig help as suggested
> > > > >
> > > > > Changes in v2:
> > > > > - Add a Kconfig as the suggested conditional did not work
> > > > >
> > > > > common/board_f.c | 3 ++-
> > > > > drivers/video/Kconfig | 9 +
> > > > > 2 files changed, 11 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/common/board_f.c b/common/board_f.c
> > > > > index 7d2c380e91e..5173d0a0c2d 100644
> > > > > --- a/common/board_f.c
> > > > > +++ b/common/board_f.c
> > > > > @@ -419,7 +419,8 @@ static int reserve_video(void)
> > > > > if (!ho)
> > > > > return log_msg_ret("blf", -ENOENT);
> > > > > video_reserve_from_bloblist(ho);
> > > > > - gd->relocaddr = ho->fb;
> > > > > + if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
> > > > > + gd->relocaddr = ho->fb;
> > > > > } else if (CONFIG_IS_ENABLED(VIDEO)) {
> > > > > ulong addr;
> > > > > int ret;
> > > > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> > > > > index b41dc60cec5..f2e56204d52 100644
> > > > > --- a/drivers/video/Kconfig
> > > > > +++ b/drivers/video/Kconfig
> > > > > @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
> > > > > if this option is enabled video driver will be removed at
> > > > > the end of
> > > > > SPL stage, beforeloading the next stage.
> > > > >
> > > > > +config VIDEO_RESERVE_SPL
> > > > > + bool
> > > > > + help
> > > > > + This adjusts reserve_video() to redirect memory reservation
> > > > > when it
> > > > > + sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This
> > > > > avoids the
> > > > > + memory used for framebuffer from being allocated by U-Boot
> > > > > proper,
> > > > > + thus preventing any further memory reservations done by
> > > > > U-Boot proper
> > > > > + from overwriting the framebuffer.
> > > > > +
> > > > > if SPL_SPLASH_SCREEN
> > > > >
> > > > > config SPL_SPLASH_SCREEN_ALIGN
> > > >
> > > > Reviewed-by: Bin Meng
> > >
> > > applied to u-boot-x86, thanks!
> >
> > This isn't the right path, we need to test:
> > https://patchwork.ozlabs.org/project/uboot/patch/20230801140414.76216-1-devar...@ti.com/
>
> I can drop this commit and apply Devarsh's one, but looks there are
> some arguments.
>
> Let me know which one is the preferred approach.
We can take that one at least for now...I have spent enough time
trying to explain the problem.
Regards,
Simon
Re: [PATCH] common: board_f: Move relocation address after framebuffer
Hi Devarsh,
On Thu, 3 Aug 2023 at 08:28, Devarsh Thakkar wrote:
>
> Hi Simon,
>
> On 03/08/23 19:32, Simon Glass wrote:
> > +Bin Meng
> >
> > Hi Devarsh,
> >
> > On Tue, 1 Aug 2023 at 08:04, Devarsh Thakkar wrote:
> >>
> >> When passing framebuffer address using bloblist, check
> >> that passed address is overlapping with current relocation
> >> address, if so move the relocation address after the framebuffer
> >> region to avoid overlap.
> >>
> >> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from
> >> SPL to u-boot")
> >> Signed-off-by: Devarsh Thakkar
> >> ---
> >> common/board_f.c | 5 -
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/common/board_f.c b/common/board_f.c
> >> index 7d2c380e91..20fa17207a 100644
> >> --- a/common/board_f.c
> >> +++ b/common/board_f.c
> >> @@ -419,7 +419,10 @@ static int reserve_video(void)
> >> if (!ho)
> >> return log_msg_ret("blf", -ENOENT);
> >> video_reserve_from_bloblist(ho);
> >> - gd->relocaddr = ho->fb;
> >> + /* Relocate after framebuffer area to avoid overlap */
> >> + if (gd->relocaddr > (unsigned long)ho->fb)
> >> + gd->relocaddr = ho->fb;
> >> +
> >> } else if (CONFIG_IS_ENABLED(VIDEO)) {
> >> ulong addr;
> >> int ret;
> >> --
> >> 2.34.1
> >>
> >
> > Yes this happens to work with qemu-x86_64. However it depends on the
> > SPL frame buffer being below the current allocation area. Why would it
> > be below, in general? This seems like a land mine for others to trip
> > up on.
> >
>
> Basically to avoid overlap, the thing we are enforcing here is that
> relocaddr should always be below framebuffer so that further areas
> reserved do not overlap with framebuffer since we decrement relocaddr to
> resereve them. If relocaddr is already below framebuffer then there is no
> need to update relocaddr as in your case otherwise we have to do it, hence
> working for both scenarios.
That's not true in general. Say the frame buffer is at 1GB and
U-Boot's top of memory is at 2GB, then this will create a gap in the
reservations, so some things are just below 2GB and some others are
just below 1GB. There will be no indication of this...
>
> The way I look at it is at u-boot proper is getting a blob from SPL
> with video handoff structure and before carrying out further reservations
> u-boot proper being agnostic to the framebuffer address set by SPL should have
> some check to make sure there is no overlap with current relocaddr.
>
>
> I think this is similar to suggestion from Tom and you regarding moving the
> ram_top if framebuffer is reserved near the ram_top, albeit instead of moving
> ram_top I am moving relocaddr which is derived from ram_top.
>
> Kindly let me know if any queries.
It just doesn't make sense to me...if you want to influence U-Boot's
reservation, add a handoff blob to tell U-Boot that.
Regards,
Simon
>
> Regards
> Devarsh
>
> > Anyway I am OK with this for now since it fixes my problems. I would
> > prefer something positive like the Kconfig I provided, since I still
> > think it is very weird to interrupt the U-Boot reservation process
> > like this.>
> > Reviewed-by: Simon Glass
> >
> > Regards,
> > Simon
Re: [PATCH v4 1/3] binman: btool: Add Xilinx Bootgen btool
On Thu, 3 Aug 2023 at 09:22, wrote: > > From: Lukas Funke > > Add the Xilinx Bootgen as bintool. Xilinx Bootgen is used to create > bootable SPL (FSBL in Xilinx terms) images for Zynq/ZynqMP devices. The > btool creates a signed version of the SPL. Additionally to signing the > key source for the decryption engine can be passend to the boot image. > > Signed-off-by: Lukas Funke > > --- > > Changes in v4: > - Fixed some typos > > Changes in v3: > - Fixed an issue where the build result was not found > - Fixed an issue where the version string was not reported correctly > > Changes in v2: > - Pass additional 'keysrc_enc' parameter to Bootgen > - Added more information and terms to documentation > > tools/binman/bintools.rst | 2 +- > tools/binman/btool/bootgen.py | 137 ++ > 2 files changed, 138 insertions(+), 1 deletion(-) > create mode 100644 tools/binman/btool/bootgen.py > Reviewed-by: Simon Glass
[PATCH] binman: Renumber 291 and 292 test files
These have ended up with the same numbers as earlier files. Fix them.
Signed-off-by: Simon Glass
---
tools/binman/ftest.py | 4 ++--
.../{291_template_phandle.dts => 309_template_phandle.dts}| 0
..._template_phandle_dup.dts => 310_template_phandle_dup.dts} | 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename tools/binman/test/{291_template_phandle.dts =>
309_template_phandle.dts} (100%)
rename tools/binman/test/{292_template_phandle_dup.dts =>
310_template_phandle_dup.dts} (100%)
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index d2315ebd5ea0..0abb95d46cf0 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -6974,7 +6974,7 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
entry_args = {
'atf-bl31-path': 'bl31.elf',
}
-data = self._DoReadFileDtb('291_template_phandle.dts',
+data = self._DoReadFileDtb('309_template_phandle.dts',
entry_args=entry_args)
fname = tools.get_output_filename('image.bin')
out = tools.run('dumpimage', '-l', fname)
@@ -6990,7 +6990,7 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
'atf-bl31-path': 'bl31.elf',
}
with self.assertRaises(ValueError) as e:
-self._DoReadFileDtb('292_template_phandle_dup.dts',
+self._DoReadFileDtb('310_template_phandle_dup.dts',
entry_args=entry_args)
self.assertIn(
'Duplicate phandle 1 in nodes
/binman/image/fit/images/atf/atf-bl31 and
/binman/image-2/fit/images/atf/atf-bl31',
diff --git a/tools/binman/test/291_template_phandle.dts
b/tools/binman/test/309_template_phandle.dts
similarity index 100%
rename from tools/binman/test/291_template_phandle.dts
rename to tools/binman/test/309_template_phandle.dts
diff --git a/tools/binman/test/292_template_phandle_dup.dts
b/tools/binman/test/310_template_phandle_dup.dts
similarity index 100%
rename from tools/binman/test/292_template_phandle_dup.dts
rename to tools/binman/test/310_template_phandle_dup.dts
--
2.41.0.640.ga95def55d0-goog
[PATCH v3 2/2] x86: coreboot: Enable standard boot
Enable bootstd options and provide instructions on how to boot a linux distro using coreboot. Signed-off-by: Simon Glass --- Changes in v3: - Drop patches already applied to x86/master configs/coreboot64_defconfig| 14 ++ configs/coreboot_defconfig | 1 + doc/board/coreboot/coreboot.rst | 16 ++-- 3 files changed, 17 insertions(+), 14 deletions(-) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index ded0e6f2422d..602465175d20 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -10,40 +10,30 @@ CONFIG_VENDOR_COREBOOT=y CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y +CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x0112 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro" -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="ext2load scsi 0:3 0100 /boot/vmlinuz; zboot 0100" CONFIG_PRE_CONSOLE_BUFFER=y CONFIG_SYS_CONSOLE_INFO_QUIET=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_SPL_NO_BSS_LIMIT=y -CONFIG_HUSH_PARSER=y CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y -CONFIG_CMD_PART=y CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set -CONFIG_CMD_DHCP=y CONFIG_BOOTP_BOOTFILESIZE=y -CONFIG_CMD_PING=y CONFIG_CMD_TIME=y CONFIG_CMD_SOUND=y -CONFIG_CMD_EXT2=y -CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y -CONFIG_CMD_FAT=y -CONFIG_CMD_FS_GENERIC=y CONFIG_MAC_PARTITION=y # CONFIG_SPL_MAC_PARTITION is not set # CONFIG_SPL_DOS_PARTITION is not set -CONFIG_ISO_PARTITION=y -CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_ENV_OVERWRITE=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 56cc542df6c6..735cd6eb4c22 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -10,6 +10,7 @@ CONFIG_TARGET_COREBOOT=y CONFIG_FIT=y CONFIG_FIT_SIGNATURE=y CONFIG_BOOTSTD_FULL=y +CONFIG_BOOTSTD_DEFAULTS=y CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_USE_BOOTARGS=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index b2c0a4c20c98..21c82e108487 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -67,9 +67,21 @@ To use 4GB of memory, typically necessary for booting Linux distros, add In addition to the 32-bit 'coreboot' build there is a 'coreboot64' build. This produces an image which can be booted from coreboot (32-bit). Internally it works by using a 32-bit SPL binary to switch to 64-bit for running U-Boot. It -can be useful for running UEFI applications, for example. +can be useful for running UEFI applications, for example with the coreboot +build in `$CBDIR`:: + + DISK=ubuntu-23.04-desktop-amd64.iso + CBDIR=~/coreboot/build + + cp $CBDIR/coreboot.rom.in coreboot.rom + cbfstool coreboot.rom add-flat-binary -f u-boot-x86-with-spl.bin \ + -n fallback/payload -c LZMA -l 0x111 -e 0x111 + + qemu-system-x86_64 -m 2G -smp 4 -bios coreboot.rom \ + -drive id=disk,file=$DISK,if=none \ + -device ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 \ -This has only been lightly tested. CBFS access --- -- 2.41.0.640.ga95def55d0-goog
[PATCH v3 1/2] x86: coreboot: Add IDE and SATA
Add these options to permit access to more disk types. Add some documentation as well. Signed-off-by: Simon Glass --- Changes in v3: - Update the documentation to use ich9-ahci - Mention that $DISK is a disk-image file configs/coreboot64_defconfig| 1 + configs/coreboot_defconfig | 9 + doc/board/coreboot/coreboot.rst | 20 3 files changed, 30 insertions(+) diff --git a/configs/coreboot64_defconfig b/configs/coreboot64_defconfig index 8aadaa68c279..ded0e6f2422d 100644 --- a/configs/coreboot64_defconfig +++ b/configs/coreboot64_defconfig @@ -26,6 +26,7 @@ CONFIG_SYS_PBSIZE=532 CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y diff --git a/configs/coreboot_defconfig b/configs/coreboot_defconfig index 8e11de663819..56cc542df6c6 100644 --- a/configs/coreboot_defconfig +++ b/configs/coreboot_defconfig @@ -22,8 +22,10 @@ CONFIG_LOGF_FUNC=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_LAST_STAGE_INIT=y CONFIG_PCI_INIT_R=y +CONFIG_CMD_IDE=y CONFIG_CMD_MMC=y CONFIG_CMD_PART=y +CONFIG_CMD_SATA=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_DHCP=y @@ -48,6 +50,13 @@ CONFIG_USE_ROOTPATH=y CONFIG_REGMAP=y CONFIG_SYSCON=y # CONFIG_ACPIGEN is not set +CONFIG_SYS_IDE_MAXDEVICE=4 +CONFIG_SYS_ATA_DATA_OFFSET=0 +CONFIG_SYS_ATA_REG_OFFSET=0 +CONFIG_SYS_ATA_ALT_OFFSET=0 +CONFIG_ATAPI=y +CONFIG_LBA48=y +CONFIG_SYS_64BIT_LBA=y CONFIG_NVME_PCI=y # CONFIG_PCI_PNP is not set CONFIG_SOUND=y diff --git a/doc/board/coreboot/coreboot.rst b/doc/board/coreboot/coreboot.rst index 21801a8a4d90..b2c0a4c20c98 100644 --- a/doc/board/coreboot/coreboot.rst +++ b/doc/board/coreboot/coreboot.rst @@ -41,6 +41,26 @@ At present it seems that for Minnowboard Max, coreboot does not pass through the video information correctly (it always says the resolution is 0x0). This works correctly for link though. +You can run via QEMU using:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio + +The `-serial mon:stdio` part shows both output in the display and on the +console. It is optional. You can add `nographic` as well to *only* get console +output. + +To run with a disk-image file called `$DISK`:: + + qemu-system-x86_64 -bios build/coreboot.rom -serial mon:stdio \ + -drive id=disk,file=$DISK,if=none \ + -device ich9-ahci,id=ahci \ + -device ide-hd,drive=disk,bus=ahci.0 + +Then you can scan it with `scsi scan` and access it normally. + +To use 4GB of memory, typically necessary for booting Linux distros, add +`-m 4GB`. + 64-bit U-Boot - -- 2.41.0.640.ga95def55d0-goog
[PATCH v3 0/2] x86: Improve bootstd support
This series provides some bootstd fixes so that IDE can be used reliably for booting a distro. It also includes some documentation on how to boot from coreboot in various scenarios, using QEMU. With this it is possible to boot Ubuntu 2023.04 from coreboot64, for example. This series is available at u-boot-dm/metha-working It depends on https://patchwork.ozlabs.org/project/uboot/list/?series=365943 Changes in v3: - Update the documentation to use ich9-ahci - Mention that $DISK is a disk-image file - Drop patches already applied to x86/master Simon Glass (2): x86: coreboot: Add IDE and SATA x86: coreboot: Enable standard boot configs/coreboot64_defconfig| 15 +++--- configs/coreboot_defconfig | 10 + doc/board/coreboot/coreboot.rst | 36 +++-- 3 files changed, 47 insertions(+), 14 deletions(-) -- 2.41.0.640.ga95def55d0-goog
Re: [PATCH 5/5] bootstd: Init the size before reading extlinux file
On Wed, Jul 26, 2023 at 09:01:25PM -0600, Simon Glass wrote: > The implementation in extlinux_pxe_getfile() does not pass a valid size > to bootmeth_read_file(), so this can fail if the uninited value happens to > be too small. > > Fix this. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/5] bootstd: Init the size before reading the devicetree
On Wed, Jul 26, 2023 at 09:01:24PM -0600, Simon Glass wrote: > The implementation in distro_efi_try_bootflow_files() does not pass a > valid size to bootmeth_common_read_file(), so this can fail if the > uninted value happens to be too small. > > Fix this. > > This was reported by someone but I cannot now find the email. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/5] bootstd: Avoid allocating memory for the EFI file
On Wed, Jul 26, 2023 at 09:01:23PM -0600, Simon Glass wrote: > The current bootflow-iteration algorithm reads the bootflow file into > an allocated memory buffer so it can be examined. This works well in > most cases. > > However, while the common case is that the first bootflow is immediately > booted, it is also possible just to scan for available bootflows, perhaps > selecting one to boot later. > > Even with the common case, EFI bootflows can be quite large. It doesn't > make sense to read it into an allocated buffer when we have kernel_addr_t > providing a suitable address for it. Even if we do have plenty of malloc() > space available, it is a violation of U-Boot's lazy-init principle to > read the bootflow before it is needed. > > So overall it seems better to make a change. > > Adjust the logic to read just the size of the EFI file at first. Later, > when the bootflow is booted, read the rest of the file into the designated > kernel buffer. > > Signed-off-by: Simon Glass > Reported-by: Da Xue > Reported-by: Vincent Stehlé Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/5] bootstd: Use a function to detect network in EFI bootmeth
On Wed, Jul 26, 2023 at 09:01:22PM -0600, Simon Glass wrote: > This checks for a network-based bootflow in two places, one of which is > less than ideal. Move the correct test into a function and use it in both > places. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] bootflow: Export setup_fs()
On Wed, Jul 26, 2023 at 09:01:21PM -0600, Simon Glass wrote: > This function is used in some bootmeth implementations. Export it. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] virtio: provide driver name in debug message
On Wed, Jul 26, 2023 at 05:43:40PM +0200, Heinrich Schuchardt wrote: > If a driver cannot be bound, provide the driver name in the debug > message. Now the debug message may look like this: > > (virtio-pci.l#0): virtio-rng driver not configured > > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] fat: correct sign for deletion mark
On Wed, Jul 26, 2023 at 10:33:13AM +0200, Heinrich Schuchardt wrote:
> The FAT file systems uses character '\xe5' to mark a deleted directory
> entry. If a file name starts with this character, it is substituted by
> '\x05' in the directory entry.
>
> While (signed char)'\xe5' is a negative number 0xe5 is a positive integer
> number. We therefore have define a constant DELETED_MARK which matches the
> signedness of the characters in the directory entry.
>
> Correct a comparison where we used the constant 0xe5 with the wrong sign.
> Use the constant aRING instead of 0x05 like in the rest of the code.
>
> Reported-by: Dan Carpenter
> Fixes: 57b745e2387a ("fs: fat: call set_name() only once")
> Fixes: 28cef9ca2e86 ("fs: fat: create correct short names")
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 3/4] rzn1-snarc: Add missing MAINTAINERS file
On Tue, Jul 25, 2023 at 06:31:55PM -0400, Tom Rini wrote: > This should have been included when the platform was added, make one > now. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] board/freescale: Drop two orphaned entries
On Tue, Jul 25, 2023 at 06:31:54PM -0400, Tom Rini wrote: > As the defconfig files here have been removed we can also remove the > entries. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] vexpress64: Rework MAINTAINERS file slightly
On Tue, Jul 25, 2023 at 06:31:53PM -0400, Tom Rini wrote: > Given that we no longer have a configs/vexpress_aemv8a_defconfig file, > drop that and then include at least the aarch64-specific config.h file > here. Also move Linus and Peter up to the main entry as well so that > they'll get tagged for the board code too and not literally only the > defconfig. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: imx: Update MAINTAINERS file on DH electronics i.MX8M Plus DHCOM
On Tue, Jul 18, 2023 at 06:14:35PM +0200, Marek Vasut wrote: > Make use of globs to cover all the DTs and defconfigs. > Fill in missing DH u-boot list name. > > Signed-off-by: Marek Vasut Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] freescale: Remove Rajesh Bhagat MAINTAINERS
On Tue, Oct 18, 2022 at 02:12:46PM -0400, Sean Anderson wrote: > Rajesh's email bounces. Remove his email from all boards he maintains. > Fortunately, he has co-maintainers on most boards. I have taken the > liberty of volunteering Pramod to maintain the LS1012AFRDM, since he > also maintains the LS1012AFRWY. Let me know if the board should be > orphaned instead. > > Signed-off-by: Sean Anderson Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] bootstd: Improve ChromiumOS support
Hi Simon, On 2023-07-30 20:16 +03:00, Simon Glass wrote: > The ChromiumOS bootmeth is fairly basic at present. It is able to boot > only x86 kernels and contains quite a few hard-coded offsets. > > This series tidies it up by bringing in some vboot structures and adding > support for ARM. > > It adds a few more features to bootstd, including display of x86 setup > information. Can't do a detailed review or test for a while, but had a cursory look now and wanted to reply. I'm not sure if you heard of it, but I maintain an alternate implementation of ChromiumOS verified boot userspace called depthcharge-tools [1]. Its main purpose is booting ordinary distros on Chromebooks, but it would be nice if your U-Boot implementation was also compatible with images produced from that. I guess it boils down to: - Enable booting from any chromeos_kernel partition (not just 2 & 4) - Fixup the ramdisk addr/size in x86 setup info after reading the kernel - Replace %U with chromeos_kernel PARTUUID (you probably already do?) - Prepend cros_secure to kernel cmdline There's a ready made debian-installer image if you want to test [2]. Has a partitioning bug defaulting to MBR, but otherwise can install for CrOS verified boot as well. (It's what took my last year away from U-Boot). [1] depthcharge-tools -- Tools to manage the Chrome OS bootloader https://github.com/alpernebbi/depthcharge-tools [2] Debian Installer netboot image for amd64 Chromebooks https://d-i.debian.org/daily-images/amd64/daily/netboot/depthcharge/ > So far this does not actually boot correctly on any ARM Chromebook: > >jerry - hangs when booting kernel >bob - Bad Linux ARM64 Image magic! with lz4-compressed kernel > > Further work can address these issues. I haven't been able to boot recent kernels with extlinux.conf on my pre-bootstd kevin U-Boot builds which I remember were working with older kernels. And I've heard people not being boot with extlinux.conf on veyrons as well. Might be the same, maybe try an older kernel for jerry? Again, there's a debian-installer arm64 image if you want to test [3], which could work fine on bob (not with depthcharge's size limit though), but kernel support is missing for anything else. Oh, and postmarketOS also supports CrOS verified boot [4] via depthcharge-tools, but they don't have pre-built images and it's a bit of a hassle. [3] Debian Installer netboot image for arm64 Chromebooks https://d-i.debian.org/daily-images/arm64/daily/netboot/depthcharge/ [4] postmarketOS Wiki - Chrome OS devices https://wiki.postmarketos.org/wiki/Chrome_OS_devices Anyway, I'm glad you're working on this, looking forward to testing it myself when I get the chance! > Simon Glass (16): > bootstd: cros: Correct reporting of I/O errors > bootstd: cros: Move partition reading into a function > bootstd: cros: Bring in some ChromiumOS structures > bootstd: cros: Support a kernel on either partition > bootstd: cros: Decode some kernel preamble fields > bootstd: cros: Simplify setup and cmdline expressions > bootstd: Move common zimage functions to bootm.h > bootstd: cros: Add docs for the kernel layout > bootstd: cros: Add private info for ChromiumOS > bootstd: Add private bootmeth data to the bootflow > bootstd: cros: Add a function to read info from partition > bootstd: cros: Add a function to read a kernel > bootstd: cros: Split up reading info and kernel > bootstd: Allow display of the x86 setup information > bootstd: Add a command to read all files for a bootflow > bootstd: cros: Add ARM support > > arch/x86/include/asm/zimage.h | 37 > arch/x86/lib/zimage.c | 8 +- > boot/Kconfig | 4 +- > boot/bootflow.c | 15 ++ > boot/bootm.c | 37 > boot/bootmeth-uclass.c| 10 + > boot/bootmeth_cros.c | 363 -- > boot/bootmeth_cros.h | 197 ++ > cmd/bootflow.c| 47 - > doc/usage/cmd/bootflow.rst| 139 - > include/bootflow.h| 15 +- > include/bootm.h | 47 + > include/bootmeth.h| 23 +++ > 13 files changed, 836 insertions(+), 106 deletions(-) > create mode 100644 boot/bootmeth_cros.h >
[PATCH 2/2] rockchip: rk356x-u-boot: Add bootph-all to i2c0_xfer pinctrl node
A RK8XX PMIC is typically using i2c0 on RK356x devices. Add bootph-all
to required pinctrl nodes to simplify use of the prevent booting on
power plug-in option in SPL.
With the following Kconfig options and nodes in u-boot.dtsi the prevent
booting on power plug-in option can work in SPL.
CONFIG_ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON=y
CONFIG_SPL_I2C=y
CONFIG_SPL_POWER=y
CONFIG_SPL_PINCTRL=y
CONFIG_SPL_PMIC_RK8XX=y
{
bootph-pre-ram;
};
{
bootph-pre-ram;
regulators {
bootph-pre-ram;
};
};
Signed-off-by: Jonas Karlman
---
arch/arm/dts/rk356x-u-boot.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk356x-u-boot.dtsi b/arch/arm/dts/rk356x-u-boot.dtsi
index d21b18205220..fe7de0dd4bc8 100644
--- a/arch/arm/dts/rk356x-u-boot.dtsi
+++ b/arch/arm/dts/rk356x-u-boot.dtsi
@@ -64,6 +64,10 @@
bootph-all;
};
+_pull_none_smt {
+ bootph-all;
+};
+
_pull_none {
bootph-all;
};
@@ -100,6 +104,10 @@
bootph-all;
};
+_xfer {
+ bootph-all;
+};
+
_bus4 {
bootph-all;
};
--
2.41.0
[PATCH 1/2] power: pmic: rk8xx: Fix power-on source check in SPL
The commit 30975fb73d51 ("rockchip: Add option to prevent booting on
power plug-in") introduce an option to prevent booting a device when the
device was powered on due to power plug-in instead of pressing a power
button.
This feature works by checking the power-on source during PMIC probe
and powers off the device if power-on source was power plug-in.
This check currently runs very late at PMIC probe in U-Boot proper.
Fix so that the power-on source check can work at probe time in SPL.
Also enable probe after bind and remove the PMIC banner in SPL.
With this we can use ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON and
SPL_PMIC_RK8XX to power off the device very quickly after TPL instead
of after TF-A and U-Boot proper has been loaded and run.
DDR V1.18 f366f69a7d typ 23/07/17-15:48:58
ln
LP4/4x derate en, other dram:1x trefi
ddrconfig:7
LPDDR4X, 324MHz
BW=32 Col=10 Bk=8 CS0 Row=17 CS1 Row=17 CS=2 Die BW=16 Size=8192MB
change to: 324MHz
clk skew:0x64
change to: 528MHz
clk skew:0x58
change to: 780MHz
clk skew:0x58
change to: 1056MHz(final freq)
clk skew:0x40
out
Power Off due to plug-in event
Fixes: 30975fb73d51 ("rockchip: Add option to prevent booting on power plug-in")
Signed-off-by: Jonas Karlman
---
drivers/power/pmic/rk8xx.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
index 25ef621f8df4..4e3a17337eee 100644
--- a/drivers/power/pmic/rk8xx.c
+++ b/drivers/power/pmic/rk8xx.c
@@ -156,6 +156,10 @@ static int rk8xx_bind(struct udevice *dev)
if (!children)
debug("%s: %s - no child found\n", __func__, dev->name);
+ if (IS_ENABLED(CONFIG_SPL_BUILD) &&
+ IS_ENABLED(CONFIG_ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON))
+ dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
+
/* Always return success for this device */
return 0;
}
@@ -236,14 +240,16 @@ static int rk8xx_probe(struct udevice *dev)
pmic_reg_read(dev, init_data[i].reg));
}
- printf("PMIC: RK%x ", show_variant);
+ if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+ printf("PMIC: RK%x ", show_variant);
+ if (on_source && off_source)
+ printf("(on=0x%02x, off=0x%02x)",
+ pmic_reg_read(dev, on_source),
+ pmic_reg_read(dev, off_source));
+ printf("\n");
+ }
- if (on_source && off_source)
- printf("(on=0x%02x, off=0x%02x)",
- pmic_reg_read(dev, on_source),
- pmic_reg_read(dev, off_source));
- printf("\n");
- if (CONFIG_IS_ENABLED(ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON))
+ if (IS_ENABLED(CONFIG_ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON))
rk8xx_off_for_plugin(dev);
return 0;
--
2.41.0
Re: [PATCH v2 2/2] schemas: Add a schema for binman
On 2023-07-20 22:56 +03:00, Simon Glass wrote:
> With this version I have done with a generic name, in this case 'data',
> as suggested by Alper Nebi Yasak. This may be controversial, but we may
> as well have the dicussion now. I assume that there are no other
> ongoing attempts to define the layout of firmware in devicetree.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Reworked significantly based on Alper's comments
>
> dtschema/schemas/firmware/binman/entry.yaml | 80 +
> dtschema/schemas/firmware/image.yaml| 77
> 2 files changed, 157 insertions(+)
> create mode 100644 dtschema/schemas/firmware/binman/entry.yaml
> create mode 100644 dtschema/schemas/firmware/image.yaml
>
> diff --git a/dtschema/schemas/firmware/binman/entry.yaml
> b/dtschema/schemas/firmware/binman/entry.yaml
> new file mode 100644
> index 000..d50f96d
> --- /dev/null
> +++ b/dtschema/schemas/firmware/binman/entry.yaml
> @@ -0,0 +1,80 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2023 Google LLC
> +
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/image/entry.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Image entry
> +
> +maintainers:
> + - Simon Glass
> +
> +description: |
> + The entry node specifies a single entry in the firmware image.
> +
> + Entries have a specific type, such as "u-boot" or "atf-bl31". This is
> provided
> + using compatible = "data,".
> +
> + Note: This definition is intended to be hierarchical, so that entries can
> + appear in other entries. Schema for that is TBD.
> +
> +properties:
> + $nodename:
> +pattern: "^[-a-z]+(-[0-9]+)?$"
> +
> + compatible:
> +$ref: /schemas/types.yaml#/definitions/string
> +
> + offset:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + Provides the offset of this entry from the start of its parent section.
> +
> + This may be omitted in the description provided by Binman, in which
> case
> + the value is calculated as part of image packing.
> +
> + size:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: |
> + Provides the size of this entry in bytes.
> +
> + This may be omitted in the description provided by Binman, in which
> case
> + the value is calculated as part of image packing.
So AFAIU, binman will take none/one/both of "offset" and "size" as
inputs and will pass them to the output unmodified, instead adding a
"reg" pair of their calculated final values?
Is there a schema-computational way to ensure that "reg" has to contain
the same values as "offset" and "size"? Or is that not a restriction at
all and "reg" overrides the others?
> +
> + reg:
> +description: |
> + Defines the offset and size of this entry, with reference to its parent
> + image / section.
> +
> + Note This is typically omitted in the description provided to Binman,
> + since the value is calculated as part of image packing. Separate
> + properties are provided for the size and offset of an entry, so that
> it is
> + easy to specify none, one or both. The `reg` property is the only one
> that
> + needs to be looked at once the image has been built.
> +
Do we not need a $ref for "reg"? Is there anything applicable?
BTW, I'm not that familiar with device-tree interpretation, I
occasionally saw 'reg' being used as an pair, and was
mostly just asking if it's appropriate.
(Also TIL "ranges", and I'm imagining ranges = <0 $size 4G-$size 4G>; as
an end-at-4gb replacement/generalization :P, but I know, later, later.)
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +firmware {
> + image {
> +compatible = "data,image";
> +#address-cells = <1>;
> +$size-cells = <1>;
> +
> +u-boot@0 {
> + compatible = "data,u-boot";
> + reg = <0 0xa>;
> +};
> +
> +atf-bl31@0x10 {
> + compatible = "data,atf-bl31";
> + reg = <0x10 0x2>;
> +};
> + };
> +};
> diff --git a/dtschema/schemas/firmware/image.yaml
> b/dtschema/schemas/firmware/image.yaml
> new file mode 100644
> index 000..949b067
> --- /dev/null
> +++ b/dtschema/schemas/firmware/image.yaml
> @@ -0,0 +1,77 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +# Copyright 2023 Google LLC
> +
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/firmware/image.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Binman firmware layout
> +
> +maintainers:
> + - Simon Glass
> +
> +description: |
> + The image node provides a layout for firmware, used when packaging firmware
> + from multiple projects. For now it just supports a very simple set of
> + features, as a starting point for discussion.
> +
> + The Binman tool processes this node to produce a final
[PATCH] rockchip: rk356x: Enable poweroff command
With PMIC_RK8XX, SYSRESET and CMD_POWEROFF options enabled it is possible to power down a board using the poweroff command and turn the board back on using a power button. Enable the poweroff command on RK356x boards that have a button wired to PMIC pwron. Also update to use PMIC poweroff when PMIC_RK8XX is enabled to avoid also having to enable the SYSRESET_CMD_POWEROFF option. Signed-off-by: Jonas Karlman --- configs/quartz64-a-rk3566_defconfig | 1 + configs/quartz64-b-rk3566_defconfig | 1 + configs/rock-3a-rk3568_defconfig | 1 + configs/soquartz-model-a-rk3566_defconfig | 1 + drivers/power/pmic/Kconfig| 1 + 5 files changed, 5 insertions(+) diff --git a/configs/quartz64-a-rk3566_defconfig b/configs/quartz64-a-rk3566_defconfig index d55b224feacd..6853cd6c44b4 100644 --- a/configs/quartz64-a-rk3566_defconfig +++ b/configs/quartz64-a-rk3566_defconfig @@ -52,6 +52,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/configs/quartz64-b-rk3566_defconfig b/configs/quartz64-b-rk3566_defconfig index b98c81f9dcef..aa29fff14643 100644 --- a/configs/quartz64-b-rk3566_defconfig +++ b/configs/quartz64-b-rk3566_defconfig @@ -50,6 +50,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/configs/rock-3a-rk3568_defconfig b/configs/rock-3a-rk3568_defconfig index 44ff054df665..409aa95acf06 100644 --- a/configs/rock-3a-rk3568_defconfig +++ b/configs/rock-3a-rk3568_defconfig @@ -49,6 +49,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/configs/soquartz-model-a-rk3566_defconfig b/configs/soquartz-model-a-rk3566_defconfig index c3958579db73..a0884a797d58 100644 --- a/configs/soquartz-model-a-rk3566_defconfig +++ b/configs/soquartz-model-a-rk3566_defconfig @@ -43,6 +43,7 @@ CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_PMIC=y diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig index 176fb07c651a..4a6f0ce093ad 100644 --- a/drivers/power/pmic/Kconfig +++ b/drivers/power/pmic/Kconfig @@ -233,6 +233,7 @@ config PMIC_QCOM config PMIC_RK8XX bool "Enable support for Rockchip PMIC RK8XX" + select SYSRESET_CMD_POWEROFF if SYSRESET && CMD_POWEROFF ---help--- The Rockchip RK808 PMIC provides four buck DC-DC convertors, 8 LDOs, an RTC and two low Rds (resistance (drain to source)) switches. It is -- 2.41.0
Re: [PATCH 2/2] configs: Make TI_SECURE_DEVICE default for K3
On Thu, Aug 03, 2023 at 09:54:41AM -0500, Andrew Davis wrote: > All K3 boards now are secure by default, instead of setting this in each > defconfig, make it implied by the ARCH config. > > The only exception is IOT2050, which I do not believe will have any > problems with being a TI_SECURE_DEVICE, but for now turn it off to keep > its config the same. > > Signed-off-by: Andrew Davis On my J721E GP EVM: Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] configs: am65x: Merge the HS and non-HS defconfigs
On Thu, Aug 03, 2023 at 09:54:40AM -0500, Andrew Davis wrote: > K3 devices have runtime type board detection. Make the default defconfig > include the secure configuration. Then remove the HS specific config. > > Non-HS devices will continue to boot due to runtime device type detection. > > Signed-off-by: Andrew Davis On my AM65x GP EVM: Tested-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: Pull request efi-2023-10-rc2-2
On Thu, Aug 03, 2023 at 05:55:54PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit 38dedebc547f795efc3daad17f7c013c515e1285: > > Merge https://source.denx.de/u-boot/custodians/u-boot-riscv > (2023-08-02 12:13:16 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-10-rc2-2 > > for you to fetch changes up to cd87d2c61ce8e8e963de514f2c8ab0f959d6b586: > > efi_loader: check uuid_str_to_bin return value (2023-08-03 09:21:03 > +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17191 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] schemas: Add a schema for binman
(I think I've strayed far away from schema/dtb side of things towards
binman-the-program side, so I'm dropping Rob and devicetree@ from Cc).
On 2023-07-20 22:55 +03:00, Simon Glass wrote:
> On Thu, 20 Jul 2023 at 09:23, Alper Nebi Yasak
> wrote:
>> There's also the issue of binman having multiple different device-trees:
>> its input, the ones in fdtmaps per image, the ones injected to U-Boot
>> dtb files per image. I'd say each has different needs, and those
>> differences have to be figured out before specified upstream. I can only
>> guess this is about the one that'll be in a u-boot.dtb.
>
> Well, there is really only one. The fdtmap is actually the same
> schema, except that it mentions only the image that it is embedded in,
> i.e. if the fdtmap is for the SPI image, then the fdtmap in SPI flash
> only contains the definition for the SPI image, not the MMC image
> which is in a different device. The input is the same schema, albeit
> that things like 'offset' may be filled in by Binman automatically
> when it packs things.
I was thinking of things like generator nodes and templates and
"filename"s in blob entries that (IMO) only make sense as binman inputs
and never should be in a fdtmap. Trying to highlight a difference
between "how to build this image" and "what this image contains".
But I guess it's OK to call them the same schema unless something has
two conflicting meanings in input-domain and output-domain, and I can't
think of any counter-examples now.
>> I want to go through binman more thoroughly, but a lot of changes
>> happened since I last looked at it and I'm a bit slow at writing things,
>> so won't exactly be soon. That being said, here's some ideas off the top
>> of my head, for inspiration on both this schema and binman itself.
>
> Do you mean the code? There are definitely some abstractions that are
> stretching a bit, but it is mostly holding together for now.
I mean both the implementation and the design. There's a lot more on my
mind, some more examples:
- Precise structures for data instead of thinking of them as black boxes
- Heuristically parsing arbitrary images/data for e.g. binman extract
- Deconstructing input files to reuse their pieces for building images
- Explicit dependency tracking and resolution for data and layout
- Making things act more like native Python objects
- In fact, making it entirely operable with just Python code
- Decoupling internals from the control dtbs ("entry._node" etc.)
- Ensuring reproducible builds and testing for it
- Fuzzing as a replacement for most tests
- ...
I think it has the beginnings of a very nice declarative-style tool, but
has to embrace that style to get there. (And I guess I'll have to do the
work to properly express myself on some points...)
> [...]
>> Or maybe even better, I think we should make it like FIT: allow a "data"
>> property that has it inside the dtb, or a pair of "data-offset/position"
>> and "data-size" properties if it's outside.
>
> Eh? The point of the entry is to declare the position of actual data.
> If the data is elsewhere, then the entry will be too.
Sorry, I'm jumping into a different contexts here without explaining it.
I'm seeing a similarity between images that start with a fdtmap and the
images built by "mkimage -T fit -E". Then I'm extrapolating to the
non-"-E" case. Then extending to make it possible for a "fdtmap + data"
binman description to result in something almost backwards-compatible
with FIT, which could replace most uses of a fit etype.
(Of course, backwards compatible only if you add config nodes, and
flatten or don't nest entries, and whatnot. And fit etype would still stay.)
>> Inlining data inside the dtb
>> could help us do nice things in binman, like hashes/signatures as entry
>> types instead of special-casing them.
>
> We already do that though, right? See testHash() for example. This is
> a powerful feature of a firmware-layout description / Binman, IMO,
> since all the metadata you need is right there.
Having that functionality in state.py and having to work around it for
mkimage/fit etypes (because we want to embed them into the data instead
of the binman dtb) is what I mean by special-casing.
If we had them as etypes, and could embed arbitrary entries as "data" in
binman dtb, I think we would have the best of both worlds -- avoid
calling mkimage just for hash/signature embedding, have it still
possible to put those in binman metadata, and enable a foundation for
other sign-verify flows (leaning towards replacing custom signing
tools/scripts with binman).
>> In fact it could be possible to turn binman images into a FIT 2.0 if we
>> do some more work on top of that, instead of nesting a FIT inside a
>> binman image.
>
> Well binman needs to produce things which are not FITs. Bear in mind
> that the output can be a binary file in any format. It doesn't
> necessarily have to have any metadata in it at all, certainly not a
> FIT header.
I know, I don't mean it
[PATCH] buildman: Allow more results while building
The -v option enables display of build results while building, instead of
needing to do a separate summary step later (or in another terminal). But
this resets the build results after each commit, so that all errors are
reported fresh, without trying to diff them against previous errors
already shown.
Drop this reset, as an experiment, so see if this is useful.
Signed-off-by: Simon Glass
---
tools/buildman/builder.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index ecbd368c47a..5ee2b5959b2 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -536,7 +536,6 @@ class Builder:
if self._verbose:
terminal.print_clear()
boards_selected = {target : result.brd}
-self.reset_result_summary(boards_selected)
self.produce_result_summary(result.commit_upto, self.commits,
boards_selected)
else:
--
2.41.0.640.ga95def55d0-goog
[PATCH 2/2] buildman: Drop warning about orphaned defconfigs
Some boards use a MAINTAINERS entry to specify common files without
referencing any defconfigs. This is allowed and should not result in a
warning.
Drop the warning in this case.
Signed-off-by: Simon Glass
---
tools/buildman/boards.py| 7 ---
tools/buildman/func_test.py | 9 ++---
2 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py
index 83adbf167c7..eef3f19f7ad 100644
--- a/tools/buildman/boards.py
+++ b/tools/buildman/boards.py
@@ -377,16 +377,9 @@ class MaintainersDatabase:
Args:
linenum (int): Current line number
"""
-added = False
if targets:
for target in targets:
self.database[target] = (status, maintainers)
-added = True
-if not added and (status != '-' and maintainers):
-leaf = fname[len(srcdir) + 1:]
-if leaf != 'MAINTAINERS':
-self.warnings.append(
-f'WARNING: orphaned defconfig in {leaf} ending at line
{linenum + 1}')
targets = []
maintainers = []
diff --git a/tools/buildman/func_test.py b/tools/buildman/func_test.py
index 3115700f07b..55dd494fe8e 100644
--- a/tools/buildman/func_test.py
+++ b/tools/buildman/func_test.py
@@ -926,10 +926,7 @@ Active aarch64 armv8 - armltd total_compute board2
tools.write_file(main, data, binary=False)
params_list, warnings = self._boards.build_board_list(config_dir, src)
self.assertEquals(2, len(params_list))
-self.assertEquals(
-["WARNING: no maintainers for 'board0'",
- 'WARNING: orphaned defconfig in boards/board0/MAINTAINERS ending
at line 4',
- ], warnings)
+self.assertEquals(["WARNING: no maintainers for 'board0'"], warnings)
# Mark a board as orphaned - this should give a warning
lines = ['S: Orphaned' if line.startswith('S') else line
@@ -969,9 +966,7 @@ Active aarch64 armv8 - armltd total_compute board2
tools.write_file(main, both_data + extra, binary=False)
params_list, warnings = self._boards.build_board_list(config_dir, src)
self.assertEquals(2, len(params_list))
-self.assertEquals(
-['WARNING: orphaned defconfig in boards/board0/MAINTAINERS ending
at line 16'],
- warnings)
+self.assertFalse(warnings)
# Add another TARGET to the Kconfig
tools.write_file(main, both_data, binary=False)
--
2.41.0.640.ga95def55d0-goog
[PATCH 1/2] buildman: Exit after reading toolchain
Recent refactoring changed buildman to continue operation after fetching
a toolchain. Fix this.
Fixes: b8680646521 ("bulidman: Move toolchain handling to a function")
Signed-off-by: Simon Glass
---
tools/buildman/control.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/buildman/control.py b/tools/buildman/control.py
index 5c5720034b6..f2ffb7f5b4a 100644
--- a/tools/buildman/control.py
+++ b/tools/buildman/control.py
@@ -610,6 +610,9 @@ def do_buildman(args, toolchains=None, make_func=None,
brds=None,
toolchains = get_toolchains(toolchains, col, args.override_toolchain,
args.fetch_arch, args.list_tool_chains,
args.verbose)
+if isinstance(toolchains, int):
+return toolchains
+
output_dir = setup_output_dir(
args.output_dir, args.work_in_output, args.branch,
args.no_subdirs, col, clean_dir)
--
2.41.0.640.ga95def55d0-goog
[PATCH] arm: mediatek: add usb support for MT7988
From: Frank Wunderlich
MT7988 has a t-phy and an x-phy controller. There is already a driver for
t-phy so we can add USB support for this phy type.
Signed-off-by: Frank Wunderlich
---
arch/arm/dts/mt7988.dtsi | 60
1 file changed, 60 insertions(+)
diff --git a/arch/arm/dts/mt7988.dtsi b/arch/arm/dts/mt7988.dtsi
index ddd629e8c99d..ac476d5cdd7f 100644
--- a/arch/arm/dts/mt7988.dtsi
+++ b/arch/arm/dts/mt7988.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "mediatek,mt7988-rfb";
@@ -161,6 +162,65 @@
#clock-cells = <1>;
};
+ dummy_clk: dummy12m {
+ compatible = "fixed-clock";
+ clock-frequency = <1200>;
+ #clock-cells = <0>;
+ /* must need this line, or uart uanable to get dummy_clk */
+ bootph-all;
+ };
+
+ xhci1: xhci@1120 {
+ compatible = "mediatek,mt7988-xhci",
+"mediatek,mtk-xhci";
+ reg = <0 0x1120 0 0x2e00>,
+ <0 0x11203e00 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ phys = < PHY_TYPE_USB2>,
+ < PHY_TYPE_USB3>;
+ clocks = <_clk>,
+<_clk>,
+<_clk>,
+<_clk>,
+<_clk>;
+ clock-names = "sys_ck",
+ "xhci_ck",
+ "ref_ck",
+ "mcu_ck",
+ "dma_ck";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ status = "okay";
+ };
+
+ usbtphy: usb-phy@11c5 {
+ compatible = "mediatek,mt7988",
+"mediatek,generic-tphy-v2";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "okay";
+
+ tphyu2port0: usb-phy@11c5 {
+ reg = <0 0x11c5 0 0x700>;
+ clocks = <_clk>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ tphyu3port0: usb-phy@11c50700 {
+ reg = <0 0x11c50700 0 0x900>;
+ clocks = <_clk>;
+ clock-names = "ref";
+ #phy-cells = <1>;
+ mediatek,usb3-pll-ssc-delta;
+ mediatek,usb3-pll-ssc-delta1;
+ status = "okay";
+ };
+ };
+
xfi_pextp0: syscon@11f2 {
compatible = "mediatek,mt7988-xfi_pextp_0", "syscon";
reg = <0 0x11f2 0 0x1>;
--
2.34.1
[PATCH] pinctrl: rockchip: Fix drive and input schmitt on RK3568
rk3568_set_drive configures a second reg for specific pins. Mainline
linux does not do this and vendor U-Boot only run similar code when bit
14 and 15 are both 0 in PMU_GRF_SOC_CON0. Something that presumably only
early revisions of the SoC have, all my RK3566/RK3568 boards read back
bit 15 as 1, even on boards dated back to 21H1.
This cause e.g. ethernet PHY on Radxa CM3-IO board not to work after
drive is configured according to the device tree.
Input schmitt is configured in 2-bit fields on RK3568 compared to earlier
generation and 2'b10 should be used to enable input schmitt.
Remove the code that presumably was intended for early pre-production
revisions of the SoC and write correct values for input schmitt setting.
Also change to use regmap_update_bits to closer match linux driver.
Fixes: 1977d746aa54 ("rockchip: rk3568: add rk3568 pinctrl driver")
Signed-off-by: Jonas Karlman
---
drivers/pinctrl/rockchip/pinctrl-rk3568.c | 52 ++-
1 file changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3568.c
b/drivers/pinctrl/rockchip/pinctrl-rk3568.c
index 314edb5a6064..9a19dbe81cdc 100644
--- a/drivers/pinctrl/rockchip/pinctrl-rk3568.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rk3568.c
@@ -113,11 +113,9 @@ static int rk3568_set_mux(struct rockchip_pin_bank *bank,
int pin, int mux)
struct rockchip_pinctrl_priv *priv = bank->priv;
int iomux_num = (pin / 8);
struct regmap *regmap;
- int reg, ret, mask;
+ int reg, mask;
u8 bit;
- u32 data;
-
- debug("setting mux of GPIO%d-%d to %d\n", bank->bank_num, pin, mux);
+ u32 data, rmask;
if (bank->iomux[iomux_num].type & IOMUX_SOURCE_PMU)
regmap = priv->regmap_pmu;
@@ -131,10 +129,10 @@ static int rk3568_set_mux(struct rockchip_pin_bank *bank,
int pin, int mux)
mask = 0xf;
data = (mask << (bit + 16));
+ rmask = data | (data >> 16);
data |= (mux & mask) << bit;
- ret = regmap_write(regmap, reg, data);
- return ret;
+ return regmap_update_bits(regmap, reg, rmask, data);
}
#define RK3568_PULL_PMU_OFFSET 0x20
@@ -225,7 +223,7 @@ static int rk3568_set_pull(struct rockchip_pin_bank *bank,
struct regmap *regmap;
int reg, ret;
u8 bit, type;
- u32 data;
+ u32 data, rmask;
if (pull == PIN_CONFIG_BIAS_PULL_PIN_DEFAULT)
return -ENOTSUPP;
@@ -249,11 +247,10 @@ static int rk3568_set_pull(struct rockchip_pin_bank *bank,
/* enable the write to the equivalent lower bits */
data = ((1 << ROCKCHIP_PULL_BITS_PER_PIN) - 1) << (bit + 16);
-
+ rmask = data | (data >> 16);
data |= (ret << bit);
- ret = regmap_write(regmap, reg, data);
- return ret;
+ return regmap_update_bits(regmap, reg, rmask, data);
}
static int rk3568_set_drive(struct rockchip_pin_bank *bank,
@@ -261,40 +258,18 @@ static int rk3568_set_drive(struct rockchip_pin_bank
*bank,
{
struct regmap *regmap;
int reg;
- u32 data;
+ u32 data, rmask;
u8 bit;
int drv = (1 << (strength + 1)) - 1;
- int ret = 0;
rk3568_calc_drv_reg_and_bit(bank, pin_num, , , );
/* enable the write to the equivalent lower bits */
data = ((1 << RK3568_DRV_BITS_PER_PIN) - 1) << (bit + 16);
+ rmask = data | (data >> 16);
data |= (drv << bit);
- ret = regmap_write(regmap, reg, data);
- if (ret)
- return ret;
-
- if (bank->bank_num == 1 && pin_num == 21)
- reg = 0x0840;
- else if (bank->bank_num == 2 && pin_num == 2)
- reg = 0x0844;
- else if (bank->bank_num == 2 && pin_num == 8)
- reg = 0x0848;
- else if (bank->bank_num == 3 && pin_num == 0)
- reg = 0x084c;
- else if (bank->bank_num == 3 && pin_num == 6)
- reg = 0x0850;
- else if (bank->bank_num == 4 && pin_num == 0)
- reg = 0x0854;
- else
- return 0;
-
- data = ((1 << RK3568_DRV_BITS_PER_PIN) - 1) << 16;
- data |= drv;
-
- return regmap_write(regmap, reg, data);
+ return regmap_update_bits(regmap, reg, rmask, data);
}
static int rk3568_set_schmitt(struct rockchip_pin_bank *bank,
@@ -302,16 +277,17 @@ static int rk3568_set_schmitt(struct rockchip_pin_bank
*bank,
{
struct regmap *regmap;
int reg;
- u32 data;
+ u32 data, rmask;
u8 bit;
rk3568_calc_schmitt_reg_and_bit(bank, pin_num, , , );
/* enable the write to the equivalent lower bits */
data = ((1 << RK3568_SCHMITT_BITS_PER_PIN) - 1) << (bit + 16);
- data |= (enable << bit);
+ rmask = data | (data >> 16);
+ data |= ((enable ? 0x2 : 0x1) << bit);
- return regmap_write(regmap, reg, data);
+ return regmap_update_bits(regmap, reg, rmask, data);
}
Re: [PATCH v18 9/9] arm_ffa: efi: corstone1000: enable MM communication
On Thu, Aug 03, 2023 at 05:03:50PM +0100, Abdellatif El Khlifi wrote: > turn on EFI MM communication > > On Corstone-1000 platform MM communication between u-boot > and the secure world (Optee) is done using the FF-A bus. > > Changes made are generated using savedefconfig. > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > > --- > > Changelog: > === > > v18: > > Ilias, Tom: > > * drop use of CONFIG_FFA_SHARED_MM_BUF_* Why? What was wrong before was what I commented on still being wrong in 8/9, this part was fine. -- Tom signature.asc Description: PGP signature
Re: [PATCH v18 8/9] arm_ffa: efi: introduce FF-A MM communication
On Thu, Aug 03, 2023 at 05:03:49PM +0100, Abdellatif El Khlifi wrote: [snip] > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > index c5835e6ef6..19e51bf503 100644 > --- a/lib/efi_loader/Kconfig > +++ b/lib/efi_loader/Kconfig [snip] > +config FFA_SHARED_MM_BUF_SIZE > + int "Memory size of the shared MM communication buffer" > + default 0 Remove the default. > + depends on EFI_MM_COMM_TEE This should be EFI_MM_COMM_TEE && ARM_FFA_TRANSPORT [snip] > +config FFA_SHARED_MM_BUF_OFFSET > + int "Data offset in the shared MM communication buffer" > + default 0 > + depends on EFI_MM_COMM_TEE Same. [snip] > +config FFA_SHARED_MM_BUF_ADDR > + hex "Define the address of the shared MM communication buffer" > + default 0x0 > + depends on EFI_MM_COMM_TEE Same. -- Tom signature.asc Description: PGP signature
[PATCH] arm: dts: mediatek: convert gmac link mode to 2500base-x for r3
From: Frank Wunderlich
Ethernet on Bananapi-r3 is broken after
commit bd70f3cea353 ("net: mediatek: add support for SGMII 1Gbps
auto-negotiation mode")
because changes from this commit were not applied to bpi-r3 devicetree too:
commit aef54ea16cac ("arm: dts: medaitek: convert gmac link mode to 2500base-x")
Signed-off-by: Frank Wunderlich
---
arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
index 15256302b86b..c156a8136343 100644
--- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
+++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
@@ -76,12 +76,12 @@
{
status = "okay";
mediatek,gmac-id = <0>;
- phy-mode = "sgmii";
+ phy-mode = "2500base-x";
mediatek,switch = "mt7531";
reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
fixed-link {
- speed = <1000>;
+ speed = <2500>;
full-duplex;
};
};
--
2.34.1
Re: [PATCH 1/2] Revert "lib: string: Fix strlcpy return value", fix callers
On 7/14/23 07:24, Matthias Schiffer wrote:
> Both the Linux kernel and libbsd agree that strlcpy() should always
> return strlen(src) and not include the NUL termination. The incorrect
> U-Boot implementation makes it impossible to check the return value for
> truncation, and breaks code written with the usual implementation in
> mind (for example, fdtdec_add_reserved_memory() was subtly broken).
>
> I reviewed all callers of strlcpy() and strlcat() and fixed them
> according to my understanding of the intended function.
>
> This reverts commit d3358ecc54be0bc3b4dd11f7a63eab0a2842f772 and adds
> related fixes.
>
> Fixes: d3358ecc54be ("lib: string: Fix strlcpy return value")
> Signed-off-by: Matthias Schiffer
> ---
> board/amlogic/vim3/vim3.c| 6 +++---
> drivers/fastboot/fb_getvar.c | 2 +-
> lib/string.c | 14 +++---
> test/lib/strlcat.c | 4 ++--
> 4 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/board/amlogic/vim3/vim3.c b/board/amlogic/vim3/vim3.c
> index fcd60ab1e05..8bdfb302f72 100644
> --- a/board/amlogic/vim3/vim3.c
> +++ b/board/amlogic/vim3/vim3.c
> @@ -104,8 +104,8 @@ int meson_ft_board_setup(void *blob, struct bd_info *bd)
> }
>
> /* Update PHY names (mandatory to disable USB3.0) */
> - len = strlcpy(data, "usb2-phy0", 32);
> - len += strlcpy([len], "usb2-phy1", 32 - len);
> + len = strlcpy(data, "usb2-phy0", 32) + 1;
> + len += strlcpy([len], "usb2-phy1", 32 - len) + 1;
> ret = fdt_setprop(blob, node, "phy-names", data, len);
> if (ret < 0) {
> printf("vim3: failed to update usb phy names property
> (%d)\n", ret);
> @@ -132,7 +132,7 @@ int meson_ft_board_setup(void *blob, struct bd_info *bd)
> }
>
> /* Enable PCIe */
> - len = strlcpy(data, "okay", 32);
> + len = strlcpy(data, "okay", 32) + 1;
> ret = fdt_setprop(blob, node, "status", data, len);
> if (ret < 0) {
> printf("vim3: failed to enable pcie node (%d)\n", ret);
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index dd3475e0a8b..d9f0f07b2bc 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -183,7 +183,7 @@ static void __maybe_unused getvar_has_slot(char
> *part_name, char *response)
>
> /* part_name_wslot = part_name + "_a" */
> len = strlcpy(part_name_wslot, part_name, PART_NAME_LEN - 3);
> - if (len > PART_NAME_LEN - 3)
> + if (len >= PART_NAME_LEN - 3)
> goto fail;
> strcat(part_name_wslot, "_a");
>
> diff --git a/lib/string.c b/lib/string.c
> index ecea755f405..f2c61471288 100644
> --- a/lib/string.c
> +++ b/lib/string.c
> @@ -116,20 +116,18 @@ char * strncpy(char * dest,const char *src,size_t count)
> * of course, the buffer size is zero). It does not pad
> * out the result like strncpy() does.
> *
> - * Return: the number of bytes copied
> + * Return: strlen(src)
> */
> size_t strlcpy(char *dest, const char *src, size_t size)
> {
> - if (size) {
> - size_t srclen = strlen(src);
> - size_t len = (srclen >= size) ? size - 1 : srclen;
> + size_t ret = strlen(src);
>
> + if (size) {
> + size_t len = (ret >= size) ? size - 1 : ret;
> memcpy(dest, src, len);
> dest[len] = '\0';
> - return len + 1;
> }
> -
> - return 0;
> + return ret;
> }
> #endif
>
> @@ -191,6 +189,8 @@ char * strncat(char *dest, const char *src, size_t count)
> * Compatible with *BSD: the result is always a valid NUL-terminated string
> that
> * fits in the buffer (unless, of course, the buffer size is zero). It does
> not
> * write past @size like strncat() does.
> + *
> + * Return: min(strlen(dest), size) + strlen(src)
> */
> size_t strlcat(char *dest, const char *src, size_t size)
> {
> diff --git a/test/lib/strlcat.c b/test/lib/strlcat.c
> index a0ec037388b..d8453fe78e2 100644
> --- a/test/lib/strlcat.c
> +++ b/test/lib/strlcat.c
> @@ -43,11 +43,11 @@ static int do_test_strlcat(struct unit_test_state *uts,
> int line, size_t align1,
> s2[i] = 32 + 23 * i % (127 - 32);
> s2[len2 - 1] = '\0';
>
> - expected = len2 < n ? min(len1 + len2 - 1, n) : n;
> + expected = min(strlen(s2), n) + strlen(s1);
> actual = strlcat(s2, s1, n);
> if (expected != actual) {
> ut_failf(uts, __FILE__, line, __func__,
> - "strlcat(s2, s1, 2) == len2 < n ? min(len1 + len2, n)
> : n",
> + "strlcat(s2, s1, n) == min(len2, n) + len1",
>"Expected %#zx (%zd), got %#zx (%zd)",
>expected, expected, actual, actual);
> return CMD_RET_FAILURE;
I remembered that something was off with this patch, but I never
Re: [PATCH v5 10/11] spl: Convert spi to spl_load
On 8/3/23 04:45, Xavier Drudis Ferran wrote:
> El Mon, Jul 31, 2023 at 06:43:02PM -0400, Sean Anderson deia:
>> This converts the spi load method to use spl_load. As a consequence, it
>> also adds support for LOAD_FIT_FULL.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v5:
>> - Rework to load header in spl_load
>>
>> common/spl/spl_spi.c | 72 +---
>> 1 file changed, 8 insertions(+), 64 deletions(-)
>>
>> diff --git a/common/spl/spl_spi.c b/common/spl/spl_spi.c
>> index 2aff025f76..14391a1c96 100644
>> --- a/common/spl/spl_spi.c
>> +++ b/common/spl/spl_spi.c
>> @@ -89,12 +89,14 @@ u32 __weak spl_spi_boot_cs(void)
>> static int spl_spi_load_image(struct spl_image_info *spl_image,
>>struct spl_boot_device *bootdev)
>> {
>> -int err = 0;
>> unsigned int payload_offs;
>> struct spi_flash *flash;
>> -struct legacy_img_hdr *header;
>> unsigned int sf_bus = spl_spi_boot_bus();
>> unsigned int sf_cs = spl_spi_boot_cs();
>> +struct spl_load_info load = {
>> +.bl_len = 1,
>> +.read = spl_spi_fit_read,
>> +};
>>
>> /*
>> * Load U-Boot image from SPI flash into RAM
>> @@ -109,77 +111,19 @@ static int spl_spi_load_image(struct spl_image_info
>> *spl_image,
>> return -ENODEV;
>> }
>>
>> +load.dev = flash;
>> payload_offs = spl_spi_get_uboot_offs(flash);
>>
>> -header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
>> -
>> if (CONFIG_IS_ENABLED(OF_REAL)) {
>> payload_offs = ofnode_conf_read_int("u-boot,spl-payload-offset",
>> payload_offs);
>> }
>>
>> #if CONFIG_IS_ENABLED(OS_BOOT)
>> -if (spl_start_uboot() || spi_load_image_os(spl_image, bootdev, flash,
>> header))
>> +if (!spl_start_uboot() && !spi_load_image_os(spl_image, bootdev, flash,
>> header))
>> +return 0;
>> #endif
>
> But with this return 0 we're skipping the soft reset at the end, aren't we ?
> This is the same the old code did. Just not sure whether it was right or
> untested.
> If some flash needs reset before running linux, then it might need it with
> U-Boot or in Falcon,
> as long as SPL has probed the flash, mightn't it ?
> If it needs fixing, then possibly better in a different commit, though ?
> I mean yours is fine, you left things as they were.
I am trying to change things only where they are necessary to combine
load methods. So while this might be a good change to make, I don't want
to do it in this series. I also don't have any SPI flash boards that I
care about so...
>> -{
>> -/* Load u-boot, mkimage header is 64 bytes. */
>> -err = spi_flash_read(flash, payload_offs, sizeof(*header),
>> - (void *)header);
>> -if (err) {
>> -debug("%s: Failed to read from SPI flash (err=%d)\n",
>> - __func__, err);
>> -return err;
>> -}
>> -
>> -if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL) &&
>> -image_get_magic(header) == FDT_MAGIC) {
>> -err = spi_flash_read(flash, payload_offs,
>> - roundup(fdt_totalsize(header), 4),
>> - (void *)CONFIG_SYS_LOAD_ADDR);
>> -if (err)
>> -return err;
>> -err = spl_parse_image_header(spl_image, bootdev,
>> -(struct legacy_img_hdr
>> *)CONFIG_SYS_LOAD_ADDR);
>
>
> So this used to load to CONFIG_SYS_LOAD_ADDR and will now load to
> CONFIG_TEXT_BASE, or whatever the applicable spl_get_load_buffer()
> uses. Is this OK ? or do we need a new parameter for the buffer or
> something ?
(commented on on the FAT patch)
>> -} else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
>> - image_get_magic(header) == FDT_MAGIC) {
>> -struct spl_load_info load;
>> -
>> -debug("Found FIT\n");
>> -load.dev = flash;
>> -load.priv = NULL;
>> -load.filename = NULL;
>> -load.bl_len = 1;
>> -load.read = spl_spi_fit_read;
>> -err = spl_load_simple_fit(spl_image, ,
>> - payload_offs,
>> - header);
>> -} else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
>> -struct spl_load_info load;
>> -
>> -load.dev = flash;
>> -load.priv = NULL;
>> -load.filename = NULL;
>> -load.bl_len = 1;
>> -
Re: [PATCH v5 04/11] spl: Convert fat to spl_load
On 8/3/23 04:30, Xavier Drudis Ferran wrote:
> El Mon, Jul 31, 2023 at 06:42:56PM -0400, Sean Anderson deia:
>> This converts the fat loader to use spl_load. Some platforms are very
>> tight on space, so we take care to only include the code we really need.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v5:
>> - Rework to load header in spl_load
>>
>> Changes in v3:
>> - Fix failing on success
>>
>> common/spl/spl_fat.c | 55 +++-
>> 1 file changed, 19 insertions(+), 36 deletions(-)
>>
>> diff --git a/common/spl/spl_fat.c b/common/spl/spl_fat.c
>> index f8a5b80a3b..6530bcd5a7 100644
>> --- a/common/spl/spl_fat.c
>> +++ b/common/spl/spl_fat.c
>> @@ -60,57 +60,40 @@ int spl_load_image_fat(struct spl_image_info *spl_image,
>> const char *filename)
>> {
>> int err;
>> -struct legacy_img_hdr *header;
>> +loff_t size;
>> +struct spl_load_info load;
>> +
>> +/* This generates smaller code than using a compound literal */
>> +load.read = spl_fit_read;
>> +load.bl_len = 1;
>> +load.filename = filename;
>>
>> err = spl_register_fat_device(block_dev, partition);
>> if (err)
>> goto end;
>>
>> -header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
>> -
>> -err = file_fat_read(filename, header, sizeof(struct legacy_img_hdr));
>> -if (err <= 0)
>> -goto end;
>> -
>> -if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL) &&
>> -image_get_magic(header) == FDT_MAGIC) {
>> -err = file_fat_read(filename, (void *)CONFIG_SYS_LOAD_ADDR, 0);
>> -if (err <= 0)
>> -goto end;
>> -err = spl_parse_image_header(spl_image, bootdev,
>> -(struct legacy_img_hdr *)CONFIG_SYS_LOAD_ADDR);
>
> So this used to load to CONFIG_SYS_LOAD_ADDR and will now load to
> CONFIG_TEXT_BASE, or whatever the applicable spl_get_load_buffer()
> uses. Is this OK ? or do we need a new parameter for the buffer or
> something ?
It's worked OK in my testing. Typically, CONFIG_SYS_LOAD_ADDR is just
CONFIG_TEXT_BASE plus some offset. If there's a discontinuity such as:
TEXT_BASE - 0x0
RAM_TOP - 0x07fff
LOAD_ADDR - 0x8
RAM2_TOP - 0xf
then this only matters if we load something larger than 2G. Obviously
not every RAM layout looks like this, but Most of the Time (TM) the
memory set aside for U-Boot to run in can hold the FIT that holds
U-Boot. If this ends up being a problem, we can add a config to load
things in a malloc'd buffer. This change could be moved to a prep commit
to aid bisecting.
--Sean
>> -if (err == -EAGAIN)
>> -return err;
>> -if (err == 0)
>> -err = 1;
>> -} else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
>> -image_get_magic(header) == FDT_MAGIC) {
>> -struct spl_load_info load;
>> -
>> -debug("Found FIT\n");
>> -load.read = spl_fit_read;
>> -load.bl_len = 1;
>> -load.filename = (void *)filename;
>> -load.priv = NULL;
>> -
>> -return spl_load_simple_fit(spl_image, , 0, header);
>> -} else {
>> -err = spl_parse_image_header(spl_image, bootdev, header);
>> +/*
>> + * Avoid pulling in this function for other image types since we are
>> + * very short on space on some boards.
>> + */
>> +if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL)) {
>> +err = fat_size(filename, );
>> if (err)
>> goto end;
>> -
>> -err = file_fat_read(filename,
>> -(u8 *)(uintptr_t)spl_image->load_addr, 0);
>> +} else {
>> +size = 0;
>> }
>>
>> +err = spl_load(spl_image, bootdev, , 0, size);
>> +
>> end:
>> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> -if (err <= 0)
>> +if (err < 0)
>> printf("%s: error reading image %s, err - %d\n",
>> __func__, filename, err);
>> #endif
>>
>> -return (err <= 0);
>> +return err;
>> }
>>
>> #if CONFIG_IS_ENABLED(OS_BOOT)
>> --
>> 2.40.1
>>
Re: [PATCHv5 09/13] net/lwip: implement lwip port to u-boot
On Thu, 3 Aug 2023 at 03:32, Simon Glass wrote:
> Hi Maxim,
>
> On Wed, 2 Aug 2023 at 08:11, Maxim Uvarov wrote:
> >
>
> subject: U-Boot
>
> commit message please (throughout series)
>
> > Signed-off-by: Maxim Uvarov
> > ---
> > lib/lwip/port/if.c| 256 ++
> > lib/lwip/port/include/arch/cc.h | 46 +
> > lib/lwip/port/include/arch/sys_arch.h | 59 ++
> > lib/lwip/port/include/limits.h| 0
> > lib/lwip/port/sys-arch.c | 20 ++
> > 5 files changed, 381 insertions(+)
> > create mode 100644 lib/lwip/port/if.c
> > create mode 100644 lib/lwip/port/include/arch/cc.h
> > create mode 100644 lib/lwip/port/include/arch/sys_arch.h
> > create mode 100644 lib/lwip/port/include/limits.h
> > create mode 100644 lib/lwip/port/sys-arch.c
>
> I wonder if this port/ directory should go away and this code should
> be in net/ ? It feels a bit odd, as lib/ code suggests it is for
> libraries, not the integration with them.
>
> >
> > diff --git a/lib/lwip/port/if.c b/lib/lwip/port/if.c
> > new file mode 100644
> > index 00..2ed59a0c4e
> > --- /dev/null
> > +++ b/lib/lwip/port/if.c
> > @@ -0,0 +1,256 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * (C) Copyright 2023 Linaro Ltd.
> > + */
> > +
> > +#include
> > +#include
> > +extern int eth_init(void); /* net.h */
> > +extern void string_to_enetaddr(const char *addr, uint8_t *enetaddr); /*
> net.h */
> > +extern struct in_addr net_ip;
> > +extern u8 net_ethaddr[6];
>
> Can that go in a header file?
>
I tried to do as minimal changes as I could. In general these are
definitions from include/net.h.
And the problem that net.h has not only ethernet things, but also protocol
defines which overlaps
with lwip protocol defines and data structures. More clean fix will be to
clean up net.h and move
ip to net/ip.h udp to net/udp.h and so on. So here we can include
to get eth_init() and
friends accessed.
>
> > +
> > +#include "lwip/debug.h"
> > +#include "lwip/arch.h"
> > +#include "netif/etharp.h"
> > +#include "lwip/stats.h"
> > +#include "lwip/def.h"
> > +#include "lwip/mem.h"
> > +#include "lwip/pbuf.h"
> > +#include "lwip/sys.h"
> > +#include "lwip/netif.h"
> > +
> > +#include "lwip/ip.h"
> > +
> > +#define IFNAME0 'e'
> > +#define IFNAME1 '0'
> > +
> > +static struct pbuf *low_level_input(struct netif *netif);
> > +static int uboot_net_use_lwip;
>
> Can we put this stuff in the UCLASS_ETH private data instead of using
> statics? They require BSS which is typically not available in SPL
> builds.
>
>
yes, that will work. I expect this flag to be used for compatibility mode.
I.e. if it's set before cmd then lwip controls net_loop(), if not set then
an original code controls net_loop(). I can even add an argument to
eth_init(). But because there are too many eth_init() calls I think I will
add an entry to uclass.
> > +
> > +int ulwip_enabled(void)
> > +{
> > + return uboot_net_use_lwip;
> > +}
> > +
> > +/* 1 - in loop
> > + * 0 - no loop
> > + */
> > +static int loop_lwip;
> > +
> > +/* ret 1 - in loop
> > + * 0 - no loop
>
> ??
>
> This all needs some more detail in the comments
>
Yes, maybe with UCLASS_ETH some of that will go away.
>
> > + */
> > +int ulwip_in_loop(void)
> > +{
> > + return loop_lwip;
> > +}
> > +
> > +void ulwip_loop_set(int loop)
> > +{
> > + loop_lwip = loop;
> > +}
> > +
> > +static int ulwip_app_err;
> > +
> > +void ulwip_exit(int err)
> > +{
> > + ulwip_app_err = err;
> > + ulwip_loop_set(0);
> > +}
> > +
> > +int ulwip_app_get_err(void)
> > +{
> > + return ulwip_app_err;
> > +}
> > +
> > +struct uboot_lwip_if {
> > +};
> > +
> > +static struct netif uboot_netif;
> > +
> > +#define LWIP_PORT_INIT_NETMASK(addr) IP4_ADDR((addr), 255, 255, 255, 0)
> > +
> > +extern uchar *net_rx_packet;
> > +extern intnet_rx_packet_len;
>
> header file please
>
>
ok, the same thing here, it's from net.h
> > +
> > +int uboot_lwip_poll(void)
> > +{
> > + struct pbuf *p;
> > + int err;
> > +
> > + p = low_level_input(_netif);
> > + if (!p) {
> > + printf("error p = low_level_input = NULL\n");
> > + return 0;
> > + }
> > +
> > + err = ethernet_input(p, _netif);
> > + if (err)
> > + printf("ip4_input err %d\n", err);
>
> log_err() ?
>
> But what is going on here? Just return the error code, rather than
> suppressing it, then the caller can handle it.
>
>
Looked more detail - current version ethernet_input() (lwip master) always
returns ERR_OK (0). When I wrote I added a return code check for non
function.
So I expect that it can be considered as a bug if some time later we
receive something non 0.
But in general the poll() function has to be void. I will correct it.
> +
> > + return 0;
> > +}
> > +
> > +static struct pbuf *low_level_input(struct netif *netif)
> > +{
> > + struct pbuf *p, *q;
> > + u16_t len =
Re: [PATCH v5 05/11] spl: Convert mmc to spl_load
On 8/3/23 04:31, Xavier Drudis Ferran wrote:
> El Mon, Jul 31, 2023 at 06:42:57PM -0400, Sean Anderson deia:
>> This converts the mmc loader to spl_load. Legacy images are handled by
>> spl_load (via spl_parse_image_header), so mmc_load_legacy can be
>> omitted.
>>
>
> Yes. I haven't used the legacy case, but by looking at the code, it
> seems to me that mmc_load_legacy left the image at some mapped memory
> at [ spl_image->load_addr, spl_image->load_addr + size )
> and the new code does too, but when the image is not aligned, the
> memory that gets written to
> was at [ spl_image->load_addr, spl_image->load_addr + size +
> spl_image->offset % mmc->read_bl_len )
> and it will
> be at [ spl_image->load_addr - spl_image->offset % mmc->read_bl_len,
> spl_image->load_addr + size )
> after this patch.
>
> Meaning both with or without this patch some memory outside the image
> gets written when the image is not aligned on media, but before it was
> some part of a block at the end and now is that part before the
> beginning.
>
> Whether that's better or worse I don't know. It depends on whether
> it's a problem to write in non mapped memory, whether there's
> something worth preserving there, and whether some SOC has some sort
> of special behaving memory just there, like it happened with the issue
> Jerome Forissier found (note in this case it wasn't legacy, it was
> simple fit)
Fundamentally, we can't really deal with unaligned images without a
bounce-buffer. The method used by SPL_LOAD_FIT_IMAGE_BUFFER_SIZE will
continue working, since we call into the FIT routines to load the image.
I would like to defer bounce buffering for other images until someone
actually needs it.
Note that in the FIT case, you can also do `mkimage -EB`, at least if
you aren't using FIT_LOAD_FULL.
--Sean
> https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fpatchwork.ozlabs.org%2fproject%2fuboot%2fpatch%2fc941d835a85255ff81a21c72069c3a9fc9a8a255.1656489154.git.jerome.forissier%40linaro.org%2f=1ca400c8-7d50-4ae9-9abc-31dac6468719=d807158c60b7d2502abde8a2fc01f40662980862-09f1f8fbc507564d04c74bc07523f5da694b0761
>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v5:
>> - Rework to load header in spl_load
>>
>> common/spl/spl_mmc.c | 91
>> 1 file changed, 8 insertions(+), 83 deletions(-)
>>
>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
>> index a665091b00..c926a42c0f 100644
>> --- a/common/spl/spl_mmc.c
>> +++ b/common/spl/spl_mmc.c
>> @@ -17,48 +17,6 @@
>> #include
>> #include
>>
>> -static int mmc_load_legacy(struct spl_image_info *spl_image,
>> - struct spl_boot_device *bootdev,
>> - struct mmc *mmc,
>> - ulong sector, struct legacy_img_hdr *header)
>> -{
>> -u32 image_offset_sectors;
>> -u32 image_size_sectors;
>> -unsigned long count;
>> -u32 image_offset;
>> -int ret;
>> -
>> -ret = spl_parse_image_header(spl_image, bootdev, header);
>> -if (ret)
>> -return ret;
>> -
>> -/* convert offset to sectors - round down */
>> -image_offset_sectors = spl_image->offset / mmc->read_bl_len;
>> -/* calculate remaining offset */
>> -image_offset = spl_image->offset % mmc->read_bl_len;
>> -
>> -/* convert size to sectors - round up */
>> -image_size_sectors = (spl_image->size + mmc->read_bl_len - 1) /
>> - mmc->read_bl_len;
>> -
>> -/* Read the header too to avoid extra memcpy */
>> -count = blk_dread(mmc_get_blk_desc(mmc),
>> - sector + image_offset_sectors,
>> - image_size_sectors,
>> - (void *)(ulong)spl_image->load_addr);
>> -debug("read %x sectors to %lx\n", image_size_sectors,
>> - spl_image->load_addr);
>> -if (count != image_size_sectors)
>> -return -EIO;
>> -
>> -if (image_offset)
>> -memmove((void *)(ulong)spl_image->load_addr,
>> -(void *)(ulong)spl_image->load_addr + image_offset,
>> -spl_image->size);
>> -
>> -return 0;
>> -}
>> -
>> static ulong h_spl_load_read(struct spl_load_info *load, ulong sector,
>> ulong count, void *buf)
>> {
>> @@ -82,47 +40,14 @@ int mmc_load_image_raw_sector(struct spl_image_info
>> *spl_image,
>>struct spl_boot_device *bootdev,
>>struct mmc *mmc, unsigned long sector)
>> {
>> -unsigned long count;
>> -struct legacy_img_hdr *header;
>> -struct blk_desc *bd = mmc_get_blk_desc(mmc);
>> -int ret = 0;
>> -
>> -header = spl_get_load_buffer(-sizeof(*header), bd->blksz);
>> -
>> -/* read image header to find the image size & load address */
>> -count = blk_dread(bd, sector, 1, header);
>> -debug("hdr
[PATCH v4 4/4] arm: dts: k3-am64: Sync DT with Linux v6.5-rc1
Sync all am642-evm/am642-sk related DT files
with Linux v6.5-rc1.
- drop timer1 in favor of main_timer0 in am64-main.dtsi.
Need to delete clock & power domain properties of
main_timer1 in -r5.dts else won't boot. This is because
timer_init is done during rproc_start to start System Firmware,
but we can't do any clock/power-domain operations before
System Firmware starts.
- same constraint applies to main_uart0
- drop cpsw3g custom DT property 'mac_efuse' and custom
DT node cpsw-phy-sel as driver picks these from standard
property/node.
- include board dts file in -r5 dts file to avoid duplication
of nodes. Include -u-boot.dtsi on top.
- drop duplicate nodes in -r5 dts and -u-boot.dtsi
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am64-main.dtsi| 171 ++-
arch/arm/dts/k3-am64-mcu.dtsi | 53 +-
arch/arm/dts/k3-am64-thermal.dtsi | 33
arch/arm/dts/k3-am64.dtsi | 22 +--
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 57 +++
arch/arm/dts/k3-am642-evm.dts | 173 ++-
arch/arm/dts/k3-am642-r5-evm.dts | 231 +++---
arch/arm/dts/k3-am642-r5-sk.dts | 218 +++-
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 52 ++
arch/arm/dts/k3-am642-sk.dts | 166 +-
arch/arm/dts/k3-am642.dtsi| 1 +
doc/board/ti/am64x_evm.rst| 2 +-
12 files changed, 605 insertions(+), 574 deletions(-)
create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
index 5e8036f32d..1664d9f024 100644
--- a/arch/arm/dts/k3-am64-main.dtsi
+++ b/arch/arm/dts/k3-am64-main.dtsi
@@ -228,12 +228,161 @@
};
};
+ main_timer0: timer@240 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x240 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 36 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 36 1>;
+ assigned-clock-parents = <_clks 36 2>;
+ power-domains = <_pds 36 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer1: timer@241 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x241 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 37 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 37 1>;
+ assigned-clock-parents = <_clks 37 2>;
+ power-domains = <_pds 37 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer2: timer@242 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x242 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 38 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 38 1>;
+ assigned-clock-parents = <_clks 38 2>;
+ power-domains = <_pds 38 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer3: timer@243 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x243 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 39 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 39 1>;
+ assigned-clock-parents = <_clks 39 2>;
+ power-domains = <_pds 39 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer4: timer@244 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x244 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 40 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 40 1>;
+ assigned-clock-parents = <_clks 40 2>;
+ power-domains = <_pds 40 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer5: timer@245 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x245 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 41 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 41 1>;
+ assigned-clock-parents = <_clks 41 2>;
+ power-domains = <_pds 41 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer6: timer@246 {
+ compatible = "ti,am654-timer";
+ reg = <0x00 0x246 0x00 0x400>;
+ interrupts = ;
+ clocks = <_clks 42 1>;
+ clock-names = "fck";
+ assigned-clocks = <_clks 42 1>;
+ assigned-clock-parents = <_clks 42 2>;
+ power-domains = <_pds 42 TI_SCI_PD_EXCLUSIVE>;
+ ti,timer-pwm;
+ };
+
+ main_timer7: timer@247 {
+ compatible =
[PATCH v4 3/4] doc: board: ti: am64: Add boot flow diagram
Add boot flow diagram for AM64 SoC. Suggested-by: Nishanth Menon Signed-off-by: Roger Quadros --- doc/board/ti/am64x_evm.rst | 197 +++ doc/board/ti/img/boot_diagram_am64.svg | 1702 doc/board/ti/k3.rst|1 + 3 files changed, 1900 insertions(+) create mode 100644 doc/board/ti/am64x_evm.rst create mode 100644 doc/board/ti/img/boot_diagram_am64.svg diff --git a/doc/board/ti/am64x_evm.rst b/doc/board/ti/am64x_evm.rst new file mode 100644 index 00..f378cbf12b --- /dev/null +++ b/doc/board/ti/am64x_evm.rst @@ -0,0 +1,197 @@ +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +.. sectionauthor:: Nishanth Menon + +AM64 Platforms +== + +Introduction: +- +The AM642 SoC belongs to the K3 Multicore SoC architecture platform, +providing advanced system integration to enable applications such as +Motor Drives, PLC, Remote IO and IoT Gateways. + +Some highlights of this SoC are: + +* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F + MCUs, and a single Cortex-M4F. +* Two Gigabit Industrial Communication Subsystems (ICSSG). +* Integrated Ethernet switch supporting up to a total of two external + ports. +* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory + controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other + peripherals. +* Centralized System Controller for Security, Power, and Resource + Management (DMSC). + +More details can be found in the Technical Reference Manual: + https://www.ti.com/lit/pdf/spruim2 + +Platform information: + +* AM64-EVM: https://www.ti.com/tool/TMDS64EVM +* AM64-SK: https://www.ti.com/tool/SK-AM64B + +Boot Flow: +-- +Below is the pictorial representation of boot flow: + +.. image:: img/boot_diagram_am64.svg + +- Here TIFS acts as master and provides all the critical services. R5/A53 + requests TIFS to get these services done as shown in the above diagram. + +Sources: + + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_boot_sources +:end-before: .. k3_rst_include_end_boot_sources + +Build procedure: + +0. Setup the environment variables: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_desc +:end-before: .. k3_rst_include_end_common_env_vars_desc + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_board_env_vars_desc +:end-before: .. k3_rst_include_end_board_env_vars_desc + +Set the variables corresponding to this platform: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_common_env_vars_defn +:end-before: .. k3_rst_include_end_common_env_vars_defn +.. code-block:: bash + + $ export UBOOT_CFG_CORTEXR=am64x_evm_r5_defconfig + $ export UBOOT_CFG_CORTEXA=am64x_evm_a53_defconfig + $ export TFA_BOARD=lite + $ # we dont use any extra TFA parameters + $ unset TFA_EXTRA_ARGS + $ export OPTEE_PLATFORM=k3-am64x + $ # we dont use any extra TFA parameters + $ unset OPTEE_EXTRA_ARGS + +.. am64x_evm_rst_include_start_build_steps + +1. Trusted Firmware-A: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_tfa +:end-before: .. k3_rst_include_end_build_steps_tfa + + +2. OP-TEE: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_optee +:end-before: .. k3_rst_include_end_build_steps_optee + +3. U-Boot: + +* 4.1 R5: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_spl_r5 +:end-before: .. k3_rst_include_end_build_steps_spl_r5 + +* 4.2 A53: + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_build_steps_uboot +:end-before: .. k3_rst_include_end_build_steps_uboot +.. am64x_evm_rst_include_end_build_steps + +Target Images +-- +In order to boot we need tiboot3.bin, tispl.bin and u-boot.img. Each SoC +variant (GP, HS-FS, HS-SE) requires a different source for these files. + + - GP + +* tiboot3-am64x-gp-evm.bin from step 3.1 +* tispl.bin_unsigned, u-boot.img_unsigned from step 3.2 + + - HS-FS + +* tiboot3-am64x-hs-fs-evm.bin from step 3.1 +* tispl.bin, u-boot.img from step 3.2 + + - HS-SE + +* tiboot3-am64x-hs-evm.bin from step 3.1 +* tispl.bin, u-boot.img from step 3.2 + +Image formats: +-- + +- tiboot3.bin + +.. image:: img/multi_cert_tiboot3.bin.svg + +- tispl.bin + +.. image:: img/nodm_tispl.bin.svg + +Switch Setting for Boot Mode + + +Boot Mode pins provide means to select the boot mode and options before the +device is powered up. After every POR, they are the main source to populate +the Boot Parameter Tables. + +The following table shows some common boot modes used on AM64 platform. More +details can be found in the Technical Reference Manual: +https://www.ti.com/lit/pdf/spruim2 under the `Boot Mode Pins` section. + +.. list-table:: Boot Modes for AM64x-EVM + :widths: 16 16 16 + :header-rows: 1 + + * - Switch Label +
[PATCH v4 2/4] Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node"
This reverts commit 28a4c3113445d4400639f357fae0def007a41093.
This node should be in the board DT file and should come from upstream.
Moreover, this PMIC is no present on all variants of am642-sk
and will need a separate board DT file.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 61
1 file changed, 61 deletions(-)
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 3d6be025bd..4431750dc6 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -54,67 +54,6 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0_pins_default>;
clock-frequency = <40>;
-
- tps65219: pmic@30 {
- compatible = "ti,tps65219";
- reg = <0x30>;
-
- regulators {
- buck1_reg: buck1 {
- regulator-name = "VDD_CORE";
- regulator-min-microvolt = <75>;
- regulator-max-microvolt = <75>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- buck2_reg: buck2 {
- regulator-name = "VCC1V8";
- regulator-min-microvolt = <180>;
- regulator-max-microvolt = <180>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- buck3_reg: buck3 {
- regulator-name = "VDD_LPDDR4";
- regulator-min-microvolt = <110>;
- regulator-max-microvolt = <110>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: ldo1 {
- regulator-name = "VDDSHV_SD_IO_PMIC";
- regulator-min-microvolt = <3300>;
- regulator-max-microvolt = <3300>;
- };
-
- ldo2_reg: ldo2 {
- regulator-name = "VDDAR_CORE";
- regulator-min-microvolt = <85>;
- regulator-max-microvolt = <85>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo3_reg: ldo3 {
- regulator-name = "VDDA_1V8";
- regulator-min-microvolt = <1800>;
- regulator-max-microvolt = <1800>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo4_reg: ldo4 {
- regulator-name = "VDD_PHY_2V5";
- regulator-min-microvolt = <2500>;
- regulator-max-microvolt = <2500>;
- regulator-boot-on;
- regulator-always-on;
- };
- };
- };
};
_uart0 {
--
2.34.1
[PATCH v4 1/4] board: ti: am64x: Recognize AM64-HSEVM
AM64-HSEVM is AM64-GPEVM with High Security Device.
Gets rid of "Unidentified board claims AM64-HSEVM in eeprom header".
Signed-off-by: Roger Quadros
Acked-by: Andrew Davis
---
board/ti/am64x/evm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index 96f4e3013a..a080b2b0d2 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -18,7 +18,8 @@
#include "../common/board_detect.h"
-#define board_is_am64x_gpevm() board_ti_k3_is("AM64-GPEVM")
+#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
+ board_ti_k3_is("AM64-HSEVM"))
#define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
board_ti_k3_is("AM64B-SKEVM"))
--
2.34.1
[PATCH v4 0/4] arm: dts: k3-am64: Sync DT with Linux
Hi, This series syncs AM64 DT files from Linux v6.5-rc1. Tested on AM642-EVM GP SR1.0 and AM642-SK-EVM HS-FS SR2.0. cheers, -roger Changelog: v4: -Add documentation for am642-evm and am642-sk-evm. -Add license to am64 svg file -drop mmc0 pinmux from k3-am642-r5-evm.dts -drop stdout-path from -r5 & -u-boot dts. -drop vtt-supply and vtt pinmux from memorycontroller in k3-am642-r5-evm.dts -am642-evm: move bootph-pre-ram for main_esm, mcu_esm into -r5 .dts v3: - include board DT file in -r5 DT file. - move including -u-boot.dtsi file at the top of -r5 DT file. - drop duplicate nodes - document why we need to delete clock/power properties from main_timer0 v2: - Sync with v6.5-rc1 - Rebase on latest uboot/master - CPSW node cleanup - Timer node cleanup Roger Quadros (4): board: ti: am64x: Recognize AM64-HSEVM Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node" doc: board: ti: am64: Add boot flow diagram arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 arch/arm/dts/k3-am64-main.dtsi | 171 ++- arch/arm/dts/k3-am64-mcu.dtsi | 53 +- arch/arm/dts/k3-am64-thermal.dtsi | 33 + arch/arm/dts/k3-am64.dtsi | 22 +- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 57 +- arch/arm/dts/k3-am642-evm.dts | 173 ++- arch/arm/dts/k3-am642-r5-evm.dts | 231 +--- arch/arm/dts/k3-am642-r5-sk.dts| 218 +-- arch/arm/dts/k3-am642-sk-u-boot.dtsi | 113 +- arch/arm/dts/k3-am642-sk.dts | 166 ++- arch/arm/dts/k3-am642.dtsi |1 + board/ti/am64x/evm.c |3 +- doc/board/ti/am64x_evm.rst | 197 +++ doc/board/ti/img/boot_diagram_am64.svg | 1702 doc/board/ti/k3.rst|1 + 15 files changed, 2506 insertions(+), 635 deletions(-) create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi create mode 100644 doc/board/ti/am64x_evm.rst create mode 100644 doc/board/ti/img/boot_diagram_am64.svg -- 2.34.1
[PATCH v2 2/2] spl: move SPL_CRC32 option to lib/Kconfig
All SPL hash algorithm options are collected in lib/Kconfig. Move SPL_CRC32 there as well. Signed-off-by: Oleksandr Suvorov --- Changes in v2: - add a related commit to the series. common/spl/Kconfig | 11 --- lib/Kconfig| 11 +++ 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c66d70e2a99..c5dd476db58 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -550,17 +550,6 @@ config SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION the eMMC EXT_CSC_PART_CONFIG selection should be overridden in SPL by user defined partition number. -config SPL_CRC32 - bool "Support CRC32" - default y if SPL_LEGACY_IMAGE_FORMAT || SPL_EFI_PARTITION - default y if SPL_ENV_SUPPORT || TPL_BLOBLIST - help - Enable this to support CRC32 in uImages or FIT images within SPL. - This is a 32-bit checksum value that can be used to verify images. - For FIT images, this is the least secure type of checksum, suitable - for detected accidental image corruption. For secure applications you - should consider SHA1 or SHA256. - config SPL_FIT_IMAGE_TINY bool "Remove functionality from SPL FIT loading to reduce size" depends on SPL_FIT diff --git a/lib/Kconfig b/lib/Kconfig index 3926652db63..07e61de5b64 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -534,6 +534,17 @@ config SHA_HW_ACCEL if SPL +config SPL_CRC32 + bool "Enable CRC32 support in SPL" + default y if SPL_LEGACY_IMAGE_SUPPORT || SPL_EFI_PARTITION + default y if SPL_ENV_SUPPORT || TPL_BLOBLIST + help + This option enables support of hashing using CRC32 algorithm. + The CRC32 algorithm produces 32-bit checksum value. For FIT + images, this is the least secure type of checksum, suitable for + detected accidental image corruption. For secure applications you + should consider SHA256 or SHA384. + config SPL_SHA1 bool "Enable SHA1 support in SPL" default y if SHA1 -- 2.40.1
[PATCH v2 1/2] spl: remove duplicate SPL_MD5 option
There is another SPL_MD5 option defined in lib/Kconfig.
Renaming SPL_MD5_SUPPORT introduced duplicate option with
different description. As for now FIT and hash algorithm options
are not related to each others, removing a duplicate option seems OK.
Fixes: 4b00fd1a84c ("Kconfig: Rename SPL_MD5_SUPPORT to SPL_MD5")
Signed-off-by: Oleksandr Suvorov
---
(no changes since v1)
common/spl/Kconfig | 12
1 file changed, 12 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index bee231b583a..c66d70e2a99 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -561,18 +561,6 @@ config SPL_CRC32
for detected accidental image corruption. For secure applications you
should consider SHA1 or SHA256.
-config SPL_MD5
- bool "Support MD5"
- depends on SPL_FIT
- help
- Enable this to support MD5 in FIT images within SPL. An MD5
- checksum is a 128-bit hash value used to check that the image
- contents have not been corrupted. Note that MD5 is not considered
- secure as it is possible (with a brute-force attack) to adjust the
- image while still retaining the same MD5 hash value. For secure
- applications where images may be changed maliciously, you should
- consider SHA256 or SHA384.
-
config SPL_FIT_IMAGE_TINY
bool "Remove functionality from SPL FIT loading to reduce size"
depends on SPL_FIT
--
2.40.1
[PATCH v18 9/9] arm_ffa: efi: corstone1000: enable MM communication
turn on EFI MM communication On Corstone-1000 platform MM communication between u-boot and the secure world (Optee) is done using the FF-A bus. Changes made are generated using savedefconfig. Signed-off-by: Abdellatif El Khlifi Cc: Tom Rini Cc: Simon Glass Cc: Ilias Apalodimas Cc: Jens Wiklander --- Changelog: === v18: Ilias, Tom: * drop use of CONFIG_FFA_SHARED_MM_BUF_* v17: * use savedefconfig to generate corstone1000_defconfig with FF-A MM comms enabled v16: * configs/corstone1000_defconfig: enable MM communication by setting the configs: ARM_FFA_TRANSPORT, OPTEE, TEE v15: Simon: * use CONFIG_FFA_SHARED_MM_BUF_* configs in place of FFA_SHARED_MM_BUFFER_* v13: * remove FF-A config in the defconfig (because it's enabled automatically by CONFIG_EFI_MM_COMM_TEE) v9: * update copyright string v8: * drop OP-TEE configs from Corstone-1000 defconfig v7: * improve the definition of FFA_SHARED_MM_BUFFER_ADDR and FFA_SHARED_MM_BUFFER_OFFSET * update FFA_SHARED_MM_BUFFER_ADDR value v6: * corstone-1000: enable optee driver * corstone-1000: remove CONFIG_ARM_FFA_EFI_RUNTIME_MODE from the defconfig v4: * corstone-1000: turn on EFI MM communication configs/corstone1000_defconfig | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig index a8a79fd105..59ce1ec15c 100644 --- a/configs/corstone1000_defconfig +++ b/configs/corstone1000_defconfig @@ -28,12 +28,10 @@ CONFIG_CMD_FWU_METADATA=y CONFIG_CMD_BOOTZ=y CONFIG_SYS_BOOTM_LEN=0x80 # CONFIG_CMD_XIMG is not set -CONFIG_CMD_NVMXIP=y CONFIG_CMD_GPT=y # CONFIG_RANDOM_UUID is not set CONFIG_CMD_LOADM=y # CONFIG_CMD_LOADS is not set -CONFIG_CMD_MMC=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set @@ -45,8 +43,7 @@ CONFIG_OF_CONTROL=y CONFIG_VERSION_VARIABLE=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_REGMAP=y -CONFIG_FWU_MDATA=y -CONFIG_FWU_MDATA_GPT_BLK=y +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_MISC=y # CONFIG_MMC is not set CONFIG_NVMXIP_QSPI=y @@ -59,9 +56,12 @@ CONFIG_DM_RTC=y CONFIG_RTC_EMULATION=y CONFIG_DM_SERIAL=y CONFIG_SYSRESET=y +CONFIG_TEE=y +CONFIG_OPTEE=y CONFIG_USB=y CONFIG_USB_ISP1760=y +CONFIG_ERRNO_STR=y +CONFIG_EFI_MM_COMM_TEE=y CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_IGNORE_OSINDICATIONS=y CONFIG_FWU_MULTI_BANK_UPDATE=y -CONFIG_ERRNO_STR=y -- 2.25.1
[PATCH v18 8/9] arm_ffa: efi: introduce FF-A MM communication
Add MM communication support using FF-A transport This feature allows accessing MM partitions services through EFI MM communication protocol. MM partitions such as StandAlonneMM or smm-gateway secure partitions which reside in secure world. An MM shared buffer and a door bell event are used to exchange the data. The data is used by EFI services such as GetVariable()/SetVariable() and copied from the communication buffer to the MM shared buffer. The secure partition is notified about availability of data in the MM shared buffer by an FF-A message (door bell). On such event, MM SP can read the data and updates the MM shared buffer with the response data. The response data is copied back to the communication buffer and consumed by the EFI subsystem. MM communication protocol supports FF-A 64-bit direct messaging. We tested the FF-A MM communication on the Corstone-1000 platform. We ran the UEFI SCT test suite containing EFI setVariable, getVariable and getNextVariable tests which involve FF-A MM communication and all tests are passing with the current changes. We made the SCT test reports (part of the ACS results) public following the latest Corstone-1000 platform software release. Please find the test reports at [1]. [1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip Signed-off-by: Abdellatif El Khlifi Tested-by: Gowtham Suresh Kumar Reviewed-by: Simon Glass Cc: Tom Rini Cc: Ilias Apalodimas Cc: Jens Wiklander --- Changelog: === v18: Ilias, Tom: * drop the use of configs for the shared MM buffer, put back #ifdefs instead * add test information to the commit log v17: * show a debug message rather than an error when FF-A is not detected v16: * lib/efi_loader/Kconfig: rather than automatically selecting OPTEE and ARM_FFA_TRANSPORT configs by EFI_MM_COMM_TEE, set them as dependencies (Otherwise FF-A will be automatically enabled for boards that don't need it). v15: Simon: * replace FFA_SHARED_MM_BUFFER_* defines with configs v14: Ilias: * drop truncating var_payload->size when using FF-A * map the MM SP return codes to errnos v13: * remove FF-A and Optee ifdefs v12: * drop use of calloc when querying SPs * address nits v11: * rename select_ffa_mm_comms() to select_mm_comms() * improve the logic of MM transport selection in mm_communicate() * addressing nits v10: * use the FF-A driver Uclass operations * use uclass_first_device() * addressing nits v9: align how FF-A is used with FF-A discovery through DM v8: * isolate the compilation choices between FF-A and OP-TEE * update partition_info_get() second argument to be an SP count * pass NULL device pointer to the FF-A bus discovery and operations v7: * set the MM door bell event to use 64-bit direct messaging * issue a compile time error when one of these macros are not found : FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_OFFSET, FFA_SHARED_MM_BUFFER_ADDR * make mm_sp_svc_uuid static * replace EINVAL with ENOMEM in ffa_discover_mm_sp_id() when calloc() fails * improve use of unmap_sysmem() in ffa_mm_communicate() v6: * add FF-A runtime discovery at MM communication level * drop EFI runtime support for FF-A MM communication * revert the changes in include/mm_communication.h for efi_mm_communicate_header and smm_variable_access structures v4: * use the new FF-A driver interfaces * discover MM partitions at runtime * copy FF-A driver private data to EFI runtime section at ExitBootServices() * drop use of FFA_ERR_STAT_SUCCESS error code * replace EFI_BUFFER_TOO_SMALL with EFI_OUT_OF_RESOURCES in ffa_mm_communicate(). No need for efi_memcpy_runtime() anymore * revert the error log in mm_communicate() in case of failure * remove packed attribute from efi_mm_communicate_header and smm_variable_communicate_header v2: * set default values to 0 for FFA_SHARED_MM_BUFFER_SIZE, FFA_SHARED_MM_BUFFER_ADDR and MM_SP_UUID_DATA and add warnings v1: * introduce FF-A MM communication include/mm_communication.h| 17 ++ lib/efi_loader/Kconfig| 42 - lib/efi_loader/efi_variable_tee.c | 282 +- 3 files changed, 335 insertions(+), 6 deletions(-) diff --git a/include/mm_communication.h b/include/mm_communication.h index e65fbde60d..f38f1a5344 100644 --- a/include/mm_communication.h +++ b/include/mm_communication.h @@ -6,6 +6,9 @@ * Copyright (c) 2017, Intel Corporation. All rights reserved. * Copyright (C) 2020 Linaro Ltd. * Copyright (C) 2020 Linaro Ltd. + * Copyright 2022-2023 Arm Limited and/or its affiliates + *Authors: + * Abdellatif El Khlifi */ #ifndef _MM_COMMUNICATION_H_ @@ -13,6 +16,11 @@ #include +#if CONFIG_IS_ENABLED(ARM_FFA_TRANSPORT) +/* MM service UUID string (big-endian format). This UUID is common across all MM SPs */ +#define MM_SP_UUID
[PATCH v18 7/9] arm_ffa: introduce armffa command
Provide armffa command showcasing the use of the U-Boot FF-A support
armffa is a command showcasing how to invoke FF-A operations.
This provides a guidance to the client developers on how to
call the FF-A bus interfaces. The command also allows to gather secure
partitions information and ping these partitions. The command is also
helpful in testing the communication with secure partitions.
For more details please refer to the command documentation [1].
A Sandbox test is provided for the armffa command.
[1]: doc/usage/cmd/armffa.rst
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v18:
Simon:
* Combining the commits of the command and the test case
v15:
Simon:
* armffa.c : integrate PHYS_ADDR_LN
v14:
Ilias:
* address nits
* in do_ffa_ping() reject the SP ID if it's 0
* use PHYS_ADDR_LN in formatting the physical addresses
v12:
* add subcommands argument checks
* usage documentation: update command return codes
* remove calloc when querying SPs
* address nits
v11:
* use U_BOOT_CMD_WITH_SUBCMDS
* address nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* address nits
v9:
* remove manual FF-A discovery and use DM
* use DM class APIs to probe and interact with the FF-A bus
* add doc/usage/cmd/armffa.rst
v8:
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7:
* adapt do_ffa_dev_list() following the recent update on
uclass_first_device/uclass_next_device functions (they return void now)
* set armffa command to use 64-bit direct messaging
v4:
* remove pattern data in do_ffa_msg_send_direct_req
v3:
* use the new driver interfaces (partition_info_get, sync_send_receive)
in armffa command
v2:
* replace use of ffa_helper_init_device function by
ffa_helper_bus_discover
v1:
* introduce armffa command
MAINTAINERS | 3 +
cmd/Kconfig | 10 ++
cmd/Makefile | 1 +
cmd/armffa.c | 202 +++
doc/arch/arm64.ffa.rst | 9 ++
doc/usage/cmd/armffa.rst | 94 ++
doc/usage/index.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 1 +
test/cmd/Makefile| 2 +
test/cmd/armffa.c| 33 +
10 files changed, 356 insertions(+)
create mode 100644 cmd/armffa.c
create mode 100644 doc/usage/cmd/armffa.rst
create mode 100644 test/cmd/armffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index b6d7263010..bd3dba3d95 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -271,9 +271,12 @@ M: Abdellatif El Khlifi
S: Maintained
F: arch/sandbox/include/asm/sandbox_arm_ffa.h
F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
+F: cmd/armffa.c
F: doc/arch/arm64.ffa.rst
+F: doc/usage/cmd/armffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
+F: test/cmd/armffa.c
F: test/dm/ffa.c
ARM FREESCALE IMX
diff --git a/cmd/Kconfig b/cmd/Kconfig
index c1941849f9..da8569b417 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -935,6 +935,16 @@ endmenu
menu "Device access commands"
+config CMD_ARMFFA
+ bool "Arm FF-A test command"
+ depends on ARM_FFA_TRANSPORT
+ help
+ Provides a test command for the FF-A support
+ supported options:
+ - Listing the partition(s) info
+ - Sending a data pattern to the specified partition
+ - Displaying the arm_ffa device info
+
config CMD_ARMFLASH
#depends on FLASH_CFI_DRIVER
bool "armflash"
diff --git a/cmd/Makefile b/cmd/Makefile
index 6c37521b4e..7d20a85a46 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,7 @@ obj-y += panic.o
obj-y += version.o
# command
+obj-$(CONFIG_CMD_ARMFFA) += armffa.o
obj-$(CONFIG_CMD_2048) += 2048.o
obj-$(CONFIG_CMD_ACPI) += acpi.o
obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
diff --git a/cmd/armffa.c b/cmd/armffa.c
new file mode 100644
index 00..7e6eafc03a
--- /dev/null
+++ b/cmd/armffa.c
@@ -0,0 +1,202 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Select the right physical address formatting according to the platform */
+#ifdef CONFIG_PHYS_64BIT
+#define PhysAddrLength "ll"
+#else
+#define PhysAddrLength ""
+#endif
+#define PHYS_ADDR_LN "%" PhysAddrLength "x"
+
+/**
+ * ffa_get_dev() - Return the FF-A device
+ * @devp: pointer to the FF-A device
+ *
+ * Search for the FF-A device.
+ *
+ * Return:
+ * 0 on success. Otherwise, failure
+ */
+static int ffa_get_dev(struct udevice **devp)
+{
+ int ret;
+
+ ret = uclass_first_device_err(UCLASS_FFA, devp);
+ if (ret) {
+
[PATCH v18 6/9] arm_ffa: introduce sandbox test cases for UCLASS_FFA
Add functional test cases for the FF-A support
These tests rely on the FF-A sandbox emulator and FF-A
sandbox driver which help in inspecting the FF-A communication.
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v12:
* remove use of dscvry_info
* drop use of calloc when querying SPs
* address nits
v11:
* drop unmapping test (taken care of by the DM when removing the device)
* address nits
v10:
* use the FF-A driver Uclass operations
* use uclass_first_device()
* replace CONFIG_SANDBOX_FFA with CONFIG_ARM_FFA_TRANSPORT
* address nits
v9: align FF-A sandbox tests with FF-A discovery through DM
v8:
* update partition_info_get() second argument to be an SP count
* pass NULL device pointer to the FF-A bus discovery and operations
v7: set the tests to use 64-bit direct messaging
v4: align sandbox tests with the new FF-A driver interfaces
and new way of error handling
v1: introduce sandbox tests
MAINTAINERS| 1 +
doc/arch/arm64.ffa.rst | 1 +
test/dm/Makefile | 3 +-
test/dm/ffa.c | 261 +
4 files changed, 265 insertions(+), 1 deletion(-)
create mode 100644 test/dm/ffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 63cf37290c..b6d7263010 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -274,6 +274,7 @@ F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
F: doc/arch/arm64.ffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
+F: test/dm/ffa.c
ARM FREESCALE IMX
M: Stefano Babic
diff --git a/doc/arch/arm64.ffa.rst b/doc/arch/arm64.ffa.rst
index 792898321a..71606373f9 100644
--- a/doc/arch/arm64.ffa.rst
+++ b/doc/arch/arm64.ffa.rst
@@ -37,6 +37,7 @@ The U-Boot FF-A support provides the following parts:
FF-A ABIs inspection methods.
- An FF-A sandbox device driver for FF-A communication with the emulated
Secure World.
The driver leverages the FF-A Uclass to establish FF-A communication.
+- Sandbox FF-A test cases.
FF-A and SMC specifications
---
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 3799b1ae8f..7ed00733c1 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2013 Google, Inc
-# Copyright 2023 Arm Limited and/or its affiliates
+# Copyright 2022-2023 Arm Limited and/or its affiliates
obj-$(CONFIG_UT_DM) += test-dm.o
@@ -92,6 +92,7 @@ obj-$(CONFIG_POWER_DOMAIN) += power-domain.o
obj-$(CONFIG_ACPI_PMC) += pmc.o
obj-$(CONFIG_DM_PMIC) += pmic.o
obj-$(CONFIG_DM_PWM) += pwm.o
+obj-$(CONFIG_ARM_FFA_TRANSPORT) += ffa.o
obj-$(CONFIG_QFW) += qfw.o
obj-$(CONFIG_RAM) += ram.o
obj-y += regmap.o
diff --git a/test/dm/ffa.c b/test/dm/ffa.c
new file mode 100644
index 00..6912666bb4
--- /dev/null
+++ b/test/dm/ffa.c
@@ -0,0 +1,261 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA class
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Functional tests for the UCLASS_FFA */
+
+static int check_fwk_version(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ struct ffa_sandbox_data func_data;
+ u32 fwk_version = 0;
+
+ func_data.data0 = _version;
+ func_data.data0_size = sizeof(fwk_version);
+ ut_assertok(sandbox_query_ffa_emul_state(FFA_VERSION, _data));
+ ut_asserteq(uc_priv->fwk_version, fwk_version);
+
+ return 0;
+}
+
+static int check_endpoint_id(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ ut_asserteq(0, uc_priv->id);
+
+ return 0;
+}
+
+static int check_rxtxbuf(struct ffa_priv *uc_priv, struct unit_test_state *uts)
+{
+ ut_assertnonnull(uc_priv->pair.rxbuf);
+ ut_assertnonnull(uc_priv->pair.txbuf);
+
+ return 0;
+}
+
+static int check_features(struct ffa_priv *uc_priv, struct unit_test_state
*uts)
+{
+ ut_assert(uc_priv->pair.rxtx_min_pages == RXTX_4K ||
+ uc_priv->pair.rxtx_min_pages == RXTX_16K ||
+ uc_priv->pair.rxtx_min_pages == RXTX_64K);
+
+ return 0;
+}
+
+static int check_rxbuf_mapped_flag(u32 queried_func_id,
+ u8 rxbuf_mapped,
+ struct unit_test_state *uts)
+{
+ switch (queried_func_id) {
+ case FFA_RXTX_MAP:
+ ut_asserteq(1, rxbuf_mapped);
+ break;
+ case FFA_RXTX_UNMAP:
+ ut_asserteq(0, rxbuf_mapped);
+ break;
+ default:
+ ut_assert(false);
+ }
+
+ return 0;
+}
+
+static int check_rxbuf_release_flag(u8 rxbuf_owned, struct unit_test_state
*uts)
+{
+ ut_asserteq(0, rxbuf_owned);
+
+ return 0;
+}
+
[PATCH v18 5/9] arm_ffa: introduce sandbox FF-A support
Emulate Secure World's FF-A ABIs and allow testing U-Boot FF-A support
Features of the sandbox FF-A support:
- Introduce an FF-A emulator
- Introduce an FF-A device driver for FF-A comms with emulated Secure World
- Provides test methods allowing to read the status of the inspected ABIs
The sandbox FF-A emulator supports only 64-bit direct messaging.
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v12:
* remove reparenting by making the emulator parent of the FF-A device in the DT
* add invoke_ffa_fn()
* address nits
v11:
* rename ffa_try_discovery() to sandbox_ffa_discover()
* rename sandbox_ffa_query_core_state() to sandbox_query_ffa_emul_state()
* store the sandbox emulator pointer in the FF-A device uc_priv (struct
ffa_priv)
* set the emulator as parent of the sandbox FF-A device
v10:
* split the FF-A sandbox support into an emulator and a driver
* read FFA_VERSION and FFA_PARTITION_INFO_GET state using
sandbox_ffa_query_core_state()
* drop CONFIG_SANDBOX_FFA config
* address nits
v9: align FF-A sandbox driver with FF-A discovery through DM
v8: update ffa_bus_prvdata_get() to return a pointer rather than
a pointer address
v7: state that sandbox driver supports only 64-bit direct messaging
v4: align sandbox driver with the new FF-A driver interfaces
and new way of error handling
v1: introduce the sandbox driver
MAINTAINERS | 3 +-
arch/sandbox/dts/sandbox.dtsi | 9 +
arch/sandbox/dts/test.dts | 8 +
arch/sandbox/include/asm/sandbox_arm_ffa.h| 72 ++
.../include/asm/sandbox_arm_ffa_priv.h| 121 +++
configs/sandbox64_defconfig | 1 +
configs/sandbox_defconfig | 1 +
doc/arch/arm64.ffa.rst| 19 +-
doc/arch/sandbox/sandbox.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 13 +-
drivers/firmware/arm-ffa/Makefile | 10 +-
drivers/firmware/arm-ffa/ffa-emul-uclass.c| 720 ++
.../firmware/arm-ffa/sandbox_arm_ffa_priv.h | 14 -
drivers/firmware/arm-ffa/sandbox_ffa.c| 110 +++
include/dm/uclass-id.h| 1 +
15 files changed, 1081 insertions(+), 22 deletions(-)
create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa.h
create mode 100644 arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
create mode 100644 drivers/firmware/arm-ffa/ffa-emul-uclass.c
delete mode 100644 drivers/firmware/arm-ffa/sandbox_arm_ffa_priv.h
create mode 100644 drivers/firmware/arm-ffa/sandbox_ffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4fd5768de0..63cf37290c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,10 +269,11 @@ F:configs/cortina_presidio-asic-pnand_defconfig
ARM FF-A
M: Abdellatif El Khlifi
S: Maintained
+F: arch/sandbox/include/asm/sandbox_arm_ffa.h
+F: arch/sandbox/include/asm/sandbox_arm_ffa_priv.h
F: doc/arch/arm64.ffa.rst
F: drivers/firmware/arm-ffa/
F: include/arm_ffa.h
-F: include/sandbox_arm_ffa.h
ARM FREESCALE IMX
M: Stefano Babic
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index 30a305c4d2..94a08814b8 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -445,6 +445,15 @@
thermal {
compatible = "sandbox,thermal";
};
+
+ arm-ffa-emul {
+ compatible = "sandbox,arm-ffa-emul";
+
+ sandbox-arm-ffa {
+ compatible = "sandbox,arm-ffa";
+ };
+ };
+
};
_ec {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ff9f9222e6..96b5404991 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1820,6 +1820,14 @@
extcon {
compatible = "sandbox,extcon";
};
+
+ arm-ffa-emul {
+ compatible = "sandbox,arm-ffa-emul";
+
+ sandbox-arm-ffa {
+ compatible = "sandbox,arm-ffa";
+ };
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/arch/sandbox/include/asm/sandbox_arm_ffa.h
b/arch/sandbox/include/asm/sandbox_arm_ffa.h
new file mode 100644
index 00..be2790f496
--- /dev/null
+++ b/arch/sandbox/include/asm/sandbox_arm_ffa.h
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#ifndef __SANDBOX_ARM_FFA_H
+#define __SANDBOX_ARM_FFA_H
+
+#include
+
+/*
+ * This header provides public sandbox FF-A emulator declarations
+ * and declarations needed by FF-A sandbox clients
+ */
+
+/* UUIDs strings of the emulated services */
+#define SANDBOX_SERVICE1_UUID "ed32d533-4209-99e6-2d72-cdd998a79cc0"
+#define SANDBOX_SERVICE2_UUID
[PATCH v18 4/9] arm_ffa: introduce Arm FF-A support
Add Arm FF-A support implementing Arm Firmware Framework for Armv8-A v1.0
The Firmware Framework for Arm A-profile processors (FF-A v1.0) [1]
describes interfaces (ABIs) that standardize communication
between the Secure World and Normal World leveraging TrustZone
technology.
This driver uses 64-bit registers as per SMCCCv1.2 spec and comes
on top of the SMCCC layer. The driver provides the FF-A ABIs needed for
querying the FF-A framework from the secure world.
The driver uses SMC32 calling convention which means using the first
32-bit data of the Xn registers.
All supported ABIs come with their 32-bit version except FFA_RXTX_MAP
which has 64-bit version supported.
Both 32-bit and 64-bit direct messaging are supported which allows both
32-bit and 64-bit clients to use the FF-A bus.
FF-A is a discoverable bus and similar to architecture features.
FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed
by the PSCI driver.
Clients are able to probe then use the FF-A bus by calling the DM class
searching APIs (e.g: uclass_first_device).
The Secure World is considered as one entity to communicate with
using the FF-A bus. FF-A communication is handled by one device and
one instance (the bus). This FF-A driver takes care of all the
interactions between Normal world and Secure World.
The driver exports its operations to be used by upper layers.
Exported operations:
- ffa_partition_info_get
- ffa_sync_send_receive
- ffa_rxtx_unmap
Generic FF-A methods are implemented in the Uclass (arm-ffa-uclass.c).
Arm specific methods are implemented in the Arm driver (arm-ffa.c).
For more details please refer to the driver documentation [2].
[1]: https://developer.arm.com/documentation/den0077/latest/
[2]: doc/arch/arm64.ffa.rst
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Reviewed-by: Ilias Apalodimas
Cc: Tom Rini
Cc: Jens Wiklander
Cc: Heinrich Schuchardt
---
Changelog:
===
v13:
* doc minor change: specify in the readme that the user
should call ffa_rxtx_unmap() driver operation to unmap
the RX/TX buffers on demand.
v12:
* remove dscvry_info
* replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn
(user drivers can override it)
* improve FFA_PARTITION_INFO_GET implementation
(clients no longer need to calloc a buffer)
* address nits
v11:
* move ffa_try_discovery() from the uclass to the Arm FF-A driver
* rename ffa_try_discovery() to arm_ffa_discover()
* pass dev as an argument of arm_ffa_discover()
* add arm_ prefix to the Arm FF-A driver functions
* add emul field in struct ffa_discovery_info
* address nits
v10:
* provide the driver operations through the Uclass
* move the generic FF-A methods to the Uclass
* keep Arm specific methods in the Arm driver (arm-ffa.c)
* rename core.c to arm-ffa.c
* address nits
v9:
* integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for
binding
v8:
* make ffa_get_partitions_info() second argument to be an SP count in both
modes
* update ffa_bus_prvdata_get() to return a pointer rather than a pointer
address
* remove packing from ffa_partition_info and ffa_send_direct_data structures
* pass the FF-A bus device to the bus operations
v7:
* add support for 32-bit direct messaging
* rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
* improve the declaration of error handling mapping
* stating in doc/arch/arm64.ffa.rst that EFI runtime is not supported
v6:
* drop use of EFI runtime support (We decided with Linaro to add this later)
* drop discovery from initcalls (discovery will be on demand by FF-A users)
* set the alignment of the RX/TX buffers to the larger translation granule size
* move FF-A RX/TX buffers unmapping at ExitBootServices() to a separate commit
* update the documentation and move it to doc/arch/arm64.ffa.rst
v4:
* add doc/README.ffa.drv
* moving the FF-A driver work to drivers/firmware/arm-ffa
* use less #ifdefs in lib/efi_loader/efi_boottime.c and replace
#if defined by #if CONFIG_IS_ENABLED
* improving error handling by mapping the FF-A errors to standard errors
and logs
* replacing panics with an error log and returning an error code
* improving features discovery in FFA_FEATURES by introducing
rxtx_min_pages private data field
* add ffa_remove and ffa_unbind functions
* improve how the driver behaves when bus discovery is done more than
once
v3:
* align the interfaces of the U-Boot FF-A driver with those in the linux
FF-A driver
* remove the FF-A helper layer
* make the U-Boot FF-A driver independent from EFI
* provide an optional config that enables copying the driver data to EFI
runtime section at ExitBootServices service
* use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
v2:
* make FF-A bus discoverable using device_{bind, probe} APIs
* remove device tree support
v1:
* introduce FF-A bus driver with device tree support
MAINTAINERS |8 +
doc/arch/arm64.ffa.rst
[PATCH v18 3/9] lib: uuid: introduce testcase for uuid_str_to_le_bin
provide a test case
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
---
Changelog:
===
v16:
* MAINTAINERS: place the UUID part in an alphabetical order
v11:
* use ut_asserteq_mem()
MAINTAINERS | 5 +
test/lib/Makefile | 1 +
test/lib/uuid.c | 41 +
3 files changed, 47 insertions(+)
create mode 100644 test/lib/uuid.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d724b64673..4324965d26 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1555,6 +1555,11 @@ T: git
https://source.denx.de/u-boot/custodians/u-boot-usb.git topic-xhci
F: drivers/usb/host/xhci*
F: include/usb/xhci.h
+UUID testing
+M: Abdellatif El Khlifi
+S: Maintained
+F: test/lib/uuid.c
+
VIDEO
M: Anatolij Gustschin
S: Maintained
diff --git a/test/lib/Makefile b/test/lib/Makefile
index e0bd9e04e8..e75a263e6a 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_AES) += test_aes.o
obj-$(CONFIG_GETOPT) += getopt.o
obj-$(CONFIG_CRC8) += test_crc8.o
obj-$(CONFIG_UT_LIB_CRYPT) += test_crypt.o
+obj-$(CONFIG_LIB_UUID) += uuid.o
else
obj-$(CONFIG_SANDBOX) += kconfig_spl.o
endif
diff --git a/test/lib/uuid.c b/test/lib/uuid.c
new file mode 100644
index 00..e24331a136
--- /dev/null
+++ b/test/lib/uuid.c
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Functional tests for UCLASS_FFA class
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* test UUID */
+#define TEST_SVC_UUID "ed32d533-4209-99e6-2d72-cdd998a79cc0"
+
+#define UUID_SIZE 16
+
+/* The UUID binary data (little-endian format) */
+static const u8 ref_uuid_bin[UUID_SIZE] = {
+ 0x33, 0xd5, 0x32, 0xed,
+ 0x09, 0x42, 0xe6, 0x99,
+ 0x72, 0x2d, 0xc0, 0x9c,
+ 0xa7, 0x98, 0xd9, 0xcd
+};
+
+static int lib_test_uuid_to_le(struct unit_test_state *uts)
+{
+ const char *uuid_str = TEST_SVC_UUID;
+ u8 ret_uuid_bin[UUID_SIZE] = {0};
+
+ ut_assertok(uuid_str_to_le_bin(uuid_str, ret_uuid_bin));
+ ut_asserteq_mem(ref_uuid_bin, ret_uuid_bin, UUID_SIZE);
+
+ return 0;
+}
+
+LIB_TEST(lib_test_uuid_to_le, 0);
--
2.25.1
[PATCH v18 2/9] lib: uuid: introduce uuid_str_to_le_bin function
convert UUID string to little endian binary data
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
---
Changelog:
===
v9:
* add a full function prototype description in uuid.h
v8:
* use simple_strtoull() in uuid_str_to_le_bin() to support 32-bit platforms
v7:
* rename be_uuid_str_to_le_bin() to uuid_str_to_le_bin()
* make uuid_str_to_le_bin() implementation similar to uuid_str_to_bin()
by using same APIs
v4:
* rename ffa_uuid_str_to_bin to be_uuid_str_to_le_bin and put in
a standalone commit (the current)
v3:
* introduce ffa_uuid_str_to_bin (provided by
arm_ffa: introduce Arm FF-A low-level driver)
include/uuid.h | 15 +++
lib/uuid.c | 48
2 files changed, 63 insertions(+)
diff --git a/include/uuid.h b/include/uuid.h
index 4a4883d3b5..89b93e642b 100644
--- a/include/uuid.h
+++ b/include/uuid.h
@@ -2,6 +2,10 @@
/*
* Copyright (C) 2014 Samsung Electronics
* Przemyslaw Marczak
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
*/
#ifndef __UUID_H__
#define __UUID_H__
@@ -44,4 +48,15 @@ int uuid_guid_get_bin(const char *guid_str, unsigned char
*guid_bin);
const char *uuid_guid_get_str(const unsigned char *guid_bin);
void gen_rand_uuid(unsigned char *uuid_bin);
void gen_rand_uuid_str(char *uuid_str, int str_format);
+
+/**
+ * uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
+ * @uuid_str: pointer to UUID string
+ * @uuid_bin: pointer to allocated array for little endian output [16B]
+ * Return:
+ *uuid_bin filled with little endian UUID data
+ *On success 0 is returned. Otherwise, failure code.
+ */
+int uuid_str_to_le_bin(const char *uuid_str, unsigned char *uuid_bin);
+
#endif
diff --git a/lib/uuid.c b/lib/uuid.c
index 96e1af3c8b..45f325d964 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -1,6 +1,10 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2011 Calxeda, Inc.
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
*/
#include
@@ -354,6 +358,50 @@ int uuid_str_to_bin(const char *uuid_str, unsigned char
*uuid_bin,
return 0;
}
+/**
+ * uuid_str_to_le_bin() - Convert string UUID to little endian binary data.
+ * @uuid_str: pointer to UUID string
+ * @uuid_bin: pointer to allocated array for little endian output [16B]
+ *
+ * UUID string is 36 characters (36 bytes):
+ *
+ * ----
+ *
+ * where x is a hexadecimal character. Fields are separated by '-'s.
+ * When converting to a little endian binary UUID, the string fields are
reversed.
+ *
+ * Return:
+ *
+ *uuid_bin filled with little endian UUID data
+ *On success 0 is returned. Otherwise, failure code.
+ */
+int uuid_str_to_le_bin(const char *uuid_str, unsigned char *uuid_bin)
+{
+ u16 tmp16;
+ u32 tmp32;
+ u64 tmp64;
+
+ if (!uuid_str_valid(uuid_str) || !uuid_bin)
+ return -EINVAL;
+
+ tmp32 = cpu_to_le32(hextoul(uuid_str, NULL));
+ memcpy(uuid_bin, , 4);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 9, NULL));
+ memcpy(uuid_bin + 4, , 2);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 14, NULL));
+ memcpy(uuid_bin + 6, , 2);
+
+ tmp16 = cpu_to_le16(hextoul(uuid_str + 19, NULL));
+ memcpy(uuid_bin + 8, , 2);
+
+ tmp64 = cpu_to_le64(simple_strtoull(uuid_str + 24, NULL, 16));
+ memcpy(uuid_bin + 10, , 6);
+
+ return 0;
+}
+
/*
* uuid_bin_to_str() - convert big endian binary data to string UUID or GUID.
*
--
2.25.1
[PATCH v18 1/9] arm64: smccc: add support for SMCCCv1.2 x0-x17 registers
add support for x0-x17 registers used by the SMC calls In SMCCC v1.2 [1] arguments are passed in registers x1-x17. Results are returned in x0-x17. This work is inspired from the following kernel commit: arm64: smccc: Add support for SMCCCv1.2 extended input/output registers [1]: https://documentation-service.arm.com/static/5f8edaeff86e16515cdbe4c6?token= Signed-off-by: Abdellatif El Khlifi Reviewed-by: Ilias Apalodimas Reviewed-by: Jens Wiklander Reviewed-by: Simon Glass Cc: Tom Rini --- Changelog: === v9: * update the copyright string v7: * improve indentation of ARM_SMCCC_1_2_REGS_Xn_OFFS v4: * rename the commit title and improve description new commit title: the current v3: * port x0-x17 registers support from linux kernel as defined by SMCCCv1.2 commit title: arm64: smccc: add Xn registers support used by SMC calls arch/arm/cpu/armv8/smccc-call.S | 57 - arch/arm/lib/asm-offsets.c | 16 + include/linux/arm-smccc.h | 45 ++ 3 files changed, 117 insertions(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv8/smccc-call.S b/arch/arm/cpu/armv8/smccc-call.S index dc92b28777..93f66d3366 100644 --- a/arch/arm/cpu/armv8/smccc-call.S +++ b/arch/arm/cpu/armv8/smccc-call.S @@ -1,7 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* * Copyright (c) 2015, Linaro Limited - */ + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi +*/ #include #include #include @@ -45,3 +49,54 @@ ENDPROC(__arm_smccc_smc) ENTRY(__arm_smccc_hvc) SMCCC hvc ENDPROC(__arm_smccc_hvc) + +#ifdef CONFIG_ARM64 + + .macro SMCCC_1_2 instr + /* Save `res` and free a GPR that won't be clobbered */ + stp x1, x19, [sp, #-16]! + + /* Ensure `args` won't be clobbered while loading regs in next step */ + mov x19, x0 + + /* Load the registers x0 - x17 from the struct arm_smccc_1_2_regs */ + ldp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] + ldp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] + ldp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] + ldp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] + ldp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] + ldp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] + ldp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] + ldp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] + ldp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] + + \instr #0 + + /* Load the `res` from the stack */ + ldr x19, [sp] + + /* Store the registers x0 - x17 into the result structure */ + stp x0, x1, [x19, #ARM_SMCCC_1_2_REGS_X0_OFFS] + stp x2, x3, [x19, #ARM_SMCCC_1_2_REGS_X2_OFFS] + stp x4, x5, [x19, #ARM_SMCCC_1_2_REGS_X4_OFFS] + stp x6, x7, [x19, #ARM_SMCCC_1_2_REGS_X6_OFFS] + stp x8, x9, [x19, #ARM_SMCCC_1_2_REGS_X8_OFFS] + stp x10, x11, [x19, #ARM_SMCCC_1_2_REGS_X10_OFFS] + stp x12, x13, [x19, #ARM_SMCCC_1_2_REGS_X12_OFFS] + stp x14, x15, [x19, #ARM_SMCCC_1_2_REGS_X14_OFFS] + stp x16, x17, [x19, #ARM_SMCCC_1_2_REGS_X16_OFFS] + + /* Restore original x19 */ + ldp xzr, x19, [sp], #16 + ret + .endm + +/* + * void arm_smccc_1_2_smc(const struct arm_smccc_1_2_regs *args, + * struct arm_smccc_1_2_regs *res); + */ +ENTRY(arm_smccc_1_2_smc) + SMCCC_1_2 smc +ENDPROC(arm_smccc_1_2_smc) + +#endif diff --git a/arch/arm/lib/asm-offsets.c b/arch/arm/lib/asm-offsets.c index 6de0ce9152..181a8ac4c2 100644 --- a/arch/arm/lib/asm-offsets.c +++ b/arch/arm/lib/asm-offsets.c @@ -9,6 +9,11 @@ * generate asm statements containing #defines, * compile this file to assembler, and then extract the * #defines from the assembly-language output. + * + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi */ #include @@ -90,6 +95,17 @@ int main(void) DEFINE(ARM_SMCCC_RES_X2_OFFS, offsetof(struct arm_smccc_res, a2)); DEFINE(ARM_SMCCC_QUIRK_ID_OFFS, offsetof(struct arm_smccc_quirk, id)); DEFINE(ARM_SMCCC_QUIRK_STATE_OFFS, offsetof(struct arm_smccc_quirk, state)); +#ifdef CONFIG_ARM64 + DEFINE(ARM_SMCCC_1_2_REGS_X0_OFFS, offsetof(struct arm_smccc_1_2_regs, a0)); + DEFINE(ARM_SMCCC_1_2_REGS_X2_OFFS, offsetof(struct arm_smccc_1_2_regs, a2)); + DEFINE(ARM_SMCCC_1_2_REGS_X4_OFFS, offsetof(struct arm_smccc_1_2_regs, a4)); + DEFINE(ARM_SMCCC_1_2_REGS_X6_OFFS, offsetof(struct arm_smccc_1_2_regs, a6)); + DEFINE(ARM_SMCCC_1_2_REGS_X8_OFFS, offsetof(struct arm_smccc_1_2_regs, a8)); + DEFINE(ARM_SMCCC_1_2_REGS_X10_OFFS, offsetof(struct arm_smccc_1_2_regs, a10)); + DEFINE(ARM_SMCCC_1_2_REGS_X12_OFFS, offsetof(struct arm_smccc_1_2_regs, a12)); +
[PATCH v18 0/9] introduce Arm FF-A support
Adding support for Arm FF-A v1.0 (Arm Firmware Framework for Armv8-A) [A]. FF-A specifies interfaces that enable a pair of software execution environments aka partitions to communicate with each other. A partition could be a VM in the Normal or Secure world, an application in S-EL0, or a Trusted OS in S-EL1. FF-A is a discoverable bus and similar to architecture features. FF-A bus is discovered using ARM_SMCCC_FEATURES mechanism performed by the PSCI driver. => dm tree Class Index Probed DriverName --- ... firmware 0 [ + ] psci |-- psci ffa 0 [ ] arm_ffa | `-- arm_ffa ... Clients are able to probe then use the FF-A bus by calling the DM class searching APIs (e.g: uclass_first_device). This implementation of the specification provides support for Aarch64. The FF-A driver uses the SMC ABIs defined by the FF-A specification to: - Discover the presence of secure partitions (SPs) of interest - Access an SP's service through communication protocols (e.g: EFI MM communication protocol) The FF-A support provides the following features: - Being generic by design and can be used by any Arm 64-bit platform - FF-A support can be compiled and used without EFI - Support for SMCCCv1.2 x0-x17 registers - Support for SMC32 calling convention - Support for 32-bit and 64-bit FF-A direct messaging - Support for FF-A MM communication (compatible with EFI boot time) - Enabling FF-A and MM communication in Corstone1000 platform as a use case - A Uclass driver providing generic FF-A methods. - An Arm FF-A device driver providing Arm-specific methods and reusing the Uclass methods. - A sandbox emulator for Arm FF-A, emulates the FF-A side of the Secure World and provides FF-A ABIs inspection methods. - An FF-A sandbox device driver for FF-A communication with the emulated Secure World. The driver leverages the FF-A Uclass to establish FF-A communication. - Sandbox FF-A test cases. - A new command called armffa is provided as an example of how to access the FF-A bus For more details about the FF-A support please refer to [B] and refer to [C] for how to use the armffa command. Please find at [D] an example of the expected boot logs when enabling FF-A support for a platform. In this example the platform is Corstone1000. But it can be any Arm 64-bit platform. Changelog of changes: === v18: Ilias, Tom: * drop the use of configs for the shared MM buffer, put back #ifdefs instead * add test information to the MM comms commit message v17: [17] Ilias: * show a debug message rather than an error when FF-A is not detected Tom: * use savedefconfig to generate corstone1000_defconfig with FF-A MM comms enabled v16: [16] Tom: * lib/efi_loader/Kconfig: rather than automatically selecting OPTEE and ARM_FFA_TRANSPORT configs by EFI_MM_COMM_TEE, set them as dependencies (Otherwise FF-A will be automatically enabled for boards that don't need it). * configs/corstone1000_defconfig: enable MM communication by setting the configs: ARM_FFA_TRANSPORT, OPTEE, TEE v15: [15] Simon: * drop commit "log: select physical address formatting in a generic way", this will be sent as a follow-up commit independently from this patchset * armffa.c : integrate PHYS_ADDR_LN * replace FFA_SHARED_MM_BUFFER_* defines with configs v14: [14] Simon: * add to log.h a generic physical address formatting Ilias: * armffa command: in do_ffa_ping() reject the SP ID if it's 0 * MM comms: drop truncating var_payload->size when using FF-A * MM comms: map the MM SP return codes to errnos * address nits v13: [13] Ilias: * remove FF-A and Optee ifdefs in efi_variable_tee.c * doc minor change: specify in the readme that the user should call ffa_rxtx_unmap() driver operation to unmap the RX/TX buffers on demand. v12: [12] * remove the global variable (dscvry_info), use uc_priv instead * replace dscvry_info.invoke_ffa_fn() with a weak invoke_ffa_fn (user drivers can override it) * improve FFA_PARTITION_INFO_GET implementation (clients no longer need to calloc a buffer) * remove reparenting by making the sandbox emulator parent of the FF-A device in the DT * improve argument checks for the armffa command * address nits v11: [11] * move ffa_try_discovery() from the uclass to the Arm FF-A driver * rename ffa_try_discovery() to arm_ffa_discover() * add arm_ prefix to the Arm FF-A driver functions * use U_BOOT_CMD_WITH_SUBCMDS for armffa command * store the sandbox emulator pointer in the FF-A device uc_priv (struct ffa_priv) * set the emulator as parent of the sandbox FF-A device * rename select_ffa_mm_comms() to select_mm_comms() * improve the logic of MM transport selection in mm_communicate() * use
Pull request efi-2023-10-rc2-2
Dear Tom, The following changes since commit 38dedebc547f795efc3daad17f7c013c515e1285: Merge https://source.denx.de/u-boot/custodians/u-boot-riscv (2023-08-02 12:13:16 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-10-rc2-2 for you to fetch changes up to cd87d2c61ce8e8e963de514f2c8ab0f959d6b586: efi_loader: check uuid_str_to_bin return value (2023-08-03 09:21:03 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17191 Pull request efi-2023-10-rc2-2 Documentation: * Move README.falcon to HTML * Describe usage of QEMU virtio block device * Add SPDX license identifiers to svg images * Add more detail to the description of U-Boot boot phases UEFI: * Fix buffer overflows * Fix memory leak in efi_add_memory_map_pg * Properly check return values of calloc, uuid_str_to_bin, efi_parse_pkcs7_header AKASHI Takahiro (1): efi_loader: capsule: enforce guid check in api and capsule_on_disk Bin Meng (1): dm: Correct DM_FLAG_ comment Dan Carpenter (2): efi_loader: Fix memory corruption on 32bit systems efi_loader: fix an IS_ERR() vs NULL check Heinrich Schuchardt (11): doc: U-Boot boot phases doc: move README.falcon to HTML doc: describe QEMU virtio block device efi_selftest: remove superfluous assignments efi_loader: out of memory in efi_add_memory_map_pg efi_loader: error handling in tcg2_hash_pe_image() efi_loader: overflow in efi_allocate_pages efi_loader: out of memory in efi_mem_carve_out efi_loader: memory leak efi_add_memory_map_pg efi_loader: error handling in efi_disk_add_dev efi_loader: catch out of memory in file_open Masahisa Kojima (1): efi_loader: check uuid_str_to_bin return value Nishanth Menon (1): doc: board: ti: Add SPDX License to svg images doc/README.falcon | 232 -- doc/board/emulation/blkdev.rst | 14 +- doc/board/ti/img/boot_diagram_am65.svg | 4 + doc/board/ti/img/boot_diagram_j721e.svg| 4 + doc/board/ti/img/boot_diagram_k3_current.svg | 4 + doc/board/ti/img/boot_flow_01.svg | 4 + doc/board/ti/img/boot_flow_02.svg | 4 + doc/board/ti/img/boot_flow_03.svg | 4 + doc/board/ti/img/dm_tispl.bin.svg | 4 + doc/board/ti/img/emmc_am65x_evm_boot0.svg | 4 + doc/board/ti/img/emmc_j7200_evm_boot01.svg | 4 + doc/board/ti/img/emmc_j7200_evm_udafs.svg | 4 + doc/board/ti/img/j7200_tiboot3.bin.svg | 4 + doc/board/ti/img/multi_cert_tiboot3.bin.svg| 4 + doc/board/ti/img/no_multi_cert_tiboot3.bin.svg | 4 + doc/board/ti/img/nodm_tispl.bin.svg| 4 + doc/board/ti/img/ospi_sysfw.svg| 4 + doc/board/ti/img/sysfw.itb.svg | 4 + doc/develop/falcon.rst | 258 + doc/develop/index.rst | 1 + doc/develop/spl.rst| 13 +- include/dm/device.h| 2 +- include/efi_loader.h | 18 +- lib/efi_loader/efi_capsule.c | 20 +- lib/efi_loader/efi_disk.c | 15 +- lib/efi_loader/efi_file.c | 14 +- lib/efi_loader/efi_firmware.c | 8 +- lib/efi_loader/efi_image_loader.c | 5 +- lib/efi_loader/efi_memory.c| 17 +- lib/efi_loader/efi_tcg2.c | 6 +- lib/efi_selftest/efi_selftest_hii.c| 11 -- 31 files changed, 416 insertions(+), 282 deletions(-) delete mode 100644 doc/README.falcon create mode 100644 doc/develop/falcon.rst
[PATCH] spl: remove duplicate SPL_MD5 option
There is another SPL_MD5 option defined in lib/Kconfig.
Renaming SPL_MD5_SUPPORT introduced duplicate option with
different description. As for now FIT and hash algorithm options
are not related to each others, removing a duplicate option seems OK.
Fixes: 4b00fd1a84c ("Kconfig: Rename SPL_MD5_SUPPORT to SPL_MD5")
Signed-off-by: Oleksandr Suvorov
---
common/spl/Kconfig | 12
1 file changed, 12 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index bee231b583a..c66d70e2a99 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -561,18 +561,6 @@ config SPL_CRC32
for detected accidental image corruption. For secure applications you
should consider SHA1 or SHA256.
-config SPL_MD5
- bool "Support MD5"
- depends on SPL_FIT
- help
- Enable this to support MD5 in FIT images within SPL. An MD5
- checksum is a 128-bit hash value used to check that the image
- contents have not been corrupted. Note that MD5 is not considered
- secure as it is possible (with a brute-force attack) to adjust the
- image while still retaining the same MD5 hash value. For secure
- applications where images may be changed maliciously, you should
- consider SHA256 or SHA384.
-
config SPL_FIT_IMAGE_TINY
bool "Remove functionality from SPL FIT loading to reduce size"
depends on SPL_FIT
--
2.40.1
Re: [PATCH v5 07/11] spl: Convert NVMe to spl_load
On 8/3/23 04:32, Xavier Drudis Ferran wrote:
> El Mon, Jul 31, 2023 at 06:42:59PM -0400, Sean Anderson deia:
>> This converts the blk load method (used exclusively by NVMe) to use
>> spl_load. As a consequence, it also adds support for LOAD_FIT_FULL and
>> IMX images.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v5:
>> - New
>>
>> common/spl/spl_blk_fs.c | 68 -
>> 1 file changed, 12 insertions(+), 56 deletions(-)
>>
>> diff --git a/common/spl/spl_blk_fs.c b/common/spl/spl_blk_fs.c
>> index d97adc4d39..eb5775a470 100644
>> --- a/common/spl/spl_blk_fs.c
>> +++ b/common/spl/spl_blk_fs.c
>> @@ -45,24 +45,28 @@ int spl_blk_load_image(struct spl_image_info *spl_image,
>> {
>> const char *filename = CONFIG_SPL_PAYLOAD;
>> struct disk_partition part_info = {};
>> -struct legacy_img_hdr *header;
>> struct blk_desc *blk_desc;
>> -loff_t actlen, filesize;
>> +loff_t filesize;
>> struct blk_dev dev;
>> int ret;
>> +struct spl_load_info load = {
>> +.read = spl_fit_read,
>> +.bl_len = 1,
>> +.filename = filename,
>> +.priv = ,
>> +};
>>
>> blk_desc = blk_get_devnum_by_uclass_id(uclass_id, devnum);
>> if (!blk_desc) {
>> printf("blk desc for %d %d not found\n", uclass_id, devnum);
>> -goto out;
>> +return ret;
>
> What do you mean return ret ?
> ret is unused yet ?
> maybe return -1 or return -ENODEV or something ?
>
> I think the error was already there before your patch, but maybe worth
> fixing ?
Yes.
--Sean
>> }
>>
>> blk_show_device(uclass_id, devnum);
>> -header = spl_get_load_buffer(-sizeof(*header), sizeof(*header));
>> ret = part_get_info(blk_desc, 1, _info);
>> if (ret) {
>> printf("spl: no partition table found. Err - %d\n", ret);
>> -goto out;
>> +return ret;
>> }
>>
>> dev.ifname = blk_get_uclass_name(uclass_id);
>> @@ -72,63 +76,15 @@ int spl_blk_load_image(struct spl_image_info *spl_image,
>> if (ret) {
>> printf("spl: unable to set blk_dev %s %s. Err - %d\n",
>> dev.ifname, dev.dev_part_str, ret);
>> -goto out;
>> -}
>> -
>> -ret = fs_read(filename, (ulong)header, 0,
>> - sizeof(struct legacy_img_hdr), );
>> -if (ret) {
>> -printf("spl: unable to read file %s. Err - %d\n", filename,
>> - ret);
>> -goto out;
>> -}
>> -
>> -if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
>> -image_get_magic(header) == FDT_MAGIC) {
>> -struct spl_load_info load;
>> -
>> -debug("Found FIT\n");
>> -load.read = spl_fit_read;
>> -load.bl_len = 1;
>> -load.filename = (void *)filename;
>> -load.priv =
>> -
>> -return spl_load_simple_fit(spl_image, , 0, header);
>> -}
>> -
>> -ret = spl_parse_image_header(spl_image, bootdev, header);
>> -if (ret) {
>> -printf("spl: unable to parse image header. Err - %d\n",
>> - ret);
>> -goto out;
>> -}
>> -
>> -ret = fs_set_blk_dev(dev.ifname, dev.dev_part_str, FS_TYPE_ANY);
>> -if (ret) {
>> -printf("spl: unable to set blk_dev %s %s. Err - %d\n",
>> - dev.ifname, dev.dev_part_str, ret);
>> -goto out;
>> +return ret;
>> }
>>
>> ret = fs_size(filename, );
>> if (ret) {
>> printf("spl: unable to get file size: %s. Err - %d\n",
>> filename, ret);
>> -goto out;
>> +return ret;
>> }
>>
>> -ret = fs_set_blk_dev(dev.ifname, dev.dev_part_str, FS_TYPE_ANY);
>> -if (ret) {
>> -printf("spl: unable to set blk_dev %s %s. Err - %d\n",
>> - dev.ifname, dev.dev_part_str, ret);
>> -goto out;
>> -}
>> -
>> -ret = fs_read(filename, (ulong)spl_image->load_addr, 0, filesize,
>> - );
>> -if (ret)
>> -printf("spl: unable to read file %s. Err - %d\n",
>> - filename, ret);
>> -out:
>> -return ret;
>> +return spl_load(spl_image, bootdev, , filesize, 0);
>> }
>> --
>> 2.40.1
>>
Re: [PATCH v5 08/11] spl: Convert nor to spl_load
On 8/3/23 04:33, Xavier Drudis Ferran wrote:
> El Mon, Jul 31, 2023 at 06:43:00PM -0400, Sean Anderson deia:
>> This converts the nor load method to use spl_load. As a result it also
>> adds support for LOAD_FIT_FULL.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v5:
>> - Rework to load header in spl_load
>>
>> common/spl/spl_nor.c | 41 +++--
>> 1 file changed, 7 insertions(+), 34 deletions(-)
>>
>> diff --git a/common/spl/spl_nor.c b/common/spl/spl_nor.c
>> index 5b65b96a77..7328a87024 100644
>> --- a/common/spl/spl_nor.c
>> +++ b/common/spl/spl_nor.c
>> @@ -26,8 +26,10 @@ unsigned long __weak spl_nor_get_uboot_base(void)
>> static int spl_nor_load_image(struct spl_image_info *spl_image,
>>struct spl_boot_device *bootdev)
>> {
>> -__maybe_unused const struct legacy_img_hdr *header;
>> -__maybe_unused struct spl_load_info load;
>> +struct spl_load_info load = {
>> +.bl_len = 1,
>> +.read = spl_nor_load_read,
>> +};
>>
>> /*
>> * Loading of the payload to SDRAM is done with skipping of
>> @@ -41,7 +43,8 @@ static int spl_nor_load_image(struct spl_image_info
>> *spl_image,
>> * Load Linux from its location in NOR flash to its defined
>> * location in SDRAM
>> */
>> -header = (const struct legacy_img_hdr *)CONFIG_SYS_OS_BASE;
>> +const struct legacy_img_hdr *header =
>> +(const struct legacy_img_hdr *)CONFIG_SYS_OS_BASE;
>> #ifdef CONFIG_SPL_LOAD_FIT
>> if (image_get_magic(header) == FDT_MAGIC) {
>> int ret;
>> @@ -91,36 +94,6 @@ static int spl_nor_load_image(struct spl_image_info
>> *spl_image,
>> * Load real U-Boot from its location in NOR flash to its
>> * defined location in SDRAM
>> */
>> -#ifdef CONFIG_SPL_LOAD_FIT
>> -header = (const struct legacy_img_hdr *)spl_nor_get_uboot_base();
>> -if (image_get_magic(header) == FDT_MAGIC) {
>> -debug("Found FIT format U-Boot\n");
>> -load.bl_len = 1;
>> -load.read = spl_nor_load_read;
>> -return spl_load_simple_fit(spl_image, ,
>> - spl_nor_get_uboot_base(),
>> - (void *)header);
>
> this loaded the simple fit from sector=CFG_SYS_UBOOT_BASE and now we'll
> call spl_load with sector=0 ?
>
> But spl_nor_get_uboot_base() is overriden by calculations of
> concatenated images in
>
> arch/arm/mach-imx/image-container.c
> arch/mips/mach-mtmips/mt7621/spl/spl.c
> arch/mips/mach-mtmips/spl.c
>
>> -}
>> -#endif
>> -if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
>> -load.bl_len = 1;
>> -load.read = spl_nor_load_read;
>> -return spl_load_imx_container(spl_image, ,
>> - spl_nor_get_uboot_base());
>
> this loaded the imx image from sector=CFG_SYS_UBOOT_BASE or whatever
> spl_nor_get_uboot_base() gave and now we'll call spl_load with
> sector=0 ?
>
>> -}
>> -
>> -/* Legacy image handling */
>> -if (IS_ENABLED(CONFIG_SPL_LEGACY_IMAGE_FORMAT)) {
>> -struct legacy_img_hdr hdr;
>> -
>> -load.bl_len = 1;
>> -load.read = spl_nor_load_read;
>> -spl_nor_load_read(, spl_nor_get_uboot_base(), sizeof(hdr),
>> );
>> -return spl_load_legacy_img(spl_image, bootdev, ,
>> - spl_nor_get_uboot_base(),
>> - );
>
> This loaded legacy image with potential lzma decompression and now
> compressed images are no longer supported ?
>
>> -}
>> -
>> -return -EINVAL;
>> +return spl_load(spl_image, bootdev, , 0, 0);
>
> maybe better
>
> + return spl_load(spl_image, bootdev, , 0, spl_nor_get_uboot_base());
>
>
> and consider calling spl_load_legacy_img(spl_image, bootdev, , offset,
> header)
> from spl_load()?
Yeah, I noticed both of these issues when Tom sent the size difference.
I'm going to address these in v6. Ideally, I will incorporate the LZMA
code into spl_load.
--Sean
>> }
>> SPL_LOAD_IMAGE_METHOD("NOR", 0, BOOT_DEVICE_NOR, spl_nor_load_image);
>> --
>> 2.40.1
>>
Re: [PATCH v5 09/11] spl: Convert semihosting to spl_load
On 8/3/23 04:36, Xavier Drudis Ferran wrote:
> El Mon, Jul 31, 2023 at 06:43:01PM -0400, Sean Anderson deia:
>> This converts the semihosting load method to use spl_load. As a result, it
>> also adds support for LOAD_FIT_FULL and IMX images.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Changes in v5:
>> - Rework to load header in spl_load
>>
>> Changes in v2:
>> - New
>>
>> common/spl/spl_semihosting.c | 43
>> 1 file changed, 14 insertions(+), 29 deletions(-)
>>
>> diff --git a/common/spl/spl_semihosting.c b/common/spl/spl_semihosting.c
>> index 5b5e842a11..e7cb9f4ce6 100644
>> --- a/common/spl/spl_semihosting.c
>> +++ b/common/spl/spl_semihosting.c
>> @@ -9,16 +9,16 @@
>> #include
>> #include
>>
>> -static int smh_read_full(long fd, void *memp, size_t len)
>> +static ulong spl_smh_fit_read(struct spl_load_info *load, ulong sector,
>> + ulong count, void *buf)
>> {
>> -long read;
>> +int ret, fd = *(int *)load->priv;
>>
>
> should ret be long to hold smh_read() return value ?
Yes.
>> -read = smh_read(fd, memp, len);
>> -if (read < 0)
>> -return read;
>> -if (read != len)
>> -return -EIO;
>> -return 0;
>> +if (smh_seek(fd, sector))
>> +return 0;
>> +
>
>
>
> I never used smh, but why would this not be :
>
> + ret = smh_seek(fd, sector);
> + if (ret)
> + return ret;
Because we always return the number of bytes read. So by returning 0 we
signal an error.
> (why does smh_seek(), smh_write(), smh_open(), smh_close() return
> long, by the way? the implementations return either 0 or smh_errno(),
> so int would do ?)
Only smh_seek/smh_close always returns 0 or smh_errno. The rest return
values from smh_trap. The reason why we use long instead of int is that
the semihosting ABI always uses native-register-sized values (aka long).
We could use int instead of long for those two functions, but I don't
think its very critical.
--Sean
>> +ret = smh_read(fd, buf, count);
>> +return ret < 0 ? 0 : ret;
>> }
>>
>> static int spl_smh_load_image(struct spl_image_info *spl_image,
>> @@ -27,14 +27,17 @@ static int spl_smh_load_image(struct spl_image_info
>> *spl_image,
>> const char *filename = CONFIG_SPL_FS_LOAD_PAYLOAD_NAME;
>> int ret;
>> long fd, len;
>> -struct legacy_img_hdr *header =
>> -spl_get_load_buffer(-sizeof(*header), sizeof(*header));
>> +struct spl_load_info load = {
>> +.bl_len = 1,
>> +.read = spl_smh_fit_read,
>> +};
>>
>> fd = smh_open(filename, MODE_READ | MODE_BINARY);
>> if (fd < 0) {
>> log_debug("could not open %s: %ld\n", filename, fd);
>> return fd;
>> }
>> +load.priv =
>>
>> ret = smh_flen(fd);
>> if (ret < 0) {
>> @@ -43,25 +46,7 @@ static int spl_smh_load_image(struct spl_image_info
>> *spl_image,
>> }
>> len = ret;
>>
>> -ret = smh_read_full(fd, header, sizeof(struct legacy_img_hdr));
>> -if (ret) {
>> -log_debug("could not read image header: %d\n", ret);
>> -goto out;
>> -}
>> -
>> -ret = spl_parse_image_header(spl_image, bootdev, header);
>> -if (ret) {
>> -log_debug("failed to parse image header: %d\n", ret);
>> -goto out;
>> -}
>> -
>> -ret = smh_seek(fd, 0);
>> -if (ret) {
>> -log_debug("could not seek to start of image: %d\n", ret);
>> -goto out;
>> -}
>> -
>> -ret = smh_read_full(fd, (void *)spl_image->load_addr, len);
>> +ret = spl_load(spl_image, bootdev, , len, 0);
>> if (ret)
>> log_debug("could not read %s: %d\n", filename, ret);
>> out:
>> --
>> 2.40.1
>>
Re: [PATCHv5 07/13] net/lwip: implement ping cmd
On Thu, 3 Aug 2023 at 15:32, Ilias Apalodimas
wrote:
> On Wed, Aug 02, 2023 at 08:06:52PM +0600, Maxim Uvarov wrote:
> > Signed-off-by: Maxim Uvarov
> > ---
> > lib/lwip/Makefile | 1 +
> > lib/lwip/apps/ping/Makefile| 11 ++
> > lib/lwip/apps/ping/lwip_ping.c | 37 ++
> > lib/lwip/apps/ping/lwip_ping.h | 24 ++
> > lib/lwip/apps/ping/ping.h | 35
> > 5 files changed, 108 insertions(+)
> > create mode 100644 lib/lwip/apps/ping/Makefile
> > create mode 100644 lib/lwip/apps/ping/lwip_ping.c
> > create mode 100644 lib/lwip/apps/ping/lwip_ping.h
> > create mode 100644 lib/lwip/apps/ping/ping.h
> >
> > diff --git a/lib/lwip/Makefile b/lib/lwip/Makefile
> > index ec6b728c8e..87ed99a230 100644
> > --- a/lib/lwip/Makefile
> > +++ b/lib/lwip/Makefile
> > @@ -67,5 +67,6 @@ obj-$(CONFIG_NET) += port/sys-arch.o
> >
> > obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
> > obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
> > +obj-$(CONFIG_CMD_PING) += apps/ping/
> > obj-$(CONFIG_CMD_TFTPBOOT) += apps/tftp/
> > obj-$(CONFIG_CMD_WGET) += apps/http/
> > diff --git a/lib/lwip/apps/ping/Makefile b/lib/lwip/apps/ping/Makefile
> > new file mode 100644
> > index 00..0d0a811336
> > --- /dev/null
> > +++ b/lib/lwip/apps/ping/Makefile
> > @@ -0,0 +1,11 @@
> > +ccflags-y += -I$(srctree)/lib/lwip/port/include
> > +ccflags-y += -I$(srctree)/lib/lwip/lwip-external/src/include
> -I$(srctree)/lib/lwip
> > +ccflags-y += -I$(obj)
> > +
> > +.PHONY: $(obj)/ping.c
> > +$(obj)/ping.o: $(obj)/ping.c
> > +$(obj)/ping.c:
> > + cp $(srctree)/lib/lwip/lwip-external/contrib/apps/ping/ping.c
> $(obj)/ping.c
> > +
> > +obj-$(CONFIG_CMD_PING) += ping.o
> > +obj-$(CONFIG_CMD_PING) += lwip_ping.o
> > diff --git a/lib/lwip/apps/ping/lwip_ping.c
> b/lib/lwip/apps/ping/lwip_ping.c
> > new file mode 100644
> > index 00..40658ab6fd
> > --- /dev/null
> > +++ b/lib/lwip/apps/ping/lwip_ping.c
> > @@ -0,0 +1,37 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * (C) Copyright 2023 Linaro Ltd.
> > + */
> > +
> > +#include "lwip/opt.h"
> > +#include "lwip/ip_addr.h"
> > +#include "ping.h"
> > +
> > +#include
> > +
> > +static ip_addr_t ip_target;
> > +
> > +static int ulwip_ping_tmo(void)
> > +{
> > +
> > + printf("ping failed; host %s is not alive\n",
> ipaddr_ntoa(_target));
> > + return 0;
>
> Shouldnt this return != 0?
Yes.
> Also why do we need this? Looking at
> ping_raw_init() it ets timeout and print fail messages
>
> No, it doesn't print error messages. And I wanted to print exactly the
same message as the original ping does to pass validation tests.
=> lwip ping 1.1.1.1
Using virtio-net#30 device
pinging addr: 1.1.1.1
ping failed; host 1.1.1.1 is not alive
=>
> > +}
> > +
> > +int lwip_ping_init(char *ping_addr)
> > +{
> > + int err;
> > +
> > + err = ipaddr_aton(ping_addr, _target);
> > + if (err == 0) {
> > + printf("wrong ping addr string \"%s\" \n", ping_addr);
> > + return -1;
> > + }
> > +
> > + ulwip_set_tmo(ulwip_ping_tmo);
> > +
> > + ping_init(_target);
> > +
> > + return 0;
> > +}
> > diff --git a/lib/lwip/apps/ping/lwip_ping.h
> b/lib/lwip/apps/ping/lwip_ping.h
> > new file mode 100644
> > index 00..7f08095427
> > --- /dev/null
> > +++ b/lib/lwip/apps/ping/lwip_ping.h
> > @@ -0,0 +1,24 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +
> > +/*
> > + * (C) Copyright 2023 Linaro Ltd.
> > + */
> > +
> > +#ifndef LWIP_PING_H
> > +#define LWIP_PING_H
> > +
> > +#include
> > +
> > +/**
> > + * PING_USE_SOCKETS: Set to 1 to use sockets, otherwise the raw api is
> used
> > + */
>
> Is there any support for sockets in the current series? IOW if someome sets
> this to 1 will it work? If not get rid of it completely
>
>
Thanks, get rid of it completely. Btw sockets can be implemented, maybe we
will enable them later.
> > +#ifndef PING_USE_SOCKETS
> > +#define PING_USE_SOCKETS 0
> > +#endif
> > +
> > +int lwip_ping_init(char *ping_addr);
> > +
> > +void ping_raw_init(void);
> > +void ping_send_now(void);
> > +
> > +#endif /* LWIP_PING_H */
> > diff --git a/lib/lwip/apps/ping/ping.h b/lib/lwip/apps/ping/ping.h
> > new file mode 100644
> > index 00..0dd4bd78c7
> > --- /dev/null
> > +++ b/lib/lwip/apps/ping/ping.h
> > @@ -0,0 +1,35 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#include "../../../lwip/ulwip.h"
>
> Again, find a away to include this normally, without all the ../../
> uglyness
>
>
yea, fixed everywhere now.
> > +
> > +#include "lwip/prot/ip4.h"
> > +
> > +#define ip4_print_parts(a, b, c, d) \
> > + printf("%" U16_F ".%" U16_F ".%" U16_F ".%" U16_F, a, b, c, d);
> > +
> > +#define ip4_print(ipaddr) \
> > + ip4_print_parts(\
> > + (u16_t)((ipaddr) != NULL ? ip4_addr1_16(ipaddr) :
> 0), \
> > + (u16_t)((ipaddr) != NULL ?
[PATCH v3] imx: syscounter: allow timer_init for SPL build
From: Michael Scott
With enabled SKIP_LOWLEVEL_INIT, the weak function timer_init() is
used in the SPL build. For iMX6 SoC, this leads MMC to fail once
u-boot proper is booted due to a timing issue.
Always use iMX-specific timer_init() in SPL to fix timing issues.
Fixes: be277c3a89 ("imx: mx7: avoid some initialization if low level is
skipped")
Signed-off-by: Michael Scott
Co-developed-by: Oleksandr Suvorov
Signed-off-by: Oleksandr Suvorov
Reviewed-by: Peng Fan
---
Changes in v3:
- add Reviewed-by from
https://patchwork.ozlabs.org/project/uboot/patch/20210925151812.58480-1-oleksandr.suvo...@foundries.io/
Changes in v2:
- rebased on top of a2ac2b964b ("Convert CONFIG_SKIP_LOWLEVEL_INIT et al to
Kconfig")
arch/arm/mach-imx/syscounter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/syscounter.c b/arch/arm/mach-imx/syscounter.c
index 129efac6fa6..16df1186759 100644
--- a/arch/arm/mach-imx/syscounter.c
+++ b/arch/arm/mach-imx/syscounter.c
@@ -59,7 +59,7 @@ static inline unsigned long long us_to_tick(unsigned long
long usec)
return usec;
}
-#if !CONFIG_IS_ENABLED(SKIP_LOWLEVEL_INIT)
+#if !CONFIG_IS_ENABLED(SKIP_LOWLEVEL_INIT) || IS_ENABLED(CONFIG_SPL_BUILD)
int timer_init(void)
{
struct sctr_regs *sctr = (struct sctr_regs *)SCTR_BASE_ADDR;
--
2.40.1
[PATCH v4 3/3] binman: etype: Add xilinx-bootgen etype
From: Lukas Funke
This adds a new etype 'xilinx-bootgen'. By using this etype it is
possible to created an signed SPL (FSBL in Xilinx terms) for
ZynqMP boards.
The etype uses Xilinx Bootgen tools in order to transform the SPL into
a bootable image and sign the image with a given primary and secondary
public key. For more information to signing the FSBL please refer to the
Xilinx Bootgen documentation.
Here is an example of the etype in use:
spl {
filename = "boot.signed.bin";
xilinx-bootgen {
pmufw-filename = "pmu-firmware.elf";
psk-key-name-hint = "psk0";
ssk-key-name-hint = "ssk0";
auth-params = "ppk_select=0", "spk_id=0x";
u-boot-spl-nodtb {
};
u-boot-spl-dtb {
};
};
};
For this to work the hash of the primary public key has to be fused
into the ZynqMP device and authentication (RSA_EN) has to be set.
For testing purposes: if ppk hash check should be skipped one can add
the property 'fsbl_config = "bh_auth_enable";' to the etype. However,
this should only be used for testing(!).
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
Changes in v4:
- Renamed etype from "xilinx-fsbl-auth" to "xilinx-bootgen"
- Add detection of missing bintool
- Promote 'pmufw-filename' to required property
Changes in v3:
- Changed etype from entry to section
- Changed property name "psk-filename" to "psk-key-name-hint"
- Changed property name "ssk-filename" to "ssk-key-name-hint"
- Decode spl elf file instead of reading start symbol
- Improved test coverage
- Improved documentation
Changes in v2:
- Add 'keysrc-enc' property to pass down to Bootgen
- Improved documentation
- Use predictable output names for intermediated results
tools/binman/entries.rst | 75 +
tools/binman/etype/xilinx_bootgen.py | 225 +++
2 files changed, 300 insertions(+)
create mode 100644 tools/binman/etype/xilinx_bootgen.py
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index f2376932be..e7dfe6b2a3 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -2667,3 +2667,78 @@ may be used instead.
+.. _etype_xilinx_bootgen:
+
+Entry: xilinx-bootgen: Signed SPL boot image for Xilinx ZynqMP devices
+--
+
+Properties / Entry arguments:
+- auth-params: (Optional) Authentication parameters passed to bootgen
+- fsbl-config: (Optional) FSBL parameters passed to bootgen
+- keysrc-enc: (Optional) Key source when using decryption engine
+- pmufw-filename: Filename of PMU firmware. Default: pmu-firmware.elf
+- psk-key-name-hint: Name of primary secret key to use for signing the
+ secondardy public key. Format: .pem file
+- ssk-key-name-hint: Name of secondardy secret key to use for signing
+ the boot image. Format: .pem file
+
+The etype is used to create a boot image for Xilinx ZynqMP
+devices.
+
+Information for signed images:
+
+In AMD/Xilinx SoCs, two pairs of public and secret keys are used
+- primary and secondary. The function of the primary public/secret key pair
+is to authenticate the secondary public/secret key pair.
+The function of the secondary key is to sign/verify the boot image. [1]
+
+AMD/Xilinx uses the following terms for private/public keys [1]:
+
+PSK = Primary Secret Key (Used to sign Secondary Public Key)
+PPK = Primary Public Key (Used to verify Secondary Public Key)
+SSK = Secondary Secret Key (Used to sign the boot image/partitions)
+SPK = Used to verify the actual boot image
+
+The following example builds a signed boot image. The fuses of
+the primary public key (ppk) should be fused together with the RSA_EN flag.
+
+Example node::
+
+spl {
+filename = "boot.signed.bin";
+
+xilinx-bootgen {
+psk-key-name-hint = "psk0";
+ssk-key-name-hint = "ssk0";
+auth-params = "ppk_select=0", "spk_id=0x";
+
+u-boot-spl-nodtb {
+};
+u-boot-spl-pubkey-dtb {
+algo = "sha384,rsa4096";
+required = "conf";
+key-name-hint = "dev";
+};
+};
+};
+
+For testing purposes, e.g. if no RSA_EN should be fused, one could add
+the "bh_auth_enable" flag in the fsbl-config field. This will skip the
+verification of the ppk fuses and boot the image, even if ppk hash is
+invalid.
+
+Example node::
+
+xilinx-bootgen {
+psk-key-name-hint = "psk0";
+psk-key-name-hint = "ssk0";
+...
+fsbl-config = "bh_auth_enable";
+...
+};
+
+[1]
https://docs.xilinx.com/r/en-US/ug1283-bootgen-user-guide/Using-Authentication
+
+
+
+
diff --git a/tools/binman/etype/xilinx_bootgen.py
b/tools/binman/etype/xilinx_bootgen.py
new file mode 100644
index 00..70a4b2e242
--- /dev/null
[PATCH v4 1/3] binman: btool: Add Xilinx Bootgen btool
From: Lukas Funke Add the Xilinx Bootgen as bintool. Xilinx Bootgen is used to create bootable SPL (FSBL in Xilinx terms) images for Zynq/ZynqMP devices. The btool creates a signed version of the SPL. Additionally to signing the key source for the decryption engine can be passend to the boot image. Signed-off-by: Lukas Funke --- Changes in v4: - Fixed some typos Changes in v3: - Fixed an issue where the build result was not found - Fixed an issue where the version string was not reported correctly Changes in v2: - Pass additional 'keysrc_enc' parameter to Bootgen - Added more information and terms to documentation tools/binman/bintools.rst | 2 +- tools/binman/btool/bootgen.py | 137 ++ 2 files changed, 138 insertions(+), 1 deletion(-) create mode 100644 tools/binman/btool/bootgen.py diff --git a/tools/binman/bintools.rst b/tools/binman/bintools.rst index 20ee24395a..1336f4d011 100644 --- a/tools/binman/bintools.rst +++ b/tools/binman/bintools.rst @@ -208,7 +208,7 @@ Using `fdt_add_pubkey` the key can be injected to the SPL independent of Bintool: bootgen: Sign ZynqMP FSBL image -- + This bintool supports running `bootgen` in order to sign a SPL for ZynqMP devices. diff --git a/tools/binman/btool/bootgen.py b/tools/binman/btool/bootgen.py new file mode 100644 index 00..f2ca552dc2 --- /dev/null +++ b/tools/binman/btool/bootgen.py @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2023 Weidmüller Interface GmbH & Co. KG +# Lukas Funke +# +"""Bintool implementation for bootgen + +bootgen allows creating bootable SPL for Zynq(MP) + +Documentation is available via: +https://www.xilinx.com/support/documents/sw_manuals/xilinx2022_1/ug1283-bootgen-user-guide.pdf + +Source code is available at: +https://github.com/Xilinx/bootgen + +""" + +from binman import bintool +from u_boot_pylib import tools + +# pylint: disable=C0103 +class Bintoolbootgen(bintool.Bintool): +"""Generate bootable fsbl image for zynq/zynqmp + +This bintools supports running Xilinx "bootgen" in order +to generate a bootable, authenticated image form an SPL. + +""" +def __init__(self, name): +super().__init__(name, 'Xilinx Bootgen', + version_regex=r'^\*\*\*\*\*\* *Xilinx Bootgen *(.*)', + version_args='-help') + +# pylint: disable=R0913 +def sign(self, arch, spl_elf_fname, pmufw_elf_fname, + psk_fname, ssk_fname, fsbl_config, auth_params, keysrc_enc, + output_fname): +"""Sign SPL elf file and bundle it with PMU firmware into an image + +The method bundels the SPL together with a 'Platform Management Unit' +(PMU)[1] firmware into a single bootable image. The image in turn is +signed with the provided 'secondary secret key' (ssk), which in turn is +signed with the 'primary secret key' (psk). In order to verify the +authenticity of the ppk, it's hash has to be fused into the device +itself. + +In Xilinx terms the SPL is usually called 'FSBL' +(First Stage Boot Loader). The jobs of the SPL and the FSBL are mostly +the same: load bitstream, bootstrap u-boot. + +Args: +arch (str): Xilinx SoC architecture. Currently only 'zynqmp' is +supported. +spl_elf_fname (str): Filename of SPL ELF file. The filename must end +with '.elf' in order for bootgen to recognized it as an ELF +file. Otherwise the start address field is missinterpreted. +pmufw_elf_fname (str): Filename PMU ELF firmware. +psk_fname (str): Filename of the primary secret key (psk). The psk +is a .pem file which holds the RSA private key used for signing +the secondary secret key. +ssk_fname (str): Filename of the secondary secret key. The ssk +is a .pem file which holds the RSA private key used for signing +the actual boot firmware. +fsbl_config (str): FSBL config options. A string list of fsbl config +options. Valid values according to [2] are: +"bh_auth_enable": Boot Header Authentication Enable: RSA +authentication of the bootimage is done +excluding the verification of PPK hash and SPK ID. This is +useful for debugging before bricking a device. +"auth_only": Boot image is only RSA signed. FSBL should not be +decrypted. See the +Zynq UltraScale+ Device Technical Reference Manual (UG1085) +for more information. +There are more options which relate to PUF (physical unclonable +functions). Please refer to Xilinx manuals for further info. +
[PATCH v4 2/3] binman: ftest: Add test for xilinx-bootgen etype
From: Lukas Funke
Add test for the 'xilinx-bootgen' etype
Signed-off-by: Lukas Funke
Reviewed-by: Simon Glass
---
Changes in v4:
- Add test to check for missing bootgen tool
Changes in v3:
- Improved test coverage for xilinx-fsbl-auth etype
Changes in v2:
- Fixed typo in dts name
tools/binman/ftest.py | 75 +++
tools/binman/test/307_xilinx_bootgen_sign.dts | 22 ++
.../test/308_xilinx_bootgen_sign_enc.dts | 24 ++
3 files changed, 121 insertions(+)
create mode 100644 tools/binman/test/307_xilinx_bootgen_sign.dts
create mode 100644 tools/binman/test/308_xilinx_bootgen_sign_enc.dts
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 36428ec343..2d541c32b9 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -7139,5 +7139,80 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
self.assertEqual(fdt_util.GetString(key_node, "key-name-hint"),
"key")
+def testXilinxBootgenSigning(self):
+"""Test xilinx-bootgen etype"""
+data = tools.read_file(self.TestFile("key.key"))
+self._MakeInputFile("psk.pem", data)
+self._MakeInputFile("ssk.pem", data)
+self._SetupPmuFwlElf()
+self._SetupSplElf()
+self._DoReadFileRealDtb('307_xilinx_bootgen_sign.dts')
+image_fname = tools.get_output_filename('image.bin')
+bootgen = bintool.Bintool.create('bootgen')
+
+# Read partition header table and check if authentication is enabled
+bootgen_out = bootgen.run_cmd("-arch", "zynqmp",
+ "-read", image_fname, "pht").splitlines()
+attributes = {"authentication": None,
+ "core": None,
+ "encryption": None}
+
+for l in bootgen_out:
+for a in attributes.keys():
+if a in l:
+ m = re.match(fr".*{a} \[([^]]+)\]", l)
+ attributes[a] = m.group(1)
+
+self.assertTrue(attributes['authentication'] == "rsa")
+self.assertTrue(attributes['core'] == "a53-0")
+self.assertTrue(attributes['encryption'] == "no")
+
+def testXilinxBootgenSigningEncryption(self):
+"""Test xilinx-bootgen etype"""
+data = tools.read_file(self.TestFile("key.key"))
+self._MakeInputFile("psk.pem", data)
+self._MakeInputFile("ssk.pem", data)
+self._SetupPmuFwlElf()
+self._SetupSplElf()
+self._DoReadFileRealDtb('308_xilinx_bootgen_sign_enc.dts')
+image_fname = tools.get_output_filename('image.bin')
+bootgen = bintool.Bintool.create('bootgen')
+
+# Read boot header in order to verify encryption source and
+# encryption parameter
+bootgen_out = bootgen.run_cmd("-arch", "zynqmp",
+ "-read", image_fname, "bh").splitlines()
+attributes = {"auth_only":
+{"re": r".*auth_only \[([^]]+)\]", "value": None},
+ "encryption_keystore":
+{"re": r" *encryption_keystore \(0x28\) : (.*)",
+"value": None},
+ }
+
+for l in bootgen_out:
+for a in attributes.keys():
+if a in l:
+ m = re.match(attributes[a]['re'], l)
+ attributes[a] = m.group(1)
+
+# Check if fsbl-attribute is set correctly
+self.assertTrue(attributes['auth_only'] == "true")
+# Check if key is stored in efuse
+self.assertTrue(attributes['encryption_keystore'] == "0xa5c3c5a3")
+
+def testXilinxBootgenMissing(self):
+"""Test that binman still produces an image if ifwitool is missing"""
+data = tools.read_file(self.TestFile("key.key"))
+self._MakeInputFile("psk.pem", data)
+self._MakeInputFile("ssk.pem", data)
+self._SetupPmuFwlElf()
+self._SetupSplElf()
+with test_util.capture_sys_output() as (_, stderr):
+self._DoTestFile('307_xilinx_bootgen_sign.dts',
+ force_missing_bintools='bootgen')
+err = stderr.getvalue()
+self.assertRegex(err,
+ "Image 'image'.*missing bintools.*: bootgen")
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/307_xilinx_bootgen_sign.dts
b/tools/binman/test/307_xilinx_bootgen_sign.dts
new file mode 100644
index 00..02acf8652a
--- /dev/null
+++ b/tools/binman/test/307_xilinx_bootgen_sign.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ binman {
+ xilinx-bootgen {
+ auth-params = "ppk_select=0", "spk_id=0x";
+ pmufw-filename = "pmu-firmware.elf";
+ psk-key-name-hint = "psk";
+
[PATCH v4 0/3] Sign Xilinx ZynqMP SPL/FSBL boot images using binman
From: Lukas Funke
This series adds one etype to create a verified boot chain for
Xilinx ZynqMP devices. The etype 'xilinx-bootgen' is used to
create a bootable, signed image for ZynqMP boards using the Xilinx
Bootgen tool. The series also contains the corresponding btool for
calling 'bootgen'.
The following block shows an example on how to use this functionality:
spl {
filename = "boot.signed.bin";
xilinx-bootgen {
psk-key-name-hint = "psk0";
ssk-key-name-hint = "ssk0";
pmufw-filename = "pmu-firmware.elf";
auth-params = "ppk_select=0", "spk_id=0x";
u-boot-spl-nodtb {
};
u-boot-spl-pubkey-dtb {
algo = "sha384,rsa4096";
required = "conf";
key-name-hint = "dev";
};
};
};
Changes in v4:
- Fixed some typos
- Add test to check for missing bootgen tool
- Renamed etype from "xilinx-fsbl-auth" to "xilinx-bootgen"
- Add detection of missing bintool
- Promote 'pmufw-filename' to required property
Changes in v3:
- Fixed an issue where the build result was not found
- Fixed an issue where the version string was not reported correctly
- Improved test coverage for xilinx-fsbl-auth etype
- Changed etype from entry to section
- Changed property name "psk-filename" to "psk-key-name-hint"
- Changed property name "ssk-filename" to "ssk-key-name-hint"
- Decode spl elf file instead of reading start symbol
- Improved test coverage
- Improved documentation
Changes in v2:
- Pass additional 'keysrc_enc' parameter to Bootgen
- Added more information and terms to documentation
- Fixed typo in dts name
- Add 'keysrc-enc' property to pass down to Bootgen
- Improved documentation
- Use predictable output names for intermediated results
Lukas Funke (3):
binman: btool: Add Xilinx Bootgen btool
binman: ftest: Add test for xilinx-bootgen etype
binman: etype: Add xilinx-bootgen etype
tools/binman/bintools.rst | 2 +-
tools/binman/btool/bootgen.py | 137 +++
tools/binman/entries.rst | 75 ++
tools/binman/etype/xilinx_bootgen.py | 225 ++
tools/binman/ftest.py | 75 ++
tools/binman/test/307_xilinx_bootgen_sign.dts | 22 ++
.../test/308_xilinx_bootgen_sign_enc.dts | 24 ++
7 files changed, 559 insertions(+), 1 deletion(-)
create mode 100644 tools/binman/btool/bootgen.py
create mode 100644 tools/binman/etype/xilinx_bootgen.py
create mode 100644 tools/binman/test/307_xilinx_bootgen_sign.dts
create mode 100644 tools/binman/test/308_xilinx_bootgen_sign_enc.dts
--
2.30.2
Re: [PATCHv5 06/13] net/lwip: implement wget cmd
On Thu, 3 Aug 2023 at 12:48, Ilias Apalodimas
wrote:
> On Wed, Aug 02, 2023 at 08:06:51PM +0600, Maxim Uvarov wrote:
> > Signed-off-by: Maxim Uvarov
> > ---
> > lib/lwip/Makefile | 1 +
> > lib/lwip/apps/http/Makefile| 13
> > lib/lwip/apps/http/lwip-wget.c | 130 +
> > 3 files changed, 144 insertions(+)
> > create mode 100644 lib/lwip/apps/http/Makefile
> > create mode 100644 lib/lwip/apps/http/lwip-wget.c
> >
> > diff --git a/lib/lwip/Makefile b/lib/lwip/Makefile
> > index 1893162c1a..ec6b728c8e 100644
> > --- a/lib/lwip/Makefile
> > +++ b/lib/lwip/Makefile
> > @@ -68,3 +68,4 @@ obj-$(CONFIG_NET) += port/sys-arch.o
> > obj-$(CONFIG_CMD_DHCP) += apps/dhcp/lwip-dhcp.o
> > obj-$(CONFIG_CMD_DNS) += apps/dns/lwip-dns.o
> > obj-$(CONFIG_CMD_TFTPBOOT) += apps/tftp/
> > +obj-$(CONFIG_CMD_WGET) += apps/http/
> > diff --git a/lib/lwip/apps/http/Makefile b/lib/lwip/apps/http/Makefile
> > new file mode 100644
> > index 00..7d22817e50
> > --- /dev/null
> > +++ b/lib/lwip/apps/http/Makefile
> > @@ -0,0 +1,13 @@
> > +ccflags-y += -I$(srctree)/lib/lwip/port/include
> > +ccflags-y += -I$(srctree)/lib/lwip/lwip-external/src/include
> -I$(srctree)/lib/lwip
> > +ccflags-y += -I$(obj)
> > +
> > +$(obj)/http_clinet.o: $(obj)/http_client.c
> > +.PHONY: $(obj)/http_client.c
> > +$(obj)/http_client.c:
> > + cp $(srctree)/lib/lwip/lwip-external/src/apps/http/http_client.c
> $(obj)/http_client.c
> > + cp
> $(srctree)/lib/lwip/lwip-external/src/include/lwip/apps/http_client.h
> $(obj)/http_client.h
> > +
> > +obj-$(CONFIG_CMD_WGET) += http_client.o
> > +obj-$(CONFIG_CMD_WGET) += lwip-wget.o
> > +
> > diff --git a/lib/lwip/apps/http/lwip-wget.c
> b/lib/lwip/apps/http/lwip-wget.c
> > new file mode 100644
> > index 00..47a77250c5
> > --- /dev/null
> > +++ b/lib/lwip/apps/http/lwip-wget.c
> > @@ -0,0 +1,130 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +
> > +/*
> > + * (C) Copyright 2023 Linaro Ltd.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include "http_client.h"
> > +#include
> > +
> > +static ulong daddr;
> > +static httpc_connection_t settings;
> > +
> > +#define SERVER_NAME_SIZE 200
> > +
> > +static err_t httpc_recv(void *arg, struct altcp_pcb *pcb, struct pbuf
> *p, err_t err)
> > +{
> > + struct pbuf *q;
> > + LWIP_UNUSED_ARG(err);
>
> I think it's better to use standard C instead of LWIP defined macros for
> things like that
>
agree no need to use lwip macro here. But what is the common practice for
U-Boot for unused function args?
I think compilation does not even warn about it. So naming like unused_err
has to be fine here.
>
> > +
> > + if (!p)
> > + return ERR_BUF;
> > +
> > + for (q = p; q != NULL; q = q->next) {
> > + memcpy((void *)daddr, q->payload, q->len);
> > + printf("downloaded chunk size %d, to addr 0x%lx\n",
> q->len, daddr);
> > + daddr += q->len;
> > + }
> > + altcp_recved(pcb, p->tot_len);
> > + pbuf_free(p);
> > + return ERR_OK;
> > +}
> > +
> > +static void httpc_result(void *arg, httpc_result_t httpc_result, u32_t
> rx_content_len,
> > + u32_t srv_res, err_t err)
> > +{
> > + if (httpc_result == HTTPC_RESULT_OK) {
> > + printf("\n%d bytes successfully downloaded.\n",
> rx_content_len);
>
> Switch those to a log_ that makes sense
>
>
yep.
> > + env_set_ulong("filesize", rx_content_len);
> > + ulwip_exit(0);
> > + } else {
> > + printf("\nhttp eroror: %d\n", httpc_result);
> > + ulwip_exit(-1);
> > + }
> > +}
> > +
> > +/* http://hostname:port/url */
> > +static int parse_url(char *url, char *host, int *port)
> > +{
> > + char *p, *pp;
> > +
> > + p = strstr(url, "http://;);
> > + if (!p) {
> > + printf("err: no http://!\n;);
> > + return -1;
> > + }
> > +
> > + p += strlen("http://;);
> > +
> > + /* parse hostname */
> > + pp = strchr(p, ':');
> > + if (pp) {
> > +#define PORT_STR_SIZE 5
>
> https://lore.kernel.org/u-boot/ZMJqIxmXJD4S72Ig@hades/
> Do we currently support a configurable port for wget?
>
>
I might have to reply to the previous email, then update the patch. Old
wget has port inside header file and it's binded to 80.
Old wget does not parse url script and uses serverip variable for the
server. Old wget does not use DNS. Because of lwip variant
can use a url (including DNS and IPv6) there is no need to use the server
ip variable and bind to a specific port. So here we parse port,
host and url and pass it to lwip http_client.c example.
> > + char portstr[PORT_STR_SIZE];
> > +
> > + if (pp - p >= SERVER_NAME_SIZE)
> > + return -2;
> > + memcpy(host, p, pp - p);
> > + host[pp - p + 1] = '\0';
> > +
> > + p = pp + 1;
> > + pp = strchr(p, '/');
> >
