[PATCH] clk: Fix error message in clk_get_bulk
From: Jan Kiszka
Fix a logical inversion of the printed text.
Signed-off-by: Jan Kiszka
---
drivers/clk/clk-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index ed6e60bc484..78d8ea94c65 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -180,7 +180,7 @@ int clk_get_bulk(struct udevice *dev, struct clk_bulk *bulk)
bulk_get_err:
err = clk_release_all(bulk->clks, bulk->count);
if (err)
- debug("%s: could release all clocks for %p\n",
+ debug("%s: could not release all clocks for %p\n",
__func__, dev);
return ret;
--
2.35.3
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 21.02.24 10:10, Francesco Dolcini wrote: > Hello Jan, > > On Mon, Feb 19, 2024 at 07:37:55PM +0100, Jan Kiszka wrote: >> My personal observation is that continuous integration testings with >> all-upstream components is not really a common thing. I saw that with >> multiple active SoCs from various vendors. > > With some limitation we have this running in Toradex since a couple of > years, we do integrate latest mainline kernel/u-boot and OE master > layers and run all that through our Lava test suite on real hardware. > > It has challenges, even getting the build to succeed is not obvious and > requires continuous care, but we do spot regression on RC releases and > we actively report and/or contribute fixes for it. > > Unfortunately the test results are still not published on some website > and are only internal, but we are working on making this available. > > Looking forward to have more players doing it, starting from the SoC > vendors! This is great to hear an highly welcome! One challenge of this is definitely to get the information to the right people, ideally without requiring too much manual effort (as that is often the most limited resource) while not overloading the target audience with too many false or inaccurate reports. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 19.02.24 19:37, Jan Kiszka wrote: > On 17.02.24 12:36, Alexander Sverdlin wrote: >> Hi Jan! >> >> On Sat, 2024-02-17 at 09:42 +0100, Jan Kiszka wrote: >>>> U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) >>>> >>>> SoC: AM62X SR1.0 HS-FS >>>> Model: Texas Instruments AM625 SK >>>> DRAM: 2 GiB >>>> Core: 56 devices, 23 uclasses, devicetree: separate >>>> MMC: mmc@fa1: 0, mmc@fa0: 1 >>>> Loading Environment from nowhere... OK >>>> In: serial@280 >>>> Out: serial@280 >>>> Err: serial@280 >>>> Net: eth0: ethernet@800port@1 >>>> Hit any key to stop autoboot: 0 >>>> switch to partitions #0, OK >>>> mmc1 is current device >>>> SD/MMC found on device 1 >>>> Failed to load 'uEnv.txt' >>>> Scanning for bootflows in all bootdevs >>>> Seq Method State Uclass Part Name >>>> Filename >>>> --- --- -- >>>> >>>> Scanning global bootmeth 'efi_mgr': >>>> No EFI system partition >>>> No EFI system partition >>>> Failed to persist EFI variables >>>> Scanning bootdev 'mmc@fa0.bootdev': >>>> Scanning bootdev 'mmc@fa1.bootdev': >>>> Unknown uclass 'usb' in label >>>> link up on port 1, speed 100, full duplex >>>> BOOTP broadcast 1 >>>> BOOTP broadcast 2 >>>> BOOTP broadcast 3 >>>> ... >>>> --- >>>> >>>> I suppose TI's BSP has older U-Boot... So it's not providing necessary >>>> script for BOOTSTD, I suppose? >>>> >>> >>> You can make the BeagleBone boot via EFI, but it requires a hybrid >>> partition table (ROM loader want DOS, EFI needs GPT). A Debian >>> integration with this can be found for Isar [1] in this series [2]. It's >>> only using upstream sources (plus still one u-boot patch to get wifi >>> working). >>> >>> If you want legacy script booting, I suspect you need to flip some extra >>> switches explicitly by now. >> >> Thanks for the hints! >> I'm wondering, if this was a deliberate "let's stop booting all the >> pre-existing embedded distros" decision? (buildroot, yocto/meta-ti...) >> > > FWIW, I'm not seeing other boot methods being specifically disabled in > beagleplay in 2024.01 or even newer. I didn't try the result, but this > may actually be some other issue and real bug, nothing obviously intended. > I'm not even sure about this anymore, though there is still a bug, just a different one: ... U-Boot 2024.04-rc2-00040-g3e6f2a94bfc (Feb 20 2024 - 08:42:59 +0100) SoC: AM62X SR1.0 GP Model: BeagleBoard.org BeaglePlay DRAM: 2 GiB Core: 98 devices, 27 uclasses, devicetree: separate MMC: mmc@fa1: 0, mmc@fa0: 1, mmc@fa2: 2 Loading Environment from nowhere... OK In:serial@280 Out: serial@280 Err: serial@280 Net: No ethernet found. Press SPACE to abort autoboot in 2 seconds => print bootmeths bootmeths=script extlinux efi pxe => bootflow scan -l Scanning for bootflows in all bootdevs Seq Method State UclassPart Name Filename --- --- -- Scanning bootdev 'mmc@fa0.bootdev': 0 efi ready mmc 2 mmc@fa0.bootdev.part_ efi/boot/bootaa64.efi Scanning bootdev 'mmc@fa1.bootdev': 1 extlinux ready mmc 1 mmc@fa1.bootdev.part_ /extlinux/extlinux.conf Unknown uclass 'usb' in label "Synchronous Abort" handler, esr 0x8604, far 0x3030303030303840 elr: 3030302fb0bc0840 lr : 3030302fb0bc0840 (reloc) elr: 3030303030303840 lr : 3030303030303840 x0 : ffed x1 : x2 : 0002 x3 : ffb49d30 x4 : fffd4c00 x5 : ffb49d50 x6 : x7 : ffb4e890 x8 : 6924 x9 : ffb1212c x10: 0003 x11: 6914 x12: ffb1221c x13: ffb12b40 x14: ffb12b40 x15: ffb12535 x16: fff8a9d4 x17: x18: ffb23da0 x19: 314074726f70 x20: fffed000 x21: fffef000 x22: x23: fffef000 x24: fffef000 x25: x26: fffc7174 x27: x28: x29: 74656e7265687465 Same with 2024.01 release. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 17.02.24 12:36, Alexander Sverdlin wrote: > Hi Jan! > > On Sat, 2024-02-17 at 09:42 +0100, Jan Kiszka wrote: >>> U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) >>> >>> SoC: AM62X SR1.0 HS-FS >>> Model: Texas Instruments AM625 SK >>> DRAM: 2 GiB >>> Core: 56 devices, 23 uclasses, devicetree: separate >>> MMC: mmc@fa1: 0, mmc@fa0: 1 >>> Loading Environment from nowhere... OK >>> In: serial@280 >>> Out: serial@280 >>> Err: serial@280 >>> Net: eth0: ethernet@800port@1 >>> Hit any key to stop autoboot: 0 >>> switch to partitions #0, OK >>> mmc1 is current device >>> SD/MMC found on device 1 >>> Failed to load 'uEnv.txt' >>> Scanning for bootflows in all bootdevs >>> Seq Method State Uclass Part Name Filename >>> --- --- -- >>> >>> Scanning global bootmeth 'efi_mgr': >>> No EFI system partition >>> No EFI system partition >>> Failed to persist EFI variables >>> Scanning bootdev 'mmc@fa0.bootdev': >>> Scanning bootdev 'mmc@fa1.bootdev': >>> Unknown uclass 'usb' in label >>> link up on port 1, speed 100, full duplex >>> BOOTP broadcast 1 >>> BOOTP broadcast 2 >>> BOOTP broadcast 3 >>> ... >>> --- >>> >>> I suppose TI's BSP has older U-Boot... So it's not providing necessary >>> script for BOOTSTD, I suppose? >>> >> >> You can make the BeagleBone boot via EFI, but it requires a hybrid >> partition table (ROM loader want DOS, EFI needs GPT). A Debian >> integration with this can be found for Isar [1] in this series [2]. It's >> only using upstream sources (plus still one u-boot patch to get wifi >> working). >> >> If you want legacy script booting, I suspect you need to flip some extra >> switches explicitly by now. > > Thanks for the hints! > I'm wondering, if this was a deliberate "let's stop booting all the > pre-existing embedded distros" decision? (buildroot, yocto/meta-ti...) > FWIW, I'm not seeing other boot methods being specifically disabled in beagleplay in 2024.01 or even newer. I didn't try the result, but this may actually be some other issue and real bug, nothing obviously intended. My personal observation is that continuous integration testings with all-upstream components is not really a common thing. I saw that with multiple active SoCs from various vendors. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 17.02.24 04:11, Alexander Sverdlin wrote: > Hello Nishanth, > > On Fri, 2023-08-25 at 13:02 -0500, Nishanth Menon wrote: >> Switch to using bootstd. Note with this change, we will stop using >> distro_bootcmd and instead depend entirely on bootflow method of >> starting the system up. >> >> Suggested-by: Tom Rini >> Suggested-by: Simon Glass >> Reviewed-by: Tom Rini >> Tested-by: Mattijs Korpershoek >> Signed-off-by: Nishanth Menon >> Reviewed-by: Tom Rini >> Reviewed-by: Mattijs Korpershoek >> --- >> No change other than picking up reviews, tested tags along the way. >> V5: https://lore.kernel.org/r/20230824031101.3460411-6...@ti.com >> configs/am62x_evm_a53_defconfig | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >> diff --git a/configs/am62x_evm_a53_defconfig >> b/configs/am62x_evm_a53_defconfig >> index d55caabe22c9..1807df8bbee9 100644 >> --- a/configs/am62x_evm_a53_defconfig >> +++ b/configs/am62x_evm_a53_defconfig >> @@ -28,8 +28,9 @@ CONFIG_SPL_SPI=y >> # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set >> CONFIG_SPL_LOAD_FIT=y >> CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100 >> -CONFIG_DISTRO_DEFAULTS=y >> -CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;" >> +CONFIG_BOOTSTD_FULL=y >> +CONFIG_BOOTSTD_DEFAULTS=y >> +CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb" >> CONFIG_SPL_MAX_SIZE=0x58000 >> CONFIG_SPL_HAS_BSS_LINKER_SECTION=y >> CONFIG_SPL_BSS_START_ADDR=0x80c8 > > could you please suggest which distro have you used for testing? > > After U-Boot update to v2024.01 Buildroot is not booting any more: > > --- > U-Boot 2024.01 (Feb 15 2024 - 01:43:17 +0100) > > SoC: AM62X SR1.0 HS-FS > Model: Texas Instruments AM625 SK > DRAM: 2 GiB > Core: 56 devices, 23 uclasses, devicetree: separate > MMC: mmc@fa1: 0, mmc@fa0: 1 > Loading Environment from nowhere... OK > In:serial@280 > Out: serial@280 > Err: serial@280 > Net: eth0: ethernet@800port@1 > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc1 is current device > SD/MMC found on device 1 > Failed to load 'uEnv.txt' > Scanning for bootflows in all bootdevs > Seq Method State UclassPart Name Filename > --- --- -- > > Scanning global bootmeth 'efi_mgr': > No EFI system partition > No EFI system partition > Failed to persist EFI variables > Scanning bootdev 'mmc@fa0.bootdev': > Scanning bootdev 'mmc@fa1.bootdev': > Unknown uclass 'usb' in label > link up on port 1, speed 100, full duplex > BOOTP broadcast 1 > BOOTP broadcast 2 > BOOTP broadcast 3 > ... > --- > > I suppose TI's BSP has older U-Boot... So it's not providing necessary > script for BOOTSTD, I suppose? > You can make the BeagleBone boot via EFI, but it requires a hybrid partition table (ROM loader want DOS, EFI needs GPT). A Debian integration with this can be found for Isar [1] in this series [2]. It's only using upstream sources (plus still one u-boot patch to get wifi working). If you want legacy script booting, I suspect you need to flip some extra switches explicitly by now. Jan [1] https://github.com/ilbers/isar/ [2] https://patchwork.isar-build.org/project/isar/list/?series=1049 -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 3/6] board: ti: am62x: Add basic initialization for usb voltage, 32k crystal, debounce
On 26.07.23 13:10, Nishanth Menon wrote: > On 00:35-20230726, Francesco Dolcini wrote: > [...] At least the ones we have currently (I am not sure about toradex, phytech etc), seem to operate the vdd_core at 0.85V .. (which is what USB is dependent upon). >>> >>> For Toradex, we do have the equivalent code in our board file, see >>> https://git.toradex.com/cgit/u-boot-toradex.git/tree/board/toradex/verdin-am62/verdin-am62.c?h=toradex_ti-u-boot-2023.04#n92 >>> >>> The 32kHz configuration is just different for us, we do not re-use the >>> same you have here. > > True, you are hitting the bypass control and not powering on the > oscillator control since the 32k is incoming from RTC, in my case, since > I have an actual 32k crystal, I am clearing the powerdown. > > >>> >>> The debounce conf registers I have no idea what they are about, >>> something we should have also on our board? Any additional details? >> >> So, I got curious and checked on the datasheet/TRM on this debounce. If >> I understood correctly this is to have debounce on GPIO and/or EQEP. > > Typically, yes - input signals more useful for eQEP or GPIO. but the > implementation is at pin level which, technically could be used for > other purposes (but I have'nt seen any). > >> >> However to my understanding this would need to have the corresponding >> DEBOUNCE_SEL register written on the pad configuration, and by default it's >> 0. >> >> What's the use case for this debounce configuration you have here? > > TRM was a bit of a crap (internal ticket was filed to improve), but long > story short: > * bootloader configures delays per index > * in the pinmux configuration, we pick which index to use for the pin > > On Beagleplay, for example, the HDMI hot plug detect GPIO benefited from > this[1]. Corresponding pinctrl.h macros were posted in [2]. > > Why do it in the bootloader? since gpio inputs could also used in u-boot > (e.g. MMC/CD) > > > All said, Tom's question is very valid - we'd rather not modify evm.c > for these specific configurations (popcorn as they might be), and we > need to figure out a better option to introduce this kind of variation > cleanly. For now, I will try dropping this patch. > > > [1] > https://git.beagleboard.org/beagleboard/linux/-/blob/v6.1.33-ti-rt-arm64-r6/arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts#L311 > [2] https://lore.kernel.org/all/20230619131620.3286650-1...@ti.com/ > What happened to this? I still need something like this patch (a version that has the CFG register writes correctly ordered) on top of current master in order to get WIFI on the Beagleplay. Jan
[PATCH] arm: dts: iot2050: Fix by syncing from Linux
From: Jan Kiszka
This restores support for IOT2050 by widely synchronizing its DT files
with the Linux kernel. We additionally need to add the alias restoration
that is still waiting for its upstream merge and the not-yet-upstreamed
bits needed for watchdog reboot detection.
Fixes: 4dbdc84754ea ("arm: dts: k3-am654: pull in dtb update from Linux")
Signed-off-by: Jan Kiszka
---
Bryan, please don't do partial DT syncing in future anymore!
arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi | 2 +-
arch/arm/dts/k3-am65-iot2050-common.dtsi | 218 +-
.../dts/k3-am6528-iot2050-basic-common.dtsi | 3 +-
.../k3-am6548-iot2050-advanced-common.dtsi| 6 +-
.../arm/dts/k3-am6548-iot2050-advanced-m2.dts | 28 ++-
5 files changed, 123 insertions(+), 134 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
index e73458ca690..e9419c4fe60 100644
--- a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
@@ -10,7 +10,7 @@
*/
_pmx0 {
- cp2102n_reset_pin_default: cp2102n-reset-pin-default {
+ cp2102n_reset_pin_default: cp2102n-reset-default-pins {
pinctrl-single,pins = <
/* (AF12) GPIO1_24, used as cp2102 reset */
AM65X_IOPAD(0x01e0, PIN_OUTPUT, 7)
diff --git a/arch/arm/dts/k3-am65-iot2050-common.dtsi
b/arch/arm/dts/k3-am65-iot2050-common.dtsi
index b6135b849f1..fa7178144b8 100644
--- a/arch/arm/dts/k3-am65-iot2050-common.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-common.dtsi
@@ -14,6 +14,16 @@
/ {
aliases {
+ serial0 = _uart0;
+ serial1 = _uart0;
+ serial2 = _uart0;
+ serial3 = _uart1;
+ i2c0 = _i2c0;
+ i2c1 = _i2c0;
+ i2c2 = _i2c0;
+ i2c3 = _i2c1;
+ i2c4 = _i2c2;
+ i2c5 = _i2c3;
spi0 = _spi0;
mmc0 =
mmc1 =
@@ -21,7 +31,6 @@
chosen {
stdout-path = "serial3:115200n8";
- bootargs = "earlycon=ns16550a,mmio32,0x0281";
};
reserved-memory {
@@ -111,7 +120,7 @@
};
_pmx0 {
- wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
pinctrl-single,pins = <
/* (AC7) WKUP_I2C0_SCL */
AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0)
@@ -120,7 +129,7 @@
>;
};
- mcu_i2c0_pins_default: mcu-i2c0-pins-default {
+ mcu_i2c0_pins_default: mcu-i2c0-default-pins {
pinctrl-single,pins = <
/* (AD8) MCU_I2C0_SCL */
AM65X_WKUP_IOPAD(0x00e8, PIN_INPUT, 0)
@@ -129,21 +138,21 @@
>;
};
- arduino_i2c_aio_switch_pins_default:
arduino-i2c-aio-switch-pins-default {
+ arduino_i2c_aio_switch_pins_default:
arduino-i2c-aio-switch-default-pins {
pinctrl-single,pins = <
/* (R2) WKUP_GPIO0_21 */
AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
>;
};
- push_button_pins_default: push-button-pins-default {
+ push_button_pins_default: push-button-default-pins {
pinctrl-single,pins = <
/* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7)
>;
};
- arduino_uart_pins_default: arduino-uart-pins-default {
+ arduino_uart_pins_default: arduino-uart-default-pins {
pinctrl-single,pins = <
/* (P4) MCU_UART0_RXD */
AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
@@ -152,7 +161,7 @@
>;
};
- arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-pins-default {
+ arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-default-pins {
pinctrl-single,pins = <
/* (P1) WKUP_GPIO0_31 */
AM65X_WKUP_IOPAD(0x004C, PIN_OUTPUT, 7)
@@ -161,7 +170,7 @@
>;
};
- arduino_io_oe_pins_default: arduino-io-oe-pins-default {
+ arduino_io_oe_pins_default: arduino-io-oe-default-pins {
pinctrl-single,pins = <
/* (N4) WKUP_GPIO0_34 */
AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7)
@@ -176,7 +185,7 @@
>;
};
- mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
+ mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins {
pinctrl-single,pins = <
/* (V1) MCU_OSPI0_CLK */
AM65X_WKUP_IOPAD(0x, PIN_OUTPUT, 0)
@@ -191,7 +200,7 @@
Re: [PATCH v2 00/26] sync am65x device tree with Linux v6.7-rc1
On 06.01.24 12:57, Jan Kiszka wrote: > On 29.12.23 18:46, Bryan Brattlof wrote: >> Hello Again Everyone! >> >> This series gets the am65x booting again along with syncing the device >> tree files with v6.7-rc1 Linux. >> >> The bulk of these patches unify the WKUP SPL board file with the arm64 >> files to make future syncs from Linux much easier. In the end the DTBs >> should look a lot like what the DTBs look like for the am64x which >> is fairly similar to the am65x. >> >> For those interested in what UART boot looks like: >>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc >> >> Changes from v1: [0] >> - fixed multi-line comment format >> - moved wkup_uart0 and mcu_uart0 U-Boot overrides to the r5 board file >> as they are not needed for a53/main domain U-Boot builds >> - corrected a bad wkup_i2c0_pins_default fixup in PATCH 6/26 >> - spelling fix (s/Libux/Linux/) in commit body for PATCH 6/26 >> - added trailers from Tom >> >> Thanks for reviewing and happy holidays >> ~Bryan >> >> [0] https://lore.kernel.org/u-boot/20231221174412.210807-1...@ti.com/ >> >> Bryan Brattlof (26): >> configs: am65x_evm_r5: enable driver for fixed regulators >> configs: am65x_evm_a53: disable CONSOLE_MUX >> arm: dts: k3-am654-r5: Merge board file and U-Boot overlay >> arm: dts: k3-am654: pull in dtb update from Linux >> arm: dts: k3-am654: copy bootph properties to a53 dts >> arm: dts: k3-am654: include a53 board dtb for r5 build >> arm: dts: k3-am654: remove duplicate vtt_supply >> arm: dts: k3-am654: remove duplicate wkup_uart0 >> arm: dts: k3-am654: remove duplicate timer >> arm: dts: k3-am654: remove duplicate mcu_ringacc >> arm: dts: k3-am654: remove duplicate mcu_udmap >> arm: dts: k3-am654: add needed regs to udmap nodes >> arm: dts: k3-am654: remove duplicate mcu_uart0 node >> arm: dts: k3-am654: remove duplicate main_uart0 >> arm: dts: k3-am654: remove duplicate sdhci0 pinmux node >> arm: dts: k3-am654: remove duplicate sdhci1 pinmux node >> arm: dts: k3-am654: remove duplicate wkup_i2c0 >> arm: dts: k3-am654: remove duplicate ospi0 node >> arm: dts: k3-am654: remove usb0 >> arm: dts: k3-am654: remove duplicate mdio >> arm: dts: k3-am654: remove duplicate vtt pinmux >> arm: dts: k3-am654: remove duplicate root properties >> arm: dts: k3-am654: remove un-needed aliases >> arm: dts: k3-am654: move dummy_clock to root node >> arm: dts: k3-am654: remove duplicate mcu secure proxy node >> arm: dts: k3-am654: convert bootph-pre-ram to bootph-all >> >> arch/arm/dts/k3-am65-main.dtsi| 342 +++--- >> arch/arm/dts/k3-am65-mcu.dtsi | 156 +++- >> arch/arm/dts/k3-am65-wakeup.dtsi | 10 +- >> arch/arm/dts/k3-am65.dtsi | 19 +- >> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 195 +- >> arch/arm/dts/k3-am654-base-board.dts | 301 +-- >> .../dts/k3-am654-r5-base-board-u-boot.dtsi| 208 --- >> arch/arm/dts/k3-am654-r5-base-board.dts | 303 >> arch/arm/dts/k3-am654.dtsi| 7 + >> configs/am65x_evm_a53_defconfig | 1 - >> configs/am65x_evm_r5_defconfig| 2 + >> 11 files changed, 886 insertions(+), 658 deletions(-) >> delete mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi >> >> >> base-commit: 0a0ceea2269b983e736b80104f03cc800d1a5e2a > > This breaks the IOT2050 boards, probably because it did in incomplete > sync, changing the core dtsi file without updating all affected boards. > But also [1] is missing in upstream already and seem to have an impact. > Bad timing for a sync. > > And the series is not bisectable - already the 3rd patch breaks the build: > > ... > DTC arch/arm/dts/k3-am654-r5-base-board.dtb > Error: arch/arm/dts/.k3-am654-r5-base-board.dtb.pre.tmp:423.27-28 syntax > error > FATAL ERROR: Unable to parse input tree > > Jan > > [1] > https://lore.kernel.org/lkml/1edbc1b56ed4ff2256d7afb7db3cab4b3a423692.1699087938.git.jan.kis...@siemens.com/ > BTW, folks @TI: You have our devices by now. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH v2 00/26] sync am65x device tree with Linux v6.7-rc1
On 29.12.23 18:46, Bryan Brattlof wrote: > Hello Again Everyone! > > This series gets the am65x booting again along with syncing the device > tree files with v6.7-rc1 Linux. > > The bulk of these patches unify the WKUP SPL board file with the arm64 > files to make future syncs from Linux much easier. In the end the DTBs > should look a lot like what the DTBs look like for the am64x which > is fairly similar to the am65x. > > For those interested in what UART boot looks like: >https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc > > Changes from v1: [0] > - fixed multi-line comment format > - moved wkup_uart0 and mcu_uart0 U-Boot overrides to the r5 board file > as they are not needed for a53/main domain U-Boot builds > - corrected a bad wkup_i2c0_pins_default fixup in PATCH 6/26 > - spelling fix (s/Libux/Linux/) in commit body for PATCH 6/26 > - added trailers from Tom > > Thanks for reviewing and happy holidays > ~Bryan > > [0] https://lore.kernel.org/u-boot/20231221174412.210807-1...@ti.com/ > > Bryan Brattlof (26): > configs: am65x_evm_r5: enable driver for fixed regulators > configs: am65x_evm_a53: disable CONSOLE_MUX > arm: dts: k3-am654-r5: Merge board file and U-Boot overlay > arm: dts: k3-am654: pull in dtb update from Linux > arm: dts: k3-am654: copy bootph properties to a53 dts > arm: dts: k3-am654: include a53 board dtb for r5 build > arm: dts: k3-am654: remove duplicate vtt_supply > arm: dts: k3-am654: remove duplicate wkup_uart0 > arm: dts: k3-am654: remove duplicate timer > arm: dts: k3-am654: remove duplicate mcu_ringacc > arm: dts: k3-am654: remove duplicate mcu_udmap > arm: dts: k3-am654: add needed regs to udmap nodes > arm: dts: k3-am654: remove duplicate mcu_uart0 node > arm: dts: k3-am654: remove duplicate main_uart0 > arm: dts: k3-am654: remove duplicate sdhci0 pinmux node > arm: dts: k3-am654: remove duplicate sdhci1 pinmux node > arm: dts: k3-am654: remove duplicate wkup_i2c0 > arm: dts: k3-am654: remove duplicate ospi0 node > arm: dts: k3-am654: remove usb0 > arm: dts: k3-am654: remove duplicate mdio > arm: dts: k3-am654: remove duplicate vtt pinmux > arm: dts: k3-am654: remove duplicate root properties > arm: dts: k3-am654: remove un-needed aliases > arm: dts: k3-am654: move dummy_clock to root node > arm: dts: k3-am654: remove duplicate mcu secure proxy node > arm: dts: k3-am654: convert bootph-pre-ram to bootph-all > > arch/arm/dts/k3-am65-main.dtsi| 342 +++--- > arch/arm/dts/k3-am65-mcu.dtsi | 156 +++- > arch/arm/dts/k3-am65-wakeup.dtsi | 10 +- > arch/arm/dts/k3-am65.dtsi | 19 +- > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 195 +- > arch/arm/dts/k3-am654-base-board.dts | 301 +-- > .../dts/k3-am654-r5-base-board-u-boot.dtsi| 208 --- > arch/arm/dts/k3-am654-r5-base-board.dts | 303 > arch/arm/dts/k3-am654.dtsi| 7 + > configs/am65x_evm_a53_defconfig | 1 - > configs/am65x_evm_r5_defconfig| 2 + > 11 files changed, 886 insertions(+), 658 deletions(-) > delete mode 100644 arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi > > > base-commit: 0a0ceea2269b983e736b80104f03cc800d1a5e2a This breaks the IOT2050 boards, probably because it did in incomplete sync, changing the core dtsi file without updating all affected boards. But also [1] is missing in upstream already and seem to have an impact. Bad timing for a sync. And the series is not bisectable - already the 3rd patch breaks the build: ... DTC arch/arm/dts/k3-am654-r5-base-board.dtb Error: arch/arm/dts/.k3-am654-r5-base-board.dtb.pre.tmp:423.27-28 syntax error FATAL ERROR: Unable to parse input tree Jan [1] https://lore.kernel.org/lkml/1edbc1b56ed4ff2256d7afb7db3cab4b3a423692.1699087938.git.jan.kis...@siemens.com/ -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 00/26] sync am65x device tree with Linux v6.7-rc1
On 02.01.24 18:42, Tom Rini wrote: > On Tue, Jan 02, 2024 at 08:27:34AM +0100, Jan Kiszka wrote: >> On 27.12.23 13:39, Nishanth Menon wrote: >>> On 15:00-20231221, Tom Rini wrote: >>>> On Thu, Dec 21, 2023 at 11:43:46AM -0600, Bryan Brattlof wrote: >>>> >>>>> Hello Everyone! >>>>> >>>>> This series gets the am65x booting again along with syncing the device >>>>> tree files with v6.7-rc1 Linux. >>>>> >>>>> The bulk of these patches unify the WKUP SPL board file with the arm64 >>>>> files to make future syncs from Linux much easier. In the end the DTBs >>>>> should look a lot like what the DTBs look like for the am64x which >>>>> is fairly similar to the am65x. >>>>> >>>>> For those interested in what UART boot looks like: >>>>>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc >>>>> >>>>> Thanks for reviewing and happy holidays >>>>> ~Bryan >>>> >>>> For the series, >>>> Tested-by: Tom Rini >>>> >>>> Nishanth, does this path work for you? >>>> >>> >>> Other than the minor comments provided in the relevant patches, >>> >>> The following files also need sync up with v6.7-rc1. >>> >>> k3-am65-iot2050-common-pg2.dtsi >>> k3-am65-iot2050-common.dtsi >>> k3-am6528-iot2050-basic-common.dtsi >>> k3-am6548-iot2050-advanced-common.dtsi >>> k3-am6548-iot2050-advanced-m2.dts >>> >>> Jan - could you look at syncing those once an update to this series is >>> posted? We could probably have a smoother v6.8-rc1 from then on. >>> >> >> We currently plan to sync once support for the new SM variant is in the >> upstream DT. Do you see other changes that would benefit from an earlier >> sync? > > So this sync is because the ref platforms at least do not boot, is > iot2050 currently booting? It was booting with ~v2024.01-rc4 before Christmas, didn't try latest master yet. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 00/26] sync am65x device tree with Linux v6.7-rc1
On 27.12.23 13:39, Nishanth Menon wrote: > On 15:00-20231221, Tom Rini wrote: >> On Thu, Dec 21, 2023 at 11:43:46AM -0600, Bryan Brattlof wrote: >> >>> Hello Everyone! >>> >>> This series gets the am65x booting again along with syncing the device >>> tree files with v6.7-rc1 Linux. >>> >>> The bulk of these patches unify the WKUP SPL board file with the arm64 >>> files to make future syncs from Linux much easier. In the end the DTBs >>> should look a lot like what the DTBs look like for the am64x which >>> is fairly similar to the am65x. >>> >>> For those interested in what UART boot looks like: >>>https://paste.sr.ht/~bryanb/7df8a645dc548912cd806abd5ecab967ef3287bc >>> >>> Thanks for reviewing and happy holidays >>> ~Bryan >> >> For the series, >> Tested-by: Tom Rini >> >> Nishanth, does this path work for you? >> > > Other than the minor comments provided in the relevant patches, > > The following files also need sync up with v6.7-rc1. > > k3-am65-iot2050-common-pg2.dtsi > k3-am65-iot2050-common.dtsi > k3-am6528-iot2050-basic-common.dtsi > k3-am6548-iot2050-advanced-common.dtsi > k3-am6548-iot2050-advanced-m2.dts > > Jan - could you look at syncing those once an update to this series is > posted? We could probably have a smoother v6.8-rc1 from then on. > We currently plan to sync once support for the new SM variant is in the upstream DT. Do you see other changes that would benefit from an earlier sync? Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
On 31.10.23 08:14, Stefan Roese wrote:
> On 10/30/23 17:20, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since
>> day 1.
>>
>> Signed-off-by: Jan Kiszka
>
> Reviewed-by: Stefan Roese
>
> Thanks,
> Stefan
>
>> ---
>>
>> We are unfortunately seeing that message right now, rarely but then
>> prominently...
>>
>> drivers/spi/cadence_qspi_apb.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/cadence_qspi_apb.c
>> b/drivers/spi/cadence_qspi_apb.c
>> index 9ce2c0f254f..d033184aa46 100644
>> --- a/drivers/spi/cadence_qspi_apb.c
>> +++ b/drivers/spi/cadence_qspi_apb.c
>> @@ -171,8 +171,7 @@ static unsigned int cadence_qspi_wait_idle(void
>> *reg_base)
>> }
>> /* Timeout, still in busy mode. */
>> - printf("QSPI: QSPI is still busy after poll for %d times.\n",
>> - CQSPI_REG_RETRY);
>> + printf("QSPI: QSPI is still busy after poll for %d ms.\n", timeout);
>> return 0;
>> }
>>
>
> Viele Grüße,
> Stefan Roese
>
Ping.
Jan
--
Siemens AG, Technology
Linux Expert Center
[PATCH] spi: cadence-quadspi: Fix error message on stuck busy state
From: Jan Kiszka
We are not iterating CQSPI_REG_RETRY, we are waiting 'timeout' ms, since
day 1.
Signed-off-by: Jan Kiszka
---
We are unfortunately seeing that message right now, rarely but then
prominently...
drivers/spi/cadence_qspi_apb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 9ce2c0f254f..d033184aa46 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -171,8 +171,7 @@ static unsigned int cadence_qspi_wait_idle(void *reg_base)
}
/* Timeout, still in busy mode. */
- printf("QSPI: QSPI is still busy after poll for %d times.\n",
- CQSPI_REG_RETRY);
+ printf("QSPI: QSPI is still busy after poll for %d ms.\n", timeout);
return 0;
}
--
2.35.3
[PATCH v2] iot2050: Allow for more than 1 USB storage device
From: Jan Kiszka
This was lost in refactoring while some users of the IOT2050 expect it
to work: Make sure that up to 3 USB storage devices are probed.
Fixes: 53873974a4b0 ("include: armv7: Enable distroboot across all configs")
Signed-off-by: Jan Kiszka
Reviewed-by: Heinrich Schuchardt
---
Changes in v2:
- typo fix
include/configs/iot2050.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
index 4968722d18f..94a9c767882 100644
--- a/include/configs/iot2050.h
+++ b/include/configs/iot2050.h
@@ -15,6 +15,15 @@
#include
+/* allow up to 3 USB storage devices */
+#ifdef CONFIG_CMD_USB
+#undef BOOT_TARGET_USB
+#define BOOT_TARGET_USB(func) \
+ func(USB, usb, 0) \
+ func(USB, usb, 1) \
+ func(USB, usb, 2)
+#endif
+
/*
* This defines all MMC devices, even if the basic variant has no mmc1.
* The non-supported device will be removed from the boot targets during
--
2.35.3
[PATCH] iot2050: Allow for more than 1 USB storage device
From: Jan Kiszka This was lost via 53873974a4b0 while some users of the IOT2050 expect it to work: Make sure that up to 3 USB storage devices are probed. Signed-off-by: Jan Kiszka --- include/configs/iot2050.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h index 4968722d18f..1d444d02c83 100644 --- a/include/configs/iot2050.h +++ b/include/configs/iot2050.h @@ -15,6 +15,15 @@ #include +/* allow up to 3 USB storage devcies */ +#ifdef CONFIG_CMD_USB +#undef BOOT_TARGET_USB +#define BOOT_TARGET_USB(func) \ + func(USB, usb, 0) \ + func(USB, usb, 1) \ + func(USB, usb, 2) +#endif + /* * This defines all MMC devices, even if the basic variant has no mmc1. * The non-supported device will be removed from the boot targets during -- 2.35.3
[PATCH] board: siemens: iot2050: Fix M.2 detection
From: Jan Kiszka
The "simpler" the logic, the higher the probability to not test and get
things wrong, again: The absence of a "-PG2" suffix is not sufficient to
derive that we are on PG1. There is also "IOT2050-ADVANCED-M2".
Finally fix that by exactly matching against the two PG1 device names.
While changing this, we can also drop the not really needed check for
!board_is_sr1 in board_is_m2 and call the boards by their names
("board_is_pg1").
Reported-and-tested-by: Bao Cheng Su
Signed-off-by: Jan Kiszka
---
board/siemens/iot2050/board.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index e35e55fb5de..0b0686e2628 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -155,19 +155,20 @@ static bool board_is_advanced(void)
strstr((char *)info->name, "IOT2050-ADVANCED") != NULL;
}
-static bool board_is_sr1(void)
+static bool board_is_pg1(void)
{
struct iot2050_info *info = IOT2050_INFO_DATA;
return info->magic == IOT2050_INFO_MAGIC &&
- strstr((char *)info->name, "-PG2") == NULL;
+ (strcmp((char *)info->name, "IOT2050-BASIC") == 0 ||
+strcmp((char *)info->name, "IOT2050-ADVANCED") == 0);
}
static bool board_is_m2(void)
{
struct iot2050_info *info = IOT2050_INFO_DATA;
- return !board_is_sr1() && info->magic == IOT2050_INFO_MAGIC &&
+ return info->magic == IOT2050_INFO_MAGIC &&
strcmp((char *)info->name, "IOT2050-ADVANCED-M2") == 0;
}
@@ -217,14 +218,14 @@ void set_board_info_env(void)
}
if (board_is_advanced()) {
- if (board_is_sr1())
+ if (board_is_pg1())
fdtfile = "ti/k3-am6548-iot2050-advanced.dtb";
else if(board_is_m2())
fdtfile = "ti/k3-am6548-iot2050-advanced-m2.dtb";
else
fdtfile = "ti/k3-am6548-iot2050-advanced-pg2.dtb";
} else {
- if (board_is_sr1())
+ if (board_is_pg1())
fdtfile = "ti/k3-am6528-iot2050-basic.dtb";
else
fdtfile = "ti/k3-am6528-iot2050-basic-pg2.dtb";
--
2.35.3
[PATCH] board: siemens: iot2050: Fix logical bug in PG1/PG2 detection
From: Jan Kiszka
This caused the wrong fdtfile to be set and was failing to apply M.2
settings.
Fixes: badaa1f6a7a9 ("boards: siemens: iot2050: Unify PG1 and PG2/M.2
configurations again")
Signed-off-by: Jan Kiszka
---
board/siemens/iot2050/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index 15f5310c7bf..e35e55fb5de 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -160,7 +160,7 @@ static bool board_is_sr1(void)
struct iot2050_info *info = IOT2050_INFO_DATA;
return info->magic == IOT2050_INFO_MAGIC &&
- strstr((char *)info->name, "-PG2") != NULL;
+ strstr((char *)info->name, "-PG2") == NULL;
}
static bool board_is_m2(void)
--
2.35.3
[PATCH] arm: dts: k3-am65-iot2050: Fix boot
From: Jan Kiszka
Since commit [1] A53 u-boot proper is broken. This is because nodes
marked as 'bootph-pre-ram' are not available at u-boot proper before
relocation.
To fix this we mark all nodes in u-boot.dtsi as 'bootph-all'.
[1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
after relocation")
Signed-off-by: Jan Kiszka
---
.../dts/k3-am65-iot2050-common-u-boot.dtsi| 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
b/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
index 9fd64809a63..30fc7a78d89 100644
--- a/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-common-u-boot.dtsi
@@ -37,18 +37,18 @@
};
leds {
- bootph-pre-ram;
+ bootph-all;
status-led-red {
- bootph-pre-ram;
+ bootph-all;
};
status-led-green {
- bootph-pre-ram;
+ bootph-all;
};
};
};
_mcu {
- bootph-pre-ram;
+ bootph-all;
mcu_navss: bus@2838 {
ringacc@2b80 {
@@ -75,70 +75,70 @@
};
_wakeup {
- bootph-pre-ram;
+ bootph-all;
};
_main {
- bootph-pre-ram;
+ bootph-all;
main_navss: bus@3080 {
- bootph-pre-ram;
+ bootph-all;
};
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
mcu-fss0-ospi0-pins-default {
- bootph-pre-ram;
+ bootph-all;
};
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
main-uart1-pins-default {
- bootph-pre-ram;
+ bootph-all;
};
};
_uart1 {
- bootph-pre-ram;
+ bootph-all;
current-speed = <115200>;
};
_gpio0 {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
flash@0 {
- bootph-pre-ram;
+ bootph-all;
};
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
--
2.35.3
Re: [PATCH] arm: dts: k3-am625-beagleplay: Fix boot
On 04.10.23 14:15, Nishanth Menon wrote:
> On 22:26-20231003, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Since commit [1] A53 u-boot proper is broken. This is because nodes
>> marked as 'bootph-pre-ram' are not available at u-boot proper before
>> relocation.
>>
>> To fix this we mark all nodes as 'bootph-all'.
>>
>> [1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
>> after relocation")
>>
>> Signed-off-by: Jan Kiszka
>> ---
>>
>> This may overshoot, but at least the board boots again. Could it be that
>> [1] broke even more boards?
>
> Jan:
> https://lore.kernel.org/all/b1c62a7d-a90e-4212-8972-9b622e147...@kernel.org/
>
> I got boot without r5-beagleplay.dts modified. and it is in line with
> the changes in linux-next commit 944adefc7f88 ("arm64: dts: ti:
> k3-am625-beagleplay: Add boot phase tags marking")
>
Yeah, no problem, missed that.
Meanwhile, I can fix our IOT2050 because I was unfortunatenly right:
more havoc in sight. Did anyone tried to look at the fallouts
systematically already? Is it only affecting the TI family?
Jan
--
Siemens AG, Technology
Linux Expert Center
[PATCH] arm: dts: k3-am625-beagleplay: Fix boot
From: Jan Kiszka
Since commit [1] A53 u-boot proper is broken. This is because nodes
marked as 'bootph-pre-ram' are not available at u-boot proper before
relocation.
To fix this we mark all nodes as 'bootph-all'.
[1] 9e644284ab812 ("dm: core: Report bootph-pre-ram/sram node as pre-reloc
after relocation")
Signed-off-by: Jan Kiszka
---
This may overshoot, but at least the board boots again. Could it be that
[1] broke even more boards?
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 70 ++--
arch/arm/dts/k3-am625-r5-beagleplay.dts | 12 ++--
2 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index f8c04e8a300..d6c6baa5518 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -14,143 +14,143 @@
};
memory@8000 {
- bootph-pre-ram;
+ bootph-all;
};
/* Keep the LEDs on by default to indicate life */
leds {
- bootph-pre-ram;
+ bootph-all;
led-0 {
default-state = "on";
- bootph-pre-ram;
+ bootph-all;
};
led-1 {
default-state = "on";
- bootph-pre-ram;
+ bootph-all;
};
led-2 {
default-state = "on";
- bootph-pre-ram;
+ bootph-all;
};
led-3 {
default-state = "on";
- bootph-pre-ram;
+ bootph-all;
};
led-4 {
default-state = "on";
- bootph-pre-ram;
+ bootph-all;
};
};
};
_main {
- bootph-pre-ram;
+ bootph-all;
};
_timer0 {
clock-frequency = <2500>;
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_proxy_main {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_pds {
- bootph-pre-ram;
+ bootph-all;
};
_clks {
- bootph-pre-ram;
+ bootph-all;
};
_reset {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
k3_sysreset: sysreset-controller {
compatible = "ti,sci-sysreset";
- bootph-pre-ram;
+ bootph-all;
};
};
_conf {
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_uart0 {
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_mcu {
- bootph-pre-ram;
+ bootph-all;
};
_wakeup {
- bootph-pre-ram;
+ bootph-all;
};
_pmx0 {
- bootph-pre-ram;
+ bootph-all;
};
_i2c0 {
- bootph-pre-ram;
+ bootph-all;
};
_i2c_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_gpio0 {
- bootph-pre-ram;
+ bootph-all;
};
_gpio1 {
- bootph-pre-ram;
+ bootph-all;
};
{
/* EMMC */
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
};
_pins_default {
- bootph-pre-ram;
+ bootph-all;
/* Force to use SDCD card detect pin */
pinctrl-single,pins = <
AM62X_IOPAD(0x023c, PIN_INPUT, 0) /* (A21) MMC1_CMD */
@@ -164,11 +164,11 @@
};
{
- bootph-pre-ram;
+ bootph-all;
};
{
- bootph-pre-ram;
+ bootph-all;
};
#ifdef CONFIG_TARGET_AM625_A53_EVM
diff --git a/arch/arm/dts/k3-am625-r5-beagleplay.dts
b/arch/arm/dts/k3-am625-r5-beagleplay.dts
index 9c9d0570592..ac5461a32c0 100644
--- a/arch/arm/dts/k3-am625-r5-beagleplay.dts
+++ b/arch/arm/dts/k3-am625-r5-beagleplay.dts
@@ -31,7 +31,7 @@
ti,sci = <>;
ti,sci-proc-id = <32>;
ti,sci-host-id = <10>;
- bootph-pre-ram;
+ bootph-all;
};
dm_tifs: dm-tifs {
@@ -41,7 +41,7 @@
mbox-names = "rx", "tx";
mboxes= <_proxy_main 22>,
<_proxy_main 23>;
- bootph-pre-ram;
+ bootph-all;
};
};
@@ -55,11 +55,11 @@
};
_esm {
- bootph-pre-ram;
+ bootph-all;
};
_proxy_sa3 {
- bootph-pre-ram;
+ bootph-all;
/* We require this for boot handshake */
status =
[PATCH] configs: iot2050: Disable CONFIG_CONSOLE_MUX
From: Jan Kiszka We only have serial as console option, and leaving this on turns on SYS_CONSOLE_IS_IN_ENV which is also not true for these devices, leaving an ugly In:No input devices available! Out: No output devices available! Err: No error devices available! behind. Signed-off-by: Jan Kiszka --- Fix for 2023.10. configs/iot2050_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig index bc9ca16fac3..3f05f8c38d7 100644 --- a/configs/iot2050_defconfig +++ b/configs/iot2050_defconfig @@ -18,7 +18,6 @@ CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="k3-am6528-iot2050-basic" CONFIG_SPL_TEXT_BASE=0x8008 -CONFIG_SYS_PROMPT="IOT2050> " CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_SERIAL=y @@ -41,7 +40,6 @@ CONFIG_AUTOBOOT_FLUSH_STDIN=y CONFIG_AUTOBOOT_PROMPT="Hit SPACE to stop autoboot in %d seconds...\n" CONFIG_AUTOBOOT_STOP_STR=" " CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd" -CONFIG_CONSOLE_MUX=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_SPL_MAX_SIZE=0x58000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y @@ -62,6 +60,7 @@ CONFIG_SPL_POWER_DOMAIN=y CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x38 +CONFIG_SYS_PROMPT="IOT2050> " CONFIG_SYS_MAXARGS=64 CONFIG_SYS_PBSIZE=1050 CONFIG_CMD_ASKENV=y -- 2.35.3
[PATCH] tools: iot2050-sign-fw.sh: Make localization of tools dir more robust
From: Jan Kiszka
When building in-tree, there is no source link.
Signed-off-by: Jan Kiszka
---
tools/iot2050-sign-fw.sh | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh
index 6b426c854c2..75ffd560823 100755
--- a/tools/iot2050-sign-fw.sh
+++ b/tools/iot2050-sign-fw.sh
@@ -5,6 +5,8 @@ if [ -z "$1" ]; then
exit 1
fi
+TOOLS_DIR=$(dirname $0)
+
TEMP_X509=$(mktemp .temp)
REVISION=${2:-0}
@@ -39,10 +41,10 @@ CERT_X509=$(mktemp .crt)
openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config
$TEMP_X509 -sha512
cat $CERT_X509 tispl.bin > tispl.bin_signed
-source/tools/binman/binman replace -i flash-pg1.bin -f tispl.bin_signed
fit@18
-source/tools/binman/binman replace -i flash-pg2.bin -f tispl.bin_signed
fit@18
+$TOOLS_DIR/binman/binman replace -i flash-pg1.bin -f tispl.bin_signed
fit@18
+$TOOLS_DIR/binman/binman replace -i flash-pg2.bin -f tispl.bin_signed
fit@18
rm $TEMP_X509 $CERT_X509
-source/tools/binman/binman sign -i flash-pg1.bin -k $1 -a sha256,rsa4096
fit@38
-source/tools/binman/binman sign -i flash-pg2.bin -k $1 -a sha256,rsa4096
fit@38
+$TOOLS_DIR/binman/binman sign -i flash-pg1.bin -k $1 -a sha256,rsa4096
fit@38
+$TOOLS_DIR/binman/binman sign -i flash-pg2.bin -k $1 -a sha256,rsa4096
fit@38
--
2.35.3
Re: [PATCH 2/5] iot2050: rename overlay sources to .dtso
On 25.09.23 10:09, Rasmus Villemoes wrote:
> Distinguish more clearly between source files meant for producing .dtb
> from those meant for producing .dtbo. No functional change, as we
> currently have rules for producing a foo.dtbo from either foo.dts or
> foo.dtso.
>
> Note that in the linux tree, all device tree overlay sources have been
> renamed to .dtso, and the .dts->.dtbo rule is gone since v6.5 (commit
> 81d362732bac). So this is also a step towards staying closer to linux
> with respect to both Kbuild and device tree sources.
>
> Signed-off-by: Rasmus Villemoes
> ---
> ... => k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso} | 0
> ...y.dts => k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso} | 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename
> arch/arm/dts/{k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts =>
> k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso} (100%)
> rename arch/arm/dts/{k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts =>
> k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso} (100%)
>
> diff --git
> a/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts
> b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso
> similarity index 100%
> rename from
> arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts
> rename to
> arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtso
> diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts
> b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso
> similarity index 100%
> rename from arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts
> rename to arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtso
Reviewed-by: Jan Kiszka
Jan
--
Siemens AG, Technology
Linux Expert Center
[PATCH] board: ti: am62x: beagleplay: Disable semi-functional PSCI reset support
From: Jan Kiszka At this point, system shutdown is not supported by the DM firmware that TF-A calls. As we can't de-select only this feature, declare complete PSCI reset support as non-functional so that we don't signal incomplete support to the OS via EFI runtime services. This makes power-off under Linux work again when booting via EFI. Signed-off-by: Jan Kiszka --- board/ti/am62x/beagleplay_a53.config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/ti/am62x/beagleplay_a53.config b/board/ti/am62x/beagleplay_a53.config index 967f794446d..8b0f671bc9e 100644 --- a/board/ti/am62x/beagleplay_a53.config +++ b/board/ti/am62x/beagleplay_a53.config @@ -53,3 +53,5 @@ CONFIG_SPI=n CONFIG_SPI_FLASH=n CONFIG_SPL_DM_SPI_FLASH=n CONFIG_SPL_SPI_FLASH_SUPPORT=n +# DM firmware lacks support for shutdown +# CONFIG_PSCI_RESET is not set -- 2.35.3
Re: [PATCH 2/2] configs: Make TI_SECURE_DEVICE default for K3
On 03.08.23 16:54, Andrew Davis wrote: > All K3 boards now are secure by default, instead of setting this in each > defconfig, make it implied by the ARCH config. > > The only exception is IOT2050, which I do not believe will have any > problems with being a TI_SECURE_DEVICE, but for now turn it off to keep > its config the same. The IOT2050 firmware is not using TI_SECURE_DEVICE because it serves non-HS devices by default as well. Secure boot on HS devices can be enabled by applying an extra config fragment like [1]. So it's indeed better to keep this off for the IO2050 to avoid untested side effects. E.g., we would probably lose legacy image booting in non-secure mode. Jan [1] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg > > Signed-off-by: Andrew Davis > --- > arch/arm/Kconfig | 1 + > configs/am62ax_evm_a53_defconfig | 1 - > configs/am62ax_evm_r5_defconfig | 1 - > configs/am62x_evm_a53_defconfig | 1 - > configs/am62x_evm_r5_defconfig | 1 - > configs/am64x_evm_a53_defconfig | 1 - > configs/am64x_evm_r5_defconfig | 1 - > configs/iot2050_defconfig| 1 + > configs/j7200_evm_a72_defconfig | 1 - > configs/j7200_evm_r5_defconfig | 1 - > configs/j721e_evm_a72_defconfig | 1 - > configs/j721e_evm_r5_defconfig | 1 - > configs/j721s2_evm_a72_defconfig | 1 - > configs/j721s2_evm_r5_defconfig | 1 - > 14 files changed, 2 insertions(+), 12 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 97c25b4f146..8ad6c5582ce 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -787,6 +787,7 @@ config ARCH_K3 > select FIT > select REGEX > select FIT_SIGNATURE if ARM64 > + imply TI_SECURE_DEVICE > > config ARCH_OMAP2PLUS > bool "TI OMAP2+" > diff --git a/configs/am62ax_evm_a53_defconfig > b/configs/am62ax_evm_a53_defconfig > index 773cf3a591c..d0a34c75505 100644 > --- a/configs/am62ax_evm_a53_defconfig > +++ b/configs/am62ax_evm_a53_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62ax_evm_r5_defconfig b/configs/am62ax_evm_r5_defconfig > index 05c30cbba19..2c1110d227f 100644 > --- a/configs/am62ax_evm_r5_defconfig > +++ b/configs/am62ax_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x9000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index d55caabe22c..1d05cecbcde 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig > index 3c5f3672984..9dd2930dc89 100644 > --- a/configs/am62x_evm_r5_defconfig > +++ b/configs/am62x_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x0800 > CONFIG_SYS_MALLOC_F_LEN=0x9000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig > index 9bdb767f9e6..d1d46c61075 100644 > --- a/configs/am64x_evm_a53_defconfig > +++ b/configs/am64x_evm_a53_defconfig > @@ -1,7 +1,6 @@ > CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig > index 45d32658cff..96cb437b10b 100644 > --- a/configs/am64x_evm_r5_defconfig > +++ b/configs/am64x_evm_r5_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8 > CONFIG_SPL_GPIO=y > diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig > index bcbaa92ee89..ad9217ff86a 100644 > --- a/configs/iot2050_defconfig > +++ b/configs/iot2050_defconfig > @@ -1,6 +1,7 @@ > CONFIG_ARM=y > CONFIG_SKIP_LOWLEVEL_INIT=y > CONFIG_ARCH_K3=y > +# CONFIG_TI_SECURE_DEVICE is not set > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig > index c68d52537e5..a9f5d36ffe3 100644 > --- a/configs/j7200_evm_a72_defconfig > +++ b/configs/j7200_evm_a72_defconfig > @@ -1,6 +1,5 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > -CONFIG_TI_SECURE_DEVICE=y > CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_GPIO=y > diff --git a/configs/j7200_evm_r5_defconfig b/configs/j7200_evm_r5_defconfig > index
[PATCH 5/5] configs: iot2050: Enabled keyed autoboot
From: Jan Kiszka Only accept SPACE to stop autobooting. This is safer to avoid accidental interruptions on unattended devices. Signed-off-by: Jan Kiszka --- configs/iot2050_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig index b5a50d4fa4a..bcbaa92ee89 100644 --- a/configs/iot2050_defconfig +++ b/configs/iot2050_defconfig @@ -36,6 +36,10 @@ CONFIG_DISTRO_DEFAULTS=y CONFIG_BOOTSTAGE=y CONFIG_SHOW_BOOT_PROGRESS=y CONFIG_SPL_SHOW_BOOT_PROGRESS=y +CONFIG_AUTOBOOT_KEYED=y +CONFIG_AUTOBOOT_FLUSH_STDIN=y +CONFIG_AUTOBOOT_PROMPT="Hit SPACE to stop autoboot in %d seconds...\n" +CONFIG_AUTOBOOT_STOP_STR=" " CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd" CONFIG_CONSOLE_MUX=y # CONFIG_DISPLAY_CPUINFO is not set -- 2.35.3
[PATCH 3/5] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
From: Jan Kiszka
This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of a template dtsi, we
can avoid duplicating the common binman image definitions.
Suggested-by: Andrew Davis
Signed-off-by: Jan Kiszka
---
CC: Andrew Davis
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 155 +++---
board/siemens/iot2050/Kconfig | 30 +---
board/siemens/iot2050/MAINTAINERS | 3 +-
board/siemens/iot2050/board.c | 25 ++-
...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +-
configs/iot2050_pg2_defconfig | 151 -
doc/board/siemens/iot2050.rst | 27 ++-
tools/iot2050-sign-fw.sh | 6 +-
8 files changed, 138 insertions(+), 262 deletions(-)
rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%)
delete mode 100644 configs/iot2050_pg2_defconfig
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 7bfa4eebb90..3ecb461b011 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) Siemens AG, 2020-2022
+ * Copyright (c) Siemens AG, 2020-2023
*
* Authors:
* Jan Kiszka
@@ -10,23 +10,23 @@
#include
/ {
- binman {
- filename = "flash.bin";
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ common_part: template {
pad-byte = <0xff>;
size = <0x8c>;
allow-repack;
- blob-ext@0x00 {
+ blob-ext@0 {
offset = <0x00>;
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
- filename = "seboot_pg1.bin";
-#else
- filename = "seboot_pg2.bin";
-#endif
missing-msg = "iot2050-seboot";
};
- fit@0x18 {
+ fit@18 {
offset = <0x18>;
filename = "tispl.bin";
pad-byte = <0xff>;
@@ -104,9 +104,8 @@
};
};
- fit@0x38 {
+ fit@38 {
description = "U-Boot for IOT2050";
- fit,fdt-list = "of-list";
offset = <0x38>;
images {
u-boot {
@@ -134,36 +133,6 @@
};
};
-#ifdef CONFIG_TARGET_IOT2050_A53_PG2
- bkey-usb3-overlay {
- description = "M.2-bkey-usb3-overlay";
- type = "blob";
- load = <0x8210>;
- arch = "arm64";
- compression = "none";
- blob-ext {
- filename =
"k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo";
- };
- hash {
- algo = "sha256";
- };
- };
-
- bkey-ekey-pcie-overlay {
- description =
"M.2-bkey-ekey-pcie-overlay";
- type = "blob";
- load = <0x8211>;
- arch = "arm64";
- compression = "none";
- blob-ext {
- filename =
"k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo";
- };
- hash {
- algo = "sha256";
- };
- };
-#endif
-
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
k3-rti-wdt-firmware {
type = "firmware";
@@ -182,20 +151,10 @@
};
configurations {
- default = "@config-DEFAULT-SEQ";
@config-SEQ {
[PATCH 0/5] iot2050: 2023.10-rc1 fixes and cleanups
[resent, now that the list is working again]
Most of this comes late, but primarily as the required binman templating
changes were awaited, and the lots of regressions hit this board. I
really hope we can not only merge the minimally required patch 1 of this
series.
Jan
CC: Andrew Davis
CC: Manorit Chawdhry
CC: Simon Glass
Jan Kiszka (5):
boards: siemens: iot2050: Fix boot configuration
iot2050: Use binman in signing script
boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
doc: board: siemens: iot2050: Update build env vars
configs: iot2050: Enabled keyed autoboot
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 155 +++---
board/siemens/iot2050/Kconfig | 30 +---
board/siemens/iot2050/MAINTAINERS | 3 +-
board/siemens/iot2050/board.c | 25 ++-
board/siemens/iot2050/iot2050.env | 2 +
...ot2050_pg1_defconfig => iot2050_defconfig} | 8 +-
configs/iot2050_pg2_defconfig | 150 -
doc/board/siemens/iot2050.rst | 31 ++--
include/configs/iot2050.h | 11 ++
tools/iot2050-sign-fw.sh | 11 +-
10 files changed, 158 insertions(+), 268 deletions(-)
rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (94%)
delete mode 100644 configs/iot2050_pg2_defconfig
--
2.35.3
[PATCH 4/5] doc: board: siemens: iot2050: Update build env vars
From: Jan Kiszka ATF is now called BL31, and OP-TEE since 3.21 suggests to use tee-raw.bin instead of (the still identical) tee-pager_v2.bin. Signed-off-by: Jan Kiszka --- doc/board/siemens/iot2050.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst index 0df11a950a7..ee3c5c95846 100644 --- a/doc/board/siemens/iot2050.rst +++ b/doc/board/siemens/iot2050.rst @@ -66,8 +66,8 @@ U-Boot: .. code-block:: text - $ export ATF=/path/to/bl31.bin - $ export TEE=/path/to/tee-pager_v2.bin + $ export BL31=/path/to/bl31.bin + $ export TEE=/path/to/tee-raw.bin $ make iot2050_defconfig $ make -- 2.35.3
[PATCH 2/5] iot2050: Use binman in signing script
From: Jan Kiszka The underlying issue was fixed in the meantime. Also signing the U-Boot proper fit image now works. Just supporting custom cert templates remains a todo. Signed-off-by: Jan Kiszka --- CC: Simon Glass --- tools/iot2050-sign-fw.sh | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh index 4d1d79498c2..3f953c09ed9 100755 --- a/tools/iot2050-sign-fw.sh +++ b/tools/iot2050-sign-fw.sh @@ -39,13 +39,8 @@ CERT_X509=$(mktemp .crt) openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512 cat $CERT_X509 tispl.bin > tispl.bin_signed -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 -dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x18/0x1000)) conv=notrunc +source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed fit@0x18 rm $TEMP_X509 $CERT_X509 -tools/mkimage -G $1 -r -o sha256,rsa4096 -F f...@0x38.fit -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 -dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) seek=$((0x38/0x1000)) conv=notrunc +source/tools/binman/binman sign -i flash.bin -k $1 -a sha256,rsa4096 fit@0x38 -- 2.35.3
[PATCH 1/5] boards: siemens: iot2050: Fix boot configuration
From: Jan Kiszka
The common env bits now come via ti_armv7_common.env, include it.
Futhermore restore the board-specific boot targets and their ordering
that is now enforced k3-wide differently. Finally, enable
CONFIG_LEGACY_IMAGE_FORMAT explicitly which got lost while turning
FIT_SIGNATURE on by default for k3 devices.
Fixes: 53873974 ("include: armv7: Enable distroboot across all configs")
Fixes: 4ae1a247 ("env: Make common bootcmd across all k3 devices")
Fixes: 86fab110 ("Kconfig: Enable FIT_SIGNATURE if ARM64")
Signed-off-by: Jan Kiszka
---
CC: Manorit Chawdhry
---
board/siemens/iot2050/iot2050.env | 2 ++
configs/iot2050_pg1_defconfig | 1 +
configs/iot2050_pg2_defconfig | 1 +
include/configs/iot2050.h | 11 +++
4 files changed, 15 insertions(+)
diff --git a/board/siemens/iot2050/iot2050.env
b/board/siemens/iot2050/iot2050.env
index 02958798b49..7fd836e6285 100644
--- a/board/siemens/iot2050/iot2050.env
+++ b/board/siemens/iot2050/iot2050.env
@@ -6,6 +6,8 @@
* Jan Kiszka
*/
+#include
+
usb_pgood_delay=900
watchdog_timeout_ms=CONFIG_WATCHDOG_TIMEOUT_MSECS
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index cc1b9673d79..391ab78d366 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -29,6 +29,7 @@ CONFIG_SPL_SPI=y
CONFIG_PCI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index c5741a4dae4..19c440732aa 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -29,6 +29,7 @@ CONFIG_SPL_SPI=y
CONFIG_PCI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
index 2177e0dfe38..4968722d18f 100644
--- a/include/configs/iot2050.h
+++ b/include/configs/iot2050.h
@@ -15,6 +15,17 @@
#include
+/*
+ * This defines all MMC devices, even if the basic variant has no mmc1.
+ * The non-supported device will be removed from the boot targets during
+ * runtime, when that board was detected.
+ */
+#undef BOOT_TARGET_DEVICES
+#define BOOT_TARGET_DEVICES(func) \
+ func(MMC, mmc, 1) \
+ func(MMC, mmc, 0) \
+ BOOT_TARGET_USB(func)
+
#ifdef CONFIG_ENV_WRITEABLE_LIST
#define CFG_ENV_FLAGS_LIST_STATIC \
"board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw," \
--
2.35.3
Re: [PATCH 00/18] K3 HS Support along with fixes
On 26.07.23 09:25, Manorit Chawdhry wrote: > On 12:17-20230726, Manorit Chawdhry wrote: >> Hi Jan, >> >> On 08:42-20230726, Jan Kiszka wrote: >>> On 14.07.23 07:52, Manorit Chawdhry wrote: >>>> The series focuses on fixes for various boards along with moving to >>>> standards and enabling the FIT_SIGNATURE for K3 Platforms towards the >>>> end. >>>> >>>> Dependencies: >>>> https://lore.kernel.org/u-boot/20230712183453.7623-1-n-fran...@ti.com/ >>>> >>>> Signed-off-by: Manorit Chawdhry >>>> --- >>>> Andrew Davis (4): >>>> environment: ti: Prefix ARM64 DTB names with directory >>>> environment: ti: Make get_fdt_mmc common >>>> configs: Enable setexpr command on TI devices >>>> arm: k3: Add regex/gsub command handling >>>> >>>> Kamlesh Gurudasani (3): >>>> board: ti: am64x: am64x.env: set fdtfile env variable >>>> configs: k3: make consistent bootcmd across all k3 socs >>>> configs: am64: Fix booting of fitImage on AM64x >>>> >>>> Manorit Chawdhry (11): >>>> arch: mach-k3: security: fix the check for authentication >>>> Kconfig: j721s2: Fix the scratchpad base >>>> mach-k3: common: correct the calculations for determining firewalls >>>> include: j7*_evm.h: Cleanups to be done >>>> configs: k3: Remove saved environments >>>> env: Make common bootcmd across all k3 devices >>>> include: armv7: Enable distroboot across all configs >>>> board: ti: keys: add .key and .crt for fit signature signing >>>> k3-*-binman: dts: Pack u-boot.dtb instead of soc specific dtb >>>> lib: Kconfig: k3: Enable SHA512 for fit signature >>>> Kconfig: Enable FIT_SIGNATURE if ARM64 >>>> >>>> arch/arm/Kconfig | 2 + >>>> arch/arm/dts/k3-am625-sk-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-am62a-sk-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-am64x-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-am65x-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-j7200-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-j721e-binman.dtsi | 2 +- >>>> arch/arm/dts/k3-j721s2-binman.dtsi | 2 +- >>>> arch/arm/mach-k3/Kconfig | 2 +- >>>> arch/arm/mach-k3/common.c | 3 +- >>>> arch/arm/mach-k3/common.h | 2 +- >>>> arch/arm/mach-k3/security.c| 5 +- >>>> board/ti/am62ax/am62ax.env | 3 +- >>>> board/ti/am62x/am62x.env | 3 +- >>>> board/ti/am64x/am64x.env | 6 +- >>>> board/ti/am65x/am65x.env | 3 +- >>>> board/ti/j721e/j721e.env | 9 +- >>>> board/ti/j721s2/j721s2.env | 7 +- >>>> board/ti/keys/custMpk.crt | 33 ++ >>>> board/ti/keys/custMpk.key | 51 + >>>> boot/Kconfig | 3 +- >>>> configs/am335x_hs_evm_defconfig| 1 - >>>> configs/am43xx_hs_evm_defconfig| 1 - >>>> configs/am43xx_hs_evm_qspi_defconfig | 1 - >>>> configs/am57xx_hs_evm_defconfig| 1 - >>>> configs/am57xx_hs_evm_usb_defconfig| 1 - >>>> configs/am62ax_evm_a53_defconfig | 1 + >>>> configs/am62x_evm_a53_defconfig| 3 +- >>>> configs/am64x_evm_a53_defconfig| 7 +- >>>> configs/am65x_evm_a53_defconfig| 1 - >>>> configs/am65x_hs_evm_a53_defconfig | 1 - >>>> configs/j7200_evm_a72_defconfig| 7 +- >>>> configs/j721e_evm_a72_defconfig| 7 +- >>>> configs/j721s2_evm_a72_defconfig | 6 +- >>>> doc/board/ti/k3.rst| 172 >>>> + >>>> include/configs/am62ax_evm.h | 71 >>>> include/configs/am62x_evm.h| 27 - >>>> include/configs/j721e_evm.h| 32 -- >>>> include/configs/j721s2_evm.h | 5 - >>>> include/configs/ti_armv7_common.h | 50 + >&
Re: [PATCH 00/18] K3 HS Support along with fixes
On 14.07.23 07:52, Manorit Chawdhry wrote: > The series focuses on fixes for various boards along with moving to > standards and enabling the FIT_SIGNATURE for K3 Platforms towards the > end. > > Dependencies: > https://lore.kernel.org/u-boot/20230712183453.7623-1-n-fran...@ti.com/ > > Signed-off-by: Manorit Chawdhry > --- > Andrew Davis (4): > environment: ti: Prefix ARM64 DTB names with directory > environment: ti: Make get_fdt_mmc common > configs: Enable setexpr command on TI devices > arm: k3: Add regex/gsub command handling > > Kamlesh Gurudasani (3): > board: ti: am64x: am64x.env: set fdtfile env variable > configs: k3: make consistent bootcmd across all k3 socs > configs: am64: Fix booting of fitImage on AM64x > > Manorit Chawdhry (11): > arch: mach-k3: security: fix the check for authentication > Kconfig: j721s2: Fix the scratchpad base > mach-k3: common: correct the calculations for determining firewalls > include: j7*_evm.h: Cleanups to be done > configs: k3: Remove saved environments > env: Make common bootcmd across all k3 devices > include: armv7: Enable distroboot across all configs > board: ti: keys: add .key and .crt for fit signature signing > k3-*-binman: dts: Pack u-boot.dtb instead of soc specific dtb > lib: Kconfig: k3: Enable SHA512 for fit signature > Kconfig: Enable FIT_SIGNATURE if ARM64 > > arch/arm/Kconfig | 2 + > arch/arm/dts/k3-am625-sk-binman.dtsi | 2 +- > arch/arm/dts/k3-am62a-sk-binman.dtsi | 2 +- > arch/arm/dts/k3-am64x-binman.dtsi | 2 +- > arch/arm/dts/k3-am65x-binman.dtsi | 2 +- > arch/arm/dts/k3-j7200-binman.dtsi | 2 +- > arch/arm/dts/k3-j721e-binman.dtsi | 2 +- > arch/arm/dts/k3-j721s2-binman.dtsi | 2 +- > arch/arm/mach-k3/Kconfig | 2 +- > arch/arm/mach-k3/common.c | 3 +- > arch/arm/mach-k3/common.h | 2 +- > arch/arm/mach-k3/security.c| 5 +- > board/ti/am62ax/am62ax.env | 3 +- > board/ti/am62x/am62x.env | 3 +- > board/ti/am64x/am64x.env | 6 +- > board/ti/am65x/am65x.env | 3 +- > board/ti/j721e/j721e.env | 9 +- > board/ti/j721s2/j721s2.env | 7 +- > board/ti/keys/custMpk.crt | 33 ++ > board/ti/keys/custMpk.key | 51 + > boot/Kconfig | 3 +- > configs/am335x_hs_evm_defconfig| 1 - > configs/am43xx_hs_evm_defconfig| 1 - > configs/am43xx_hs_evm_qspi_defconfig | 1 - > configs/am57xx_hs_evm_defconfig| 1 - > configs/am57xx_hs_evm_usb_defconfig| 1 - > configs/am62ax_evm_a53_defconfig | 1 + > configs/am62x_evm_a53_defconfig| 3 +- > configs/am64x_evm_a53_defconfig| 7 +- > configs/am65x_evm_a53_defconfig| 1 - > configs/am65x_hs_evm_a53_defconfig | 1 - > configs/j7200_evm_a72_defconfig| 7 +- > configs/j721e_evm_a72_defconfig| 7 +- > configs/j721s2_evm_a72_defconfig | 6 +- > doc/board/ti/k3.rst| 172 > + > include/configs/am62ax_evm.h | 71 > include/configs/am62x_evm.h| 27 - > include/configs/j721e_evm.h| 32 -- > include/configs/j721s2_evm.h | 5 - > include/configs/ti_armv7_common.h | 50 + > include/environment/ti/mmc.env | 5 +- > include/environment/ti/ti_armv7_common.env | 11 +- > lib/Kconfig| 1 + > 43 files changed, 356 insertions(+), 202 deletions(-) > --- > base-commit: 26bd02c45a97f77cfb6afac4ee4f61fb9c5c7007 > change-id: 20230713-b4-upstream-fit-image-support-9d3c113ebab7 > > Best regards, This series (at least) completely broke IOT2050 booting, specifically by dictating EVM-specific settings on our non-EVM board. Still trying to understand all problems and how to resolve them, either on board level or via making the side-effects optional. Due to that, our own patches missed rc1 :(. Jan -- Siemens AG, Technology Linux Expert Center
Re: [PATCH 2/5] MAINTAINERS: Add some missing defconfig files to existing entries
On 18.07.23 18:20, Tom Rini wrote: > We have a few places where defconfigs were added (or renamed) and not > included in their previously listed MAINTAINERS entry, correct this. > > Signed-off-by: Tom Rini > --- > Cc: Adam Ford > Cc: Chris Packham > Cc: Jan Kiszka > Cc: Neil Armstrong > Cc: Stefan Roese > --- > board/Marvell/db-88f6820-amc/MAINTAINERS | 1 + > board/amlogic/w400/MAINTAINERS | 1 + > board/beacon/imx8mm/MAINTAINERS | 1 + > board/beacon/imx8mn/MAINTAINERS | 1 + > board/siemens/iot2050/MAINTAINERS| 3 ++- > board/solidrun/clearfog/MAINTAINERS | 2 ++ > 6 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/board/Marvell/db-88f6820-amc/MAINTAINERS > b/board/Marvell/db-88f6820-amc/MAINTAINERS > index abf5b7efdc93..d519eb47b84c 100644 > --- a/board/Marvell/db-88f6820-amc/MAINTAINERS > +++ b/board/Marvell/db-88f6820-amc/MAINTAINERS > @@ -4,3 +4,4 @@ S:Maintained > F: board/Marvell/db-88f6820-amc/ > F: include/configs/db-88f6820-amc.h > F: configs/db-88f6820-amc_defconfig > +F: configs/db-88f6820-amc_nand_defconfig > diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS > index 117f79ea047b..19b1f30e6213 100644 > --- a/board/amlogic/w400/MAINTAINERS > +++ b/board/amlogic/w400/MAINTAINERS > @@ -5,6 +5,7 @@ L:u-boot-amlo...@groups.io > F: board/amlogic/w400/ > F: configs/bananapi-cm4-cm4io_defconfig > F: configs/bananapi-m2s_defconfig > +F: configs/odroid-n2l_defconfig > F: configs/radxa-zero2_defconfig > F: doc/board/amlogic/w400.rst > F: doc/board/amlogic/bananapi-cm4io.rst > diff --git a/board/beacon/imx8mm/MAINTAINERS b/board/beacon/imx8mm/MAINTAINERS > index d48ba8605bba..d8a5d0973694 100644 > --- a/board/beacon/imx8mm/MAINTAINERS > +++ b/board/beacon/imx8mm/MAINTAINERS > @@ -5,4 +5,5 @@ S:Maintained > F: board/beacon/imx8mm/ > F: include/configs/imx8mm_beacon.h > F: configs/imx8mm_beacon_defconfig > +F: configs/imx8mm_beacon_fspi_defconfig > F: doc/board/beacon/ > diff --git a/board/beacon/imx8mn/MAINTAINERS b/board/beacon/imx8mn/MAINTAINERS > index 4805cb255cc0..6dcef21a65e9 100644 > --- a/board/beacon/imx8mn/MAINTAINERS > +++ b/board/beacon/imx8mn/MAINTAINERS > @@ -5,3 +5,4 @@ F:board/beacon/imx8mn/ > F: include/configs/imx8mn_beacon.h > F: configs/imx8mn_beacon_defconfig > F: configs/imx8mn_beacon_2g_defconfig > +F: configs/imx8mn_beacon_fspi_defconfig > diff --git a/board/siemens/iot2050/MAINTAINERS > b/board/siemens/iot2050/MAINTAINERS > index 1b525356c2d6..aa21de2099f7 100644 > --- a/board/siemens/iot2050/MAINTAINERS > +++ b/board/siemens/iot2050/MAINTAINERS > @@ -4,6 +4,7 @@ M:Jan Kiszka > S: Maintained > F: board/siemens/iot2050/ > F: include/configs/iot2050.h > -F: configs/iot2050_defconfig > +F: configs/iot2050_pg1_defconfig > +F: configs/iot2050_pg2_defconfig Hehe, I'm sitting on patches to revert that again, but I don't object to fix this first to the current reality. Jan > F: arch/arm/dts/iot2050-* > F: doc/board/siemens/iot2050.rst > diff --git a/board/solidrun/clearfog/MAINTAINERS > b/board/solidrun/clearfog/MAINTAINERS > index 6646d96206bf..55bd1278049a 100644 > --- a/board/solidrun/clearfog/MAINTAINERS > +++ b/board/solidrun/clearfog/MAINTAINERS > @@ -5,3 +5,5 @@ F:board/soldrun/clearfog/ > F: include/configs/clearfog.h > F: configs/clearfog_defconfig > F: configs/clearfog_gt_8k_defconfig > +F: configs/clearfog_sata_defconfig > +F: configs/clearfog_spi_defconfig -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v6 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 12.07.23 20: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
> Reviewed-by: Simon Glass
> ---
> 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 {
You forgot to update tools/iot2050-sign-fw.sh?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v4 00/20] binman: Simple templating feature and mkimage conversion
On 11.07.23 16:59, Simon Glass wrote: > This series converts the mkimage entry type to be a section, i.e. based on > the entry_Section class. This makes it more consistent in its behaviour, > e.g. allowing symbol writing and expanded entries. > > A simple templating feature is also introduced, to reduce duplication > when a set of entries must be used in multiple images. > > In this version the nodes from the template are placed before any other > nodes, meaning that the template sets the node order. This seems more > consistent than other mechanisms. > > This series is available at u-boot-dm/mkim-working > > Changes in v4: > - Avoid copying phandle nodes > - Support copying over properties from each template node > - Make sure phandles are not copied > - Copy over properties from the top-level template node > - Add new patch to reduce state.SetInt and bintool cmd to debug level > > Changes in v3: > - Add new patch for elf to return number of written symbols > - Add new patch with more detail on how ObtainContents() works > - Fix up some tests which now need SPL and TPL > - Avoid calling ObtainContents() when not needed > - Fix 'specific' typo > - Add a new devicetree file especially for node copying > - Correct logic for merging nodes in order > - Tidy up some comments > - Adjust to use the new example file > - Drop duplicate dts-v1 header > - Add new test case for templating in a FIT > - Add new patch to support writing symbols inside a mkimage image > > Changes in v2: > - Drop now-unnecessary methods in mkimage etype > - Correct ordering of template nodes > - Fix 'preseverd' and 'inserter' typos > > Marek Vasut (1): > binman: Convert mkimage to Entry_section > > Simon Glass (19): > binman: Correct coverage gap in control > binman: Init align_default in entry_Section > binman: Use GetEntries() to obtain section contents > binman: Read _multiple_data_files in the correct place > binman: Allow disabling symbol writing > stm32mp15: Avoid writing symbols in SPL > binman: Update elf to return number of written symbols > binman: Add more detail on how ObtainContents() works > binman: Provide a way to specify the fdt-list directly > binman: Drop __bss_size variable in bss_data.c > binman: Correct handling of zero bss size > dtoc: Support copying the contents of a node into another > dtoc: Allow inserting a list of nodes into another > binman: Support simple templates > binman: Support templating with multiple images > binman: Add a test for templating in a FIT > binman: Support templates at any level > binman: Support writing symbols inside a mkimage image > binman: Reduce state.SetInt and bintool cmd to debug level > > arch/arm/dts/stm32mp15-u-boot.dtsi | 1 + > tools/binman/binman.rst| 94 + > tools/binman/bintool.py| 2 +- > tools/binman/control.py| 34 +++- > tools/binman/elf.py| 13 +- > tools/binman/elf_test.py | 13 +- > tools/binman/entries.rst | 6 + > tools/binman/entry.py | 11 +- > tools/binman/etype/blob_phase.py | 5 + > tools/binman/etype/fit.py | 9 + > tools/binman/etype/mkimage.py | 110 --- > tools/binman/etype/section.py | 54 +++-- > tools/binman/etype/u_boot_spl_bss_pad.py | 2 +- > tools/binman/etype/u_boot_tpl_bss_pad.py | 2 +- > tools/binman/etype/u_boot_vpl_bss_pad.py | 2 +- > tools/binman/ftest.py | 218 - > tools/binman/state.py | 4 +- > tools/binman/test/282_symbols_disable.dts | 25 +++ > tools/binman/test/283_mkimage_special.dts | 24 +++ > tools/binman/test/284_fit_fdt_list.dts | 58 ++ > tools/binman/test/285_spl_expand.dts | 13 ++ > tools/binman/test/286_template.dts | 42 > tools/binman/test/287_template_multi.dts | 27 +++ > tools/binman/test/288_template_fit.dts | 37 > tools/binman/test/289_template_section.dts | 52 + > tools/binman/test/290_mkimage_sym.dts | 27 +++ > tools/binman/test/Makefile | 5 +- > tools/binman/test/bss_data.c | 3 +- > tools/binman/test/bss_data_zero.c | 16 ++ > tools/binman/test/bss_data_zero.lds| 15 ++ > tools/binman/test/embed_data.lds | 1 + > tools/dtoc/fdt.py | 141 - > tools/dtoc/test/dtoc_test_copy.dts | 88 + > tools/dtoc/test_fdt.py | 113 +++ > 34 files changed, 1196 insertions(+), 71 deletions(-) > create mode 100644 tools/binman/test/282_symbols_disable.dts > create mode 100644 tools/binman/test/283_mkimage_special.dts > create mode 100644 tools/binman/test/284_fit_fdt_list.dts > create mode 100644 tools/binman/test/285_spl_expand.dts > create mode 100644
Re: [PATCH v5 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
On 10.07.23 09:50, Neha Malcom Francis wrote:
> Hi Jan
>
> On 07/07/23 19:08, Jan Kiszka wrote:
>> 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";
>>> + };
>>> + };
>>> };
>>>
Re: [PATCH v5 12/23] j721s2: yaml: Add board configs for J721S2
On 07.07.23 14:34, Neha Malcom Francis wrote: > 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 >
Re: [PATCH v5 10/23] am64x: yaml: Add board configs for AM64x
On 07.07.23 14:34, Neha Malcom Francis wrote: > Added YAML configs for AM64xx > > Signed-off-by: Neha Malcom Francis > --- > board/ti/am64x/board-cfg.yaml | 37 + > board/ti/am64x/pm-cfg.yaml| 12 + > board/ti/am64x/rm-cfg.yaml| 1400 + > board/ti/am64x/sec-cfg.yaml | 380 + > 4 files changed, 1829 insertions(+) > create mode 100644 board/ti/am64x/board-cfg.yaml > create mode 100644 board/ti/am64x/pm-cfg.yaml > create mode 100644 board/ti/am64x/rm-cfg.yaml > create mode 100644 board/ti/am64x/sec-cfg.yaml > > diff --git a/board/ti/am64x/board-cfg.yaml b/board/ti/am64x/board-cfg.yaml > new file mode 100644 > index 00..f1f7c68d50 > --- /dev/null > +++ b/board/ti/am64x/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 AM64x > +# > + > +--- > + > +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/am64x/pm-cfg.yaml b/board/ti/am64x/pm-cfg.yaml > new file mode 100644 > index 00..c97495f482 > --- /dev/null > +++ b/board/ti/am64x/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 AM64x > +# > + > +--- > + > +pm-cfg: > +rev: > +boardcfg_abi_maj : 0x0 > +boardcfg_abi_min : 0x1 > diff --git a/board/ti/am64x/rm-cfg.yaml b/board/ti/am64x/rm-cfg.yaml > new file mode 100644 > index 00..1e6b07aef6 > --- /dev/null > +++ b/board/ti/am64x/rm-cfg.yaml > @@ -0,0 +1,1400 @@ > +# SPDX-License-Identifier: GPL-2.0+ > +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > +# > +# Resource management configuration for AM64x > +# > + > +--- > + > +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: 38 > +allowed_atype : 0x2A > +allowed_qos : 0x > +allowed_orderid : 0x > +allowed_priority : 0x > +allowed_sched_priority : 0xAA > +- #5 > +
Re: [PATCH v5 01/23] binman: ti-board-config: Add support for TI board config binaries
On 07.07.23 14:34, Neha Malcom Francis wrote:
> The ti-board-config entry loads and validates a given YAML config file
> against a given schema, and generates the board config binary. K3
> devices require these binaries to be packed into the final system
> firmware images.
>
> Signed-off-by: Neha Malcom Francis
> Reviewed-by: Simon Glass
> ---
> tools/binman/entries.rst | 48
> tools/binman/etype/ti_board_config.py | 259 ++
> tools/binman/ftest.py | 20 ++
> tools/binman/test/277_ti_board_cfg.dts| 14 +
> .../binman/test/278_ti_board_cfg_combined.dts | 25 ++
> .../binman/test/279_ti_board_cfg_no_type.dts | 11 +
> tools/binman/test/yaml/config.yaml| 19 ++
> tools/binman/test/yaml/schema.yaml| 51
> tools/binman/test/yaml/schema_notype.yaml | 40 +++
> 9 files changed, 487 insertions(+)
> create mode 100644 tools/binman/etype/ti_board_config.py
> create mode 100644 tools/binman/test/277_ti_board_cfg.dts
> create mode 100644 tools/binman/test/278_ti_board_cfg_combined.dts
> create mode 100644 tools/binman/test/279_ti_board_cfg_no_type.dts
> create mode 100644 tools/binman/test/yaml/config.yaml
> create mode 100644 tools/binman/test/yaml/schema.yaml
> create mode 100644 tools/binman/test/yaml/schema_notype.yaml
>
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index b71af801fd..14a2d03fad 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -1658,6 +1658,54 @@ by setting the size of the entry to something larger
> than the text.
>
>
>
> +.. _etype_ti_board_config:
> +
> +Entry: ti-board-config: An entry containing a TI schema validated board
> config binary
> +-
> +
> +This etype supports generation of two kinds of board configuration
> +binaries: singular board config binary as well as combined board config
> +binary.
> +
> +Properties / Entry arguments:
> +- config-file: File containing board configuration data in YAML
> +- schema-file: File containing board configuration YAML schema against
> + which the config file is validated
> +
> +Output files:
> +- board config binary: File containing board configuration binary
> +
> +These above parameters are used only when the generated binary is
> +intended to be a single board configuration binary. Example::
> +
> +my-ti-board-config {
> +ti-board-config {
> +config = "board-config.yaml";
> +schema = "schema.yaml";
> +};
> +};
> +
> +To generate a combined board configuration binary, we pack the
> +needed individual binaries into a ti-board-config binary. In this case,
> +the available supported subnode names are board-cfg, pm-cfg, sec-cfg and
> +rm-cfg. The final binary is prepended with a header containing details about
> +the included board config binaries. Example::
> +
> +my-combined-ti-board-config {
> +ti-board-config {
> +board-cfg {
> +config = "board-cfg.yaml";
> +schema = "schema.yaml";
> +};
> +sec-cfg {
> +config = "sec-cfg.yaml";
> +schema = "schema.yaml";
> +};
> +}
> +}
> +
> +
> +
> .. _etype_u_boot:
>
> Entry: u-boot: U-Boot flat binary
> diff --git a/tools/binman/etype/ti_board_config.py
> b/tools/binman/etype/ti_board_config.py
> new file mode 100644
> index 00..0799e5dc59
> --- /dev/null
> +++ b/tools/binman/etype/ti_board_config.py
> @@ -0,0 +1,259 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/
> +# Written by Neha Malcom Francis
> +#
> +# Entry-type module for generating schema validated TI board
> +# configuration binary
> +#
> +
> +import os
> +import struct
> +import yaml
> +
> +from collections import OrderedDict
> +from jsonschema import validate
> +from shutil import copyfileobj
> +
> +from binman.entry import Entry
> +from binman.etype.section import Entry_section
> +from dtoc import fdt_util
> +from u_boot_pylib import tools
> +
> +BOARDCFG = 0xB
> +BOARDCFG_SEC = 0xD
> +BOARDCFG_PM = 0xE
> +BOARDCFG_RM = 0xC
> +BOARDCFG_NUM_ELEMS = 4
> +
> +class Entry_ti_board_config(Entry_section):
> +"""An entry containing a TI schema validated board config binary
> +
> +This etype supports generation of two kinds of board configuration
> +binaries: singular board config binary as well as combined board config
> +binary.
> +
> +Properties / Entry arguments:
> +- config-file: File containing board configuration data in YAML
> +- schema-file: File containing board configuration YAML schema
> against
> + which the config file is validated
> +
> +Output files:
> +- board config binary: File containing board configuration binary
> +
> +
Re: [PATCH v3 00/19] binman: Simple templating feature and mkimage conversion
On 10.07.23 18:00, Simon Glass wrote: > Hi Jan, > > On Sun, 9 Jul 2023 at 23:21, Jan Kiszka wrote: >> >> On 10.07.23 04:40, Simon Glass wrote: >>> This series converts the mkimage entry type to be a section, i.e. based on >>> the entry_Section class. This makes it more consistent in its behaviour, >>> e.g. allowing symbol writing and expanded entries. >>> >>> A simple templating feature is also introduced, to reduce duplication >>> when a set of entries must be used in multiple images. >>> >>> In this version the nodes from the template are placed before any other >>> nodes, meaning that the template sets the node order. This seems more >>> consistent than other mechanisms. >>> >>> Changes in v3: >>> - Add new patch for elf to return number of written symbols >>> - Add new patch with more detail on how ObtainContents() works >>> - Fix up some tests which now need SPL and TPL >>> - Avoid calling ObtainContents() when not needed >>> - Fix 'specific' typo >>> - Add a new devicetree file especially for node copying >>> - Correct logic for merging nodes in order >>> - Tidy up some comments >>> - Adjust to use the new example file >>> - Drop duplicate dts-v1 header >>> - Add new test case for templating in a FIT >>> - Add new patch to support writing symbols inside a mkimage image >>> >>> Changes in v2: >>> - Drop now-unnecessary methods in mkimage etype >>> - Correct ordering of template nodes >>> - Fix 'preseverd' and 'inserter' typos >>> >>> Marek Vasut (1): >>> binman: Convert mkimage to Entry_section >>> >>> Simon Glass (18): >>> binman: Correct coverage gap in control >>> binman: Init align_default in entry_Section >>> binman: Use GetEntries() to obtain section contents >>> binman: Read _multiple_data_files in the correct place >>> binman: Allow disabling symbol writing >>> stm32mp15: Avoid writing symbols in SPL >>> binman: Update elf to return number of written symbols >>> binman: Add more detail on how ObtainContents() works >>> binman: Provide a way to specify the fdt-list directly >>> binman: Drop __bss_size variable in bss_data.c >>> binman: Correct handling of zero bss size >>> dtoc: Support copying the contents of a node into another >>> dtoc: Allow inserting a list of nodes into another >>> binman: Support simple templates >>> binman: Support templating with multiple images >>> binman: Add a test for templating in a FIT >>> binman: Support templates at any level >>> binman: Support writing symbols inside a mkimage image >>> >>> arch/arm/dts/stm32mp15-u-boot.dtsi | 1 + >>> tools/binman/binman.rst| 89 + >>> tools/binman/control.py| 34 +++- >>> tools/binman/elf.py| 13 +- >>> tools/binman/elf_test.py | 13 +- >>> tools/binman/entries.rst | 6 + >>> tools/binman/entry.py | 11 +- >>> tools/binman/etype/blob_phase.py | 5 + >>> tools/binman/etype/fit.py | 9 + >>> tools/binman/etype/mkimage.py | 110 --- >>> tools/binman/etype/section.py | 54 +++-- >>> tools/binman/etype/u_boot_spl_bss_pad.py | 2 +- >>> tools/binman/etype/u_boot_tpl_bss_pad.py | 2 +- >>> tools/binman/etype/u_boot_vpl_bss_pad.py | 2 +- >>> tools/binman/ftest.py | 218 - >>> tools/binman/test/282_symbols_disable.dts | 25 +++ >>> tools/binman/test/283_mkimage_special.dts | 24 +++ >>> tools/binman/test/284_fit_fdt_list.dts | 58 ++ >>> tools/binman/test/285_spl_expand.dts | 13 ++ >>> tools/binman/test/286_template.dts | 42 >>> tools/binman/test/287_template_multi.dts | 27 +++ >>> tools/binman/test/288_template_fit.dts | 37 >>> tools/binman/test/289_template_section.dts | 52 + >>> tools/binman/test/290_mkimage_sym.dts | 27 +++ >>> tools/binman/test/Makefile | 5 +- >>> tools/binman/test/bss_data.c | 3 +- >>> tools/binman/test/bss_data_zero.c | 16 ++ >>> tools/binman/test/bss_data_zero.lds| 15 ++ >>> tools/binman/test/embed_data.lds | 1 + >>> t
Re: [PATCH v5 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
On 10.07.23 11:12, Neha Malcom Francis wrote: > Hi Simon > > On 07/07/23 23:05, Simon Glass wrote: >> 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. >> > > Right, I'll have a shot at it once this series is up. Thanks! > I would recommend testing it earlier locally if you are interested - there might be still some edges left, and early feedback already helped to improve it. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v3 00/19] binman: Simple templating feature and mkimage conversion
On 10.07.23 04:40, Simon Glass wrote:
> This series converts the mkimage entry type to be a section, i.e. based on
> the entry_Section class. This makes it more consistent in its behaviour,
> e.g. allowing symbol writing and expanded entries.
>
> A simple templating feature is also introduced, to reduce duplication
> when a set of entries must be used in multiple images.
>
> In this version the nodes from the template are placed before any other
> nodes, meaning that the template sets the node order. This seems more
> consistent than other mechanisms.
>
> Changes in v3:
> - Add new patch for elf to return number of written symbols
> - Add new patch with more detail on how ObtainContents() works
> - Fix up some tests which now need SPL and TPL
> - Avoid calling ObtainContents() when not needed
> - Fix 'specific' typo
> - Add a new devicetree file especially for node copying
> - Correct logic for merging nodes in order
> - Tidy up some comments
> - Adjust to use the new example file
> - Drop duplicate dts-v1 header
> - Add new test case for templating in a FIT
> - Add new patch to support writing symbols inside a mkimage image
>
> Changes in v2:
> - Drop now-unnecessary methods in mkimage etype
> - Correct ordering of template nodes
> - Fix 'preseverd' and 'inserter' typos
>
> Marek Vasut (1):
> binman: Convert mkimage to Entry_section
>
> Simon Glass (18):
> binman: Correct coverage gap in control
> binman: Init align_default in entry_Section
> binman: Use GetEntries() to obtain section contents
> binman: Read _multiple_data_files in the correct place
> binman: Allow disabling symbol writing
> stm32mp15: Avoid writing symbols in SPL
> binman: Update elf to return number of written symbols
> binman: Add more detail on how ObtainContents() works
> binman: Provide a way to specify the fdt-list directly
> binman: Drop __bss_size variable in bss_data.c
> binman: Correct handling of zero bss size
> dtoc: Support copying the contents of a node into another
> dtoc: Allow inserting a list of nodes into another
> binman: Support simple templates
> binman: Support templating with multiple images
> binman: Add a test for templating in a FIT
> binman: Support templates at any level
> binman: Support writing symbols inside a mkimage image
>
> arch/arm/dts/stm32mp15-u-boot.dtsi | 1 +
> tools/binman/binman.rst| 89 +
> tools/binman/control.py| 34 +++-
> tools/binman/elf.py| 13 +-
> tools/binman/elf_test.py | 13 +-
> tools/binman/entries.rst | 6 +
> tools/binman/entry.py | 11 +-
> tools/binman/etype/blob_phase.py | 5 +
> tools/binman/etype/fit.py | 9 +
> tools/binman/etype/mkimage.py | 110 ---
> tools/binman/etype/section.py | 54 +++--
> tools/binman/etype/u_boot_spl_bss_pad.py | 2 +-
> tools/binman/etype/u_boot_tpl_bss_pad.py | 2 +-
> tools/binman/etype/u_boot_vpl_bss_pad.py | 2 +-
> tools/binman/ftest.py | 218 -
> tools/binman/test/282_symbols_disable.dts | 25 +++
> tools/binman/test/283_mkimage_special.dts | 24 +++
> tools/binman/test/284_fit_fdt_list.dts | 58 ++
> tools/binman/test/285_spl_expand.dts | 13 ++
> tools/binman/test/286_template.dts | 42
> tools/binman/test/287_template_multi.dts | 27 +++
> tools/binman/test/288_template_fit.dts | 37
> tools/binman/test/289_template_section.dts | 52 +
> tools/binman/test/290_mkimage_sym.dts | 27 +++
> tools/binman/test/Makefile | 5 +-
> tools/binman/test/bss_data.c | 3 +-
> tools/binman/test/bss_data_zero.c | 16 ++
> tools/binman/test/bss_data_zero.lds| 15 ++
> tools/binman/test/embed_data.lds | 1 +
> tools/dtoc/fdt.py | 122 +++-
> tools/dtoc/test/dtoc_test_copy.dts | 86
> tools/dtoc/test_fdt.py | 93 +
> 32 files changed, 1147 insertions(+), 68 deletions(-)
> create mode 100644 tools/binman/test/282_symbols_disable.dts
> create mode 100644 tools/binman/test/283_mkimage_special.dts
> create mode 100644 tools/binman/test/284_fit_fdt_list.dts
> create mode 100644 tools/binman/test/285_spl_expand.dts
> create mode 100644 tools/binman/test/286_template.dts
> create mode 100644 tools/binman/test/287_template_multi.dts
> create mode 100644 tools/binman/test/288_template_fit.dts
> create mode 100644 tools/binman/test/289_template_section.dts
> create mode 100644 tools/binman/test/290_mkimage_sym.dts
> create mode 100644 tools/binman/test/bss_data_zero.c
> create mode 100644 tools/binman/test/bss_data_zero.lds
> create mode 100644 tools/dtoc/test/dtoc_test_copy.dts
>
Works much better!
What does not work yet:
/dts-v1/;
/ {
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
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
>>>>>>> +};
>>>>>>> +
>>
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 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";
>>>&
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 12/12] binman: Support simple templates
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
Re: [PATCH 07/12] binman: Provide a way to specific the fdt-list directly
On 28.06.23 13:41, Simon Glass wrote:
> Sometimes multiple boards are built with binman and it is useful to
> specify a different FDT list for each. At present this is not possible
> without providing multiple values of the of-list entryarg (which is not
> supported in the U-Boot build system).
>
> Allow a fit,fdt-list-val string-list property to be used instead.
>
> Signed-off-by: Simon Glass
> ---
>
> tools/binman/entries.rst | 6 +++
> tools/binman/etype/fit.py | 9
> tools/binman/ftest.py | 14 ++-
> tools/binman/test/284_fit_fdt_list.dts | 58 ++
> 4 files changed, 86 insertions(+), 1 deletion(-)
> create mode 100644 tools/binman/test/284_fit_fdt_list.dts
>
> diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
> index b71af801fdad..b55f424620a3 100644
> --- a/tools/binman/entries.rst
> +++ b/tools/binman/entries.rst
> @@ -615,6 +615,12 @@ The top-level 'fit' node supports the following special
> properties:
> `of-list` meaning that `-a of-list="dtb1 dtb2..."` should be passed
> to binman.
>
> +fit,fdt-list-val
> +As an alternative to fit,fdt-list the list of device tree files
> +can be provided in this property as a string list, e.g.::
> +
> +fit,fdt-list-val = "dtb1", "dtb2";
> +
> Substitutions
> ~
>
> diff --git a/tools/binman/etype/fit.py b/tools/binman/etype/fit.py
> index c395706ece5f..ef4d0667578d 100644
> --- a/tools/binman/etype/fit.py
> +++ b/tools/binman/etype/fit.py
> @@ -81,6 +81,12 @@ class Entry_fit(Entry_section):
> `of-list` meaning that `-a of-list="dtb1 dtb2..."` should be
> passed
> to binman.
>
> +fit,fdt-list-val
> +As an alternative to fit,fdt-list the list of device tree files
> +can be provided in this property as a string list, e.g.::
> +
> +fit,fdt-list-val = "dtb1", "dtb2";
> +
> Substitutions
> ~
>
> @@ -361,6 +367,9 @@ class Entry_fit(Entry_section):
> [EntryArg(self._fit_list_prop.value, str)])
> if fdts is not None:
> self._fdts = fdts.split()
> +else:
> +self._fdts = fdt_util.GetStringList(self._node,
> 'fit,fdt-list-val')
> +
> self._fit_default_dt =
> self.GetEntryArgsOrProps([EntryArg('default-dt',
>str)])[0]
>
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index 6d0ffda2f432..54691c420733 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -6739,6 +6739,18 @@ fdt fdtmapExtract the
> devicetree blob from the fdtmap
> # Just check that the data appears in the file somewhere
> self.assertIn(U_BOOT_DATA, data)
>
> +def testFitFdtList(self):
> +"""Test an image with an FIT with the fit,fdt-list-val option"""
> +entry_args = {
> +'default-dt': 'test-fdt2',
> +}
> +data = self._DoReadFileDtb(
> +'284_fit_fdt_list.dts',
> +entry_args=entry_args,
> +extra_indirs=[os.path.join(self._indir, TEST_FDT_SUBDIR)])[0]
> +self.assertEqual(U_BOOT_NODTB_DATA, data[-len(U_BOOT_NODTB_DATA):])
> +fit_data = data[len(U_BOOT_DATA):-len(U_BOOT_NODTB_DATA)]
> +
>
> -if __name__ == "_s_main__":
> +if __name__ == "__main__":
> unittest.main()
> diff --git a/tools/binman/test/284_fit_fdt_list.dts
> b/tools/binman/test/284_fit_fdt_list.dts
> new file mode 100644
> index ..8885313f5b88
> --- /dev/null
> +++ b/tools/binman/test/284_fit_fdt_list.dts
> @@ -0,0 +1,58 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + binman {
> + u-boot {
> + };
> + fit {
> + description = "test-desc";
> + #address-cells = <1>;
> + fit,fdt-list-val = "test-fdt1", "test-fdt2";
> +
> + images {
> + kernel {
> + description = "Vanilla Linux kernel";
> + type = "kernel";
> + arch = "ppc";
> + os = "linux";
> + compression = "gzip";
> + load = <>;
> + entry = <>;
> + hash-1 {
> + algo = "crc32";
> + };
> + hash-2 {
> + algo = "sha1";
> + };
> + u-boot {
> +
Re: [PATCH 12/12] binman: Support simple templates
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.
> +
> +Note: The above limitation will likely be removed in future, so that the
> +template subnodes appear before the target subnodes.
> +
> +
> Updating an ELF file
>
>
> diff --git a/tools/binman/control.py b/tools/binman/control.py
> index 68597c4e7792..e7faca78e9aa 100644
> --- a/tools/binman/control.py
> +++ b/tools/binman/control.py
> @@ -22,6 +22,7 @@ from binman import bintool
> from binman import cbfs_util
> from binman import elf
> from binman import entry
> +from dtoc import fdt_util
> from u_boot_pylib import command
> from u_boot_pylib import tools
> from u_boot_pylib import tout
> @@ -478,6 +479,12 @@ def SignEntries(image_fname, input_fname,
> privatekey_fname, algo,
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 20.06.23 16:36, Simon Glass wrote: > Hi Jan, > > On Tue, 20 Jun 2023 at 11:37, Jan Kiszka wrote: >> >> On 20.06.23 12:11, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: >>>> >>>> On 19.06.23 16:09, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: >>>>>> >>>>>> On 19.06.23 14:36, Simon Glass wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >>>>>>>> >>>>>>>> On 15.06.23 13:46, Jan Kiszka wrote: >>>>>>>>> On 15.06.23 13:38, Simon Glass wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> >>>>>>>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 15.06.23 13:19, Simon Glass wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> From: Jan Kiszka >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., >>>>>>>>>>>>>>>>> to inject >>>>>>>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define >>>>>>>>>>>>>>>>> multiple >>>>>>>>>>>>>>>>> of-lists. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> CC: Simon Glass >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> Makefile | 1 + >>>>>>>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm really not keen on this, since it means that the Makefile >>>>>>>>>>>>>>>> (or some >>>>>>>>>>>>>>>> vars it sets) are again involved in controlling the image >>>>>>>>>>>>>>>> generation. >>>>>>>>>>>>>>>> It should really all be in the binman image description / >>>>>>>>>>>>>>>> .dtsi file >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> binman does not allow me to unrole of-list inside the dts file, >>>>>>>>>>>>>>> does it? >>>>>>>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X >>>>>>>>>>>>>>> switches >>>>>>>>>>>>>>> and, thus, no such EXTRA_ARGS. >>>>>>>>>>>>>> >>>>>>>>>>>>&
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 20.06.23 12:11, Simon Glass wrote: > Hi Jan, > > On Mon, 19 Jun 2023 at 16:09, Jan Kiszka wrote: >> >> On 19.06.23 16:09, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote: >>>> >>>> On 19.06.23 14:36, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote: >>>>>> >>>>>> On 15.06.23 13:46, Jan Kiszka wrote: >>>>>>> On 15.06.23 13:38, Simon Glass wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On 15.06.23 13:19, Simon Glass wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> >>>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: Jan Kiszka >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to >>>>>>>>>>>>>>> inject >>>>>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define >>>>>>>>>>>>>>> multiple >>>>>>>>>>>>>>> of-lists. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> CC: Simon Glass >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> Makefile | 1 + >>>>>>>>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm really not keen on this, since it means that the Makefile >>>>>>>>>>>>>> (or some >>>>>>>>>>>>>> vars it sets) are again involved in controlling the image >>>>>>>>>>>>>> generation. >>>>>>>>>>>>>> It should really all be in the binman image description / .dtsi >>>>>>>>>>>>>> file >>>>>>>>>>>>> >>>>>>>>>>>>> binman does not allow me to unrole of-list inside the dts file, >>>>>>>>>>>>> does it? >>>>>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X >>>>>>>>>>>>> switches >>>>>>>>>>>>> and, thus, no such EXTRA_ARGS. >>>>>>>>>>>> >>>>>>>>>>>> Can you explain a bit more about what you mean by 'unrole'? It is >>>>>>>>>>>> just >>>>>>>>>>>> software, so anything should be possible. >>>>>>>>>>> >>>>>>>>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>>>>>>>>> >>>>>>>>>>> fit,ftd-list = "first.dtb second.dtb" >>>>>>>>>>> >>>>>>>>>>> I rather need to go via the EntryArg indirection of the binman >
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 19.06.23 16:09, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 19 Jun 2023 at 14:28, Jan Kiszka wrote:
>>
>> On 19.06.23 14:36, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote:
>>>>
>>>> On 15.06.23 13:46, Jan Kiszka wrote:
>>>>> On 15.06.23 13:38, Simon Glass wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote:
>>>>>>>
>>>>>>> On 15.06.23 13:19, Simon Glass wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>>>>>> Hi Jan,
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Jan Kiszka
>>>>>>>>>>>>>
>>>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to
>>>>>>>>>>>>> inject
>>>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define
>>>>>>>>>>>>> multiple
>>>>>>>>>>>>> of-lists.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Signed-off-by: Jan Kiszka
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> CC: Simon Glass
>>>>>>>>>>>>> ---
>>>>>>>>>>>>> Makefile | 1 +
>>>>>>>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>>>>>>
>>>>>>>>>>>> I'm really not keen on this, since it means that the Makefile (or
>>>>>>>>>>>> some
>>>>>>>>>>>> vars it sets) are again involved in controlling the image
>>>>>>>>>>>> generation.
>>>>>>>>>>>> It should really all be in the binman image description / .dtsi
>>>>>>>>>>>> file
>>>>>>>>>>>
>>>>>>>>>>> binman does not allow me to unrole of-list inside the dts file,
>>>>>>>>>>> does it?
>>>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X
>>>>>>>>>>> switches
>>>>>>>>>>> and, thus, no such EXTRA_ARGS.
>>>>>>>>>>
>>>>>>>>>> Can you explain a bit more about what you mean by 'unrole'? It is
>>>>>>>>>> just
>>>>>>>>>> software, so anything should be possible.
>>>>>>>>>
>>>>>>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say
>>>>>>>>>
>>>>>>>>> fit,ftd-list = "first.dtb second.dtb"
>>>>>>>>>
>>>>>>>>> I rather need to go via the EntryArg indirection of the binman
>>>>>>>>> command line.
>>>>>>>>
>>>>>>>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you
>>>>>>>> wanting to filter that list based on something else?
>>>>>>>>
>>>>>>>> I'm afraid I am really not following this at all.
>>>>>>>
>>>>>>> CONFIG_OF_LIST is not working here as we have two different boards with
>>>>>>> two different lists.
>>>>>>
>>>>>> But we only build one board at a time, don't we?
>>>>>
>>>>> No, this is about building two flash images for two different board
>>>>> generations in the same binman run (see patch 3).
>>>>>
>>>>>>
>>>>>> We could provide a way to select between different lists, but how does
>>>>>> Makefile get access to them?
>>>>>
>>>>> See patch 3: known lists, now put into board config.mk.
>>>>>
>>>>
>>>> Any better suggestions for this issue? Otherwise, I will have to keep
>>>> binman args extension for now.
>>>
>>> I've dug into this a bit. The use of #defines and macros looks to be
>>> unnecessary, unless I am missing something.
>>>
>>> You can do things like this:
>>>
>>> fit_node: fit {
>>> // base definition of FIT
>>> };
>>>
>>> the later on:
>>>
>>> fit_node: {
>>> #ifdef xxx
>>>// override a few things
>>>fit,fdt-list = ...
>>> #else
>>>
>>> #endif
>>
>> As I wrote already, I have a solution for that by using a template dtsi.
>>
>>>
>>> There is no need to specify the properties all at once. You can update
>>> a property later on just by referring to its node as above.
>>
>> Does not help when the anchor name needs to vary as well. That's where I
>> will use a #define to customize the template on include.
>>
>>>
>>> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
>>> and all the #define stuff.
>>
>> You still didn't address my question. Should I share my version to make
>> the problem clearer? But I thought I explained this in various shades
>> already.
>
> Yes, if I am looking at the wrong patches, please point me to the
> correct series, or push a tree somewhere.
>
Please have a look at
https://github.com/siemens/u-boot/commit/393ce2b78cee9214edda7f7e04f6ca2ce144195e
Thanks,
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 19.06.23 14:36, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 16 Jun 2023 at 16:42, Jan Kiszka wrote:
>>
>> On 15.06.23 13:46, Jan Kiszka wrote:
>>> On 15.06.23 13:38, Simon Glass wrote:
>>>> Hi Jan,
>>>>
>>>> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote:
>>>>>
>>>>> On 15.06.23 13:19, Simon Glass wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote:
>>>>>>>
>>>>>>> On 15.06.23 12:55, Simon Glass wrote:
>>>>>>>> Hi Jan,
>>>>>>>>
>>>>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 12.06.23 23:17, Simon Glass wrote:
>>>>>>>>>> Hi Jan,
>>>>>>>>>>
>>>>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> From: Jan Kiszka
>>>>>>>>>>>
>>>>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to
>>>>>>>>>>> inject
>>>>>>>>>>> specific settings. Will be used by IOT2050 first to define multiple
>>>>>>>>>>> of-lists.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Jan Kiszka
>>>>>>>>>>> ---
>>>>>>>>>>> CC: Simon Glass
>>>>>>>>>>> ---
>>>>>>>>>>> Makefile | 1 +
>>>>>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>>>>
>>>>>>>>>> I'm really not keen on this, since it means that the Makefile (or
>>>>>>>>>> some
>>>>>>>>>> vars it sets) are again involved in controlling the image generation.
>>>>>>>>>> It should really all be in the binman image description / .dtsi file
>>>>>>>>>
>>>>>>>>> binman does not allow me to unrole of-list inside the dts file, does
>>>>>>>>> it?
>>>>>>>>> With such a feature, I wouldn't need any custom -a of-list-X switches
>>>>>>>>> and, thus, no such EXTRA_ARGS.
>>>>>>>>
>>>>>>>> Can you explain a bit more about what you mean by 'unrole'? It is just
>>>>>>>> software, so anything should be possible.
>>>>>>>
>>>>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say
>>>>>>>
>>>>>>> fit,ftd-list = "first.dtb second.dtb"
>>>>>>>
>>>>>>> I rather need to go via the EntryArg indirection of the binman command
>>>>>>> line.
>>>>>>
>>>>>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you
>>>>>> wanting to filter that list based on something else?
>>>>>>
>>>>>> I'm afraid I am really not following this at all.
>>>>>
>>>>> CONFIG_OF_LIST is not working here as we have two different boards with
>>>>> two different lists.
>>>>
>>>> But we only build one board at a time, don't we?
>>>
>>> No, this is about building two flash images for two different board
>>> generations in the same binman run (see patch 3).
>>>
>>>>
>>>> We could provide a way to select between different lists, but how does
>>>> Makefile get access to them?
>>>
>>> See patch 3: known lists, now put into board config.mk.
>>>
>>
>> Any better suggestions for this issue? Otherwise, I will have to keep
>> binman args extension for now.
>
> I've dug into this a bit. The use of #defines and macros looks to be
> unnecessary, unless I am missing something.
>
> You can do things like this:
>
> fit_node: fit {
> // base definition of FIT
> };
>
> the later on:
>
> fit_node: {
> #ifdef xxx
>// override a few things
>fit,fdt-list = ...
> #else
>
> #endif
As I wrote already, I have a solution for that by using a template dtsi.
>
> There is no need to specify the properties all at once. You can update
> a property later on just by referring to its node as above.
Does not help when the anchor name needs to vary as well. That's where I
will use a #define to customize the template on include.
>
> I think with this you should be above to eliminate BINMAN_EXTRA_ARGS
> and all the #define stuff.
You still didn't address my question. Should I share my version to make
the problem clearer? But I thought I explained this in various shades
already.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 13:46, Jan Kiszka wrote: > On 15.06.23 13:38, Simon Glass wrote: >> Hi Jan, >> >> On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: >>> >>> On 15.06.23 13:19, Simon Glass wrote: >>>> Hi Jan, >>>> >>>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >>>>> >>>>> On 15.06.23 12:55, Simon Glass wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >>>>>>> >>>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>>> Hi Jan, >>>>>>>> >>>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>>>>>>> >>>>>>>>> From: Jan Kiszka >>>>>>>>> >>>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>>>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>>>>> of-lists. >>>>>>>>> >>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>> --- >>>>>>>>> CC: Simon Glass >>>>>>>>> --- >>>>>>>>> Makefile | 1 + >>>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>> >>>>>>>> I'm really not keen on this, since it means that the Makefile (or some >>>>>>>> vars it sets) are again involved in controlling the image generation. >>>>>>>> It should really all be in the binman image description / .dtsi file >>>>>>> >>>>>>> binman does not allow me to unrole of-list inside the dts file, does it? >>>>>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>>>>> and, thus, no such EXTRA_ARGS. >>>>>> >>>>>> Can you explain a bit more about what you mean by 'unrole'? It is just >>>>>> software, so anything should be possible. >>>>> >>>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>>> >>>>> fit,ftd-list = "first.dtb second.dtb" >>>>> >>>>> I rather need to go via the EntryArg indirection of the binman command >>>>> line. >>>> >>>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >>>> wanting to filter that list based on something else? >>>> >>>> I'm afraid I am really not following this at all. >>> >>> CONFIG_OF_LIST is not working here as we have two different boards with >>> two different lists. >> >> But we only build one board at a time, don't we? > > No, this is about building two flash images for two different board > generations in the same binman run (see patch 3). > >> >> We could provide a way to select between different lists, but how does >> Makefile get access to them? > > See patch 3: known lists, now put into board config.mk. > Any better suggestions for this issue? Otherwise, I will have to keep binman args extension for now. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 13:38, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:21, Jan Kiszka wrote: >> >> On 15.06.23 13:19, Simon Glass wrote: >>> Hi Jan, >>> >>> On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >>>> >>>> On 15.06.23 12:55, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >>>>>> >>>>>> On 12.06.23 23:17, Simon Glass wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>>>>>> >>>>>>>> From: Jan Kiszka >>>>>>>> >>>>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>>>> of-lists. >>>>>>>> >>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>> --- >>>>>>>> CC: Simon Glass >>>>>>>> --- >>>>>>>> Makefile | 1 + >>>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> I'm really not keen on this, since it means that the Makefile (or some >>>>>>> vars it sets) are again involved in controlling the image generation. >>>>>>> It should really all be in the binman image description / .dtsi file >>>>>> >>>>>> binman does not allow me to unrole of-list inside the dts file, does it? >>>>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>>>> and, thus, no such EXTRA_ARGS. >>>>> >>>>> Can you explain a bit more about what you mean by 'unrole'? It is just >>>>> software, so anything should be possible. >>>> >>>> To use a DT sequence, I need to specify fit,ftd-list. But I can say >>>> >>>> fit,ftd-list = "first.dtb second.dtb" >>>> >>>> I rather need to go via the EntryArg indirection of the binman command >>>> line. >>> >>> Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you >>> wanting to filter that list based on something else? >>> >>> I'm afraid I am really not following this at all. >> >> CONFIG_OF_LIST is not working here as we have two different boards with >> two different lists. > > But we only build one board at a time, don't we? No, this is about building two flash images for two different board generations in the same binman run (see patch 3). > > We could provide a way to select between different lists, but how does > Makefile get access to them? See patch 3: known lists, now put into board config.mk. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
On 12.06.23 23:17, Simon Glass wrote:
> Hi Jan,
>
> On Mon, 5 Jun 2023 at 15:40, Jan Kiszka wrote:
>>
>> From: Jan Kiszka
>>
>> This avoids having to maintain to defconfigs that are 99% equivalent.
>> The approach is to use binman to generate two flash images,
>> flash-pg1.bin and flash-pg2.bin. With the help of some macros, we can
>> avoid duplicating the common binman image definitions.
>>
>> Suggested-by: Andrew Davis
>> Signed-off-by: Jan Kiszka
>> ---
>> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++
>> board/siemens/iot2050/Kconfig | 30 +-
>> board/siemens/iot2050/board.c | 14 +-
>> board/siemens/iot2050/config.mk | 6 +-
>> ...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +-
>> configs/iot2050_pg2_defconfig | 150 -
>> doc/board/siemens/iot2050.rst | 29 +-
>> tools/iot2050-sign-fw.sh | 9 +-
>> 8 files changed, 202 insertions(+), 338 deletions(-)
>> rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%)
>> delete mode 100644 configs/iot2050_pg2_defconfig
>
> We need to find another way to do this... the macros are horrible.
>
> Could you put the common code in another .dtsi file and include it twice?
>
> Then in the 'main' .dtsi file refer to some anchors to set the properties:
>
> _boot {
>fit,fdt-list = "...";
> };
I can use some preprocessor defines in that template code which need to
be re-defined before the inclusions. Prototype is working already.
>
> Or do we need a new binman feature to handle this?
>
> BTW using #ifdef on a particular target is something we should avoid.
> Isn't there another Kconfig (for the feature itself) that you can use?
What are you referring to?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 13:19, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 12:09, Jan Kiszka wrote: >> >> On 15.06.23 12:55, Simon Glass wrote: >>> Hi Jan, >>> >>> On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >>>> >>>> On 12.06.23 23:17, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>>>> >>>>>> From: Jan Kiszka >>>>>> >>>>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>>>> specific settings. Will be used by IOT2050 first to define multiple >>>>>> of-lists. >>>>>> >>>>>> Signed-off-by: Jan Kiszka >>>>>> --- >>>>>> CC: Simon Glass >>>>>> --- >>>>>> Makefile | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> I'm really not keen on this, since it means that the Makefile (or some >>>>> vars it sets) are again involved in controlling the image generation. >>>>> It should really all be in the binman image description / .dtsi file >>>> >>>> binman does not allow me to unrole of-list inside the dts file, does it? >>>> With such a feature, I wouldn't need any custom -a of-list-X switches >>>> and, thus, no such EXTRA_ARGS. >>> >>> Can you explain a bit more about what you mean by 'unrole'? It is just >>> software, so anything should be possible. >> >> To use a DT sequence, I need to specify fit,ftd-list. But I can say >> >> fit,ftd-list = "first.dtb second.dtb" >> >> I rather need to go via the EntryArg indirection of the binman command line. > > Do you mean you would rather not use '-a CONFIG_OF_LIST'. Or are you > wanting to filter that list based on something else? > > I'm afraid I am really not following this at all. CONFIG_OF_LIST is not working here as we have two different boards with two different lists. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 15.06.23 12:55, Simon Glass wrote: > Hi Jan, > > On Thu, 15 Jun 2023 at 11:26, Jan Kiszka wrote: >> >> On 12.06.23 23:17, Simon Glass wrote: >>> Hi Jan, >>> >>> On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >>>> >>>> From: Jan Kiszka >>>> >>>> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >>>> specific settings. Will be used by IOT2050 first to define multiple >>>> of-lists. >>>> >>>> Signed-off-by: Jan Kiszka >>>> --- >>>> CC: Simon Glass >>>> --- >>>> Makefile | 1 + >>>> 1 file changed, 1 insertion(+) >>> >>> I'm really not keen on this, since it means that the Makefile (or some >>> vars it sets) are again involved in controlling the image generation. >>> It should really all be in the binman image description / .dtsi file >> >> binman does not allow me to unrole of-list inside the dts file, does it? >> With such a feature, I wouldn't need any custom -a of-list-X switches >> and, thus, no such EXTRA_ARGS. > > Can you explain a bit more about what you mean by 'unrole'? It is just > software, so anything should be possible. To use a DT sequence, I need to specify fit,ftd-list. But I can say fit,ftd-list = "first.dtb second.dtb" I rather need to go via the EntryArg indirection of the binman command line. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/3] binman: Allow to define custom arguments
On 12.06.23 23:17, Simon Glass wrote: > Hi Jan, > > On Mon, 5 Jun 2023 at 15:39, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject >> specific settings. Will be used by IOT2050 first to define multiple >> of-lists. >> >> Signed-off-by: Jan Kiszka >> --- >> CC: Simon Glass >> --- >> Makefile | 1 + >> 1 file changed, 1 insertion(+) > > I'm really not keen on this, since it means that the Makefile (or some > vars it sets) are again involved in controlling the image generation. > It should really all be in the binman image description / .dtsi file binman does not allow me to unrole of-list inside the dts file, does it? With such a feature, I wouldn't need any custom -a of-list-X switches and, thus, no such EXTRA_ARGS. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v4 11/11] configs: starfive: Enable ID EEPROM configuration
On 07.06.23 04:19, yanhong wang wrote:
>
>
> On 2023/6/5 3:23, Jan Kiszka wrote:
>> On 25.05.23 11:36, Yanhong Wang wrote:
>>> Enabled ID_EEPROM and I2C configuration for StarFive VisionFive2 board.
>>>
>>> Signed-off-by: Yanhong Wang
>>> ---
>>> configs/starfive_visionfive2_defconfig | 19 ++-
>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configs/starfive_visionfive2_defconfig
>>> b/configs/starfive_visionfive2_defconfig
>>> index c57708199d..570a1f53a1 100644
>>> --- a/configs/starfive_visionfive2_defconfig
>>> +++ b/configs/starfive_visionfive2_defconfig
>>> @@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="StarFive #"
>>> CONFIG_OF_LIBFDT_OVERLAY=y
>>> CONFIG_DM_RESET=y
>>> CONFIG_SPL_MMC=y
>>> +CONFIG_SPL_DRIVERS_MISC=y
>>> CONFIG_SPL_STACK=0x818
>>> CONFIG_SPL=y
>>> CONFIG_SPL_SPI_FLASH_SUPPORT=y
>>> @@ -23,6 +24,7 @@ CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000
>>> CONFIG_ARCH_RV64I=y
>>> CONFIG_CMODEL_MEDANY=y
>>> CONFIG_RISCV_SMODE=y
>>> +# CONFIG_OF_BOARD_FIXUP is not set
>>> CONFIG_FIT=y
>>> CONFIG_DISTRO_DEFAULTS=y
>>> CONFIG_QSPI_BOOT=y
>>> @@ -34,6 +36,8 @@ CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt
>>> addr ${fdtcontroladdr};"
>>> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb"
>>> CONFIG_DISPLAY_CPUINFO=y
>>> CONFIG_DISPLAY_BOARDINFO=y
>>> +CONFIG_ID_EEPROM=y
>>> +CONFIG_SYS_EEPROM_BUS_NUM=5
>>> CONFIG_SPL_MAX_SIZE=0x4
>>> CONFIG_SPL_PAD_TO=0x0
>>> CONFIG_SPL_BSS_START_ADDR=0x804
>>> @@ -45,21 +49,34 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000
>>> CONFIG_SYS_SPL_MALLOC_SIZE=0x40
>>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
>>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2
>>> +CONFIG_SPL_I2C=y
>>> CONFIG_SPL_DM_SPI_FLASH=y
>>> CONFIG_SPL_DM_RESET=y
>>> CONFIG_SPL_SPI_LOAD=y
>>> CONFIG_SYS_CBSIZE=256
>>> CONFIG_SYS_PBSIZE=276
>>> CONFIG_SYS_BOOTM_LEN=0x400
>>> +CONFIG_CMD_EEPROM=y
>>> +CONFIG_SYS_EEPROM_SIZE=512
>>> +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=4
>>> +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=5
>>> CONFIG_CMD_MEMINFO=y
>>> +CONFIG_CMD_I2C=y
>>> CONFIG_CMD_TFTPPUT=y
>>> +CONFIG_OF_BOARD=y
>>> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>>> +CONFIG_SPL_DM_SEQ_ALIAS=y
>>> CONFIG_REGMAP=y
>>> CONFIG_SYSCON=y
>>> CONFIG_SPL_CLK_COMPOSITE_CCF=y
>>> CONFIG_CLK_COMPOSITE_CCF=y
>>> CONFIG_SPL_CLK_JH7110=y
>>> -# CONFIG_I2C is not set
>>> +CONFIG_DM_I2C=y
>>> +CONFIG_SYS_I2C_DW=y
>>> +CONFIG_MISC=y
>>> +CONFIG_I2C_EEPROM=y
>>> +CONFIG_SPL_I2C_EEPROM=y
>>> +CONFIG_SYS_I2C_EEPROM_ADDR=0X50
>>> CONFIG_MMC_HS400_SUPPORT=y
>>> CONFIG_SPL_MMC_HS400_SUPPORT=y
>>> CONFIG_MMC_DW=y
>>
>> This comes too late: Already patch 4 needs at least CONFIG_ID_EEPROM=y,
>> if not more.
>>
>
> Moving patch 4 to the series end, is that okay?
>
I didn't try. I would recommend that you to run a quick build check
after each patch being applied for the affected defconfig(s). Can be
automated (git rebase --exec ...).
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
[PATCH 3/3] boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
From: Jan Kiszka
This avoids having to maintain to defconfigs that are 99% equivalent.
The approach is to use binman to generate two flash images,
flash-pg1.bin and flash-pg2.bin. With the help of some macros, we can
avoid duplicating the common binman image definitions.
Suggested-by: Andrew Davis
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++
board/siemens/iot2050/Kconfig | 30 +-
board/siemens/iot2050/board.c | 14 +-
board/siemens/iot2050/config.mk | 6 +-
...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +-
configs/iot2050_pg2_defconfig | 150 -
doc/board/siemens/iot2050.rst | 29 +-
tools/iot2050-sign-fw.sh | 9 +-
8 files changed, 202 insertions(+), 338 deletions(-)
rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%)
delete mode 100644 configs/iot2050_pg2_defconfig
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 03ccc543293..1ea3fa85120 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) Siemens AG, 2020-2022
+ * Copyright (c) Siemens AG, 2020-2023
*
* Authors:
* Jan Kiszka
@@ -8,158 +8,177 @@
*/
#include
+#include
-/ {
- binman {
- filename = "flash.bin";
- pad-byte = <0xff>;
- size = <0x8c>;
- allow-repack;
-
- blob-ext@0x00 {
- offset = <0x00>;
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
- filename = "seboot_pg1.bin";
+#ifdef CONFIG_WDT_K3_RTI_FW_FILE
+#define IOT2050_WDT_FIRMWARE_LOADABLE "k3-rti-wdt-firmware"
+#define IOT2050_WDT_FIRMWARE \
+ k3-rti-wdt-firmware { \
+ type = "firmware"; \
+ load = <0x8200>;\
+ arch = "arm"; \
+ compression = "none"; \
+ blob-ext { \
+ filename = CONFIG_WDT_K3_RTI_FW_FILE; \
+ missing-msg = IOT2050_WDT_FIRMWARE_LOADABLE;\
+ }; \
+ hash { \
+ algo = "sha256";\
+ }; \
+ };
#else
- filename = "seboot_pg2.bin";
+#define IOT2050_WDT_FIRMWARE_LOADABLE
+#define IOT2050_WDT_FIRMWARE
#endif
- missing-msg = "iot2050-seboot";
- };
-
- blob@0x18 {
- offset = <0x18>;
- filename = "tispl.bin";
- };
-
- fit@0x38 {
- description = "U-Boot for IOT2050";
- fit,fdt-list = "of-list";
- offset = <0x38>;
- images {
- u-boot {
- description = "U-Boot";
- type = "standalone";
- arch = "arm64";
- os = "u-boot";
- compression = "none";
- load = <0x8080>;
- entry = <0x8080>;
- u-boot-nodtb {
- };
- hash {
- algo = "sha256";
- };
- };
- @fdt-SEQ {
- description = "fdt-NAME";
- type = "flat_dt";
- arch = "arm64";
- compression = "none";
- hash {
- algo = "sha256";
- };
- };
-
-#ifdef CONFIG_TARGET_IOT2050_A53_PG2
-
[PATCH 2/3] iot2050: Use binman in signing script
From: Jan Kiszka The underlying issue was fixed in the meantime. Switching to fully binman-based signing (script-free) remains a todo, though. Signed-off-by: Jan Kiszka --- CC: Simon Glass --- tools/iot2050-sign-fw.sh | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh index 4d1d79498c2..da425c94a5d 100755 --- a/tools/iot2050-sign-fw.sh +++ b/tools/iot2050-sign-fw.sh @@ -39,13 +39,9 @@ CERT_X509=$(mktemp .crt) openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512 cat $CERT_X509 tispl.bin > tispl.bin_signed -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 -dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x18/0x1000)) conv=notrunc +source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x18 rm $TEMP_X509 $CERT_X509 tools/mkimage -G $1 -r -o sha256,rsa4096 -F f...@0x38.fit -# currently broken in upstream -#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 -dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) seek=$((0x38/0x1000)) conv=notrunc +source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit fit@0x38 -- 2.35.3
[PATCH 0/3] iot2050: Re-unify its configs and build processes
This restores the possibility to build firmware images for both PG1 and
PG2-based IOT2050 devices in one run. We still end up with different
binaries, but the the build is now fed again from a single defconfig.
Should simplify maintenance and will also simplify our generation
tooling around it.
Jan
CC: Simon Glass
Jan Kiszka (3):
binman: Allow to define custom arguments
iot2050: Use binman in signing script
boards: siemens: iot2050: Unify PG1 and PG2/M.2 configurations again
Makefile | 1 +
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 299 ++
board/siemens/iot2050/Kconfig | 30 +-
board/siemens/iot2050/board.c | 14 +-
board/siemens/iot2050/config.mk | 6 +-
...ot2050_pg1_defconfig => iot2050_defconfig} | 3 +-
configs/iot2050_pg2_defconfig | 150 -
doc/board/siemens/iot2050.rst | 29 +-
tools/iot2050-sign-fw.sh | 13 +-
9 files changed, 203 insertions(+), 342 deletions(-)
rename configs/{iot2050_pg1_defconfig => iot2050_defconfig} (97%)
delete mode 100644 configs/iot2050_pg2_defconfig
--
2.35.3
[PATCH 1/3] binman: Allow to define custom arguments
From: Jan Kiszka
Introduce BINMAN_EXTRA_ARGS that can be set per board, e.g., to inject
specific settings. Will be used by IOT2050 first to define multiple
of-lists.
Signed-off-by: Jan Kiszka
---
CC: Simon Glass
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 10bfaa52adf..2285ae26b9b 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
$(BINMAN_DEBUG),-D) \
-a spl-dtb=$(CONFIG_SPL_OF_REAL) \
-a tpl-dtb=$(CONFIG_TPL_OF_REAL) \
-a pre-load-key-path=${PRE_LOAD_KEY_PATH} \
+ $(BINMAN_EXTRA_ARGS) \
$(BINMAN_$(@F))
OBJCOPYFLAGS_u-boot.ldr.hex := -I binary -O ihex
--
2.35.3
Re: [PATCH v4 11/11] configs: starfive: Enable ID EEPROM configuration
On 25.05.23 11:36, Yanhong Wang wrote:
> Enabled ID_EEPROM and I2C configuration for StarFive VisionFive2 board.
>
> Signed-off-by: Yanhong Wang
> ---
> configs/starfive_visionfive2_defconfig | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/configs/starfive_visionfive2_defconfig
> b/configs/starfive_visionfive2_defconfig
> index c57708199d..570a1f53a1 100644
> --- a/configs/starfive_visionfive2_defconfig
> +++ b/configs/starfive_visionfive2_defconfig
> @@ -13,6 +13,7 @@ CONFIG_SYS_PROMPT="StarFive #"
> CONFIG_OF_LIBFDT_OVERLAY=y
> CONFIG_DM_RESET=y
> CONFIG_SPL_MMC=y
> +CONFIG_SPL_DRIVERS_MISC=y
> CONFIG_SPL_STACK=0x818
> CONFIG_SPL=y
> CONFIG_SPL_SPI_FLASH_SUPPORT=y
> @@ -23,6 +24,7 @@ CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000
> CONFIG_ARCH_RV64I=y
> CONFIG_CMODEL_MEDANY=y
> CONFIG_RISCV_SMODE=y
> +# CONFIG_OF_BOARD_FIXUP is not set
> CONFIG_FIT=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_QSPI_BOOT=y
> @@ -34,6 +36,8 @@ CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr
> ${fdtcontroladdr};"
> CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb"
> CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> +CONFIG_ID_EEPROM=y
> +CONFIG_SYS_EEPROM_BUS_NUM=5
> CONFIG_SPL_MAX_SIZE=0x4
> CONFIG_SPL_PAD_TO=0x0
> CONFIG_SPL_BSS_START_ADDR=0x804
> @@ -45,21 +49,34 @@ CONFIG_CUSTOM_SYS_SPL_MALLOC_ADDR=0x8000
> CONFIG_SYS_SPL_MALLOC_SIZE=0x40
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2
> +CONFIG_SPL_I2C=y
> CONFIG_SPL_DM_SPI_FLASH=y
> CONFIG_SPL_DM_RESET=y
> CONFIG_SPL_SPI_LOAD=y
> CONFIG_SYS_CBSIZE=256
> CONFIG_SYS_PBSIZE=276
> CONFIG_SYS_BOOTM_LEN=0x400
> +CONFIG_CMD_EEPROM=y
> +CONFIG_SYS_EEPROM_SIZE=512
> +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=4
> +CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=5
> CONFIG_CMD_MEMINFO=y
> +CONFIG_CMD_I2C=y
> CONFIG_CMD_TFTPPUT=y
> +CONFIG_OF_BOARD=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
> CONFIG_REGMAP=y
> CONFIG_SYSCON=y
> CONFIG_SPL_CLK_COMPOSITE_CCF=y
> CONFIG_CLK_COMPOSITE_CCF=y
> CONFIG_SPL_CLK_JH7110=y
> -# CONFIG_I2C is not set
> +CONFIG_DM_I2C=y
> +CONFIG_SYS_I2C_DW=y
> +CONFIG_MISC=y
> +CONFIG_I2C_EEPROM=y
> +CONFIG_SPL_I2C_EEPROM=y
> +CONFIG_SYS_I2C_EEPROM_ADDR=0X50
> CONFIG_MMC_HS400_SUPPORT=y
> CONFIG_SPL_MMC_HS400_SUPPORT=y
> CONFIG_MMC_DW=y
This comes too late: Already patch 4 needs at least CONFIG_ID_EEPROM=y,
if not more.
Make sure you don't leave non-bisectable commit series behind. Whenever
something breaks (like 55171aedda88), people will use bisection to find
the causing commit, and then they will appreciate not having to deal
with such hick-ups.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v4 10/11] configs: starfive: Enable ethernet configuration for StarFive VisionFive2
On 25.05.23 11:36, Yanhong Wang wrote:
> Enable DWC_ETH_QOS and PHY_MOTORCOMM configuration to support ethernet
> function for StarFive VisionFive 2 board,including versions 1.2A and
> 1.3B.
>
> Signed-off-by: Yanhong Wang
> ---
> configs/starfive_visionfive2_defconfig | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/configs/starfive_visionfive2_defconfig
> b/configs/starfive_visionfive2_defconfig
> index ffbc4b9476..c57708199d 100644
> --- a/configs/starfive_visionfive2_defconfig
> +++ b/configs/starfive_visionfive2_defconfig
> @@ -7,7 +7,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8000
> CONFIG_SF_DEFAULT_SPEED=1
> CONFIG_SPL_DM_SPI=y
> -CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2-v1.3b"
> +CONFIG_DEFAULT_DEVICE_TREE="jh7110-starfive-visionfive-2"
> CONFIG_SPL_TEXT_BASE=0x800
> CONFIG_SYS_PROMPT="StarFive #"
> CONFIG_OF_LIBFDT_OVERLAY=y
> @@ -31,7 +31,7 @@ CONFIG_USE_BOOTARGS=y
> CONFIG_BOOTARGS="console=ttyS0,115200 debug rootwait earlycon=sbi"
> CONFIG_USE_PREBOOT=y
> CONFIG_PREBOOT="setenv fdt_addr ${fdtcontroladdr};fdt addr
> ${fdtcontroladdr};"
> -CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2-v1.3b.dtb"
> +CONFIG_DEFAULT_FDT_FILE="starfive/jh7110-starfive-visionfive-2.dtb"
These two hunks belong into patch 7.
Jan
> CONFIG_DISPLAY_CPUINFO=y
> CONFIG_DISPLAY_BOARDINFO=y
> CONFIG_SPL_MAX_SIZE=0x4
> @@ -54,6 +54,8 @@ CONFIG_SYS_BOOTM_LEN=0x400
> CONFIG_CMD_MEMINFO=y
> CONFIG_CMD_TFTPPUT=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_REGMAP=y
> +CONFIG_SYSCON=y
> CONFIG_SPL_CLK_COMPOSITE_CCF=y
> CONFIG_CLK_COMPOSITE_CCF=y
> CONFIG_SPL_CLK_JH7110=y
> @@ -66,6 +68,13 @@ CONFIG_SPI_FLASH_EON=y
> CONFIG_SPI_FLASH_GIGADEVICE=y
> CONFIG_SPI_FLASH_ISSI=y
> CONFIG_SPI_FLASH_MACRONIX=y
> +CONFIG_PHY_MOTORCOMM=y
> +CONFIG_DM_MDIO=y
> +CONFIG_DM_ETH_PHY=y
> +CONFIG_DWC_ETH_QOS=y
> +CONFIG_DWC_ETH_QOS_STARFIVE=y
> +CONFIG_RGMII=y
> +CONFIG_RMII=y
> CONFIG_PINCTRL=y
> CONFIG_PINCONF=y
> CONFIG_SPL_PINCTRL=y
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH v3 01/17] dm: Emit the arch_cpu_init_dm() even only before relocation
On 05.05.23 00:50, Simon Glass wrote:
> The original function was only called once, before relocation. The new
> one is called again after relocation. This was not the intent of the
> original call. Fix this by renaming and updating the calling logic.
>
> With this, chromebook_link64 makes it through SPL.
>
> Fixes: 7fe32b3442f ("event: Convert arch_cpu_init_dm() to")
> Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events")
> Reviewed-by: Bin Meng
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Fix 'intend' typo
>
> arch/arm/mach-imx/imx8/cpu.c| 2 +-
> arch/arm/mach-imx/imx8m/soc.c | 2 +-
> arch/arm/mach-imx/imx8ulp/soc.c | 2 +-
> arch/arm/mach-imx/imx9/soc.c| 2 +-
> arch/arm/mach-omap2/am33xx/board.c | 2 +-
> arch/arm/mach-omap2/hwinit-common.c | 2 +-
> arch/mips/mach-pic32/cpu.c | 2 +-
> arch/nios2/cpu/cpu.c| 2 +-
> arch/riscv/cpu/cpu.c| 2 +-
> arch/x86/cpu/baytrail/cpu.c | 2 +-
> arch/x86/cpu/broadwell/cpu.c| 2 +-
> arch/x86/cpu/ivybridge/cpu.c| 2 +-
> arch/x86/cpu/quark/quark.c | 2 +-
> arch/x86/lib/fsp2/fsp_init.c| 2 +-
> doc/develop/event.rst | 6 +++---
> drivers/core/root.c | 4 ++--
> drivers/cpu/microblaze_cpu.c| 2 +-
> include/event.h | 2 +-
> 18 files changed, 21 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
> index be1f4edded1..99772f68c32 100644
> --- a/arch/arm/mach-imx/imx8/cpu.c
> +++ b/arch/arm/mach-imx/imx8/cpu.c
> @@ -89,7 +89,7 @@ static int imx8_init_mu(void *ctx, struct event *event)
>
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT, imx8_init_mu);
> +EVENT_SPY(EVT_DM_POST_INIT_F, imx8_init_mu);
>
> #if defined(CONFIG_ARCH_MISC_INIT)
> int arch_misc_init(void)
> diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> index 4705e6c1192..5a4f8358c9f 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -549,7 +549,7 @@ static int imx8m_check_clock(void *ctx, struct event
> *event)
>
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT, imx8m_check_clock);
> +EVENT_SPY(EVT_DM_POST_INIT_F, imx8m_check_clock);
>
> static void imx8m_setup_snvs(void)
> {
> diff --git a/arch/arm/mach-imx/imx8ulp/soc.c b/arch/arm/mach-imx/imx8ulp/soc.c
> index 8424332f429..81eae02b6a8 100644
> --- a/arch/arm/mach-imx/imx8ulp/soc.c
> +++ b/arch/arm/mach-imx/imx8ulp/soc.c
> @@ -808,7 +808,7 @@ static int imx8ulp_evt_dm_post_init(void *ctx, struct
> event *event)
> {
> return imx8ulp_dm_post_init();
> }
> -EVENT_SPY(EVT_DM_POST_INIT, imx8ulp_evt_dm_post_init);
> +EVENT_SPY(EVT_DM_POST_INIT_F, imx8ulp_evt_dm_post_init);
>
> #if defined(CONFIG_SPL_BUILD)
> __weak void __noreturn jump_to_image_no_args(struct spl_image_info
> *spl_image)
> diff --git a/arch/arm/mach-imx/imx9/soc.c b/arch/arm/mach-imx/imx9/soc.c
> index a16e22ea6bb..252663a9eec 100644
> --- a/arch/arm/mach-imx/imx9/soc.c
> +++ b/arch/arm/mach-imx/imx9/soc.c
> @@ -262,7 +262,7 @@ int imx9_probe_mu(void *ctx, struct event *event)
>
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT, imx9_probe_mu);
> +EVENT_SPY(EVT_DM_POST_INIT_F, imx9_probe_mu);
>
> int timer_init(void)
> {
> diff --git a/arch/arm/mach-omap2/am33xx/board.c
> b/arch/arm/mach-omap2/am33xx/board.c
> index a52d04d85c8..ecc0a592e99 100644
> --- a/arch/arm/mach-omap2/am33xx/board.c
> +++ b/arch/arm/mach-omap2/am33xx/board.c
> @@ -535,4 +535,4 @@ static int am33xx_dm_post_init(void *ctx, struct event
> *event)
> #endif
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT, am33xx_dm_post_init);
> +EVENT_SPY(EVT_DM_POST_INIT_F, am33xx_dm_post_init);
> diff --git a/arch/arm/mach-omap2/hwinit-common.c
> b/arch/arm/mach-omap2/hwinit-common.c
> index c4a8eabc3eb..771533394bc 100644
> --- a/arch/arm/mach-omap2/hwinit-common.c
> +++ b/arch/arm/mach-omap2/hwinit-common.c
> @@ -246,7 +246,7 @@ static int omap2_system_init(void *ctx, struct event
> *event)
>
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT, omap2_system_init);
> +EVENT_SPY(EVT_DM_POST_INIT_F, omap2_system_init);
>
> /*
> * Routine: wait_for_command_complete
> diff --git a/arch/mips/mach-pic32/cpu.c b/arch/mips/mach-pic32/cpu.c
> index de449e3c6a2..ec3c2505313 100644
> --- a/arch/mips/mach-pic32/cpu.c
> +++ b/arch/mips/mach-pic32/cpu.c
> @@ -102,7 +102,7 @@ static int pic32_flash_prefetch(void *ctx, struct event
> *event)
> prefetch_init();
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT, pic32_flash_prefetch);
> +EVENT_SPY(EVT_DM_POST_INIT_F, pic32_flash_prefetch);
>
> /* Un-gate DDR2 modules (gated by default) */
> static void ddr2_pmd_ungate(void)
> diff --git a/arch/nios2/cpu/cpu.c b/arch/nios2/cpu/cpu.c
> index 85544503a5e..da167f4b29e 100644
> --- a/arch/nios2/cpu/cpu.c
> +++ b/arch/nios2/cpu/cpu.c
> @@ -80,7 +80,7 @@ static
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 08.05.23 07:05, Neha Malcom Francis wrote: > Hi Jan, > > On 07/05/23 17:41, Jan Kiszka wrote: >> On 04.05.23 08:13, Neha Malcom Francis wrote: >>> Hi Jan >>> >>> On 04/05/23 10:13, Neha Malcom Francis wrote: >>>> Hi Jan, >>>> >>>> On 03/05/23 22:04, Jan Kiszka wrote: >>>>> On 03.05.23 14:56, Neha Malcom Francis wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 03/05/23 12:57, Neha Malcom Francis wrote: >>>>>>> Hi Tom >>>>>>> >>>>>>> On 27/04/23 04:07, Tom Rini wrote: >>>>>>>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This series aims to eliminate the use of additional custom >>>>>>>>> repositories >>>>>>>>> such as k3-image-gen (K3 Image Generation) repo and >>>>>>>>> core-secdev-k3 (K3 >>>>>>>>> Security Development Tools) that was plumbed into the U-Boot >>>>>>>>> build flow >>>>>>>>> to generate boot images for TI K3 platform devices. And >>>>>>>>> instead, we >>>>>>>>> move >>>>>>>>> towards using binman that aligns better with the community >>>>>>>>> standard >>>>>>>>> build >>>>>>>>> flow. >>>>>>>>> >>>>>>>>> This series uses binman for all K3 platforms supported on U-Boot >>>>>>>>> currently; >>>>>>>>> both HS (High Security, both SE and FS) and GP (General Purpose) >>>>>>>>> devices. >>>>>>>>> >>>>>>>>> Background on using k3-image-gen: >>>>>>>>> * TI K3 devices require a SYSFW (System Firmware) image >>>>>>>>> consisting >>>>>>>>> of a signed system firmware image and board configuration >>>>>>>>> binaries, >>>>>>>>> this is needed to bring up system firmware during U-Boot >>>>>>>>> R5 SPL >>>>>>>>> startup. >>>>>>>>> * Board configuration data contain board-specific >>>>>>>>> information >>>>>>>>> such as resource management, power management and security. >>>>>>>>> >>>>>>>>> Background on using core-secdev-k3: >>>>>>>>> * Contains resources to sign x509 certificates for HS >>>>>>>>> devices >>>>>>>>> >>>>>>>>> Series intends to use binman to take over the packaging and >>>>>>>>> signing for >>>>>>>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>>>>>>>> non-combined >>>>>>>>> boot flow) instead of k3-image-gen. >>>>>>>>> >>>>>>>>> Series also packages the A72/A53 bootloader images (tispl.bin and >>>>>>>>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >>>>>>>> >>>>>>>> So, next up is fixing this in CI. After taking Andrew's patch to >>>>>>>> fix the >>>>>>>> typedef issue, and after my patches to ensure we can get >>>>>>>> pyyaml/jsonschema for python, there's problems still: >>>>>>> >>>>>>> >>>>>>> Thanks for checking this! Couple things: >>>>>>> >>>>>>>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>>>>>>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >>>>>>>> input >>>>>>>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>>>>>>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >>>>>>> >>>>>>> 1. This is dependent on the patch merging J721S2 HS and GP configs >>>>>>> [1]. However it has been reverted on -next, seen in the same thread. >>>>>>> >>>>>>>> >>>>>>>>
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 04.05.23 08:13, Neha Malcom Francis wrote: > Hi Jan > > On 04/05/23 10:13, Neha Malcom Francis wrote: >> Hi Jan, >> >> On 03/05/23 22:04, Jan Kiszka wrote: >>> On 03.05.23 14:56, Neha Malcom Francis wrote: >>>> Hi Jan, >>>> >>>> On 03/05/23 12:57, Neha Malcom Francis wrote: >>>>> Hi Tom >>>>> >>>>> On 27/04/23 04:07, Tom Rini wrote: >>>>>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>>>>> >>>>>>> This series aims to eliminate the use of additional custom >>>>>>> repositories >>>>>>> such as k3-image-gen (K3 Image Generation) repo and >>>>>>> core-secdev-k3 (K3 >>>>>>> Security Development Tools) that was plumbed into the U-Boot >>>>>>> build flow >>>>>>> to generate boot images for TI K3 platform devices. And instead, we >>>>>>> move >>>>>>> towards using binman that aligns better with the community standard >>>>>>> build >>>>>>> flow. >>>>>>> >>>>>>> This series uses binman for all K3 platforms supported on U-Boot >>>>>>> currently; >>>>>>> both HS (High Security, both SE and FS) and GP (General Purpose) >>>>>>> devices. >>>>>>> >>>>>>> Background on using k3-image-gen: >>>>>>> * TI K3 devices require a SYSFW (System Firmware) image >>>>>>> consisting >>>>>>> of a signed system firmware image and board configuration >>>>>>> binaries, >>>>>>> this is needed to bring up system firmware during U-Boot R5 SPL >>>>>>> startup. >>>>>>> * Board configuration data contain board-specific information >>>>>>> such as resource management, power management and security. >>>>>>> >>>>>>> Background on using core-secdev-k3: >>>>>>> * Contains resources to sign x509 certificates for HS devices >>>>>>> >>>>>>> Series intends to use binman to take over the packaging and >>>>>>> signing for >>>>>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>>>>>> non-combined >>>>>>> boot flow) instead of k3-image-gen. >>>>>>> >>>>>>> Series also packages the A72/A53 bootloader images (tispl.bin and >>>>>>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >>>>>> >>>>>> So, next up is fixing this in CI. After taking Andrew's patch to >>>>>> fix the >>>>>> typedef issue, and after my patches to ensure we can get >>>>>> pyyaml/jsonschema for python, there's problems still: >>>>> >>>>> >>>>> Thanks for checking this! Couple things: >>>>> >>>>>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>>>>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >>>>>> input >>>>>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>>>>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >>>>> >>>>> 1. This is dependent on the patch merging J721S2 HS and GP configs >>>>> [1]. However it has been reverted on -next, seen in the same thread. >>>>> >>>>>> >>>>>> And then: >>>>>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>>>>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>>>>> I've fixed this, minor but serious change. >>>>> >>>>> 2. Regarding iot2050, build fails since it uses >>>>> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >>>>> try moving iot2050 to binman as well. >>>> >>>> I'll need some help with this, might need to know the bootloader >>>> flow to >>>> make a clean migration. >>> >>> Where do I have to look at? Is there a git repo with that experiment >>> somewhere? >>> >>> Jan >>> >> >> There's no experiment yet, I will send one today; but I do not have >> complete understanding of the booting
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 04.05.23 08:13, Neha Malcom Francis wrote: > Hi Jan > > On 04/05/23 10:13, Neha Malcom Francis wrote: >> Hi Jan, >> >> On 03/05/23 22:04, Jan Kiszka wrote: >>> On 03.05.23 14:56, Neha Malcom Francis wrote: >>>> Hi Jan, >>>> >>>> On 03/05/23 12:57, Neha Malcom Francis wrote: >>>>> Hi Tom >>>>> >>>>> On 27/04/23 04:07, Tom Rini wrote: >>>>>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>>>>> >>>>>>> This series aims to eliminate the use of additional custom >>>>>>> repositories >>>>>>> such as k3-image-gen (K3 Image Generation) repo and >>>>>>> core-secdev-k3 (K3 >>>>>>> Security Development Tools) that was plumbed into the U-Boot >>>>>>> build flow >>>>>>> to generate boot images for TI K3 platform devices. And instead, we >>>>>>> move >>>>>>> towards using binman that aligns better with the community standard >>>>>>> build >>>>>>> flow. >>>>>>> >>>>>>> This series uses binman for all K3 platforms supported on U-Boot >>>>>>> currently; >>>>>>> both HS (High Security, both SE and FS) and GP (General Purpose) >>>>>>> devices. >>>>>>> >>>>>>> Background on using k3-image-gen: >>>>>>> * TI K3 devices require a SYSFW (System Firmware) image >>>>>>> consisting >>>>>>> of a signed system firmware image and board configuration >>>>>>> binaries, >>>>>>> this is needed to bring up system firmware during U-Boot R5 SPL >>>>>>> startup. >>>>>>> * Board configuration data contain board-specific information >>>>>>> such as resource management, power management and security. >>>>>>> >>>>>>> Background on using core-secdev-k3: >>>>>>> * Contains resources to sign x509 certificates for HS devices >>>>>>> >>>>>>> Series intends to use binman to take over the packaging and >>>>>>> signing for >>>>>>> the R5 bootloader images tiboot3.bin (and sysfw.itb, for >>>>>>> non-combined >>>>>>> boot flow) instead of k3-image-gen. >>>>>>> >>>>>>> Series also packages the A72/A53 bootloader images (tispl.bin and >>>>>>> u-boot.img) using ATF, OPTEE and DM (Device Manager) >>>>>> >>>>>> So, next up is fixing this in CI. After taking Andrew's patch to >>>>>> fix the >>>>>> typedef issue, and after my patches to ensure we can get >>>>>> pyyaml/jsonschema for python, there's problems still: >>>>> >>>>> >>>>> Thanks for checking this! Couple things: >>>>> >>>>>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>>>>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in >>>>>> input >>>>>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>>>>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >>>>> >>>>> 1. This is dependent on the patch merging J721S2 HS and GP configs >>>>> [1]. However it has been reverted on -next, seen in the same thread. >>>>> >>>>>> >>>>>> And then: >>>>>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>>>>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>>>>> I've fixed this, minor but serious change. >>>>> >>>>> 2. Regarding iot2050, build fails since it uses >>>>> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >>>>> try moving iot2050 to binman as well. >>>> >>>> I'll need some help with this, might need to know the bootloader >>>> flow to >>>> make a clean migration. >>> >>> Where do I have to look at? Is there a git repo with that experiment >>> somewhere? >>> >>> Jan >>> >> >> There's no experiment yet, I will send one today; but I do not have >> complete understanding of the booting; whether the tispl.bin (which I >> assume is the only boot component that is affecting iot2050 boot since >> k3_fit_atf.sh is no longer there) has any concept of signing? Is >> core-secdev-k3 ever used? >> > > I have a tree posted here [2] that builds flash.bin with no error for > me. Please confirm whether your build flow does the same and also let me > know if the binary actually boots. > > [2] > https://github.com/nehamalcom/u-boot/tree/migration-to-binman-cicd-iot2050 > FWIW, dependencies, signing procedure etc. are all documented in u-boot/doc/board/siemens/iot2050.rst. I will try to have a look at that patch as well. Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH v3 00/19] Migration to using binman for bootloader
On 03.05.23 14:56, Neha Malcom Francis wrote: > Hi Jan, > > On 03/05/23 12:57, Neha Malcom Francis wrote: >> Hi Tom >> >> On 27/04/23 04:07, Tom Rini wrote: >>> On Fri, Apr 21, 2023 at 06:01:44PM +0530, Neha Malcom Francis wrote: >>> This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) >>> >>> So, next up is fixing this in CI. After taking Andrew's patch to fix the >>> typedef issue, and after my patches to ensure we can get >>> pyyaml/jsonschema for python, there's problems still: >> >> >> Thanks for checking this! Couple things: >> >>> Over at https://source.denx.de/u-boot/u-boot/-/jobs/617966: >>> binman: Filename 'spl/dts/k3-am68-sk-base-board.dtb' not found in input >>> path (.,/builds/u-boot/u-boot,board/ti/j721s2,arch/arm/dts) >>> (cwd='/tmp/.bm-work/j721s2_hs_evm_a72') >> >> 1. This is dependent on the patch merging J721S2 HS and GP configs >> [1]. However it has been reverted on -next, seen in the same thread. >> >>> >>> And then: >>> https://source.denx.de/u-boot/u-boot/-/jobs/617965#L1328 >>> Error: arch/arm/dts/k3-am62a-sk-binman.dtsi:167.1-8 syntax error >>> I've fixed this, minor but serious change. >> >> 2. Regarding iot2050, build fails since it uses >> arch/arm/mach-k3/config.mk which is now entirely binman based. Will >> try moving iot2050 to binman as well. > > I'll need some help with this, might need to know the bootloader flow to > make a clean migration. Where do I have to look at? Is there a git repo with that experiment somewhere? Jan -- Siemens AG, Technology Competence Center Embedded Linux
[PATCH] arm: dts: iot2050: Include u-boot specific bits implicitly
From: Jan Kiszka
Create *-u-boot.dtsi files for each target dtb of the IOT2050 series so
that we can drop the #include deviations from upstream dts[i] files
here.
Signed-off-by: Jan Kiszka
---
This was tested against most of our boards with the DTS synced from
kernel 6.3.
arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi | 2 --
arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi | 3 ---
arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi | 11 +++
arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi | 10 ++
arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi | 3 ---
.../arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi | 1 +
.../dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi| 1 +
arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi | 1 +
8 files changed, 24 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi
create mode 100644 arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi
create mode 12 arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi
create mode 12 arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi
create mode 12 arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi
diff --git a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
index e7e0ca41597..e73458ca690 100644
--- a/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-common-pg2.dtsi
@@ -49,5 +49,3 @@
snps,dis-u1-entry-quirk;
snps,dis-u2-entry-quirk;
};
-
-#include "k3-am65-iot2050-common-pg2-u-boot.dtsi"
diff --git a/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi
b/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi
index 0d215b4d668..4a9bf7d7c07 100644
--- a/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi
+++ b/arch/arm/dts/k3-am6528-iot2050-basic-common.dtsi
@@ -11,9 +11,6 @@
#include "k3-am65-iot2050-common.dtsi"
-#include "k3-am65-iot2050-common-u-boot.dtsi"
-#include "k3-am65-iot2050-boot-image.dtsi"
-
/ {
memory@8000 {
device_type = "memory";
diff --git a/arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi
b/arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi
new file mode 100644
index 000..1e393042ac0
--- /dev/null
+++ b/arch/arm/dts/k3-am6528-iot2050-basic-pg2-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2023
+ *
+ * Authors:
+ * Jan Kiszka
+ */
+
+#include "k3-am65-iot2050-common-u-boot.dtsi"
+#include "k3-am65-iot2050-common-pg2-u-boot.dtsi"
+#include "k3-am65-iot2050-boot-image.dtsi"
diff --git a/arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi
b/arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi
new file mode 100644
index 000..64afe25e38f
--- /dev/null
+++ b/arch/arm/dts/k3-am6528-iot2050-basic-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2023
+ *
+ * Authors:
+ * Jan Kiszka
+ */
+
+#include "k3-am65-iot2050-common-u-boot.dtsi"
+#include "k3-am65-iot2050-boot-image.dtsi"
diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi
b/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi
index 816a4cb4a68..d25e8b26187 100644
--- a/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi
+++ b/arch/arm/dts/k3-am6548-iot2050-advanced-common.dtsi
@@ -13,9 +13,6 @@
#include "k3-am65-iot2050-common.dtsi"
-#include "k3-am65-iot2050-common-u-boot.dtsi"
-#include "k3-am65-iot2050-boot-image.dtsi"
-
/ {
memory@8000 {
device_type = "memory";
diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi
b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi
new file mode 12
index 000..859776d3ffe
--- /dev/null
+++ b/arch/arm/dts/k3-am6548-iot2050-advanced-m2-u-boot.dtsi
@@ -0,0 +1 @@
+k3-am6528-iot2050-basic-pg2-u-boot.dtsi
\ No newline at end of file
diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi
b/arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi
new file mode 12
index 000..859776d3ffe
--- /dev/null
+++ b/arch/arm/dts/k3-am6548-iot2050-advanced-pg2-u-boot.dtsi
@@ -0,0 +1 @@
+k3-am6528-iot2050-basic-pg2-u-boot.dtsi
\ No newline at end of file
diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi
b/arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi
new file mode 12
index 000..ac30e4ef46e
--- /dev/null
+++ b/arch/arm/dts/k3-am6548-iot2050-advanced-u-boot.dtsi
@@ -0,0 +1 @@
+k3-am6528-iot2050-basic-u-boot.dtsi
\ No newline at end of file
--
2.35.3
[PATCH] tools: Fall back to importlib_resources on Python 3.6
From: Jan Kiszka importlib.resources became part of 3.7 only. Allow using distros with 3.6 and the importlib_resources backport. Signed-off-by: Jan Kiszka --- Tested on OpenSUSE 15.4 with importlib_resources 1.1.0. tools/binman/control.py | 6 +- tools/buildman/control.py | 6 +- tools/patman/__main__.py | 6 +- 3 files changed, 15 insertions(+), 3 deletions(-) diff --git a/tools/binman/control.py b/tools/binman/control.py index 0febcb79a60..68597c4e779 100644 --- a/tools/binman/control.py +++ b/tools/binman/control.py @@ -7,7 +7,11 @@ from collections import OrderedDict import glob -import importlib.resources +try: +import importlib.resources +except ImportError: +# for Python 3.6 +import importlib_resources import os import pkg_resources import re diff --git a/tools/buildman/control.py b/tools/buildman/control.py index 35f44c0cf3d..09a11f25b3f 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -3,7 +3,11 @@ # import multiprocessing -import importlib.resources +try: +import importlib.resources +except ImportError: +# for Python 3.6 +import importlib_resources import os import shutil import subprocess diff --git a/tools/patman/__main__.py b/tools/patman/__main__.py index 48ffbc8eadf..8eba5d34864 100755 --- a/tools/patman/__main__.py +++ b/tools/patman/__main__.py @@ -7,7 +7,11 @@ """See README for more information""" from argparse import ArgumentParser -import importlib.resources +try: +import importlib.resources +except ImportError: +# for Python 3.6 +import importlib_resources import os import re import sys -- 2.35.3
Re: [PATCH V7 04/15] iot2050: Migrate settings into board env file
On 02.03.23 00:38, Simon Glass wrote: > Hi Jan, > > On Tue, 28 Feb 2023 at 11:20, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> Anything that is not boot-env related is better kept there by now. >> >> At this chance, also drop a stale comment from iot2050.h >> >> Signed-off-by: Jan Kiszka >> --- >> board/siemens/iot2050/iot2050.env | 9 + >> include/configs/iot2050.h | 11 ++- >> 2 files changed, 11 insertions(+), 9 deletions(-) >> create mode 100644 board/siemens/iot2050/iot2050.env >> >> diff --git a/board/siemens/iot2050/iot2050.env >> b/board/siemens/iot2050/iot2050.env >> new file mode 100644 >> index 000..4bd93f0b2f4 >> --- /dev/null >> +++ b/board/siemens/iot2050/iot2050.env >> @@ -0,0 +1,9 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (c) Siemens AG, 2023 >> + * >> + * Authors: >> + * Jan Kiszka >> + */ >> + >> +usb_pgood_delay=900 >> diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h >> index cfff46ce339..8dfeaddf541 100644 >> --- a/include/configs/iot2050.h >> +++ b/include/configs/iot2050.h >> @@ -13,12 +13,6 @@ >> >> #include >> >> -/* SPL Loader Configuration */ >> - >> -/* U-Boot general configuration */ >> -#define EXTRA_ENV_IOT2050_BOARD_SETTINGS \ >> - "usb_pgood_delay=900\0" >> - >> #if IS_ENABLED(CONFIG_CMD_USB) >> # define BOOT_TARGET_USB(func) \ >> func(USB, usb, 0) \ >> @@ -40,10 +34,9 @@ >> >> #include >> >> -#define CFG_EXTRA_ENV_SETTINGS \ >> +#define CFG_EXTRA_ENV_SETTINGS \ >> DEFAULT_LINUX_BOOT_ENV \ >> - BOOTENV \ >> - EXTRA_ENV_IOT2050_BOARD_SETTINGS >> + BOOTENV >> >> #include >> >> -- >> 2.35.3 >> > > You might want to move to standard boot so you can use a text-based > environment. See for example [1] [2] and later patches from [3]. > Err, this patch is about introducing a text-based env for the parts that can be moved. I don't see a relevant delta after this patch to the referenced examples (btw, [2] is missing). Jan > Regards, > Simon > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=342718 > [2] > [3] from > https://patchwork.ozlabs.org/project/uboot/list/?series=338993=* -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH V7 15/15] iot2050: Add support for configuring M.2 connector
On 02.03.23 00:38, Simon Glass wrote: > Hi Jan, > > On Tue, 28 Feb 2023 at 11:23, Jan Kiszka wrote: >> >> From: Jan Kiszka >> >> The M.2 slots of the related IOT2050 variant need to be configured >> according to the plugged cards. This tries to detect the card using the >> M.2 configuration pins of the B-key slot. If that fails, a U-Boot >> environment variable can be set to configure manually. This variable is >> write-permitted also in secure boot mode as it is not able to undermine >> the integrity of the booted system. >> >> The configuration is then applied to mux the serdes and to fix up the >> device tree passed to or loaded by the bootloader. The fix-ups are >> coming from device tree overlays that are embedded into the firmware >> image and there also integrity protected. The OS remains free to load >> a device tree to which they do not apply: U-Boot will not fail to boot >> in that case. >> >> Based on original patch by Chao Zeng. >> >> Signed-off-by: Jan Kiszka >> --- >> arch/arm/dts/Makefile | 4 +- >> arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 38 ++- >> ...050-advanced-m2-bkey-ekey-pcie-overlay.dts | 27 ++ >> ...-iot2050-advanced-m2-bkey-usb3-overlay.dts | 47 >> board/siemens/iot2050/board.c | 259 +- >> doc/board/siemens/iot2050.rst | 18 ++ >> include/configs/iot2050.h | 1 + >> 7 files changed, 391 insertions(+), 3 deletions(-) >> create mode 100644 >> arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts >> create mode 100644 >> arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts > > There is an 'extension' command and associated infra available. To my understanding, this is about scripting, open-coding extension detection and overlay application. Here we are making this automatic. Also, we are not really detecting an extension board, more the used connector. struct extension therefore does not really fit. > Also > there is sysinfo. I just wanted to check if either of those is helpful > here. This might save a handful of lines of own code around gpio parsing. We will have a look on top of this. Thanks, Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH V7 01/15] board: siemens: iot2050: Split the build for PG1 and PG2
On 01.03.23 19:34, Andrew Davis wrote:
> On 3/1/23 12:29 PM, Jan Kiszka wrote:
>> On 01.03.23 18:26, Andrew Davis wrote:
>>> On 2/28/23 12:19 PM, Jan Kiszka wrote:
>>>> From: Su Baocheng
>>>>
>>>> Due to different signature keys, the PG1 and the PG2 boards can no
>>>> longer use the same FSBL (tiboot3). This makes it impossible anyway to
>>>> maintaine a single flash.bin for both variants, so we can also split
>>>> the
>>>> build.
>>>>
>>>
>>> Having two defconfigs just to make the small changes needed will be
>>> more burden than it saves. Keeping them in sync and having your
>>> integration
>>> layer do two different builds just adds more work than it is worth IMHO.
>>>
>>> We (TI) are going in that direction for our HS boards and combining the
>>> defconfigs back together now. The solution is to have the one defconfig
>>> build both images, one for HS and one for non-HS. For you looks like you
>>> are already calling the two PG boot images differently so this should
>>> work
>>> (seboot_pg1.bin and seboot_pg2.bin). Just add a new full entry in
>>> boot-image.dtsi for each (vs that #ifdef check changing the output
>>> name).
>>
>> How should that work? Will we somehow get two flash.bin out of a single
>> build then?
>>
>
> Yes if you add two enteries in your image.dtsi file. Then your integration
> selects the right named one for the board, instead of selecting the right
> defconfig for the board and doing a completely new build.
Something like this?
binman: binman {
multiple-images;
};
{
flash-pg1 {
filename = "flash-pg1.bin"
...
};
flash-pg2 {
filename = "flash-pg2.bin"
...
};
};
How to avoid duplicating the common nodes of flash-pg1/pg2?
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH V7 01/15] board: siemens: iot2050: Split the build for PG1 and PG2
On 01.03.23 18:26, Andrew Davis wrote: > On 2/28/23 12:19 PM, Jan Kiszka wrote: >> From: Su Baocheng >> >> Due to different signature keys, the PG1 and the PG2 boards can no >> longer use the same FSBL (tiboot3). This makes it impossible anyway to >> maintaine a single flash.bin for both variants, so we can also split the >> build. >> > > Having two defconfigs just to make the small changes needed will be > more burden than it saves. Keeping them in sync and having your integration > layer do two different builds just adds more work than it is worth IMHO. > > We (TI) are going in that direction for our HS boards and combining the > defconfigs back together now. The solution is to have the one defconfig > build both images, one for HS and one for non-HS. For you looks like you > are already calling the two PG boot images differently so this should work > (seboot_pg1.bin and seboot_pg2.bin). Just add a new full entry in > boot-image.dtsi for each (vs that #ifdef check changing the output name). How should that work? Will we somehow get two flash.bin out of a single build then? Jan -- Siemens AG, Technology Competence Center Embedded Linux
[PATCH V7 14/15] arm: dts: iot2050: Add support for M.2 variant
From: chao zeng
Add support for the M.2 board based on the iot2050 advanced board.
The board has two m.2 connectors, one is B-keyed, the other E-keyed.
The B-key slot can connect 5G/SSD devices, and E-key can be used for
WIFI/BT devices.
This variant is covered by PG2 firmware image.
Signed-off-by: chao zeng
[Jan: align DT to kernel, polish wording]
Signed-off-by: Jan Kiszka
---
arch/arm/dts/Makefile | 3 +-
.../arm/dts/k3-am6548-iot2050-advanced-m2.dts | 121 ++
configs/iot2050_pg2_defconfig | 2 +-
doc/board/siemens/iot2050.rst | 6 +-
4 files changed, 128 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7a577deb502..8e9e2bf9a42 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1253,7 +1253,8 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
k3-am6528-iot2050-basic.dtb \
k3-am6528-iot2050-basic-pg2.dtb \
k3-am6548-iot2050-advanced.dtb \
- k3-am6548-iot2050-advanced-pg2.dtb
+ k3-am6548-iot2050-advanced-pg2.dtb \
+ k3-am6548-iot2050-advanced-m2.dtb
dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
k3-j721e-r5-common-proc-board.dtb \
k3-j7200-common-proc-board.dtb \
diff --git a/arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts
b/arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts
new file mode 100644
index 000..9400e35882a
--- /dev/null
+++ b/arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2023
+ *
+ * Authors:
+ * Chao Zeng
+ * Jan Kiszka
+ *
+ * AM6548-based (quad-core) IOT2050 M.2 variant (based on Advanced Product
+ * Generation 2), 2 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
+ *
+ * Product homepage:
+ *
https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
+ */
+
+#include "k3-am6548-iot2050-advanced-common.dtsi"
+#include "k3-am65-iot2050-common-pg2.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-advanced-m2", "ti,am654";
+ model = "SIMATIC IOT2050 Advanced M2";
+};
+
+_r5fss0 {
+ /* lock-step mode not supported on this board */
+ ti,cluster-mode = <0>;
+};
+
+_pmx0 {
+ main_m2_enable_pins_default: main-m2-enable-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01c4, PIN_INPUT_PULLUP, 7) /* (AH13)
GPIO1_17 */
+ >;
+ };
+
+ main_bkey_pcie_reset: main-bkey-pcie-reset {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01bc, PIN_OUTPUT_PULLUP, 7) /* (AG13)
GPIO1_15 */
+ >;
+ };
+
+ main_pmx0_m2_config_pins_default: main-pmx0-m2-config-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01c8, PIN_INPUT_PULLUP, 7) /* (AE13)
GPIO1_18 */
+ AM65X_IOPAD(0x01cc, PIN_INPUT_PULLUP, 7) /* (AD13)
GPIO1_19 */
+ >;
+ };
+
+ main_m2_pcie_mux_control: main-m2-pcie-mux-control {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0148, PIN_INPUT_PULLUP, 7) /* (AG22)
GPIO0_82 */
+ AM65X_IOPAD(0x0160, PIN_INPUT_PULLUP, 7) /* (AE20)
GPIO0_88 */
+ AM65X_IOPAD(0x0164, PIN_INPUT_PULLUP, 7) /* (AF19)
GPIO0_89 */
+ >;
+ };
+};
+
+_pmx1 {
+ main_pmx1_m2_config_pins_default: main-pmx1-m2-config-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0018, PIN_INPUT_PULLUP, 7) /* (B22)
GPIO1_88 */
+ AM65X_IOPAD(0x001c, PIN_INPUT_PULLUP, 7) /* (C23)
GPIO1_89 */
+ >;
+ };
+};
+
+_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _m2_pcie_mux_control
+ _io_d4_to_d9_pins_default
+ >;
+};
+
+_gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _m2_enable_pins_default
+ _pmx0_m2_config_pins_default
+ _pmx1_m2_config_pins_default
+ _reset_pin_default
+ >;
+};
+
+/*
+ * Base configuration for B-key slot with PCIe x2, E-key with USB 2.0 only.
+ * Firmware switches to other modes via device tree overlays.
+ */
+
+ {
+ assigned-clocks = <_clks 153 4>, < AM654_SERDES_CMU_REFCLK>;
+ assigned-clock-parents = <_clks 153 8>, <_clks 153 4>;
+};
+
+_rc {
+ pinctrl-names = "default";
+ pinctrl-0 = <_bkey_pcie_reset>;
+
+ num-lanes = <2>;
+ phys = < PHY_TYPE_PCIE 1>, < PHY_TYPE_PCIE 1>;
+ phy-names = "pcie
[PATCH V7 15/15] iot2050: Add support for configuring M.2 connector
From: Jan Kiszka
The M.2 slots of the related IOT2050 variant need to be configured
according to the plugged cards. This tries to detect the card using the
M.2 configuration pins of the B-key slot. If that fails, a U-Boot
environment variable can be set to configure manually. This variable is
write-permitted also in secure boot mode as it is not able to undermine
the integrity of the booted system.
The configuration is then applied to mux the serdes and to fix up the
device tree passed to or loaded by the bootloader. The fix-ups are
coming from device tree overlays that are embedded into the firmware
image and there also integrity protected. The OS remains free to load
a device tree to which they do not apply: U-Boot will not fail to boot
in that case.
Based on original patch by Chao Zeng.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/Makefile | 4 +-
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 38 ++-
...050-advanced-m2-bkey-ekey-pcie-overlay.dts | 27 ++
...-iot2050-advanced-m2-bkey-usb3-overlay.dts | 47
board/siemens/iot2050/board.c | 259 +-
doc/board/siemens/iot2050.rst | 18 ++
include/configs/iot2050.h | 1 +
7 files changed, 391 insertions(+), 3 deletions(-)
create mode 100644
arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts
create mode 100644
arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8e9e2bf9a42..0bfc69ecc86 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1254,7 +1254,9 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
k3-am6528-iot2050-basic-pg2.dtb \
k3-am6548-iot2050-advanced.dtb \
k3-am6548-iot2050-advanced-pg2.dtb \
- k3-am6548-iot2050-advanced-m2.dtb
+ k3-am6548-iot2050-advanced-m2.dtb \
+ k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo \
+ k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo
dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
k3-j721e-r5-common-proc-board.dtb \
k3-j7200-common-proc-board.dtb \
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index a2fc8bbc123..03ccc543293 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -61,6 +61,36 @@
};
};
+#ifdef CONFIG_TARGET_IOT2050_A53_PG2
+ bkey-usb3-overlay {
+ description = "M.2-bkey-usb3-overlay";
+ type = "blob";
+ load = <0x8210>;
+ arch = "arm64";
+ compression = "none";
+ blob-ext {
+ filename =
"k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dtbo";
+ };
+ hash {
+ algo = "sha256";
+ };
+ };
+
+ bkey-ekey-pcie-overlay {
+ description =
"M.2-bkey-ekey-pcie-overlay";
+ type = "blob";
+ load = <0x8211>;
+ arch = "arm64";
+ compression = "none";
+ blob-ext {
+ filename =
"k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dtbo";
+ };
+ hash {
+ algo = "sha256";
+ };
+ };
+#endif
+
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
k3-rti-wdt-firmware {
type = "firmware";
@@ -84,9 +114,15 @@
description = "NAME";
firmware = "u-boot";
fdt = "fdt-SEQ";
+ loadables =
+#ifdef CONFIG_TARGET_IOT2050_A53_PG2
+ "bkey-usb3-overlay",
+ "bkey-ekey-pcie-overlay",
+#e
[PATCH V7 13/15] iot2050: Refresh defconfigs and activate CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN
From: Jan Kiszka This feature is desired on the platform. Signed-off-by: Jan Kiszka --- configs/iot2050_pg1_defconfig | 1 + configs/iot2050_pg2_defconfig | 5 + 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig index 258ad4c87e5..45c88fc134e 100644 --- a/configs/iot2050_pg1_defconfig +++ b/configs/iot2050_pg1_defconfig @@ -146,3 +146,4 @@ CONFIG_WDT=y CONFIG_WDT_K3_RTI=y CONFIG_WDT_K3_RTI_LOAD_FW=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig index 2ff360b0623..d2bdeab593b 100644 --- a/configs/iot2050_pg2_defconfig +++ b/configs/iot2050_pg2_defconfig @@ -25,11 +25,8 @@ CONFIG_ENV_OFFSET_REDUND=0x6a CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8010 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_SPL_LOAD_FIT=y -# CONFIG_USE_SPL_FIT_GENERATOR is not set CONFIG_OF_BOARD_SETUP=y CONFIG_BOOTSTAGE=y CONFIG_SHOW_BOOT_PROGRESS=y @@ -78,7 +75,6 @@ CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_DM=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_REGMAP=y @@ -150,3 +146,4 @@ CONFIG_WDT=y CONFIG_WDT_K3_RTI=y CONFIG_WDT_K3_RTI_LOAD_FW=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y -- 2.35.3
[PATCH V7 11/15] doc: iot2050: Add a note about the watchdog firmware
From: Jan Kiszka This is enabled by default, thus should be described as well. Signed-off-by: Jan Kiszka --- doc/board/siemens/iot2050.rst | 4 1 file changed, 4 insertions(+) diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst index cb49a0e36bf..efe94a448a9 100644 --- a/doc/board/siemens/iot2050.rst +++ b/doc/board/siemens/iot2050.rst @@ -27,6 +27,10 @@ The following binaries from that source need to be present in the build folder: - seboot_pg1.bin - seboot_pg2.bin +When using the watchdog, a related firmware for the R5 core(s) is needed, e.g. +https://github.com/siemens/k3-rti-wdt. The name and location of the image is +configured via CONFIG_WDT_K3_RTI_FW_FILE. + For building an image containing the OTP key provisioning data, below binary needs to be present in the build folder: -- 2.35.3
[PATCH V7 10/15] arm: dts: iot2050: Optionally embed OTP programming data into image
From: Jan Kiszka
Use external blob otpcmd.bin to replace the 0xff filled OTP programming
command block to create a firmware image that provisions the OTP on
first boot. This otpcmd.bin is generated from the customer keys using
steps described in the meta-iot2050 integration layer for the device.
Based on original patch by Baocheng Su.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 9 +
board/siemens/iot2050/Kconfig| 7 +++
doc/board/siemens/iot2050.rst| 8
tools/binman/missing-blob-help | 8
4 files changed, 32 insertions(+)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 9082a79a034..a2fc8bbc123 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -111,10 +111,19 @@
};
/* OTP update command block */
+#if CONFIG_IOT2050_EMBED_OTPCMD
+ blob-ext@0x6c {
+ offset = <0x6c>;
+ size = <0x01>;
+ filename = "otpcmd.bin";
+ missing-msg = "iot2050-otpcmd";
+ };
+#else
fill@0x6c {
offset = <0x6c>;
size = <0x01>;
fill-byte = [ff];
};
+#endif
};
};
diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig
index a2b40881d11..e66b2427d95 100644
--- a/board/siemens/iot2050/Kconfig
+++ b/board/siemens/iot2050/Kconfig
@@ -49,4 +49,11 @@ config IOT2050_BOOT_SWITCH
bool "Disable eMMC boot via USER button (Advanced version only)"
default y
+config IOT2050_EMBED_OTPCMD
+ bool "Embed OTP programming data"
+ help
+ Embed signed OTP programming data 'otpcmd.bin' into the firmware
+ image. This data will be evaluated and executed on first boot of the
+ device.
+
endif
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 4e0925c72c9..cb49a0e36bf 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -27,6 +27,14 @@ The following binaries from that source need to be present
in the build folder:
- seboot_pg1.bin
- seboot_pg2.bin
+For building an image containing the OTP key provisioning data, below binary
+needs to be present in the build folder:
+
+ - otpcmd.bin
+
+Regarding how to generating this otpcmd.bin, please refer to:
+https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh
+
Building
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index 1a30da7b5aa..db16229f9f2 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -23,6 +23,14 @@ See the documentation for IOT2050 board. Your image is
missing SEBoot
which is mandatory for board startup. Prebuilt SEBoot located at
meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/seboot_pg*.bin.
+iot2050-otpcmd:
+See the documentation for IOT2050 board. Your image is missing OTP command data
+block which is used for provisioning the customer keys to the board.
+Please refer to
+meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh
+for how to generate this binary. If you are not using secure boot or do not
+intend to provision the keys, disable CONFIG_IOT2050_EMBED_OTPCMD.
+
k3-rti-wdt-firmware:
If CONFIG_WDT_K3_RTI_LOAD_FW is enabled, a firmware image is needed for
the R5F core(s) to trigger the system reset. One possible source is
--
2.35.3
[PATCH V7 08/15] tools: Add script for converting public key into device tree include
From: Jan Kiszka
Allows to create a public key device tree dtsi for inclusion into U-Boot
SPL and proper during first build already. This can be achieved via
CONFIG_DEVICE_TREE_INCLUDES.
Signed-off-by: Jan Kiszka
---
tools/key2dtsi.py | 64 +++
1 file changed, 64 insertions(+)
create mode 100755 tools/key2dtsi.py
diff --git a/tools/key2dtsi.py b/tools/key2dtsi.py
new file mode 100755
index 000..1dbb2cc94bf
--- /dev/null
+++ b/tools/key2dtsi.py
@@ -0,0 +1,64 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Public key to dtsi converter.
+#
+# Copyright (c) Siemens AG, 2022
+#
+
+from argparse import ArgumentParser, FileType
+from os.path import basename, splitext
+from Cryptodome.PublicKey import RSA
+from Cryptodome.Util.number import inverse
+
+def int_to_bytestr(n, length=None):
+if not length:
+length = (n.bit_length() + 7) // 8
+byte_array = n.to_bytes(length, 'big')
+return ' '.join(['{:02x}'.format(byte) for byte in byte_array])
+
+ap = ArgumentParser(description='Public key to dtsi converter')
+
+ap.add_argument('--hash', '-H', default='sha256',
+help='hash to be used with key (default: sha256)')
+ap.add_argument('--required-conf', '-c', action='store_true',
+help='mark key required for configuration')
+ap.add_argument('--required-image', '-i', action='store_true',
+help='mark key required for image')
+ap.add_argument('--spl', '-s', action='store_true',
+help='mark key for usage in SPL')
+ap.add_argument('key_file', metavar='KEY_FILE', type=FileType('r'),
+help='key file (formats: X.509, PKCS#1, OpenSSH)')
+ap.add_argument('dtsi_file', metavar='DTSI_FILE', type=FileType('w'),
+help='dtsi output file')
+
+args = ap.parse_args()
+
+key_name, _ = splitext(basename(args.key_file.name))
+
+key_data = args.key_file.read()
+key = RSA.importKey(key_data)
+
+r_squared = (2**key.size_in_bits())**2 % key.n
+n0_inverse = 2**32 - inverse(key.n, 2**32)
+
+out = args.dtsi_file
+out.write('/ {\n')
+out.write('\tsignature {\n')
+out.write('\t\tkey-{} {{\n'.format(key_name))
+out.write('\t\t\tkey-name-hint = "{}";\n'.format(key_name))
+out.write('\t\t\talgo = "{},rsa{}";\n'.format(args.hash, key.size_in_bits()))
+out.write('\t\t\trsa,num-bits = <{}>;\n'.format(key.size_in_bits()))
+out.write('\t\t\trsa,modulus = [{}];\n'.format(int_to_bytestr(key.n)))
+out.write('\t\t\trsa,exponent = [{}];\n'.format(int_to_bytestr(key.e, 8)))
+out.write('\t\t\trsa,r-squared = [{}];\n'.format(int_to_bytestr(r_squared)))
+out.write('\t\t\trsa,n0-inverse = <0x{:x}>;\n'.format(n0_inverse))
+if args.required_conf:
+out.write('\t\t\trequired = "conf";\n')
+elif args.required_image:
+out.write('\t\t\trequired = "image";\n')
+if args.spl:
+out.write('\t\t\tu-boot,dm-spl;\n')
+out.write('\t\t};\n')
+out.write('\t};\n')
+out.write('};\n')
--
2.35.3
[PATCH V7 09/15] iot2050: Add script for signing artifacts
From: Jan Kiszka
There are many ways to get a signed firmware for the IOT2050 devices,
namely for the parts under user-control. This script documents one way
of doing it, given a signing key. Augment the board documentation with
the required procedure around it.
Signed-off-by: Jan Kiszka
---
doc/board/siemens/iot2050.rst | 52 +++
tools/iot2050-sign-fw.sh | 51 ++
2 files changed, 103 insertions(+)
create mode 100755 tools/iot2050-sign-fw.sh
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 26972e20ae9..4e0925c72c9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -79,3 +79,55 @@ Via external programmer Dediprog SF100 or SF600:
.. code-block:: text
$ dpcmd --vcc 2 -v -u flash.bin
+
+Signing (optional)
+--
+
+To enable verified boot for the firmware artifacts after the Siemens-managed
+first-stage loader (seboot_pg*.bin), the following steps need to be taken
+before and after the build:
+
+Generate dtsi holding the public key
+
+
+.. code-block:: text
+
+ tools/key2dtsi.py -c -s key.pem public-key.dtsi
+
+This will be used to embed the public key into U-Boot SPL and main so that each
+step can validate signatures of the succeeding one.
+
+Adjust U-Boot configuration
+^^^
+
+Enabled at least the following options in U-Boot:
+
+.. code-block:: text
+
+ CONFIG_SPL_FIT_SIGNATURE=y
+ CONFIG_DEVICE_TREE_INCLUDES="/path/to/public-key.dtsi"
+ CONFIG_RSA=y
+
+Note that there are more configuration changes needed in order to lock-down
+the command line and the boot process of U-Boot for secure scenarios. These are
+not in scope here.
+
+Build U-Boot
+
+
+See related section above.
+
+Sign flash.bin
+^^
+
+In the build folder still containing artifacts from step 3, invoke:
+
+.. code-block:: text
+
+ tools/iot2050-sign-fw.sh /path/to/key.pem
+
+Flash signed flash.bin
+^^
+
+The signing has happen in-place in flash.bin, thus the flashing procedure
+described above.
diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh
new file mode 100755
index 000..4d1d79498c2
--- /dev/null
+++ b/tools/iot2050-sign-fw.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+if [ -z "$1" ]; then
+ echo "Usage: $0 KEY"
+ exit 1
+fi
+
+TEMP_X509=$(mktemp .temp)
+
+REVISION=${2:-0}
+SHA_VAL=$(openssl dgst -sha512 -hex tispl.bin | sed -e "s/^.*= //g")
+BIN_SIZE=$(stat -c %s tispl.bin)
+
+cat <$TEMP_X509
+[ req ]
+distinguished_name = req_distinguished_name
+x509_extensions= v3_ca
+prompt = no
+dirstring_type = nobmp
+
+[ req_distinguished_name ]
+CN = IOT2050 Firmware Signature
+
+[ v3_ca ]
+basicConstraints = CA:true
+1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
+1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity
+
+[ swrv ]
+swrv = INTEGER:$REVISION
+
+[ sysfw_image_integrity ]
+shaType= OID:2.16.840.1.101.3.4.2.3
+shaValue = FORMAT:HEX,OCT:$SHA_VAL
+imageSize = INTEGER:$BIN_SIZE
+EOF
+
+CERT_X509=$(mktemp .crt)
+
+openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config
$TEMP_X509 -sha512
+cat $CERT_X509 tispl.bin > tispl.bin_signed
+# currently broken in upstream
+#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed
blob@0x18
+dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x18/0x1000))
conv=notrunc
+
+rm $TEMP_X509 $CERT_X509
+
+tools/mkimage -G $1 -r -o sha256,rsa4096 -F f...@0x38.fit
+# currently broken in upstream
+#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit
fit@0x38
+dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) seek=$((0x38/0x1000))
conv=notrunc
--
2.35.3
[PATCH V7 12/15] board: siemens: iot2050: use the named gpio to control the user-button
From: chao zeng
User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.
To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.
Signed-off-by: chao zeng
---
board/siemens/iot2050/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index 57d7009e8c7..2735ae3fb74 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -183,7 +183,7 @@ static bool user_button_pressed(void)
memset(, 0, sizeof(gpio));
- if (dm_gpio_lookup_name("25", ) < 0 ||
+ if (dm_gpio_lookup_name("gpio@4211_25", ) < 0 ||
dm_gpio_request(, "USER button") < 0 ||
dm_gpio_set_dir_flags(, GPIOD_IS_IN) < 0)
return false;
--
2.35.3
[PATCH V7 00/15] IOT2050-related enhancements
Flushing our upstream queue for the IOT2050 device, this mostly
brings board-specific changes such as:
- updated build process and firmware layout for PG1 vs. PG2 devices
- more watchdog preparations
- preparations for verified boot on IOT2050 Advanced devices
- support for M.2 variant
Changes in v7:
- rebased over master
- included M.2 support patches, now that the DT is merged into the kernel
Changes in v6:
- fixed CFG_ENV_FLAGS_LIST_STATIC setup
- migrated to board env file
- cleaned up #ifdef in "Optionally embed OTP programming data into image"
- rebased over latest master
Changes in v5:
- factored out two patches
Changes in v4:
- rebased over latest master
- make use of new CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN
Changes in v3:
- further reworked patch 1 to load default env directly, leaving driver
ordering alone
Changes in v2:
- rebased over latest master
- reworked patch 1 to be less invasive to the code
- added "iot2050: use the named gpio to control the user-button"
Jan
CC: chao zeng
CC: Su Baocheng
Jan Kiszka (11):
iot2050: Update firmware layout
iot2050: Migrate settings into board env file
iot2050: Add watchdog start to bootcmd
iot2050: Add CFG_ENV_FLAGS_LIST_STATIC
arm: dts: iot2050: Allow verifying U-Boot proper by SPL
tools: Add script for converting public key into device tree include
iot2050: Add script for signing artifacts
arm: dts: iot2050: Optionally embed OTP programming data into image
doc: iot2050: Add a note about the watchdog firmware
iot2050: Refresh defconfigs and activate
CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN
iot2050: Add support for configuring M.2 connector
Su Baocheng (2):
board: siemens: iot2050: Split the build for PG1 and PG2
arm: dts: iot2050: Use the auto generator nodes for fdt
chao zeng (2):
board: siemens: iot2050: use the named gpio to control the user-button
arm: dts: iot2050: Add support for M.2 variant
arch/arm/dts/Makefile | 5 +-
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 149 +-
...050-advanced-m2-bkey-ekey-pcie-overlay.dts | 27 ++
...-iot2050-advanced-m2-bkey-usb3-overlay.dts | 47 +++
.../arm/dts/k3-am6548-iot2050-advanced-m2.dts | 121
board/siemens/iot2050/Kconfig | 35 ++-
board/siemens/iot2050/board.c | 270 +-
board/siemens/iot2050/iot2050.env | 17 ++
...ot2050_defconfig => iot2050_pg1_defconfig} | 8 +-
...ot2050_defconfig => iot2050_pg2_defconfig} | 12 +-
doc/board/siemens/iot2050.rst | 101 ++-
include/configs/iot2050.h | 19 +-
tools/binman/missing-blob-help| 16 +-
tools/iot2050-sign-fw.sh | 51
tools/key2dtsi.py | 64 +
15 files changed, 818 insertions(+), 124 deletions(-)
create mode 100644
arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-ekey-pcie-overlay.dts
create mode 100644
arch/arm/dts/k3-am6548-iot2050-advanced-m2-bkey-usb3-overlay.dts
create mode 100644 arch/arm/dts/k3-am6548-iot2050-advanced-m2.dts
create mode 100644 board/siemens/iot2050/iot2050.env
copy configs/{iot2050_defconfig => iot2050_pg1_defconfig} (93%)
rename configs/{iot2050_defconfig => iot2050_pg2_defconfig} (90%)
create mode 100755 tools/iot2050-sign-fw.sh
create mode 100755 tools/key2dtsi.py
--
2.35.3
[PATCH V7 06/15] iot2050: Add CFG_ENV_FLAGS_LIST_STATIC
From: Jan Kiszka Will be needed when CONFIG_ENV_WRITEABLE_LIST is enabled. The listed variables shall remain writable, for informational purposes - they have to be considered untrusted because the persistent U-Boot env is not protected. Signed-off-by: Jan Kiszka --- include/configs/iot2050.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h index 8dfeaddf541..217719472e5 100644 --- a/include/configs/iot2050.h +++ b/include/configs/iot2050.h @@ -40,4 +40,11 @@ #include +#ifdef CONFIG_ENV_WRITEABLE_LIST +#define CFG_ENV_FLAGS_LIST_STATIC \ + "board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw," \ + "mlfb:sw,fw_version:sw,seboot_version:sw," \ + "eth1addr:mw,eth2addr:mw,watchdog_timeout_ms:dw,boot_targets:sw" +#endif + #endif /* __CONFIG_IOT2050_H */ -- 2.35.3
[PATCH V7 02/15] arm: dts: iot2050: Use the auto generator nodes for fdt
From: Su Baocheng
Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.
As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.
Signed-off-by: Su Baocheng
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 44
board/siemens/iot2050/board.c| 3 ++
configs/iot2050_pg1_defconfig| 1 +
configs/iot2050_pg2_defconfig| 1 +
4 files changed, 12 insertions(+), 37 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 3135ad04715..46669576864 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -32,6 +32,7 @@
fit@0x28 {
description = "U-Boot for IOT2050";
+ fit,fdt-list = "of-list";
offset = <0x28>;
images {
u-boot {
@@ -46,32 +47,11 @@
};
};
- fdt-iot2050-basic {
- description =
"k3-am6528-iot2050-basic*.dtb";
+ @fdt-SEQ {
+ description = "fdt-NAME";
type = "flat_dt";
arch = "arm64";
compression = "none";
- blob {
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
- filename =
"arch/arm/dts/k3-am6528-iot2050-basic.dtb";
-#else
- filename =
"arch/arm/dts/k3-am6528-iot2050-basic-pg2.dtb";
-#endif
- };
- };
-
- fdt-iot2050-advanced {
- description =
"k3-am6548-iot2050-advanced*.dtb";
- type = "flat_dt";
- arch = "arm64";
- compression = "none";
- blob {
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
- filename =
"arch/arm/dts/k3-am6548-iot2050-advanced.dtb";
-#else
- filename =
"arch/arm/dts/k3-am6548-iot2050-advanced-pg2.dtb";
-#endif
- };
};
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
@@ -89,21 +69,11 @@
};
configurations {
- default = "conf-iot2050-basic";
-
- conf-iot2050-basic {
- description = "iot2050-basic";
- firmware = "u-boot";
- fdt = "fdt-iot2050-basic";
-#ifdef CONFIG_WDT_K3_RTI_FW_FILE
- loadables = "k3-rti-wdt-firmware";
-#endif
- };
-
- conf-iot2050-advanced {
- description = "iot2050-advanced";
+ default = "@config-DEFAULT-SEQ";
+ @config-SEQ {
+ description = "NAME";
firmware = "u-boot";
- fdt = "fdt-iot2050-advanced";
+ fdt = "fdt-SEQ";
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
loadables = "k3-rti-wdt-firmware";
#endif
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index dbf893000a7..57d7009e8c7 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -154,6 +154,9 @@ int board_fit_config_name_match(const char *name)
struct iot2050_info *info = IOT2050_INFO_DATA;
char upper_name[32];
+ /* skip the prefix "k3-am65x8-" */
+ name += 10;
+
if (info->magic != IOT2050_INFO_MAGIC ||
strlen(name) >= sizeof(upper_name))
return -1;
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index d9580309664..a13fd9ff68d 100644
--- a/configs/iot2050_
[PATCH V7 01/15] board: siemens: iot2050: Split the build for PG1 and PG2
From: Su Baocheng
Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.
A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.
The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.
Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.
Signed-off-by: Su Baocheng
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 80 ++-
board/siemens/iot2050/Kconfig | 28 ++-
board/siemens/iot2050/board.c | 12 +--
...ot2050_defconfig => iot2050_pg1_defconfig} | 2 +-
...ot2050_defconfig => iot2050_pg2_defconfig} | 10 ++-
doc/board/siemens/iot2050.rst | 15 +++-
6 files changed, 70 insertions(+), 77 deletions(-)
copy configs/{iot2050_defconfig => iot2050_pg1_defconfig} (99%)
rename configs/{iot2050_defconfig => iot2050_pg2_defconfig} (94%)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 27058370ccc..3135ad04715 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (c) Siemens AG, 2020-2021
+ * Copyright (c) Siemens AG, 2020-2022
*
* Authors:
* Jan Kiszka
@@ -17,7 +17,11 @@
blob-ext@0x00 {
offset = <0x00>;
- filename = "tiboot3.bin";
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
+ filename = "seboot_pg1.bin";
+#else
+ filename = "seboot_pg2.bin";
+#endif
missing-msg = "iot2050-seboot";
};
@@ -43,42 +47,30 @@
};
fdt-iot2050-basic {
- description =
"k3-am6528-iot2050-basic.dtb";
+ description =
"k3-am6528-iot2050-basic*.dtb";
type = "flat_dt";
arch = "arm64";
compression = "none";
blob {
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
filename =
"arch/arm/dts/k3-am6528-iot2050-basic.dtb";
- };
- };
-
- fdt-iot2050-basic-pg2 {
- description =
"k3-am6528-iot2050-basic-pg2.dtb";
- type = "flat_dt";
- arch = "arm64";
- compression = "none";
- blob {
+#else
filename =
"arch/arm/dts/k3-am6528-iot2050-basic-pg2.dtb";
+#endif
};
};
fdt-iot2050-advanced {
- description =
"k3-am6548-iot2050-advanced.dtb";
+ description =
"k3-am6548-iot2050-advanced*.dtb";
type = "flat_dt";
arch = "arm64";
compression = "none";
blob {
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
filename =
"arch/arm/dts/k3-am6548-iot2050-advanced.dtb";
- };
- };
-
- fdt-iot2050-advanced-pg2 {
- description =
"k3-am6548-iot2050-advanced-pg2.dtb";
- type = "flat_dt";
- arch = "arm64";
- compression = "none";
- blob {
+#else
filename =
"arch/arm/dts/k3-am6548-iot2050-advanced-pg2.dtb";
+#endif
};
};
@@ -108,30 +100,12 @@
#endif
};
-
[PATCH V7 03/15] iot2050: Update firmware layout
From: Jan Kiszka
The latest version of the binary-only firmware parts come in a combined
form of FSBL and sysfw containers. This implies some layout changes to
the generated firmware image but also makes handling of artifacts much
simpler (4 files less). The env locations will not change, just the
space reserved for U-Boot will shrink from 4 to 3 MB - still plenty of
space left in practice.
Adjust configuration and documentation accordingly.
Along this change, add a new reservation for update commands of the
user-controlled OTP part. A specific userspace tool will fill it, and
the FSBL will evaluate it during boot. This reservation will use 64K of
the former sysfw section.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 30 ++--
configs/iot2050_pg1_defconfig| 2 +-
configs/iot2050_pg2_defconfig| 2 +-
doc/board/siemens/iot2050.rst| 4 ---
tools/binman/missing-blob-help | 8 +-
5 files changed, 11 insertions(+), 35 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 46669576864..3ee0842e993 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -25,15 +25,15 @@
missing-msg = "iot2050-seboot";
};
- blob@0x08 {
- offset = <0x08>;
+ blob@0x18 {
+ offset = <0x18>;
filename = "tispl.bin";
};
- fit@0x28 {
+ fit@0x38 {
description = "U-Boot for IOT2050";
fit,fdt-list = "of-list";
- offset = <0x28>;
+ offset = <0x38>;
images {
u-boot {
description = "U-Boot";
@@ -94,25 +94,11 @@
fill-byte = [00];
};
- /* sysfw, basic variant */
- blob-ext@0x6c {
+ /* OTP update command block */
+ fill@0x6c {
offset = <0x6c>;
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
- filename = "sysfw_sr1.itb";
-#else
- filename = "sysfw_sr2.itb";
-#endif
- missing-msg = "iot2050-sysfw";
- };
- /* sysfw, advanced variant */
- blob-ext@0x74 {
- offset = <0x74>;
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
- filename = "sysfw_sr1.itb_HS";
-#else
- filename = "sysfw_sr2.itb_HS";
-#endif
- missing-msg = "iot2050-sysfw";
+ size = <0x01>;
+ fill-byte = [ff];
};
};
};
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index a13fd9ff68d..2f7a9d86794 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -52,7 +52,7 @@ CONFIG_SPL_POWER_DOMAIN=y
# CONFIG_SPL_SPI_FLASH_TINY is not set
CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x38
CONFIG_SYS_MAXARGS=64
CONFIG_SYS_PBSIZE=1050
CONFIG_CMD_ASKENV=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index 65400b4696a..e3f82ad3065 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -54,7 +54,7 @@ CONFIG_SPL_POWER_DOMAIN=y
# CONFIG_SPL_SPI_FLASH_TINY is not set
CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x28
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x38
CONFIG_SYS_MAXARGS=64
CONFIG_SYS_PBSIZE=1050
CONFIG_CMD_ASKENV=y
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index fd3431fa3f8..26972e20ae9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -25,11 +25,7 @@
https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/pre
The following binaries from that source need to be present in the build folder:
- seboot_pg1.bin
- - sysfw_sr1.itb
- - sysfw_sr1.itb_HS
- seboot_pg2.bin
- - sysfw_sr2.itb
- - sysfw_sr2.itb_HS
Building
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index 4448ac93112..1a30da7b5aa 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -21,13 +21,7 @@ Please read the section on SCP firmware in
board/sunxi/README.sunxi64
iot2050-seboot:
See the documentation for IOT2050 board. Your image is missing SEBoot
which is
[PATCH V7 04/15] iot2050: Migrate settings into board env file
From: Jan Kiszka Anything that is not boot-env related is better kept there by now. At this chance, also drop a stale comment from iot2050.h Signed-off-by: Jan Kiszka --- board/siemens/iot2050/iot2050.env | 9 + include/configs/iot2050.h | 11 ++- 2 files changed, 11 insertions(+), 9 deletions(-) create mode 100644 board/siemens/iot2050/iot2050.env diff --git a/board/siemens/iot2050/iot2050.env b/board/siemens/iot2050/iot2050.env new file mode 100644 index 000..4bd93f0b2f4 --- /dev/null +++ b/board/siemens/iot2050/iot2050.env @@ -0,0 +1,9 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) Siemens AG, 2023 + * + * Authors: + * Jan Kiszka + */ + +usb_pgood_delay=900 diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h index cfff46ce339..8dfeaddf541 100644 --- a/include/configs/iot2050.h +++ b/include/configs/iot2050.h @@ -13,12 +13,6 @@ #include -/* SPL Loader Configuration */ - -/* U-Boot general configuration */ -#define EXTRA_ENV_IOT2050_BOARD_SETTINGS \ - "usb_pgood_delay=900\0" - #if IS_ENABLED(CONFIG_CMD_USB) # define BOOT_TARGET_USB(func) \ func(USB, usb, 0) \ @@ -40,10 +34,9 @@ #include -#define CFG_EXTRA_ENV_SETTINGS \ +#define CFG_EXTRA_ENV_SETTINGS \ DEFAULT_LINUX_BOOT_ENV \ - BOOTENV \ - EXTRA_ENV_IOT2050_BOARD_SETTINGS + BOOTENV #include -- 2.35.3
[PATCH V7 05/15] iot2050: Add watchdog start to bootcmd
From: Jan Kiszka
Allows run-time control over watchdog auto-start and the timeout via
setting the environment variable watchdog_timeout_ms. A value of zero
means "do not start". Use CONFIG_WATCHDOG_TIMEOUT_MSECS as initial value
and this to zero by default. Users can then enable the watchdog once the
use and OS which picks it up during boot.
Signed-off-by: Jan Kiszka
---
board/siemens/iot2050/iot2050.env | 8
configs/iot2050_pg1_defconfig | 2 ++
configs/iot2050_pg2_defconfig | 2 ++
3 files changed, 12 insertions(+)
diff --git a/board/siemens/iot2050/iot2050.env
b/board/siemens/iot2050/iot2050.env
index 4bd93f0b2f4..02958798b49 100644
--- a/board/siemens/iot2050/iot2050.env
+++ b/board/siemens/iot2050/iot2050.env
@@ -7,3 +7,11 @@
*/
usb_pgood_delay=900
+
+watchdog_timeout_ms=CONFIG_WATCHDOG_TIMEOUT_MSECS
+start_watchdog=
+ if test ${watchdog_timeout_ms} -gt 0; then
+ wdt dev watchdog@4061;
+ wdt start ${watchdog_timeout_ms};
+ echo Watchdog started, timeout ${watchdog_timeout_ms} ms;
+ fi
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index 2f7a9d86794..258ad4c87e5 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -32,6 +32,7 @@ CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTSTAGE=y
CONFIG_SHOW_BOOT_PROGRESS=y
CONFIG_SPL_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd"
CONFIG_CONSOLE_MUX=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_MAX_SIZE=0x58000
@@ -140,6 +141,7 @@ CONFIG_USB_DWC3_GENERIC=y
CONFIG_USB_KEYBOARD=y
# CONFIG_WATCHDOG is not set
# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WATCHDOG_TIMEOUT_MSECS=0
CONFIG_WDT=y
CONFIG_WDT_K3_RTI=y
CONFIG_WDT_K3_RTI_LOAD_FW=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index e3f82ad3065..2ff360b0623 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -34,6 +34,7 @@ CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTSTAGE=y
CONFIG_SHOW_BOOT_PROGRESS=y
CONFIG_SPL_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd"
CONFIG_CONSOLE_MUX=y
# CONFIG_DISPLAY_CPUINFO is not set
CONFIG_SPL_MAX_SIZE=0x58000
@@ -144,6 +145,7 @@ CONFIG_USB_DWC3_GENERIC=y
CONFIG_USB_KEYBOARD=y
# CONFIG_WATCHDOG is not set
# CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WATCHDOG_TIMEOUT_MSECS=0
CONFIG_WDT=y
CONFIG_WDT_K3_RTI=y
CONFIG_WDT_K3_RTI_LOAD_FW=y
--
2.35.3
[PATCH V7 07/15] arm: dts: iot2050: Allow verifying U-Boot proper by SPL
From: Jan Kiszka
Add hashes and configuration signature stubs to prepare verified boot
of main U-Boot by SPL.
Signed-off-by: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 3ee0842e993..9082a79a034 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -14,6 +14,7 @@
filename = "flash.bin";
pad-byte = <0xff>;
size = <0x8c>;
+ allow-repack;
blob-ext@0x00 {
offset = <0x00>;
@@ -45,6 +46,9 @@
entry = <0x8080>;
u-boot-nodtb {
};
+ hash {
+ algo = "sha256";
+ };
};
@fdt-SEQ {
@@ -52,6 +56,9 @@
type = "flat_dt";
arch = "arm64";
compression = "none";
+ hash {
+ algo = "sha256";
+ };
};
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
@@ -64,6 +71,9 @@
filename =
CONFIG_WDT_K3_RTI_FW_FILE;
missing-msg =
"k3-rti-wdt-firmware";
};
+ hash {
+ algo = "sha256";
+ };
};
#endif
};
@@ -77,10 +87,16 @@
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
loadables = "k3-rti-wdt-firmware";
#endif
+ signature {
+ sign-images = "firmware",
"fdt", "loadables";
+ };
};
};
};
+ fdtmap {
+ };
+
/* primary env */
fill@0x68 {
offset = <0x68>;
--
2.35.3
Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts
On 13.02.23 05:26, Simon Glass wrote: > Hi Jan, > > On Tue, 7 Feb 2023 at 11:39, Simon Glass wrote: >> >> Hi Jan, >> >> On Tue, 7 Feb 2023 at 09:45, Jan Kiszka wrote: >>> >>> On 07.02.23 16:28, Simon Glass wrote: >>>> Hi Jan, >>>> >>>> On Mon, 6 Feb 2023 at 04:57, Jan Kiszka wrote: >>>>> >>>>> On 06.02.23 11:47, Jan Kiszka wrote: >>>>>> On 04.02.23 23:26, Simon Glass wrote: >>>>>>> Hi Jan, >>>>>>> >>>>>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka wrote: >>>>>>>> >>>>>>>> On 03.02.23 19:51, Tom Rini wrote: >>>>>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote: >>>>>>>>> >>>>>>>>>> From: Jan Kiszka >>>>>>>>>> >>>>>>>>>> There are many ways to get a signed firmware for the IOT2050 devices, >>>>>>>>>> namely for the parts under user-control. This script documents one >>>>>>>>>> way >>>>>>>>>> of doing it, given a signing key. Augment the board documentation >>>>>>>>>> with >>>>>>>>>> the required procedure around it. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Jan Kiszka >>>>>>>>> [snip] >>>>>>>>>> +# currently broken in upstream >>>>>>>>>> +#source/tools/binman/binman replace -i flash.bin -f >>>>>>>>>> f...@0x38.fit fit@0x38 >>>>>>>>>> +dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) >>>>>>>>>> seek=$((0x38/0x1000)) conv=notrunc >>>>>>>>> >>>>>>>>> Is that still a true comment? >>>>>>>>> >>>>>>>> >>>>>>>> binman: Node '/fit@0x38/images/u-boot': Offset 0x0 (0) size 0xb8870 >>>>>>>> (755824) is outside the section '/fit@0x38' starting at 0x0 (0) of >>>>>>>> size 0x400 (1024) >>>>>>>> >>>>>>>> And for the second call: >>>>>>>> >>>>>>>> binman: Node '/fit@0x38': Replacing sections is not implemented yet >>>>>>> >>>>>>> I sent a patch to implement that. >>>>>>> >>>>>>> I'm not quite sure if this resolves the first problem, too. If not, >>>>>>> can you please provide a binman test for the case you need, or >>>>>>> instructions on how to cause the failure? >>>>>> >>>>>> Instructions to reproduce are basically >>>>>> - apply this series >>>>>> - build flash.bin according to doc/board/siemens/iot2050.rst >>>>>> - drop the dd calls and activate binman in this signing script >>>>>> - run it >>>>>> >>>>>> But I'll try your patch ASAP on my setup. >>>>> >>>>> Still left with >>>>> >>>>> binman: Node '/fit@0x38/images/u-boot': Offset 0x0 (0) size 0xb8928 >>>>> (756008) is outside the section '/fit@0x38' starting at 0x0 (0) of >>>>> size 0x400 (1024) >>>>> >>>>> and >>>>> >>>>> binman: 'NoneType' object has no attribute 'props' >>>>> >>>>> That was for the second call of binman (source/tools/binman/binman >>>>> replace -i flash.bin -f f...@0x38.fit fit@0x38). The "not >>>>> implemented messages is gone. >>>>> >>>>> I've switched back to dd for the first call, but that did not work yet. >>>>> So the message above indicates a relevant error. >>>>> >>>>> Jan >>>> >>>> I thought I was able to follow all the steps (gosh, so many blobs) but >>>> I got something different from the first 'binman' call in your script. >>>> >>>> binman: Error 1 running 'mkimage -t -F >>>> /tmp/binman.l_xl69mi/f...@0x38.fit': mkimage: verify_header failed >>>> for FIT Image support with exit code 1 >>>> >>>> I will take a look at that...it is trying to rebuild the FIT and it >>>> should
Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts
On 07.02.23 16:28, Simon Glass wrote: > Hi Jan, > > On Mon, 6 Feb 2023 at 04:57, Jan Kiszka wrote: >> >> On 06.02.23 11:47, Jan Kiszka wrote: >>> On 04.02.23 23:26, Simon Glass wrote: >>>> Hi Jan, >>>> >>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka wrote: >>>>> >>>>> On 03.02.23 19:51, Tom Rini wrote: >>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote: >>>>>> >>>>>>> From: Jan Kiszka >>>>>>> >>>>>>> There are many ways to get a signed firmware for the IOT2050 devices, >>>>>>> namely for the parts under user-control. This script documents one way >>>>>>> of doing it, given a signing key. Augment the board documentation with >>>>>>> the required procedure around it. >>>>>>> >>>>>>> Signed-off-by: Jan Kiszka >>>>>> [snip] >>>>>>> +# currently broken in upstream >>>>>>> +#source/tools/binman/binman replace -i flash.bin -f f...@0x38.fit >>>>>>> fit@0x38 >>>>>>> +dd if=f...@0x38.fit of=flash.bin bs=$((0x1000)) >>>>>>> seek=$((0x38/0x1000)) conv=notrunc >>>>>> >>>>>> Is that still a true comment? >>>>>> >>>>> >>>>> binman: Node '/fit@0x38/images/u-boot': Offset 0x0 (0) size 0xb8870 >>>>> (755824) is outside the section '/fit@0x38' starting at 0x0 (0) of >>>>> size 0x400 (1024) >>>>> >>>>> And for the second call: >>>>> >>>>> binman: Node '/fit@0x38': Replacing sections is not implemented yet >>>> >>>> I sent a patch to implement that. >>>> >>>> I'm not quite sure if this resolves the first problem, too. If not, >>>> can you please provide a binman test for the case you need, or >>>> instructions on how to cause the failure? >>> >>> Instructions to reproduce are basically >>> - apply this series >>> - build flash.bin according to doc/board/siemens/iot2050.rst >>> - drop the dd calls and activate binman in this signing script >>> - run it >>> >>> But I'll try your patch ASAP on my setup. >> >> Still left with >> >> binman: Node '/fit@0x38/images/u-boot': Offset 0x0 (0) size 0xb8928 >> (756008) is outside the section '/fit@0x38' starting at 0x0 (0) of >> size 0x400 (1024) >> >> and >> >> binman: 'NoneType' object has no attribute 'props' >> >> That was for the second call of binman (source/tools/binman/binman >> replace -i flash.bin -f f...@0x38.fit fit@0x38). The "not >> implemented messages is gone. >> >> I've switched back to dd for the first call, but that did not work yet. >> So the message above indicates a relevant error. >> >> Jan > > I thought I was able to follow all the steps (gosh, so many blobs) but > I got something different from the first 'binman' call in your script. > > binman: Error 1 running 'mkimage -t -F > /tmp/binman.l_xl69mi/f...@0x38.fit': mkimage: verify_header failed > for FIT Image support with exit code 1 > > I will take a look at that...it is trying to rebuild the FIT and it > should not. It is another case of rebuilding sections that I didn't > think of. > > But actually, you need to create a new entry type for your signing > scheme. It looks like the signature is created by openssl and (rather > than putting it in a separate file) it creates a new file containing > both the signature and the file contents. That is a bit of a pain, but > can be made to work. > > Basically you need a new entry type (of which the FIT is a child) that > gets the contents of its child, signs it and returns that as the > contents. You can see vblock for an example, and > collection_contents_to_file(). Let me know if you want me to create an > example. > > The way it should work is that you run binman once (as part of the > U-Boot build) and it produces a final image. No messing about with > scripts, etc. In this case it looks like the key.pem file should be an > input to your new entry type. > > Using binman replace to sign something later is fine, but it is not > the intended use. Binman is supposed to be a single-pass image > builder. I strongly suspect we will need split build/sign also in the future because those steps are generally separate in corporate production envs. Maybe even 3 steps: assemble, extract hashes that should be signed and embed signatures of those in the end. > > Since we get different results, I suggest pushing a tree somewhere, in > case something is different with the patches. Tree is already at https://github.com/siemens/u-boot/commits/jan/iot2050 Jan -- Siemens AG, Technology Competence Center Embedded Linux
Re: [PATCH 1/2] env: Complete generic support for writable list
On 07.02.23 05:02, Simon Glass wrote:
> Hi Jan,
>
> On Fri, 3 Feb 2023 at 05:23, Jan Kiszka wrote:
>>
>> From: Jan Kiszka
>>
>> This completes what 890feecaab72 started by selecting ENV_APPEND and
>> loading the default env before any other sources. This ensures that load
>> operations pick up all non-writable vars from the default env and only
>> permitted parts from other locations according to the regular
>> priorities.
>>
>> With this change, boards only need to define the list of writable
>> variables but no longer have to provide a custom env_get_location
>> implementation.
>>
>> CC: Joe Hershberger
>> CC: Marek Vasut
>> CC: Stefan Herbrechtsmeier
>> Signed-off-by: Jan Kiszka
>> Reviewed-by: Marek Vasut
>> ---
>> env/Kconfig | 1 +
>> env/env.c | 8
>> 2 files changed, 9 insertions(+)
>>
>> diff --git a/env/Kconfig b/env/Kconfig
>> index c409ea71fe5..6e24eee55f2 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -733,6 +733,7 @@ config ENV_APPEND
>>
>> config ENV_WRITEABLE_LIST
>> bool "Permit write access only to listed variables"
>> + select ENV_APPEND
>> help
>> If defined, only environment variables which explicitly set the 'w'
>> writeable flag can be written and modified at runtime. No variables
>> diff --git a/env/env.c b/env/env.c
>> index 06078c7f374..45e638fcd1f 100644
>> --- a/env/env.c
>> +++ b/env/env.c
>> @@ -195,6 +195,14 @@ int env_load(void)
>> int best_prio = -1;
>> int prio;
>>
>> + if (CONFIG_IS_ENABLED(ENV_WRITEABLE_LIST)) {
>> + /*
>> +* When using a list of writeable variables, the baseline
>> comes
>> +* from the built-in default env. So load this first.
>> +*/
>> + env_set_default(NULL, 0);
>> + }
>> +
>> for (prio = 0; (drv = env_driver_lookup(ENVOP_LOAD, prio)); prio++) {
>> int ret;
>>
>> --
>> 2.35.3
>>
>
> This looks OK, but please can you write some tests in test/env ?
Looking at those, it seems there is nothing at all regarding access
flags yet. Any suggestions how to first of all build up that
infrastructure are welcome. Then I could add this aspect here on top.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include
On 07.02.23 05:02, Simon Glass wrote: > Hi Jan, > > On Mon, 6 Feb 2023 at 03:42, Jan Kiszka wrote: >> >> On 04.02.23 23:23, Simon Glass wrote: >>> Hi Jan, >>> >>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka wrote: >>>> >>>> On 04.02.23 01:20, Simon Glass wrote: >>>>> Hi Jan, >>>>> >>>>> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka wrote: >>>>>> >>>>>> From: Jan Kiszka >>>>>> >>>>>> Allows to create a public key device tree dtsi for inclusion into U-Boot >>>>>> SPL and proper during first build already. This can be achieved via >>>>>> CONFIG_DEVICE_TREE_INCLUDES. >>>>>> >>>>>> Signed-off-by: Jan Kiszka >>>>>> --- >>>>>> tools/key2dtsi.py | 64 +++ >>>>>> 1 file changed, 64 insertions(+) >>>>>> create mode 100755 tools/key2dtsi.py >>>>> >>>>> Please can you build this into Binman instead? We really don't want >>>>> any more of these scripts. Perhaps you can add a new entry type? >>>>> >>>> >>>> I don't think you are requesting something that makes any sense: >>>> >>>> "Binman creates and manipulate *images* for a board from a set of binaries" >>> >>> I mean that Binman can include a public key in the DT, if that it was >>> you are wanting. We don't want to add scripts for creating images and >>> pieces of images. >>> >>> Perhaps I just don't understand the goal here. How would your script be >>> used? >>> >> >> We feed the generated dtsi into the U-Boot build, using >> CONFIG_DEVICE_TREE_INCLUDES. This ensures that will be signed along with >> the built artifacts. Have a look at patch 9 for the steps, specifically >> the doc update bits. Full bitbake (Isar) integration is available under >> [1], specifically [2] in combination with [3]. >> > > OK, so is Binman run in this case? > It's run at the end of the build, to assemble the unsigned flash.bin. And it should have been used also for signing that image (patch 8, see the other discussion). Jan >> Jan >> >> [1] https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot >> [2] >> https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/rules.tmpl >> [3] >> https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg >> >> -- >> Siemens AG, Technology >> Competence Center Embedded Linux >> > > Regards, > Simon -- Siemens AG, Technology Competence Center Embedded Linux
