Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully
On 11:53-20240328, Sverdlin, Alexander wrote: [..] > > Btw, this no longer applies on next. only applies on master. Depending > > on where Tom would like to apply this change, might need a rebase. > > Thanks for the hint! I've totally missed this! > And I'm even not sure the patch makes sense on "next". > I'd need to retest if the problem is still there (and if there would be one, > then it's rather subsystem problem, not am65-cpsw any more. > > So the patch only makes sense for stable branches, if any. On next, I think a variant of the patch will be needed as well. I see the same bug on latest next as well (ab8d9ca3044a Merge tag 'v2024.04-rc5' into next) https://gist.github.com/nmenon/691ccd210ed7e1add4c865ca9a698f2e -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully
On 07:29-20240328, A. Sverdlin wrote:
> From: Alexander Sverdlin
>
> am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> specified in DT gracefully:
>
> am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1 (-2)
>
> am65_cpsw_mdio_init() in turn is prepared for this, checks
> if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
>
> am65_cpsw_phy_init() however is not prepared for this and calls
> phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
>
> "Synchronous Abort" handler, esr 0x860d, far 0x0
> elr: 808ab000 lr : 8083bde4 (reloc)
>
> where lr points to the instruction right after bus->read() in get_phy_id().
>
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch
> subsystem driver")
> Signed-off-by: Alexander Sverdlin
> ---
> v2: rewritten subject; "is turn" -> "in turn" further down in message body
>
> drivers/net/ti/am65-cpsw-nuss.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 6da018c0f9d5..d1e452b6b43c 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -722,6 +722,9 @@ static int am65_cpsw_phy_init(struct udevice *dev)
> u32 supported = PHY_GBIT_FEATURES;
> int ret;
>
> + if (!priv->has_phy || !cpsw_common->bus)
> + return 0;
> +
> phydev = phy_connect(cpsw_common->bus,
>priv->phy_addr,
>priv->dev,
> --
> 2.44.0
>
Reviewed-by: Nishanth Menon
Thanks for fixing this.
Btw, this no longer applies on next. only applies on master. Depending
on where Tom would like to apply this change, might need a rebase.
CC Roger.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
On 18:40-20240322, Neha Malcom Francis wrote: > Clean up templatized boot binaries for all K3 boards. This includes > modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and > UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse > code. > > All k3--binman.dtsi will contain only templates. Only required boot > binaries can be built from the templates in the boards' respective > -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows > clear distinction between the SoC common stuff vs. what is additionally > needed to boot up a specific board. > > Signed-off-by: Neha Malcom Francis > --- > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +- > arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 + > arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 --- > arch/arm/dts/k3-am625-sk-binman.dtsi | 148 + > arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 +++ > .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +- > arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 + > arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 +++ > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 +++ > arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 +++ > arch/arm/dts/k3-am64x-binman.dtsi | 239 +- > arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 +++ > arch/arm/dts/k3-am65x-binman.dtsi | 144 + > .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 ++ > arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +- > arch/arm/dts/k3-binman.dtsi | 96 ++ > arch/arm/dts/k3-j7200-binman.dtsi | 145 + > .../k3-j7200-common-proc-board-u-boot.dtsi| 40 +++ > .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 + > arch/arm/dts/k3-j721e-binman.dtsi | 262 +++- > .../k3-j721e-common-proc-board-u-boot.dtsi| 84 + > arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +- > arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 + > arch/arm/dts/k3-j721s2-binman.dtsi| 231 +- > .../k3-j721s2-common-proc-board-u-boot.dtsi | 42 +++ > arch/arm/dts/k3-j784s4-binman.dtsi| 154 + > arch/arm/dts/k3-j784s4-evm-u-boot.dtsi| 42 +++ > 27 files changed, 858 insertions(+), 2305 deletions(-) > > diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi > b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi > index cca0f44b7d8..fc1898f1510 100644 > --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi > +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi > @@ -6,7 +6,11 @@ > * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation > */ > > -#include "k3-binman.dtsi" > +#define SPL_BOARD_DTB "spl/dts/k3-am625-beagleplay.dtb" > +#define BOARD_DESCRIPTION "k3-am625-beagleplay" > +#define UBOOT_BOARD_DESCRIPTION "U-Boot for AM625 BeaglePlay" > + > +#include "k3-am625-sk-binman.dtsi" Drop the "sk" ? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 2/4] arm: dts: k3-j7200: Fix support for OSPI flash
On 18:47-20240306, Kumar, Udit wrote:
>
> On 3/6/2024 12:07 PM, Aniket Limaye wrote:
> > - Add the missing bootph-all property in the flash subnode for ospi
> > - Add the missing overrides for the ospi node in the r5 devicetree
>
> Please see , if you can add more on this why we are adding this
>
> also, if this patch fixes some previous commit
>
> >
> > Signed-off-by: Aniket Limaye
> > ---
> > arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 4
> > arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 5 +
> > 2 files changed, 9 insertions(+)
> >
> > diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > index 60ca6d21ab..c9fee0ea99 100644
> > --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> > @@ -195,6 +195,10 @@
> >{
> > bootph-all;
You should only use bootph-all property in leaf nodes - at least for
kernel world.
> > +
> > + flash@0 {
> > + bootph-all;
> > + };
> > };
>
>
> Ideally this should come from kernel DT sync or with OF_UPSTREAM, whatever
> is applicable
>
> As you are fixing broken OSPI boot.
>
> Tom can suggest, if he is ok to pull in this fix for 2024.04 or we need to
> wait to get this change into kernel first.
Send this change for upstream kernel right away please.
>
>
> > _ln_ctrl {
> > diff --git a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > index 018faaa13b..195637a836 100644
> > --- a/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > +++ b/arch/arm/dts/k3-j7200-r5-common-proc-board.dts
> > @@ -83,3 +83,8 @@
> > _vtm0 {
> > bootph-pre-ram;
> > };
> > +
> > + {
> > +reg = <0x0 0x4704 0x0 0x100>,
> > + <0x0 0x5000 0x0 0x800>;
> > +};
>
> With change in commit message,
>
> Reviewed-by: Udit Kumar
>
>
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 1/4] configs: j7200_evm_*_defconfig: Enable OSPI configs
On 18:41-20240306, Kumar, Udit wrote: > > On 3/6/2024 12:07 PM, Aniket Limaye wrote: > > Add the necessary configs required for OSPI functionality. > > Also update the ospi flash partition offsets as per the devicetree. > > > > Signed-off-by: Aniket Limaye > > --- > > configs/j7200_evm_a72_defconfig | 10 -- > > configs/j7200_evm_r5_defconfig | 9 +++-- > > 2 files changed, 15 insertions(+), 4 deletions(-) > > Could we not do fragments? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] arch: mach-k3: fix mapping higher DDR addresses as device memory
On 12:15-20240222, Neha Malcom Francis wrote:
> From: Sekhar Nori
>
> An entry in memory map table for MMU configuration is spilling over and
> inadvertently mapping DDR available at higher address (above 4GB address
> space) as device memory (nGnRnE).
>
> Fix this by adjusting entry size. Tested on AM62A SK by enabling
> CONFIG_CMD_TIME. Before this patch:
>
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 5a7a5760
>
> time: 1 minutes, 14.715 seconds
>
> After patch:
>
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 3df1ce02
>
> time: 2.711 seconds
>
> Signed-off-by: Sekhar Nori
> [n-fran...@ti.com: rebased on next, retested on all devices inc. commit]
> Signed-off-by: Neha Malcom Francis
> Cc: Andrew Davis
> ---
> Boot logs:
> https://gist.github.com/nehamalcom/7b101ea8b97f5a9433a553ef881166a1
>
> arch/arm/mach-k3/arm64-mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
> index b4308205b2..0e07b1b7ce 100644
> --- a/arch/arm/mach-k3/arm64-mmu.c
> +++ b/arch/arm/mach-k3/arm64-mmu.c
> @@ -41,7 +41,7 @@ struct mm_region k3_mem_map[] = {
> }, {
> .virt = 0x5UL,
> .phys = 0x5UL,
> - .size = 0x4UL,
> + .size = 0x38000UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> --
> 2.34.1
>
https://lore.kernel.org/u-boot/20240119160900.GU12635@bill-the-cat/ ??
Something was missing?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH V2 4/5] board: beagle: beagleplay: Configure debounce registers
Configure the debounce configuration that makes sense for BeaglePlay
usage model.
Signed-off-by: Nishanth Menon
---
Changes since V1:
* No change
V1: https://lore.kernel.org/r/20240212155332.541949-5...@ti.com
board/beagle/beagleplay/beagleplay.c | 24
1 file changed, 24 insertions(+)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index 2adb2517ef00..fe1c4f920329 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -59,8 +59,32 @@ static void crystal_32k_enable(void)
}
}
+static void debounce_configure(void)
+{
+ /* Configure debounce one time from R5 */
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ /*
+* Setup debounce time registers.
+* arbitrary values. Times are approx
+*/
+ /* 1.9ms debounce @ 32k */
+ writel(0x1, CTRLMMR_DBOUNCE_CFG(1));
+ /* 5ms debounce @ 32k */
+ writel(0x5, CTRLMMR_DBOUNCE_CFG(2));
+ /* 20ms debounce @ 32k */
+ writel(0x14, CTRLMMR_DBOUNCE_CFG(3));
+ /* 46ms debounce @ 32k */
+ writel(0x18, CTRLMMR_DBOUNCE_CFG(4));
+ /* 100ms debounce @ 32k */
+ writel(0x1c, CTRLMMR_DBOUNCE_CFG(5));
+ /* 156ms debounce @ 32k */
+ writel(0x1f, CTRLMMR_DBOUNCE_CFG(6));
+ }
+}
+
void spl_board_init(void)
{
crystal_32k_enable();
+ debounce_configure();
}
#endif
--
2.43.0
[PATCH V2 3/5] arm: mach-k3: am62: Add Debounce configuration register definitions
Add the Debounce configuration registers that need to be configured one time for the platform for the entire SoC. Signed-off-by: Nishanth Menon --- Changes since V1: * Fix 4080 to 0x4080 V1: https://lore.kernel.org/r/20240212155332.541949-4...@ti.com arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h b/arch/arm/mach-k3/include/mach/am62_hardware.h index 54380f36e161..4cf7778a89ee 100644 --- a/arch/arm/mach-k3/include/mach/am62_hardware.h +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h @@ -75,6 +75,9 @@ #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE + 0x18170) +/* Debounce register configuration */ +#define CTRLMMR_DBOUNCE_CFG(index) (MCU_CTRL_MMR0_BASE + 0x4080 + (index * 4)) + #define ROM_EXTENDED_BOOT_DATA_INFO0x43c3f1e0 #define TI_SRAM_SCRATCH_BOARD_EEPROM_START 0x43c3 -- 2.43.0
[PATCH V2 5/5] board: beagle: beagleplay: env: Drop usb and pxe as boot targets
We had enabled USB and network pxe boot with the hope to get it all merged on time. However, it has not panned out. Drop usb and pxe boot else bootflow scan -l throws in: a) Unknown uclass 'usb' in label b) Crashes when attempting pxe - cpsw/mdio driver apparently has missing error handling of what ever form. This is the one that Jan noticed in his log. We can enable these on a later date once things are working. Cc: Roger Quadros Reported-by: Jan Kiszka Closes: https://lore.kernel.org/all/782ea2c0-eef5-478d-a122-cc6e2d066...@siemens.com/ Signed-off-by: Nishanth Menon --- - New patch in V2 of the series. board/beagle/beagleplay/beagleplay.env | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/beagle/beagleplay/beagleplay.env b/board/beagle/beagleplay/beagleplay.env index 4f0a94a8113e..db737e069b58 100644 --- a/board/beagle/beagleplay/beagleplay.env +++ b/board/beagle/beagleplay/beagleplay.env @@ -14,6 +14,6 @@ boot=mmc mmcdev=1 bootpart=1:1 bootdir=/boot -boot_targets=mmc1 mmc0 usb pxe +boot_targets=mmc1 mmc0 bootmeths=script extlinux efi pxe rd_spec=- -- 2.43.0
[PATCH V2 0/5] board: beagle: Enable 32k and debounce configuration and fixups
Hi, Rev 2 of the series. This is a follow up from [1] - Without the 32k crystal configuration, wlan doesn't work. Debounce is needed for HDMI Hot plug detect(hpd) gpio interrupt not storming. At least the 32k configuration has been done for toradex and phytec boards, follow similar model of programming. Series is now based off master branch. Bootlog: https://gist.github.com/nmenon/75df38bee907785d1d78d1ec4abd7304 Changes from V2: - Removed depedency on [2] - depending on which way the merge sequence goes, one of the series will need a rebase. - Added a patch for a bug that Jan noticed - Fixup for the fat finger missing 0x in 0x4080 :( V1: https://lore.kernel.org/all/20240212155332.541949-1...@ti.com/ Nishanth Menon : board: beagle: beagleplay: Enable 32k crystal configs: am62x_beagleplay_r5_defconfig: Enable SPL_BOARD_INIT arm: mach-k3: am62: Add Debounce configuration register definitions board: beagle: beagleplay: Configure debounce registers board: beagle: beagleplay: env: Drop usb and pxe as boot targets arch/arm/mach-k3/include/mach/am62_hardware.h | 3 + board/beagle/beagleplay/beagleplay.c | 61 +++ board/beagle/beagleplay/beagleplay.env| 2 +- configs/am62x_beagleplay_r5_defconfig | 1 + 4 files changed, 66 insertions(+), 1 deletion(-) base-commit: 3e6f2a94bfc25f1782ce2d45db27f47ec781feb1 [1] https://lore.kernel.org/u-boot/20230725185253.2123433-4...@ti.com/ [2] https://lore.kernel.org/u-boot/20240212194726.1093771-1...@ti.com/ -- 2.43.0
[PATCH V2 1/5] board: beagle: beagleplay: Enable 32k crystal
Enable the external 32k crystal similar to that found on other
production AM62X board. The trim settings for the crystal is board
dependent, so the sequences tend to be board specific. Since this is
a configuration that needs to be done prior to DM managing the system
and all other muxes get set, do the same from R5 context.
Tested-by: Robert Nelson
Signed-off-by: Nishanth Menon
---
Changes from V1:
* Added Robert's tested by.
V1: https://lore.kernel.org/r/20240212155332.541949-2...@ti.com
board/beagle/beagleplay/beagleplay.c | 37
1 file changed, 37 insertions(+)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index 1c376dea372f..2adb2517ef00 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -11,6 +11,8 @@
#include
#include
+#include
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -27,3 +29,38 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_SPL_BOARD_INIT
+
+/*
+ * Enable the 32k Crystal: needed for accurate 32k clock
+ * and external clock sources such as wlan 32k input clock
+ * supplied from the SoC to the wlan chip.
+ *
+ * The trim setup can be very highly board type specific choice of the crystal
+ * So this is done in the board file, though, in this case, no specific trim
+ * is necessary.
+ */
+static void crystal_32k_enable(void)
+{
+ /* Only mess with 32k at the start of boot from R5 */
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ /*
+* We have external 32k crystal, so lets enable it (0x0)
+* and disable bypass (0x0)
+*/
+ writel(0x0, MCU_CTRL_LFXOSC_CTRL);
+
+ /* Add any crystal specific TRIM needed here.. */
+
+ /* Make sure to mux the SoC 32k from the crystal */
+ writel(MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL,
+ MCU_CTRL_DEVICE_CLKOUT_32K_CTRL);
+ }
+}
+
+void spl_board_init(void)
+{
+ crystal_32k_enable();
+}
+#endif
--
2.43.0
[PATCH V2 2/5] configs: am62x_beagleplay_r5_defconfig: Enable SPL_BOARD_INIT
Enable CONFIG_SPL_BOARD_INIT to configure the 32k crystal. Signed-off-by: Nishanth Menon --- Changes since V1: * No change V1: https://lore.kernel.org/r/20240212155332.541949-3...@ti.com configs/am62x_beagleplay_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am62x_beagleplay_r5_defconfig b/configs/am62x_beagleplay_r5_defconfig index 2f3264b7ede6..9413c859870f 100644 --- a/configs/am62x_beagleplay_r5_defconfig +++ b/configs/am62x_beagleplay_r5_defconfig @@ -36,6 +36,7 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x43c3b000 CONFIG_SPL_BSS_MAX_SIZE=0x3000 CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y +CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y -- 2.43.0
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
/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. boot_targets=mmc1 mmc0 usb pxe networking ran into some significant challenges. I was hoping to get networking merged but the series got offset and network never made it.. Dropping pxe from boot_targets => setenv boot_targets mmc1 mmc0 usb => print bootmeths bootmeths=script extlinux efi pxe => print boot_targets boot_targets=mmc1 mmc0 usb => bootflow scan -l Scanning for bootflows in all bootdevs Seq Method State UclassPart Name Filename --- --- -- Scanning bootdev 'mmc@fa0.bootdev': 0 extlinux ready mmc 1 mmc@fa0.bootdev.part_ /extlinux/extlinux.conf Scanning bootdev 'mmc@fa1.bootdev': 1 extlinux ready mmc 1 mmc@fa1.bootdev.part_ /extlinux/extlinux.conf Unknown uclass 'usb' in label No more bootdevs --- --- -- (2 bootflows, 2 valid) => -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH V6 07/20] configs: am62x_evm_a53_defconfig: Switch to bootstd
On 19:37-20240219, 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. For what it is worth, https://software-dl.ti.com/cicd-report/upstream/ -> we are trying to do that on TI side, though it is still in infancy and test coverage is still more to be desired. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v8 12/16] arm: dts: Introduce j784s4 u-boot dts files
On 14:33-20240215, Neha Malcom Francis wrote: [...] > > if the templates are abstract enough, the additional code will be so > > minimal that we wont need a board-binman.dtsi - just u-boot.dtsi and > > r5.dtsi can include the relevant templates. > > > > Hope this helps. > > > So I took a stab at working on this for couple of days, a fix was needed > within the tool to allow binman to handle multiple consecutive templates > which is needed here etc. which is why it did not work as is; but the built > binaries are still not stable for boot. I think this will need some > additional work and debugging. As of now, templating is not widely used, so > I'm guessing some more minor fixes would be needed to get it building as we > intend. > > If you are okay, I think we can take this series as is for now, I will take > action to start off a series cleaning up and using templating for all the > devices. Sure, as long you can do this by the next window. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH 03/11] board: ti: am62ax: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-4...@ti.com
board/ti/am62ax/am62ax.env | 1 -
board/ti/am62ax/evm.c| 10 ++
configs/am62ax_evm_a53_defconfig | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index a6d967e982d4..334374abb73e 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
index cd3360a43029..62d3664936e7 100644
--- a/board/ti/am62ax/evm.c
+++ b/board/ti/am62ax/evm.c
@@ -13,6 +13,8 @@
#include
#include
+#include "../common/fdt_ops.h"
+
int board_init(void)
{
return 0;
@@ -27,3 +29,11 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 38083586a3ec..e5fcd8cc5b6f 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -24,6 +24,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTSTD_DEFAULTS=y
CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_PAD_TO=0x0
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.43.0
[PATCH 10/11] board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from C
code.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-11...@ti.com
board/beagle/beagleplay/beagleplay.c | 14 ++
board/beagle/beagleplay/beagleplay.env | 1 -
configs/am62x_beagleplay_a53_defconfig | 3 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index 1c376dea372f..20819ecf45b4 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -27,3 +27,17 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ char fdtfile[50];
+
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+ env_set("fdtfile", fdtfile);
+
+ return 0;
+}
+#endif
diff --git a/board/beagle/beagleplay/beagleplay.env
b/board/beagle/beagleplay/beagleplay.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/configs/am62x_beagleplay_a53_defconfig
b/configs/am62x_beagleplay_a53_defconfig
index 0be20045a974..1f43891d10bb 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -33,7 +33,8 @@ CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
--
2.43.0
[PATCH 02/11] board: ti: common: Introduce a common fdt ops library
Introduce a common fdt operations library for basic device tree
operations that are common between various boards.
The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-3...@ti.com
board/ti/common/Kconfig | 12
board/ti/common/Makefile | 1 +
board/ti/common/fdt_ops.c | 64 +++
board/ti/common/fdt_ops.h | 42 +
4 files changed, 119 insertions(+)
create mode 100644 board/ti/common/fdt_ops.c
create mode 100644 board/ti/common/fdt_ops.h
diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab..de44e4de2115 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
imply CMD_SPI
imply CMD_TIME
imply CMD_USB if USB
+
+config TI_FDT_FOLDER_PATH
+ string "Location of Folder path where dtb is present"
+ default "ti/davinci" if ARCH_DAVINCI
+ default "ti/keystone" if ARCH_KEYSTONE
+ default "ti/omap" if ARCH_OMAP2PLUS
+ default "ti" if ARCH_K3
+ depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
+ help
+ Folder path for kernel device tree default.
+ This is used along with fdtfile path to locate the kernel
+ device tree blob.
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 26bf12e2e6d5..5ac361ba7fcf 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -3,3 +3,4 @@
obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
new file mode 100644
index ..eb917be9e0da
--- /dev/null
+++ b/board/ti/common/fdt_ops.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Library to support FDT file operations which are common
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include
+#include "fdt_ops.h"
+
+void ti_set_fdt_env(const char *board_name, struct ti_fdt_map *fdt_map)
+{
+ char *fdt_file_name = NULL;
+ char fdtfile[TI_FDT_FILE_MAX];
+
+ if (board_name) {
+ while (fdt_map) {
+ /* Check for NULL terminator in the list */
+ if (!fdt_map->board_name)
+ break;
+ if (!strncmp(fdt_map->board_name, board_name,
TI_BOARD_NAME_MAX)) {
+ fdt_file_name = fdt_map->fdt_file_name;
+ break;
+ }
+ fdt_map++;
+ }
+ }
+
+ /* match not found OR null board_name */
+ if (!fdt_file_name) {
+ /*
+* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
+* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
+*/
+#ifdef CONFIG_DEFAULT_FDT_FILE
+ if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
+CONFIG_TI_FDT_FOLDER_PATH,
CONFIG_DEFAULT_FDT_FILE);
+ } else
+#endif
+ {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH,
CONFIG_DEFAULT_DEVICE_TREE);
+ }
+ } else {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
CONFIG_TI_FDT_FOLDER_PATH,
+fdt_file_name);
+ }
+
+ env_set("fdtfile", fdtfile);
+
+ /*
+* XXX: DEPRECATION WARNING: 2 u-boot versions (2024.10).
+*
+* Maintain compatibility with downstream scripts that may be using
+* name_fdt
+*/
+ if (board_name)
+ env_set("name_fdt", fdtfile);
+ /* Also set the findfdt legacy script to warn users to stop using this
*/
+ env_set("findfdt",
+ "echo WARN: fdtfile already set. Stop using findfdt in script");
+}
diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
new file mode 100644
index ..5d304994fb6e
--- /dev/null
+++ b/board/ti/common/fdt_ops.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Library to support common device tree manipulation for TI EVMs
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#ifndef __FDT_OPS_H
+#define __FDT_OPS_H
+
+#define TI_BOA
[PATCH 05/11] board: ti: am64x: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-6...@ti.com
board/ti/am64x/am64x.env | 9 -
board/ti/am64x/evm.c | 8
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index efd736b99be4..9a8812d4ee54 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -2,14 +2,6 @@
#include
#include
-findfdt=
- if test $board_name = am64x_gpevm; then
- setenv name_fdt ti/k3-am642-evm.dtb; fi;
- if test $board_name = am64x_skevm; then
- setenv name_fdt ti/k3-am642-sk.dtb; fi;
- if test $name_fdt = undefined; then
- echo WARNING: Could not determine device tree to use; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
@@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
usbboot=setenv boot usb;
setenv bootpart 0:2;
usb start;
- run findfdt;
run init_usb;
run get_kern_usb;
run get_fdt_usb;
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index a7ca6be436eb..b8de69da06c5 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -16,6 +16,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
board_ti_k3_is("AM64-EVM") || \
@@ -181,6 +182,12 @@ int checkboard(void)
}
#ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
+ {"am64x_gpevm", "k3-am642-evm.dtb"},
+ {"am64x_skevm", "k3-am642-sk.dtb"},
+ { /* Sentinel. */ }
+};
+
static void setup_board_eeprom_env(void)
{
char *name = "am64x_gpevm";
@@ -198,6 +205,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_am64_evm_fdt_map);
}
static void setup_serial(void)
--
2.43.0
[PATCH 06/11] board: ti: am65x: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-7...@ti.com
board/ti/am65x/am65x.env | 3 ---
board/ti/am65x/evm.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 286b9c300c05..814374d68cf0 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -5,9 +5,6 @@
#include
#endif
-findfdt=
- setenv name_fdt ti/k3-am654-base-board.dtb;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index df209021c1b7..3109c9a2acac 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -22,6 +22,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
@@ -141,6 +142,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(NULL, NULL);
}
static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
--
2.43.0
[PATCH 08/11] board: ti: j721s2: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-9...@ti.com
board/ti/j721s2/evm.c | 8
board/ti/j721s2/j721s2.env | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 1220cd84519b..5a0281d6b483 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -23,6 +23,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -114,6 +115,12 @@ int checkboard(void)
return 0;
}
+static struct ti_fdt_map ti_j721s2_evm_fdt_map[] = {
+ {"j721s2", "k3-j721s2-common-proc-board.dtb"},
+ {"am68-sk", "k3-am68-sk-base-board.dtb"},
+ { /* Sentinel. */ }
+};
+
static void setup_board_eeprom_env(void)
{
char *name = "j721s2";
@@ -131,6 +138,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_j721s2_evm_fdt_map);
}
static void setup_serial(void)
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 64e3d9da85f0..9a03b9f30aee 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -7,14 +7,6 @@
#include
#endif
-default_device_tree=ti/k3-j721s2-common-proc-board.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- if test $board_name = j721s2; then \
- setenv name_fdt ti/k3-j721s2-common-proc-board.dtb; fi;
- if test $board_name = am68-sk; then
- setenv name_fdt ti/k3-am68-sk-base-board.dtb; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
--
2.43.0
[PATCH 00/11] board/ti: k3 boards: Stop using findfdt
Hi, Hopefully the last time. Apologies on the screw ups. Ran CI loop[1] to be doubly sure that I have'nt yet again fat fingered something. This is a wide cleanup to switch to setting fdtfile using env_set instead of scripted magic. 'fdtfile' is expected to be set by default. This allows the stdboot triggered efi loaders to find the correct OS device tree file even if regular boot process is interrupted by user intervention. Fixes since V3: * fix up missing header for am62x evm (I seemed to have dropped the fixup somehow) based on: master e8f2404e093d Merge branch 'master-779h0-r2' of https://source.denx.de/u-boot/custodians/u-boot-sh Since this impacts out of box distro support, will be great to get it as part of 2024.04 release. Testing (decided to retest it all): https://gist.github.com/nmenon/b9d49d752c27988aabdc062dcdc41e67 V3: https://lore.kernel.org/all/20240130130615.670783-1...@ti.com/ V2: https://lore.kernel.org/all/20240109191506.3820908-1...@ti.com/ V1: https://lore.kernel.org/all/20240108173301.2692332-1...@ti.com/ Nishanth Menon (11): board: ti: Add missing common/Kconfig references board: ti: common: Introduce a common fdt ops library board: ti: am62ax: Set fdtfile from C code instead of findfdt script board: ti: am62x: Set fdtfile from C code instead of findfdt script board: ti: am64x: Set fdtfile from C code instead of findfdt script board: ti: am65x: Set fdtfile from C code instead of findfdt script board: ti: j721e: Set fdtfile from C code instead of findfdt script board: ti: j721s2: Set fdtfile from C code instead of findfdt script board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script include: env: ti: Drop default_findfdt board/beagle/beagleboneai64/beagleboneai64.c | 14 .../beagle/beagleboneai64/beagleboneai64.env | 1 - board/beagle/beagleplay/beagleplay.c | 14 board/beagle/beagleplay/beagleplay.env| 1 - board/ti/am62ax/am62ax.env| 1 - board/ti/am62ax/evm.c | 10 +++ board/ti/am62x/am62x.env | 1 - board/ti/am62x/evm.c | 10 +++ board/ti/am64x/am64x.env | 9 --- board/ti/am64x/evm.c | 8 +++ board/ti/am65x/am65x.env | 3 - board/ti/am65x/evm.c | 2 + board/ti/common/Kconfig | 12 board/ti/common/Makefile | 1 + board/ti/common/fdt_ops.c | 64 +++ board/ti/common/fdt_ops.h | 42 board/ti/j721e/evm.c | 8 +++ board/ti/j721e/j721e.env | 10 --- board/ti/j721s2/evm.c | 8 +++ board/ti/j721s2/j721s2.env| 8 --- board/ti/omap3evm/Kconfig | 2 + board/ti/panda/Kconfig| 2 + board/ti/sdp4430/Kconfig | 2 + configs/am62ax_evm_a53_defconfig | 1 + configs/am62x_beagleplay_a53_defconfig| 3 +- configs/am62x_evm_a53_defconfig | 1 + configs/j721e_beagleboneai64_a72_defconfig| 3 +- include/env/ti/default_findfdt.env| 12 28 files changed, 205 insertions(+), 48 deletions(-) create mode 100644 board/ti/common/fdt_ops.c create mode 100644 board/ti/common/fdt_ops.h delete mode 100644 include/env/ti/default_findfdt.env [1] https://github.com/u-boot/u-boot/pull/487 base-commit: e8f2404e093daf6cc3ac2b3233e3c6770d13e371 -- 2.43.0
[PATCH 04/11] board: ti: am62x: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* Add missing header file - have no idea how i dropped that fixup.. :(
V3: https://lore.kernel.org/r/20240130130615.670783-5...@ti.com
board/ti/am62x/am62x.env| 1 -
board/ti/am62x/evm.c| 10 ++
configs/am62x_evm_a53_defconfig | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index e53a55c38fbb..9cb186c2a03c 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 88e02155ee33..b3e8680dfab2 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -19,6 +19,8 @@
#include
#include
+#include "../common/fdt_ops.h"
+
DECLARE_GLOBAL_DATA_PTR;
#if CONFIG_IS_ENABLED(SPLASH_SCREEN)
@@ -54,6 +56,14 @@ int dram_init(void)
return fdtdec_setup_mem_size_base();
}
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
+
int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 457931faf210..a39b82d05a63 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -32,6 +32,7 @@ CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTSTD_DEFAULTS=y
CONFIG_SYS_BOOTM_LEN=0x80
CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
--
2.43.0
[PATCH 11/11] include: env: ti: Drop default_findfdt
We shouldn't need finfdt anymore. Drop the env script.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-12...@ti.com
include/env/ti/default_findfdt.env | 12
1 file changed, 12 deletions(-)
delete mode 100644 include/env/ti/default_findfdt.env
diff --git a/include/env/ti/default_findfdt.env
b/include/env/ti/default_findfdt.env
deleted file mode 100644
index a2b51dd923bb..
--- a/include/env/ti/default_findfdt.env
+++ /dev/null
@@ -1,12 +0,0 @@
-default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
-default_device_tree_arch=ti
-#ifdef CONFIG_ARM64
-findfdt=
- setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
- setenv fdtfile ${name_fdt}
-#else
-default_device_tree_subarch=omap
-findfdt=
- setenv name_fdt
${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
- setenv fdtfile ${name_fdt}
-#endif
--
2.43.0
[PATCH 09/11] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from C
code.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-10...@ti.com
board/beagle/beagleboneai64/beagleboneai64.c | 14 ++
board/beagle/beagleboneai64/beagleboneai64.env | 1 -
configs/j721e_beagleboneai64_a72_defconfig | 3 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/board/beagle/beagleboneai64/beagleboneai64.c
b/board/beagle/beagleboneai64/beagleboneai64.c
index c8c1c78ae5a2..c5b4ff7df47a 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -28,3 +28,17 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ char fdtfile[50];
+
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+ env_set("fdtfile", fdtfile);
+
+ return 0;
+}
+#endif
diff --git a/board/beagle/beagleboneai64/beagleboneai64.env
b/board/beagle/beagleboneai64/beagleboneai64.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.env
+++ b/board/beagle/beagleboneai64/beagleboneai64.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/configs/j721e_beagleboneai64_a72_defconfig
b/configs/j721e_beagleboneai64_a72_defconfig
index 4b019fa2f30e..3f061381f06c 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -34,7 +34,8 @@ CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d
seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.43.0
[PATCH 01/11] board: ti: Add missing common/Kconfig references
Add missing board/ti/common/Kconfig references for the platforms that missed it. The intent is for the common Kconfig to be usable across TI reference boards as required. Reported-by: Tom Rini Signed-off-by: Nishanth Menon --- Changes since V3: * No change V3: https://lore.kernel.org/r/20240130130615.670783-2...@ti.com board/ti/omap3evm/Kconfig | 2 ++ board/ti/panda/Kconfig| 2 ++ board/ti/sdp4430/Kconfig | 2 ++ 3 files changed, 6 insertions(+) diff --git a/board/ti/omap3evm/Kconfig b/board/ti/omap3evm/Kconfig index 08a8aa20ae85..cd71fe083176 100644 --- a/board/ti/omap3evm/Kconfig +++ b/board/ti/omap3evm/Kconfig @@ -9,4 +9,6 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "omap3_evm" +source "board/ti/common/Kconfig" + endif diff --git a/board/ti/panda/Kconfig b/board/ti/panda/Kconfig index 8f277b612a45..5912f69babe2 100644 --- a/board/ti/panda/Kconfig +++ b/board/ti/panda/Kconfig @@ -9,4 +9,6 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "omap4_panda" +source "board/ti/common/Kconfig" + endif diff --git a/board/ti/sdp4430/Kconfig b/board/ti/sdp4430/Kconfig index 36f185282166..65e9107bc1b0 100644 --- a/board/ti/sdp4430/Kconfig +++ b/board/ti/sdp4430/Kconfig @@ -12,4 +12,6 @@ config SYS_CONFIG_NAME config CMD_BAT bool "Enable board-specific battery command" +source "board/ti/common/Kconfig" + endif -- 2.43.0
[PATCH 07/11] board: ti: j721e: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes since V3:
* No change
V3: https://lore.kernel.org/r/20240130130615.670783-8...@ti.com
board/ti/j721e/evm.c | 8
board/ti/j721e/j721e.env | 10 --
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index b77cffc5ef56..9dc3ed6dfffa 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -16,6 +16,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \
board_ti_k3_is("J721EX-PM2-SOM"))
@@ -353,6 +354,12 @@ static int probe_daughtercards(void)
#endif
#ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
+ {"j721e", "k3-j721e-common-proc-board.dtb"},
+ {"j721e-sk", "k3-j721e-sk.dtb"},
+ {"j7200", "k3-j7200-common-proc-board.dtb"},
+ { /* Sentinel. */ }
+};
static void setup_board_eeprom_env(void)
{
char *name = "j721e";
@@ -372,6 +379,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
}
static void setup_serial(void)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index cb27bf5e2b24..38bfd7d49634 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -7,16 +7,6 @@
#include
#endif
-default_device_tree=ti/k3-j721e-common-proc-board.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- if test $board_name = j721e; then
- setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
- if test $board_name = j7200; then
- setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
- if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
- setenv name_fdt ti/k3-j721e-sk.dtb; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
--
2.43.0
Re: [PATCH 3/4] arm: mach-k3: am62: Add Debounce configuration register definitions
On 09:53-20240212, Nishanth Menon wrote: > Add the Debounce configuration registers that need to be configured one > time for the platform for the entire SoC. > > Signed-off-by: Nishanth Menon > --- > arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h > b/arch/arm/mach-k3/include/mach/am62_hardware.h > index 54380f36e161..06fcab01a5b7 100644 > --- a/arch/arm/mach-k3/include/mach/am62_hardware.h > +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h > @@ -75,6 +75,9 @@ > > #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE + 0x18170) > > +/* Debounce register configuration */ > +#define CTRLMMR_DBOUNCE_CFG(index) (MCU_CTRL_MMR0_BASE + 4080 + > (index * 4)) Grrr.. missed the fixup for 0x4080 here. will wait a couple of days for any other review comments. > + > #define ROM_EXTENDED_BOOT_DATA_INFO 0x43c3f1e0 > > #define TI_SRAM_SCRATCH_BOARD_EEPROM_START 0x43c3 > -- > 2.43.0 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH 1/4] board: beagle: beagleplay: Enable 32k crystal
Enable the external 32k crystal similar to that found on other
production AM62X board. The trim settings for the crystal is board
dependent, so the sequences tend to be board specific. Since this is
a configuration that needs to be done prior to DM managing the system
and all other muxes get set, do the same from R5 context.
Signed-off-by: Nishanth Menon
---
board/beagle/beagleplay/beagleplay.c | 37
1 file changed, 37 insertions(+)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index 20819ecf45b4..a75b3145fa37 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -11,6 +11,8 @@
#include
#include
+#include
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -28,6 +30,41 @@ int dram_init_banksize(void)
return fdtdec_setup_memory_banksize();
}
+#ifdef CONFIG_SPL_BOARD_INIT
+
+/*
+ * Enable the 32k Crystal: needed for accurate 32k clock
+ * and external clock sources such as wlan 32k input clock
+ * supplied from the SoC to the wlan chip.
+ *
+ * The trim setup can be very highly board type specific choice of the crystal
+ * So this is done in the board file, though, in this case, no specific trim
+ * is necessary.
+ */
+static void crystal_32k_enable(void)
+{
+ /* Only mess with 32k at the start of boot from R5 */
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ /*
+* We have external 32k crystal, so lets enable it (0x0)
+* and disable bypass (0x0)
+*/
+ writel(0x0, MCU_CTRL_LFXOSC_CTRL);
+
+ /* Add any crystal specific TRIM needed here.. */
+
+ /* Make sure to mux the SoC 32k from the crystal */
+ writel(MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL,
+ MCU_CTRL_DEVICE_CLKOUT_32K_CTRL);
+ }
+}
+
+void spl_board_init(void)
+{
+ crystal_32k_enable();
+}
+#endif
+
#ifdef CONFIG_BOARD_LATE_INIT
int board_late_init(void)
{
--
2.43.0
[PATCH 4/4] board: beagle: beagleplay: Configure debounce registers
Configure the debounce configuration that makes sense for BeaglePlay
usage model.
Signed-off-by: Nishanth Menon
---
board/beagle/beagleplay/beagleplay.c | 24
1 file changed, 24 insertions(+)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index a75b3145fa37..5640fdf41ed3 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -59,9 +59,33 @@ static void crystal_32k_enable(void)
}
}
+static void debounce_configure(void)
+{
+ /* Configure debounce one time from R5 */
+ if (IS_ENABLED(CONFIG_CPU_V7R)) {
+ /*
+* Setup debounce time registers.
+* arbitrary values. Times are approx
+*/
+ /* 1.9ms debounce @ 32k */
+ writel(0x1, CTRLMMR_DBOUNCE_CFG(1));
+ /* 5ms debounce @ 32k */
+ writel(0x5, CTRLMMR_DBOUNCE_CFG(2));
+ /* 20ms debounce @ 32k */
+ writel(0x14, CTRLMMR_DBOUNCE_CFG(3));
+ /* 46ms debounce @ 32k */
+ writel(0x18, CTRLMMR_DBOUNCE_CFG(4));
+ /* 100ms debounce @ 32k */
+ writel(0x1c, CTRLMMR_DBOUNCE_CFG(5));
+ /* 156ms debounce @ 32k */
+ writel(0x1f, CTRLMMR_DBOUNCE_CFG(6));
+ }
+}
+
void spl_board_init(void)
{
crystal_32k_enable();
+ debounce_configure();
}
#endif
--
2.43.0
[PATCH 2/4] configs: am62x_beagleplay_r5_defconfig: Enable SPL_BOARD_INIT
Enable CONFIG_SPL_BOARD_INIT to configure the 32k crystal. Signed-off-by: Nishanth Menon --- configs/am62x_beagleplay_r5_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am62x_beagleplay_r5_defconfig b/configs/am62x_beagleplay_r5_defconfig index 2f3264b7ede6..9413c859870f 100644 --- a/configs/am62x_beagleplay_r5_defconfig +++ b/configs/am62x_beagleplay_r5_defconfig @@ -36,6 +36,7 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x43c3b000 CONFIG_SPL_BSS_MAX_SIZE=0x3000 CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y +CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_STACK_R=y CONFIG_SPL_SEPARATE_BSS=y -- 2.43.0
[PATCH 0/4] board: beagle: Enable 32k and debounce configuration
Hi, This is a follow up from [1] - Without the 32k crystal configuration, wlan does'nt work. Debounce is needed for HDMI hpd gpio interrupt. At least the 32k configuration has been done for toradex and phytec boards, follow similar model of programming. This series is based on master commit e8f2404e093d + the findfdt series[2]. Nishanth Menon (4): board: beagle: beagleplay: Enable 32k crystal configs: am62x_beagleplay_r5_defconfig: Enable SPL_BOARD_INIT arm: mach-k3: am62: Add Debounce configuration register definitions board: beagle: beagleplay: Configure debounce registers arch/arm/mach-k3/include/mach/am62_hardware.h | 3 + board/beagle/beagleplay/beagleplay.c | 61 +++ configs/am62x_beagleplay_r5_defconfig | 1 + 3 files changed, 65 insertions(+) [1] https://lore.kernel.org/u-boot/20230725185253.2123433-4...@ti.com/ [2] https://lore.kernel.org/all/20240130130615.670783-1...@ti.com/ -- 2.43.0
[PATCH 3/4] arm: mach-k3: am62: Add Debounce configuration register definitions
Add the Debounce configuration registers that need to be configured one time for the platform for the entire SoC. Signed-off-by: Nishanth Menon --- arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h b/arch/arm/mach-k3/include/mach/am62_hardware.h index 54380f36e161..06fcab01a5b7 100644 --- a/arch/arm/mach-k3/include/mach/am62_hardware.h +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h @@ -75,6 +75,9 @@ #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE + 0x18170) +/* Debounce register configuration */ +#define CTRLMMR_DBOUNCE_CFG(index) (MCU_CTRL_MMR0_BASE + 4080 + (index * 4)) + #define ROM_EXTENDED_BOOT_DATA_INFO0x43c3f1e0 #define TI_SRAM_SCRATCH_BOARD_EEPROM_START 0x43c3 -- 2.43.0
Re: [PATCH 2/2] arm: dts: k3-am64: Sync with kernel v6.8-rc1
On 16:27-20240201, Andrew Davis wrote: > Sync with kernel v6.8-rc1 and sync up the u-boot dts files accordingly. > > Signed-off-by: Andrew Davis Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH V3 09/11] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from C
code.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-9...@ti.com
board/beagle/beagleboneai64/beagleboneai64.c | 14 ++
board/beagle/beagleboneai64/beagleboneai64.env | 1 -
configs/j721e_beagleboneai64_a72_defconfig | 3 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/board/beagle/beagleboneai64/beagleboneai64.c
b/board/beagle/beagleboneai64/beagleboneai64.c
index c8c1c78ae5a2..c5b4ff7df47a 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -28,3 +28,17 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ char fdtfile[50];
+
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+ env_set("fdtfile", fdtfile);
+
+ return 0;
+}
+#endif
diff --git a/board/beagle/beagleboneai64/beagleboneai64.env
b/board/beagle/beagleboneai64/beagleboneai64.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.env
+++ b/board/beagle/beagleboneai64/beagleboneai64.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/configs/j721e_beagleboneai64_a72_defconfig
b/configs/j721e_beagleboneai64_a72_defconfig
index 4b019fa2f30e..3f061381f06c 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -34,7 +34,8 @@ CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d
seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.43.0
[PATCH V3 06/11] board: ti: am65x: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-6...@ti.com
board/ti/am65x/am65x.env | 3 ---
board/ti/am65x/evm.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 286b9c300c05..814374d68cf0 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -5,9 +5,6 @@
#include
#endif
-findfdt=
- setenv name_fdt ti/k3-am654-base-board.dtb;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index df209021c1b7..3109c9a2acac 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -22,6 +22,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
@@ -141,6 +142,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(NULL, NULL);
}
static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
--
2.43.0
[PATCH V3 11/11] include: env: ti: Drop default_findfdt
We shouldn't need finfdt anymore. Drop the env script.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-11...@ti.com
include/env/ti/default_findfdt.env | 12
1 file changed, 12 deletions(-)
delete mode 100644 include/env/ti/default_findfdt.env
diff --git a/include/env/ti/default_findfdt.env
b/include/env/ti/default_findfdt.env
deleted file mode 100644
index a2b51dd923bb..
--- a/include/env/ti/default_findfdt.env
+++ /dev/null
@@ -1,12 +0,0 @@
-default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
-default_device_tree_arch=ti
-#ifdef CONFIG_ARM64
-findfdt=
- setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
- setenv fdtfile ${name_fdt}
-#else
-default_device_tree_subarch=omap
-findfdt=
- setenv name_fdt
${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
- setenv fdtfile ${name_fdt}
-#endif
--
2.43.0
[PATCH V3 04/11] board: ti: am62x: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-4...@ti.com
board/ti/am62x/am62x.env| 1 -
board/ti/am62x/evm.c| 8
configs/am62x_evm_a53_defconfig | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index e53a55c38fbb..9cb186c2a03c 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 88e02155ee33..be578f131726 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -54,6 +54,14 @@ int dram_init(void)
return fdtdec_setup_mem_size_base();
}
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
+
int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 457931faf210..a39b82d05a63 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -32,6 +32,7 @@ CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTSTD_DEFAULTS=y
CONFIG_SYS_BOOTM_LEN=0x80
CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
--
2.43.0
[PATCH V3 05/11] board: ti: am64x: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-5...@ti.com
board/ti/am64x/am64x.env | 9 -
board/ti/am64x/evm.c | 8
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index efd736b99be4..9a8812d4ee54 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -2,14 +2,6 @@
#include
#include
-findfdt=
- if test $board_name = am64x_gpevm; then
- setenv name_fdt ti/k3-am642-evm.dtb; fi;
- if test $board_name = am64x_skevm; then
- setenv name_fdt ti/k3-am642-sk.dtb; fi;
- if test $name_fdt = undefined; then
- echo WARNING: Could not determine device tree to use; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
@@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
usbboot=setenv boot usb;
setenv bootpart 0:2;
usb start;
- run findfdt;
run init_usb;
run get_kern_usb;
run get_fdt_usb;
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index a7ca6be436eb..b8de69da06c5 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -16,6 +16,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
board_ti_k3_is("AM64-EVM") || \
@@ -181,6 +182,12 @@ int checkboard(void)
}
#ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
+ {"am64x_gpevm", "k3-am642-evm.dtb"},
+ {"am64x_skevm", "k3-am642-sk.dtb"},
+ { /* Sentinel. */ }
+};
+
static void setup_board_eeprom_env(void)
{
char *name = "am64x_gpevm";
@@ -198,6 +205,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_am64_evm_fdt_map);
}
static void setup_serial(void)
--
2.43.0
[PATCH V3 07/11] board: ti: j721e: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-7...@ti.com
board/ti/j721e/evm.c | 8
board/ti/j721e/j721e.env | 10 --
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index b77cffc5ef56..9dc3ed6dfffa 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -16,6 +16,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \
board_ti_k3_is("J721EX-PM2-SOM"))
@@ -353,6 +354,12 @@ static int probe_daughtercards(void)
#endif
#ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
+ {"j721e", "k3-j721e-common-proc-board.dtb"},
+ {"j721e-sk", "k3-j721e-sk.dtb"},
+ {"j7200", "k3-j7200-common-proc-board.dtb"},
+ { /* Sentinel. */ }
+};
static void setup_board_eeprom_env(void)
{
char *name = "j721e";
@@ -372,6 +379,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
}
static void setup_serial(void)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index cb27bf5e2b24..38bfd7d49634 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -7,16 +7,6 @@
#include
#endif
-default_device_tree=ti/k3-j721e-common-proc-board.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- if test $board_name = j721e; then
- setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
- if test $board_name = j7200; then
- setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
- if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
- setenv name_fdt ti/k3-j721e-sk.dtb; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
--
2.43.0
[PATCH V3 03/11] board: ti: am62ax: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-3...@ti.com
board/ti/am62ax/am62ax.env | 1 -
board/ti/am62ax/evm.c| 10 ++
configs/am62ax_evm_a53_defconfig | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index a6d967e982d4..334374abb73e 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
index cd3360a43029..62d3664936e7 100644
--- a/board/ti/am62ax/evm.c
+++ b/board/ti/am62ax/evm.c
@@ -13,6 +13,8 @@
#include
#include
+#include "../common/fdt_ops.h"
+
int board_init(void)
{
return 0;
@@ -27,3 +29,11 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 38083586a3ec..e5fcd8cc5b6f 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -24,6 +24,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTSTD_DEFAULTS=y
CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_PAD_TO=0x0
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.43.0
[PATCH V3 02/11] board: ti: common: Introduce a common fdt ops library
Introduce a common fdt operations library for basic device tree
operations that are common between various boards.
The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-2...@ti.com
board/ti/common/Kconfig | 12
board/ti/common/Makefile | 1 +
board/ti/common/fdt_ops.c | 64 +++
board/ti/common/fdt_ops.h | 42 +
4 files changed, 119 insertions(+)
create mode 100644 board/ti/common/fdt_ops.c
create mode 100644 board/ti/common/fdt_ops.h
diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab..de44e4de2115 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
imply CMD_SPI
imply CMD_TIME
imply CMD_USB if USB
+
+config TI_FDT_FOLDER_PATH
+ string "Location of Folder path where dtb is present"
+ default "ti/davinci" if ARCH_DAVINCI
+ default "ti/keystone" if ARCH_KEYSTONE
+ default "ti/omap" if ARCH_OMAP2PLUS
+ default "ti" if ARCH_K3
+ depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
+ help
+ Folder path for kernel device tree default.
+ This is used along with fdtfile path to locate the kernel
+ device tree blob.
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 26bf12e2e6d5..5ac361ba7fcf 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -3,3 +3,4 @@
obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
new file mode 100644
index ..eb917be9e0da
--- /dev/null
+++ b/board/ti/common/fdt_ops.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Library to support FDT file operations which are common
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include
+#include "fdt_ops.h"
+
+void ti_set_fdt_env(const char *board_name, struct ti_fdt_map *fdt_map)
+{
+ char *fdt_file_name = NULL;
+ char fdtfile[TI_FDT_FILE_MAX];
+
+ if (board_name) {
+ while (fdt_map) {
+ /* Check for NULL terminator in the list */
+ if (!fdt_map->board_name)
+ break;
+ if (!strncmp(fdt_map->board_name, board_name,
TI_BOARD_NAME_MAX)) {
+ fdt_file_name = fdt_map->fdt_file_name;
+ break;
+ }
+ fdt_map++;
+ }
+ }
+
+ /* match not found OR null board_name */
+ if (!fdt_file_name) {
+ /*
+* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
+* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
+*/
+#ifdef CONFIG_DEFAULT_FDT_FILE
+ if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
+CONFIG_TI_FDT_FOLDER_PATH,
CONFIG_DEFAULT_FDT_FILE);
+ } else
+#endif
+ {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH,
CONFIG_DEFAULT_DEVICE_TREE);
+ }
+ } else {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
CONFIG_TI_FDT_FOLDER_PATH,
+fdt_file_name);
+ }
+
+ env_set("fdtfile", fdtfile);
+
+ /*
+* XXX: DEPRECATION WARNING: 2 u-boot versions (2024.10).
+*
+* Maintain compatibility with downstream scripts that may be using
+* name_fdt
+*/
+ if (board_name)
+ env_set("name_fdt", fdtfile);
+ /* Also set the findfdt legacy script to warn users to stop using this
*/
+ env_set("findfdt",
+ "echo WARN: fdtfile already set. Stop using findfdt in script");
+}
diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
new file mode 100644
index ..5d304994fb6e
--- /dev/null
+++ b/board/ti/common/fdt_ops.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Library to support common device tree manipulation for TI EVMs
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#ifndef __FDT_OPS_H
+#define __FDT_O
[PATCH V3 10/11] board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from C
code.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-10...@ti.com
board/beagle/beagleplay/beagleplay.c | 14 ++
board/beagle/beagleplay/beagleplay.env | 1 -
configs/am62x_beagleplay_a53_defconfig | 3 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index 1c376dea372f..20819ecf45b4 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -27,3 +27,17 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ char fdtfile[50];
+
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+ env_set("fdtfile", fdtfile);
+
+ return 0;
+}
+#endif
diff --git a/board/beagle/beagleplay/beagleplay.env
b/board/beagle/beagleplay/beagleplay.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/configs/am62x_beagleplay_a53_defconfig
b/configs/am62x_beagleplay_a53_defconfig
index 0be20045a974..1f43891d10bb 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -33,7 +33,8 @@ CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
--
2.43.0
[PATCH V3 01/11] board: ti: Add missing common/Kconfig references
Add missing board/ti/common/Kconfig references for the platforms that missed it. The intent is for the common Kconfig to be usable across TI reference boards as required. Reported-by: Tom Rini Signed-off-by: Nishanth Menon --- New patch: Fixed build fail that Tom noted: https://lore.kernel.org/all/20240120163625.GA3665999@bill-the-cat/ board/ti/omap3evm/Kconfig | 2 ++ board/ti/panda/Kconfig| 2 ++ board/ti/sdp4430/Kconfig | 2 ++ 3 files changed, 6 insertions(+) diff --git a/board/ti/omap3evm/Kconfig b/board/ti/omap3evm/Kconfig index 08a8aa20ae85..cd71fe083176 100644 --- a/board/ti/omap3evm/Kconfig +++ b/board/ti/omap3evm/Kconfig @@ -9,4 +9,6 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "omap3_evm" +source "board/ti/common/Kconfig" + endif diff --git a/board/ti/panda/Kconfig b/board/ti/panda/Kconfig index 8f277b612a45..5912f69babe2 100644 --- a/board/ti/panda/Kconfig +++ b/board/ti/panda/Kconfig @@ -9,4 +9,6 @@ config SYS_VENDOR config SYS_CONFIG_NAME default "omap4_panda" +source "board/ti/common/Kconfig" + endif diff --git a/board/ti/sdp4430/Kconfig b/board/ti/sdp4430/Kconfig index 36f185282166..65e9107bc1b0 100644 --- a/board/ti/sdp4430/Kconfig +++ b/board/ti/sdp4430/Kconfig @@ -12,4 +12,6 @@ config SYS_CONFIG_NAME config CMD_BAT bool "Enable board-specific battery command" +source "board/ti/common/Kconfig" + endif -- 2.43.0
[PATCH V3 08/11] board: ti: j721s2: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Reviewed-by: Jonathan Humphreys
Reviewed-by: Roger Quadros
Signed-off-by: Nishanth Menon
---
Changes in V3:
- none other than picking up reviews.
V2: https://lore.kernel.org/r/20240109191506.3820908-8...@ti.com
board/ti/j721s2/evm.c | 8
board/ti/j721s2/j721s2.env | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 1220cd84519b..5a0281d6b483 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -23,6 +23,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -114,6 +115,12 @@ int checkboard(void)
return 0;
}
+static struct ti_fdt_map ti_j721s2_evm_fdt_map[] = {
+ {"j721s2", "k3-j721s2-common-proc-board.dtb"},
+ {"am68-sk", "k3-am68-sk-base-board.dtb"},
+ { /* Sentinel. */ }
+};
+
static void setup_board_eeprom_env(void)
{
char *name = "j721s2";
@@ -131,6 +138,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_j721s2_evm_fdt_map);
}
static void setup_serial(void)
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 64e3d9da85f0..9a03b9f30aee 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -7,14 +7,6 @@
#include
#endif
-default_device_tree=ti/k3-j721s2-common-proc-board.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- if test $board_name = j721s2; then \
- setenv name_fdt ti/k3-j721s2-common-proc-board.dtb; fi;
- if test $board_name = am68-sk; then
- setenv name_fdt ti/k3-am68-sk-base-board.dtb; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
--
2.43.0
[PATCH V3 00/11] board/ti: k3 boards: Stop using findfdt
This is a wide cleanup to switch to setting fdtfile using env_set instead of scripted magic. 'fdtfile' is expected to be set by default. This allows the stdboot triggered efi loaders to find the correct OS device tree file even if regular boot process is interrupted by user intervention. Updates from V2: * New patch #1 added for older omap platform build breakage (sorry about that) Bootlogs (no change from V1): https://gist.github.com/nmenon/843e343cde645ec4aa57b60cece5256a based on master 6faba41927bd Prepare v2024.04-rc1 NOTE: There are a couple of checkpatch WARN (around LATE_INIT) and CHECK (fdt_ops #ifdeffery) that on closer inspection looks fine and consistent with other similar usage. V2: https://lore.kernel.org/all/20240109191506.3820908-1...@ti.com/ V1: https://lore.kernel.org/all/20240108173301.2692332-1...@ti.com/ Nishanth Menon (11): board: ti: Add missing common/Kconfig references board: ti: common: Introduce a common fdt ops library board: ti: am62ax: Set fdtfile from C code instead of findfdt script board: ti: am62x: Set fdtfile from C code instead of findfdt script board: ti: am64x: Set fdtfile from C code instead of findfdt script board: ti: am65x: Set fdtfile from C code instead of findfdt script board: ti: j721e: Set fdtfile from C code instead of findfdt script board: ti: j721s2: Set fdtfile from C code instead of findfdt script board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script include: env: ti: Drop default_findfdt board/beagle/beagleboneai64/beagleboneai64.c | 14 .../beagle/beagleboneai64/beagleboneai64.env | 1 - board/beagle/beagleplay/beagleplay.c | 14 board/beagle/beagleplay/beagleplay.env| 1 - board/ti/am62ax/am62ax.env| 1 - board/ti/am62ax/evm.c | 10 +++ board/ti/am62x/am62x.env | 1 - board/ti/am62x/evm.c | 8 +++ board/ti/am64x/am64x.env | 9 --- board/ti/am64x/evm.c | 8 +++ board/ti/am65x/am65x.env | 3 - board/ti/am65x/evm.c | 2 + board/ti/common/Kconfig | 12 board/ti/common/Makefile | 1 + board/ti/common/fdt_ops.c | 64 +++ board/ti/common/fdt_ops.h | 42 board/ti/j721e/evm.c | 8 +++ board/ti/j721e/j721e.env | 10 --- board/ti/j721s2/evm.c | 8 +++ board/ti/j721s2/j721s2.env| 8 --- board/ti/omap3evm/Kconfig | 2 + board/ti/panda/Kconfig| 2 + board/ti/sdp4430/Kconfig | 2 + configs/am62ax_evm_a53_defconfig | 1 + configs/am62x_beagleplay_a53_defconfig| 3 +- configs/am62x_evm_a53_defconfig | 1 + configs/j721e_beagleboneai64_a72_defconfig| 3 +- include/env/ti/default_findfdt.env| 12 28 files changed, 203 insertions(+), 48 deletions(-) create mode 100644 board/ti/common/fdt_ops.c create mode 100644 board/ti/common/fdt_ops.h delete mode 100644 include/env/ti/default_findfdt.env base-commit: 6faba41927bdc8973b59678649ef83c564cc421e -- 2.43.0
Re: [PATCH V4 2/2] firmware: ti_sci: Add comment explaining the is_secure code
On 17:28-20240130, Dhruva Gole wrote:
> Add a comment to explain the code under is_secure condition of
> ti_sci_do_xfer. This will help avoid confusion amongst people who may in
> future touch upon this code.
>
> Signed-off-by: Dhruva Gole
> ---
> drivers/firmware/ti_sci.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index 49d2696a6d09..d969470b5221 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -239,6 +239,12 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> ti_sci_secure_msg_hdr *)secure_buf;
> int ret;
>
> + /*
> + * The reason why we need the is_secure code is because of boot R5.
> + * boot R5 starts off in "secure mode" when it hands off from Boot
> + * ROM over to the Secondary bootloader. The initial set of calls
> + * we have to make need to be on a secure pipe.
> + */
> if (info->is_secure) {
> /* ToDo: get checksum of the entire message */
> secure_hdr->checksum = 0;
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V4 1/2] firmware: ti_sci: fix the secure_hdr in do_xfer
On 17:28-20240130, Dhruva Gole wrote:
> The ti_sci driver in U-Boot has support for secure_msg as part of it's
> do_xfer function. This let's U-boot send secure messages during boot up.
>
> The protocol to send such secure messages is described as part of the
> struct ti_sci_secure_msg_hdr. As part of this, there are 2 fields for
> checksum and reserved that occupy the first 4 bytes of any secure
> message. This is called as the secure_hdr.
>
> As of now, the secure_hdr needs to be 0 init-ed before sending secure
> messages. However the existing code was never putting the zero-inited vars
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make secure_hdr members 0, it automatically ensures
> the first 4 bytes of secure_buf are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Cc: Nishanth Menon
> Cc: Andrew Davis
> Cc: Manorit Chawdhry
> Signed-off-by: Dhruva Gole
> ---
> drivers/firmware/ti_sci.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> index 6e9f93e9a302..49d2696a6d09 100644
> --- a/drivers/firmware/ti_sci.c
> +++ b/drivers/firmware/ti_sci.c
> @@ -236,21 +236,21 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> {
> struct k3_sec_proxy_msg *msg = >tx_message;
> u8 secure_buf[info->desc->max_msg_size];
> - struct ti_sci_secure_msg_hdr secure_hdr;
> + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> ti_sci_secure_msg_hdr *)secure_buf;
> int ret;
>
> if (info->is_secure) {
> /* ToDo: get checksum of the entire message */
> - secure_hdr.checksum = 0;
> - secure_hdr.reserved = 0;
I was thinking originally just adding memcpy(secure_buf, secure_hdr,
sizeof(secure_hdr)) would save all the churn.. but anyways.. we save
allocating secure_hdr struct.. not a big saving, but better code
anyways..
> - memcpy(_buf[sizeof(secure_hdr)], xfer->tx_message.buf,
> + secure_hdr->checksum = 0;
> + secure_hdr->reserved = 0;
> + memcpy(_buf[sizeof(struct ti_sci_secure_msg_hdr)],
> xfer->tx_message.buf,
> xfer->tx_message.len);
here and below:
s/sizeof(var)/sizeof(*var) instead of sizeof(struct ... ) is probably
all the change we need? rather than converting it to sizeof(struct ..)?
same below. this would allow (theoretically), that the structure
name to change for secure_hdr and there would be less churn? not that it
matters here.. just a style thing..
Either way:
Reviewed-by: Nishanth Menon
>
> xfer->tx_message.buf = (u32 *)secure_buf;
> - xfer->tx_message.len += sizeof(secure_hdr);
> + xfer->tx_message.len += sizeof(struct ti_sci_secure_msg_hdr);
>
> if (xfer->rx_len)
> - xfer->rx_len += sizeof(secure_hdr);
> + xfer->rx_len += sizeof(struct ti_sci_secure_msg_hdr);
> }
>
> /* Send the message */
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V3] firmware: ti_sci: fix the secure_hdr in do_xfer
On 11:44-20240129, Dhruva Gole wrote:
> On Jan 24, 2024 at 12:09:06 -0600, Nishanth Menon wrote:
> > On 18:37-20240124, Dhruva Gole wrote:
> > > The secure_hdr needs to be 0 init-ed however this was never being put
> > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > secure_buf being possibly garbage.
> > >
> > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > location, thus when we make it 0, it automatically ensures the first 4
> > > bytes are 0.
> > >
> > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> > > Interface (TI SCI)")
> > > Signed-off-by: Dhruva Gole
> > > ---
> > >
> > > Boot tested for sanity on AM62x SK
> > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > >
> > > Changelog:
> > > v2 --> v3
> > > Address Kamlesh's comment on v2: use sizeof(struct ti_sci_secure_msg_hdr)
> >
> > Lets finish discussing in:
> > https://lore.kernel.org/all/20240124163910.sp7gt56lihoujm7k@etching/
>
> Bringing the conversation back to this latest patch revision,
> Based on where we left off:
> https://lore.kernel.org/all/20240125171335.qoxphnemadkh7xjd@gullible/
>
> Would it be better to add a comment above ``if (info->is_secure) {`` in
> drivers/firmware/ti_sci.c as follows:
> The secure path will be used by R5 SPL bcause it starts of in "secure mode"
> when it hands
> off from Boot ROM over to the Secondary bootloader.
>
> Kindly advise if the patch needs respin with that minor change, and if the
> rest
> of it seems okay?
>
improve the commit message and add a documentation patch to add
information around if (info->is_secure) please, so that we don't yet
again need to dig up history.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v8 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 17:02-20240129, Apurva Nandan wrote:
> Hi,
>
> On 24/01/24 02:17, Nishanth Menon wrote:
> > On 20:21-20240123, Apurva Nandan wrote:
> > [...]
> > > > > +void k3_mem_init(void)
> > > > > +{
> > > > > + struct udevice *dev;
> > > > > + int ret, ctr = 1;
> > > > > +
> > > > > + if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
> > > > > + ret = uclass_get_device(UCLASS_RAM, 0, );
> > > > > + if (ret)
> > > > > + panic("DRAM 0 init failed: %d\n", ret);
> > > > > +
> > > > > + while (dev) {
> > > > why loop on dev? is it possible to have ret != 0 and dev = 0?
> > > >
> > > Some variable needs to be used for loop condition, do you want it to be
> > > ret?
> > > or maybe you can suggest your idea for this please.
> > > > > + ret = uclass_next_device_err();
> > > > > + if (ret) {
> > > > > + printf("Initialized %d DRAM
> > > > > controllers\n", ctr);
> > > > > + break;
> > > > > + }
> > > > > + ctr++;
> > > > What is the use of ctr++ ?? please do a limit check for instances.
> > > This is to keep the logic independent of board evm, so that no include of
> > > EVM config is needed.
> > > ctr is just used to notify user about how many DDR are up during boot,
> > > else
> > > it is not needed.
> > >
> > > I can remove the ctr and printf, if you want.
> > >
> > > For a limit check, how can we get number of DDR instances on the EVM, I
> > > don't know, can you please suggest some way?
> > >
> > > There is no config that stores this info afaik.
> > Why? J784s4 has only specific number of controllerns, correct?
> >
> > A variant of the below -> but still have a question:
> >
> > while (ctrl < J784S4_MAX_CONTROLLERS) {
>
> Is J784S4_MAX_CONTROLLERS going to be a #define in j784s4_init.c
>
> Or a Kconfig option like:
>
> config DDR_MAX_CONTROLLERS
> Â Â Â int "Max number of DRAM controllers"
> Â Â Â default 4 if SOC_K3_J784S4
> Â Â Â default 1
> Â Â Â help
>
I dont see a need for Kconfig - but that is just me.
> > ret = uclass_next_device_err();
> > if (ret) /* Question: How do we differentiate between valid
> > * failure and next instance not being present? */
> > break;
>
> how about:
>
> Â Â Â Â Â Â Â Â Â ...
> Â Â Â if (ret == -ENODEV)
> Â Â Â Â Â Â Â Â Â Â Â Â break;
>
> Â Â Â if (ret)
>       panic("DRAM %d init failed: %d\n", ctrl, ret);
> Â Â Â ...
What ever is appropriate.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On 10:55-20240125, Andrew Davis wrote: > I'd say since U-Boot today cannot send over secure channels anyway, > lets just drop this code and if we ever need it then we add it back > over in the right spot at that time. Chatting with manorit, the reason why we need the secure code is because of boot R5. boot R5 starts of in "secure mode" when it hands off from Boot ROM over to the Secondary bootloader. The initial set of calls we have to make unfortunately needs to be on secure pipe (think j721e load sysfw call, board config load call etc..) - which needs this support - which again, we should probably document in the code so that people don't go scratching our heads again. That is unfortunately confusing enough for code since 99% of rest of u-boot flow does not use secure comm path. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [RFC PATCH v3 02/15] misc: fs-loader: Use fw_storage_interface instead of storage_interface
On 12:19-20240124, MD Danish Anwar wrote:
> The fs-loader driver reads env storage_interface and uses it to load
> firmware file into memory using the medium set by env. Update the driver
> to use env fw_storage_interface as this variable is only used to load
> firmwares. The env storage_interface will act as fallback so that the
> existing implementations do not break.
>
> Also update the FS Loader documentation accordingly.
>
> Signed-off-by: MD Danish Anwar
> ---
> doc/develop/driver-model/fs_firmware_loader.rst | 5 -
> drivers/misc/fs_loader.c| 5 -
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/doc/develop/driver-model/fs_firmware_loader.rst
> b/doc/develop/driver-model/fs_firmware_loader.rst
> index 149b8b436e..410cc1442d 100644
> --- a/doc/develop/driver-model/fs_firmware_loader.rst
> +++ b/doc/develop/driver-model/fs_firmware_loader.rst
> @@ -98,8 +98,11 @@ through the U-Boot environment variable during run time.
>
> For examples:
>
> +fw_storage_interface:
> + Firmware storage interface, it can be "mmc", "usb", "sata" or "ubi".
> storage_interface:
> - Storage interface, it can be "mmc", "usb", "sata" or "ubi".
> + Storage interface, it can be "mmc", "usb", "sata" or "ubi". This acts
> + as a fallback if fw_storage_interface is not set.
> fw_dev_part:
>Block device number and its partition, it can be "0:1".
> fw_ubi_mtdpart:
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 1ffc199ba1..3798dab5b6 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -153,7 +153,10 @@ static int fw_get_filesystem_firmware(struct udevice
> *dev)
> char *storage_interface, *dev_part, *ubi_mtdpart, *ubi_volume;
> int ret;
>
> - storage_interface = env_get("storage_interface");
> + storage_interface = env_get("fw_storage_interface");
> + if (!storage_interface)
> + storage_interface = env_get("storage_interface");
> +
> dev_part = env_get("fw_dev_part");
> ubi_mtdpart = env_get("fw_ubi_mtdpart");
> ubi_volume = env_get("fw_ubi_volume");
> --
> 2.34.1
>
You should move these specific patches out of the series and debate on
their merits seperately. mixing things like these in a single series
that needs to go to multiple u-boot custodians just creates problems for
everyone.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 1/2] env: ti: mmc: add save_uenv command
On 12:56-20240124, Manorit Chawdhry wrote:
> This is to make easier development with uEnv.txt to update from the
> board on the fly from u-boot to MMC boot media.
>
> Signed-off-by: Manorit Chawdhry
> ---
> include/env/ti/mmc.env | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/env/ti/mmc.env b/include/env/ti/mmc.env
> index 0256a2d2aaca..886e4cab36fe 100644
> --- a/include/env/ti/mmc.env
> +++ b/include/env/ti/mmc.env
> @@ -34,6 +34,9 @@ envboot=if mmc dev ${mmcdev}; then
> fi;
> fi;
>fi;
> +save_uenv=
> + env export -t $loadaddr $save_to_env save_to_env;
> + fatwrite mmc ${mmcdev} ${loadaddr} ${bootenvfile} ${filesize};
Please NO! saveenv has ability.. why not use that? it is better to
improve the commands themselves.
> mmcloados=
> if test ${boot_fdt} = yes || test ${boot_fdt} = try; then
> if run get_fdt_mmc; then
>
> --
> 2.43.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V3] firmware: ti_sci: fix the secure_hdr in do_xfer
On 18:37-20240124, Dhruva Gole wrote:
> The secure_hdr needs to be 0 init-ed however this was never being put
> into the secure_buf, leading to possibility of the first 4 bytes of
> secure_buf being possibly garbage.
>
> Fix this by initialising the secure_hdr itself to the secure_buf
> location, thus when we make it 0, it automatically ensures the first 4
> bytes are 0.
>
> Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> Interface (TI SCI)")
> Signed-off-by: Dhruva Gole
> ---
>
> Boot tested for sanity on AM62x SK
> https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
>
> Changelog:
> v2 --> v3
> Address Kamlesh's comment on v2: use sizeof(struct ti_sci_secure_msg_hdr)
Lets finish discussing in:
https://lore.kernel.org/all/20240124163910.sp7gt56lihoujm7k@etching/
Responding to keep patchworks happy.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On 23:07-20240124, Dhruva Gole wrote:
> On Jan 24, 2024 at 10:39:10 -0600, Nishanth Menon wrote:
> > On 18:38-20240124, Dhruva Gole wrote:
> > > On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> > > > Dhruva Gole writes:
> > > >
> > > > > The secure_hdr needs to be 0 init-ed however this was never being put
> > > > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > > > secure_buf being possibly garbage.
> > > > >
> > > > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > > > location, thus when we make it 0, it automatically ensures the first 4
> > > > > bytes are 0.
> > > > >
> > > > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System
> > > > > Control Interface (TI SCI)")
> > > > > Signed-off-by: Dhruva Gole
> > > > > ---
> > > > >
> > > > > Boot tested for sanity on AM62x SK
> > > > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > > > >
> > > > > Cc: Nishanth Menon
> > > > > Cc: Tom Rini
> > > > >
> > > > > drivers/firmware/ti_sci.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > > > > index f5f659c11274..83ee8401a731 100644
> > > > > --- a/drivers/firmware/ti_sci.c
> > > > > +++ b/drivers/firmware/ti_sci.c
> > > > > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info
> > > > > *info,
> > > > > {
> > > > > struct k3_sec_proxy_msg *msg = >tx_message;
> > > > > u8 secure_buf[info->desc->max_msg_size];
> > > > > - struct ti_sci_secure_msg_hdr secure_hdr;
> > > > > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > > > > ti_sci_secure_msg_hdr *)secure_buf;
> > > > > int ret;
> > > > >
> > > > > if (info->is_secure) {
> > > > > /* ToDo: get checksum of the entire message */
> > > > > - secure_hdr.checksum = 0;
> > > > > - secure_hdr.reserved = 0;
> > > > > + secure_hdr->checksum = 0;
> > > > > + secure_hdr->reserved = 0;
> > > > >
> > > > > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> > > > secure_hdr is pointer now, the value may be same but (struct
> > > > ti_sci_secure_msg_hdr) would make more sense
> > >
> > > Good catch Kamlesh! I have sent a new revision addressing this.
> > >
> >
> > Makes no sense why we have secure API support in U-Boot. what is using
> > this?
>
> In my understanding of generic K3 boot flow, things like proc_boot and
> even applying or removing of firewalls will need a secure channel to
> talk to TIFS right? From my understanding secure host can only talk to
> TIFS and make such requests hence secure API.
U-boot runs in NS world, you cant even talk to the Trustzone Sec proxy
without triggering a firewall violation.
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/TISCI_header.html?highlight=header#secure-messaging-header
"The Secure Messaging Header is only required when sending messages over
secure transport. Messages sent over non-secure transport must not
contain the secure messaging header."
btw, that checksum field should be renamed integ_check, but anyways..
So, I do not see a reason to even have that if condition in the first
place and what real bug was getting fixed in this patch.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH] firmware: ti_sci: fix the secure_hdr in do_xfer
On 18:38-20240124, Dhruva Gole wrote:
> On Jan 24, 2024 at 16:42:12 +0530, Kamlesh Gurudasani wrote:
> > Dhruva Gole writes:
> >
> > > The secure_hdr needs to be 0 init-ed however this was never being put
> > > into the secure_buf, leading to possibility of the first 4 bytes of
> > > secure_buf being possibly garbage.
> > >
> > > Fix this by initialising the secure_hdr itself to the secure_buf
> > > location, thus when we make it 0, it automatically ensures the first 4
> > > bytes are 0.
> > >
> > > Fixes: 32cd25128bd849 ("firmware: Add basic support for TI System Control
> > > Interface (TI SCI)")
> > > Signed-off-by: Dhruva Gole
> > > ---
> > >
> > > Boot tested for sanity on AM62x SK
> > > https://gist.github.com/DhruvaG2000/724ceba3a0db03f4b0bff47de1160074
> > >
> > > Cc: Nishanth Menon
> > > Cc: Tom Rini
> > >
> > > drivers/firmware/ti_sci.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
> > > index f5f659c11274..83ee8401a731 100644
> > > --- a/drivers/firmware/ti_sci.c
> > > +++ b/drivers/firmware/ti_sci.c
> > > @@ -236,13 +236,13 @@ static int ti_sci_do_xfer(struct ti_sci_info *info,
> > > {
> > > struct k3_sec_proxy_msg *msg = >tx_message;
> > > u8 secure_buf[info->desc->max_msg_size];
> > > - struct ti_sci_secure_msg_hdr secure_hdr;
> > > + struct ti_sci_secure_msg_hdr *secure_hdr = (struct
> > > ti_sci_secure_msg_hdr *)secure_buf;
> > > int ret;
> > >
> > > if (info->is_secure) {
> > > /* ToDo: get checksum of the entire message */
> > > - secure_hdr.checksum = 0;
> > > - secure_hdr.reserved = 0;
> > > + secure_hdr->checksum = 0;
> > > + secure_hdr->reserved = 0;
> > > memcpy(_buf[sizeof(secure_hdr)],xfer->tx_message.buf,
> > secure_hdr is pointer now, the value may be same but (struct
> > ti_sci_secure_msg_hdr) would make more sense
>
> Good catch Kamlesh! I have sent a new revision addressing this.
>
Makes no sense why we have secure API support in U-Boot. what is using
this?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 07/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS
On 15:49-20240122, Chintan Vankar wrote: > > On 12/01/24 18:00, Nishanth Menon wrote: > > On 12:17-20240112, Siddharth Vadapalli wrote: > > > From: Kishon Vijay Abraham I > > > > > > In order to support Ethernet boot on AM62x, probe AM65 CPSW NUSS driver > > > in board_init_f(). > > Why? doesn't the DM framework handle this? > Can you suggest how can we do this ? Did'nt you guys just discuss this in https://lore.kernel.org/all/48c63fc4-9f06-4066-b206-a0a548936...@ti.com/ ? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v8 12/16] arm: dts: Introduce j784s4 u-boot dts files
On 20:28-20240123, Apurva Nandan wrote:
>
[...]
> > in j784s4-binman.dtsi:
> >
> >
> >{
> > j784s4_tiboot3_hs_fs_template: template-9 {
> >
> > and then in sk.dtsi:
> sk.dtsi means sk-uboot.dtsi or sk-binman.dtsi?
you wont need an sk-binman.dtsi with template. sk-u-boot.dtsi and
r5-sk.dts ofcourse will instantiate the required templates!
> > {
> >ti-j784s4-hs-evm.bin {
> > insert-template =<_tiboot3_hs_fs_template>;
> > };
> > };
> >
> > This allows boards to readily include the template for the binaries of
> > choice and generate just relevant output. Wont it save much confusion?
> >
> > [...]
> It is still little unclear what is the full thing that you are recommending
> to implement here.
> From what I understood, is it as follows?
>
> - Three binman files will be there: j784s4-binman.dtsi (soc binman),
> j784s4-evm-binman.dtsi and am69-sk-binman.dtsi (board binman)
Nope. just j784s4-binman.dtsi with bin file templates for different kinds
of devices.
> - j784s4-binman.dtsi will be a SoC binman, and will have only templates for
> all tiboot3 gp, hs, hsfs, and tispl/uboot
tiboot3.bin is a an example, but you should do templates for other files
(tispl, u-boot.img... )as well on similar lines. So all a board file
ideally should instantiate is device types it wants and overrides of
dtbs it needs.
> - The board binman files will include these templates and update the dtb
> files in them.
Correct.
> - Final board.dts will use the correct board-binman.dtsi files
if the templates are abstract enough, the additional code will be so
minimal that we wont need a board-binman.dtsi - just u-boot.dtsi and
r5.dtsi can include the relevant templates.
Hope this helps.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v8 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 20:21-20240123, Apurva Nandan wrote:
[...]
> > > +void k3_mem_init(void)
> > > +{
> > > + struct udevice *dev;
> > > + int ret, ctr = 1;
> > > +
> > > + if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
> > > + ret = uclass_get_device(UCLASS_RAM, 0, );
> > > + if (ret)
> > > + panic("DRAM 0 init failed: %d\n", ret);
> > > +
> > > + while (dev) {
> > why loop on dev? is it possible to have ret != 0 and dev = 0?
> >
> Some variable needs to be used for loop condition, do you want it to be ret?
> or maybe you can suggest your idea for this please.
> > > + ret = uclass_next_device_err();
> > > + if (ret) {
> > > + printf("Initialized %d DRAM controllers\n",
> > > ctr);
> > > + break;
> > > + }
> > > + ctr++;
> > What is the use of ctr++ ?? please do a limit check for instances.
> This is to keep the logic independent of board evm, so that no include of
> EVM config is needed.
> ctr is just used to notify user about how many DDR are up during boot, else
> it is not needed.
>
> I can remove the ctr and printf, if you want.
>
> For a limit check, how can we get number of DDR instances on the EVM, I
> don't know, can you please suggest some way?
>
> There is no config that stores this info afaik.
Why? J784s4 has only specific number of controllerns, correct?
A variant of the below -> but still have a question:
while (ctrl < J784S4_MAX_CONTROLLERS) {
ret = uclass_next_device_err();
if (ret) /* Question: How do we differentiate between valid
* failure and next instance not being present? */
break;
ctrl++;
}
info("Initialized %d DRAM controllers\n", ctrl - 1);
>
> >
> > [...]
> >
> > Next time, please respond to the review comment questions so that I
> > know that you have considered and decided something is not necessary
> > or something was missed in the new version - for example what happened
> > to mmc_stop/restart?
> mmc_stop/restart were removed (mentioned in series changelog)
Mentioning in diffstat of the patch helps give people the context of the
change w.r.t the path itself.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v8 09/16] board: ti: j784s4: Add board support for J784S4 EVM
On 23:20-20240119, Apurva Nandan wrote: > Add board files for J784S4 EVM. > > SYS_DISABLE_DCACHE_OPS is selected in the Kconfig because > J784S4/AM69 are a coherent architecture at A72 level by > MSMC support. > > Signed-off-by: Hari Nagalla > [ add env and board specific yaml files for binman ] Neither of them are part of this patch? > Signed-off-by: Neha Malcom Francis > [ cleaned up the env files ] no env file in this patch? > Signed-off-by: Manorit Chawdhry > Signed-off-by: Dasnavis Sabiya > Signed-off-by: Apurva Nandan > Reviewed-by: Tom Rini [...] > diff --git a/board/ti/j784s4/MAINTAINERS b/board/ti/j784s4/MAINTAINERS > new file mode 100644 > index 00..9e0df11503 > --- /dev/null > +++ b/board/ti/j784s4/MAINTAINERS > @@ -0,0 +1,14 @@ > +J784S4 EVM BOARD > +M: Apurva Nandan > +S: Maintained > +F: board/ti/j784s4 > +F: arch/arm/mach-k3/j784s4 > +F: include/configs/j784s4_evm.h > +F: arch/arm/dts/k3-j784s4.dtsi > +F: arch/arm/dts/k3-j784s4-main.dtsi > +F: arch/arm/dts/k3-j784s4-mcu-wakeup.dtsi > +F: arch/arm/dts/k3-j784s4-thermal.dtsi > +F: arch/arm/dts/k3-j784s4-evm.dts > + > +AM69 SK BOARD Don't all entries need a maintainer? I am not actually sure if the above M will fall through for SK board. > +F: arch/arm/dts/k3-am69-sk.dts > diff --git a/board/ti/j784s4/Makefile b/board/ti/j784s4/Makefile > new file mode 100644 > index 00..60161a8b5c > --- /dev/null > +++ b/board/ti/j784s4/Makefile > @@ -0,0 +1,7 @@ > +# SPDX-License-Identifier: GPL-2.0-or-later > +# > +# Copyright (C) 2023-2024 Texas Instruments Incorporated - > https://www.ti.com/ > +#Hari Nagalla > +# > + > +obj-y += evm.o > diff --git a/board/ti/j784s4/evm.c b/board/ti/j784s4/evm.c > new file mode 100644 > index 00..5af3e21ff0 > --- /dev/null > +++ b/board/ti/j784s4/evm.c > @@ -0,0 +1,43 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Board specific initialization for J784S4 EVM > + * > + * Copyright (C) 2023-2024 Texas Instruments Incorporated - > https://www.ti.com/ > + * Hari Nagalla > + * > + */ > + > +#include > +#include > +#include > +#include Are you sure we need all the above headers? > +#include "../common/fdt_ops.h" [...] -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v8 02/16] arm: mach-k3: Add basic support for J784S4 SoC definition
On 23:20-20240119, Apurva Nandan wrote:
[...]
> +void k3_spl_init(void)
> +{
> + struct udevice *dev;
> + int ret;
> +
> + /*
> + * Cannot delay this further as there is a chance that
> + * K3_BOOT_PARAM_TABLE_INDEX can be over written by SPL MALLOC section.
> + */
> + store_boot_info_from_rom();
> +
> + /* Make all control module registers accessible */
> + ctrl_mmr_unlock();
> +
> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> + disable_linefill_optimization();
> + setup_k3_mpu_regions();
> + }
> +
> + /* Init DM early */
> + ret = spl_early_init();
> +
> + /* Prepare console output */
> + preloader_console_init();
> +
> + if (IS_ENABLED(CONFIG_CPU_V7R)) {
> + /*
> + * Process pinctrl for the serial0 a.k.a. WKUP_UART0 module and
> continue
> + * regardless of the result of pinctrl. Do this without probing
> the
> + * device, but instead by searching the device that would
> request the
> + * given sequence number if probed. The UART will be used by
> the system
> + * firmware (SYSFW) image for various purposes and SYSFW
> depends on us
Nit pick - there is no SYSFW image anymore - it is either TIFS or DM.
> + * to initialize its pin settings.
> + */
> + ret = uclass_find_device_by_seq(UCLASS_SERIAL, 0, );
> + if (!ret)
> + pinctrl_select_state(dev, "default");
> +
> + /*
> + * Load, start up, and configure system controller firmware.
> Provide
> + * the U-Boot console init function to the SYSFW post-PM
> configuration
> + * callback hook, effectively switching on (or over) the console
> + * output.
> + */
> + k3_sysfw_loader(is_rom_loaded_sysfw(), NULL, NULL);
> +
> + if (IS_ENABLED(CONFIG_SPL_CLK_K3)) {
> + /*
> + * Force probe of clk_k3 driver here to ensure basic
> default clock
> + * configuration is always done for enabling PM
> services.
> + */
> + ret = uclass_get_device_by_driver(UCLASS_CLK,
> + DM_DRIVER_GET(ti_clk),
> + );
> + if (ret)
> + panic("Failed to initialize clk-k3!\n");
> + }
> +
> + remove_fwl_configs(cbass_hc_cfg0_fwls,
> ARRAY_SIZE(cbass_hc_cfg0_fwls));
> + remove_fwl_configs(cbass_hc2_fwls, ARRAY_SIZE(cbass_hc2_fwls));
> + remove_fwl_configs(cbass_rc_cfg0_fwls,
> ARRAY_SIZE(cbass_rc_cfg0_fwls));
> + remove_fwl_configs(infra_cbass0_fwls,
> ARRAY_SIZE(infra_cbass0_fwls));
> + remove_fwl_configs(mcu_cbass0_fwls,
> ARRAY_SIZE(mcu_cbass0_fwls));
> + remove_fwl_configs(wkup_cbass0_fwls,
> ARRAY_SIZE(wkup_cbass0_fwls));
> + remove_fwl_configs(navss_cbass0_fwls,
> ARRAY_SIZE(navss_cbass0_fwls));
> + }
> +
> + /* Output System Firmware version info */
> + k3_sysfw_print_ver();
> +}
> +
> +void k3_mem_init(void)
> +{
> + struct udevice *dev;
> + int ret, ctr = 1;
> +
> + if (IS_ENABLED(CONFIG_K3_J721E_DDRSS)) {
> + ret = uclass_get_device(UCLASS_RAM, 0, );
> + if (ret)
> + panic("DRAM 0 init failed: %d\n", ret);
> +
> + while (dev) {
why loop on dev? is it possible to have ret != 0 and dev = 0?
> + ret = uclass_next_device_err();
> + if (ret) {
> + printf("Initialized %d DRAM controllers\n",
> ctr);
> + break;
> + }
> + ctr++;
What is the use of ctr++ ?? please do a limit check for instances.
[...]
Next time, please respond to the review comment questions so that I
know that you have considered and decided something is not necessary
or something was missed in the new version - for example what happened
to mmc_stop/restart?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v8 04/16] arm: dts: Add bootph-all for memory node
On 23:20-20240119, Apurva Nandan wrote:
[...]
> diff --git a/arch/arm/dts/k3-am69-sk.dts b/arch/arm/dts/k3-am69-sk.dts
> index 9868c7049b..29884097b9 100644
> --- a/arch/arm/dts/k3-am69-sk.dts
> +++ b/arch/arm/dts/k3-am69-sk.dts
I think you mis-interpreted
https://lore.kernel.org/u-boot/20240103175221.ovjzcwwljnjhka2n@expire/
comment to modify kernel board.dts. I meant for you to squash that
correct change to the patch that introduces board-u-boot.dtsi and r5.dts
Now that i read my comment, I can see why it might have been
mis-interpreted. Sorry about that - please squash your v7 patch
instead to appropriate patch.
> @@ -33,6 +33,7 @@
>
> memory@8000 {
> device_type = "memory";
> + bootph-all;
> /* 32G RAM */
> reg = <0x00 0x8000 0x00 0x8000>,
> <0x08 0x8000 0x07 0x8000>;
> diff --git a/arch/arm/dts/k3-j784s4-evm.dts b/arch/arm/dts/k3-j784s4-evm.dts
> index f1f4c8634a..662552c872 100644
> --- a/arch/arm/dts/k3-j784s4-evm.dts
> +++ b/arch/arm/dts/k3-j784s4-evm.dts
> @@ -31,6 +31,7 @@
>
> memory@8000 {
> device_type = "memory";
> + bootph-all;
> /* 32G RAM */
> reg = <0x00 0x8000 0x00 0x80000000>,
> <0x08 0x8000 0x07 0x8000>;
> --
> 2.34.1
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v8 12/16] arm: dts: Introduce j784s4 u-boot dts files
On 23:20-20240119, Apurva Nandan wrote:
[...]
> diff --git a/arch/arm/dts/k3-j784s4-binman.dtsi
> b/arch/arm/dts/k3-j784s4-binman.dtsi
> new file mode 100644
> index 00..d0d49b5bbe
> --- /dev/null
> +++ b/arch/arm/dts/k3-j784s4-binman.dtsi
> @@ -0,0 +1,345 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include "k3-binman.dtsi"
> +
> +#ifdef CONFIG_TARGET_J784S4_R5_EVM
> +
> +_yaml_tifs {
> + config = "tifs-rm-cfg.yaml";
> +};
> +
> + {
> + tiboot3-j784s4-hs-evm.bin {
> + filename = "tiboot3-j784s4-hs-evm.bin";
> +
https://lore.kernel.org/u-boot/20240103174756.xa4rzbn4klk5gv2x@aware/
You haven't responded on thread why
"Prefer #1 - j784s4 binman template" is not feasible or not desirable.
Something like:
in j784s4-binman.dtsi:
{
j784s4_tiboot3_hs_fs_template: template-9 {
and then in sk.dtsi:
{
ti-j784s4-hs-evm.bin {
insert-template =<_tiboot3_hs_fs_template>;
};
};
This allows boards to readily include the template for the binaries of
choice and generate just relevant output. Wont it save much confusion?
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 00/11] An effort to bring DT bindings compliance within U-Boot
On 16:05-20240110, Sumit Garg wrote: [...] > Prerequisite > > > This patch series requires devicetree-rebasing git repo to be added as a > subtree to the main U-Boot repo via: > > $ git subtree add --prefix dts/upstream \ > > git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > \ Please use https:// also what is the baseline? didn't seem to apply on (fails at patch #2): next f28a77589e75 Merge tag 'dm-next-7jan23' of https://source.denx.de/u-boot/custodians/u-boot-dm into next master f7cca7ccc511 Revert "test: hush: dollar: fix bugous behavior" -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 0/2] arm: dts: Add Itap Delay Value For High Speed DDR
On 07:20-20240110, Bryan Brattlof wrote: > On January 10, 2024 thus sayeth Bhavya Kapoor: > > > > On 08/01/24 7:35 pm, Bryan Brattlof wrote: > > > Hi Bhavya! > > > > > > On January 8, 2024 thus sayeth Bhavya Kapoor: > > > > This Series adds Itap Delay Value for DDR52 speed mode for eMMC in > > > > J7200 SoC and for DDR50 speed mode for MMCSD in J721s2 SoC. > > > > > > > > Bhavya Kapoor (2): > > > >arm: dts: k3-j7200-main: Add Itap Delay Value For DDR52 speed mode > > > >arm: dts: k3-j721s2-main: Add Itap Delay Value For DDR50 speed mode > > > > > > > > arch/arm/dts/k3-j7200-main.dtsi | 1 + > > > > arch/arm/dts/k3-j721s2-main.dtsi | 1 + > > > Because of the periodic syncs with the kernel, modifying these dt files > > > in U-Boot will cause confusion. (Which node is correct why did we have > > > to do this in U-Boot and not in the Kernel... bla bla bla) If they > > > absolutely need to go in now please override these nodes in the > > > *-u-boot.dtsi files with a comment so we can keep track of these changes > > > during the next sync with Linux. > > > > > > ~Bryan > > > > Hi Bryan, Fyi, This patch went in kernel as well. > > > > Can be tracked below- > > > > https://lore.kernel.org/all/170266085077.3490141.14935960940418963459.b4...@ti.com/ > > > > So , kernel and uboot dt files will remain in sync. > > > > Sorry I may be missing something. Why do we need these properties in > U-Boot now? Why not wait 2 weeks for the v6.8-rc1 tag in Linux and sync > everything all at once? I agree. NAK for the series. Please get this part of dts sync. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 5/7] configs: am62x_evm_*: Enable USB and DFU support
On 16:06-20240112, Sjoerd Simons wrote:
[...]
> >
> > I am starting to wonder if
> > https://lore.kernel.org/u-boot/20231101170519.39627-1-...@ti.com/
> > will help us here.
>
> Yes absolutely that would be perfect. Can i suggest we land it as is
> for now ("fat monolithic config") and once those patches land i'm happy
> to split things up?
>
https://libera.irclog.whitequark.org/u-boot/2024-01-12#35590530 I think
Tom agrees in principle (and Simon already acked), so we could go down
this road and refactor - I am always a bit squeamish about redoing work
if the baseline changes or has a reasonable chance of change.. Just
doing it once and cleanly is my preference.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 5/7] configs: am62x_evm_*: Enable USB and DFU support
On 14:09-20240112, Sjoerd Simons wrote: [...] > > > diff --git a/configs/am62x_evm_a53_defconfig > > > b/configs/am62x_evm_a53_defconfig > > > index aa96c1b3125..f335eb11e63 100644 > > > --- a/configs/am62x_evm_a53_defconfig > > > +++ b/configs/am62x_evm_a53_defconfig > > > > Should we make the a53 also a defconfig fragment allowing reuse > > across > > multiple boards? > > Pros and cons. having all the various options (USB boot, ETH boot, misc > other) as fragments would allow easier re-use but make it more > complicated for the end-user to get a "full-featured" u-boot. > > My personal preference, as i'm coming with a distribution background, > is to always enable as much as possible in a default build to allow > maximum flexibility for end-users; Those that need > space/performance/whatever optimisation can always do custom builds. > > It would be great if we could have a level of indirection here where by > default a set of fragments get included such that it's invisible to the > end-user that the underlying config is actually quite modular. But I > don't think that's currently possible, hence preferring a fat defconfig > such that the user/distro can just do `make am62x_evm_a53_defconfig` > (and similar for beagleplay) > I understand, but I am looking to reduce duplication between boards and making it easier for new board devs to be able to pick the feature group they need - almost all am62x users who desire dfu on a53 will need the same options enabled. This also keeps the default u-boot foot print lower to allow for emmc boot0 partition limitations if any (I removed that dependency on beagle by using uda, but other platforms still keep u-boot in emmc boot0 and depending on the part and TEE binary size, the available space can be constraining) I am starting to wonder if https://lore.kernel.org/u-boot/20231101170519.39627-1-...@ti.com/ will help us here. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
On 15:06-20240112, Roger Quadros wrote:
>
>
> On 12/01/2024 15:02, Nishanth Menon wrote:
> > On 14:49-20240112, Roger Quadros wrote:
> >> Without correct SERDES MUX and Lane control settings
> >> USB0 will be broken. Set the MUX and Lane control devices
> >> to be auto probed so they are configured correctly.
> >>
> >> Signed-off-by: Roger Quadros
> >> ---
> >> arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >> b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >> index f83caf7998..017a5a722e 100644
> >> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> >> @@ -165,6 +165,7 @@
> >>
> >> _ln_ctrl {
> >>bootph-all;
> >> + u-boot,mux-autoprobe;
> >> };
> >>
> >> _usb_link {
> >> @@ -173,6 +174,7 @@
> >>
> >> _serdes_mux {
> >>bootph-all;
> >> + u-boot,mux-autoprobe;
> >> };
> >>
> >> _wiz2 {
> >> --
> >> 2.34.1
> >>
> >
> > Is this a u-boot thing? or a driver limitation?
> >
>
> u-boot specific. We just want the mux driver to probe
> and apply the settings.
>
> from drivers/mux/mux-uclass.c
>
> int dm_mux_init(void)
> {
> struct uclass *uc;
> struct udevice *dev;
> int ret;
>
> ret = uclass_get(UCLASS_MUX, );
> if (ret < 0) {
> log_debug("unable to get MUX uclass\n");
> return ret;
> }
> uclass_foreach_dev(dev, uc) {
> if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
> ret = device_probe(dev);
> if (ret)
> log_debug("unable to probe device %s\n",
> dev->name);
> }
> }
>
> return 0;
> }
>
>
Uggh.. We need to see eventually how to get rid of this.
This makes
https://lore.kernel.org/u-boot/20240110103547.719757-1-sumit.g...@linaro.org/#t
harder now?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 4/5] arm: dts: k3-j721e-beagleboneai64: Fix USB operation
On 14:49-20240112, Roger Quadros wrote:
> Without correct SERDES MUX and Lane control settings
> USB0 will be broken. Set the MUX and Lane control devices
> to be auto probed so they are configured correctly.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> index f83caf7998..017a5a722e 100644
> --- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
> @@ -165,6 +165,7 @@
>
> _ln_ctrl {
> bootph-all;
> + u-boot,mux-autoprobe;
> };
>
> _usb_link {
> @@ -173,6 +174,7 @@
>
> _serdes_mux {
> bootph-all;
> + u-boot,mux-autoprobe;
> };
>
> _wiz2 {
> --
> 2.34.1
>
Is this a u-boot thing? or a driver limitation?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 00/10] Add support for Ethernet Boot on SK-AM62
On 18:17-20240112, Siddharth Vadapalli wrote: > > > On 12/01/24 18:12, Nishanth Menon wrote: > > On 18:06-20240112, Siddharth Vadapalli wrote: > >> > >> > >> On 12/01/24 18:02, Nishanth Menon wrote: > >>> On 12:17-20240112, Siddharth Vadapalli wrote: > >>>> Hello, > >>>> > >>>> This series enables Ethernet Boot on SK-AM62 device. > >>>> Product Link: https://www.ti.com/tool/SK-AM62 > >>>> User Guide: https://www.ti.com/lit/pdf/spruj40 > >>>> > >>>> Ethernet Boot flow is as follows: > >>>> 1. The BOOT MODE pins are configured for Ethernet Boot. > >>>> 2. On powering on the device, ROM uses the Ethernet Port corresponding > >>>> to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot". > >>>> 3. The TFTP server and DHCP server on the receiver device need to be > >>>> configured such that VCI string "TI K3 Bootp Boot" maps to the file > >>>> "tiboot3.bin" and the TFTP server should be capable of transferring > >>>> it to the device. > >>>> 4. ROM loads and executes "tiboot3.bin" provided by the TFTP server. > >>>> 5. The "tiboot3.bin" file is expected to be built using the config: > >>>> am62x_evm_r5_ethboot_defconfig > >>>> introduced in this series, which shall enable "tispl.bin" to be fetched > >>>> over TFTP using "tiboot3.bin". > >>>> 6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its > >>>> NET_VCI_STRING, thereby implying that the DHCP server and TFTP server > >>>> need to be configured to transfer "tispl.bin" to the device. > >>>> 7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP > >>>> server. > >>>> 8. The "tispl.bin" file is expected to be built using the config: > >>>> am62x_evm_a53_defconfig > >>>> which has been updated in this series to enable Ethernet Boot specific > >>>> configs, allowing "u-boot.img" to be fetched over TFTP using > >>>> "tispl.bin". > >>>> 9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its > >>>> NET_VCI_STRING. The DHCP server and TFTP server need to be configured to > >>>> transfer "u-boot.img" to the device for the aforementioned > >>>> NET_VCI_STRING. > >>>> 10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and > >>>> executes it on the device, completing the process of Ethernet Boot on the > >>>> device. > >>>> > >>>> NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode > >>>> of operation due to which it is expected that the Link Partner also > >>>> supports the same mode of operation. > >>>> Additionally, enabling "phy_gmii_sel" node at SPL stage will be > >>>> necessary and is not added as a part of this series with the aim of > >>>> adding the "bootph-all" property to its counterpart in Linux device-tree > >>>> first. > >>> > >>> > >>> NAK - instead of writing all this up in the commit message, why would > >>> you not spend that time updating the excellent documentation we have? > >> > >> I plan to document it after the feature is in. The reason for mentioning > >> the > >> content above is for explaining the flow in case anyone wishes to test and > >> verify it. Wouldn't documenting it make it appear that the feature is > >> present > >> when it isn't? > > > > So you are saying this series does NOT work! why are you sending patches > > then? If you are introducing a feature and enabling it, ensure you send > > documentation along with it allowing people to be able to actually use > > the feature. > > I have mentioned in the "NOTE" above that enabling "phy_gmii_sel" node at SPL > stage by adding the "bootph-all" property is necessary to verify this series. > I cannot post that with this series since Linux device-tree needs to have the > property added first and the merge window is closed now. Once it is in the > Linux > device-tree, syncing U-Boot device-tree with Linux device-tree will enable > Ethernet Boot which is when the feature will work. That is when I was planning > to document it. However, based on your feedback, in the next version for this > series I will add the documentation as well along with the note that > "phy_gmii_sel" needs to be enabled at SPL stage for the feature to work. > considered first posting a patch to kernel.org (merge window has nothing to do with posting and having patches reviewed) and in the interim, doing that in u-boot.dtsi so that the next sync will drop it from u-boot.dtsi? OR hold the series back till it is merged into kernel.org master? Either way, please do not send patches to the list that does not work. Since it is now hard to trust your patches without detailed cover letter analysis, next time you are updating the series post test logs as well with just the patches applied and no additional changes. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 00/10] Add support for Ethernet Boot on SK-AM62
On 18:06-20240112, Siddharth Vadapalli wrote: > > > On 12/01/24 18:02, Nishanth Menon wrote: > > On 12:17-20240112, Siddharth Vadapalli wrote: > >> Hello, > >> > >> This series enables Ethernet Boot on SK-AM62 device. > >> Product Link: https://www.ti.com/tool/SK-AM62 > >> User Guide: https://www.ti.com/lit/pdf/spruj40 > >> > >> Ethernet Boot flow is as follows: > >> 1. The BOOT MODE pins are configured for Ethernet Boot. > >> 2. On powering on the device, ROM uses the Ethernet Port corresponding > >> to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot". > >> 3. The TFTP server and DHCP server on the receiver device need to be > >> configured such that VCI string "TI K3 Bootp Boot" maps to the file > >> "tiboot3.bin" and the TFTP server should be capable of transferring > >> it to the device. > >> 4. ROM loads and executes "tiboot3.bin" provided by the TFTP server. > >> 5. The "tiboot3.bin" file is expected to be built using the config: > >> am62x_evm_r5_ethboot_defconfig > >> introduced in this series, which shall enable "tispl.bin" to be fetched > >> over TFTP using "tiboot3.bin". > >> 6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its > >> NET_VCI_STRING, thereby implying that the DHCP server and TFTP server > >> need to be configured to transfer "tispl.bin" to the device. > >> 7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP > >> server. > >> 8. The "tispl.bin" file is expected to be built using the config: > >> am62x_evm_a53_defconfig > >> which has been updated in this series to enable Ethernet Boot specific > >> configs, allowing "u-boot.img" to be fetched over TFTP using > >> "tispl.bin". > >> 9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its > >> NET_VCI_STRING. The DHCP server and TFTP server need to be configured to > >> transfer "u-boot.img" to the device for the aforementioned NET_VCI_STRING. > >> 10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and > >> executes it on the device, completing the process of Ethernet Boot on the > >> device. > >> > >> NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode > >> of operation due to which it is expected that the Link Partner also > >> supports the same mode of operation. > >> Additionally, enabling "phy_gmii_sel" node at SPL stage will be > >> necessary and is not added as a part of this series with the aim of > >> adding the "bootph-all" property to its counterpart in Linux device-tree > >> first. > > > > > > NAK - instead of writing all this up in the commit message, why would > > you not spend that time updating the excellent documentation we have? > > I plan to document it after the feature is in. The reason for mentioning the > content above is for explaining the flow in case anyone wishes to test and > verify it. Wouldn't documenting it make it appear that the feature is present > when it isn't? So you are saying this series does NOT work! why are you sending patches then? If you are introducing a feature and enabling it, ensure you send documentation along with it allowing people to be able to actually use the feature. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On 18:01-20240112, Siddharth Vadapalli wrote: > Hello Nishanth, > > On 12/01/24 17:56, Nishanth Menon wrote: > > On 12:17-20240112, Siddharth Vadapalli wrote: > >> From: Kishon Vijay Abraham I > >> > >> Call dram_init_banksize() from spl_board_init() otherwise TFTP download > >> fails with error "TFTP error: trying to overwrite reserved memory..." > >> due to lmb_get_free_size() not able to find unreserved region due > >> to lack of DRAM size info. Required to support Ethernet boot on AM62x. > >> > >> Signed-off-by: Kishon Vijay Abraham I > >> Signed-off-by: Siddharth Vadapalli > >> --- > >> board/ti/am62x/evm.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c > >> index ad93908840..35f291d83a 100644 > >> --- a/board/ti/am62x/evm.c > >> +++ b/board/ti/am62x/evm.c > >> @@ -85,6 +85,9 @@ void spl_board_init(void) > >>if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP)) > >>splash_display(); > >> > >> + if (IS_ENABLED(CONFIG_SPL_ETH)) > >> + /* Init DRAM size for R5/A53 SPL */ > >> + dram_init_banksize(); > >> } > >> > >> #if defined(CONFIG_K3_AM64_DDRSS) > >> -- > >> 2.34.1 > >> > > > > Are you sure? tftp seems to work without this patch. > > > > https://gist.github.com/nmenon/91e3282e00e38ae42e8cf640be2ab888 > > I noticed the error pointed out in the commit message at the A53 SPL stage > when > the U-Boot Image is being fetched over TFTP without this patch, so I have > verified that this patch is necessary. The logs you have shared verify TFTP at > U-Boot, but this patch is for enabling TFTP at A53 SPL for fetching U-Boot > image > via TFTP. Please fix the commit message. I still dont get why we have to explicitly have to call dram_init_banksize is that because some sort of configuration option was missed? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 5/7] configs: am62x_evm_*: Enable USB and DFU support
On 09:52-20240112, Sjoerd Simons wrote: > Enable USB host as well as USB gadget and DFU support for a53; For the > r5 due to the smaller available size create a config fragment for DFU > supports which disables support for persistent storage to free up space > for USB support > > Signed-off-by: Sjoerd Simons > > --- > > Changes in v4: > - Move R5 dfu config to a config fragment rather then a full defconfig > - Don't enable XHCI for the R5 SPL, unneeded > > Changes in v3: > - Run savedefconfig to adjust to more recent u-boot > > Changes in v2: > - Create a seperate defconfig for R5 > > configs/am62x_evm_a53_defconfig | 30 ++ > configs/am62x_r5_usbdfu.config | 28 > 2 files changed, 58 insertions(+) > create mode 100644 configs/am62x_r5_usbdfu.config > > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index aa96c1b3125..f335eb11e63 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig Should we make the a53 also a defconfig fragment allowing reuse across multiple boards? > @@ -1,5 +1,6 @@ > CONFIG_ARM=y > CONFIG_ARCH_K3=y > +CONFIG_SYS_MALLOC_LEN=0x200 > CONFIG_SYS_MALLOC_F_LEN=0x8000 > CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > @@ -41,16 +42,23 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y > CONFIG_SPL_STACK_R=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 > +CONFIG_SPL_ENV_SUPPORT=y > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" > CONFIG_SPL_DM_MAILBOX=y > CONFIG_SPL_DM_SPI_FLASH=y > CONFIG_SPL_POWER_DOMAIN=y > +CONFIG_SPL_RAM_SUPPORT=y > +CONFIG_SPL_RAM_DEVICE=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_SPL_USB_GADGET=y > +CONFIG_SPL_DFU=y > CONFIG_SPL_YMODEM_SUPPORT=y > +CONFIG_CMD_DFU=y > CONFIG_CMD_MMC=y > +CONFIG_CMD_USB=y > CONFIG_OF_CONTROL=y > CONFIG_SPL_OF_CONTROL=y > CONFIG_MULTI_DTB_FIT=y > @@ -61,10 +69,17 @@ CONFIG_SPL_DM=y > CONFIG_SPL_DM_SEQ_ALIAS=y > CONFIG_REGMAP=y > CONFIG_SPL_REGMAP=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > CONFIG_SPL_OF_TRANSLATE=y > CONFIG_CLK=y > CONFIG_SPL_CLK=y > CONFIG_CLK_TI_SCI=y > +CONFIG_DFU_MMC=y > +CONFIG_DFU_RAM=y > +CONFIG_DFU_SF=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 > +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 > CONFIG_DMA_CHANNELS=y > CONFIG_TI_K3_NAVSS_UDMA=y > CONFIG_TI_SCI_PROTOCOL=y > @@ -103,4 +118,19 @@ CONFIG_CADENCE_QSPI=y > CONFIG_SYSRESET=y > CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_TI_SCI=y > +CONFIG_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_SPL_DM_USB_GADGET=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_AM62=y > +CONFIG_USB_DWC3_AM62=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 > +CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > diff --git a/configs/am62x_r5_usbdfu.config b/configs/am62x_r5_usbdfu.config > new file mode 100644 > index 000..772bb2ab935 > --- /dev/null > +++ b/configs/am62x_r5_usbdfu.config > @@ -0,0 +1,28 @@ > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 > +CONFIG_MISC=y > +CONFIG_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_SPL_DM_USB_GADGET=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_AM62=y > +CONFIG_USB_GADGET=y > +CONFIG_SPL_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 > +CONFIG_USB_GADGET_DOWNLOAD=y > +CONFIG_SPL_DFU=y > +# CONFIG_SPL_MMC is not set > +# CONFIG_SPL_FS_FAT is not set > +# CONFIG_SPL_LIBDISK_SUPPORT is not set > +# CONFIG_SPL_SPI is not set > +# CONFIG_SPL_SYS_MALLOC is not set > +# CONFIG_CMD_GPT is not set > +# CONFIG_CMD_MMC is not set > +# CONFIG_CMD_FAT is not set > +# CONFIG_MMC_SDHCI is not set > -- > 2.43.0 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 7/7] doc: board: Add document for DFU boot on am62x SoCs
On 09:52-20240112, Sjoerd Simons wrote:
> Both AM62 SK and beagleplay support DFU boot in a similar way now;
> Document how to actually run DFU boot for both boards
>
> Signed-off-by: Sjoerd Simons
>
> ---
>
> Changes in v4:
> - New patch
>
> doc/board/beagle/am62x_beagleplay.rst | 12 +
> doc/board/ti/am62x_sk.rst | 37 +++
> 2 files changed, 49 insertions(+)
>
> diff --git a/doc/board/beagle/am62x_beagleplay.rst
> b/doc/board/beagle/am62x_beagleplay.rst
> index 7784e62b0b7..4c8b0845845 100644
> --- a/doc/board/beagle/am62x_beagleplay.rst
> +++ b/doc/board/beagle/am62x_beagleplay.rst
> @@ -270,6 +270,18 @@ for details.
> To switch to SD card boot mode, hold the USR button while powering on
> with Type-C power supply, then release when power LED lights up.
>
> +DFU based boot
> +--
> +
> +To boot the board over DFU, ensure there is no SD card inserted with a
> +bootloader. Hold the USR switch while plugging into the Type C to boot into
> DFU
> +mode. After power-on the build artifacts needs to be uploaded one by one
> with a
> +tool like dfu-util.
Don't we also need a wiped out emmc unfortunately?
> +
> +.. include:: ../ti/am62x_sk.rst
> +:start-after: .. am62x_evm_rst_include_start_dfu_boot
> +:end-before: .. am62x_evm_rst_include_end_dfu_boot
> +
> Debugging U-Boot
>
>
> diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst
> index b12dc85f06b..904a54cd5ff 100644
> --- a/doc/board/ti/am62x_sk.rst
> +++ b/doc/board/ti/am62x_sk.rst
> @@ -105,6 +105,20 @@ Set the variables corresponding to this platform:
>
> * 3.1 R5:
>
> +.. include:: ../ti/k3.rst
> +:start-after: .. k3_rst_include_start_build_steps_spl_r5
> +:end-before: .. k3_rst_include_end_build_steps_spl_r5
> +
> +* 3.1.1 Alternatively build R5 for DFU boot:
> +
> +As the SPL size can get to big when building with support for booting both
> from
> +local storage *and* DFU an extra config fragment should be used to enable DFU
> +support (and disable storage support)
> +
> +.. prompt:: bash $
> +
> + export UBOOT_CFG_CORTEXR=${UBOOT_CFG_CORTEXR} am62x_r5_usbdfu.config
> +
> .. include:: ../ti/k3.rst
> :start-after: .. k3_rst_include_start_build_steps_spl_r5
> :end-before: .. k3_rst_include_end_build_steps_spl_r5
> @@ -251,6 +265,29 @@ https://www.ti.com/lit/pdf/spruiv7 under the `Boot Mode
> Pins` section.
>
> For SW2 and SW1, the switch state in the "ON" position = 1.
>
> +DFU based boot
> +--
> +
> +To boot the board over DFU, set the switches to DFU mode and connect to the
> +USB Type C DRD Port on the board. After power-on the build artifacts needs
> to be
> +uploaded one by one with a tool like dfu-util.
> +
> +.. am62x_evm_rst_include_start_dfu_boot
> +
> +The initial ROM will have a DFU alt named `bootloader` for the initial R5 spl
> +upload. The next stages as exposed by u-boot have target alts matching the
> name
> +of the artifacts, for these a USB reset has to be done after each upload.
> +
> +When using dfu-util the following commands can be used to boot to a u-boot
> shell:
> +
> +.. prompt:: bash $
> +
> + dfu-util -a bootloader -D tiboot3.bin
> + dfu-util -R -a tispl -D tispl.bin
> + dfu-util -R -a u-boot.img -D u-boot.img
> +
> +.. am62x_evm_rst_include_end_dfu_boot
> +
> Debugging U-Boot
>
>
> --
> 2.43.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 6/7] beagleplay: Add DFU support
On 09:52-20240112, Sjoerd Simons wrote:
> DFU mode on a beagleplay can be used via the Type-C connector by holding
> the USR switch while powering on.
>
> Configuration is only added for the A53 u-boot parts, for R5 the
> am62x_r5_usbdfu.config fragment should be used.
>
> Signed-off-by: Sjoerd Simons
>
> ---
>
> Changes in v4:
> - New patch
>
> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 8 ++
> board/beagle/beagleplay/beagleplay.env | 1 +
> configs/am62x_beagleplay_a53_defconfig | 30
> 3 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> index a723caa5805..0b1e5e70fe2 100644
> --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> @@ -61,6 +61,14 @@
> >;
> };
>
> + {
> + bootph-all;
> +};
> +
> + {
> + bootph-all;
> +};
> +
> #ifdef CONFIG_TARGET_AM625_A53_BEAGLEPLAY
>
> #define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
> diff --git a/board/beagle/beagleplay/beagleplay.env
> b/board/beagle/beagleplay/beagleplay.env
> index 4f0a94a8113..85c94856017 100644
> --- a/board/beagle/beagleplay/beagleplay.env
> +++ b/board/beagle/beagleplay/beagleplay.env
> @@ -1,6 +1,7 @@
> #include
> #include
> #include
> +#include
>
> name_kern=Image
> console=ttyS2,115200n8
> diff --git a/configs/am62x_beagleplay_a53_defconfig
> b/configs/am62x_beagleplay_a53_defconfig
> index 0be20045a97..dfe04b71810 100644
> --- a/configs/am62x_beagleplay_a53_defconfig
> +++ b/configs/am62x_beagleplay_a53_defconfig
> @@ -1,5 +1,6 @@
> CONFIG_ARM=y
> CONFIG_ARCH_K3=y
> +CONFIG_SYS_MALLOC_LEN=0x200
> CONFIG_SYS_MALLOC_F_LEN=0x8000
> CONFIG_SPL_GPIO=y
> CONFIG_SPL_LIBCOMMON_SUPPORT=y
> @@ -43,15 +44,20 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> CONFIG_SPL_STACK_R=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
> +CONFIG_SPL_ENV_SUPPORT=y
> CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img"
> CONFIG_SPL_I2C=y
> CONFIG_SPL_DM_MAILBOX=y
> CONFIG_SPL_POWER_DOMAIN=y
> +CONFIG_SPL_RAM_SUPPORT=y
> +CONFIG_SPL_RAM_DEVICE=y
> CONFIG_SPL_YMODEM_SUPPORT=y
> +CONFIG_CMD_DFU=y
Couldn't these go to config fragments?
> CONFIG_CMD_GPIO=y
> CONFIG_CMD_GPIO_READ=y
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> +CONFIG_CMD_USB=y
> CONFIG_CMD_PMIC=y
> CONFIG_CMD_REGULATOR=y
> CONFIG_OF_CONTROL=y
> @@ -68,6 +74,10 @@ CONFIG_SPL_OF_TRANSLATE=y
> CONFIG_CLK=y
> CONFIG_SPL_CLK=y
> CONFIG_CLK_TI_SCI=y
> +CONFIG_DFU_MMC=y
> +CONFIG_DFU_RAM=y
> +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000
> +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80
> CONFIG_DMA_CHANNELS=y
> CONFIG_TI_K3_NAVSS_UDMA=y
> CONFIG_TI_SCI_PROTOCOL=y
> @@ -113,6 +123,26 @@ CONFIG_SOC_TI=y
> CONFIG_SYSRESET=y
> CONFIG_SPL_SYSRESET=y
> CONFIG_SYSRESET_TI_SCI=y
> +CONFIG_USB=y
> +CONFIG_DM_USB_GADGET=y
> +CONFIG_SPL_DM_USB_GADGET=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_DWC3=y
> +CONFIG_USB_DWC3_GENERIC=y
> +CONFIG_SPL_USB_DWC3_GENERIC=y
> +CONFIG_SPL_USB_DWC3_AM62=y
> +CONFIG_USB_DWC3_AM62=y
> +CONFIG_USB_GADGET=y
> +CONFIG_SPL_USB_GADGET=y
> +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
> +CONFIG_USB_GADGET_VENDOR_NUM=0x0451
> +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165
> +CONFIG_USB_GADGET_DOWNLOAD=y
> +CONFIG_SPL_DFU=y
> CONFIG_EXT4_WRITE=y
> CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
> CONFIG_LZO=y
> +CONFIG_SYSCON=y
> +CONFIG_SPL_SYSCON=y
> +
> --
> 2.43.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 09/10] configs: am62x_evm_a53_defconfig: Enable configs required for Ethboot
On 12:17-20240112, Siddharth Vadapalli wrote: > From: Kishon Vijay Abraham I > > Enable config options needed to support Ethernet boot on AM62x SK. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Siddharth Vadapalli > --- > configs/am62x_evm_a53_defconfig | 8 > 1 file changed, 8 insertions(+) > > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index aa96c1b312..5c56b17a3e 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -17,6 +17,7 @@ CONFIG_OF_LIBFDT_OVERLAY=y > CONFIG_DM_RESET=y > CONFIG_SPL_MMC=y > CONFIG_SPL_SERIAL=y > +CONFIG_SPL_DRIVERS_MISC=y > CONFIG_SPL_STACK_R_ADDR=0x8200 > CONFIG_SPL_SIZE_LIMIT=0x4 > CONFIG_SPL_SIZE_LIMIT_PROVIDE_STACK=0x800 > @@ -37,13 +38,19 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y > CONFIG_SPL_BSS_START_ADDR=0x80c8 > CONFIG_SPL_BSS_MAX_SIZE=0x8 > CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y > +CONFIG_SPL_BOARD_INIT=y > CONFIG_SPL_SYS_MALLOC_SIMPLE=y > CONFIG_SPL_STACK_R=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y > CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400 > +CONFIG_SPL_DMA=y > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_SPL_ETH=y > CONFIG_SPL_FS_LOAD_PAYLOAD_NAME="u-boot.img" > CONFIG_SPL_DM_MAILBOX=y > CONFIG_SPL_DM_SPI_FLASH=y > +CONFIG_SPL_NET=y > +CONFIG_SPL_NET_VCI_STRING="AM62X U-Boot A53 SPL" > CONFIG_SPL_POWER_DOMAIN=y > # CONFIG_SPL_SPI_FLASH_TINY is not set > CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y > @@ -61,6 +68,7 @@ CONFIG_SPL_DM=y > CONFIG_SPL_DM_SEQ_ALIAS=y > CONFIG_REGMAP=y > CONFIG_SPL_REGMAP=y > +CONFIG_SPL_SYSCON=y > CONFIG_SPL_OF_TRANSLATE=y > CONFIG_CLK=y > CONFIG_SPL_CLK=y > -- > 2.34.1 > NAK again - why cant we use config fragments? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 00/10] Add support for Ethernet Boot on SK-AM62
On 12:17-20240112, Siddharth Vadapalli wrote: > Hello, > > This series enables Ethernet Boot on SK-AM62 device. > Product Link: https://www.ti.com/tool/SK-AM62 > User Guide: https://www.ti.com/lit/pdf/spruj40 > > Ethernet Boot flow is as follows: > 1. The BOOT MODE pins are configured for Ethernet Boot. > 2. On powering on the device, ROM uses the Ethernet Port corresponding > to CPSW3G's MAC Port 1 to transmit "TI K3 Bootp Boot". > 3. The TFTP server and DHCP server on the receiver device need to be > configured such that VCI string "TI K3 Bootp Boot" maps to the file > "tiboot3.bin" and the TFTP server should be capable of transferring > it to the device. > 4. ROM loads and executes "tiboot3.bin" provided by the TFTP server. > 5. The "tiboot3.bin" file is expected to be built using the config: > am62x_evm_r5_ethboot_defconfig > introduced in this series, which shall enable "tispl.bin" to be fetched > over TFTP using "tiboot3.bin". > 6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its > NET_VCI_STRING, thereby implying that the DHCP server and TFTP server > need to be configured to transfer "tispl.bin" to the device. > 7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP > server. > 8. The "tispl.bin" file is expected to be built using the config: > am62x_evm_a53_defconfig > which has been updated in this series to enable Ethernet Boot specific > configs, allowing "u-boot.img" to be fetched over TFTP using > "tispl.bin". > 9. "tispl.bin" is configured to transmit "AM62X U-Boot A53 SPL" as its > NET_VCI_STRING. The DHCP server and TFTP server need to be configured to > transfer "u-boot.img" to the device for the aforementioned NET_VCI_STRING. > 10. "tispl.bin" then fetches "u-boot.img" using TFTP and loads and > executes it on the device, completing the process of Ethernet Boot on the > device. > > NOTE: ROM configures CPSW3G's MAC Port 1 for 100 Mbps full-duplex mode > of operation due to which it is expected that the Link Partner also > supports the same mode of operation. > Additionally, enabling "phy_gmii_sel" node at SPL stage will be > necessary and is not added as a part of this series with the aim of > adding the "bootph-all" property to its counterpart in Linux device-tree > first. NAK - instead of writing all this up in the commit message, why would you not spend that time updating the excellent documentation we have? > > This series is based on commit: > f28a77589e Merge tag 'dm-next-7jan23' of > https://source.denx.de/u-boot/custodians/u-boot-dm into next > of the next branch of u-boot. > > Regards, > Siddharth. > > Andreas Dannenberg (1): > arm: mach-k3: am62: Update SoC autogenerated data to enable Ethernet > Boot > > Kishon Vijay Abraham I (7): > board: ti: am62x: Init DRAM size in R5/A53 SPL > firmware: ti_sci: Add No-OP for "RX_FL_CFG" > soc: ti: k3-navss-ringacc: Initialize base address of ring cfg > registers > dma: ti: k3-udma: Add support for native configuration of chan/flow > arm: mach-k3: am625_init: Probe AM65 CPSW NUSS > configs: am62: Add configs for enabling ETHBOOT in R5SPL > configs: am62x_evm_a53_defconfig: Enable configs required for Ethboot > > Siddharth Vadapalli (1): > arm: dts: k3-am625-r5-sk: Enable DM services for main_pktdma > > Vignesh Raghavendra (1): > soc: ti: k3-navss-ringacc: Fix reset ring API > > arch/arm/dts/k3-am625-r5-sk.dts | 5 ++ > arch/arm/mach-k3/am625_init.c| 10 +++ > arch/arm/mach-k3/r5/am62x/clk-data.c | 79 > board/ti/am62x/evm.c | 3 + > configs/am62x_evm_a53_defconfig | 8 ++ > configs/am62x_evm_r5_ethboot_defconfig | 110 +++ > drivers/dma/ti/k3-udma.c | 6 ++ > drivers/firmware/ti_sci.c| 8 +- > drivers/soc/ti/k3-navss-ringacc-u-boot.c | 9 +- > drivers/soc/ti/k3-navss-ringacc.c| 7 +- > 10 files changed, 202 insertions(+), 43 deletions(-) > create mode 100644 configs/am62x_evm_r5_ethboot_defconfig > > -- > 2.34.1 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 08/10] configs: am62: Add configs for enabling ETHBOOT in R5SPL
On 12:17-20240112, Siddharth Vadapalli wrote: > From: Kishon Vijay Abraham I > > Add configs for enabling ETHBOOT in R5SPL. Adding a separate config > minimizes the risk of going past the R5-SPL size limit for any future > config additions. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Andreas Dannenberg > Signed-off-by: Siddharth Vadapalli > --- > configs/am62x_evm_r5_ethboot_defconfig | 110 + NAK. use config fragments please. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 07/10] arm: mach-k3: am625_init: Probe AM65 CPSW NUSS
On 12:17-20240112, Siddharth Vadapalli wrote:
> From: Kishon Vijay Abraham I
>
> In order to support Ethernet boot on AM62x, probe AM65 CPSW NUSS driver
> in board_init_f().
Why? doesn't the DM framework handle this?
>
> Signed-off-by: Kishon Vijay Abraham I
> Signed-off-by: Siddharth Vadapalli
> ---
> arch/arm/mach-k3/am625_init.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
> index 6c96e88114..b89dd206e5 100644
> --- a/arch/arm/mach-k3/am625_init.c
> +++ b/arch/arm/mach-k3/am625_init.c
> @@ -209,6 +209,16 @@ void board_init_f(ulong dummy)
> if (ret)
> panic("DRAM init failed: %d\n", ret);
> }
> +
> + if (IS_ENABLED(CONFIG_SPL_ETH) && IS_ENABLED(CONFIG_TI_AM65_CPSW_NUSS)
> &&
> + spl_boot_device() == BOOT_DEVICE_ETHERNET) {
> + struct udevice *cpswdev;
> +
> + if (uclass_get_device_by_driver(UCLASS_MISC,
> DM_DRIVER_GET(am65_cpsw_nuss),
> + ))
> + printf("Failed to probe am65_cpsw_nuss driver\n");
> + }
> +
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 06/10] arm: mach-k3: am62: Update SoC autogenerated data to enable Ethernet Boot
On 12:17-20240112, Siddharth Vadapalli wrote: > From: Andreas Dannenberg > > In order to enable Ethernet Boot using CPSW, update the clock data. There is too many changes in the patch - including ownership change etc.. and the actual data addition itself is not clear - what is added.. could please elaborate in the commit message. > > Signed-off-by: Andreas Dannenberg > Signed-off-by: Siddharth Vadapalli > --- > arch/arm/mach-k3/r5/am62x/clk-data.c | 79 ++-- > 1 file changed, 39 insertions(+), 40 deletions(-) > [...] -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On 12:17-20240112, Siddharth Vadapalli wrote: > From: Kishon Vijay Abraham I > > Call dram_init_banksize() from spl_board_init() otherwise TFTP download > fails with error "TFTP error: trying to overwrite reserved memory..." > due to lmb_get_free_size() not able to find unreserved region due > to lack of DRAM size info. Required to support Ethernet boot on AM62x. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Siddharth Vadapalli > --- > board/ti/am62x/evm.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c > index ad93908840..35f291d83a 100644 > --- a/board/ti/am62x/evm.c > +++ b/board/ti/am62x/evm.c > @@ -85,6 +85,9 @@ void spl_board_init(void) > if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP)) > splash_display(); > > + if (IS_ENABLED(CONFIG_SPL_ETH)) > + /* Init DRAM size for R5/A53 SPL */ > + dram_init_banksize(); > } > > #if defined(CONFIG_K3_AM64_DDRSS) > -- > 2.34.1 > Are you sure? tftp seems to work without this patch. https://gist.github.com/nmenon/91e3282e00e38ae42e8cf640be2ab888 -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v7 15/17] configs: Add am69_sk_* defconfig fragments
On 14:25-20240111, Roger Quadros wrote: [...] > > Signed-off-by: Dasnavis Sabiya > > Signed-off-by: Apurva Nandan > > --- > > configs/am69_sk_a72.config | 3 +++ > > configs/am69_sk_r5.config | 3 +++ > > Shouldn't the config fragments lie in the board//configs directory? > Else we will just keep polluting the configs directory. Correct - fragments should be in board/ti/.../ folder. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v7 15/17] configs: Add am69_sk_* defconfig fragments
On 15:06-20240111, Manorit Chawdhry wrote: > Hi Nishanth, > > On 11:59-20240103, Nishanth Menon wrote: > > On 00:45-20231220, Apurva Nandan wrote: > > > From: Dasnavis Sabiya > > > > > > Add config fragments for am69_sk A72 and R5 configuration. > > > > > > This applies on to: > > > j784s4_evm_a72_defconfig -> am69_sk_a72.config > > > j784s4_evm_r5_defconfig -> am69_sk_r5.config > > > > > > The usage model (with the fragment) would be: > > > make j784s4_evm_a72_defconfig am69_sk_a72.config > > > make > > > > > > OR > > > > > > make j784s4_evm_r5_defconfig am69_sk_r5.config > > > make > > > > > > Signed-off-by: Dasnavis Sabiya > > > Signed-off-by: Apurva Nandan > > > --- > > > configs/am69_sk_a72.config | 3 +++ > > > configs/am69_sk_r5.config | 3 +++ > > > 2 files changed, 6 insertions(+) > > > create mode 100644 configs/am69_sk_a72.config > > > create mode 100644 configs/am69_sk_r5.config > > > > > > diff --git a/configs/am69_sk_a72.config b/configs/am69_sk_a72.config > > > new file mode 100644 > > > index 00..5668e23b37 > > > --- /dev/null > > > +++ b/configs/am69_sk_a72.config > > > @@ -0,0 +1,3 @@ > > > +# Defconfig fragment to apply on top of j784s4_evm_a72_defconfig > > > + > > > +CONFIG_DEFAULT_DEVICE_TREE="k3-am69-sk" > > > diff --git a/configs/am69_sk_r5.config b/configs/am69_sk_r5.config > > > new file mode 100644 > > > index 00..9194694393 > > > --- /dev/null > > > +++ b/configs/am69_sk_r5.config > > > @@ -0,0 +1,3 @@ > > > +# Defconfig fragment to apply on top of j784s4_evm_r5_defconfig > > > + > > > +CONFIG_DEFAULT_DEVICE_TREE="k3-am69-r5-sk" > > > > See my previous comment. OF_LIST should have been overriden here to just > > a single dtb. > > Just to get an understanding with this change, so from what I see is > OF_LIST is used to package multiple DTBs in u-boot but they way binman > is made, we don't have dtb generator nodes that will pack them > automatically. Even if that is the case from what I understand is the > u-boot.dtb that gets generated is based on CONFIG_DEFAULT_DEVICE_TREE so > how would we know which one is the default? Or are we saying that we'll > override OF_LIST and always use only one DTB for packing in U-boot. > > The reason am asking this is because with FIT Signature, we embed a > signature node as well in the u-boot.dtb and not knowing which one is > the default and having multiple DTBs packed in U-boot have always been > problematic with this flow. ( In the past based on > CONFIG_DEFAULT_DEVICE_TREE value we have ended up packing the same DTB > twice. ) > > We use u-boot.dtb as a base reference and after adding the signature > node to it we pack it back in u-boot with EXT_DTB flag in u-boot which > gets propagated to u-boot.dtb (essentially only one DTB we can pack in > this way which has the signed node), so essentially if we use OF_LIST > and end up packing multiple DTBs I don't want use to have a conflicting > dtb actually getting packed in some other DTBs place.. > None of this changes - FIT image still is valid - but the conf-1, 2 etc makes no sense for a platform build that can only support one board. there is no board detection logic added. You just need to include the correct dtb data in. - this will also be exactly the same approach that customer boards will take when they dont need to deal with board variations (which is what majority of the customer platforms are) - the entire idea is to keep things simple and provide a good reference for customer platforms. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH V2 10/10] include: env: ti: Drop default_findfdt
envboot; run
> distro_bootcmd"
> omap4_sdp4430_defconfig:CONFIG_BOOTCOMMAND="if test ${boot_fit} -eq 1; then
> run update_to_fit; fi; run findfdt; run init_console; run envboot; run
> distro_bootcmd"
Yep - I have not cleaned up OR moved to stdboot any of the older
platforms (pre k3). That said the script that this patch is deleting is
not used anywhere else at this point in the series. So, it is safe to
remove. The existing platforms implement findfdt in many different ways
unfortunately.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
On 21:00-20240109, Francesco Dolcini wrote: > On Tue, Jan 09, 2024 at 02:54:00PM -0500, Tom Rini wrote: > > On Tue, Jan 09, 2024 at 01:18:59PM -0600, Nishanth Menon wrote: > > > On 14:26-20240109, Roger Quadros wrote: > > > > CONFIG_CMD_PMIC=y > > > > CONFIG_CMD_REGULATOR=y > > > > +CONFIG_CMD_MTDPARTS=y > > > > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" > > > > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)" > > > > > > Why not handle this as device tree partitions? > > > > I honestly forget what the preferred way of defining and passing NAND > > partition information is these days. It might even be the funny case > > that passing as cmdline args is "best" rather than fixed-partitions > > binding? > > According to past discussions [1] doing the fixup in U-Boot is not advised. > > Using the command line or having the partition fixed in the DT are both > valid options. > > [1] https://lore.kernel.org/all/20230206224838.75963-1-france...@dolcini.it/ yup - also why I wonder why we cant depend on DT. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
On 14:48-20240109, Tom Rini wrote: [...] > > > -- > > > 2.34.1 > > > > > > > Why not a config fragment? > > To me, this makes sense to keep in the main config. It can be turned off > as needed, and at run time if it's not present, it's safe. Three reasons: * There is going to be duplication across multiple boards * It confuses the affair of trying to find the minimal configuration needed to boot the board. * SRAM is limited already - we have been playing all kind of dances around this - NAND is a daughter card addon - while I am not trying to diminish NAND support, we are in a constant struggle to keep SRAM viable and adding additional boot modes to a single config, IMHO is the wrong direction to go. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH] board: ti: am64: Support TMDS64EVM
On 15:16-20240108, Roger Quadros wrote:
> The TMDS64EVM [1] ships with AM64X SR2.0 HS-FS chip
> and a slightly different board name in the board information
> EEPROM header. Support this board.
>
> [1] https://www.ti.com/tool/TMDS64EVM
>
> Gets rid of below message at boot
> "Unidentified board claims AM64-EVM in eeprom header"
>
> Signed-off-by: Roger Quadros
> ---
> board/ti/am64x/evm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
> index a6dcff2eb4..a7ca6be436 100644
> --- a/board/ti/am64x/evm.c
> +++ b/board/ti/am64x/evm.c
> @@ -18,6 +18,7 @@
> #include "../common/board_detect.h"
>
> #define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
> + board_ti_k3_is("AM64-EVM") || \
> board_ti_k3_is("AM64-HSEVM"))
>
> #define board_is_am64x_skevm() (board_ti_k3_is("AM64-SKEVM") || \
>
> base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994
> --
> 2.34.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH 4/4] configs: am64x_evm_a53_defconfig: Enable NAND
On 14:26-20240109, Roger Quadros wrote: > Enables configuration required for NAND in SPL and u-boot. > > Enable MTD Driver model and MTD + UBI command line utilities. > > Add mtdids/mtdparts for NAND as it is required for u-boot's > MTD subsystem commands to recognize NAND partitions. > > Add u-boot partition location. > > Signed-off-by: Roger Quadros > --- > configs/am64x_evm_a53_defconfig | 32 > 1 file changed, 32 insertions(+) > > diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig > index 05e35a8db6..e22153a958 100644 > --- a/configs/am64x_evm_a53_defconfig > +++ b/configs/am64x_evm_a53_defconfig > @@ -66,10 +66,15 @@ CONFIG_CMD_DFU=y > CONFIG_CMD_GPT=y > CONFIG_CMD_I2C=y > CONFIG_CMD_MMC=y > +CONFIG_CMD_MTD=y > CONFIG_CMD_USB=y > CONFIG_CMD_TIME=y > CONFIG_CMD_PMIC=y > CONFIG_CMD_REGULATOR=y > +CONFIG_CMD_MTDPARTS=y > +CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0" > +CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:2m(NAND.tiboot3),2m(NAND.tispl),2m(NAND.tiboot3.backup),4m(NAND.u-boot),256k(NAND.u-boot-env),256k(NAND.u-boot-env.backup),-(NAND.file-system)" Why not handle this as device tree partitions? > +CONFIG_CMD_UBI=y > CONFIG_OF_CONTROL=y > CONFIG_SPL_OF_CONTROL=y > CONFIG_OF_LIST="k3-am642-evm k3-am642-sk" > @@ -107,6 +112,9 @@ CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_ADMA=y > CONFIG_SPL_MMC_SDHCI_ADMA=y > CONFIG_MMC_SDHCI_AM654=y > +CONFIG_MTD=y > +CONFIG_SPL_MTD=y > +CONFIG_DM_MTD=y > CONFIG_DM_SPI_FLASH=y > CONFIG_SPI_FLASH_SPANSION=y > CONFIG_SPI_FLASH_STMICRO=y > @@ -161,3 +169,27 @@ CONFIG_USB_GADGET_DOWNLOAD=y > CONFIG_USB_FUNCTION_MASS_STORAGE=y > CONFIG_SPL_DFU=y > CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > +CONFIG_MEMORY=y > +CONFIG_SPL_MEMORY=y > +CONFIG_TI_GPMC=y > +CONFIG_MTD_RAW_NAND=y > +CONFIG_NAND_OMAP_GPMC=y > +CONFIG_CMD_NAND=y > +CONFIG_NAND_OMAP_ELM=y > +CONFIG_NAND_OMAP_ECCSCHEME_BCH8_CODE_HW=y > +CONFIG_SYS_NAND_BLOCK_SIZE=0x4 > +CONFIG_SYS_NAND_ONFI_DETECTION=y > +CONFIG_SYS_NAND_PAGE_SIZE=0x1000 > +CONFIG_SYS_NAND_PAGE_COUNT=0x40 > +CONFIG_SYS_NAND_OOBSIZE=0x100 > +CONFIG_SPL_NAND_SUPPORT=y > +CONFIG_SPL_NAND_DRIVERS=y > +CONFIG_SPL_NAND_BASE=y > +CONFIG_SPL_NAND_IDENT=y > +CONFIG_SPL_NAND_ECC=y > +CONFIG_SYS_NAND_MAX_CHIPS=1 > +CONFIG_SYS_MAX_NAND_DEVICE=1 > +# CONFIG_SPL_NAND_AM33XX_BCH is not set > +CONFIG_SPL_MTD_SUPPORT=y > +CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y > +CONFIG_SYS_NAND_U_BOOT_OFFS=0x60 > -- > 2.34.1 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH V2 04/10] board: ti: am64x: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
I have retained the the existing names used in the file as is for now, a
cleanup as suggested in review is probably something to do in a follow
on series.
V1: https://lore.kernel.org/r/20240108173301.2692332-5...@ti.com
board/ti/am64x/am64x.env | 9 -
board/ti/am64x/evm.c | 8
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index efd736b99be4..9a8812d4ee54 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -2,14 +2,6 @@
#include
#include
-findfdt=
- if test $board_name = am64x_gpevm; then
- setenv name_fdt ti/k3-am642-evm.dtb; fi;
- if test $board_name = am64x_skevm; then
- setenv name_fdt ti/k3-am642-sk.dtb; fi;
- if test $name_fdt = undefined; then
- echo WARNING: Could not determine device tree to use; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
@@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
usbboot=setenv boot usb;
setenv bootpart 0:2;
usb start;
- run findfdt;
run init_usb;
run get_kern_usb;
run get_fdt_usb;
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index a6dcff2eb434..e2f506d2c6ea 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -16,6 +16,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
board_ti_k3_is("AM64-HSEVM"))
@@ -180,6 +181,12 @@ int checkboard(void)
}
#ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
+ {"am64x_gpevm", "k3-am642-evm.dtb"},
+ {"am64x_skevm", "k3-am642-sk.dtb"},
+ { /* Sentinel. */ }
+};
+
static void setup_board_eeprom_env(void)
{
char *name = "am64x_gpevm";
@@ -197,6 +204,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_am64_evm_fdt_map);
}
static void setup_serial(void)
--
2.43.0
[PATCH V2 10/10] include: env: ti: Drop default_findfdt
We shouldn't need finfdt anymore. Drop the env script.
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
V1: https://lore.kernel.org/r/20240108173301.2692332-11...@ti.com
include/env/ti/default_findfdt.env | 12
1 file changed, 12 deletions(-)
delete mode 100644 include/env/ti/default_findfdt.env
diff --git a/include/env/ti/default_findfdt.env
b/include/env/ti/default_findfdt.env
deleted file mode 100644
index a2b51dd923bb..
--- a/include/env/ti/default_findfdt.env
+++ /dev/null
@@ -1,12 +0,0 @@
-default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
-default_device_tree_arch=ti
-#ifdef CONFIG_ARM64
-findfdt=
- setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
- setenv fdtfile ${name_fdt}
-#else
-default_device_tree_subarch=omap
-findfdt=
- setenv name_fdt
${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
- setenv fdtfile ${name_fdt}
-#endif
--
2.43.0
[PATCH V2 08/10] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from C
code.
Signed-off-by: Nishanth Menon
---
Changes from V1:
* Just macro name change s/TI_EVM_FDT_FOLDER_PATH/TI_FDT_FOLDER_PATH
* Commit message update to drop the "warning added to findfdt" since
that is not done.
I have retained the explicit setting of fdtfile to remove dependency on
TI evm specific logic. Also, the dynamic population of fdtfile instead
of env_set("fdtfile", "ti/k3-j721e-beagleboneai64.dtb") to allow for the
upcoming board variants to be able to configure the dtb name via a
config fragment.
V1: https://lore.kernel.org/r/20240108173301.2692332-9...@ti.com
board/beagle/beagleboneai64/beagleboneai64.c | 14 ++
board/beagle/beagleboneai64/beagleboneai64.env | 1 -
configs/j721e_beagleboneai64_a72_defconfig | 3 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/board/beagle/beagleboneai64/beagleboneai64.c
b/board/beagle/beagleboneai64/beagleboneai64.c
index c8c1c78ae5a2..c5b4ff7df47a 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -28,3 +28,17 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ char fdtfile[50];
+
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+ env_set("fdtfile", fdtfile);
+
+ return 0;
+}
+#endif
diff --git a/board/beagle/beagleboneai64/beagleboneai64.env
b/board/beagle/beagleboneai64/beagleboneai64.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.env
+++ b/board/beagle/beagleboneai64/beagleboneai64.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/configs/j721e_beagleboneai64_a72_defconfig
b/configs/j721e_beagleboneai64_a72_defconfig
index 959f86844d32..9e53658eacb9 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -34,7 +34,8 @@ CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d
seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.43.0
[PATCH V2 00/10] board/ti: k3 boards: Stop using findfdt
This is a wide cleanup to switch to setting fdtfile using env_set instead of scripted magic. 'fdtfile' is expected to be set by default. This allows the stdboot triggered efi loaders to find the correct OS device tree file even if regular boot process is interrupted by user intervention. This is a refresh of https://lore.kernel.org/all/86le9dwz4d@udb0321960.dhcp.ti.com/ which was the wrong approach. Updates from V1: * Renames of variables and macros for various review comments. * Commit message updates in some patches for clarity. Bootlogs: https://gist.github.com/nmenon/843e343cde645ec4aa57b60cece5256a based on master: c5e461fbf7cc Merge tag 'u-boot-imx-master-20240108' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx NOTE: There are a couple of checkpatch WARN (around LATE_INIT) and CHECK (fdt_ops #ifdeffery) that on closer inspection looks fine and consistent with other similar usage. V1: https://lore.kernel.org/all/20240108173301.2692332-1...@ti.com/ Nishanth Menon (10): board: ti: common: Introduce a common fdt ops library board: ti: am62ax: Set fdtfile from C code instead of findfdt script board: ti: am62x: Set fdtfile from C code instead of findfdt script board: ti: am64x: Set fdtfile from C code instead of findfdt script board: ti: am65x: Set fdtfile from C code instead of findfdt script board: ti: j721e: Set fdtfile from C code instead of findfdt script board: ti: j721s2: Set fdtfile from C code instead of findfdt script board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script include: env: ti: Drop default_findfdt board/beagle/beagleboneai64/beagleboneai64.c | 14 .../beagle/beagleboneai64/beagleboneai64.env | 1 - board/beagle/beagleplay/beagleplay.c | 14 board/beagle/beagleplay/beagleplay.env| 1 - board/ti/am62ax/am62ax.env| 1 - board/ti/am62ax/evm.c | 10 +++ board/ti/am62x/am62x.env | 1 - board/ti/am62x/evm.c | 8 +++ board/ti/am64x/am64x.env | 9 --- board/ti/am64x/evm.c | 8 +++ board/ti/am65x/am65x.env | 3 - board/ti/am65x/evm.c | 2 + board/ti/common/Kconfig | 12 board/ti/common/Makefile | 1 + board/ti/common/fdt_ops.c | 64 +++ board/ti/common/fdt_ops.h | 42 board/ti/j721e/evm.c | 8 +++ board/ti/j721e/j721e.env | 10 --- board/ti/j721s2/evm.c | 8 +++ board/ti/j721s2/j721s2.env| 8 --- configs/am62ax_evm_a53_defconfig | 1 + configs/am62x_beagleplay_a53_defconfig| 3 +- configs/am62x_evm_a53_defconfig | 1 + configs/j721e_beagleboneai64_a72_defconfig| 3 +- include/env/ti/default_findfdt.env| 12 25 files changed, 197 insertions(+), 48 deletions(-) create mode 100644 board/ti/common/fdt_ops.c create mode 100644 board/ti/common/fdt_ops.h delete mode 100644 include/env/ti/default_findfdt.env -- 2.43.0
[PATCH V2 09/10] board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from C
code.
Signed-off-by: Nishanth Menon
---
Changes from V1:
* Just macro name change s/TI_EVM_FDT_FOLDER_PATH/TI_FDT_FOLDER_PATH
* Commit message update to drop the "warning added to findfdt" since
that is not done.
I have retained the explicit setting of fdtfile to remove dependency on
TI evm specific logic. Also, the dynamic population of fdtfile instead
of env_set("fdtfile", "ti/k3-am625-beagleplay.dtb") to allow for the
upcoming board variants to be able to configure the dtb name via a
config fragment.
V1: https://lore.kernel.org/r/20240108173301.2692332-10...@ti.com
board/beagle/beagleplay/beagleplay.c | 14 ++
board/beagle/beagleplay/beagleplay.env | 1 -
configs/am62x_beagleplay_a53_defconfig | 3 ++-
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/board/beagle/beagleplay/beagleplay.c
b/board/beagle/beagleplay/beagleplay.c
index 1c376dea372f..20819ecf45b4 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -27,3 +27,17 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ char fdtfile[50];
+
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+ env_set("fdtfile", fdtfile);
+
+ return 0;
+}
+#endif
diff --git a/board/beagle/beagleplay/beagleplay.env
b/board/beagle/beagleplay/beagleplay.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/configs/am62x_beagleplay_a53_defconfig
b/configs/am62x_beagleplay_a53_defconfig
index 0be20045a974..1f43891d10bb 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -33,7 +33,8 @@ CONFIG_AUTOBOOT_KEYED=y
CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
CONFIG_AUTOBOOT_DELAY_STR="d"
CONFIG_AUTOBOOT_STOP_STR=" "
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot;
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
--
2.43.0
[PATCH V2 06/10] board: ti: j721e: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
v1: https://lore.kernel.org/r/20240108173301.2692332-7...@ti.com
board/ti/j721e/evm.c | 8
board/ti/j721e/j721e.env | 10 --
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index c541880107ec..ad6ef4553e04 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -16,6 +16,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_j721e_som() (board_ti_k3_is("J721EX-PM1-SOM") || \
board_ti_k3_is("J721EX-PM2-SOM"))
@@ -424,6 +425,12 @@ void configure_serdes_sierra(void)
}
#ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
+ {"j721e", "k3-j721e-common-proc-board.dtb"},
+ {"j721e-sk", "k3-j721e-sk.dtb"},
+ {"j7200", "k3-j7200-common-proc-board.dtb"},
+ { /* Sentinel. */ }
+};
static void setup_board_eeprom_env(void)
{
char *name = "j721e";
@@ -443,6 +450,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
}
static void setup_serial(void)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index cb27bf5e2b24..38bfd7d49634 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -7,16 +7,6 @@
#include
#endif
-default_device_tree=ti/k3-j721e-common-proc-board.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- if test $board_name = j721e; then
- setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
- if test $board_name = j7200; then
- setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
- if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
- setenv name_fdt ti/k3-j721e-sk.dtb; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
--
2.43.0
[PATCH V2 07/10] board: ti: j721s2: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
V1: https://lore.kernel.org/r/20240108173301.2692332-8...@ti.com
board/ti/j721s2/evm.c | 8
board/ti/j721s2/j721s2.env | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 1220cd84519b..5a0281d6b483 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -23,6 +23,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -114,6 +115,12 @@ int checkboard(void)
return 0;
}
+static struct ti_fdt_map ti_j721s2_evm_fdt_map[] = {
+ {"j721s2", "k3-j721s2-common-proc-board.dtb"},
+ {"am68-sk", "k3-am68-sk-base-board.dtb"},
+ { /* Sentinel. */ }
+};
+
static void setup_board_eeprom_env(void)
{
char *name = "j721s2";
@@ -131,6 +138,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(name, ti_j721s2_evm_fdt_map);
}
static void setup_serial(void)
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 64e3d9da85f0..9a03b9f30aee 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -7,14 +7,6 @@
#include
#endif
-default_device_tree=ti/k3-j721s2-common-proc-board.dtb
-findfdt=
- setenv name_fdt ${default_device_tree};
- if test $board_name = j721s2; then \
- setenv name_fdt ti/k3-j721s2-common-proc-board.dtb; fi;
- if test $board_name = am68-sk; then
- setenv name_fdt ti/k3-am68-sk-base-board.dtb; fi;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
--
2.43.0
[PATCH V2 02/10] board: ti: am62ax: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
I have retained the central call ti_set_fdt_env() to retain the
population of fdtfile name using the CONFIG fall back logic and the
population of (now deprecated) legacy variables for downstream script
users.
V1: https://lore.kernel.org/r/20240108173301.2692332-3...@ti.com
board/ti/am62ax/am62ax.env | 1 -
board/ti/am62ax/evm.c| 10 ++
configs/am62ax_evm_a53_defconfig | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index a6d967e982d4..334374abb73e 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
index cd3360a43029..62d3664936e7 100644
--- a/board/ti/am62ax/evm.c
+++ b/board/ti/am62ax/evm.c
@@ -13,6 +13,8 @@
#include
#include
+#include "../common/fdt_ops.h"
+
int board_init(void)
{
return 0;
@@ -27,3 +29,11 @@ int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
}
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 38083586a3ec..e5fcd8cc5b6f 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -24,6 +24,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTSTD_DEFAULTS=y
CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_PAD_TO=0x0
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
--
2.43.0
[PATCH V2 01/10] board: ti: common: Introduce a common fdt ops library
Introduce a common fdt operations library for basic device tree
operations that are common between various boards.
The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.
Signed-off-by: Nishanth Menon
---
Changes Since v1:
* s/TI_EVM_FDT_FOLDER_PATH/TI_FDT_FOLDER_PATH s/name_fdt/board_name
s/TI_NAME_FDT_MAX/TI_BOARD_NAME_MAX
* Comment updates in various places for review clarification.
* Still maintain the fall back using CONFIG_DEFAULT_DEVICE_TREE for
reasons explained in review comment response.
* Added a specific u-boot version number for deprecation of legacy
env variables.
V1: https://lore.kernel.org/r/20240108173301.2692332-2...@ti.com
board/ti/common/Kconfig | 12
board/ti/common/Makefile | 1 +
board/ti/common/fdt_ops.c | 64 +++
board/ti/common/fdt_ops.h | 42 +
4 files changed, 119 insertions(+)
create mode 100644 board/ti/common/fdt_ops.c
create mode 100644 board/ti/common/fdt_ops.h
diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab..de44e4de2115 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
imply CMD_SPI
imply CMD_TIME
imply CMD_USB if USB
+
+config TI_FDT_FOLDER_PATH
+ string "Location of Folder path where dtb is present"
+ default "ti/davinci" if ARCH_DAVINCI
+ default "ti/keystone" if ARCH_KEYSTONE
+ default "ti/omap" if ARCH_OMAP2PLUS
+ default "ti" if ARCH_K3
+ depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
+ help
+ Folder path for kernel device tree default.
+ This is used along with fdtfile path to locate the kernel
+ device tree blob.
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 26bf12e2e6d5..5ac361ba7fcf 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -3,3 +3,4 @@
obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
new file mode 100644
index ..eb917be9e0da
--- /dev/null
+++ b/board/ti/common/fdt_ops.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Library to support FDT file operations which are common
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include
+#include "fdt_ops.h"
+
+void ti_set_fdt_env(const char *board_name, struct ti_fdt_map *fdt_map)
+{
+ char *fdt_file_name = NULL;
+ char fdtfile[TI_FDT_FILE_MAX];
+
+ if (board_name) {
+ while (fdt_map) {
+ /* Check for NULL terminator in the list */
+ if (!fdt_map->board_name)
+ break;
+ if (!strncmp(fdt_map->board_name, board_name,
TI_BOARD_NAME_MAX)) {
+ fdt_file_name = fdt_map->fdt_file_name;
+ break;
+ }
+ fdt_map++;
+ }
+ }
+
+ /* match not found OR null board_name */
+ if (!fdt_file_name) {
+ /*
+* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
+* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
+*/
+#ifdef CONFIG_DEFAULT_FDT_FILE
+ if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
+CONFIG_TI_FDT_FOLDER_PATH,
CONFIG_DEFAULT_FDT_FILE);
+ } else
+#endif
+ {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH,
CONFIG_DEFAULT_DEVICE_TREE);
+ }
+ } else {
+ snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
CONFIG_TI_FDT_FOLDER_PATH,
+fdt_file_name);
+ }
+
+ env_set("fdtfile", fdtfile);
+
+ /*
+* XXX: DEPRECATION WARNING: 2 u-boot versions (2024.10).
+*
+* Maintain compatibility with downstream scripts that may be using
+* name_fdt
+*/
+ if (board_name)
+ env_set("name_fdt", fdtfile);
+ /* Also set the findfdt legacy script to warn users to stop using this
*/
+ env_set("findfdt",
+ "echo WARN: fdtfile already set. Stop using findfdt in script");
+}
diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
new file mode 100644
index ..5d304994fb6e
--- /dev/null
+++ b/board/ti/co
[PATCH V2 03/10] board: ti: am62x: Set fdtfile from C code instead of findfdt script
Stop using the findfdt script and switch to setting the fdtfile from
C code.
While at this, replace findfdt in environment with a warning as it is
no longer needed
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
I have retained the central call ti_set_fdt_env() to retain the
population of fdtfile name using the CONFIG fall back logic and the
population of (now deprecated) legacy variables for downstream script
users.
V1: https://lore.kernel.org/r/20240108173301.2692332-4...@ti.com
board/ti/am62x/am62x.env| 1 -
board/ti/am62x/evm.c| 8
configs/am62x_evm_a53_defconfig | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index e53a55c38fbb..9cb186c2a03c 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,5 +1,4 @@
#include
-#include
#include
name_kern=Image
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index ad939088402e..b76ef1b94a61 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -54,6 +54,14 @@ int dram_init(void)
return fdtdec_setup_mem_size_base();
}
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+ ti_set_fdt_env(NULL, NULL);
+ return 0;
+}
+#endif
+
int dram_init_banksize(void)
{
return fdtdec_setup_memory_banksize();
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index aa96c1b3125c..3cf3b93a93fc 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -32,6 +32,7 @@ CONFIG_BOOTSTD_FULL=y
CONFIG_BOOTSTD_DEFAULTS=y
CONFIG_SYS_BOOTM_LEN=0x80
CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
--
2.43.0
[PATCH V2 05/10] board: ti: am65x: Set fdtfile from C code instead of findfdt script
We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".
While at this, replace findfdt in environment with a warning as it is no
longer needed.
Signed-off-by: Nishanth Menon
---
Changes from V1: None.
I have retained the central call ti_set_fdt_env() to retain the
population of fdtfile name using the CONFIG fall back logic and the
population of (now deprecated) legacy variables for downstream script
users.
V1: https://lore.kernel.org/r/20240108173301.2692332-6...@ti.com
board/ti/am65x/am65x.env | 3 ---
board/ti/am65x/evm.c | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 286b9c300c05..814374d68cf0 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -5,9 +5,6 @@
#include
#endif
-findfdt=
- setenv name_fdt ti/k3-am654-base-board.dtb;
- setenv fdtfile ${name_fdt}
name_kern=Image
console=ttyS2,115200n8
args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index df209021c1b7..3109c9a2acac 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -22,6 +22,7 @@
#include
#include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
#define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
@@ -141,6 +142,7 @@ static void setup_board_eeprom_env(void)
invalid_eeprom:
set_board_info_env_am6(name);
+ ti_set_fdt_env(NULL, NULL);
}
static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
--
2.43.0
Re: [PATCH 0/4] arm: mach-k3: am64: Add NAND configuration
On 14:26-20240109, Roger Quadros wrote: > Hi, > > AM64-EVM [1] supports NAND via expansion card. > > This series fixes the GPMC memory and NAND drivers > and provides NAND configuration for AM642 platform. > > The extension card support and NAND DT overlay is > still missing so NAND is not yet functional just with > this series. > > It was tested with NAND overlay [2] manually applied to base > AM64-EVM DT. > > CI test results are available at > https://github.com/u-boot/u-boot/pull/460 > > [1] https://www.ti.com/tool/TMDS64EVM > [2] https://lore.kernel.org/all/20230923080046.5373-2-rog...@kernel.org/ > > Roger Quadros (4): > memory: ti-gpmc: Fix build > mtd: rawnand: omap_gpmc: Use DT provided IO address > arm: mach-k3: am642: Define NAND boot device > configs: am64x_evm_a53_defconfig: Enable NAND > > arch/arm/mach-k3/am642_init.c| 3 +++ > arch/arm/mach-k3/include/mach/am64_spl.h | 1 + > configs/am64x_evm_a53_defconfig | 32 > drivers/memory/ti-gpmc.c | 2 +- > drivers/mtd/nand/raw/omap_gpmc.c | 19 ++ > 5 files changed, 51 insertions(+), 6 deletions(-) Please update am64x documentation as well. People will need to know how to actually build, flash and use it. > > > base-commit: c2c598e87cfe56f5991730762c00733c5aa9a994 > prerequisite-patch-id: e0465f3e924302d1c4bd47f2129b4eb3bd9faead > -- > 2.34.1 > -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
