Re: Raspberry Pi 3b Plus USB-Ethernet lan78xx_eth address not set
Hi Anand, Thanks for the update. Yes, I can set it manually. But this should be done by u-boot, right? Is there any reason why this is not happening on Pi 3b plus? I have other Raspberry Pi (4 & 3b) and they are working fine. Also, is this MAC address for LAN75xx or LAN78xx? The error message shows lan78xx_eth. On Sun, Feb 25, 2024, 06:50 Anand Moon wrote: > Hi, > > On Sat, 24 Feb 2024 at 01:56, Sourabh Hegde Ramu > wrote: > > > > Hello, > > > > I have a Raspberry Pi 3B Plus which I want to integrate with U-boot > > (v2023.10) . > > > > I am using rpi_3_32b_defconfig to generate u-boot.bin. But while booting > I > > am getting below error > > > > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > > In:serial,usbkbd > > Out: serial,vidconsole > > Err: serial,vidconsole > > Net: No ethernet found. > > starting USB... > > Bus usb@7e98: USB DWC2 > > scanning bus usb@7e98 for devices... > > Error: lan78xx_eth address not set. > > 3 USB Device(s) found > >scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > > > In the "bdinfo", "current eth" is not set > > > > U-Boot> bdinfo > > boot_params = 0x0100 > > DRAM bank = 0x > > -> start= 0x > > -> size = 0x3b40 > > flashstart = 0x > > flashsize = 0x > > flashoffset = 0x > > baudrate= 115200 bps > > relocaddr = 0x3b36 > > reloc off = 0x3b358000 > > Build = 32-bit > > current eth = unknown > > eth-1addr = (not set) > > IP addr = > > > > I also enabled LAN75xx in menuconfig and re-compiled u-boot. But still > the > > same error. > > > > However on Raspberry Pi 3B, I don't see this error and "current eth" is > set > > to "smsc95xx_eth" and "ethaddr" is also available. > > > > Can anyone please let me know the issue with Raspberry Pi 3b plus? > > > > Thanks in advance. > > Can you set the MAC address in boot environment? > > # setenv ethaddr 00:14:05:42:03:BB > # saveenv > > It should update the mac address for LAN75xx > printenv should display the mac address > > Thanks > -Anand >
Re: Raspberry Pi 3b Plus USB-Ethernet lan78xx_eth address not set
Hi, On Sat, 24 Feb 2024 at 01:56, Sourabh Hegde Ramu wrote: > > Hello, > > I have a Raspberry Pi 3B Plus which I want to integrate with U-boot > (v2023.10) . > > I am using rpi_3_32b_defconfig to generate u-boot.bin. But while booting I > am getting below error > > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > In:serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: No ethernet found. > starting USB... > Bus usb@7e98: USB DWC2 > scanning bus usb@7e98 for devices... > Error: lan78xx_eth address not set. > 3 USB Device(s) found >scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 0 > > In the "bdinfo", "current eth" is not set > > U-Boot> bdinfo > boot_params = 0x0100 > DRAM bank = 0x > -> start= 0x > -> size = 0x3b40 > flashstart = 0x > flashsize = 0x > flashoffset = 0x > baudrate= 115200 bps > relocaddr = 0x3b36 > reloc off = 0x3b358000 > Build = 32-bit > current eth = unknown > eth-1addr = (not set) > IP addr = > > I also enabled LAN75xx in menuconfig and re-compiled u-boot. But still the > same error. > > However on Raspberry Pi 3B, I don't see this error and "current eth" is set > to "smsc95xx_eth" and "ethaddr" is also available. > > Can anyone please let me know the issue with Raspberry Pi 3b plus? > > Thanks in advance. Can you set the MAC address in boot environment? # setenv ethaddr 00:14:05:42:03:BB # saveenv It should update the mac address for LAN75xx printenv should display the mac address Thanks -Anand
Re: [PATCH v2 2/3] arm: mach-k3: j721e: Enable OSPI boot
Thanks For fixing this
On 2/24/2024 5:53 AM, Jonathan Humphreys wrote:
Add boot ROM XSPI bootmode, and set to BOOT_DEVICE_SPI if detected.
Signed-off-by: Jonathan Humphreys
---
arch/arm/mach-k3/include/mach/j721e_spl.h | 5 +++--
arch/arm/mach-k3/j721e_init.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-k3/include/mach/j721e_spl.h
b/arch/arm/mach-k3/include/mach/j721e_spl.h
index ed3d7333bd..aaee653537 100644
--- a/arch/arm/mach-k3/include/mach/j721e_spl.h
+++ b/arch/arm/mach-k3/include/mach/j721e_spl.h
@@ -24,8 +24,9 @@
#define BOOT_DEVICE_UFS 0x13
#define BOOT_DEVIE_GPMC 0x14
#define BOOT_DEVICE_PCIE 0x15
-#define BOOT_DEVICE_MMC2_2 0x16
-#define BOOT_DEVICE_RAM0x17
+#define BOOT_DEVICE_XSPI 0x16
+#define BOOT_DEVICE_RAM0x17
+#define BOOT_DEVICE_MMC2_2 0xFF /* Invalid value */
/* Backup boot modes with MCU Only = 0 */
#define BACKUP_BOOT_DEVICE_RAM0x0
diff --git a/arch/arm/mach-k3/j721e_init.c b/arch/arm/mach-k3/j721e_init.c
index c2976c4ea0..7ee9b75de4 100644
--- a/arch/arm/mach-k3/j721e_init.c
+++ b/arch/arm/mach-k3/j721e_init.c
@@ -346,7 +346,8 @@ static u32 __get_primary_bootmedia(u32 main_devstat, u32
wkup_devstat)
bootmode |= (main_devstat & MAIN_DEVSTAT_BOOT_MODE_B_MASK) <<
BOOT_MODE_B_SHIFT;
- if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI)
+ if (bootmode == BOOT_DEVICE_OSPI || bootmode == BOOT_DEVICE_QSPI ||
+ bootmode == BOOT_DEVICE_XSPI)
bootmode = BOOT_DEVICE_SPI;
Reviewed-by: Udit Kumar
if (bootmode == BOOT_DEVICE_MMC2) {
Re: [PATCH v2 1/3] configs: j721e: Enable OSPI memory
On 2/24/2024 5:53 AM, Jonathan Humphreys wrote: Set config values to enable OSPI functionality. Signed-off-by: Jonathan Humphreys --- configs/j721e_evm_a72_defconfig | 7 +++ configs/j721e_evm_r5_defconfig | 6 ++ 2 files changed, 13 insertions(+) diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 74af5bebb5..1b39dd7c86 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -10,6 +10,7 @@ CONFIG_SOC_K3_J721E=y CONFIG_TARGET_J721E_A72_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048 +CONFIG_SF_DEFAULT_SPEED=2500 CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y @@ -142,7 +143,13 @@ CONFIG_FLASH_CFI_MTD=y CONFIG_SYS_FLASH_CFI=y CONFIG_SYS_MAX_FLASH_BANKS_DETECT=y CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MT35XU=y # CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_SPI_FLASH_MTD=y CONFIG_MULTIPLEXER=y diff --git a/configs/j721e_evm_r5_defconfig b/configs/j721e_evm_r5_defconfig index bc4f35cce1..59c0c4135c 100644 --- a/configs/j721e_evm_r5_defconfig +++ b/configs/j721e_evm_r5_defconfig @@ -10,6 +10,7 @@ CONFIG_K3_EARLY_CONS=y CONFIG_TARGET_J721E_R5_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x41cf59f0 +CONFIG_SF_DEFAULT_SPEED=2500 CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y @@ -128,7 +129,12 @@ CONFIG_FLASH_CFI_MTD=y CONFIG_SYS_FLASH_CFI=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_SOFT_RESET=y +CONFIG_SPI_FLASH_SOFT_RESET_ON_BOOT=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_S28HX_T=y CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_MT35XU=y Reviewed-by: Udit Kumar CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y
Re: [PATCH v2 3/3] arm: dts: k3-j721e-sk: Remove OSPI phypattern partition
Thanks Jon
On 2/24/2024 5:53 AM, Jonathan Humphreys wrote:
The phy calibration pattern partition isn't needed as the Cadence driver isn't
calibrating the phys.
Please do mention Fixes tag here
58d61fb5a77e ("arm: dts: k3-j721e-sk: Add initial A72 specific dts support")
Signed-off-by: Jonathan Humphreys
---
arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
index 479b7bcd6f..20b76a84ff 100644
--- a/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-sk-u-boot.dtsi
@@ -157,9 +157,5 @@
flash@0 {
bootph-all;
-
- partition@3fc {
- bootph-all;
- };
};
This Patch LTGM,
+ Neha
For further cleanup, we should not have these ospi nodes in u-boot dts file.
should be in board dts (k3-j721e-sk.dts) with right bootph properties ,
and comes via kernel DT.
};
[PATCH RESEND] serial: pl01x: set baudrate when probing
From: Yang Xiwen
It is found that when DM is enabled, only generic init function is
called in .probe(). Baudrate is never honored. Add a function call
to .setbrg() when probing so that we can update the baudrate of the
serial device.
Signed-off-by: Yang Xiwen
---
drivers/serial/serial_pl01x.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 428a4d210de5..57bbcaf3b619 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -290,6 +290,7 @@ int pl01x_serial_probe(struct udevice *dev)
{
struct pl01x_serial_plat *plat = dev_get_plat(dev);
struct pl01x_priv *priv = dev_get_priv(dev);
+ int ret;
#if CONFIG_IS_ENABLED(OF_PLATDATA)
struct dtd_serial_pl01x *dtplat = >dtplat;
@@ -301,10 +302,14 @@ int pl01x_serial_probe(struct udevice *dev)
#endif
priv->type = plat->type;
- if (!plat->skip_init)
- return pl01x_generic_serial_init(priv->regs, priv->type);
- else
+ if (!plat->skip_init) {
+ ret = pl01x_generic_serial_init(priv->regs, priv->type);
+ if (!ret)
+ return ret;
+ return pl01x_serial_setbrg(dev, gd->baudrate);
+ } else {
return 0;
+ }
}
int pl01x_serial_getc(struct udevice *dev)
---
base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3
change-id: 20240123-b4-pl011-ee9575ff2a38
Best regards,
--
Yang Xiwen
[PATCH] rockchip: rock64: store env in SPI flash
Currently, U-Boot attempts to store the environment in MMC 0, which doesn't work when an eMMC is used without an SD card. There is an SPI flash chip on the board, so use that instead which should work in all cases. Additionally, this brings the Rock64 into line with the RockPro64. Signed-off-by: Ben Wolsieffer --- configs/rock64-rk3328_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 0297d09876..589e5184ca 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -8,6 +8,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 CONFIG_SF_DEFAULT_SPEED=2000 +CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64" CONFIG_DM_RESET=y @@ -54,7 +55,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_TPL_OF_CONTROL=y CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_TPL_OF_PLATDATA=y -CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_NET_RANDOM_ETHADDR=y -- 2.43.2
Re: [PATCH 1/1] arm: separate .data and .text sections of EFI binaries
On 2/24/24 10:16, Heinrich Schuchardt wrote:
On 2/16/24 11:35, Ilias Apalodimas wrote:
Hi Heinrich,
[...]
}
+ .rela.dyn : { *(.rela.dyn) }
+ .rela.plt : { *(.rela.plt) }
+ .rela.got : { *(.rela.got) }
+ .rela.data : { *(.rela.data) *(.rela.data*) }
Why are we switching from Rel to Rela?
This was wrong.
Looking at the u-boot ELF binary we see these relocation sections:
arm: .rel.dyn
arm64: .rela.dyn
riscv64: .rela.dyn
In our EFI object files we currently have no relocations. This is why
tests did not complain.
In arch/arm/lib/reloc_arm_efi.c we handle DT_REL.
In arch/arm/lib/reloc_aarch64_efi.c we handle DT_RELA.
In arch/riscv/lib/reloc_riscv_efi.c we handle DT_RELA.
To be truthful our generated binaries are only usable because we have no
relocations.
If we had relocations, copying these to the .text or .data section would
would not work. We would have to translate them to the relocation format
of PE files and put them into the .reloc section like EDK II does in
BaseTools/Source/C/GenFw/Elf32Convert.c.
Best regards
Heinrich
Best regards
Heinrich
_etext = .;
_text_size = . - _text;
- .dynamic : { *(.dynamic) }
+ . = ALIGN(4096);
.data : {
_data = .;
*(.sdata)
@@ -47,20 +59,19 @@ SECTIONS
. = ALIGN(512);
_bss_end = .;
_edata = .;
- }
- .rel.dyn : { *(.rel.dyn) }
- .rel.plt : { *(.rel.plt) }
- .rel.got : { *(.rel.got) }
- .rel.data : { *(.rel.data) *(.rel.data*) }
- _data_size = . - _etext;
+ } :data
+ _data_size = _edata - _data;
+ . = ALIGN(4096);
+ .dynsym : { *(.dynsym) }
+ . = ALIGN(4096);
+ .dynstr : { *(.dynstr) }
+ . = ALIGN(4096);
+ .note.gnu.build-id : { *(.note.gnu.build-id) }
/DISCARD/ : {
*(.rel.reloc)
*(.eh_frame)
*(.note.GNU-stack)
- *(.dynsym)
- *(.dynstr)
- *(.note.gnu.build-id)
- *(.comment)
}
+ .comment 0 : { *(.comment) }
}
--
2.43.0
Cheers
/Ilias
[PATCH v2 3/3] mmc: renesas-sdhi: Do not access SCC during tuning in send_cmd callback
Do not access SCC when sending commands during tuning operation as that will disrupt the tuning operation. The tuning operation is adjusting the SCC settings itself in execute_tuning callback. When renesas_sdhi_execute_tuning() is called by the MMC core code, a loop which consists of renesas_sdhi_prepare_tuning(), mmc_send_tuning() and renesas_sdhi_compare_scc_data() iterates over each SCC tuning tap. The renesas_sdhi_prepare_tuning() configures the SCC tuning tap number into hardware, mmc_send_tuning() triggers transfer of tuning block which depends on the bus mode for which the bus is currently being tuned, this information is supplied by the MMC core code, and finally renesas_sdhi_compare_scc_data() tests the received tuning block for validity. Because renesas_sdhi_prepare_tuning() configures the SCC tuning tap into the hardware to fit the tuning operation, mmc_send_tuning() which triggers command transfer using renesas_sdhi_send_cmd() must not manipulate with the SCC in any way. Currently renesas_sdhi_send_cmd() does unconditionally call renesas_sdhi_check_scc_error(), which may adjust the SCC tuning tap position by writing RENESAS_SDHI_SCC_TAPSET, which would overwrite the required tuning configuration set by renesas_sdhi_prepare_tuning() and disrupt the tuning operation. Fix this by skipping the renesas_sdhi_check_scc_error() call in case the MMC subsystem is in tuning state. This way, the SCC settings are left unmodified by command transfer during tuning operation. Reviewed-by: Paul Barker Tested-by: Paul Barker Signed-off-by: Marek Vasut --- Cc: Hai Pham Cc: Jaehoon Chung Cc: Nobuhiro Iwamatsu Cc: Paul Barker Cc: Peng Fan Cc: Sean Anderson Cc: Tom Rini Cc: Yoshihiro Shimoda --- V2: Add RB/TB from Paul --- drivers/mmc/renesas-sdhi.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c index 29a742f404e..c4d0733b621 100644 --- a/drivers/mmc/renesas-sdhi.c +++ b/drivers/mmc/renesas-sdhi.c @@ -798,9 +798,12 @@ static int renesas_sdhi_send_cmd(struct udevice *dev, struct mmc_cmd *cmd, #if CONFIG_IS_ENABLED(MMC_UHS_SUPPORT) || \ CONFIG_IS_ENABLED(MMC_HS200_SUPPORT) || \ CONFIG_IS_ENABLED(MMC_HS400_SUPPORT) + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); struct tmio_sd_priv *priv = dev_get_priv(dev); + struct mmc *mmc = upriv->mmc; - renesas_sdhi_check_scc_error(dev); + if (!mmc->tuning) + renesas_sdhi_check_scc_error(dev); if (cmd->cmdidx == MMC_CMD_SEND_STATUS) renesas_sdhi_adjust_hs400_mode_enable(priv); -- 2.43.0
[PATCH v2 2/3] mmc: Add generic tuning flag
Set generic mmc->tuning flag when performing tuning to indicate
this condition to drivers. Drivers may use this to bypass various
checks during tuning.
Signed-off-by: Marek Vasut
---
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Nobuhiro Iwamatsu
Cc: Paul Barker
Cc: Peng Fan
Cc: Sean Anderson
Cc: Tom Rini
Cc: Yoshihiro Shimoda
---
V2: Use bool var:1;
---
drivers/mmc/mmc-uclass.c | 8 +++-
include/mmc.h| 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 328456831dd..304bd5eaee2 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -124,7 +124,13 @@ static int dm_mmc_execute_tuning(struct udevice *dev, uint
opcode)
int mmc_execute_tuning(struct mmc *mmc, uint opcode)
{
- return dm_mmc_execute_tuning(mmc->dev, opcode);
+ int ret;
+
+ mmc->tuning = true;
+ ret = dm_mmc_execute_tuning(mmc->dev, opcode);
+ mmc->tuning = false;
+
+ return ret;
}
#endif
diff --git a/include/mmc.h b/include/mmc.h
index afca123b386..5c1be5c5b1e 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -736,6 +736,7 @@ struct mmc {
* accessing the boot partitions
*/
u32 quirks;
+ bool tuning:1;
bool hs400_tuning:1;
enum bus_mode user_speed_mode; /* input speed mode from user */
--
2.43.0
[PATCH v2 1/3] mmc: Convert hs400_tuning flag from u8 to bool
This hs400_tuning is a flag, make it bool. No functional change.
This will be useful in the following patch, which adds another
more generic flag, where the compiler can better use the space
now reserved for the u8 to store more flags in it.
Signed-off-by: Marek Vasut
---
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Nobuhiro Iwamatsu
Cc: Paul Barker
Cc: Peng Fan
Cc: Sean Anderson
Cc: Tom Rini
Cc: Yoshihiro Shimoda
---
V2: Use bool var:1;
---
drivers/mmc/mmc.c | 4 ++--
include/mmc.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 83f9ae8bb7d..07d87c993a6 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -2027,9 +2027,9 @@ static int mmc_select_hs400(struct mmc *mmc)
mmc_set_clock(mmc, mmc->tran_speed, false);
/* execute tuning if needed */
- mmc->hs400_tuning = 1;
+ mmc->hs400_tuning = true;
err = mmc_execute_tuning(mmc, MMC_CMD_SEND_TUNING_BLOCK_HS200);
- mmc->hs400_tuning = 0;
+ mmc->hs400_tuning = false;
if (err) {
debug("tuning failed\n");
return err;
diff --git a/include/mmc.h b/include/mmc.h
index 2b9a6aa8ee0..afca123b386 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -736,7 +736,7 @@ struct mmc {
* accessing the boot partitions
*/
u32 quirks;
- u8 hs400_tuning;
+ bool hs400_tuning:1;
enum bus_mode user_speed_mode; /* input speed mode from user */
};
--
2.43.0
[GIT PULL] Please pull u-boot-imx-master-20240224
Hi Tom, Please pull from u-boot-imx, thanks. The following changes since commit bb9d6c7f4f6a598e8856b2e19e58c7de078a0d6e: Merge tag 'u-boot-amlogic-fixes-20240223' of https://source.denx.de/u-boot/custodians/u-boot-amlogic (2024-02-23 12:54:03 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240224 for you to fetch changes up to 7c76b1b91bf67cd09fdf5dbd71590f9e580590fa: opos6uldev: Convert to watchdog driver model (2024-02-24 16:29:24 -0300) u-boot-imx-master-20240224 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19725 - Enable the thermal driver for the imx8m phycore boards. - Convert imx53-qsb to watchdog driver to fix the 'reset' command. - Remove multiline string from imx6dl-sielaff. - Add SPI boot support for imxrt1050-evk. - Convert opos6uldev to watchdog driver to fix the 'reset' command. Benjamin Hahn (3): phycore-imx8mp_defconfig: Enable CONFIG_IMX_TMU phycore-imx8mm_defconfig: Enable CONFIG_IMX_TMU imx8mm-phygate-tauri-l_defconfig: Enable CONFIG_IMX_TMU Fabio Estevam (1): imx53-qsb: Convert to watchdog driver model Frieder Schrempf (1): board: imx6dl-sielaff: spl.c: Remove multiline string Jesse Taube (2): imx: imxrt1050-evk: Add support for SPI flash booting imx: imxrt1050-evk: Add documentation for SPI boot Mathieu Othacehe (4): arm: dts: imx93: Add USB support. arm: dts: imx93-var-som-symphony: Add USB support. configs: imx93_var_som: Add USB support. configs: imx93_var_som: Add fastboot support. Sébastien Szymanski (1): opos6uldev: Convert to watchdog driver model arch/arm/dts/imx53-qsb-u-boot.dtsi | 13 arch/arm/dts/imx6ul-opos6ul-u-boot.dtsi| 10 +++ arch/arm/dts/imx93-var-som-symphony.dts| 18 + arch/arm/dts/imx93.dtsi| 58 ++ arch/arm/dts/imxrt1020-evk-u-boot.dtsi | 4 + arch/arm/dts/imxrt1050-evk-u-boot.dtsi | 31 arch/arm/dts/imxrt1170-evk-u-boot.dtsi | 4 + arch/arm/mach-imx/imxrt/Kconfig| 1 + board/freescale/imxrt1050-evk/MAINTAINERS | 1 + board/freescale/imxrt1050-evk/imximage-nor.cfg | 41 ++ board/freescale/imxrt1050-evk/imximage.cfg | 10 ++- board/freescale/imxrt1050-evk/imxrt1050-evk.c | 7 +- board/sielaff/imx6dl-sielaff/spl.c | 4 +- configs/imx8mm-phygate-tauri-l_defconfig | 1 + configs/imx93_var_som_defconfig| 15 configs/imxrt1050-evk_defconfig| 8 +- configs/imxrt1050-evk_fspi_defconfig | 100 + configs/mx53loco_defconfig | 3 + configs/opos6uldev_defconfig | 3 + configs/phycore-imx8mm_defconfig | 1 + configs/phycore-imx8mp_defconfig | 1 + doc/board/nxp/imxrt1050-evk.rst| 30 include/configs/imxrt1050-evk.h| 6 ++ 23 files changed, 362 insertions(+), 8 deletions(-) create mode 100644 arch/arm/dts/imx53-qsb-u-boot.dtsi create mode 100644 board/freescale/imxrt1050-evk/imximage-nor.cfg create mode 100644 configs/imxrt1050-evk_fspi_defconfig
Re: [PATCH 1/1] opos6uldev: Convert to watchdog driver model
On Fri, Feb 23, 2024 at 8:28 AM Sébastien Szymanski
wrote:
>
> Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
> the 'reset' command in U-Boot to not cause a board reset.
>
> Fix it by switching to the watchdog driver model via sysreset, which
> is the preferred method for implementing the watchdog reset.
>
> Signed-off-by: Sébastien Szymanski
Applied, thanks.
Re: [PATCH] imx53-qsb: Convert to watchdog driver model
On Wed, Feb 21, 2024 at 2:39 PM Fabio Estevam wrote:
>
> Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
> the 'reset' command in U-Boot to not cause a board reset.
>
> Fix it by switching to the watchdog driver model via sysreset, which
> is the preferred method for implementing the watchdog reset.
>
> Signed-off-by: Fabio Estevam
Applied, thanks.
Re: [PATCH 0/3] Enable IMX_TMU driver for PHYTEC boards
On Tue, Feb 20, 2024 at 7:43 AM Benjamin Hahn wrote: > > Enable IMX_TMU driver to prevent the system from booting when it is too > hot. > > Signed-off-by: Benjamin Hahn > --- > Benjamin Hahn (3): > phycore-imx8mp_defconfig: Enable CONFIG_IMX_TMU > phycore-imx8mm_defconfig: Enable CONFIG_IMX_TMU > imx8mm-phygate-tauri-l_defconfig: Enable CONFIG_IMX_TMU Next time, please put me on CC. Applied, thanks.
Re: [PATCH 0/5] imx93_var_som: Add USB support.
On Tue, Feb 20, 2024 at 7:35 AM Mathieu Othacehe wrote: > > Hello, > > This series adds USB support for the imx93_var_som board. It depends on: > https://lists.denx.de/pipermail/u-boot/2024-February/546203.html > > It also adds support for fastboot and EFI partitions. > > Thanks, > > Mathieu > > Mathieu Othacehe (5): > arm: dts: imx93: Add USB support. > arm: dts: imx93-var-som-symphony: Add USB support. > configs: imx93_var_som: Add USB support. > configs: imx93_var_som: Add fastboot support. > configs: imx93_var_som: Add EFI support. This last one did not apply against master. I checked and the two options are already enabled, so I dropped the patch 5/5 and applied the others, thanks.
Re: [PATCH] board: imx6dl-sielaff: spl.c: Remove multiline string
On Tue, Feb 20, 2024 at 6:01 AM Frieder Schrempf wrote: > > From: Frieder Schrempf > > Remove the malformed multiline string and fix the checkpatch warning. > > Reported-by: Dan Carpenter > Signed-off-by: Frieder Schrempf Applied, thanks.
Re: [PATCH v4 1/2] imx: imxrt1050-evk: Add support for SPI flash booting
On Tue, Feb 20, 2024 at 2:20 PM Fabio Estevam wrote: > Please fix both issues and submit a v5. I have fixed these issues myself and applied it, thanks.
Re: [PATCH v2 2/2] arm: dts: k3-am642-evm/sk: Enable OSPI support in SPL
Tom Rini writes:
> On Fri, Feb 23, 2024 at 06:17:02PM -0600, Jonathan Humphreys wrote:
>> Add bootph DT tags to enable OSPI in SPL.
>> Set OSPI regs for R5 SPL to address OSPI's boot region.
>>
>> Signed-off-by: Jonathan Humphreys
>> ---
>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 16
>> arch/arm/dts/k3-am642-r5-evm.dts | 5 +
>> arch/arm/dts/k3-am642-r5-sk.dts | 5 +
>> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 16
>> 4 files changed, 42 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> index b843078243..60b219c0be 100644
>> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> @@ -182,3 +182,19 @@
>> _port2 {
>> status = "disabled";
>> };
>> +
>> +_pins_default {
>> +bootph-all;
>> +};
>> +
>> + {
>> +bootph-all;
>> +};
>> +
>> + {
>> +bootph-all;
>> +
>> +flash@0 {
>> +bootph-all;
>> +};
>> +};
>
> So this gets back to what I was asking in the first series, is this
> needed in SPL or full U-Boot as well? The bootph-* properties are
> supposed to be transitive, but originally the tooling didn't handle this
> and now the tooling handles SPL but not full U-Boot. Which also brings
> back the is this _needed_ question and is bootph-all right, rather than
> just the big hammer?
>
By "this", are you referring to the original phypattern partition nodes,
or the ospi0 node itself? The partition nodes are not needed at all, so
removed. The ospi node is needed in both SPL and U-Boot. In that case,
using the bootph-all tag is the proper way, correct?
What do you mean by the 'big hammer'?
Please advise and thanks.
> --
> Tom
Re: [PATCH v2 2/2] arm: dts: k3-am642-evm/sk: Enable OSPI support in SPL
On Fri, Feb 23, 2024 at 06:17:02PM -0600, Jonathan Humphreys wrote:
> Add bootph DT tags to enable OSPI in SPL.
> Set OSPI regs for R5 SPL to address OSPI's boot region.
>
> Signed-off-by: Jonathan Humphreys
> ---
> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 16
> arch/arm/dts/k3-am642-r5-evm.dts | 5 +
> arch/arm/dts/k3-am642-r5-sk.dts | 5 +
> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 16
> 4 files changed, 42 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> index b843078243..60b219c0be 100644
> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
> @@ -182,3 +182,19 @@
> _port2 {
> status = "disabled";
> };
> +
> +_pins_default {
> + bootph-all;
> +};
> +
> + {
> + bootph-all;
> +};
> +
> + {
> + bootph-all;
> +
> + flash@0 {
> + bootph-all;
> + };
> +};
So this gets back to what I was asking in the first series, is this
needed in SPL or full U-Boot as well? The bootph-* properties are
supposed to be transitive, but originally the tooling didn't handle this
and now the tooling handles SPL but not full U-Boot. Which also brings
back the is this _needed_ question and is bootph-all right, rather than
just the big hammer?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] arm: separate .data and .text sections of EFI binaries
On 2/16/24 11:35, Ilias Apalodimas wrote:
Hi Heinrich,
[...]
}
+ .rela.dyn : { *(.rela.dyn) }
+ .rela.plt : { *(.rela.plt) }
+ .rela.got : { *(.rela.got) }
+ .rela.data : { *(.rela.data) *(.rela.data*) }
Why are we switching from Rel to Rela?
This was wrong.
Looking at the u-boot ELF binary we see these relocation sections:
arm: .rel.dyn
arm64: .rela.dyn
riscv64: .rela.dyn
In our EFI object files we currently have no relocations. This is why
tests did not complain.
In arch/arm/lib/reloc_arm_efi.c we handle DT_REL.
In arch/arm/lib/reloc_aarch64_efi.c we handle DT_RELA.
In arch/riscv/lib/reloc_riscv_efi.c we handle DT_RELA.
Best regards
Heinrich
_etext = .;
_text_size = . - _text;
- .dynamic : { *(.dynamic) }
+ . = ALIGN(4096);
.data : {
_data = .;
*(.sdata)
@@ -47,20 +59,19 @@ SECTIONS
. = ALIGN(512);
_bss_end = .;
_edata = .;
- }
- .rel.dyn : { *(.rel.dyn) }
- .rel.plt : { *(.rel.plt) }
- .rel.got : { *(.rel.got) }
- .rel.data : { *(.rel.data) *(.rel.data*) }
- _data_size = . - _etext;
+ } :data
+ _data_size = _edata - _data;
+ . = ALIGN(4096);
+ .dynsym : { *(.dynsym) }
+ . = ALIGN(4096);
+ .dynstr : { *(.dynstr) }
+ . = ALIGN(4096);
+ .note.gnu.build-id : { *(.note.gnu.build-id) }
/DISCARD/ : {
*(.rel.reloc)
*(.eh_frame)
*(.note.GNU-stack)
- *(.dynsym)
- *(.dynstr)
- *(.note.gnu.build-id)
- *(.comment)
}
+ .comment 0 : { *(.comment) }
}
--
2.43.0
Cheers
/Ilias
