Re: imx8mp: issues getting dtb with pcie enabled to boot
Hi, On Fri, 7 Jul 2023 at 14:34, Fabio Estevam wrote: > > Adding Marcel and Francesco. > > On Fri, Jul 7, 2023 at 5:30 PM Sahaj Sarup wrote: > > > > Hi, > > I am working on the imxmp-verdin platform. One of the quirks with > > this particular som is that it uses an internal pcie_phy clock instead of > > an external one like most imx8mp boards do. > > To get this working on mainline linux, the way clocks are defined for the > > pcie_phy is > > `clocks = <_blk_ctrl>;` > > However this causes u-boot to completely fail to boot with this > > error `Device tree error at node '__symbols__'` . That looks like a strange error was found when trying to read the compatible string from the node. It wasn't -FDT_ERR_NOTFOUND. See lists_bind_fdt(). Perhaps we need to ignore the __symbols__ node? > > > > My end goal is to boot a generic arm image over pcie nvme, I don't know if > > this would be possible but atleast a compatible device tree would be a good > > starting point. > > > > Thanks. Regards, Simon
Re: imx8mp: issues getting dtb with pcie enabled to boot
On Sat, 8 Jul 2023 at 02:04, Fabio Estevam wrote: > Adding Marcel and Francesco. > > On Fri, Jul 7, 2023 at 5:30 PM Sahaj Sarup wrote: > > > > Hi, > > I am working on the imxmp-verdin platform. One of the quirks with > > this particular som is that it uses an internal pcie_phy clock instead of > > an external one like most imx8mp boards do. > > To get this working on mainline linux, the way clocks are defined for the > > pcie_phy is > > `clocks = <_blk_ctrl>;` > > However this causes u-boot to completely fail to boot with this > > error `Device tree error at node '__symbols__'` . > For now the fix seems to be `clocks = <_blk_ctrl 0>;` this gets pcie working under linux but not under u-boot, i'm guessing pcie for imx8 is not yet implemented? > > My end goal is to boot a generic arm image over pcie nvme, I don't know if > > this would be possible but atleast a compatible device tree would be a > good > > starting point. > > > > Thanks. > -- Best Regards Sahaj Sarup
Re: [PATCH v3 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Sat, Jul 08, 2023 at 12:54:38AM +0200, Pali Rohár wrote: > To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition() > function better understandable, rewrite it via explicit switch-case code > pattern. > > Also indicate an error when eMMC EXT_CSD[179] register is configured by > user to value which is not suitable for eMMC booting and SPL do not know > how to interpret it. > > Signed-off-by: Pali Rohár I did some quick local testing to check on the size impact and this is indeed quite manageable, thanks for reworking things! Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH v3 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
function better understandable, rewrite it via explicit switch-case code
pattern.
Also indicate an error when eMMC EXT_CSD[179] register is configured by
user to value which is not suitable for eMMC booting and SPL do not know
how to interpret it.
Signed-off-by: Pali Rohár
---
Changes in v3:
* Instead of showing (verbose) warning, make them as errors and
propagate them back to caller.
* Add comment with explanation what happened and how to fix possible
misconfigured configuration.
Changes in v2:
* Disable showing warning on sama5d2_xplained due to size restrictions
---
This patch depends on another patch:
mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
---
common/spl/spl_mmc.c | 56 +---
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index f7a42a11477d..656363a3b51a 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -408,15 +408,46 @@ int default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
*
* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area value.
-*
-* FIXME: When booting from this eMMC device is explicitly
-* disabled then we use User area for booting. This is incorrect.
-* Probably we should skip this eMMC device and select the next
-* one for booting. Or at least throw warning about this fallback.
*/
- part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
- if (part == 7)
- part = 0;
+ if (mmc->part_config == MMCPART_NOAVAILABLE)
+ part = 0; /* If partitions are not supported then we have only
User Area partition */
+ else {
+ switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
+ case 0: /* Booting from this eMMC device is disabled */
+ /*
+* This eMMC device has disabled booting.
+* This may happen because of misconfiguration of eMMC
device or
+* because user explicitly wanted to not boot from this
eMMC device.
+* eMMC boot configuration can be changed by "mmc
partconf" command.
+*/
+ part = -ENXIO; /* negative value indicates error */
+ /* Note that error message is printed by caller of this
function. */
+ break;
+ case 1: /* Boot partition 1 is used for booting */
+ part = 1;
+ break;
+ case 2: /* Boot partition 2 is used for booting */
+ part = 2;
+ break;
+ case 7: /* User area is used for booting */
+ part = 0;
+ break;
+ default: /* Other values are reserved */
+ /*
+* This eMMC device has configured booting from
reserved value.
+* This may happen because of misconfiguration of eMMC
device or
+* because this is newer eMMC device than what U-Boot
understand.
+* If newer eMMC specification defines meaning for some
reserved
+* values then switch above should be updated for new
cases.
+* At this stage we do not know how to interpret this
reserved
+* value so return error.
+* eMMC boot configuration can be changed by "mmc
partconf" command.
+*/
+ part = -EINVAL; /* negative value indicates error */
+ /* Note that error message is printed by caller of this
function. */
+ break;
+ }
+ }
#endif
return part;
}
@@ -471,6 +502,15 @@ int spl_mmc_load(struct spl_image_info *spl_image,
switch (boot_mode) {
case MMCSD_MODE_EMMCBOOT:
part = spl_mmc_emmc_boot_partition(mmc);
+ if (part < 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
+ if (part == -ENXIO)
+ puts("spl: mmc booting disabled\n");
+ else
+ puts("spl: mmc misconfigured\n");
+#endif
+ return part;
+ }
if (CONFIG_IS_ENABLED(MMC_TINY))
err = mmc_switch_part(mmc, part);
--
2.20.1
Re: [PATCH] buildman: Switch ARC toolchain to the upstream version
On Fri, Jul 07, 2023 at 10:04:53PM +0100, Alexey Brodkin wrote: > Back in the day we relied a lot on Synopsys own build of the GNU tools > for ARC processors, but since then we worked hard on getting all our changes > upstream and for a couple of years now we have ARCompact (AKA ARCv1) > and ARCv2 processors supported very well in upstream GCC, Binutils, GDB etc. > > And so there's no need to use Synopsys forks any longer, thus we remove > all the references to that form and use upstream components as majority > of other architectures in U-Boot. > > Thanks to Tom for pointing to that left-over! > > Signed-off-by: Alexey Brodkin > Cc: Simon Glass > Cc: Tom Rini Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] doc: fix typo in README.usb
On Fri, Jul 07, 2023 at 11:44:00AM +0200, Enguerrand de Ribaucourt wrote: > Signed-off-by: Enguerrand de Ribaucourt > > --- > doc/README.usb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/doc/README.usb b/doc/README.usb > index ef1d6ba36..b4c3ef522 100644 > --- a/doc/README.usb > +++ b/doc/README.usb > @@ -63,7 +63,7 @@ Common USB Commands: > Storage USB Commands: > - usb scan: scans the USB for storage devices.The USB must be > running for this command (usb start) > -- usb device [dev]: show or set current USB staorage device > +- usb device [dev]: show or set current USB storage device > - usb part [dev]: print partition table of one or all USB storage > devices > - usb read addr blk# cnt: This typo doesn't exist currently in master. -- Tom signature.asc Description: PGP signature
[PATCH] tools/docker: Dockerfile: Don't specify dtc submodule
When building qemu, all required submodules (of which we need more than just dtc) are handled automatically. Currently trying to init the submodule the way we do results in a git failure. Reported-by: Alexey Brodkin Signed-off-by: Tom Rini --- tools/docker/Dockerfile | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 9804b55ddde7..aa54e2689fb5 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -175,7 +175,6 @@ RUN git clone git://git.savannah.gnu.org/grub.git /tmp/grub && \ RUN git clone https://gitlab.com/qemu-project/qemu.git /tmp/qemu && \ cd /tmp/qemu && \ - git submodule update --init dtc && \ git checkout v6.1.0 && \ # config user.name and user.email to make 'git am' happy git config user.name u-boot && \ -- 2.34.1
[PATCH 2/2] tools: Fix package discovery in pyproject.toml of u_boot_pylib.
When building from source, setuptools would complain about not finding package via its auto-discovery mechanism. Manually specify how to locate the files, relative to the package's directory. * tools/u_boot_pylib/pyproject.toml: New tool.setuptools.packages.find section. Signed-off-by: Maxim Cournoyer --- tools/u_boot_pylib/pyproject.toml | 4 1 file changed, 4 insertions(+) diff --git a/tools/u_boot_pylib/pyproject.toml b/tools/u_boot_pylib/pyproject.toml index 31a4c0adae..037c5d629e 100644 --- a/tools/u_boot_pylib/pyproject.toml +++ b/tools/u_boot_pylib/pyproject.toml @@ -20,3 +20,7 @@ classifiers = [ [project.urls] "Homepage" = "https://u-boot.readthedocs.io; "Bug Tracker" = "https://source.denx.de/groups/u-boot/-/issues; + +[tool.setuptools.packages.find] +where = [".."] +include = ["u_boot_pylib*"] -- 2.40.1
[PATCH 1/2] tools: Fix README file in pyproject.toml of u_boot_pylib.
* tools/u_boot_pylib/pyproject.toml (readme): Replace README.md with
README.rst.
Signed-off-by: Maxim Cournoyer
---
tools/u_boot_pylib/pyproject.toml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/u_boot_pylib/pyproject.toml
b/tools/u_boot_pylib/pyproject.toml
index 3f33caf6f8..31a4c0adae 100644
--- a/tools/u_boot_pylib/pyproject.toml
+++ b/tools/u_boot_pylib/pyproject.toml
@@ -9,7 +9,7 @@ authors = [
{ name="Simon Glass", email="s...@chromium.org" },
]
description = "U-Boot python library"
-readme = "README.md"
+readme = "README.rst"
requires-python = ">=3.7"
classifiers = [
"Programming Language :: Python :: 3",
base-commit: 923de765ee1a5b26310f02cb42dcbad9e2b011c5
--
2.40.1
[PATCH] buildman: Switch ARC toolchain to the upstream version
Back in the day we relied a lot on Synopsys own build of the GNU tools for ARC processors, but since then we worked hard on getting all our changes upstream and for a couple of years now we have ARCompact (AKA ARCv1) and ARCv2 processors supported very well in upstream GCC, Binutils, GDB etc. And so there's no need to use Synopsys forks any longer, thus we remove all the references to that form and use upstream components as majority of other architectures in U-Boot. Thanks to Tom for pointing to that left-over! Signed-off-by: Alexey Brodkin Cc: Simon Glass Cc: Tom Rini --- tools/buildman/bsettings.py | 1 - tools/buildman/buildman.rst | 6 -- tools/docker/Dockerfile | 3 +-- 3 files changed, 1 insertion(+), 9 deletions(-) diff --git a/tools/buildman/bsettings.py b/tools/buildman/bsettings.py index 0eb894a558..029c401fd2 100644 --- a/tools/buildman/bsettings.py +++ b/tools/buildman/bsettings.py @@ -91,7 +91,6 @@ other = / [toolchain-prefix] # name = path to prefix # e.g. x86 = /opt/gcc-4.6.3-nolibc/x86_64-linux/bin/x86_64-linux- -# arc = /opt/arc/arc_gnu_2021.03_prebuilt_elf32_le_linux_install/bin/arc-elf32- [toolchain-alias] # arch = alias diff --git a/tools/buildman/buildman.rst b/tools/buildman/buildman.rst index c8b0db3d8b..6808727eb4 100644 --- a/tools/buildman/buildman.rst +++ b/tools/buildman/buildman.rst @@ -475,10 +475,6 @@ Setting up sudo mkdir -p /toolchains sudo mv ~/.buildman-toolchains/*/* /toolchains/ - For those not available from kernel.org, download from the following links: - - - `Arc Toolchain`_ - Buildman should now be set up to use your new toolchain. At the time of writing, U-Boot has these architectures: @@ -1342,8 +1338,6 @@ Thanks to Grant Grundler for his ideas for improving the build speed by building all commits for a board instead of the other way around. -.. _`Arc Toolchain`: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2021.03-release/arc_gnu_2021.03_prebuilt_elf32_le_linux_install.tar.gz - .. sectionauthor:: Simon Glass .. sectionauthor:: Copyright (c) 2013 The Chromium OS Authors. .. sectionauthor:: s...@chromium.org diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 9804b55ddd..fa03f3f2a7 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -16,6 +16,7 @@ RUN echo deb http://apt.llvm.org/jammy/ llvm-toolchain-jammy-16 main | tee /etc/ # Manually install the kernel.org "Crosstool" based toolchains for gcc-12.2.0 RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-aarch64-linux.tar.xz | tar -C /opt -xJ +RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-arc-linux.tar.xz | tar -C /opt -xJ RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-arm-linux-gnueabi.tar.xz | tar -C /opt -xJ RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-i386-linux.tar.xz | tar -C /opt -xJ RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/x86_64-gcc-12.2.0-nolibc-m68k-linux.tar.xz | tar -C /opt -xJ @@ -29,7 +30,6 @@ RUN wget -O - https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_ # Manually install other toolchains RUN wget -O - https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc233c-elf.tar.gz | tar -C /opt -xz -RUN wget -O - https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2021.03-release/arc_gnu_2021.03_prebuilt_uclibc_le_archs_linux_install.tar.gz | tar --no-same-owner -C /opt -xz # Update and install things from apt now RUN apt-get update && apt-get install -y \ @@ -279,7 +279,6 @@ RUN virtualenv -p /usr/bin/python3 /tmp/venv && \ # Create the buildman config file RUN /bin/echo -e "[toolchain]\nroot = /usr" > ~/.buildman RUN /bin/echo -e "kernelorg = /opt/gcc-12.2.0-nolibc/*" >> ~/.buildman -RUN /bin/echo -e "arc = /opt/arc_gnu_2021.03_prebuilt_uclibc_le_archs_linux_install" >> ~/.buildman RUN /bin/echo -e "\n[toolchain-prefix]\nxtensa = /opt/2020.07/xtensa-dc233c-elf/bin/xtensa-dc233c-elf-" >> ~/.buildman; RUN /bin/echo -e "\n[toolchain-alias]\nsh = sh2" >> ~/.buildman RUN /bin/echo -e "\nsandbox = x86_64" >> ~/.buildman -- 2.34.1
Re: imx8mp: issues getting dtb with pcie enabled to boot
Adding Marcel and Francesco. On Fri, Jul 7, 2023 at 5:30 PM Sahaj Sarup wrote: > > Hi, > I am working on the imxmp-verdin platform. One of the quirks with > this particular som is that it uses an internal pcie_phy clock instead of > an external one like most imx8mp boards do. > To get this working on mainline linux, the way clocks are defined for the > pcie_phy is > `clocks = <_blk_ctrl>;` > However this causes u-boot to completely fail to boot with this > error `Device tree error at node '__symbols__'` . > > My end goal is to boot a generic arm image over pcie nvme, I don't know if > this would be possible but atleast a compatible device tree would be a good > starting point. > > Thanks.
imx8mp: issues getting dtb with pcie enabled to boot
Hi, I am working on the imxmp-verdin platform. One of the quirks with this particular som is that it uses an internal pcie_phy clock instead of an external one like most imx8mp boards do. To get this working on mainline linux, the way clocks are defined for the pcie_phy is `clocks = <_blk_ctrl>;` However this causes u-boot to completely fail to boot with this error `Device tree error at node '__symbols__'` . My end goal is to boot a generic arm image over pcie nvme, I don't know if this would be possible but atleast a compatible device tree would be a good starting point. Thanks.
[PATCH 7/7] rockchip: chromebook_speedy: Enable sound
Commit ec107f04b619 ("rockchip: chromebook_minnie: Enable sound") and
commit 2d0c01b8f0ad ("sound: rockchip: Add sound support for jerry")
enable audio support for chromebook_minnie and chromebook_jerry. Enable
it for chromebook_speedy as well, but put the non-upstream sound node
in the board -u-boot.dtsi instead.
Signed-off-by: Alper Nebi Yasak
---
Not enabling these for chromebit_mickey, as that'd use HDMI in a way I
don't know how.
arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 14 ++
configs/chromebook_speedy_defconfig | 5 +
2 files changed, 19 insertions(+)
diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
index 2a4ba44e0bf9..6bfa84906e35 100644
--- a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
@@ -5,6 +5,20 @@
#include "rk3288-veyron-u-boot.dtsi"
+/ {
+ sound {
+ compatible = "rockchip,audio-max98090-jerry";
+
+ cpu {
+ sound-dai = < 0>;
+ };
+
+ codec {
+ sound-dai = < 0>;
+ };
+ };
+};
+
{
rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
0x6 0x0 0x8 0x4 0x17 0x24 0xd 0x6
diff --git a/configs/chromebook_speedy_defconfig
b/configs/chromebook_speedy_defconfig
index f8f2a280f6cf..15b6e21095db 100644
--- a/configs/chromebook_speedy_defconfig
+++ b/configs/chromebook_speedy_defconfig
@@ -52,6 +52,7 @@ CONFIG_CMD_USB=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_CACHE=y
CONFIG_CMD_TIME=y
+CONFIG_CMD_SOUND=y
CONFIG_CMD_PMIC=y
CONFIG_CMD_REGULATOR=y
# CONFIG_SPL_DOS_PARTITION is not set
@@ -99,6 +100,10 @@ CONFIG_SPL_RAM=y
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550_MEM32=y
CONFIG_ROCKCHIP_SERIAL=y
+CONFIG_SOUND=y
+CONFIG_I2S=y
+CONFIG_I2S_ROCKCHIP=y
+CONFIG_SOUND_MAX98090=y
CONFIG_ROCKCHIP_SPI=y
CONFIG_SYSRESET=y
CONFIG_USB=y
--
2.40.1
[PATCH 6/7] rockchip: chromebook_jerry: Re-enable MAX98090 codec driver
Sound support for chromebook_jerry needs the MAX98090 codec driver. This
was enabled in commit 2d0c01b8f0ad ("sound: rockchip: Add sound support
for jerry"), but apparently lost in commit 7ae2729401bb ("configs:
Resync with savedefconfig"). Enable it again.
Signed-off-by: Alper Nebi Yasak
---
configs/chromebook_jerry_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/chromebook_jerry_defconfig
b/configs/chromebook_jerry_defconfig
index 1a54986d089e..5b601a0b5809 100644
--- a/configs/chromebook_jerry_defconfig
+++ b/configs/chromebook_jerry_defconfig
@@ -102,6 +102,7 @@ CONFIG_ROCKCHIP_SERIAL=y
CONFIG_SOUND=y
CONFIG_I2S=y
CONFIG_I2S_ROCKCHIP=y
+CONFIG_SOUND_MAX98090=y
CONFIG_ROCKCHIP_SPI=y
CONFIG_SYSRESET=y
CONFIG_USB=y
--
2.40.1
[PATCH 5/7] rockchip: veyron: Use TrueType fonts
Commit 815ed79d8338 ("video: rockchip: Use TrueType fonts with jerry")
enables makes chromebook_jerry use TrueType fonts. Make other veyron
boards switch to it as well.
Signed-off-by: Alper Nebi Yasak
---
I have no idea why that commit disables USE_PRIVATE_LIBGCC, but I'm
following that change here.
configs/chromebit_mickey_defconfig | 2 ++
configs/chromebook_minnie_defconfig | 2 ++
2 files changed, 4 insertions(+)
diff --git a/configs/chromebit_mickey_defconfig
b/configs/chromebit_mickey_defconfig
index f45b14b9d3d1..81efa0fd4cc6 100644
--- a/configs/chromebit_mickey_defconfig
+++ b/configs/chromebit_mickey_defconfig
@@ -107,9 +107,11 @@ CONFIG_USB_DWC2=y
CONFIG_ROCKCHIP_USB2_PHY=y
CONFIG_VIDEO=y
# CONFIG_VIDEO_BPP8 is not set
+CONFIG_CONSOLE_TRUETYPE=y
CONFIG_DISPLAY=y
CONFIG_VIDEO_ROCKCHIP=y
CONFIG_DISPLAY_ROCKCHIP_HDMI=y
+# CONFIG_USE_PRIVATE_LIBGCC is not set
CONFIG_SPL_TINY_MEMSET=y
CONFIG_CMD_DHRYSTONE=y
CONFIG_ERRNO_STR=y
diff --git a/configs/chromebook_minnie_defconfig
b/configs/chromebook_minnie_defconfig
index 01964d13754e..e2302074e8b3 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -112,10 +112,12 @@ CONFIG_USB_DWC2=y
CONFIG_ROCKCHIP_USB2_PHY=y
CONFIG_VIDEO=y
# CONFIG_VIDEO_BPP8 is not set
+CONFIG_CONSOLE_TRUETYPE=y
CONFIG_DISPLAY=y
CONFIG_VIDEO_ROCKCHIP=y
CONFIG_DISPLAY_ROCKCHIP_EDP=y
CONFIG_DISPLAY_ROCKCHIP_HDMI=y
+# CONFIG_USE_PRIVATE_LIBGCC is not set
CONFIG_SPL_TINY_MEMSET=y
CONFIG_CMD_DHRYSTONE=y
CONFIG_ERRNO_STR=y
--
2.40.1
[PATCH 4/7] rockchip: veyron: Add serial, logging, silent console support
Commit eba768c54587 ("rockchip: jerry: Add serial support") enables
ROCKCHIP_SERIAL for chromebook_jerry to make the serial console work
correctly. Enable it also for other veyron boards.
Also enable logging and disable scrolling multiple lines at once as in
chromebook_jerry, and enable silent console as chromebook_minnie does.
Signed-off-by: Alper Nebi Yasak
---
configs/chromebit_mickey_defconfig | 3 +++
configs/chromebook_minnie_defconfig | 3 ++-
configs/chromebook_speedy_defconfig | 1 +
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/configs/chromebit_mickey_defconfig
b/configs/chromebit_mickey_defconfig
index a7c6213a9892..f45b14b9d3d1 100644
--- a/configs/chromebit_mickey_defconfig
+++ b/configs/chromebit_mickey_defconfig
@@ -26,6 +26,8 @@ CONFIG_SPL_PAYLOAD="u-boot.img"
CONFIG_DEBUG_UART=y
CONFIG_USE_PREBOOT=y
CONFIG_DEFAULT_FDT_FILE="rk3288-veyron-mickey.dtb"
+CONFIG_SILENT_CONSOLE=y
+CONFIG_LOG=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_R=y
@@ -96,6 +98,7 @@ CONFIG_RAM=y
CONFIG_SPL_RAM=y
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SERIAL=y
CONFIG_ROCKCHIP_SPI=y
CONFIG_SYSRESET=y
CONFIG_USB=y
diff --git a/configs/chromebook_minnie_defconfig
b/configs/chromebook_minnie_defconfig
index 8a4e1858c8bd..01964d13754e 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -27,6 +27,7 @@ CONFIG_DEBUG_UART=y
CONFIG_USE_PREBOOT=y
CONFIG_DEFAULT_FDT_FILE="rk3288-veyron-minnie.dtb"
CONFIG_SILENT_CONSOLE=y
+CONFIG_LOG=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_R=y
@@ -98,6 +99,7 @@ CONFIG_RAM=y
CONFIG_SPL_RAM=y
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SERIAL=y
CONFIG_SOUND=y
CONFIG_I2S=y
CONFIG_I2S_ROCKCHIP=y
@@ -114,7 +116,6 @@ CONFIG_DISPLAY=y
CONFIG_VIDEO_ROCKCHIP=y
CONFIG_DISPLAY_ROCKCHIP_EDP=y
CONFIG_DISPLAY_ROCKCHIP_HDMI=y
-CONFIG_CONSOLE_SCROLL_LINES=10
CONFIG_SPL_TINY_MEMSET=y
CONFIG_CMD_DHRYSTONE=y
CONFIG_ERRNO_STR=y
diff --git a/configs/chromebook_speedy_defconfig
b/configs/chromebook_speedy_defconfig
index 45c22f5b103a..f8f2a280f6cf 100644
--- a/configs/chromebook_speedy_defconfig
+++ b/configs/chromebook_speedy_defconfig
@@ -27,6 +27,7 @@ CONFIG_DEBUG_UART=y
CONFIG_USE_PREBOOT=y
CONFIG_DEFAULT_FDT_FILE="rk3288-veyron-speedy.dtb"
CONFIG_SILENT_CONSOLE=y
+CONFIG_LOG=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_BOARD_EARLY_INIT_R=y
--
2.40.1
[PATCH 3/7] rockchip: veyron: Unify u-boot.dtsi bootph-all fragments
The rk3288-veyron-speedy-u-boot.dtsi file duplicates the bootphase dts
fragments from rk3288-veyron-u-boot.dtsi even though it #inclues that.
Deduplicate these into the latter file, which should also make the eMMC
available to the other veyron boards' SPL.
Signed-off-by: Alper Nebi Yasak
---
arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 16
arch/arm/dts/rk3288-veyron-u-boot.dtsi| 4
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
index 90ce9e1395de..2a4ba44e0bf9 100644
--- a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
@@ -15,19 +15,3 @@ {
0x0 0xc3 0x6 0x1>;
rockchip,sdram-params = <0x20D266A4 0x5B6 6 53300 6 13 0>;
};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
-
- {
- bootph-all;
-};
diff --git a/arch/arm/dts/rk3288-veyron-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-u-boot.dtsi
index ab564e73ed00..4f9c59c67573 100644
--- a/arch/arm/dts/rk3288-veyron-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-veyron-u-boot.dtsi
@@ -31,6 +31,10 @@ {
>;
};
+ {
+ bootph-all;
+};
+
{
bootph-all;
};
--
2.40.1
[PATCH 2/7] rockchip: veyron: Enable building SPI ROM images
Commit 9b312e26fc77 ("rockchip: Enable building a SPI ROM image on
jerry") produces a u-boot.rom file for chromebook_jerry, intended to be
written to SPI flash. Build this file for other veyron boards as well,
especially because they are already configured only to boot from SPI.
Signed-off-by: Alper Nebi Yasak
---
arch/arm/mach-rockchip/rk3288/Kconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-rockchip/rk3288/Kconfig
b/arch/arm/mach-rockchip/rk3288/Kconfig
index ea94ad114247..69a5614b449a 100644
--- a/arch/arm/mach-rockchip/rk3288/Kconfig
+++ b/arch/arm/mach-rockchip/rk3288/Kconfig
@@ -16,7 +16,9 @@ config TARGET_CHROMEBOOK_JERRY
config TARGET_CHROMEBIT_MICKEY
bool "Google/Rockchip Veyron-Mickey Chromebit"
+ select HAS_ROM
select BOARD_LATE_INIT
+ select ROCKCHIP_SPI_IMAGE
help
Mickey is a small RK3288-based device with one USB 3.0 port, HDMI
and WiFi. It has a separate power port and is designed to connect
@@ -26,7 +28,9 @@ config TARGET_CHROMEBIT_MICKEY
config TARGET_CHROMEBOOK_MINNIE
bool "Google/Rockchip Veyron-Minnie Chromebook"
+ select HAS_ROM
select BOARD_LATE_INIT
+ select ROCKCHIP_SPI_IMAGE
help
Minnie is a RK3288-based convertible clamshell device with 2 USB 3.0
ports, micro HDMI, a 10.1-inch 1280x800 EDP display, micro-SD card,
@@ -37,7 +41,9 @@ config TARGET_CHROMEBOOK_MINNIE
config TARGET_CHROMEBOOK_SPEEDY
bool "Google/Rockchip Veyron-Speedy Chromebook"
+ select HAS_ROM
select BOARD_LATE_INIT
+ select ROCKCHIP_SPI_IMAGE
help
Speedy is a RK3288-based clamshell device with 2 USB 2.0 ports,
micro HDMI, an 11.6 inch display, micro-SD card,
--
2.40.1
[PATCH 1/7] rockchip: veyron: Enable RESET driver
Commit 70e351bdfeee ("rockchip: jerry: Enable RESET driver") enables
DM_RESET for chromebook_jerry to fix its display as required by changes
to the Rockchip video drivers. Enable it for other veyron boards as
well.
Fixes: cd529f7ad62 ("rockchip: video: edp: Add missing reset support")
Fixes: 9749d2ea29e ("rockchip: video: vop: Add reset support")
Signed-off-by: Alper Nebi Yasak
---
configs/chromebit_mickey_defconfig | 1 +
configs/chromebook_minnie_defconfig | 1 +
configs/chromebook_speedy_defconfig | 1 +
3 files changed, 3 insertions(+)
diff --git a/configs/chromebit_mickey_defconfig
b/configs/chromebit_mickey_defconfig
index d4302353c5df..a7c6213a9892 100644
--- a/configs/chromebit_mickey_defconfig
+++ b/configs/chromebit_mickey_defconfig
@@ -10,6 +10,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x10
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-mickey"
CONFIG_SPL_TEXT_BASE=0xff704000
+CONFIG_DM_RESET=y
CONFIG_SYS_MONITOR_LEN=614400
CONFIG_ROCKCHIP_RK3288=y
# CONFIG_SPL_MMC is not set
diff --git a/configs/chromebook_minnie_defconfig
b/configs/chromebook_minnie_defconfig
index 73ab2f62af5e..8a4e1858c8bd 100644
--- a/configs/chromebook_minnie_defconfig
+++ b/configs/chromebook_minnie_defconfig
@@ -10,6 +10,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x10
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-minnie"
CONFIG_SPL_TEXT_BASE=0xff704000
+CONFIG_DM_RESET=y
CONFIG_SYS_MONITOR_LEN=614400
CONFIG_ROCKCHIP_RK3288=y
# CONFIG_SPL_MMC is not set
diff --git a/configs/chromebook_speedy_defconfig
b/configs/chromebook_speedy_defconfig
index 06437aae18d6..45c22f5b103a 100644
--- a/configs/chromebook_speedy_defconfig
+++ b/configs/chromebook_speedy_defconfig
@@ -10,6 +10,7 @@ CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x10
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_DEFAULT_DEVICE_TREE="rk3288-veyron-speedy"
CONFIG_SPL_TEXT_BASE=0xff704000
+CONFIG_DM_RESET=y
CONFIG_SYS_MONITOR_LEN=614400
CONFIG_ROCKCHIP_RK3288=y
# CONFIG_SPL_MMC is not set
--
2.40.1
[PATCH 0/7] rockchip: veyron: Synchronize changes for veyron boards
There have been bug fixes and new features for some veyron-based boards which are applicable to others because they share most of the underlying hardware. This series tries to synchronize changes across all veyron boards. I couldn't personally test these myself as I don't have any of the supported boards, and couldn't spent time to port the veyron-mighty I have yet. Sending so others can test and for the first two patches I think should go in v2023.07, but take with a grain of salt. Alper Nebi Yasak (7): rockchip: veyron: Enable RESET driver rockchip: veyron: Enable building SPI ROM images rockchip: veyron: Unify u-boot.dtsi bootph-all fragments rockchip: veyron: Add serial, logging, silent console support rockchip: veyron: Use TrueType fonts rockchip: chromebook_jerry: Re-enable MAX98090 codec driver rockchip: chromebook_speedy: Enable sound arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 30 +-- arch/arm/dts/rk3288-veyron-u-boot.dtsi| 4 +++ arch/arm/mach-rockchip/rk3288/Kconfig | 6 configs/chromebit_mickey_defconfig| 6 configs/chromebook_jerry_defconfig| 1 + configs/chromebook_minnie_defconfig | 6 +++- configs/chromebook_speedy_defconfig | 7 + 7 files changed, 43 insertions(+), 17 deletions(-) -- 2.40.1
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Fri, Jul 07, 2023 at 07:56:56PM +0200, Pali Rohár wrote:
> On Friday 07 July 2023 13:10:19 Tom Rini wrote:
> > On Fri, Jul 07, 2023 at 07:05:45PM +0200, Pali Rohár wrote:
> > > On Friday 07 July 2023 12:54:58 Tom Rini wrote:
> > > > On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> > > > > On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > > > > > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > > > > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > > > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > > > > > To make eMMC partition choosing in
> > > > > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > > > > function better understandable, rewrite it via explicit
> > > > > > > > > switch-case code
> > > > > > > > > pattern.
> > > > > > > > >
> > > > > > > > > Also add a warning when eMMC EXT_CSD[179] register is
> > > > > > > > > configured by user to
> > > > > > > > > value which is not suitable for eMMC booting and SPL do not
> > > > > > > > > know how to
> > > > > > > > > interpret it.
> > > > > > > > >
> > > > > > > > > Note that when booting from eMMC device via EXT_CSD[179]
> > > > > > > > > register is
> > > > > > > > > explicitly disabled then SPL still loads and boots from this
> > > > > > > > > eMMC device
> > > > > > > > > from User Area partition. This behavior was not changed in
> > > > > > > > > this commit and
> > > > > > > > > should be revisited in the future.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Pali Rohár
> > > > > > > > > ---
> > > > > > > > > Changes in v2:
> > > > > > > > > * Disable showing warning on sama5d2_xplained due to size
> > > > > > > > > restrictions
> > > > > > > > > ---
> > > > > > > > > This patch depends on another patch:
> > > > > > > > > mmc: spl: Add comments for
> > > > > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > > > > > ---
> > > > > > > > > common/spl/Kconfig | 7 +++
> > > > > > > > > common/spl/spl_mmc.c | 46
> > > > > > > > >
> > > > > > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > > > > > --- a/common/spl/Kconfig
> > > > > > > > > +++ b/common/spl/Kconfig
> > > > > > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > > > > > help
> > > > > > > > > Enable write access to MMC and SD Cards in SPL
> > > > > > > > >
> > > > > > > > > +config SPL_MMC_WARNINGS
> > > > > > > > > + bool "Print MMC warnings"
> > > > > > > > > + depends on SPL_MMC
> > > > > > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > > > > > + help
> > > > > > > > > + Print SPL MMC warnings. You can disable this option
> > > > > > > > > to reduce SPL size.
> > > > > > > > > +
> > > > > > > > >
> > > > > > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > > > > > bool "Support MPC8XXX DDR init"
> > > > > > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > > > > > --- a/common/spl/spl_mmc.c
> > > > > > > > > +++ b/common/spl/spl_mmc.c
> > > > > > > > > @@ -408,15 +408,45 @@ int
> > > > > > > > > default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > > > > > > > >*
> > > > > > > > >* Note: See difference between
> > > > > > > > > EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > > > > > >* and EXT_CSD_EXTRACT_BOOT_PART, specially about User
> > > > > > > > > area value.
> > > > > > > > > - *
> > > > > > > > > - * FIXME: When booting from this eMMC device is
> > > > > > > > > explicitly
> > > > > > > > > - * disabled then we use User area for booting. This is
> > > > > > > > > incorrect.
> > > > > > > > > - * Probably we should skip this eMMC device and select
> > > > > > > > > the next
> > > > > > > > > - * one for booting. Or at least throw warning about
> > > > > > > > > this fallback.
> > > > > > > > >*/
> > > > > > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > > > > > - if (part == 7)
> > > > > > > > > - part = 0;
> > > > > > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > > > > > + part = 0; /* If partitions are not supported
> > > > > > > > > then we have only User Area partition */
> > > > > > > > > + else {
> > > > > > > > > +
> > > > > > > > > switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > > > > > + case 0: /* Booting from this eMMC device is
> > > > > > > > > disabled */
> > > > > > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > > > > > + puts("spl: WARNING:
Re: [PATCH v14 11/11] arm_ffa: efi: corstone1000: enable MM communication
Hi Tom, On Fri, 7 Jul 2023 at 11:44, Tom Rini wrote: > > On Fri, Jul 07, 2023 at 11:35:05AM -0600, Simon Glass wrote: > > Hi Abdellatif, > > > > On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi > > wrote: > > > > > > turn on EFI MM communication > > > > > > On corstone1000 platform MM communication between u-boot > > > and the secure world (Optee) is done using the FF-A bus. > > > > > > Signed-off-by: Abdellatif El Khlifi > > > Cc: Tom Rini > > > Cc: Simon Glass > > > Cc: Ilias Apalodimas > > > Cc: Jens Wiklander > > > > > > --- > > > > > > Changelog: > > > === > > > > > > 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 | 1 + > > > include/configs/corstone1000.h | 15 +-- > > > 2 files changed, 14 insertions(+), 2 deletions(-) > > > > > > diff --git a/configs/corstone1000_defconfig > > > b/configs/corstone1000_defconfig > > > index a8a79fd105..b57e2322c4 100644 > > > --- a/configs/corstone1000_defconfig > > > +++ b/configs/corstone1000_defconfig > > > @@ -65,3 +65,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y > > > CONFIG_EFI_IGNORE_OSINDICATIONS=y > > > CONFIG_FWU_MULTI_BANK_UPDATE=y > > > CONFIG_ERRNO_STR=y > > > +CONFIG_EFI_MM_COMM_TEE=y > > > diff --git a/include/configs/corstone1000.h > > > b/include/configs/corstone1000.h > > > index 3347c11792..4ef1f05e40 100644 > > > --- a/include/configs/corstone1000.h > > > +++ b/include/configs/corstone1000.h > > > @@ -1,9 +1,11 @@ > > > /* SPDX-License-Identifier: GPL-2.0+ */ > > > /* > > > - * (C) Copyright 2022 ARM Limited > > > * (C) Copyright 2022 Linaro > > > * Rui Miguel Silva > > > - * Abdellatif El Khlifi > > > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > > > > > + * > > > + * Authors: > > > + * Abdellatif El Khlifi > > > * > > > * Configuration for Corstone1000. Parts were derived from other ARM > > > * configurations. > > > @@ -14,6 +16,15 @@ > > > > > > #include > > > > > > +#define FFA_SHARED_MM_BUFFER_SIZE SZ_4K /* 4 KB */ > > > + > > > +/* > > > + * shared buffer physical address used for communication between > > > + * u-boot and the MM SP > > > + */ > > > +#define FFA_SHARED_MM_BUFFER_ADDR 0x0200UL > > > +#define FFA_SHARED_MM_BUFFER_OFFSET0 > > > + > > > > These should be in devicetree properties, shouldn't they? We don't > > want things in board config.h files anymore. > > Wasn't one of the earlier debates on if the whole thing needs to be in > device tree, or not, because it's a "discoverable bus" and so Linux > wasn't needing one? I don't want to de-rail this series, which I think > we're just about otherwise ready to merge, over that debate again. > > As these values have to match up (I assume) with the other side, are > these truly per-board, or SoC dependent? Yes let's not derail the series...it has gone on too long already. But we do need to think about this. Addresses in #defines are not a great look. It isn't even a CFG. Regards, Simon
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 11:46, Jan Kiszka wrote:
>
> On 07.07.23 19:35, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 7 Jul 2023 at 17:03, Jan Kiszka wrote:
> >>
> >> On 07.07.23 17:35, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
>
> On 07.07.23 14:42, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
> >>
> >> On 05.07.23 00:14, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka
> >>> wrote:
>
> Hi Simon,
>
> On 28.06.23 13:41, Simon Glass wrote:
> > Collections can used to collect the contents of other entries into a
> > single entry, but they result in a single entry, with the original
> > entries
> > 'left behind' in their old place.
> >
> > It is useful to be able to specific a set of entries ones and have
> > it used
> > in multiple images, or parts of an image.
> >
> > Implement this mechanism.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > tools/binman/binman.rst | 80
> >
> > tools/binman/control.py | 9 +++
> > tools/binman/etype/section.py| 3 +-
> > tools/binman/ftest.py| 8 +++
> > tools/binman/test/286_entry_template.dts | 42 +
> > 5 files changed, 141 insertions(+), 1 deletion(-)
> > create mode 100644 tools/binman/test/286_entry_template.dts
> >
> > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> > index a4b31fe5397b..9be979ae1c5b 100644
> > --- a/tools/binman/binman.rst
> > +++ b/tools/binman/binman.rst
> > @@ -727,6 +727,13 @@ optional:
> > Note that missing, optional blobs do not produce a non-zero
> > exit code from
> > binman, although it does show a warning about the missing
> > external blob.
> >
> > +insert-template:
> > +This is not strictly speaking an entry property, since it is
> > processed early
> > +in Binman before the entries are read. It is a list of
> > phandles of nodes to
> > +include in the current (target) node. For each node, its
> > subnodes and their
> > +properties are brought into the target node. See Templates_
> > below for
> > +more information.
> > +
> > The attributes supported for images and sections are described
> > below. Several
> > are similar to those for entries.
> >
> > @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what
> > is going on, you can use
> > arch/arm/dts/u-boot.dtsi ... found:
> > "arch/arm/dts/juno-r2-u-boot.dtsi"
> >
> >
> > +Templates
> > +=
> > +
> > +Sometimes multiple images need to be created which have all have a
> > common
> > +part. For example, a board may generate SPI and eMMC images which
> > both include
> > +a FIT. Since the FIT includes many entries, it is tedious to
> > repeat them twice
> > +in the image description.
> > +
> > +Templates provide a simple way to handle this::
> > +
> > +binman {
> > +multiple-images;
> > +common_part: template-1 {
> > +fit {
> > +... lots of entries in here
> > +};
> > +
> > +text {
> > +text = "base image";
> > +};
> > +};
> > +
> > +spi-image {
> > +filename = "image-spi.bin";
> > +insert-template = <>;
> > +
> > +/* things specific to SPI follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "SPI image";
> > +};
> > +};
> > +
> > +mmc-image {
> > +filename = "image-mmc.bin";
> > +insert-template = <>;
> > +
> > +/* things specific to MMC follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "MMC image";
> > +};
> > +};
> > +};
> > +
> > +The template node name must start with 'template', so it is not
> > considered to be
> > +an image itself.
> > +
>
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Friday 07 July 2023 13:10:19 Tom Rini wrote:
> On Fri, Jul 07, 2023 at 07:05:45PM +0200, Pali Rohár wrote:
> > On Friday 07 July 2023 12:54:58 Tom Rini wrote:
> > > On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> > > > On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > > > > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > > > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > > > > To make eMMC partition choosing in
> > > > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > > > function better understandable, rewrite it via explicit
> > > > > > > > switch-case code
> > > > > > > > pattern.
> > > > > > > >
> > > > > > > > Also add a warning when eMMC EXT_CSD[179] register is
> > > > > > > > configured by user to
> > > > > > > > value which is not suitable for eMMC booting and SPL do not
> > > > > > > > know how to
> > > > > > > > interpret it.
> > > > > > > >
> > > > > > > > Note that when booting from eMMC device via EXT_CSD[179]
> > > > > > > > register is
> > > > > > > > explicitly disabled then SPL still loads and boots from this
> > > > > > > > eMMC device
> > > > > > > > from User Area partition. This behavior was not changed in this
> > > > > > > > commit and
> > > > > > > > should be revisited in the future.
> > > > > > > >
> > > > > > > > Signed-off-by: Pali Rohár
> > > > > > > > ---
> > > > > > > > Changes in v2:
> > > > > > > > * Disable showing warning on sama5d2_xplained due to size
> > > > > > > > restrictions
> > > > > > > > ---
> > > > > > > > This patch depends on another patch:
> > > > > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > > > > ---
> > > > > > > > common/spl/Kconfig | 7 +++
> > > > > > > > common/spl/spl_mmc.c | 46
> > > > > > > >
> > > > > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > > > > --- a/common/spl/Kconfig
> > > > > > > > +++ b/common/spl/Kconfig
> > > > > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > > > > help
> > > > > > > > Enable write access to MMC and SD Cards in SPL
> > > > > > > >
> > > > > > > > +config SPL_MMC_WARNINGS
> > > > > > > > + bool "Print MMC warnings"
> > > > > > > > + depends on SPL_MMC
> > > > > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > > > > + help
> > > > > > > > + Print SPL MMC warnings. You can disable this option
> > > > > > > > to reduce SPL size.
> > > > > > > > +
> > > > > > > >
> > > > > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > > > > bool "Support MPC8XXX DDR init"
> > > > > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > > > > --- a/common/spl/spl_mmc.c
> > > > > > > > +++ b/common/spl/spl_mmc.c
> > > > > > > > @@ -408,15 +408,45 @@ int
> > > > > > > > default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > > > > > > > *
> > > > > > > > * Note: See difference between
> > > > > > > > EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > > > > > * and EXT_CSD_EXTRACT_BOOT_PART, specially about User
> > > > > > > > area value.
> > > > > > > > -*
> > > > > > > > -* FIXME: When booting from this eMMC device is
> > > > > > > > explicitly
> > > > > > > > -* disabled then we use User area for booting. This is
> > > > > > > > incorrect.
> > > > > > > > -* Probably we should skip this eMMC device and select
> > > > > > > > the next
> > > > > > > > -* one for booting. Or at least throw warning about
> > > > > > > > this fallback.
> > > > > > > > */
> > > > > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > > > > - if (part == 7)
> > > > > > > > - part = 0;
> > > > > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > > > > + part = 0; /* If partitions are not supported
> > > > > > > > then we have only User Area partition */
> > > > > > > > + else {
> > > > > > > > +
> > > > > > > > switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > > > > + case 0: /* Booting from this eMMC device is
> > > > > > > > disabled */
> > > > > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > > > > + puts("spl: WARNING: Booting from this
> > > > > > > > eMMC device is disabled in EXT_CSD[179] register\n");
> > > > > > > > + puts("spl: WARNING: Continuing anyway
> > > > > > > > and selecting User Area partition for
Re: [PATCH] MAINTAINERS: correct at91 tree link
On Fri, 07 Jul 2023 16:45:32 +0300, Eugen Hristev wrote: > This was not done when the tree name was changed, fix it now. > > Applied to u-boot/master, thanks! -- Tom
[PATCH] fs/erofs: Introduce new features including ztailpacking, fragments and dedupe
This patch updates erofs driver code to catch up with the latest code of
erofs_utils (commit e4939f9eaa177e05d697ace85d8dc283e25dc2ed).
LZMA will be supported in the separate patch later.
Signed-off-by: Yifan Zhao
---
CI result here:
https://github.com/u-boot/u-boot/pull/344
fs/erofs/data.c | 165 ++-
fs/erofs/decompress.c | 32 -
fs/erofs/decompress.h | 3 +
fs/erofs/erofs_fs.h | 301 +++---
fs/erofs/fs.c | 12 +-
fs/erofs/internal.h | 119 ++---
fs/erofs/namei.c | 44 +++---
fs/erofs/super.c | 33 ++---
fs/erofs/zmap.c | 277 +-
9 files changed, 642 insertions(+), 344 deletions(-)
diff --git a/fs/erofs/data.c b/fs/erofs/data.c
index 761896054c..f4b21d7917 100644
--- a/fs/erofs/data.c
+++ b/fs/erofs/data.c
@@ -12,23 +12,23 @@ static int erofs_map_blocks_flatmode(struct erofs_inode
*inode,
struct erofs_inode *vi = inode;
bool tailendpacking = (vi->datalayout == EROFS_INODE_FLAT_INLINE);
- nblocks = DIV_ROUND_UP(inode->i_size, EROFS_BLKSIZ);
+ nblocks = BLK_ROUND_UP(inode->i_size);
lastblk = nblocks - tailendpacking;
/* there is no hole in flatmode */
map->m_flags = EROFS_MAP_MAPPED;
- if (offset < blknr_to_addr(lastblk)) {
- map->m_pa = blknr_to_addr(vi->u.i_blkaddr) + map->m_la;
- map->m_plen = blknr_to_addr(lastblk) - offset;
+ if (offset < erofs_pos(lastblk)) {
+ map->m_pa = erofs_pos(vi->u.i_blkaddr) + map->m_la;
+ map->m_plen = erofs_pos(lastblk) - offset;
} else if (tailendpacking) {
/* 2 - inode inline B: inode, [xattrs], inline last blk... */
map->m_pa = iloc(vi->nid) + vi->inode_isize +
vi->xattr_isize + erofs_blkoff(map->m_la);
map->m_plen = inode->i_size - offset;
- /* inline data should be located in one meta block */
- if (erofs_blkoff(map->m_pa) + map->m_plen > PAGE_SIZE) {
+ /* inline data should be located in the same meta block */
+ if (erofs_blkoff(map->m_pa) + map->m_plen > erofs_blksiz()) {
erofs_err("inline data cross block boundary @ nid %"
PRIu64,
vi->nid);
DBG_BUGON(1);
@@ -55,7 +55,7 @@ int erofs_map_blocks(struct erofs_inode *inode,
{
struct erofs_inode *vi = inode;
struct erofs_inode_chunk_index *idx;
- u8 buf[EROFS_BLKSIZ];
+ u8 buf[EROFS_MAX_BLOCK_SIZE];
u64 chunknr;
unsigned int unit;
erofs_off_t pos;
@@ -87,7 +87,7 @@ int erofs_map_blocks(struct erofs_inode *inode,
map->m_la = chunknr << vi->u.chunkbits;
map->m_plen = min_t(erofs_off_t, 1UL << vi->u.chunkbits,
- roundup(inode->i_size - map->m_la, EROFS_BLKSIZ));
+ roundup(inode->i_size - map->m_la, erofs_blksiz()));
/* handle block map */
if (!(vi->u.chunkformat & EROFS_CHUNK_FORMAT_INDEXES)) {
@@ -96,7 +96,7 @@ int erofs_map_blocks(struct erofs_inode *inode,
if (le32_to_cpu(*blkaddr) == EROFS_NULL_ADDR) {
map->m_flags = 0;
} else {
- map->m_pa = blknr_to_addr(le32_to_cpu(*blkaddr));
+ map->m_pa = erofs_pos(le32_to_cpu(*blkaddr));
map->m_flags = EROFS_MAP_MAPPED;
}
goto out;
@@ -110,7 +110,7 @@ int erofs_map_blocks(struct erofs_inode *inode,
default:
map->m_deviceid = le16_to_cpu(idx->device_id) &
sbi.device_id_mask;
- map->m_pa = blknr_to_addr(le32_to_cpu(idx->blkaddr));
+ map->m_pa = erofs_pos(le32_to_cpu(idx->blkaddr));
map->m_flags = EROFS_MAP_MAPPED;
break;
}
@@ -119,23 +119,23 @@ out:
return err;
}
-int erofs_map_dev(struct erofs_sb_info *sbi, struct erofs_map_dev *map)
+int erofs_map_dev(struct erofs_map_dev *map)
{
struct erofs_device_info *dif;
int id;
if (map->m_deviceid) {
- if (sbi->extra_devices < map->m_deviceid)
+ if (sbi.extra_devices < map->m_deviceid)
return -ENODEV;
- } else if (sbi->extra_devices) {
- for (id = 0; id < sbi->extra_devices; ++id) {
+ } else if (sbi.extra_devices) {
+ for (id = 0; id < sbi.extra_devices; ++id) {
erofs_off_t startoff, length;
- dif = sbi->devs + id;
+ dif = sbi.devs + id;
if (!dif->mapped_blkaddr)
continue;
- startoff = blknr_to_addr(dif->mapped_blkaddr);
- length =
[PATCH v5 04/23] j721e: schema: yaml: Add general schema and J721E board config files
Schema file in YAML must be provided in board/ti/common for validating input config files and packaging system firmware. The schema includes entries for rm-cfg, board-cfg, pm-cfg and sec-cfg. Board config files must be provided in board/ti/ in YAML. These can then be consumed for generation of binaries to package system firmware. Added YAML configs for J721E in particular. Signed-off-by: Tarun Sahu [n-fran...@ti.com: prepared patch for upstreaming] Signed-off-by: Neha Malcom Francis --- board/ti/common/schema.yaml | 436 + board/ti/j721e/board-cfg.yaml | 37 + board/ti/j721e/pm-cfg.yaml| 13 + board/ti/j721e/rm-cfg.yaml| 3174 + board/ti/j721e/sec-cfg.yaml | 381 5 files changed, 4041 insertions(+) create mode 100644 board/ti/common/schema.yaml create mode 100644 board/ti/j721e/board-cfg.yaml create mode 100644 board/ti/j721e/pm-cfg.yaml create mode 100644 board/ti/j721e/rm-cfg.yaml create mode 100644 board/ti/j721e/sec-cfg.yaml diff --git a/board/ti/common/schema.yaml b/board/ti/common/schema.yaml new file mode 100644 index 00..8023ecb0e0 --- /dev/null +++ b/board/ti/common/schema.yaml @@ -0,0 +1,436 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Config schema for TI K3 devices +# + +--- + +definitions: +u8: +type: integer +minimum: 0 +maximum: 0xff +u16: +type: integer +minimum: 0 +maximum: 0x +u32: +type: integer +minimum: 0 +maximum: 0x + + + +type: object +properties: +pm-cfg: +type: object +properties: +rev: +type: object +properties: +boardcfg_abi_maj: +$ref: "#/definitions/u8" +boardcfg_abi_min: +$ref: "#/definitions/u8" +board-cfg: +type: object +properties: +rev: +type: object +properties: +boardcfg_abi_maj: +$ref: "#/definitions/u8" +boardcfg_abi_min: +$ref: "#/definitions/u8" +control: +type: object +properties: +subhdr: +type: object +properties: +magic: +$ref: "#/definitions/u16" +size: +$ref: "#/definitions/u16" +main_isolation_enable: +$ref: "#/definitions/u8" +main_isolation_hostid: +$ref: "#/definitions/u16" + + +secproxy: +type: object +properties: +subhdr: +type: object +properties: +magic: +$ref: "#/definitions/u16" +size: +$ref: "#/definitions/u16" +scaling_factor: +$ref: "#/definitions/u8" +scaling_profile: +$ref: "#/definitions/u8" +disable_main_nav_secure_proxy: +$ref: "#/definitions/u8" + +msmc: +type: object +properties: +subhdr: +type: object +properties: +magic: +$ref: "#/definitions/u16" +size: +$ref: "#/definitions/u16" +msmc_cache_size: +$ref: "#/definitions/u8" +debug_cfg: +type: object +properties: +subhdr: +type: object +properties: +magic: +$ref: "#/definitions/u16" +size: +$ref: "#/definitions/u16" +trace_dst_enables: +$ref: "#/definitions/u16" +trace_src_enables: +$ref: "#/definitions/u16" + +sec-cfg: +type: object +properties: +rev: +type: object +properties: +boardcfg_abi_maj: +$ref: "#/definitions/u8" +boardcfg_abi_min: +$ref: "#/definitions/u8" + +processor_acl_list: +type: object +properties: +subhdr: +type: object +
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 19:35, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 7 Jul 2023 at 17:03, Jan Kiszka wrote:
>>
>> On 07.07.23 17:35, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
On 07.07.23 14:42, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>>
>> On 05.07.23 00:14, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
Hi Simon,
On 28.06.23 13:41, Simon Glass wrote:
> Collections can used to collect the contents of other entries into a
> single entry, but they result in a single entry, with the original
> entries
> 'left behind' in their old place.
>
> It is useful to be able to specific a set of entries ones and have it
> used
> in multiple images, or parts of an image.
>
> Implement this mechanism.
>
> Signed-off-by: Simon Glass
> ---
>
> tools/binman/binman.rst | 80
>
> tools/binman/control.py | 9 +++
> tools/binman/etype/section.py| 3 +-
> tools/binman/ftest.py| 8 +++
> tools/binman/test/286_entry_template.dts | 42 +
> 5 files changed, 141 insertions(+), 1 deletion(-)
> create mode 100644 tools/binman/test/286_entry_template.dts
>
> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> index a4b31fe5397b..9be979ae1c5b 100644
> --- a/tools/binman/binman.rst
> +++ b/tools/binman/binman.rst
> @@ -727,6 +727,13 @@ optional:
> Note that missing, optional blobs do not produce a non-zero exit
> code from
> binman, although it does show a warning about the missing
> external blob.
>
> +insert-template:
> +This is not strictly speaking an entry property, since it is
> processed early
> +in Binman before the entries are read. It is a list of phandles
> of nodes to
> +include in the current (target) node. For each node, its
> subnodes and their
> +properties are brought into the target node. See Templates_
> below for
> +more information.
> +
> The attributes supported for images and sections are described
> below. Several
> are similar to those for entries.
>
> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> going on, you can use
> arch/arm/dts/u-boot.dtsi ... found:
> "arch/arm/dts/juno-r2-u-boot.dtsi"
>
>
> +Templates
> +=
> +
> +Sometimes multiple images need to be created which have all have a
> common
> +part. For example, a board may generate SPI and eMMC images which
> both include
> +a FIT. Since the FIT includes many entries, it is tedious to repeat
> them twice
> +in the image description.
> +
> +Templates provide a simple way to handle this::
> +
> +binman {
> +multiple-images;
> +common_part: template-1 {
> +fit {
> +... lots of entries in here
> +};
> +
> +text {
> +text = "base image";
> +};
> +};
> +
> +spi-image {
> +filename = "image-spi.bin";
> +insert-template = <>;
> +
> +/* things specific to SPI follow */
> +header {
> +];
> +
> +text {
> +text = "SPI image";
> +};
> +};
> +
> +mmc-image {
> +filename = "image-mmc.bin";
> +insert-template = <>;
> +
> +/* things specific to MMC follow */
> +header {
> +];
> +
> +text {
> +text = "MMC image";
> +};
> +};
> +};
> +
> +The template node name must start with 'template', so it is not
> considered to be
> +an image itself.
> +
> +The mechanism is very simple. For each phandle in the
> 'insert-templates'
> +property, the source node is looked up. Then the subnodes of that
> source node
> +are copied into the target node, i.e. the one containing the
> `insert-template`
> +property.
> +
>
Re: [PATCH v14 11/11] arm_ffa: efi: corstone1000: enable MM communication
On Fri, Jul 07, 2023 at 11:35:05AM -0600, Simon Glass wrote: > Hi Abdellatif, > > On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi > wrote: > > > > turn on EFI MM communication > > > > On corstone1000 platform MM communication between u-boot > > and the secure world (Optee) is done using the FF-A bus. > > > > Signed-off-by: Abdellatif El Khlifi > > Cc: Tom Rini > > Cc: Simon Glass > > Cc: Ilias Apalodimas > > Cc: Jens Wiklander > > > > --- > > > > Changelog: > > === > > > > 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 | 1 + > > include/configs/corstone1000.h | 15 +-- > > 2 files changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig > > index a8a79fd105..b57e2322c4 100644 > > --- a/configs/corstone1000_defconfig > > +++ b/configs/corstone1000_defconfig > > @@ -65,3 +65,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y > > CONFIG_EFI_IGNORE_OSINDICATIONS=y > > CONFIG_FWU_MULTI_BANK_UPDATE=y > > CONFIG_ERRNO_STR=y > > +CONFIG_EFI_MM_COMM_TEE=y > > diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h > > index 3347c11792..4ef1f05e40 100644 > > --- a/include/configs/corstone1000.h > > +++ b/include/configs/corstone1000.h > > @@ -1,9 +1,11 @@ > > /* SPDX-License-Identifier: GPL-2.0+ */ > > /* > > - * (C) Copyright 2022 ARM Limited > > * (C) Copyright 2022 Linaro > > * Rui Miguel Silva > > - * Abdellatif El Khlifi > > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > > > + * > > + * Authors: > > + * Abdellatif El Khlifi > > * > > * Configuration for Corstone1000. Parts were derived from other ARM > > * configurations. > > @@ -14,6 +16,15 @@ > > > > #include > > > > +#define FFA_SHARED_MM_BUFFER_SIZE SZ_4K /* 4 KB */ > > + > > +/* > > + * shared buffer physical address used for communication between > > + * u-boot and the MM SP > > + */ > > +#define FFA_SHARED_MM_BUFFER_ADDR 0x0200UL > > +#define FFA_SHARED_MM_BUFFER_OFFSET0 > > + > > These should be in devicetree properties, shouldn't they? We don't > want things in board config.h files anymore. Wasn't one of the earlier debates on if the whole thing needs to be in device tree, or not, because it's a "discoverable bus" and so Linux wasn't needing one? I don't want to de-rail this series, which I think we're just about otherwise ready to merge, over that debate again. As these values have to match up (I assume) with the other side, are these truly per-board, or SoC dependent? -- Tom signature.asc Description: PGP signature
Re: [PATCH 08/10] cmd: add scmi command for SCMI firmware
Hi,
On Tue, 4 Jul 2023 at 02:26, AKASHI Takahiro wrote:
>
> On Mon, Jul 03, 2023 at 02:30:54PM +0100, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 3 Jul 2023 at 01:55, AKASHI Takahiro
> > wrote:
> > >
> > > On Thu, Jun 29, 2023 at 08:10:00PM +0100, Simon Glass wrote:
> > > > Hi AKASHI,
> > > >
> > > > On Wed, 28 Jun 2023 at 01:49, AKASHI Takahiro
> > > > wrote:
> > > > >
> > > > > This command, "scmi", provides a command line interface to various
> > > > > SCMI
> > > > > protocols. It supports at least initially SCMI base protocol with the
> > > > > sub
> > > > > command, "base", and is intended mainly for debug purpose.
> > > > >
> > > > > Signed-off-by: AKASHI Takahiro
> > > > > ---
> > > > > cmd/Kconfig | 8 ++
> > > > > cmd/Makefile | 1 +
> > > > > cmd/scmi.c | 373
> > > > > +++
> > > > > 3 files changed, 382 insertions(+)
> > > > > create mode 100644 cmd/scmi.c
> > > > >
> > > > > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > > > > index 02e54f1e50fe..065470a76295 100644
> > > > > --- a/cmd/Kconfig
> > > > > +++ b/cmd/Kconfig
> > > > > @@ -2504,6 +2504,14 @@ config CMD_CROS_EC
> > > > > a number of sub-commands for performing EC tasks such as
> > > > > updating its flash, accessing a small saved context area
> > > > > and talking to the I2C bus behind the EC (if there is one).
> > > > > +
> > > > > +config CMD_SCMI
> > > > > + bool "Enable scmi command"
> > > > > + depends on SCMI_FIRMWARE
> > > > > + default n
> > > > > + help
> > > > > + This command provides user interfaces to several SCMI
> > > > > protocols,
> > > > > + including Base protocol.
> > > >
> > > > Please mention what is SCMI
> > >
> > > I will give a full spelling.
> > >
> > > > > endmenu
> > > > >
> > > > > menu "Filesystem commands"
> > > > > diff --git a/cmd/Makefile b/cmd/Makefile
> > > > > index 6c37521b4e2b..826e0b74b587 100644
> > > > > --- a/cmd/Makefile
> > > > > +++ b/cmd/Makefile
> > > > > @@ -156,6 +156,7 @@ obj-$(CONFIG_CMD_SATA) += sata.o
> > > > > obj-$(CONFIG_CMD_NVME) += nvme.o
> > > > > obj-$(CONFIG_SANDBOX) += sb.o
> > > > > obj-$(CONFIG_CMD_SF) += sf.o
> > > > > +obj-$(CONFIG_CMD_SCMI) += scmi.o
> > > > > obj-$(CONFIG_CMD_SCSI) += scsi.o disk.o
> > > > > obj-$(CONFIG_CMD_SHA1SUM) += sha1sum.o
> > > > > obj-$(CONFIG_CMD_SEAMA) += seama.o
> > > > > diff --git a/cmd/scmi.c b/cmd/scmi.c
> > > > > new file mode 100644
> > > > > index ..c97f77e97d95
> > > > > --- /dev/null
> > > > > +++ b/cmd/scmi.c
> > > > > @@ -0,0 +1,373 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > +/*
> > > > > + * SCMI utility command
> > > > > + *
> > > > > + * Copyright (c) 2023 Linaro Limited
> > > > > + * Author: AKASHI Takahiro
> > > > > + */
> > > > > +
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include /* uclass_get_device */
> > > >
> > > > Goes before linux/bitfield.h
> > >
> > > Can you tell me why?
> >
> > It is just a convention:
> > https://u-boot.readthedocs.io/en/latest/develop/codingstyle.html#include-files
>
> Okay.
>
> > >
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > +
> > > > > +static struct udevice *agent;
> > > > > +static struct udevice *base_proto;
> > > > > +static const struct scmi_base_ops *ops;
> > > > > +
> > > > > +struct {
> > > > > + enum scmi_std_protocol id;
> > > > > + const char *name;
> > > > > +} protocol_name[] = {
> > > > > + {SCMI_PROTOCOL_ID_BASE, "Base"},
> > > > > + {SCMI_PROTOCOL_ID_POWER_DOMAIN, "Power domain management"},
> > > > > + {SCMI_PROTOCOL_ID_SYSTEM, "System power management"},
> > > > > + {SCMI_PROTOCOL_ID_PERF, "Performance domain management"},
> > > > > + {SCMI_PROTOCOL_ID_CLOCK, "Clock management"},
> > > > > + {SCMI_PROTOCOL_ID_SENSOR, "Sensor management"},
> > > > > + {SCMI_PROTOCOL_ID_RESET_DOMAIN, "Reset domain management"},
> > > > > + {SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN, "Voltage domain
> > > > > management"},
> > > > > +};
> > > > > +
> > > > > +/**
> > > > > + * scmi_convert_id_to_string() - get the name of SCMI protocol
> > > > > + *
> > > > > + * @id:Protocol ID
> > > > > + *
> > > > > + * Get the printable name of the protocol, @id
> > > > > + *
> > > > > + * Return: Name string on success, NULL on failure
> > > > > + */
> > > > > +static const char *scmi_convert_id_to_string(enum scmi_std_protocol
> > > > > id)
> > > >
> > > > scmi_lookup_id?
> > >
> > > Not sure your intention.
> > > The name above gives us exactly what this function does for pretty
> > > printing
> > > instead of a number.
> > > I think that 'lookup' implies we try to determine if the id exists or not.
> >
> > I am just trying to avoid the code turning into Java :-)
>
> Java?
Long names like stories
>
> > How about
Re: [PATCH v2] efi_driver: fix duplicate efiblk#0 issue
Hi Heinrich,
On Tue, 4 Jul 2023 at 00:43, Heinrich Schuchardt wrote:
>
> On 03.07.23 15:30, Simon Glass wrote:
> > Hi Masahisa,
> >
> > On Mon, 3 Jul 2023 at 07:09, Masahisa Kojima
> > wrote:
> >>
> >> The devnum value of the blk_desc structure starts from 0,
> >> current efi_bl_create_block_device() function creates
> >> two "efiblk#0" devices for the cases that blk_find_max_devnum()
> >> returns -ENODEV and blk_find_max_devnum() returns 0(one device
> >> found in this case).
> >>
> >> This commit uses blk_next_free_devnum() instead of blk_find_max_devnum().
> >>
>
> Fixes: 05ef48a2484b ("efi_driver: EFI block driver")
>
> >> Signed-off-by: Masahisa Kojima
> >> ---
> >> Changes in v2:
> >> - uses blk_next_free_devnum() instead of blk_find_max_devnum()
> >>
> >> lib/efi_driver/efi_block_device.c | 6 ++
> >> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/lib/efi_driver/efi_block_device.c
> >> b/lib/efi_driver/efi_block_device.c
> >> index add00eeebb..e3abd90275 100644
> >> --- a/lib/efi_driver/efi_block_device.c
> >> +++ b/lib/efi_driver/efi_block_device.c
> >> @@ -124,10 +124,8 @@ efi_bl_create_block_device(efi_handle_t handle, void
> >> *interface)
> >> struct efi_block_io *io = interface;
> >> struct efi_blk_plat *plat;
> >>
> >> - devnum = blk_find_max_devnum(UCLASS_EFI_LOADER);
>
> Simon, this line was last changed by your patch
> e33a5c6be55e ("blk: Switch over to using uclass IDs")
>
> >> - if (devnum == -ENODEV)
> >> - devnum = 0;
> >> - else if (devnum < 0)
> >> + devnum = blk_next_free_devnum(UCLASS_EFI_LOADER);
> >
> > This really should be an internal function but I see it was exported
> > as part of the virtio work.
> >
> > How come the EFI and DM block devices are getting out of sync?
>
> They never were in sync:
>
> The bug dates back to Jan 2018:
> 05ef48a2484b ("efi_driver: EFI block driver")
OK I see. Well it looks like the original code was a bit off, as per
my comment. It should be fixed.
>
> Best regards
>
> Heinrich
>
> >
> > Anyway this function is munging around in the internals of the device
> > and should be fixed before it causes more problems.
> >
> > For now, I suggest following what most other drivers so which is to
> > call blk_create_devicef() passing a devnum of -1.
> >
> >> + if (devnum < 0)
> >> return EFI_OUT_OF_RESOURCES;
> >>
> >> name = calloc(1, 18); /* strlen("efiblk#2147483648") + 1 */
> >> --
> >> 2.34.1
Regards,
Simon
Re: [PATCH 07/10] test: dm: add SCMI base protocol test
Hi,
On Tue, 4 Jul 2023 at 03:35, AKASHI Takahiro wrote:
>
> Hi Simon,
>
> On Mon, Jul 03, 2023 at 02:30:57PM +0100, Simon Glass wrote:
> > Hi,
> >
> > On Mon, 3 Jul 2023 at 01:57, AKASHI Takahiro
> > wrote:
> > >
> > > On Thu, Jun 29, 2023 at 08:09:58PM +0100, Simon Glass wrote:
> > > > Hi AKASHI,
> > > >
> > > > On Wed, 28 Jun 2023 at 01:49, AKASHI Takahiro
> > > > wrote:
> > > > >
> > > > > Added is a new unit test for SCMI base protocol, which will exercise
> > > > > all
> > > > > the commands provided by the protocol, except SCMI_BASE_NOTIFY_ERRORS.
> > > > > $ ut dm scmi_base
> > > > > It is assumed that test.dtb is used as sandbox's device tree.
> > > > >
> > > > > Signed-off-by: AKASHI Takahiro
> > > > > ---
> > > > > test/dm/scmi.c | 112
> > > > > +
> > > > > 1 file changed, 112 insertions(+)
> > > > >
> > > > > diff --git a/test/dm/scmi.c b/test/dm/scmi.c
> > > > > index 881be3171b7c..563017bb63e0 100644
> > > > > --- a/test/dm/scmi.c
> > > > > +++ b/test/dm/scmi.c
> > > > > @@ -16,6 +16,9 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > +#include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > @@ -95,6 +98,115 @@ static int dm_test_scmi_sandbox_agent(struct
> > > > > unit_test_state *uts)
> > > > > }
> > > > > DM_TEST(dm_test_scmi_sandbox_agent, UT_TESTF_SCAN_FDT);
> > > > >
> > > > > +static int dm_test_scmi_base(struct unit_test_state *uts)
> > > > > +{
> > > > > + struct udevice *agent_dev, *base;
> > > > > + struct scmi_agent_priv *priv;
> > > > > + const struct scmi_base_ops *ops;
> > > > > + u32 version, num_agents, num_protocols, impl_version;
> > > > > + u32 attributes, agent_id;
> > > > > + char vendor[SCMI_BASE_NAME_LENGTH_MAX],
> > > > > +agent_name[SCMI_BASE_NAME_LENGTH_MAX];
> > > > > + u8 *protocols;
> > > > > + int ret;
> > > > > +
> > > > > + /* preparation */
> > > > > + ut_assertok(uclass_get_device_by_name(UCLASS_SCMI_AGENT,
> > > > > "scmi",
> > > > > + _dev));
> > > > > + ut_assertnonnull(agent_dev);
> > > > > + ut_assertnonnull(priv = dev_get_uclass_plat(agent_dev));
> > > > > + ut_assertnonnull(base = scmi_get_protocol(agent_dev,
> > > > > +
> > > > > SCMI_PROTOCOL_ID_BASE));
> > > > > + ut_assertnonnull(ops = dev_get_driver_ops(base));
> > > > > +
> > > > > + /* version */
> > > > > + ret = (*ops->protocol_version)(base, );
> > > >
> > > > Can you add uclass helpers to call each of the methods? That is how it
> > > > is commonly done. You should not be calling ops->xxx directly here.
> > >
> > > Yes, I will add inline functions instead.
> >
> > I don't mean inline...see all the other uclasses which define a
>
> Okay, I will *real* functions.
>
> > function which is implemented in the uclass. It is confusing when one
> > uclass does something different. People might copy this style and then
> > the code base diverges. Did you not notice this when looking around
> > the source tree?
>
> But one concern came up in my mind.
> Contrary to ordinary "device controllers", there exists only a single
> implementation of driver for each of "udevice"'s associated with SCMI
> protocols including the base protocol.
>
> So if I follow your suggestion, the code (base.c) might look like:
> ===
> static int __scmi_base_discover_vendor(struct udevice *dev, u8 *vendor)
> {
> ...
> }
>
> struct scmi_base_ops scmi_base_ops = {
>
> .base_discover_vendor = __scmi_base_discover_vendor,
>
> }
>
> int scmi_base_discover_vendor(struct udevice *dev, u8 *vendor)
> {
> struct scmi_base_ops *ops;
>
> ops = scmi_base_dev_ops(dev);
>
> return ops->base_discover_vendor(dev, vendor);
> }
> ===
>
> We will have to have similar definitions for every operation in ops.
> It looks quite weird to me as there are always pairs of functions,
> like __scmi_base_discover_vendor() and scmi_base_discover_vendor().
Yes I understand that you only have one driver at present. Is there
not a sandbox driver?
>
> We can avoid this redundant code easily by eliminating "ops" abstraction.
> But as far as I remember, you insist that every driver that complies
> to U-Boot driver model should have a "ops".
>
> What do you make of this?
Well there are some exceptions, but yes that is the idea. Operations
should be in a 'ops' struct and documented and implemented in a
consistent way.
Regards,
Simon
Re: [PATCH] env: Fix default environment saving issue
On Tue, 4 Jul 2023 at 07:16, Ashok Reddy Soma wrote:
>
> When CONFIG_SYS_REDUNDAND_ENVIRONMENT is enabled, by default env is
> getting saved to redundant environment irrespective of primary env is
> present or not.
>
> It means even if primary and redundant environment are not present, by
> default, env is getting stored to redundant environment. Even if primary
> env is present, it is choosing to store in redudndant env.
>
> Ideally it should look for primary env and choose to store in primary env
> if it is present. If both primary and redundant env are not present then
> it should save in to primary env area.
>
> Fix the issue by making env_valid = ENV_INVALID when both the
> environments are not present.
>
> Signed-off-by: Ashok Reddy Soma
> ---
>
> env/common.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Simon Glass
Can a test be added for this?
> diff --git a/env/common.c b/env/common.c
> index 8beb8e6aa4..0ecdb248a0 100644
> --- a/env/common.c
> +++ b/env/common.c
> @@ -353,6 +353,7 @@ int env_check_redund(const char *buf1, int buf1_read_fail,
> tmp_env2->crc;
>
> if (!crc1_ok && !crc2_ok) {
> + gd->env_valid = ENV_INVALID;
> return -ENOMSG; /* needed for env_load() */
> } else if (crc1_ok && !crc2_ok) {
> gd->env_valid = ENV_VALID;
> --
> 2.17.1
>
Re: [PATCH v2 11/11] binman: etype: Add xilinx_fsbl_auth etype
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
> This adds a new etype 'xilinx_fsbl_auth'. Using this etype it is possible
> to created an authenticated 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 seconrady
> 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_fsbl_auth {
> psk-filename = "psk0.pem";
> ssk-filename = "ssk0.pem";
> 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
>
> ---
>
> 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 | 53 ++
> tools/binman/etype/xilinx_fsbl_auth.py | 213 +
> 2 files changed, 266 insertions(+)
> create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py
>
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index c3c5bda881..98ec3c82a5 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -2462,3 +2462,56 @@ may be used instead.
>
>
>
> +.. _etype_xilinx_fsbl_auth:
> +
> +Entry: xilinx-fsbl-auth: Authenticated SPL for booting 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-filename: Filename of primary public key
> +- ssk-filename: Filename of secondary public key
> +
> +The following example builds an authenticated 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-fsbl-auth {
> +psk-filename = "psk0.pem";
> +ssk-filename = "ssk0.pem";
> +auth-params = "ppk_select=0", "spk_id=0x";
> +
> +u-boot-spl-nodtb {
> +};
> +u-boot-spl-pubkey-dtb {
> +algo = "sha384,rsa4096";
> +required = "conf";
> +key-name = "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-fsbl-auth {
> +psk-filename = "psk0.pem";
> +ssk-filename = "ssk0.pem";
> +...
> +fsbl-config = "bh_auth_enable";
> +...
> +};
> +
> +
> +
> diff --git a/tools/binman/etype/xilinx_fsbl_auth.py
> b/tools/binman/etype/xilinx_fsbl_auth.py
> new file mode 100644
> index 00..72794ad2bc
> --- /dev/null
> +++ b/tools/binman/etype/xilinx_fsbl_auth.py
> @@ -0,0 +1,213 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (c) 2023 Weidmueller GmbH
> +# Written by Lukas Funke
> +#
> +# Entry-type module for signed ZynqMP boot images (boot.bin)
> +#
> +
> +import tempfile
> +
> +from collections import OrderedDict
> +
> +from binman import elf
> +from binman.entry import Entry
> +
> +from dtoc import fdt_util
> +
> +from u_boot_pylib import tools
> +from u_boot_pylib import command
> +
> +# pylint: disable=C0103
> +class Entry_xilinx_fsbl_auth(Entry):
> +"""Authenticated SPL for booting 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-filename: Filename of primary public key
> +- ssk-filename: Filename of secondary public key
Can you link to some docs that explains what all of these really are,
e.g. format of files.
> +
> +The
Re: [PATCH v2 00/11] Sign Xilinx ZynqMP SPL/FSBL boot images using binman
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
>
> This series adds two etypes to create a verified boot chain for
> Xilinx ZynqMP devices. The first etype 'xilinx_fsbl_auth' is used to
> create a bootable, signed image for ZynqMP boards using the Xilinx
> Bootgen tool. The second etype 'u_boot_spl_pubkey_dtb' is used to add
> a '/signature' node to the SPL. The public key in the signature is read
> from a certificate file and added using the 'fdt_add_pubkey' tool. The
> series also contains the corresponding btool for calling 'bootgen' and
> 'fdt_add_pubkey'
>
> The following block shows an example on how to use this functionality:
>
> spl {
> filename = "boot.signed.bin";
>
> xilinx_fsbl_auth {
> psk-filename = "psk0.pem";
> ssk-filename = "ssk0.pem";
> auth-params = "ppk_select=0", "spk_id=0x";
>
> u_boot_spl_nodtb {
> };
> u_boot_spl_pubkey_dtb {
> algo = "sha384,rsa4096";
> required = "conf";
> key-name = "dev";
> };
> };
> };
>
>
> Changes in v2:
> - Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb
> - Improved rst/python documentation
> - Changed u_boot_spl_pubkey_dtb to u-boot-spl-pubkey-dtb in example
> - 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 (11):
> binman: elf: Check for ELF_TOOLS availability and remove extra
> semicolon
> binman: Don't decompress data while signing
> binman: blob_dtb: Add fake_size argument to ObtainContents()
> binman: doc: Add documentation for fdt_add_pubkey bintool
> binman: ftest: Add test for u_boot_spl_pubkey_dtb
> binman: btool: Add fdt_add_pubkey as btool
> binman: etype: Add u_boot_spl_pubkey_dtb etype
> binman: doc: Add documentation for Xilinx Bootgen bintool
> binman: btool: Add Xilinx Bootgen btool
> binman: ftest: Add test for xilinx_fsbl_auth etype
> binman: etype: Add xilinx_fsbl_auth etype
>
> tools/binman/bintools.rst | 22 ++
> tools/binman/btool/bootgen.py | 136 +
> tools/binman/btool/fdt_add_pubkey.py| 67 ++
> tools/binman/control.py | 2 +-
> tools/binman/elf.py | 10 +-
> tools/binman/entries.rst| 92 +
> tools/binman/etype/blob_dtb.py | 2 +-
> tools/binman/etype/u_boot_spl_pubkey_dtb.py | 109 ++
> tools/binman/etype/xilinx_fsbl_auth.py | 213
> tools/binman/ftest.py | 42 +++-
> tools/binman/test/280_xilinx_fsbl_auth.dts | 23 +++
> tools/binman/test/281_spl_pubkey_dtb.dts| 16 ++
> 12 files changed, 727 insertions(+), 7 deletions(-)
> create mode 100644 tools/binman/btool/bootgen.py
> create mode 100644 tools/binman/btool/fdt_add_pubkey.py
> create mode 100644 tools/binman/etype/u_boot_spl_pubkey_dtb.py
> create mode 100644 tools/binman/etype/xilinx_fsbl_auth.py
> create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
> create mode 100644 tools/binman/test/281_spl_pubkey_dtb.dts
>
> --
> 2.30.2
>
This looks pretty good to me. I've made comments on individual
patches. Please do make sure that the docs are enough to understand
the feature - e.g. describing each field. You may need to link to some
'forever' docs somewhere too.
Regards,
Simon
Re: [PATCH v1 1/2] drivers: firmware: introduce Meson Secure Monitor driver
Hi Alexey, On Fri, 7 Jul 2023 at 09:43, Alexey Romanov wrote: > > Hello, Simon! > > On Thu, Jul 06, 2023 at 09:58:02AM -0600, Simon Glass wrote: > > Hi Alexey, > > > > On Thu, 6 Jul 2023 at 14:16, Alexey Romanov > > wrote: > > > > > > At the moment, only smc API is a set of functions in > > > arch/arm/mach-meson/sm.c. This approach is hard to configure > > > and also doesni't contain any generic API for calling smc. > > > > > > This patch add Meson SM driver with generic API (struct meson_sm_ops): > > > > > > - sm_call() > > > - sm_call_write() > > > - sm_call_read() > > > > > > A typical driver usage example is shown here: > > > > > > 1. uclass_get_device_by_driver(UCLASS_FIRMWARE, "secure-monitor", ); > > > 2. handle = meson_sm_get_handle(dev); > > > 3. handle->ops.sm_call(dev, cmd, ...); > > > > > > Signed-off-by: Alexey Romanov > > > --- > > > arch/arm/mach-meson/Kconfig | 1 + > > > drivers/firmware/Kconfig | 10 ++ > > > drivers/firmware/Makefile | 1 + > > > drivers/firmware/meson/Kconfig| 6 + > > > drivers/firmware/meson/Makefile | 3 + > > > drivers/firmware/meson/meson_sm.c | 217 ++ > > > include/meson/sm_handle.h | 38 ++ > > > 7 files changed, 276 insertions(+) > > > create mode 100644 drivers/firmware/meson/Kconfig > > > create mode 100644 drivers/firmware/meson/Makefile > > > create mode 100644 drivers/firmware/meson/meson_sm.c > > > create mode 100644 include/meson/sm_handle.h > > > > Please can you use the remoteproc uclass for this and add a proper driver? > > > > I don't see it architecturally well. Can you explain please? > > This driver is just ARM SMC fw interface. There seems to be nothing to > do here for remoteproc uclass. Well you seem to be implementing a remote CPU interface, which is what remoteproc is for. How does Linux do this? Also there is a pending series on FFA - is that related? It uses smc from what I can tell. Regards, Simon
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 17:03, Jan Kiszka wrote:
>
> On 07.07.23 17:35, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
> >>
> >> On 07.07.23 14:42, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>
> On 05.07.23 00:14, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
> >>
> >> Hi Simon,
> >>
> >> On 28.06.23 13:41, Simon Glass wrote:
> >>> Collections can used to collect the contents of other entries into a
> >>> single entry, but they result in a single entry, with the original
> >>> entries
> >>> 'left behind' in their old place.
> >>>
> >>> It is useful to be able to specific a set of entries ones and have it
> >>> used
> >>> in multiple images, or parts of an image.
> >>>
> >>> Implement this mechanism.
> >>>
> >>> Signed-off-by: Simon Glass
> >>> ---
> >>>
> >>> tools/binman/binman.rst | 80
> >>>
> >>> tools/binman/control.py | 9 +++
> >>> tools/binman/etype/section.py| 3 +-
> >>> tools/binman/ftest.py| 8 +++
> >>> tools/binman/test/286_entry_template.dts | 42 +
> >>> 5 files changed, 141 insertions(+), 1 deletion(-)
> >>> create mode 100644 tools/binman/test/286_entry_template.dts
> >>>
> >>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> >>> index a4b31fe5397b..9be979ae1c5b 100644
> >>> --- a/tools/binman/binman.rst
> >>> +++ b/tools/binman/binman.rst
> >>> @@ -727,6 +727,13 @@ optional:
> >>> Note that missing, optional blobs do not produce a non-zero exit
> >>> code from
> >>> binman, although it does show a warning about the missing
> >>> external blob.
> >>>
> >>> +insert-template:
> >>> +This is not strictly speaking an entry property, since it is
> >>> processed early
> >>> +in Binman before the entries are read. It is a list of phandles
> >>> of nodes to
> >>> +include in the current (target) node. For each node, its
> >>> subnodes and their
> >>> +properties are brought into the target node. See Templates_
> >>> below for
> >>> +more information.
> >>> +
> >>> The attributes supported for images and sections are described
> >>> below. Several
> >>> are similar to those for entries.
> >>>
> >>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> >>> going on, you can use
> >>> arch/arm/dts/u-boot.dtsi ... found:
> >>> "arch/arm/dts/juno-r2-u-boot.dtsi"
> >>>
> >>>
> >>> +Templates
> >>> +=
> >>> +
> >>> +Sometimes multiple images need to be created which have all have a
> >>> common
> >>> +part. For example, a board may generate SPI and eMMC images which
> >>> both include
> >>> +a FIT. Since the FIT includes many entries, it is tedious to repeat
> >>> them twice
> >>> +in the image description.
> >>> +
> >>> +Templates provide a simple way to handle this::
> >>> +
> >>> +binman {
> >>> +multiple-images;
> >>> +common_part: template-1 {
> >>> +fit {
> >>> +... lots of entries in here
> >>> +};
> >>> +
> >>> +text {
> >>> +text = "base image";
> >>> +};
> >>> +};
> >>> +
> >>> +spi-image {
> >>> +filename = "image-spi.bin";
> >>> +insert-template = <>;
> >>> +
> >>> +/* things specific to SPI follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "SPI image";
> >>> +};
> >>> +};
> >>> +
> >>> +mmc-image {
> >>> +filename = "image-mmc.bin";
> >>> +insert-template = <>;
> >>> +
> >>> +/* things specific to MMC follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "MMC image";
> >>> +};
> >>> +};
> >>> +};
> >>> +
> >>> +The template node name must start with 'template', so it is not
> >>> considered to be
> >>> +an image itself.
> >>> +
> >>> +The mechanism is very simple. For each phandle in the
> >>> 'insert-templates'
> >>> +property, the source node is looked up. Then the subnodes of that
> >>> source node
> >>> +are copied into the target node, i.e. the one containing the
> >>> `insert-template`
> >>> +property.
> >>> +
> >>> +If the target node has a node with the same
Re: [PATCH 09/10] doc: cmd: add documentation for scmi
Hi, On Tue, 4 Jul 2023 at 03:05, AKASHI Takahiro wrote: > > Hi Simon, > > On Mon, Jul 03, 2023 at 02:30:55PM +0100, Simon Glass wrote: > > Hi , > > > > On Mon, 3 Jul 2023 at 02:19, AKASHI Takahiro > > wrote: > > > > > > On Thu, Jun 29, 2023 at 08:10:02PM +0100, Simon Glass wrote: > > > > Hi AKASHI, > > > > > > > > On Wed, 28 Jun 2023 at 01:49, AKASHI Takahiro > > > > wrote: > > > > > > > > > > This is a help text for scmi command. > > > > > > > > > > Signed-off-by: AKASHI Takahiro > > > > > --- > > > > > doc/usage/cmd/scmi.rst | 98 > > > > > ++ > > > > > 1 file changed, 98 insertions(+) > > > > > create mode 100644 doc/usage/cmd/scmi.rst > > > > > > > > > > diff --git a/doc/usage/cmd/scmi.rst b/doc/usage/cmd/scmi.rst > > > > > new file mode 100644 > > > > > index ..20cdae4b877d > > > > > --- /dev/null > > > > > +++ b/doc/usage/cmd/scmi.rst > > > > > @@ -0,0 +1,98 @@ > > > > > +.. SPDX-License-Identifier: GPL-2.0+: > > > > > + > > > > > +scmi command > > > > > + > > > > > + > > > > > +Synopsis > > > > > + > > > > > + > > > > > +:: > > > > > + > > > > > +scmi base info > > > > > +scmi base perm_dev > > > > > +scmi base perm_proto > > > > > +scmi base reset > > > > > + > > > > > +Description > > > > > +--- > > > > > + > > > > > +The scmi command is used to access and operate on SCMI server. > > > > > + > > > > > +scmi base info > > > > > +~~ > > > > > +Show base information about SCMI server and supported protocols > > > > > + > > > > > +scmi base perm_dev > > > > > +~~ > > > > > +Allow or deny access permission to the device > > > > > + > > > > > +scmi base perm_proto > > > > > + > > > > > +Allow or deny access to the protocol on the device > > > > > + > > > > > +scmi base reset > > > > > +~~~ > > > > > +Reset the existing configurations > > > > > + > > > > > +Parameters are used as follows: > > > > > + > > > > > + > > > > > +Agent ID > > > > > > > > what is this? > > > > > > I thought that the meaning was trivial in SCMI context. > > > Will change it to "SCMI Agent ID". > > > > What is SCMI? Really you should explain and link to information about > > things you mention in documentation. How else is anyone supposed to > > Generally yes, but please note that SCMI and related drivers are already > there in U-Boot. For instance, see drivers/firmware/scmi/Kconfig. > I don't think we need any more explanation about what is SCMI everywhere > the word, "SCMI", appears. > > > figure out what you are talking about? > > Again, those who don't know about SCMI and if SCMI server is installed > on their systems will never use this command. > > > > > "SCMI Agent ID" doesn't tell us much. What form does it take? Is it a > > string? How do you find it out? > > While I still believe that What SCMI agent ID means is trivial for > those who read the SCMI specification, I will give a short description > about possible values. > > > > > > > > > > > > + > > > > > + > > > > > +Device ID > > > > > > > > what is this? > > > > > > Again, will change it to "SCMI Device ID". > > > > That doesn't help much. The purpose of documentation is to explain > > things for people who don't already know it. We need to try to be as > > helpful as possible. > > The same above. > Please note that the definition of "device (ID)", except its data type, > is out of scope of SCMI specification. > It doesn't describe any means by which values be identified/retrieved. > > > > > > > > > + > > > > > + > > > > > +Protocol ID, should not be 0x10 (base protocol) > > > > > > > > what is this? Please add more detail > > > > > > Again, will change it to "SCMI Protocol ID". > > > I think that users should be familiar with those terms > > > if they want to use these interfaces. > > > > Maybe, but it still isn't clear what it is. A string? > > Will add a short description about its data type/format. > > > It is confusing > > that the command ID is also a protocol ID. > > Yes, I know, but the confusion exists in SCMI specification. > It sometimes seems to use both words almost interchangeably, even > in a single context. For instance, the section 4.2.2.11 of [1] > says, > > 4.2.2.11 BASE_SET_PROTOCOL_PERMISSIONS > ... > This command BASE_SET_PROTOCOL_PERMISSIONS is used to ... > (This "command" has a yet another meaning.) > > Parameters > uint32_t command_id Bits[31:8] Reserved, must be zero > Bits[7:0] Protocol ID > > [1] https://developer.arm.com/documentation/den0056/e/?lang=en > > So using "command_id" for a parameter name and "Protocol ID" > as a (part of) value is very much aligned with the specification. > > That said, I will change "command_id" to "protocol_id" for now. > > > > > > > > > + > > > > > + > > > > > +Flags to control the action. See SCMI specification for > > > > > +defined values. > > > > > > > > ? > > > >
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On Fri, 7 Jul 2023 at 13:36, Neha Malcom Francis wrote: > > Move to using binman to generate tispl.bin which is used to generate the > final flash.bin bootloader for iot2050 boards. > > Signed-off-by: Neha Malcom Francis > Cc: Jan Kiszka > --- > arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++- > 1 file changed, 74 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH v5 21/23] binman: Overwrite symlink if it already exists
Hi Neha, On Fri, 7 Jul 2023 at 13:37, Neha Malcom Francis wrote: > > From: Andrew Davis > > Without this re-building will fail with an error when trying to create > the symlink for the second time with an already exists error. > > Signed-off-by: Andrew Davis > Signed-off-by: Neha Malcom Francis > --- > tools/binman/image.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/tools/binman/image.py b/tools/binman/image.py > index 8ebf71d61a..e77b5d0d97 100644 > --- a/tools/binman/image.py > +++ b/tools/binman/image.py > @@ -182,6 +182,8 @@ class Image(section.Entry_section): > # Create symlink to file if symlink given > if self._symlink is not None: > sname = tools.get_output_filename(self._symlink) > +if os.path.islink(sname): > +os.remove(sname) > os.symlink(fname, sname) > > def WriteMap(self): > -- > 2.34.1 > This breaks test coverage. Please add a test to ftest.py. You can probably run _DoTestFile() on an output directory with a in it? Regards, Simon
Re: [PATCH v5 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
Hi Neha, On Fri, 7 Jul 2023 at 13:36, Neha Malcom Francis wrote: > > Support added for HS and GP boot binaries for AM64x. > > HS-SE: > * tiboot3-am64x_sr2-hs-evm.bin > * tispl.bin > * u-boot.img > > HS-FS: > * tiboot3-am64x_sr2-hs-fs-evm.bin > * tispl.bin > * u-boot.img > > GP: > * tiboot3.bin --> tiboot3-am64x-gp-evm.bin > * tispl.bin_unsigned > * u-boot.img_unsigned > > Note that the bootflow followed by AM64x requires: > > tiboot3.bin: > * R5 SPL > * R5 SPL dtbs > * sysfw > * board-cfg > * pm-cfg > * sec-cfg > * rm-cfg > > tispl.bin: > * ATF > * OPTEE > * A53 SPL > * A53 SPL dtbs > > u-boot.img: > * A53 U-Boot > * A53 U-Boot dtbs > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > [a...@ti.com: changed output binary names appropriately] > Signed-off-by: Andrew Davis > --- > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 + > arch/arm/dts/k3-am642-r5-evm.dts | 1 + > arch/arm/dts/k3-am642-sk-u-boot.dtsi | 2 + > arch/arm/dts/k3-am64x-binman.dtsi | 515 ++ > board/ti/am64x/Kconfig| 2 + > 5 files changed, 522 insertions(+) > create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi It looks like the template feature (see pending patches) might help reduce the size of the .dtsi, but we can worry about that later. Regards, Simon
Re: [PATCH v5 03/23] arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin
On Fri, 7 Jul 2023 at 13:35, Neha Malcom Francis wrote: > > Board config binary artifacts must be generated to be used by binman to > package sysfw.itb and tiboot3.bin for all K3 devices. > > For devices that follow combined flow, these board configuration > binaries must again be packaged into a combined board configuration > blobs to be used by binman to package tiboot3.bin. > > Add common k3-binman.dtsi to generate all the board configuration > binaries needed. > > Also add custMpk.pem and ti-degenerate-key.pem needed for signing GP and > HS bootloader images common to all K3 devices. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/dts/k3-binman.dtsi | 116 > 1 file changed, 116 insertions(+) > create mode 100644 arch/arm/dts/k3-binman.dtsi > Reviewed-by: Simon Glass
Re: [PATCH v2 09/11] binman: btool: Add Xilinx Bootgen btool
Hi Lukas, On Thu, 6 Jul 2023 at 09:38, 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 v2: > - Pass additional 'keysrc_enc' parameter to Bootgen > - Added more information and terms to documentation > > tools/binman/btool/bootgen.py | 136 ++ > 1 file changed, 136 insertions(+) > create mode 100644 tools/binman/btool/bootgen.py > This does not work for me: binman tool -f missing Fetching tools: bootgen bzip2 cbfstool fdt_add_pubkey fiptool futility gzip ifwitool lz4 lzma_alone lzop mkimage openssl xz zstd Fetch: bootgen - trying method: binary download - trying method: build from source - clone git repo 'https://github.com/Xilinx/bootgen' to '/tmp/binmanf.qq6wo7tw' - build target 'all' - File '/tmp/binmanf.qq6wo7tw/build/bootgen/bootgen' was not produced - failed to fetch with all methods Otherwise it looks good. > diff --git a/tools/binman/btool/bootgen.py b/tools/binman/btool/bootgen.py > new file mode 100644 > index 00..a30268c964 > --- /dev/null > +++ b/tools/binman/btool/bootgen.py > @@ -0,0 +1,136 @@ > +# 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 > + > +""" > +import tempfile > + > +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='') > + > +# 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 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' (ppk). 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 Loder). 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 secondardy 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 aktual 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 > +
Re: [PATCH v2 10/11] binman: ftest: Add test for xilinx_fsbl_auth etype
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
> Add test for the 'xilinx_fsbl_auth' etype
>
> Signed-off-by: Lukas Funke
>
> ---
>
> Changes in v2:
> - Fixed typo in dts name
>
> tools/binman/ftest.py | 8
> tools/binman/test/280_xilinx_fsbl_auth.dts | 23 ++
> 2 files changed, 31 insertions(+)
> create mode 100644 tools/binman/test/280_xilinx_fsbl_auth.dts
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 0ee0ce1155..27a8a37864 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6686,6 +6686,14 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> ['fit'])
> self.assertIn("Node '/fit': Missing tool: 'mkimage'",
> str(e.exception))
>
> +def testXilinxFsblAuth(self):
> +"""Test xilinx_fsbl_auth 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('280_xilinx_fsbl_auth.dts')
Can you check something in the image to see it is there?
>
> def testSplPubkeyDtb(self):
> """Test u_boot_spl_pubkey_dtb etype"""
> diff --git a/tools/binman/test/280_xilinx_fsbl_auth.dts
> b/tools/binman/test/280_xilinx_fsbl_auth.dts
> new file mode 100644
> index 00..a37c5aa072
> --- /dev/null
> +++ b/tools/binman/test/280_xilinx_fsbl_auth.dts
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + xilinx-fsbl-auth {
> + filename = "boot.bin";
> +
> + psk-filename = "psk.pem";
> + ssk-filename = "ssk.pem";
> + auth-params = "ppk_select=0", "spk_id=0x";
> +
> + u-boot-spl-nodtb {
> + };
> + u-boot-spl-dtb {
> + };
> + };
> + };
> +};
> --
> 2.30.2
>
Regards,
Simon
Re: [PATCH v2 01/11] binman: elf: Check for ELF_TOOLS availability and remove extra semicolon
Hi Lukas,
On Thu, 6 Jul 2023 at 09:38, wrote:
>
> From: Lukas Funke
>
> Check if elf tools are available when running DecodeElf(). Also
> remove superfuous semicolon at line ending.
>
> Signed-off-by: Lukas Funke
> Reviewed-by: Simon Glass
> ---
>
> (no changes since v1)
>
> tools/binman/elf.py | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/tools/binman/elf.py b/tools/binman/elf.py
> index 5816284c32..a53f4b9c4f 100644
> --- a/tools/binman/elf.py
> +++ b/tools/binman/elf.py
> @@ -438,13 +438,15 @@ def DecodeElf(data, location):
> Returns:
> ElfInfo object containing information about the decoded ELF file
> """
> +if not ELF_TOOLS:
> +raise ValueError("Python: No module named 'elftools'")
Actually this is missing test coverage. See testEmbedFail() for an
example of how to add it for this function.
Use 'binman test -T' to see test coverage.
> file_size = len(data)
> with io.BytesIO(data) as fd:
> elf = ELFFile(fd)
> -data_start = 0x;
> -data_end = 0;
> -mem_end = 0;
> -virt_to_phys = 0;
> +data_start = 0x
> +data_end = 0
> +mem_end = 0
> +virt_to_phys = 0
>
> for i in range(elf.num_segments()):
> segment = elf.get_segment(i)
> --
> 2.30.2
>
Regards,
Simon
Re: [PATCH v2 3/3] binman: Add tests for etype encrypted
Hi Christian,
On Tue, 4 Jul 2023 at 10:03, wrote:
>
> From: Christian Taedcke
>
> Add tests to reach 100% code coverage for the added etype encrypted.
>
> Signed-off-by: Christian Taedcke
> ---
>
> Changes in v2:
> - adapt tests for changed entry implementation
>
> tools/binman/ftest.py | 52 +++
> .../binman/test/282_encrypted_no_content.dts | 15 ++
> tools/binman/test/283_encrypted_no_algo.dts | 19 +++
> .../test/284_encrypted_invalid_iv_file.dts| 23
> .../binman/test/285_encrypted_missing_key.dts | 28 ++
> .../binman/test/286_encrypted_key_source.dts | 29 +++
> tools/binman/test/287_encrypted_key_file.dts | 29 +++
> 7 files changed, 195 insertions(+)
> create mode 100644 tools/binman/test/282_encrypted_no_content.dts
> create mode 100644 tools/binman/test/283_encrypted_no_algo.dts
> create mode 100644 tools/binman/test/284_encrypted_invalid_iv_file.dts
> create mode 100644 tools/binman/test/285_encrypted_missing_key.dts
> create mode 100644 tools/binman/test/286_encrypted_key_source.dts
> create mode 100644 tools/binman/test/287_encrypted_key_file.dts
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 43b4f850a6..d51139799f 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -94,6 +94,8 @@ ROCKCHIP_TPL_DATA = b'rockchip-tpl'
> TEST_FDT1_DATA= b'fdt1'
> TEST_FDT2_DATA= b'test-fdt2'
> ENV_DATA = b'var1=1\nvar2="2"'
> +ENCRYPTED_IV_DATA = b'123456'
> +ENCRYPTED_KEY_DATA= b'1234567890123456'
Can you make that different, e.g. abcd, since at present one is a
subset of the other. Does the length matter? If not, shorter is better
for the second one, so we can visually look at the output.
> PRE_LOAD_MAGIC= b'UBSH'
> PRE_LOAD_VERSION = 0x11223344.to_bytes(4, 'big')
> PRE_LOAD_HDR_SIZE = 0x1000.to_bytes(4, 'big')
> @@ -226,6 +228,10 @@ class TestFunctional(unittest.TestCase):
> # Newer OP_TEE file in v1 binary format
> cls.make_tee_bin('tee.bin')
>
> +# test files for encrypted tests
> +TestFunctional._MakeInputFile('encrypted-file.iv', ENCRYPTED_IV_DATA)
> +TestFunctional._MakeInputFile('encrypted-file.key',
> ENCRYPTED_KEY_DATA)
> +
> cls.comp_bintools = {}
> for name in COMP_BINTOOLS:
> cls.comp_bintools[name] = bintool.Bintool.create(name)
> @@ -6676,6 +6682,52 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> ['fit'])
> self.assertIn("Node '/fit': Missing tool: 'mkimage'",
> str(e.exception))
>
> +def testEncryptedNoContent(self):
"""Test for missing content property"""
Please add a comment to following test functions
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('282_encrypted_no_content.dts')
> +self.assertIn("Node '/binman/fit/images/u-boot/encrypted':
> Collection must have a 'content' property", str(e.exception))
Please wrap to 80cols. It is OK not to split strings though, but
otherwise, please keep to 80.
self.assertIn(
"Node '/binman/fit/images/u-boot/encrypted': Collection must have
a 'content' property",
str(e.exception))
same below
> +
> +def testEncryptedNoAlgo(self):
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('283_encrypted_no_algo.dts')
> +self.assertIn("Node '/binman/fit/images/u-boot/encrypted':
> 'encrypted' entry is missing properties: algo iv-filename", str(e.exception))
> +
> +def testEncryptedInvalidIvfile(self):
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('284_encrypted_invalid_iv_file.dts')
> +self.assertIn("Filename 'invalid-iv-file' not found in input path",
> + str(e.exception))
> +
> +def testEncryptedMissingKey(self):
> +with self.assertRaises(ValueError) as e:
> +self._DoReadFileDtb('285_encrypted_missing_key.dts')
> +self.assertIn("Node '/binman/fit/images/u-boot/encrypted': Provide
> either 'key-filename' or 'key-source'",
> + str(e.exception))
> +
> +def testEncryptedKeySource(self):
> +data = self._DoReadFileDtb('286_encrypted_key_source.dts')[0]
> +
> +dtb = fdt.Fdt.FromData(data)
> +dtb.Scan()
> +
> +node = dtb.GetNode('/images/u-boot/cipher')
> +self.assertEqual('algo-name', node.props['algo'].value)
> +self.assertEqual('key-source-value', node.props['key-source'].value)
> +self.assertEqual(ENCRYPTED_IV_DATA,
> tools.to_bytes(''.join(node.props['iv'].value)))
> +self.assertNotIn('key', node.props)
> +
> +def testEncryptedKeyFile(self):
> +data = self._DoReadFileDtb('287_encrypted_key_file.dts')[0]
> +
> +dtb = fdt.Fdt.FromData(data)
> +dtb.Scan()
> +
> +
Re: [PATCH v2 2/3] binman: Allow cipher node as special section
On Tue, 4 Jul 2023 at 10:03, wrote: > > From: Christian Taedcke > > The new encrypted etype generates a cipher node in the device tree > that should not be evaluated by binman, but still be kept in the > output device tree. > > Signed-off-by: Christian Taedcke > --- > > (no changes since v1) > > tools/binman/etype/section.py | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Although this patch needs to change once rebased to u-boot-dm/mkim-working
Re: [PATCH v2 1/3] binman: Add support for externally encrypted blobs
Hi Christian,
On Tue, 4 Jul 2023 at 10:03, wrote:
>
> From: Christian Taedcke
>
> This adds a new etype encrypted that is derived from collection.
>
> It creates a new cipher node in the related image similar to the
> cipher node used by u-boot, see boot/image-cipher.c.
>
> Signed-off-by: Christian Taedcke
> ---
>
> Changes in v2:
> - remove global /cipher node
> - replace key-name-hint with key-source property
> - add entry documentation
>
> tools/binman/etype/encrypted.py | 149
> 1 file changed, 149 insertions(+)
> create mode 100644 tools/binman/etype/encrypted.py
Please can you regenerate entries.rst in the same patch?
Also please rebase your series on u-boot-dm/mkim-working as it has a
fix to section.py (if that is a pain for you to do, I can do it).
>
> diff --git a/tools/binman/etype/encrypted.py b/tools/binman/etype/encrypted.py
> new file mode 100644
> index 00..feb2b4f1de
> --- /dev/null
> +++ b/tools/binman/etype/encrypted.py
> @@ -0,0 +1,149 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright 2023 Weidmüller Interface GmbH & Co. KG
> +# Written by Christian Taedcke
> +#
> +# Entry-type module for cipher information of encrypted blobs/binaries
> +#
> +
> +from binman.etype.collection import Entry_collection
> +from dtoc import fdt_util
> +from u_boot_pylib import tools
> +
> +# This is imported if needed
> +state = None
> +
> +
> +class Entry_encrypted(Entry_collection):
> +"""Externally built encrypted binary blob
> +
> +This entry provides the functionality to include information about how to
> +decrypt an encrypted binary. This information is added to the
> +resulting device tree by adding a new cipher node in the entry's parent
> +node (i.e. the binary).
> +
> +The key that must be used to decrypt the binary is either directly
> embedded
> +in the device tree or indirectly by specifying a key source. The key
> source
> +can be used as an id of a key that is stored in an external device.
> +
> +Using an embedded key
> +~
> +
> +This is an example using an embedded key::
> +
> +encrypted_blob: blob-ext {
> +filename = "encrypted-blob.bin";
> +};
> +
> +encrypted {
> +content = <_blob>;
> +algo = "aes256-gcm";
> +iv-filename = "encrypted-blob.bin.iv";
> +key-filename = "encrypted-blob.bin.key";
> +};
> +
> +This entry generates the following device tree structure form the example
> +above::
> +
> +data = [...]
> +cipher {
> +algo = "aes256-gcm";
> +key = <0x...>;
> +iv = <0x...>;
> +};
> +
> +The data property is generated by the blob-ext etype, the cipher node and
> +its content is generated by this etype.
> +
> +Using an external key
> +~
> +
> +Instead of embedding the key itself into the device tree, it is also
> +possible to address an externally stored key by specifying a 'key-source'
> +instead of the 'key'::
> +
> +encrypted_blob: blob-ext {
> +filename = "encrypted-blob.bin";
> +};
> +
> +encrypted {
> +content = <_blob>;
> +algo = "aes256-gcm";
> +iv-filename = "encrypted-blob.bin.iv";
> +key-source = "external-key-id";
> +};
> +
> +This entry generates the following device tree structure form the example
> +above::
> +
> +data = [...]
> +cipher {
> +algo = "aes256-gcm";
> +key-source = "external-key-id";
> +iv = <0x...>;
> +};
> +
> +Properties
> +~~
> +
> +In addition to the inherited 'collection' for Properties / Entry
> arguments:
> +- algo: The encryption algorithm. Currently no algorithm is supported
> +out-of-the-box. Certain algorithms will be added in future
> +patches.
> +- iv-filename: The name of the file containing the initialization
> + vector (in short iv). See
> + https://en.wikipedia.org/wiki/Initialization_vector
> +- key-filename: The name of the file containing the key. Either
> +key-filename or key-source must be provided.
> +- key-source: The key that should be used. Either key-filename or
> + key-source must be provided.
> +"""
> +
> +def __init__(self, section, etype, node):
> +# Put this here to allow entry-docs and help to work without libfdt
> +global state
> +from binman import state
> +
> +super().__init__(section, etype, node)
> +self.required_props = ['algo', 'iv-filename']
> +self._algo = None
> +self._iv_filename = None
> +self._key_name_hint = None
> +self._key_filename = None
> +
> +def ReadNode(self):
> +
Re: [PATCH v14 11/11] arm_ffa: efi: corstone1000: enable MM communication
Hi Abdellatif, On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi wrote: > > turn on EFI MM communication > > On corstone1000 platform MM communication between u-boot > and the secure world (Optee) is done using the FF-A bus. > > Signed-off-by: Abdellatif El Khlifi > Cc: Tom Rini > Cc: Simon Glass > Cc: Ilias Apalodimas > Cc: Jens Wiklander > > --- > > Changelog: > === > > 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 | 1 + > include/configs/corstone1000.h | 15 +-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig > index a8a79fd105..b57e2322c4 100644 > --- a/configs/corstone1000_defconfig > +++ b/configs/corstone1000_defconfig > @@ -65,3 +65,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y > CONFIG_EFI_IGNORE_OSINDICATIONS=y > CONFIG_FWU_MULTI_BANK_UPDATE=y > CONFIG_ERRNO_STR=y > +CONFIG_EFI_MM_COMM_TEE=y > diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h > index 3347c11792..4ef1f05e40 100644 > --- a/include/configs/corstone1000.h > +++ b/include/configs/corstone1000.h > @@ -1,9 +1,11 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * (C) Copyright 2022 ARM Limited > * (C) Copyright 2022 Linaro > * Rui Miguel Silva > - * Abdellatif El Khlifi > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > + * > + * Authors: > + * Abdellatif El Khlifi > * > * Configuration for Corstone1000. Parts were derived from other ARM > * configurations. > @@ -14,6 +16,15 @@ > > #include > > +#define FFA_SHARED_MM_BUFFER_SIZE SZ_4K /* 4 KB */ > + > +/* > + * shared buffer physical address used for communication between > + * u-boot and the MM SP > + */ > +#define FFA_SHARED_MM_BUFFER_ADDR 0x0200UL > +#define FFA_SHARED_MM_BUFFER_OFFSET0 > + These should be in devicetree properties, shouldn't they? We don't want things in board config.h files anymore. > #define V2M_BASE 0x8000 > > #define CFG_PL011_CLOCK5000 > -- > 2.25.1 > Regards, Simon
Re: [PATCH v14 07/11] arm_ffa: introduce sandbox FF-A support
Hi Abdellatif, On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi wrote: > > 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 > Cc: Tom Rini > Cc: Simon Glass > 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 Reviewed-by: Simon Glass
Re: [PATCH v14 05/11] log: select physical address formatting in a generic way
Hi Abdellatif, On Fri, 7 Jul 2023 at 15:44, Abdellatif El Khlifi wrote: > > sets the log formatting according to the platform (64-bit vs 32-bit) > > Signed-off-by: Abdellatif El Khlifi > Cc: Simon Glass > --- > include/log.h | 8 > 1 file changed, 8 insertions(+) > > diff --git a/include/log.h b/include/log.h > index 3bab40b617..689cef905b 100644 > --- a/include/log.h > +++ b/include/log.h > @@ -686,4 +686,12 @@ static inline int log_get_default_format(void) >(IS_ENABLED(CONFIG_LOGF_FUNC) ? BIT(LOGF_FUNC) : 0); > } > > +/* Select the right physical address formatting according to the platform */ > +#ifdef CONFIG_PHYS_64BIT > +#define PhysAddrLength "ll" > +#else > +#define PhysAddrLength "" Shouldn't this be "l" ? We normally use ulong for addresses. > +#endif > +#define PHYS_ADDR_LN "%" PhysAddrLength "x" > +#define PHYS_ADDR_LNU "%" PhysAddrLength "u" > #endif > -- > 2.25.1 > Regards, Simon
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Fri, Jul 07, 2023 at 07:05:45PM +0200, Pali Rohár wrote:
> On Friday 07 July 2023 12:54:58 Tom Rini wrote:
> > On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> > > On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > > > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > > > To make eMMC partition choosing in
> > > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > > function better understandable, rewrite it via explicit
> > > > > > > switch-case code
> > > > > > > pattern.
> > > > > > >
> > > > > > > Also add a warning when eMMC EXT_CSD[179] register is configured
> > > > > > > by user to
> > > > > > > value which is not suitable for eMMC booting and SPL do not know
> > > > > > > how to
> > > > > > > interpret it.
> > > > > > >
> > > > > > > Note that when booting from eMMC device via EXT_CSD[179] register
> > > > > > > is
> > > > > > > explicitly disabled then SPL still loads and boots from this eMMC
> > > > > > > device
> > > > > > > from User Area partition. This behavior was not changed in this
> > > > > > > commit and
> > > > > > > should be revisited in the future.
> > > > > > >
> > > > > > > Signed-off-by: Pali Rohár
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > * Disable showing warning on sama5d2_xplained due to size
> > > > > > > restrictions
> > > > > > > ---
> > > > > > > This patch depends on another patch:
> > > > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > > > ---
> > > > > > > common/spl/Kconfig | 7 +++
> > > > > > > common/spl/spl_mmc.c | 46
> > > > > > >
> > > > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > > > >
> > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > > > --- a/common/spl/Kconfig
> > > > > > > +++ b/common/spl/Kconfig
> > > > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > > > help
> > > > > > > Enable write access to MMC and SD Cards in SPL
> > > > > > >
> > > > > > > +config SPL_MMC_WARNINGS
> > > > > > > + bool "Print MMC warnings"
> > > > > > > + depends on SPL_MMC
> > > > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > > > + help
> > > > > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > > > > SPL size.
> > > > > > > +
> > > > > > >
> > > > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > > > bool "Support MPC8XXX DDR init"
> > > > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > > > --- a/common/spl/spl_mmc.c
> > > > > > > +++ b/common/spl/spl_mmc.c
> > > > > > > @@ -408,15 +408,45 @@ int
> > > > > > > default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > > > > > >*
> > > > > > >* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > > > >* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > > > > value.
> > > > > > > - *
> > > > > > > - * FIXME: When booting from this eMMC device is explicitly
> > > > > > > - * disabled then we use User area for booting. This is
> > > > > > > incorrect.
> > > > > > > - * Probably we should skip this eMMC device and select the next
> > > > > > > - * one for booting. Or at least throw warning about this
> > > > > > > fallback.
> > > > > > >*/
> > > > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > > > - if (part == 7)
> > > > > > > - part = 0;
> > > > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > > > + part = 0; /* If partitions are not supported then we
> > > > > > > have only User Area partition */
> > > > > > > + else {
> > > > > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > > > + puts("spl: WARNING: Booting from this eMMC
> > > > > > > device is disabled in EXT_CSD[179] register\n");
> > > > > > > + puts("spl: WARNING: Continuing anyway and
> > > > > > > selecting User Area partition for booting\n");
> > > > > > > +#else
> > > > > > > + puts("spl: mmc: fallback to user area\n");
> > > > > > > +#endif
> > > > > > > +#endif
> > > > > > > + /* FIXME: This is incorrect and probably we
> > > > > > > should select next eMMC device for booting */
> > > > > > > + part = 0;
> > > > > > > + break;
> > > > > > > + case 1: /* Boot partition 1 is used for booting */
> > > > > > > + part =
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Friday 07 July 2023 12:54:58 Tom Rini wrote:
> On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> > On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > > To make eMMC partition choosing in
> > > > > > default_spl_mmc_emmc_boot_partition()
> > > > > > function better understandable, rewrite it via explicit switch-case
> > > > > > code
> > > > > > pattern.
> > > > > >
> > > > > > Also add a warning when eMMC EXT_CSD[179] register is configured by
> > > > > > user to
> > > > > > value which is not suitable for eMMC booting and SPL do not know
> > > > > > how to
> > > > > > interpret it.
> > > > > >
> > > > > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > > > > explicitly disabled then SPL still loads and boots from this eMMC
> > > > > > device
> > > > > > from User Area partition. This behavior was not changed in this
> > > > > > commit and
> > > > > > should be revisited in the future.
> > > > > >
> > > > > > Signed-off-by: Pali Rohár
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > * Disable showing warning on sama5d2_xplained due to size
> > > > > > restrictions
> > > > > > ---
> > > > > > This patch depends on another patch:
> > > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > > ---
> > > > > > common/spl/Kconfig | 7 +++
> > > > > > common/spl/spl_mmc.c | 46
> > > > > >
> > > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > > >
> > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > > --- a/common/spl/Kconfig
> > > > > > +++ b/common/spl/Kconfig
> > > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > > help
> > > > > > Enable write access to MMC and SD Cards in SPL
> > > > > >
> > > > > > +config SPL_MMC_WARNINGS
> > > > > > + bool "Print MMC warnings"
> > > > > > + depends on SPL_MMC
> > > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > > + help
> > > > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > > > SPL size.
> > > > > > +
> > > > > >
> > > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > > bool "Support MPC8XXX DDR init"
> > > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > > --- a/common/spl/spl_mmc.c
> > > > > > +++ b/common/spl/spl_mmc.c
> > > > > > @@ -408,15 +408,45 @@ int
> > > > > > default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> > > > > > *
> > > > > > * Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > > > * and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > > > value.
> > > > > > -*
> > > > > > -* FIXME: When booting from this eMMC device is explicitly
> > > > > > -* disabled then we use User area for booting. This is
> > > > > > incorrect.
> > > > > > -* Probably we should skip this eMMC device and select the next
> > > > > > -* one for booting. Or at least throw warning about this
> > > > > > fallback.
> > > > > > */
> > > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > > - if (part == 7)
> > > > > > - part = 0;
> > > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > > + part = 0; /* If partitions are not supported then we
> > > > > > have only User Area partition */
> > > > > > + else {
> > > > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > > + puts("spl: WARNING: Booting from this eMMC
> > > > > > device is disabled in EXT_CSD[179] register\n");
> > > > > > + puts("spl: WARNING: Continuing anyway and
> > > > > > selecting User Area partition for booting\n");
> > > > > > +#else
> > > > > > + puts("spl: mmc: fallback to user area\n");
> > > > > > +#endif
> > > > > > +#endif
> > > > > > + /* FIXME: This is incorrect and probably we
> > > > > > should select next eMMC device for booting */
> > > > > > + part = 0;
> > > > > > + break;
> > > > > > + case 1: /* Boot partition 1 is used for booting */
> > > > > > + part = 1;
> > > > > > + break;
> > > > > > + case 2: /* Boot partition 2 is used for booting */
> > > > > > + part = 2;
> > > > > > + break;
> > > > > > +
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Fri, Jul 07, 2023 at 06:46:39PM +0200, Pali Rohár wrote:
> On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> > On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > > To make eMMC partition choosing in
> > > > > default_spl_mmc_emmc_boot_partition()
> > > > > function better understandable, rewrite it via explicit switch-case
> > > > > code
> > > > > pattern.
> > > > >
> > > > > Also add a warning when eMMC EXT_CSD[179] register is configured by
> > > > > user to
> > > > > value which is not suitable for eMMC booting and SPL do not know how
> > > > > to
> > > > > interpret it.
> > > > >
> > > > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > > > explicitly disabled then SPL still loads and boots from this eMMC
> > > > > device
> > > > > from User Area partition. This behavior was not changed in this
> > > > > commit and
> > > > > should be revisited in the future.
> > > > >
> > > > > Signed-off-by: Pali Rohár
> > > > > ---
> > > > > Changes in v2:
> > > > > * Disable showing warning on sama5d2_xplained due to size restrictions
> > > > > ---
> > > > > This patch depends on another patch:
> > > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > > ---
> > > > > common/spl/Kconfig | 7 +++
> > > > > common/spl/spl_mmc.c | 46
> > > > >
> > > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > > index 865571d4579c..0574d22b3b25 100644
> > > > > --- a/common/spl/Kconfig
> > > > > +++ b/common/spl/Kconfig
> > > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > > help
> > > > > Enable write access to MMC and SD Cards in SPL
> > > > >
> > > > > +config SPL_MMC_WARNINGS
> > > > > + bool "Print MMC warnings"
> > > > > + depends on SPL_MMC
> > > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > > + help
> > > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > > SPL size.
> > > > > +
> > > > >
> > > > > config SPL_MPC8XXX_INIT_DDR
> > > > > bool "Support MPC8XXX DDR init"
> > > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > > index f7a42a11477d..ec424ceded0e 100644
> > > > > --- a/common/spl/spl_mmc.c
> > > > > +++ b/common/spl/spl_mmc.c
> > > > > @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct
> > > > > mmc *mmc)
> > > > >*
> > > > >* Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > >* and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > > value.
> > > > > - *
> > > > > - * FIXME: When booting from this eMMC device is explicitly
> > > > > - * disabled then we use User area for booting. This is
> > > > > incorrect.
> > > > > - * Probably we should skip this eMMC device and select the next
> > > > > - * one for booting. Or at least throw warning about this
> > > > > fallback.
> > > > >*/
> > > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > > - if (part == 7)
> > > > > - part = 0;
> > > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > > + part = 0; /* If partitions are not supported then we
> > > > > have only User Area partition */
> > > > > + else {
> > > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > > + puts("spl: WARNING: Booting from this eMMC
> > > > > device is disabled in EXT_CSD[179] register\n");
> > > > > + puts("spl: WARNING: Continuing anyway and
> > > > > selecting User Area partition for booting\n");
> > > > > +#else
> > > > > + puts("spl: mmc: fallback to user area\n");
> > > > > +#endif
> > > > > +#endif
> > > > > + /* FIXME: This is incorrect and probably we
> > > > > should select next eMMC device for booting */
> > > > > + part = 0;
> > > > > + break;
> > > > > + case 1: /* Boot partition 1 is used for booting */
> > > > > + part = 1;
> > > > > + break;
> > > > > + case 2: /* Boot partition 2 is used for booting */
> > > > > + part = 2;
> > > > > + break;
> > > > > + case 7: /* User area is used for booting */
> > > > > + part = 0;
> > > > > + break;
> > > > > + default: /* Other values are reserved
Re: [PATCH v2 u-boot] mmc: spl: Make partition choice in default_spl_mmc_emmc_boot_partition() more explicit
On Thursday 06 July 2023 13:52:14 Tom Rini wrote:
> On Thu, Jul 06, 2023 at 07:49:18PM +0200, Pali Rohár wrote:
> > On Thursday 06 July 2023 13:42:18 Tom Rini wrote:
> > > On Thu, Jul 06, 2023 at 07:35:02PM +0200, Pali Rohár wrote:
> > > > To make eMMC partition choosing in default_spl_mmc_emmc_boot_partition()
> > > > function better understandable, rewrite it via explicit switch-case code
> > > > pattern.
> > > >
> > > > Also add a warning when eMMC EXT_CSD[179] register is configured by
> > > > user to
> > > > value which is not suitable for eMMC booting and SPL do not know how to
> > > > interpret it.
> > > >
> > > > Note that when booting from eMMC device via EXT_CSD[179] register is
> > > > explicitly disabled then SPL still loads and boots from this eMMC device
> > > > from User Area partition. This behavior was not changed in this commit
> > > > and
> > > > should be revisited in the future.
> > > >
> > > > Signed-off-by: Pali Rohár
> > > > ---
> > > > Changes in v2:
> > > > * Disable showing warning on sama5d2_xplained due to size restrictions
> > > > ---
> > > > This patch depends on another patch:
> > > > mmc: spl: Add comments for default_spl_mmc_emmc_boot_partition()
> > > > https://patchwork.ozlabs.org/project/uboot/patch/20230404202805.8523-1-p...@kernel.org/
> > > > ---
> > > > common/spl/Kconfig | 7 +++
> > > > common/spl/spl_mmc.c | 46
> > > > 2 files changed, 45 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> > > > index 865571d4579c..0574d22b3b25 100644
> > > > --- a/common/spl/Kconfig
> > > > +++ b/common/spl/Kconfig
> > > > @@ -855,6 +855,13 @@ config SPL_MMC_WRITE
> > > > help
> > > > Enable write access to MMC and SD Cards in SPL
> > > >
> > > > +config SPL_MMC_WARNINGS
> > > > + bool "Print MMC warnings"
> > > > + depends on SPL_MMC
> > > > + default y if !TARGET_SAMA5D2_XPLAINED
> > > > + help
> > > > + Print SPL MMC warnings. You can disable this option to reduce
> > > > SPL size.
> > > > +
> > > >
> > > > config SPL_MPC8XXX_INIT_DDR
> > > > bool "Support MPC8XXX DDR init"
> > > > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > > > index f7a42a11477d..ec424ceded0e 100644
> > > > --- a/common/spl/spl_mmc.c
> > > > +++ b/common/spl/spl_mmc.c
> > > > @@ -408,15 +408,45 @@ int default_spl_mmc_emmc_boot_partition(struct
> > > > mmc *mmc)
> > > > *
> > > > * Note: See difference between EXT_CSD_EXTRACT_PARTITION_ACCESS
> > > > * and EXT_CSD_EXTRACT_BOOT_PART, specially about User area
> > > > value.
> > > > -*
> > > > -* FIXME: When booting from this eMMC device is explicitly
> > > > -* disabled then we use User area for booting. This is
> > > > incorrect.
> > > > -* Probably we should skip this eMMC device and select the next
> > > > -* one for booting. Or at least throw warning about this
> > > > fallback.
> > > > */
> > > > - part = EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config);
> > > > - if (part == 7)
> > > > - part = 0;
> > > > + if (mmc->part_config == MMCPART_NOAVAILABLE)
> > > > + part = 0; /* If partitions are not supported then we
> > > > have only User Area partition */
> > > > + else {
> > > > + switch(EXT_CSD_EXTRACT_BOOT_PART(mmc->part_config)) {
> > > > + case 0: /* Booting from this eMMC device is disabled */
> > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > + puts("spl: WARNING: Booting from this eMMC
> > > > device is disabled in EXT_CSD[179] register\n");
> > > > + puts("spl: WARNING: Continuing anyway and
> > > > selecting User Area partition for booting\n");
> > > > +#else
> > > > + puts("spl: mmc: fallback to user area\n");
> > > > +#endif
> > > > +#endif
> > > > + /* FIXME: This is incorrect and probably we
> > > > should select next eMMC device for booting */
> > > > + part = 0;
> > > > + break;
> > > > + case 1: /* Boot partition 1 is used for booting */
> > > > + part = 1;
> > > > + break;
> > > > + case 2: /* Boot partition 2 is used for booting */
> > > > + part = 2;
> > > > + break;
> > > > + case 7: /* User area is used for booting */
> > > > + part = 0;
> > > > + break;
> > > > + default: /* Other values are reserved */
> > > > +#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> > > > +#ifdef CONFIG_SPL_MMC_WARNINGS
> > > > + puts("spl: WARNING: EXT_CSD[179] register is
> > > > configured to boot from Reserved value\n");
> > > > +
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 17:35, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
>>
>> On 07.07.23 14:42, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
On 05.07.23 00:14, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
>>
>> Hi Simon,
>>
>> On 28.06.23 13:41, Simon Glass wrote:
>>> Collections can used to collect the contents of other entries into a
>>> single entry, but they result in a single entry, with the original
>>> entries
>>> 'left behind' in their old place.
>>>
>>> It is useful to be able to specific a set of entries ones and have it
>>> used
>>> in multiple images, or parts of an image.
>>>
>>> Implement this mechanism.
>>>
>>> Signed-off-by: Simon Glass
>>> ---
>>>
>>> tools/binman/binman.rst | 80
>>> tools/binman/control.py | 9 +++
>>> tools/binman/etype/section.py| 3 +-
>>> tools/binman/ftest.py| 8 +++
>>> tools/binman/test/286_entry_template.dts | 42 +
>>> 5 files changed, 141 insertions(+), 1 deletion(-)
>>> create mode 100644 tools/binman/test/286_entry_template.dts
>>>
>>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
>>> index a4b31fe5397b..9be979ae1c5b 100644
>>> --- a/tools/binman/binman.rst
>>> +++ b/tools/binman/binman.rst
>>> @@ -727,6 +727,13 @@ optional:
>>> Note that missing, optional blobs do not produce a non-zero exit
>>> code from
>>> binman, although it does show a warning about the missing external
>>> blob.
>>>
>>> +insert-template:
>>> +This is not strictly speaking an entry property, since it is
>>> processed early
>>> +in Binman before the entries are read. It is a list of phandles of
>>> nodes to
>>> +include in the current (target) node. For each node, its subnodes
>>> and their
>>> +properties are brought into the target node. See Templates_ below
>>> for
>>> +more information.
>>> +
>>> The attributes supported for images and sections are described below.
>>> Several
>>> are similar to those for entries.
>>>
>>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
>>> going on, you can use
>>> arch/arm/dts/u-boot.dtsi ... found:
>>> "arch/arm/dts/juno-r2-u-boot.dtsi"
>>>
>>>
>>> +Templates
>>> +=
>>> +
>>> +Sometimes multiple images need to be created which have all have a
>>> common
>>> +part. For example, a board may generate SPI and eMMC images which both
>>> include
>>> +a FIT. Since the FIT includes many entries, it is tedious to repeat
>>> them twice
>>> +in the image description.
>>> +
>>> +Templates provide a simple way to handle this::
>>> +
>>> +binman {
>>> +multiple-images;
>>> +common_part: template-1 {
>>> +fit {
>>> +... lots of entries in here
>>> +};
>>> +
>>> +text {
>>> +text = "base image";
>>> +};
>>> +};
>>> +
>>> +spi-image {
>>> +filename = "image-spi.bin";
>>> +insert-template = <>;
>>> +
>>> +/* things specific to SPI follow */
>>> +header {
>>> +];
>>> +
>>> +text {
>>> +text = "SPI image";
>>> +};
>>> +};
>>> +
>>> +mmc-image {
>>> +filename = "image-mmc.bin";
>>> +insert-template = <>;
>>> +
>>> +/* things specific to MMC follow */
>>> +header {
>>> +];
>>> +
>>> +text {
>>> +text = "MMC image";
>>> +};
>>> +};
>>> +};
>>> +
>>> +The template node name must start with 'template', so it is not
>>> considered to be
>>> +an image itself.
>>> +
>>> +The mechanism is very simple. For each phandle in the
>>> 'insert-templates'
>>> +property, the source node is looked up. Then the subnodes of that
>>> source node
>>> +are copied into the target node, i.e. the one containing the
>>> `insert-template`
>>> +property.
>>> +
>>> +If the target node has a node with the same name as a template, its
>>> properties
>>> +override corresponding properties in the template. This allows the
>>> template to
>>> +be uses as a base, with the node providing updates to the properties
>>> as needed.
>>> +The overriding happens recursively.
>>> +
>>> +At present there is an unpleasant
Re: [PATCH] x86: Update docs link in bootparam header
On Fri, Jul 07, 2023 at 07:51:42AM +0100, Paul Barker wrote:
> After Linux commit ff61f0791ce9, x86 documentation was moved to
> arch/x86 and the link in bootparam.h was broken.
>
> Signed-off-by: Paul Barker
> ---
> arch/x86/include/asm/bootparam.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/bootparam.h
> b/arch/x86/include/asm/bootparam.h
> index ea816ca74698..1f8ca569b880 100644
> --- a/arch/x86/include/asm/bootparam.h
> +++ b/arch/x86/include/asm/bootparam.h
> @@ -62,7 +62,7 @@ struct setup_indirect {
> /**
> * struct setup_header - Information needed by Linux to boot
> *
> - * See https://www.kernel.org/doc/html/latest/x86/boot.html
> + * See https://docs.kernel.org/arch/x86/boot.html
This is also now:
https://www.kernel.org/doc/html/latest/arch/x86/boot.html
And tree-wide we have two examples of docs.kernel.org and the rest are
www.kernel.org/doc/html/latest for the base. We should be consistent
here, so I'm deferring to Heinrich.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 14:56, Jan Kiszka wrote:
>
> On 07.07.23 14:42, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
> >>
> >> On 05.07.23 00:14, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
>
> Hi Simon,
>
> On 28.06.23 13:41, Simon Glass wrote:
> > Collections can used to collect the contents of other entries into a
> > single entry, but they result in a single entry, with the original
> > entries
> > 'left behind' in their old place.
> >
> > It is useful to be able to specific a set of entries ones and have it
> > used
> > in multiple images, or parts of an image.
> >
> > Implement this mechanism.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > tools/binman/binman.rst | 80
> > tools/binman/control.py | 9 +++
> > tools/binman/etype/section.py| 3 +-
> > tools/binman/ftest.py| 8 +++
> > tools/binman/test/286_entry_template.dts | 42 +
> > 5 files changed, 141 insertions(+), 1 deletion(-)
> > create mode 100644 tools/binman/test/286_entry_template.dts
> >
> > diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> > index a4b31fe5397b..9be979ae1c5b 100644
> > --- a/tools/binman/binman.rst
> > +++ b/tools/binman/binman.rst
> > @@ -727,6 +727,13 @@ optional:
> > Note that missing, optional blobs do not produce a non-zero exit
> > code from
> > binman, although it does show a warning about the missing external
> > blob.
> >
> > +insert-template:
> > +This is not strictly speaking an entry property, since it is
> > processed early
> > +in Binman before the entries are read. It is a list of phandles of
> > nodes to
> > +include in the current (target) node. For each node, its subnodes
> > and their
> > +properties are brought into the target node. See Templates_ below
> > for
> > +more information.
> > +
> > The attributes supported for images and sections are described below.
> > Several
> > are similar to those for entries.
> >
> > @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> > going on, you can use
> > arch/arm/dts/u-boot.dtsi ... found:
> > "arch/arm/dts/juno-r2-u-boot.dtsi"
> >
> >
> > +Templates
> > +=
> > +
> > +Sometimes multiple images need to be created which have all have a
> > common
> > +part. For example, a board may generate SPI and eMMC images which both
> > include
> > +a FIT. Since the FIT includes many entries, it is tedious to repeat
> > them twice
> > +in the image description.
> > +
> > +Templates provide a simple way to handle this::
> > +
> > +binman {
> > +multiple-images;
> > +common_part: template-1 {
> > +fit {
> > +... lots of entries in here
> > +};
> > +
> > +text {
> > +text = "base image";
> > +};
> > +};
> > +
> > +spi-image {
> > +filename = "image-spi.bin";
> > +insert-template = <>;
> > +
> > +/* things specific to SPI follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "SPI image";
> > +};
> > +};
> > +
> > +mmc-image {
> > +filename = "image-mmc.bin";
> > +insert-template = <>;
> > +
> > +/* things specific to MMC follow */
> > +header {
> > +];
> > +
> > +text {
> > +text = "MMC image";
> > +};
> > +};
> > +};
> > +
> > +The template node name must start with 'template', so it is not
> > considered to be
> > +an image itself.
> > +
> > +The mechanism is very simple. For each phandle in the
> > 'insert-templates'
> > +property, the source node is looked up. Then the subnodes of that
> > source node
> > +are copied into the target node, i.e. the one containing the
> > `insert-template`
> > +property.
> > +
> > +If the target node has a node with the same name as a template, its
> > properties
> > +override corresponding properties in the template. This allows the
> > template to
> > +be uses as a base, with the node providing updates to the properties
> > as needed.
> > +The overriding happens recursively.
> > +
> > +At present there is an unpleasant limitation on this feature: it works
> > by
>
Re: [PATCH] binman: Support templating with multiple images
Hi Jan,
On Fri, 7 Jul 2023 at 15:04, Jan Kiszka wrote:
>
> On 07.07.23 14:40, Simon Glass wrote:
> > Allow a template to appear in the top level description when using
> > multiple images.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > tools/binman/control.py | 5 ++--
> > tools/binman/ftest.py| 12 ++
> > tools/binman/test/287_template_multi.dts | 29
> > 3 files changed, 44 insertions(+), 2 deletions(-)
> > create mode 100644 tools/binman/test/287_template_multi.dts
> >
> > diff --git a/tools/binman/control.py b/tools/binman/control.py
> > index 0f98e9904fb1..b334fbc8ac8f 100644
> > --- a/tools/binman/control.py
> > +++ b/tools/binman/control.py
> > @@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded):
> > images = OrderedDict()
> > if 'multiple-images' in binman_node.props:
> > for node in binman_node.subnodes:
> > -images[node.name] = Image(node.name, node,
> > - use_expanded=use_expanded)
> > +if 'template' not in node.name:
> > +images[node.name] = Image(node.name, node,
> > + use_expanded=use_expanded)
> > else:
> > images['image'] = Image('image', binman_node,
> > use_expanded=use_expanded)
> > return images
> > diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> > index 389d3906371a..c783424c91da 100644
> > --- a/tools/binman/ftest.py
> > +++ b/tools/binman/ftest.py
> > @@ -6771,6 +6771,18 @@ fdt fdtmapExtract the
> > devicetree blob from the fdtmap
> > second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA
> > self.assertEqual(U_BOOT_IMG_DATA + first + second, data)
> >
> > +def testEntryTemplateBlobMulti(self):
> > +"""Test using a template with 'multiple-images' enabled"""
> > +TestFunctional._MakeInputFile('my-blob.bin', b'blob')
> > +TestFunctional._MakeInputFile('my-blob2.bin', b'other')
> > +retcode = self._DoTestFile('287_template_multi.dts')
> > +
> > +self.assertEqual(0, retcode)
> > +image = control.images['image']
> > +image_fname = tools.get_output_filename('my-image.bin')
> > +data = tools.read_file(image_fname)
> > +self.assertEqual(b'blobother', data)
> > +
> >
> > if __name__ == "__main__":
> > unittest.main()
> > diff --git a/tools/binman/test/287_template_multi.dts
> > b/tools/binman/test/287_template_multi.dts
> > new file mode 100644
> > index ..15bd8701c671
> > --- /dev/null
> > +++ b/tools/binman/test/287_template_multi.dts
> > @@ -0,0 +1,29 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +
> > +/dts-v1/;
> > +
> > +/dts-v1/;
>
> Duplicate.
>
> > +/ {
> > + binman: binman {
> > + multiple-images;
> > +
> > + my_template: template {
> > + blob-ext@0 {
> > + filename = "my-blob.bin";
> > + offset = <0>;
> > + };
> > + blob-ext@8 {
> > + offset = <8>;
> > + };
> > + };
> > +
> > + image {
> > + pad-byte = <0x40>;
> > + filename = "my-image.bin";
> > + insert-template = <_template>;
> > + blob-ext@8 {
> > + filename = "my-blob2.bin";
> > + };
> > + };
> > + };
> > +};
>
> For the sake of context:
>
> echo 1234 > my-blob.bin
> echo 5678 > my-blob2.bin
> dtc tools/binman/test/287_template_multi.dts -o binman-test.dtb
> tools/binman/binman build -d binman-test.dtb -O .
>
> binman: Node '/binman/image/blob-ext@0': Offset 0x0 (0) overlaps with
> previous entry '/binman/image/blob-ext@8' ending at 0xd (13)
Hi Jan,
I don't get that error when I try these exact commands:
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> echo 1234 > my-blob.bin
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> echo 5678 > my-blob2.bin
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> dtc
tools/binman/test/287_template_multi.dts -o binman-test.dtb
tools/binman/test/287_template_multi.dts:11.15-14.6: Warning
(unit_address_vs_reg): /binman/template/blob-ext@0: node has a unit
name, but no reg or ranges property
tools/binman/test/287_template_multi.dts:15.15-17.6: Warning
(unit_address_vs_reg): /binman/template/blob-ext@8: node has a unit
name, but no reg or ranges property
tools/binman/test/287_template_multi.dts:24.15-26.6: Warning
(unit_address_vs_reg): /binman/image/blob-ext@8: node has a unit name,
but no reg or ranges property
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> tools/binman/binman
build -d binman-test.dtb -O .
(=88a31 moveconfig.failed) sglass@ELLESMERE ~/u> hd my-image.bin
31 32 33 34 0a 40 40 40 35 36 37 38 0a
[PATCH v14 11/11] arm_ffa: efi: corstone1000: enable MM communication
turn on EFI MM communication On corstone1000 platform MM communication between u-boot and the secure world (Optee) is done using the FF-A bus. Signed-off-by: Abdellatif El Khlifi Cc: Tom Rini Cc: Simon Glass Cc: Ilias Apalodimas Cc: Jens Wiklander --- Changelog: === 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 | 1 + include/configs/corstone1000.h | 15 +-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig index a8a79fd105..b57e2322c4 100644 --- a/configs/corstone1000_defconfig +++ b/configs/corstone1000_defconfig @@ -65,3 +65,4 @@ CONFIG_EFI_CAPSULE_ON_DISK=y CONFIG_EFI_IGNORE_OSINDICATIONS=y CONFIG_FWU_MULTI_BANK_UPDATE=y CONFIG_ERRNO_STR=y +CONFIG_EFI_MM_COMM_TEE=y diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h index 3347c11792..4ef1f05e40 100644 --- a/include/configs/corstone1000.h +++ b/include/configs/corstone1000.h @@ -1,9 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * (C) Copyright 2022 ARM Limited * (C) Copyright 2022 Linaro * Rui Miguel Silva - * Abdellatif El Khlifi + * Copyright 2022-2023 Arm Limited and/or its affiliates + * + * Authors: + * Abdellatif El Khlifi * * Configuration for Corstone1000. Parts were derived from other ARM * configurations. @@ -14,6 +16,15 @@ #include +#define FFA_SHARED_MM_BUFFER_SIZE SZ_4K /* 4 KB */ + +/* + * shared buffer physical address used for communication between + * u-boot and the MM SP + */ +#define FFA_SHARED_MM_BUFFER_ADDR 0x0200UL +#define FFA_SHARED_MM_BUFFER_OFFSET0 + #define V2M_BASE 0x8000 #define CFG_PL011_CLOCK5000 -- 2.25.1
[PATCH v14 10/11] 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.
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:
===
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| 13 ++
lib/efi_loader/Kconfig| 16 +-
lib/efi_loader/efi_variable_tee.c | 272 +-
3 files changed, 294 insertions(+), 7 deletions(-)
diff --git a/include/mm_communication.h b/include/mm_communication.h
index e65fbde60d..f17847583b 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,9 @@
#include
+/* MM service UUID string (big-endian format). This UUID is common across all
MM SPs */
+#define MM_SP_UUID "33d532ed-e699-0942-c09c-a798d9cd722d"
+
/*
* Interface to the pseudo Trusted Application (TA), which provides a
* communication channel with the Standalone MM (Management Mode)
@@ -248,4 +254,11 @@ struct smm_variable_var_check_property {
u16 name[];
};
+/* supported MM transports */
+enum mm_comms_select {
+ MM_COMMS_UNDEFINED,
+ MM_COMMS_FFA,
+ MM_COMMS_OPTEE
+};
+
#endif /* _MM_COMMUNICATION_H_ */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c5835e6ef6..cb26e110fd 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -55,13 +55,25 @@ config EFI_VARIABLE_FILE_STORE
stored as file /ubootefi.var on the EFI system partition.
config EFI_MM_COMM_TEE
- bool "UEFI variables storage service via OP-TEE"
- depends on OPTEE
+ bool "UEFI variables storage service via the trusted world"
+ select ARM_FFA_TRANSPORT
+ select TEE
+ select OPTEE
help
+ Allowing access to the MM SP services (SPs such as StandAlonneMM,
smm-gateway).
+ When using the u-boot OP-TEE driver, StandAlonneMM is supported.
+ When using
[PATCH v14 08/11] 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 f8948b7635..4a8b3a5419 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -276,6 +276,7 @@ F: doc/arch/arm64.ffa.rst
F: doc/usage/cmd/armffa.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 b7c754fa3d..325fb80346 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;
+}
+
+static int
[PATCH v14 09/11] arm_ffa: introduce armffa command Sandbox test
Add Sandbox test for the armffa command
Signed-off-by: Abdellatif El Khlifi
Reviewed-by: Simon Glass
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
---
Changelog:
===
v12:
* address nits
v10:
* replace CMD_RET_SUCCESS with 0
* replace CONFIG_SANDBOX_FFA with CONFIG_ARM_FFA_TRANSPORT
v9: align the test with FF-A discovery through DM
v4: drop use of helper APIs
v1: introduce armffa command sandbox test
MAINTAINERS | 1 +
test/cmd/Makefile | 2 ++
test/cmd/armffa.c | 33 +
3 files changed, 36 insertions(+)
create mode 100644 test/cmd/armffa.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a8b3a5419..30d1b87149 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -276,6 +276,7 @@ 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/test/cmd/Makefile b/test/cmd/Makefile
index a3cf983739..6e3d7e919e 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright (c) 2013 Google, Inc
+# Copyright 2022-2023 Arm Limited and/or its affiliates
ifdef CONFIG_HUSH_PARSER
obj-$(CONFIG_CONSOLE_RECORD) += test_echo.o
@@ -24,6 +25,7 @@ obj-$(CONFIG_CMD_SEAMA) += seama.o
ifdef CONFIG_SANDBOX
obj-$(CONFIG_CMD_READ) += rw.o
obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
+obj-$(CONFIG_ARM_FFA_TRANSPORT) += armffa.o
endif
obj-$(CONFIG_CMD_TEMPERATURE) += temperature.o
obj-$(CONFIG_CMD_WGET) += wget.o
diff --git a/test/cmd/armffa.c b/test/cmd/armffa.c
new file mode 100644
index 00..9a44a397e8
--- /dev/null
+++ b/test/cmd/armffa.c
@@ -0,0 +1,33 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test for armffa command
+ *
+ * Copyright 2022-2023 Arm Limited and/or its affiliates
+ *
+ * Authors:
+ * Abdellatif El Khlifi
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Basic test of 'armffa' command */
+static int dm_test_armffa_cmd(struct unit_test_state *uts)
+{
+ /* armffa getpart */
+ ut_assertok(run_command("armffa getpart " SANDBOX_SERVICE1_UUID, 0));
+
+ /* armffa ping */
+ ut_assertok(run_commandf("armffa ping 0x%x", SANDBOX_SP1_ID));
+
+ /* armffa devlist */
+ ut_assertok(run_command("armffa devlist", 0));
+
+ return 0;
+}
+
+DM_TEST(dm_test_armffa_cmd, UT_TESTF_SCAN_FDT | UT_TESTF_CONSOLE_REC);
--
2.25.1
[PATCH v14 07/11] 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
Cc: Tom Rini
Cc: Simon Glass
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 ff6a222960..f8948b7635 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,12 +269,13 @@ 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: 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: 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
[PATCH v14 06/11] 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].
[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:
===
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 | 2 +
cmd/Kconfig | 10 ++
cmd/Makefile | 1 +
cmd/armffa.c | 194 +++
doc/arch/arm64.ffa.rst | 7 ++
doc/usage/cmd/armffa.rst | 93 +++
doc/usage/index.rst | 1 +
drivers/firmware/arm-ffa/Kconfig | 1 +
8 files changed, 309 insertions(+)
create mode 100644 cmd/armffa.c
create mode 100644 doc/usage/cmd/armffa.rst
diff --git a/MAINTAINERS b/MAINTAINERS
index b3a16ed802..ff6a222960 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -269,7 +269,9 @@ F: configs/cortina_presidio-asic-pnand_defconfig
ARM FF-A
M: Abdellatif El Khlifi
S: Maintained
+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: include/sandbox_arm_ffa.h
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 02e54f1e50..79b4f8367a 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..ab0fd54d97
--- /dev/null
+++ b/cmd/armffa.c
@@ -0,0 +1,194 @@
+// 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
+
+/**
+ * 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) {
+ log_err("Cannot find FF-A bus device\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+/**
+ * do_ffa_getpart() - implementation of the getpart subcommand
+ * @cmdtp: Command Table
+ * @flag: flags
+ * @argc: number of arguments
+ * @argv: arguments
+ *
+ * Query a secure partition information. The secure partition UUID is provided
+ * as an argument. The function uses the arm_ffa driver
+ * partition_info_get operation which implements FFA_PARTITION_INFO_GET
+ * ABI to retrieve the data. The input UUID string is
[PATCH v14 04/11] 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
Cc: Tom Rini
Cc: Ilias Apalodimas
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 v14 05/11] log: select physical address formatting in a generic way
sets the log formatting according to the platform (64-bit vs 32-bit) Signed-off-by: Abdellatif El Khlifi Cc: Simon Glass --- include/log.h | 8 1 file changed, 8 insertions(+) diff --git a/include/log.h b/include/log.h index 3bab40b617..689cef905b 100644 --- a/include/log.h +++ b/include/log.h @@ -686,4 +686,12 @@ static inline int log_get_default_format(void) (IS_ENABLED(CONFIG_LOGF_FUNC) ? BIT(LOGF_FUNC) : 0); } +/* 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" +#define PHYS_ADDR_LNU "%" PhysAddrLength "u" #endif -- 2.25.1
[PATCH v14 03/11] 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:
===
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..a1e34ab63a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1634,3 +1634,8 @@ S:Maintained
F: arch/arm/dts/ls1021a-twr-u-boot.dtsi
F: drivers/crypto/fsl/
F: include/fsl_sec.h
+
+UUID testing
+M: Abdellatif El Khlifi
+S: Maintained
+F: test/lib/uuid.c
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 v14 02/11] 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 v14 01/11] 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 v14 00/11] 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: === v14: 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 ut_asserteq_mem() in uuid_str_to_le_bin test case * address nits v10: [10] * provide the FF-A driver operations through the Uclass (arm-ffa-uclass.c) * move the generic FF-A methods to the Uclass * keep Arm specific methods in the Arm driver (arm-ffa.c renamed from core.c) * split the FF-A sandbox support into an emulator (ffa-emul-uclass.c) and a driver (sandbox_ffa.c) * use the FF-A driver Uclass operations by clients (armffa command, tests, MM comms) * use uclass_first_device to search and probe the FF-A device (whether it is on Arm or on sandbox) * address nits v9: [9] * integrate the FF-A bus discovery in the DM and use ARM_SMCCC_FEATURES for binding * align FF-A sandbox driver with FF-A discovery through DM * use DM class APIs to probe and interact with the FF-A bus (in FF-A MM comms, armffa command, sandbox tests) * add documentation for the armffa command: doc/usage/cmd/armffa.rst * introduce testcase for uuid_str_to_le_bin v8: [8] * pass
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Fri, Jul 07, 2023 at 10:54:00AM -0300, Fabio Estevam wrote: > On Fri, Jul 7, 2023 at 10:46 AM Anne Macedo wrote: > > > On u-boot shell: > > > > gpio set pd6 > > Good point. You should pass the following options: > > CONFIG_DM_REGULATOR=y > CONFIG_DM_REGULATOR_FIXED=y > > so that the GPIO3_6 turns on by default and then you would not need to > run the "gpio set pd6" command. That didn't work. I still had to enable with "gpio set pd6". Also, when it gets to the kernel, ethernet shuts down. I also don't see the device in my router, so I believe even though eth0 is up, something may not be working yet. > > > then dhcp command works :). However, it doesn't get an IP and with > > static IP pinging doesn't work.
Re: [RESEND PATCH v1 1/4] riscv: t-head: licheepi4a: initial support added
Hi Leo
On 02:55 Thu 29 Jun , Leo Liang wrote:
> Hi YiXun,
> On Fri, May 26, 2023 at 08:41:04PM +0800, Yixun Lan wrote:
> > Add support for Sipeed's Lichee Pi 4A board which based on
> > T-HEAD's TH1520 SoC, only minimal device tree and serial onsole are enabled,
> > so it's capable of chain booting from T-HEAD's vendor u-boot.
> >
> > Reviewed-by: Wei Fu
> > Signed-off-by: Yixun Lan
> > ...
> > diff --git a/board/thead/th1520_lpi4a/board.c
> > b/board/thead/th1520_lpi4a/board.c
> > new file mode 100644
> > index 00..378bab098b
> > --- /dev/null
> > +++ b/board/thead/th1520_lpi4a/board.c
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (c) 2023, Yixun Lan
> > + *
> > + */
> > +
> > +#include
> > +
> > +int board_init(void)
> > +{
> > + enable_caches();
>
> There is a compilation warining here at "enable_caches"
> (probably due to cpu_func.h not being included to provide this function)
>
thanks, will fix in v2
>
> Best regards,
> Leo
> > +
> > + return 0;
> > +}
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
Re: [PATCH] binman: Support templating with multiple images
On 07.07.23 14:40, Simon Glass wrote:
> Allow a template to appear in the top level description when using
> multiple images.
>
> Signed-off-by: Simon Glass
> ---
>
> tools/binman/control.py | 5 ++--
> tools/binman/ftest.py| 12 ++
> tools/binman/test/287_template_multi.dts | 29
> 3 files changed, 44 insertions(+), 2 deletions(-)
> create mode 100644 tools/binman/test/287_template_multi.dts
>
> diff --git a/tools/binman/control.py b/tools/binman/control.py
> index 0f98e9904fb1..b334fbc8ac8f 100644
> --- a/tools/binman/control.py
> +++ b/tools/binman/control.py
> @@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded):
> images = OrderedDict()
> if 'multiple-images' in binman_node.props:
> for node in binman_node.subnodes:
> -images[node.name] = Image(node.name, node,
> - use_expanded=use_expanded)
> +if 'template' not in node.name:
> +images[node.name] = Image(node.name, node,
> + use_expanded=use_expanded)
> else:
> images['image'] = Image('image', binman_node,
> use_expanded=use_expanded)
> return images
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 389d3906371a..c783424c91da 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6771,6 +6771,18 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA
> self.assertEqual(U_BOOT_IMG_DATA + first + second, data)
>
> +def testEntryTemplateBlobMulti(self):
> +"""Test using a template with 'multiple-images' enabled"""
> +TestFunctional._MakeInputFile('my-blob.bin', b'blob')
> +TestFunctional._MakeInputFile('my-blob2.bin', b'other')
> +retcode = self._DoTestFile('287_template_multi.dts')
> +
> +self.assertEqual(0, retcode)
> +image = control.images['image']
> +image_fname = tools.get_output_filename('my-image.bin')
> +data = tools.read_file(image_fname)
> +self.assertEqual(b'blobother', data)
> +
>
> if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/287_template_multi.dts
> b/tools/binman/test/287_template_multi.dts
> new file mode 100644
> index ..15bd8701c671
> --- /dev/null
> +++ b/tools/binman/test/287_template_multi.dts
> @@ -0,0 +1,29 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/dts-v1/;
Duplicate.
> +/ {
> + binman: binman {
> + multiple-images;
> +
> + my_template: template {
> + blob-ext@0 {
> + filename = "my-blob.bin";
> + offset = <0>;
> + };
> + blob-ext@8 {
> + offset = <8>;
> + };
> + };
> +
> + image {
> + pad-byte = <0x40>;
> + filename = "my-image.bin";
> + insert-template = <_template>;
> + blob-ext@8 {
> + filename = "my-blob2.bin";
> + };
> + };
> + };
> +};
For the sake of context:
echo 1234 > my-blob.bin
echo 5678 > my-blob2.bin
dtc tools/binman/test/287_template_multi.dts -o binman-test.dtb
tools/binman/binman build -d binman-test.dtb -O .
binman: Node '/binman/image/blob-ext@0': Offset 0x0 (0) overlaps with previous
entry '/binman/image/blob-ext@8' ending at 0xd (13)
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v2] lib: sparse: allocate FASTBOOT_MAX_BLK_WRITE instead of small number
Hi Qianfan,
Thank you for your review.
On ven., juil. 07, 2023 at 18:54, qianfan wrote:
> 在 2023/7/7 16:13, Mattijs Korpershoek 写道:
>> Commit 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
>> fixed cache alignment for systems with a D-CACHE.
>>
>> However it introduced some performance regressions [1] on system
>> flashing huge images, such as Android.
>>
>> On AM62x SK EVM, we also observe such performance penalty:
>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.954s]
>> Writing 'super'OKAY [ 75.926s]
>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.641s]
>> Writing 'super'OKAY [ 62.849s]
>> Finished. Total time: 182.474s
>>
>> The reason for this is that we use an arbitrary small buffer
>> (info->blksz * 100) for transferring.
>>
>> Fix it by using a bigger buffer (info->blksz * FASTBOOT_MAX_BLK_WRITE)
>> as suggested in the original's patch review [2].
>>
>> With this patch, performance impact is mitigated:
>> Sending sparse 'super' 1/2 (768793 KB) OKAY [ 23.912s]
>> Writing 'super'OKAY [ 15.780s]
>> Sending sparse 'super' 2/2 (629819 KB) OKAY [ 19.581s]
>> Writing 'super'OKAY [ 17.192s]
>> Finished. Total time: 76.569s
>>
>> [1]
>> https://lore.kernel.org/r/20221118121323.4009193-1-gary.bis...@boundarydevices.com
>> [2]
>> https://lore.kernel.org/r/all/43e4c17c-4483-ec8e-f843-9b4c5569b...@seco.com/
>>
>> Fixes: 62649165cb02 ("lib: sparse: Make CHUNK_TYPE_RAW buffer aligned")
>> Signed-off-by: Mattijs Korpershoek
>> ---
>> Changes in v2:
>> - Use FASTBOOT_MAX_BLK_WRITE instead of blkcnt (Qianfan)
>> - Link to v1:
>> https://lore.kernel.org/r/20230616-sparse-flash-fix-v1-1-6bafeacc5...@baylibre.com
>> ---
>> drivers/fastboot/fb_mmc.c | 2 --
>> include/image-sparse.h| 2 ++
>> lib/image-sparse.c| 3 ++-
>> 3 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
>> index 9d25c402028a..060918e49109 100644
>> --- a/drivers/fastboot/fb_mmc.c
>> +++ b/drivers/fastboot/fb_mmc.c
>> @@ -19,8 +19,6 @@
>> #include
>> #include
>>
>> -#define FASTBOOT_MAX_BLK_WRITE 16384
>> -
>> #define BOOT_PARTITION_NAME "boot"
>>
>> struct fb_mmc_sparse {
>> diff --git a/include/image-sparse.h b/include/image-sparse.h
>> index 0572dbd0a283..282a0b256498 100644
>> --- a/include/image-sparse.h
>> +++ b/include/image-sparse.h
>> @@ -7,6 +7,8 @@
>> #include
>> #include
>>
>> +#define FASTBOOT_MAX_BLK_WRITE 16384
> Hi:
>
> Just a personal suggestion, define sometings like FASTBOOT_MAX_BLK_WRITE in
> image-sparse.c is very strange.
>
> Or maybe define a marco such as SPARSE_MAX_BLK_WRITE and set a default
> value to 16384, and leave some comments for why we choice this value.
I don't agree with having a duplicating between SPARSE_MAX_BLK_WRITE
and FASTBOOT_MAX_BLK_WRITE. code comments can rot as well.
And FASTBOOT_MAX_BLK_WRITE is used for both sparse and unsparsed image,
which is why I chose to not rename it.
>
> Thanks.
>> +
>> #define ROUNDUP(x, y) (((x) + ((y) - 1)) & ~((y) - 1))
>>
>> struct sparse_storage {
>> diff --git a/lib/image-sparse.c b/lib/image-sparse.c
>> index 5ec0f94ab3eb..8f8a67e15804 100644
>> --- a/lib/image-sparse.c
>> +++ b/lib/image-sparse.c
>> @@ -55,7 +55,8 @@ static lbaint_t write_sparse_chunk_raw(struct
>> sparse_storage *info,
>> void *data,
>> char *response)
>> {
>> -lbaint_t n = blkcnt, write_blks, blks = 0, aligned_buf_blks = 100;
>> +lbaint_t n = blkcnt, write_blks, blks = 0;
>> +lbaint_t aligned_buf_blks = FASTBOOT_MAX_BLK_WRITE;
>> uint32_t *aligned_buf = NULL;
>>
>> if (CONFIG_IS_ENABLED(SYS_DCACHE_OFF)) {
>>
>> ---
>> base-commit: 923de765ee1a5b26310f02cb42dcbad9e2b011c5
>> change-id: 20230616-sparse-flash-fix-9c2852aa8d16
>>
>> Best regards,
Re: [PATCH 12/12] binman: Support simple templates
On 07.07.23 14:42, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>>
>> On 05.07.23 00:14, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
Hi Simon,
On 28.06.23 13:41, Simon Glass wrote:
> Collections can used to collect the contents of other entries into a
> single entry, but they result in a single entry, with the original entries
> 'left behind' in their old place.
>
> It is useful to be able to specific a set of entries ones and have it used
> in multiple images, or parts of an image.
>
> Implement this mechanism.
>
> Signed-off-by: Simon Glass
> ---
>
> tools/binman/binman.rst | 80
> tools/binman/control.py | 9 +++
> tools/binman/etype/section.py| 3 +-
> tools/binman/ftest.py| 8 +++
> tools/binman/test/286_entry_template.dts | 42 +
> 5 files changed, 141 insertions(+), 1 deletion(-)
> create mode 100644 tools/binman/test/286_entry_template.dts
>
> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> index a4b31fe5397b..9be979ae1c5b 100644
> --- a/tools/binman/binman.rst
> +++ b/tools/binman/binman.rst
> @@ -727,6 +727,13 @@ optional:
> Note that missing, optional blobs do not produce a non-zero exit
> code from
> binman, although it does show a warning about the missing external
> blob.
>
> +insert-template:
> +This is not strictly speaking an entry property, since it is
> processed early
> +in Binman before the entries are read. It is a list of phandles of
> nodes to
> +include in the current (target) node. For each node, its subnodes
> and their
> +properties are brought into the target node. See Templates_ below for
> +more information.
> +
> The attributes supported for images and sections are described below.
> Several
> are similar to those for entries.
>
> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> going on, you can use
> arch/arm/dts/u-boot.dtsi ... found:
> "arch/arm/dts/juno-r2-u-boot.dtsi"
>
>
> +Templates
> +=
> +
> +Sometimes multiple images need to be created which have all have a common
> +part. For example, a board may generate SPI and eMMC images which both
> include
> +a FIT. Since the FIT includes many entries, it is tedious to repeat them
> twice
> +in the image description.
> +
> +Templates provide a simple way to handle this::
> +
> +binman {
> +multiple-images;
> +common_part: template-1 {
> +fit {
> +... lots of entries in here
> +};
> +
> +text {
> +text = "base image";
> +};
> +};
> +
> +spi-image {
> +filename = "image-spi.bin";
> +insert-template = <>;
> +
> +/* things specific to SPI follow */
> +header {
> +];
> +
> +text {
> +text = "SPI image";
> +};
> +};
> +
> +mmc-image {
> +filename = "image-mmc.bin";
> +insert-template = <>;
> +
> +/* things specific to MMC follow */
> +header {
> +];
> +
> +text {
> +text = "MMC image";
> +};
> +};
> +};
> +
> +The template node name must start with 'template', so it is not
> considered to be
> +an image itself.
> +
> +The mechanism is very simple. For each phandle in the 'insert-templates'
> +property, the source node is looked up. Then the subnodes of that source
> node
> +are copied into the target node, i.e. the one containing the
> `insert-template`
> +property.
> +
> +If the target node has a node with the same name as a template, its
> properties
> +override corresponding properties in the template. This allows the
> template to
> +be uses as a base, with the node providing updates to the properties as
> needed.
> +The overriding happens recursively.
> +
> +At present there is an unpleasant limitation on this feature: it works by
> +appending the template nodes after any existing subnodes to the target
> node.
> +This means that if the target node includes any subnodes, these appear
> in order
> +before the template node. In the above example, 'header' becomes the
> first
> +subnode of each image, followed by `fit` and `text`. If this is not what
> is
> +desired,
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Fri, Jul 7, 2023 at 10:46 AM Anne Macedo wrote: > On u-boot shell: > > gpio set pd6 Good point. You should pass the following options: CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y so that the GPIO3_6 turns on by default and then you would not need to run the "gpio set pd6" command. > then dhcp command works :). However, it doesn't get an IP and with > static IP pinging doesn't work.
[RFC] riscv: (visionfive2:) device tree binding for riscv_timer
Hi,
following the existing device tree binding[1], here is a draft to use it
in drivers/timer/riscv_timer.c. This would also fix the regression we see
with commit 55171aedda8 ("dm: Emit the arch_cpu_init_dm() even only
before relocation"), at least on the VisionFive2, as sketched out below.
The device tree addition suits the Linux kernel dirver
| riscv-timer: riscv_timer_init_dt: Registering clocksource cpuid [0] hartid [3]
The of_match, along with the "timebase-frequency" property, provides
a working timer (again) on the VF2.
If this is the way to go, I'll turn this into a nicer patch series.
Comments welcome!
Torsten
[1] linux/Documentation/devicetree/bindings/timer/riscv,timer.yaml
---
arch/riscv/dts/jh7110.dtsi | 10 ++
configs/starfive_visionfive2_defconfig |1 -
drivers/timer/riscv_timer.c| 21 ++---
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 3627ed79b8..03dda12f73 100644
--- a/drivers/timer/riscv_timer.c
+++ b/drivers/timer/riscv_timer.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
@@ -53,9 +54,18 @@ u64 notrace timer_early_get_count(void)
static int riscv_timer_probe(struct udevice *dev)
{
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
-
/* clock frequency was passed from the cpu driver as driver data */
- uc_priv->clock_rate = dev->driver_data;
+ u32 rate = dev->driver_data;
+
+ if (!rate && gd->fdt_blob) {/* not called from CPU driver?
*/
+ rate = fdt_getprop_u32_default(gd->fdt_blob,
+ "/cpus", "timebase-frequency",
0);
+ }
+ uc_priv->clock_rate = rate;
+
+ /* timer uclass post_probe will later fail with -EINVAL. Hint at the
cause! */
+ if (!rate)
+ log_err("riscv_timer_probe with clock rate 0\n");
return 0;
}
@@ -64,10 +74,15 @@ static const struct timer_ops riscv_timer_ops = {
.get_count = riscv_timer_get_count,
};
+static const struct udevice_id riscv_timer_ids[] = {
+{ .compatible = "riscv,timer", },
+{ }
+};
+
U_BOOT_DRIVER(riscv_timer) = {
.name = "riscv_timer",
.id = UCLASS_TIMER,
+ .of_match = of_match_ptr(riscv_timer_ids),
.probe = riscv_timer_probe,
.ops = _timer_ops,
- .flags = DM_FLAG_PRE_RELOC,
};
diff --git a/arch/riscv/dts/jh7110.dtsi b/arch/riscv/dts/jh7110.dtsi
index c61730e8d1..9944f261b3 100644
--- a/arch/riscv/dts/jh7110.dtsi
+++ b/arch/riscv/dts/jh7110.dtsi
@@ -6,6 +6,7 @@
/dts-v1/;
#include
#include
+#include
/ {
compatible = "starfive,jh7110";
@@ -204,6 +205,15 @@
};
};
+ timer {
+ compatible = "riscv,timer";
+ interrupts-extended = <_intc HART_INT_S_TIMER>,
+ <_intc HART_INT_S_TIMER>,
+ <_intc HART_INT_S_TIMER>,
+ <_intc HART_INT_S_TIMER>,
+ <_intc HART_INT_S_TIMER>;
+ };
+
osc: oscillator {
compatible = "fixed-clock";
clock-output-names = "osc";
diff --git a/configs/starfive_visionfive2_defconfig
b/configs/starfive_visionfive2_defconfig
index 570a1f53a1..3a213b2601 100644
--- a/configs/starfive_visionfive2_defconfig
+++ b/configs/starfive_visionfive2_defconfig
@@ -102,4 +102,3 @@ CONFIG_PINCTRL_STARFIVE=y
# CONFIG_RAM_SIFIVE is not set
CONFIG_SYS_NS16550=y
CONFIG_CADENCE_QSPI=y
-CONFIG_TIMER_EARLY=y
RE: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
>On 07.07.23 15:30, Jerome Forissier wrote: >> >> >> On 7/7/23 14:34, Neha Malcom Francis wrote: >>> Earlier documentation specified builds for generating bootloader >>> images using an external TI repository k3-image-gen and >>> core-secdev-k3. Modify this to using the binman flow so that user >>> understands how to build the final boot images. >>> >>> Signed-off-by: Neha Malcom Francis >>> Reviewed-by: Simon Glass >>> --- >>> doc/board/ti/am62x_sk.rst | 42 - >>> doc/board/ti/j721e_evm.rst | 50 +--- >>> doc/board/ti/k3.rst| 95 +- >>> 3 files changed, 73 insertions(+), 114 deletions(-) >>> >>> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst >>> index 27d7b527c6..e4d58b4958 100644 >>> --- a/doc/board/ti/am62x_sk.rst >>> +++ b/doc/board/ti/am62x_sk.rst >> [...] >>> @@ -139,35 +135,37 @@ Build procedure: >>> >>> 1. ATF: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 >PLAT=k3 >>> TARGET_BOARD=lite SPD=opteed >>> + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 >PLAT=k3 \ >>> +TARGET_BOARD=lite SPD=opteed >>> >>> 2. OPTEE: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make PLATFORM=k3 CFG_ARM64_core=y >>> CROSS_COMPILE=arm-none-linux-gnueabihf- >>> CROSS_COMPILE64=aarch64-none-linux-gnu- >>> + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none- >linux-gnueabihf- \ >>> +CROSS_COMPILE64=aarch64-none-linux-gnu- >>> >>> 3. U-Boot: >>> >>> * 3.1 R5: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >>> am62x_evm_r5_defconfig O=/tmp/r5 >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >O=/tmp/r5 >>> - $ cd >>> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >SOC=am62x >>> SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=>> ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin >>> - >>> -Use the tiboot3.bin generated from last command >>> + $ make ARCH=arm am62x_evm_r5_defconfig $ make ARCH=arm >>> + CROSS_COMPILE=arm-none-linux-gnueabihf- \ >>> +BINMAN_INDIRS= >>> >>> * 3.2 A53: >>> >>> -.. code-block:: text >>> +.. code-block:: bash >>> >>> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- >>> am62x_evm_a53_defconfig O=/tmp/a53 >>> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=to >>> ATF dir>/build/k3/lite/release/bl31.bin TEE=>> dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM=>> ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.x >>> er5f O=/tmp/a53 >>> + $ make ARCH=arm am62x_evm_a53_defconfig $ make ARCH=arm >>> + CROSS_COMPILE=aarch64-none-linux-gnu- \ >>> +BL31=/build/k3/lite/release/bl31.bin \ >>> +TEE=>> + dir>/out/arm-plat-k3/core/tee-pager_v2.bin \ >> >> Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used >> instead of tee-pager_v2.bin. Indeed when the "pager" feature is not >> enabled, the two binaries are identical, and the newer name is hopefully >less confusing. >> > >Ah, interesting. That will affect doc/board/siemens/iot2050.rst as well (and >our integration recipes). And J7200 docs as well, however this doc is on next https://github.com/u-boot/u-boot/blob/next/doc/board/ti/j7200_evm.rst > >Jan > >-- >Siemens AG, Technology >Competence Center Embedded Linux
Re: [bug report] sunxi: H6: no ethernet on Orange Pi One Plus
On Fri, Jul 07, 2023 at 08:42:33AM -0300, Anne Macedo wrote:
> On Thu, Jul 06, 2023 at 11:51:54PM +, Anne Macedo wrote:
> > On Wed, Jul 05, 2023 at 02:15:43PM -0300, Fabio Estevam wrote:
> > > On Wed, Jul 5, 2023 at 1:31 PM Anne Macedo wrote:
> > >
> > > > I think I'm on the right path :)
> > > >
> > > > 1. Included SUNXI_SETUP_REGULATORS=0 to the bl31 make
> > > > 2. Changed the phy mode on arch/arm/dts/sun50i-h6-orangepi-one-plus.dts
> > > >From rgmii-id to rgmii
> > >
> > > This does not look like the correct fix. Please see this commit from
> > > Linux:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.4.1=544cc3f8573bf9a82e8f348741f2f68d2a8376fb
> > >
> > > >More info on [1][2][3]
> > > > 3. Added this configs to configs/orangepi_one_plus_defconfig:
> > > >CONFIG_SPL_SPI_SUNXI=y
> > > >CONFIG_SUNXI_NO_PMIC=y
> > >e>CONFIG_SUN8I_EMAC=y
> > > >
> > > > Result:
> > > >
> > > > U-Boot 2023.04-gfd4ed6b (Apr 03 2023 - 20:38:50 +) Allwinner
> > > > Technology
> > > >
> > > > CPU: Allwinner H6 (SUN50I)
> > > > Model: OrangePi One Plus
> > > > DRAM: 1 GiB
> > > > Core: 55 devices, 17 uclasses, devicetree: separate
> > > > WDT: Not starting watchdog@7020400
> > > > MMC: mmc@402: 0
> > > > Loading Environment from FAT... Unable to read "uboot.env" from
> > > > mmc0:1...
> > > > In:serial@500
> > > > Out: serial@500
> > > > Err: serial@500
> > > > Net: eth0: ethernet@502
> > > >
> > > > => dhcp
> > > > sun8i_emac_eth_start: Timeout
> > > > => mdio list
> > > > ethernet@502:
> > > > 1 - Generic PHY <--> ethernet@502
> > >
> > > What about using the Realtek PHY driver instead of the Generic one?
> > >
> > > --- a/configs/orangepi_one_plus_defconfig
> > > +++ b/configs/orangepi_one_plus_defconfig
> > > @@ -8,3 +8,6 @@ CONFIG_SUNXI_DRAM_H6_LPDDR3=y
> > > # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > CONFIG_USB_EHCI_HCD=y
> > > CONFIG_USB_OHCI_HCD=y
> > > +CONFIG_PHY_REALTEK=y
> > > +CONFIG_RGMII=y
> > > +CONFIG_MII=y
> > >
> > > Does this help?
> >
> > Sorry for the delay, life came in the way.
> >
> > u-boot config:
> > CONFIG_PHY_REALTEK=y
> > CONFIG_RGMII=y
> > CONFIG_MII=y
> >
> > tfa config:
> > SUNXI_SETUP_REGULATORS=0
> >
> > result:
> > => dhcp
> > No ethernet found.
> >
> > u-boot config:
> > CONFIG_SPL_SPI_SUNXI=y
> > CONFIG_SUNXI_NO_PMIC=y
> > CONFIG_SUN8I_EMAC=y
> > CONFIG_PHY_REALTEK=y
> > CONFIG_RGMII=y
> > CONFIG_MII=y
> >
> > tfa config:
> > SUNXI_SETUP_REGULATORS=0
> >
> > result:
> > Net: PHY reset timed out
> > eth0: ethernet@502
> > => dhcp
> > sun8i_emac_eth_start: Timeout
> > => mdio list
> > ethernet@502:
> > 1 - Generic PHY <--> ethernet@502
> >
> > It's interesting that it keeps using Generic PHY.
> >
> > Regards,
> > Anne
> >
>
> OH! I believe I discovered something I overlooked:
>
> On arch/arm/dts/sun50i-h6-orangepi-one-plus.dts:
>
> reg_gmac_3v3: gmac-3v3 {
> compatible = "regulator-fixed";
> regulator-name = "vcc-gmac-3v3";
> regulator-min-microvolt = <330>;
> regulator-max-microvolt = <330>;
> startup-delay-us = <10>;
> enable-active-high;
> gpio = < 3 6 GPIO_ACTIVE_HIGH>; /* PD6 */
> vin-supply = <_aldo2>;
> };
>
> After I connected GPIO 3 to GPIO 6, the Ethernet LED turned on!
Okay, I completely misunderstood this... and I lost the combination that
turned the LED on :(
It seems that PD6 is not exposed on the GPIO header [1]. It is defined
on the FBGA on the pin map session of the datasheet [2]. So, I don't
believe I need to short the pins to get it working, but somehow it at
least powered on the Ethernet port. I wish I remember the combination.
[1]
https://forum.armbian.com/uploads/monthly_2020_04/873961756_Opioneplusgpio.jpg.e28c37c0f66189dc68e86a428a5a8b95.jpg
[2]
https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf
UPDATE: I did it!
On u-boot shell:
gpio set pd6
then dhcp command works :). However, it doesn't get an IP and with
static IP pinging doesn't work.
It seems to be able to send BOOTP broadcasts but it doesn't get an IP...
Combination was:
u-boot config:
CONFIG_SPL_SPI_SUNXI=y
CONFIG_SUN8I_EMAC=y
tfa config:
SUNXI_SETUP_REGULATORS=1 (or just unset this)
>
> I still see:
>
> => dhcp
> sun8i_emac_eth_start: Timeout
>
> And
>
> Net: PHY reset timed out
> eth0: ethernet@502
>
> Regards,
> Anne
Regards,
Anne
[PATCH] MAINTAINERS: correct at91 tree link
This was not done when the tree name was changed, fix it now. Signed-off-by: Eugen Hristev --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index d724b6467344..2477923a5201 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -409,7 +409,7 @@ F: configs/uDPU_defconfig ARM MICROCHIP/ATMEL AT91 M: Eugen Hristev S: Maintained -T: git https://source.denx.de/u-boot/custodians/u-boot-atmel.git +T: git https://source.denx.de/u-boot/custodians/u-boot-at91.git F: arch/arm/mach-at91/ F: board/atmel/ F: drivers/cpu/at91_cpu.c -- 2.34.1
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 07.07.23 15:30, Jerome Forissier wrote: > > > On 7/7/23 14:34, Neha Malcom Francis wrote: >> Earlier documentation specified builds for generating bootloader images >> using an external TI repository k3-image-gen and core-secdev-k3. Modify >> this to using the binman flow so that user understands how to build the >> final boot images. >> >> Signed-off-by: Neha Malcom Francis >> Reviewed-by: Simon Glass >> --- >> doc/board/ti/am62x_sk.rst | 42 - >> doc/board/ti/j721e_evm.rst | 50 +--- >> doc/board/ti/k3.rst| 95 +- >> 3 files changed, 73 insertions(+), 114 deletions(-) >> >> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst >> index 27d7b527c6..e4d58b4958 100644 >> --- a/doc/board/ti/am62x_sk.rst >> +++ b/doc/board/ti/am62x_sk.rst > [...] >> @@ -139,35 +135,37 @@ Build procedure: >> >> 1. ATF: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 >> TARGET_BOARD=lite SPD=opteed >> + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ >> +TARGET_BOARD=lite SPD=opteed >> >> 2. OPTEE: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make PLATFORM=k3 CFG_ARM64_core=y >> CROSS_COMPILE=arm-none-linux-gnueabihf- >> CROSS_COMPILE64=aarch64-none-linux-gnu- >> + $ make PLATFORM=k3 CFG_ARM64_core=y >> CROSS_COMPILE=arm-none-linux-gnueabihf- \ >> +CROSS_COMPILE64=aarch64-none-linux-gnu- >> >> 3. U-Boot: >> >> * 3.1 R5: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- >> am62x_evm_r5_defconfig O=/tmp/r5 >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 >> - $ cd >> - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x >> SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=> ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin >> - >> -Use the tiboot3.bin generated from last command >> + $ make ARCH=arm am62x_evm_r5_defconfig >> + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ >> +BINMAN_INDIRS= >> >> * 3.2 A53: >> >> -.. code-block:: text >> +.. code-block:: bash >> >> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- >> am62x_evm_a53_defconfig O=/tmp/a53 >> - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=> dir>/build/k3/lite/release/bl31.bin TEE=> dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM=> ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f >> O=/tmp/a53 >> + $ make ARCH=arm am62x_evm_a53_defconfig >> + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ >> +BL31=/build/k3/lite/release/bl31.bin \ >> +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ > > Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used instead of > tee-pager_v2.bin. Indeed when the "pager" feature is not enabled, the two > binaries are identical, and the newer name is hopefully less confusing. > Ah, interesting. That will affect doc/board/siemens/iot2050.rst as well (and our integration recipes). Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 07.07.23 14:34, Neha Malcom Francis wrote:
> Move to using binman to generate tispl.bin which is used to generate the
> final flash.bin bootloader for iot2050 boards.
>
> Signed-off-by: Neha Malcom Francis
> Cc: Jan Kiszka
> ---
> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++-
> 1 file changed, 74 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> index 03ccc54329..9d83898d33 100644
> --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> @@ -26,9 +26,81 @@
> missing-msg = "iot2050-seboot";
> };
>
> - blob@0x18 {
> + fit@0x18 {
> offset = <0x18>;
> - filename = "tispl.bin";
> + pad-byte = <0xff>;
> + description = "Configuration to load ATF and SPL";
> +
> + images {
> + atf {
> + description = "ARM Trusted Firmware";
> + type = "firmware";
> + arch = "arm64";
> + compression = "none";
> + os = "arm-trusted-firmware";
> + load = ;
> + entry = ;
> + atf: atf-bl31 {
> + };
> + };
> +
> + tee {
> + description = "OPTEE";
> + type = "tee";
> + arch = "arm64";
> + compression = "none";
> + os = "tee";
> + load = <0x9e80>;
> + entry = <0x9e80>;
> + tee: tee-os {
> + };
> + };
> +
> + dm {
> + description = "DM binary";
> + type = "firmware";
> + arch = "arm32";
> + compression = "none";
> + os = "DM";
> + load = <0x8900>;
> + entry = <0x8900>;
> + blob-ext {
> + filename = "/dev/null";
> + };
> + };
> +
> + spl {
> + description = "SPL (64-bit)";
> + type = "standalone";
> + os = "U-Boot";
> + arch = "arm64";
> + compression = "none";
> + load = ;
> + entry = ;
> + u_boot_spl_nodtb: blob-ext {
> + filename =
> "spl/u-boot-spl-nodtb.bin";
> + };
> + };
> +
> + fdt-0 {
> + description = "k3-am65-iot2050-spl.dtb";
> + type = "flat_dt";
> + arch = "arm";
> + compression = "none";
> + spl_am65x_evm_dtb: blob-ext {
> + filename =
> "spl/dts/k3-am65-iot2050-spl.dtb";
> + };
> + };
> + };
> +
> + configurations {
> + default = "spl";
> + spl {
> + fdt = "fdt-0";
> + firmware = "atf";
> + loadables = "tee", "dm", "spl";
> + };
> + };
> };
>
> fit@0x38 {
Looks ok (will have to test), but this lacks adjustment of
tools/iot2050-sign-fw.sh, probably something around
s/tispl.bin/fit@0x18/g.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 7/7/23 14:34, Neha Malcom Francis wrote: > Earlier documentation specified builds for generating bootloader images > using an external TI repository k3-image-gen and core-secdev-k3. Modify > this to using the binman flow so that user understands how to build the > final boot images. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > --- > doc/board/ti/am62x_sk.rst | 42 - > doc/board/ti/j721e_evm.rst | 50 +--- > doc/board/ti/k3.rst| 95 +- > 3 files changed, 73 insertions(+), 114 deletions(-) > > diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst > index 27d7b527c6..e4d58b4958 100644 > --- a/doc/board/ti/am62x_sk.rst > +++ b/doc/board/ti/am62x_sk.rst [...] > @@ -139,35 +135,37 @@ Build procedure: > > 1. ATF: > > -.. code-block:: text > +.. code-block:: bash > > - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 > TARGET_BOARD=lite SPD=opteed > + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ > +TARGET_BOARD=lite SPD=opteed > > 2. OPTEE: > > -.. code-block:: text > +.. code-block:: bash > > - $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- > CROSS_COMPILE64=aarch64-none-linux-gnu- > + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- > \ > +CROSS_COMPILE64=aarch64-none-linux-gnu- > > 3. U-Boot: > > * 3.1 R5: > > -.. code-block:: text > +.. code-block:: bash > > - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- > am62x_evm_r5_defconfig O=/tmp/r5 > - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 > - $ cd > - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x > SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH= ti-linux-firmware>/ti-sysfw/ti-fs-firmware-am62x-gp.bin > - > -Use the tiboot3.bin generated from last command > + $ make ARCH=arm am62x_evm_r5_defconfig > + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ > +BINMAN_INDIRS= > > * 3.2 A53: > > -.. code-block:: text > +.. code-block:: bash > > - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- > am62x_evm_a53_defconfig O=/tmp/a53 > - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF= dir>/build/k3/lite/release/bl31.bin TEE= dir>/out/arm-plat-k3/core/tee-pager_v2.bin DM= ti-linux-firmware>/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f > O=/tmp/a53 > + $ make ARCH=arm am62x_evm_a53_defconfig > + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ > +BL31=/build/k3/lite/release/bl31.bin \ > +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ Note that since OP-TEE 3.21.0, tee-raw.bin could/should be used instead of tee-pager_v2.bin. Indeed when the "pager" feature is not enabled, the two binaries are identical, and the newer name is hopefully less confusing. -- Jerome
Re: [PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
On 18:04-20230707, Neha Malcom Francis wrote: > Earlier documentation specified builds for generating bootloader images > using an external TI repository k3-image-gen and core-secdev-k3. Modify > this to using the binman flow so that user understands how to build the > final boot images. > > Signed-off-by: Neha Malcom Francis > Reviewed-by: Simon Glass > --- > doc/board/ti/am62x_sk.rst | 42 - > doc/board/ti/j721e_evm.rst | 50 +--- > doc/board/ti/k3.rst| 95 +- > 3 files changed, 73 insertions(+), 114 deletions(-) > [...] > > Sources: > > -1. SYSFW: > - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git > - Branch: master > - > -2. ATF: > +1. ATF: Minor nitpick: ATF was the old name https://community.arm.com/oss-platforms/w/docs/483/trusted-firmware-a Trusted Firmware-A is the new name. > Tree: https://github.com/ARM-software/arm-trusted-firmware.git I believe the official repo is https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/ [...] -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 12/12] binman: Support simple templates
Hi Jan,
On Fri, 7 Jul 2023 at 11:05, Jan Kiszka wrote:
>
> On 05.07.23 00:14, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 3 Jul 2023 at 20:34, Jan Kiszka wrote:
> >>
> >> Hi Simon,
> >>
> >> On 28.06.23 13:41, Simon Glass wrote:
> >>> Collections can used to collect the contents of other entries into a
> >>> single entry, but they result in a single entry, with the original entries
> >>> 'left behind' in their old place.
> >>>
> >>> It is useful to be able to specific a set of entries ones and have it used
> >>> in multiple images, or parts of an image.
> >>>
> >>> Implement this mechanism.
> >>>
> >>> Signed-off-by: Simon Glass
> >>> ---
> >>>
> >>> tools/binman/binman.rst | 80
> >>> tools/binman/control.py | 9 +++
> >>> tools/binman/etype/section.py| 3 +-
> >>> tools/binman/ftest.py| 8 +++
> >>> tools/binman/test/286_entry_template.dts | 42 +
> >>> 5 files changed, 141 insertions(+), 1 deletion(-)
> >>> create mode 100644 tools/binman/test/286_entry_template.dts
> >>>
> >>> diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst
> >>> index a4b31fe5397b..9be979ae1c5b 100644
> >>> --- a/tools/binman/binman.rst
> >>> +++ b/tools/binman/binman.rst
> >>> @@ -727,6 +727,13 @@ optional:
> >>> Note that missing, optional blobs do not produce a non-zero exit
> >>> code from
> >>> binman, although it does show a warning about the missing external
> >>> blob.
> >>>
> >>> +insert-template:
> >>> +This is not strictly speaking an entry property, since it is
> >>> processed early
> >>> +in Binman before the entries are read. It is a list of phandles of
> >>> nodes to
> >>> +include in the current (target) node. For each node, its subnodes
> >>> and their
> >>> +properties are brought into the target node. See Templates_ below for
> >>> +more information.
> >>> +
> >>> The attributes supported for images and sections are described below.
> >>> Several
> >>> are similar to those for entries.
> >>>
> >>> @@ -1172,6 +1179,79 @@ If you are having trouble figuring out what is
> >>> going on, you can use
> >>> arch/arm/dts/u-boot.dtsi ... found:
> >>> "arch/arm/dts/juno-r2-u-boot.dtsi"
> >>>
> >>>
> >>> +Templates
> >>> +=
> >>> +
> >>> +Sometimes multiple images need to be created which have all have a common
> >>> +part. For example, a board may generate SPI and eMMC images which both
> >>> include
> >>> +a FIT. Since the FIT includes many entries, it is tedious to repeat them
> >>> twice
> >>> +in the image description.
> >>> +
> >>> +Templates provide a simple way to handle this::
> >>> +
> >>> +binman {
> >>> +multiple-images;
> >>> +common_part: template-1 {
> >>> +fit {
> >>> +... lots of entries in here
> >>> +};
> >>> +
> >>> +text {
> >>> +text = "base image";
> >>> +};
> >>> +};
> >>> +
> >>> +spi-image {
> >>> +filename = "image-spi.bin";
> >>> +insert-template = <>;
> >>> +
> >>> +/* things specific to SPI follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "SPI image";
> >>> +};
> >>> +};
> >>> +
> >>> +mmc-image {
> >>> +filename = "image-mmc.bin";
> >>> +insert-template = <>;
> >>> +
> >>> +/* things specific to MMC follow */
> >>> +header {
> >>> +];
> >>> +
> >>> +text {
> >>> +text = "MMC image";
> >>> +};
> >>> +};
> >>> +};
> >>> +
> >>> +The template node name must start with 'template', so it is not
> >>> considered to be
> >>> +an image itself.
> >>> +
> >>> +The mechanism is very simple. For each phandle in the 'insert-templates'
> >>> +property, the source node is looked up. Then the subnodes of that source
> >>> node
> >>> +are copied into the target node, i.e. the one containing the
> >>> `insert-template`
> >>> +property.
> >>> +
> >>> +If the target node has a node with the same name as a template, its
> >>> properties
> >>> +override corresponding properties in the template. This allows the
> >>> template to
> >>> +be uses as a base, with the node providing updates to the properties as
> >>> needed.
> >>> +The overriding happens recursively.
> >>> +
> >>> +At present there is an unpleasant limitation on this feature: it works by
> >>> +appending the template nodes after any existing subnodes to the target
> >>> node.
> >>> +This means that if the target node includes any subnodes, these appear
> >>> in order
> >>> +before the template node. In the above example, 'header' becomes the
> >>> first
> >>> +subnode of each image, followed by `fit` and `text`. If this is not what
> >>> is
> >>> +desired, there is no way to adjust it.
> >>> +
> >>>
[PATCH] binman: Support templating with multiple images
Allow a template to appear in the top level description when using
multiple images.
Signed-off-by: Simon Glass
---
tools/binman/control.py | 5 ++--
tools/binman/ftest.py| 12 ++
tools/binman/test/287_template_multi.dts | 29
3 files changed, 44 insertions(+), 2 deletions(-)
create mode 100644 tools/binman/test/287_template_multi.dts
diff --git a/tools/binman/control.py b/tools/binman/control.py
index 0f98e9904fb1..b334fbc8ac8f 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -57,8 +57,9 @@ def _ReadImageDesc(binman_node, use_expanded):
images = OrderedDict()
if 'multiple-images' in binman_node.props:
for node in binman_node.subnodes:
-images[node.name] = Image(node.name, node,
- use_expanded=use_expanded)
+if 'template' not in node.name:
+images[node.name] = Image(node.name, node,
+ use_expanded=use_expanded)
else:
images['image'] = Image('image', binman_node,
use_expanded=use_expanded)
return images
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 389d3906371a..c783424c91da 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -6771,6 +6771,18 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
second = U_BOOT_DATA + b'#' + VGA_DATA + U_BOOT_DTB_DATA
self.assertEqual(U_BOOT_IMG_DATA + first + second, data)
+def testEntryTemplateBlobMulti(self):
+"""Test using a template with 'multiple-images' enabled"""
+TestFunctional._MakeInputFile('my-blob.bin', b'blob')
+TestFunctional._MakeInputFile('my-blob2.bin', b'other')
+retcode = self._DoTestFile('287_template_multi.dts')
+
+self.assertEqual(0, retcode)
+image = control.images['image']
+image_fname = tools.get_output_filename('my-image.bin')
+data = tools.read_file(image_fname)
+self.assertEqual(b'blobother', data)
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/287_template_multi.dts
b/tools/binman/test/287_template_multi.dts
new file mode 100644
index ..15bd8701c671
--- /dev/null
+++ b/tools/binman/test/287_template_multi.dts
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/dts-v1/;
+/ {
+ binman: binman {
+ multiple-images;
+
+ my_template: template {
+ blob-ext@0 {
+ filename = "my-blob.bin";
+ offset = <0>;
+ };
+ blob-ext@8 {
+ offset = <8>;
+ };
+ };
+
+ image {
+ pad-byte = <0x40>;
+ filename = "my-image.bin";
+ insert-template = <_template>;
+ blob-ext@8 {
+ filename = "my-blob2.bin";
+ };
+ };
+ };
+};
--
2.41.0.390.g38632f3daf-goog
[PATCH v5 23/23] CI: Make use of buildman requirements.txt
From: Tom Rini
Now that buildman has a requirements.txt file we need to make use of it.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
[n-fran...@ti.com: Adding missing command from .azure-pipelines.yml]
Signed-off-by: Neha Malcom Francis
---
.azure-pipelines.yml | 4
.gitlab-ci.yml | 4
2 files changed, 8 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 06c46b681c..8626b27d4b 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -162,6 +162,7 @@ stages:
virtualenv -p /usr/bin/python3 /tmp/venv
. /tmp/venv/bin/activate
pip install -r test/py/requirements.txt
+ pip install -r tools/buildman/requirements.txt
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl
export PYTHONPATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt
export PATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}
@@ -209,6 +210,7 @@ stages:
git config --global --add safe.directory $(work_dir)
export USER=azure
pip install -r test/py/requirements.txt
+ pip install -r tools/buildman/requirements.txt
pip install asteval pylint==2.12.2 pyopenssl
export PATH=${PATH}:~/.local/bin
echo "[MASTER]" >> .pylintrc
@@ -404,6 +406,7 @@ stages:
if [ -n "${BUILD_ENV}" ]; then
export ${BUILD_ENV};
fi
+ pip install -r tools/buildman/requirements.txt
tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W -e
--board ${TEST_PY_BD} ${OVERRIDE}
cp ~/grub_x86.efi ${UBOOT_TRAVIS_BUILD_DIR}/
cp ~/grub_x64.efi ${UBOOT_TRAVIS_BUILD_DIR}/
@@ -583,6 +586,7 @@ stages:
# make environment variables available as tests are running inside a
container
export BUILDMAN="${BUILDMAN}"
git config --global --add safe.directory ${WORK_DIR}
+ pip install -r tools/buildman/requirements.txt
EOF
cat << "EOF" >> build.sh
if [[ "${BUILDMAN}" != "" ]]; then
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index cfd58513c3..07d8ba5ac2 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -97,6 +97,7 @@ build all 32bit ARM platforms:
script:
- ret=0;
git config --global --add safe.directory "${CI_PROJECT_DIR}";
+ pip install -r tools/buildman/requirements.txt;
./tools/buildman/buildman -o /tmp -PEWM arm -x aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
./tools/buildman/buildman -o /tmp -seP;
@@ -110,6 +111,7 @@ build all 64bit ARM platforms:
- . /tmp/venv/bin/activate
- ret=0;
git config --global --add safe.directory "${CI_PROJECT_DIR}";
+ pip install -r tools/buildman/requirements.txt;
./tools/buildman/buildman -o /tmp -PEWM aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
./tools/buildman/buildman -o /tmp -seP;
@@ -208,6 +210,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
virtualenv -p /usr/bin/python3 /tmp/venv;
. /tmp/venv/bin/activate;
pip install -r test/py/requirements.txt;
+ pip install -r tools/buildman/requirements.txt;
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
@@ -240,6 +243,7 @@ Run pylint:
script:
- git config --global --add safe.directory "${CI_PROJECT_DIR}"
- pip install -r test/py/requirements.txt
+- pip install -r tools/buildman/requirements.txt
- pip install asteval pylint==2.12.2 pyopenssl
- export PATH=${PATH}:~/.local/bin
- echo "[MASTER]" >> .pylintrc
--
2.34.1
[PATCH v5 22/23] buildman: Create a requirements.txt file
From: Tom Rini At this point, buildman requires a few different modules and so we need a requirements.txt to track what modules are needed. Cc: Simon Glass Cc: Neha Malcom Francis Signed-off-by: Tom Rini Reviewed-by: Simon Glass Signed-off-by: Neha Malcom Francis --- tools/buildman/requirements.txt | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 tools/buildman/requirements.txt diff --git a/tools/buildman/requirements.txt b/tools/buildman/requirements.txt new file mode 100644 index 00..a1efcb9d4b --- /dev/null +++ b/tools/buildman/requirements.txt @@ -0,0 +1,2 @@ +jsonschema==4.17.3 +pyyaml==6.0 -- 2.34.1
[PATCH v5 21/23] binman: Overwrite symlink if it already exists
From: Andrew Davis Without this re-building will fail with an error when trying to create the symlink for the second time with an already exists error. Signed-off-by: Andrew Davis Signed-off-by: Neha Malcom Francis --- tools/binman/image.py | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/binman/image.py b/tools/binman/image.py index 8ebf71d61a..e77b5d0d97 100644 --- a/tools/binman/image.py +++ b/tools/binman/image.py @@ -182,6 +182,8 @@ class Image(section.Entry_section): # Create symlink to file if symlink given if self._symlink is not None: sname = tools.get_output_filename(self._symlink) +if os.path.islink(sname): +os.remove(sname) os.symlink(fname, sname) def WriteMap(self): -- 2.34.1
[PATCH v5 20/23] doc: board: ti: Update documentation for binman flow
Earlier documentation specified builds for generating bootloader images using an external TI repository k3-image-gen and core-secdev-k3. Modify this to using the binman flow so that user understands how to build the final boot images. Signed-off-by: Neha Malcom Francis Reviewed-by: Simon Glass --- doc/board/ti/am62x_sk.rst | 42 - doc/board/ti/j721e_evm.rst | 50 +--- doc/board/ti/k3.rst| 95 +- 3 files changed, 73 insertions(+), 114 deletions(-) diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index 27d7b527c6..e4d58b4958 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -115,23 +115,19 @@ Below is the pictorial representation of boot flow: Sources: -1. SYSFW: - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git - Branch: master - -2. ATF: +1. ATF: Tree: https://github.com/ARM-software/arm-trusted-firmware.git Branch: master -3. OPTEE: +2. OPTEE: Tree: https://github.com/OP-TEE/optee_os.git Branch: master -4. U-Boot: +3. U-Boot: Tree: https://source.denx.de/u-boot/u-boot Branch: master -5. TI Linux Firmware: +4. TI Linux Firmware: Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git Branch: ti-linux-firmware @@ -139,35 +135,37 @@ Build procedure: 1. ATF: -.. code-block:: text +.. code-block:: bash - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=lite SPD=opteed + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ +TARGET_BOARD=lite SPD=opteed 2. OPTEE: -.. code-block:: text +.. code-block:: bash - $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- CROSS_COMPILE64=aarch64-none-linux-gnu- + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- \ +CROSS_COMPILE64=aarch64-none-linux-gnu- 3. U-Boot: * 3.1 R5: -.. code-block:: text +.. code-block:: bash - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am62x_evm_r5_defconfig O=/tmp/r5 - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 - $ cd - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=/ti-sysfw/ti-fs-firmware-am62x-gp.bin - -Use the tiboot3.bin generated from last command + $ make ARCH=arm am62x_evm_r5_defconfig + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ +BINMAN_INDIRS= * 3.2 A53: -.. code-block:: text +.. code-block:: bash - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- am62x_evm_a53_defconfig O=/tmp/a53 - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=/build/k3/lite/release/bl31.bin TEE=/out/arm-plat-k3/core/tee-pager_v2.bin DM=/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f O=/tmp/a53 + $ make ARCH=arm am62x_evm_a53_defconfig + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ +BL31=/build/k3/lite/release/bl31.bin \ +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ +BINMAN_INDIRS= Target Images -- diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst index feaa2da5e9..9e604f6f12 100644 --- a/doc/board/ti/j721e_evm.rst +++ b/doc/board/ti/j721e_evm.rst @@ -130,67 +130,61 @@ support. Below is the pictorial representation of boot flow: Sources: -1. SYSFW: - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git - Branch: master - -2. ATF: +1. ATF: Tree: https://github.com/ARM-software/arm-trusted-firmware.git Branch: master -3. OPTEE: +2. OPTEE: Tree: https://github.com/OP-TEE/optee_os.git Branch: master -4. DM Firmware: - Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git - Branch: ti-linux-firmware - -5. U-Boot: +3. U-Boot: Tree: https://source.denx.de/u-boot/u-boot Branch: master +4. TI Linux Firmware: + Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git + Branch: ti-linux-firmware + Build procedure: -1. SYSFW: - -.. code-block:: bash - -make CROSS_COMPILE=arm-linux-gnueabihf- SOC=j721e - -2. ATF: +1. ATF: .. code-block:: bash -make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic SPD=opteed + $ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 \ +TARGET_BOARD=generic SPD=opteed -3. OPTEE: +2. OPTEE: .. code-block:: bash -make PLATFORM=k3-j721e CFG_ARM64_core=y + $ make PLATFORM=k3-j721e CFG_ARM64_core=y -4. U-Boot: +3. U-Boot: * 4.1 R5: .. code-block:: bash -make CROSS_COMPILE=arm-linux-gnueabihf- j721e_evm_r5_defconfig O=build/r5 -make CROSS_COMPILE=arm-linux-gnueabihf- O=build/r5 + $ make j721e_evm_r5_defconfig + $ make CROSS_COMPILE=arm-linux-gnueabihf- \ +BINMAN_INDIRS= * 4.2 A72: .. code-block:: bash -make
[PATCH v5 19/23] k3: tools: config.mk: Update makefile and remove scripts
Since binman is used to package bootloader images for all K3 devices, we
do not have to rely on the earlier methods to package them.
Scripts that were used to generate x509 certificate for tiboot3.bin and
generate tispl.bin, u-boot.img have been removed.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/mach-k3/config.mk | 103 ---
tools/k3_fit_atf.sh| 123 -
tools/k3_gen_x509_cert.sh | 262 -
3 files changed, 488 deletions(-)
delete mode 100644 arch/arm/mach-k3/config.mk
delete mode 100755 tools/k3_fit_atf.sh
delete mode 100755 tools/k3_gen_x509_cert.sh
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
deleted file mode 100644
index cbf9c10210..00
--- a/arch/arm/mach-k3/config.mk
+++ /dev/null
@@ -1,103 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
-# Lokesh Vutla
-
-ifdef CONFIG_SPL_BUILD
-
-# Openssl is required to generate x509 certificate.
-# Error out if openssl is not available.
-ifeq ($(shell which openssl),)
-$(error "No openssl in $(PATH), consider installing openssl")
-endif
-
-IMAGE_SIZE= $(shell cat $(obj)/u-boot-spl.bin | wc -c)
-MAX_SIZE= $(shell printf "%d" $(CONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE))
-
-ifeq ($(CONFIG_SYS_K3_KEY), "")
-KEY=""
-# On HS use real key or warn if not available
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
-KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
-else
-$(warning "WARNING: signing key not found. Random key will NOT work on HS
hardware!")
-endif
-endif
-else
-KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
-endif
-
-# X509 SWRV default
-SWRV = $(CONFIG_K3_X509_SWRV)
-# On HS use SECDEV provided software revision or warn if not available
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/swrv.txt),)
-SWRV= $(shell cat $(TI_SECURE_DEV_PKG)/keys/swrv.txt)
-else
-$(warning "WARNING: Software revision file not found. Default may not work on
HS hardware.")
-endif
-endif
-
-# tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
-# So restrict tiboot3.bin creation for CPU_V7R.
-ifdef CONFIG_CPU_V7R
-image_check: $(obj)/u-boot-spl.bin FORCE
- @if [ $(IMAGE_SIZE) -gt $(MAX_SIZE) ]; then \
- echo "===" >&2; \
- echo "ERROR: Final Image too big. " >&2;\
- echo "$< size = $(IMAGE_SIZE), max size = $(MAX_SIZE)" >&2; \
- echo "===" >&2; \
- exit 1; \
- fi
-
-tiboot3.bin: image_check FORCE
- $(srctree)/tools/k3_gen_x509_cert.sh -c 16 -b $(obj)/u-boot-spl.bin \
- -o $@ -l $(CONFIG_SPL_TEXT_BASE) -r $(SWRV) -k
$(KEY)
-
-INPUTS-y += tiboot3.bin
-endif
-
-ifdef CONFIG_ARM64
-
-ifeq ($(CONFIG_SOC_K3_J721E),)
-export DM := /dev/null
-endif
-
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-SPL_ITS := u-boot-spl-k3_HS.its
-$(SPL_ITS): export IS_HS=1
-INPUTS-y += tispl.bin_HS
-INPUTS-y += tispl.bin
-tispl.bin: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst
%,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST)))
-else
-SPL_ITS := u-boot-spl-k3.its
-INPUTS-y += tispl.bin
-endif
-
-ifeq ($(CONFIG_SPL_OF_LIST),)
-LIST_OF_DTB := $(CONFIG_DEFAULT_DEVICE_TREE)
-else
-LIST_OF_DTB := $(CONFIG_SPL_OF_LIST)
-endif
-
-quiet_cmd_k3_mkits = MKITS $@
-cmd_k3_mkits = \
- $(srctree)/tools/k3_fit_atf.sh \
- $(CONFIG_K3_ATF_LOAD_ADDR) \
- $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(LIST_OF_DTB))) > $@
-
-$(SPL_ITS): FORCE
- $(call cmd,k3_mkits)
-endif
-
-else
-
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-INPUTS-y += u-boot.img_HS
-else
-INPUTS-y += u-boot.img
-endif
-endif
-
-include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
deleted file mode 100755
index 7bc07ad074..00
--- a/tools/k3_fit_atf.sh
+++ /dev/null
@@ -1,123 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0+
-#
-# script to generate FIT image source for K3 Family boards with
-# ATF, OPTEE, SPL and multiple device trees (given on the command line).
-# Inspired from board/sunxi/mksunxi_fit_atf.sh
-#
-# usage: $0 [ [&2
- ATF=/dev/null
-fi
-
-[ -z "$TEE" ] && TEE="bl32.bin"
-
-if [ ! -f $TEE ]; then
- echo "WARNING OPTEE file $TEE NOT found, resulting might be
non-functional" >&2
- TEE=/dev/null
-fi
-
-[ -z "$DM" ] && DM="dm.bin"
-
-if [ ! -e $DM ]; then
- echo "WARNING DM file $DM NOT found, resulting might be non-functional"
>&2
- DM=/dev/null
-fi
-
-if [ ! -z "$IS_HS" ]; then
- HS_APPEND=_HS
-fi
-
-cat << __HEADER_EOF
-/dts-v1/;
-
-/ {
- description = "Configuration to load
[PATCH v5 16/23] am62a: yaml: Add board configs for AM62ax
Added YAML configs for AM62ax Signed-off-by: Neha Malcom Francis --- board/ti/am62ax/board-cfg.yaml | 36 + board/ti/am62ax/pm-cfg.yaml | 12 + board/ti/am62ax/rm-cfg.yaml | 1151 ++ board/ti/am62ax/sec-cfg.yaml | 379 ++ board/ti/am62ax/tifs-rm-cfg.yaml | 1011 ++ 5 files changed, 2589 insertions(+) create mode 100644 board/ti/am62ax/board-cfg.yaml create mode 100644 board/ti/am62ax/pm-cfg.yaml create mode 100644 board/ti/am62ax/rm-cfg.yaml create mode 100644 board/ti/am62ax/sec-cfg.yaml create mode 100644 board/ti/am62ax/tifs-rm-cfg.yaml diff --git a/board/ti/am62ax/board-cfg.yaml b/board/ti/am62ax/board-cfg.yaml new file mode 100644 index 00..6e45b494e0 --- /dev/null +++ b/board/ti/am62ax/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM62ax +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am62ax/pm-cfg.yaml b/board/ti/am62ax/pm-cfg.yaml new file mode 100644 index 00..a491f11260 --- /dev/null +++ b/board/ti/am62ax/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM62ax +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml new file mode 100644 index 00..0e11bd3e3c --- /dev/null +++ b/board/ti/am62ax/rm-cfg.yaml @@ -0,0 +1,1151 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM62ax +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +
[PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
Move to using binman to generate tispl.bin which is used to generate the
final flash.bin bootloader for iot2050 boards.
Signed-off-by: Neha Malcom Francis
Cc: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++-
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 03ccc54329..9d83898d33 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -26,9 +26,81 @@
missing-msg = "iot2050-seboot";
};
- blob@0x18 {
+ fit@0x18 {
offset = <0x18>;
- filename = "tispl.bin";
+ pad-byte = <0xff>;
+ description = "Configuration to load ATF and SPL";
+
+ images {
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ os = "arm-trusted-firmware";
+ load = ;
+ entry = ;
+ atf: atf-bl31 {
+ };
+ };
+
+ tee {
+ description = "OPTEE";
+ type = "tee";
+ arch = "arm64";
+ compression = "none";
+ os = "tee";
+ load = <0x9e80>;
+ entry = <0x9e80>;
+ tee: tee-os {
+ };
+ };
+
+ dm {
+ description = "DM binary";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "DM";
+ load = <0x8900>;
+ entry = <0x8900>;
+ blob-ext {
+ filename = "/dev/null";
+ };
+ };
+
+ spl {
+ description = "SPL (64-bit)";
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+ entry = ;
+ u_boot_spl_nodtb: blob-ext {
+ filename =
"spl/u-boot-spl-nodtb.bin";
+ };
+ };
+
+ fdt-0 {
+ description = "k3-am65-iot2050-spl.dtb";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ spl_am65x_evm_dtb: blob-ext {
+ filename =
"spl/dts/k3-am65-iot2050-spl.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "spl";
+ spl {
+ fdt = "fdt-0";
+ firmware = "atf";
+ loadables = "tee", "dm", "spl";
+ };
+ };
};
fit@0x38 {
--
2.34.1
[PATCH v5 17/23] am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
Support added for HS-SE, HS-FS and GP boot binaries for AM62ax.
HS-SE:
* tiboot3-am62ax-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-am62ax-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am62ax-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by AM62ax requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am62a-sk-binman.dtsi | 466 +++
arch/arm/dts/k3-am62a7-r5-sk.dts | 1 +
arch/arm/dts/k3-am62a7-sk.dts| 1 +
board/ti/am62ax/Kconfig | 2 +
4 files changed, 470 insertions(+)
create mode 100644 arch/arm/dts/k3-am62a-sk-binman.dtsi
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
new file mode 100644
index 00..abbac8f084
--- /dev/null
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -0,0 +1,466 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM62A7_R5_EVM
+
+_yaml_tifs {
+ config = "tifs-rm-cfg.yaml";
+};
+
+ {
+ tiboot3-am62ax-hs-evm.bin {
+ filename = "tiboot3-am62ax-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-am62ax-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-am62ax-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3-am62ax-hs-fs-evm.bin {
+ filename = "tiboot3-am62ax-hs-fs-evm.bin";
+ symlink = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-am62ax-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+
[PATCH v5 15/23] am625: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
Support added for HS-SE, HS-FS and GP boot binaries for AM62.
HS-SE:
* tiboot3-am62x-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-am62x-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am62x-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by AM62 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am625-r5-sk.dts | 1 +
arch/arm/dts/k3-am625-sk-binman.dtsi | 463 +++
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 2 +
board/ti/am62x/Kconfig | 2 +
4 files changed, 468 insertions(+)
create mode 100644 arch/arm/dts/k3-am625-sk-binman.dtsi
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 78df7cec3f..3ec5bad735 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -9,6 +9,7 @@
#include "k3-am62-ddr.dtsi"
#include "k3-am625-sk-u-boot.dtsi"
+#include "k3-am625-sk-binman.dtsi"
/ {
aliases {
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
new file mode 100644
index 00..c5bd9e48d0
--- /dev/null
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -0,0 +1,463 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM625_R5_EVM
+
+ {
+ tiboot3-am62x-hs-evm.bin {
+ filename = "tiboot3-am62x-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-am62x-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-am62x-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3-am62x-hs-fs-evm.bin {
+ filename = "tiboot3-am62x-hs-fs-evm.bin";
+ symlink = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-am62x-hs-fs-enc.bin";
+
[PATCH v5 14/23] am62: yaml: Add board configs for AM62
Added YAML configs for AM62 Signed-off-by: Neha Malcom Francis --- board/ti/am62x/board-cfg.yaml | 36 ++ board/ti/am62x/pm-cfg.yaml| 12 + board/ti/am62x/rm-cfg.yaml| 1088 + board/ti/am62x/sec-cfg.yaml | 379 4 files changed, 1515 insertions(+) create mode 100644 board/ti/am62x/board-cfg.yaml create mode 100644 board/ti/am62x/pm-cfg.yaml create mode 100644 board/ti/am62x/rm-cfg.yaml create mode 100644 board/ti/am62x/sec-cfg.yaml diff --git a/board/ti/am62x/board-cfg.yaml b/board/ti/am62x/board-cfg.yaml new file mode 100644 index 00..a26ef55bd4 --- /dev/null +++ b/board/ti/am62x/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM62 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am62x/pm-cfg.yaml b/board/ti/am62x/pm-cfg.yaml new file mode 100644 index 00..aa94097e97 --- /dev/null +++ b/board/ti/am62x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM62 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am62x/rm-cfg.yaml b/board/ti/am62x/rm-cfg.yaml new file mode 100644 index 00..1e8678c30b --- /dev/null +++ b/board/ti/am62x/rm-cfg.yaml @@ -0,0 +1,1088 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM62 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0
[PATCH v5 12/23] j721s2: yaml: Add board configs for J721S2
Added YAML configs for J721S2 Signed-off-by: Neha Malcom Francis --- board/ti/j721s2/board-cfg.yaml | 37 + board/ti/j721s2/pm-cfg.yaml| 12 + board/ti/j721s2/rm-cfg.yaml| 2901 board/ti/j721s2/sec-cfg.yaml | 379 + 4 files changed, 3329 insertions(+) create mode 100644 board/ti/j721s2/board-cfg.yaml create mode 100644 board/ti/j721s2/pm-cfg.yaml create mode 100644 board/ti/j721s2/rm-cfg.yaml create mode 100644 board/ti/j721s2/sec-cfg.yaml diff --git a/board/ti/j721s2/board-cfg.yaml b/board/ti/j721s2/board-cfg.yaml new file mode 100644 index 00..d80f308ca6 --- /dev/null +++ b/board/ti/j721s2/board-cfg.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for J721S2 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 + diff --git a/board/ti/j721s2/pm-cfg.yaml b/board/ti/j721s2/pm-cfg.yaml new file mode 100644 index 00..45994e23cc --- /dev/null +++ b/board/ti/j721s2/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for J721S2 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/j721s2/rm-cfg.yaml b/board/ti/j721s2/rm-cfg.yaml new file mode 100644 index 00..6058f3b35c --- /dev/null +++ b/board/ti/j721s2/rm-cfg.yaml @@ -0,0 +1,2901 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for J721S2 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 21 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #6 +host_id: 23 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #7 +host_id: 35 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #8 +host_id: 37 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #9 +host_id: 40 +allowed_atype : 0x2A +
[PATCH v5 13/23] j721s2: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
Support has been added for both HS-SE, HS-FS and GP images.
HS-SE:
* tiboot3-j721s2-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-j721s2-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-j721s2-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
It is to be noted that the bootflow followed by J721S2 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
.../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 2 +
arch/arm/dts/k3-j721s2-binman.dtsi| 546 ++
.../k3-j721s2-common-proc-board-u-boot.dtsi | 2 +
.../dts/k3-j721s2-r5-common-proc-board.dts| 1 +
board/ti/j721s2/Kconfig | 2 +
5 files changed, 553 insertions(+)
create mode 100644 arch/arm/dts/k3-j721s2-binman.dtsi
diff --git a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
index ee31b1ebe7..79faa1b573 100644
--- a/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am68-sk-base-board-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-j721s2-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi
b/arch/arm/dts/k3-j721s2-binman.dtsi
new file mode 100644
index 00..7fd7ba8e5d
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-binman.dtsi
@@ -0,0 +1,546 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J721S2_R5_EVM
+
+ {
+ tiboot3-j721s2-hs-evm.bin {
+ filename = "tiboot3-j721s2-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j721s2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-j721s2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3-j721s2-hs-fs-evm.bin {
+ filename = "tiboot3-j721s2-hs-fs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+
[PATCH v5 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
Support added for HS and GP boot binaries for AM64x.
HS-SE:
* tiboot3-am64x_sr2-hs-evm.bin
* tispl.bin
* u-boot.img
HS-FS:
* tiboot3-am64x_sr2-hs-fs-evm.bin
* tispl.bin
* u-boot.img
GP:
* tiboot3.bin --> tiboot3-am64x-gp-evm.bin
* tispl.bin_unsigned
* u-boot.img_unsigned
Note that the bootflow followed by AM64x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
[a...@ti.com: changed output binary names appropriately]
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 +
arch/arm/dts/k3-am642-r5-evm.dts | 1 +
arch/arm/dts/k3-am642-sk-u-boot.dtsi | 2 +
arch/arm/dts/k3-am64x-binman.dtsi | 515 ++
board/ti/am64x/Kconfig| 2 +
5 files changed, 522 insertions(+)
create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b0909..73577e8cfd 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-am64x-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index e870492a69..b49064181a 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -8,6 +8,7 @@
#include "k3-am642.dtsi"
#include "k3-am64-evm-ddr4-1600MTs.dtsi"
#include "k3-am64-ddr.dtsi"
+#include "k3-am64x-binman.dtsi"
/ {
chosen {
diff --git a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
index 69dbe943bd..3d6be025bd 100644
--- a/arch/arm/dts/k3-am642-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-sk-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-am64x-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-am64x-binman.dtsi
b/arch/arm/dts/k3-am64x-binman.dtsi
new file mode 100644
index 00..e6ca2457b4
--- /dev/null
+++ b/arch/arm/dts/k3-am64x-binman.dtsi
@@ -0,0 +1,515 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM642_R5_EVM
+
+ {
+ tiboot3-am64x_sr2-hs-evm.bin {
+ filename = "tiboot3-am64x_sr2-hs-evm.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_sci_enc>,
+ <_sysfw_cfg>, <_inner_cert>;
+ combined;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_sci_enc>;
+ content-sysfw-data = <_sysfw_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ load = <0x7000>;
+ load-sysfw = <0x44000>;
+ load-sysfw-data = <0x7b000>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_sci_enc: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_sysfw_cfg: combined-sysfw-cfg.bin {
+ filename = "combined-sysfw-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+
+ };
+};
+
+ {
+ tiboot3-am64x_sr2-hs-fs-evm.bin {
+ filename = "tiboot3-am64x_sr2-hs-fs-evm.bin";
+ symlink = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_sci_enc_fs>,
+ <_sysfw_cfg_fs>,
<_inner_cert_fs>;
+ combined;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_sci_enc_fs>;
+ content-sysfw-data = <_sysfw_cfg_fs>;
+
