Re: [ANN] U-Boot v2025.04-rc4 released
On 3/11/25 12:32 AM, Tom Rini wrote: Hey all, Hi, So it's release day and I have tagged and pushed things out. This will be merged to -next shortly. Continuing on with what I started after the -rc1 release, we had a call today and the link was https://calendar.google.com/calendar/event Maybe it would be good to inform people BEFORE the call rather than AFTER the call ? I would've actually liked to join ... [...]
Re: [ANN] U-Boot v2025.04-rc4 released
On Tue, Mar 11, 2025 at 01:44:03AM +0100, Marek Vasut wrote: > On 3/11/25 12:32 AM, Tom Rini wrote: > > Hey all, > > Hi, > > > So it's release day and I have tagged and pushed things out. This will > > be merged to -next shortly. > > > > Continuing on with what I started after the -rc1 release, we had a call > > today and the link was > > https://calendar.google.com/calendar/event > > Maybe it would be good to inform people BEFORE the call rather than AFTER > the call ? I would've actually liked to join ... Sigh. Yes, I edit the emails. Last release I messed up and didn't send the rc notice the right day. This release I got the day correct, but missed this part. I did not miss the part where I updated the meeting time to note it's tomorrow. They also continue to be the day after the release, Tuesdays. Sorry for the confusion. -- Tom signature.asc Description: PGP signature
Fwd: New Defects reported by Coverity Scan for Das U-Boot
Here's the latest report.
-- Forwarded message -
From:
Date: Mon, Mar 10, 2025 at 5:43 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To:
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot
found with Coverity Scan.
1 new defect(s) introduced to Das U-Boot found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 544194: Error handling issues (CHECKED_RETURN)
/lib/efi_loader/efi_net.c: 1084 in efi_net_set_dp()
*** CID 544194: Error handling issues (CHECKED_RETURN)
/lib/efi_loader/efi_net.c: 1084 in efi_net_set_dp()
1078// If netobj is not started yet, end here.
1079if (!netobj) {
1080goto exit;
1081}
1082
1083phandler = NULL;
>>> CID 544194: Error handling issues (CHECKED_RETURN)
>>> Calling "efi_search_protocol" without checking return value (as is
done elsewhere 39 out of 43 times).
1084efi_search_protocol(&netobj->header, &efi_guid_device_path,
&phandler);
1085
1086// If the device path protocol is not yet installed,
install it
1087if (!phandler)
1088goto add;
1089
- End forwarded message -
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 4/6] net: lwip: add support for built-in root certificates
On 3/10/25 13:38, Ilias Apalodimas wrote:
> On Mon, 10 Mar 2025 at 14:13, Jerome Forissier
> wrote:
>>
>>
>>
>> On 3/10/25 12:52, Ilias Apalodimas wrote:
>>> Hi Jerome,
>>>
>>> [...]
>>>
>>>
>>
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> + cacert_initialized = true;
>> +#endif
>> return CMD_RET_SUCCESS;
>> }
>> +
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> +static int set_cacert_builtin(void)
>> +{
>> + return _set_cacert(builtin_cacert, builtin_cacert_size);
>> +}
>> #endif
>>
>> +#if CONFIG_IS_ENABLED(WGET_CACERT)
>> +static int set_cacert(char * const saddr, char * const ssz)
>> +{
>> + ulong addr, sz;
>> +
>> + addr = hextoul(saddr, NULL);
>> + sz = hextoul(ssz, NULL);
>> +
>> + return _set_cacert((void *)addr, sz);
>> +}
>> +#endif
>> +#endif /* CONFIG_WGET_CACERT || CONFIG_WGET_BUILTIN_CACERT */
>> +
>> static int wget_loop(struct udevice *udev, ulong dst_addr, char *uri)
>> {
>> #if CONFIG_IS_ENABLED(WGET_HTTPS)
>> @@ -373,8 +401,15 @@ static int wget_loop(struct udevice *udev, ulong
>> dst_addr, char *uri)
>> memset(&conn, 0, sizeof(conn));
>> #if CONFIG_IS_ENABLED(WGET_HTTPS)
>> if (is_https) {
>> - char *ca = cacert;
>> - size_t ca_sz = cacert_size;
>> + char *ca;
>> + size_t ca_sz;
>> +
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> + if (!cacert_initialized)
>> + set_cacert_builtin();
>> +#endif
>
> The code and the rest of the patch seems fine, but the builtin vs
> downloaded cert is a bit confusing here.
> Since the built-in cert always gets initialized in the wget loop it
> would overwrite any certificates that are downloaded in memory?
The built-in certs are enabled only when cacert_initialized is false.
set_cacert_builtin() will set it to true (via _set_cacert()), so it will
happen only once. Note also that any successful "wget cacert" command
will also do the same. So effectively these two lines enable the
built-in certificates by default, that's all they do.
>>>
>>> Ok, so if you download a cert in memory and have u-boot with a builtin
>>> certificate, then the memory one will be overwritten in the first run.
>>
>> No, because the downloaded cert must have be made active via "wget cacert
>> ", which will set cacert_initialized to true, and thus the
>> built-in certs won't overwrite them. Or did I miss something?
>
> Nop I did, when reading the patch. But should the command that clears
> the downloaded cert set cacert_initialized; to false now?
It's probably easier if it does not, so that "wget cacert 0 0" really clears
the certs. We have a command to restore the built-in ones ("wget cacert
builtin").
Thanks,
--
Jerome
>
> Thanks
> /Ilias
>>
>> Cheers,
>> --
>> Jerome
>>
>>> This is not easy to solve, I was trying to think of ways to make the
>>> functionality clearer to users.
>>>
>>> Cheers
>>> /Ilias
Cheers,
--
Jerome
>
> [...]
>
> Cheers
> /Ilias
Re: [Uboot-stm32] [PATCH 1/5] dm: pwm: Check if duty_ns is lower than period_ns
On 3/10/25 15:12, Cheick TRAORE wrote: > > On 3/10/25 13:35, Patrice CHOTARD wrote: >> >> On 3/10/25 11:00, Patrice CHOTARD wrote: >>> >>> On 3/6/25 15:13, Patrice CHOTARD wrote: On 3/6/25 11:56, Cheick Traore wrote: > It was possible to provide a duty_ns greater than period_ns to > "pwm config" command. The framework must check the values before > providing them to drivers. > > Signed-off-by: Cheick Traore > --- > > drivers/pwm/pwm-uclass.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/pwm/pwm-uclass.c b/drivers/pwm/pwm-uclass.c > index 6543db1d623..b4491f7dcd4 100644 > --- a/drivers/pwm/pwm-uclass.c > +++ b/drivers/pwm/pwm-uclass.c > @@ -27,6 +27,9 @@ int pwm_set_config(struct udevice *dev, uint channel, > uint period_ns, > if (!ops->set_config) > return -ENOSYS; > + if (duty_ns > period_ns) > + return -EINVAL; > + > return ops->set_config(dev, channel, period_ns, duty_ns); > } > Reviewed-by: Patrice Chotard Thanks Patrice >>> Applied to u-boot-stm32/next >>> >>> Thanks >>> Patrice >> >> Hi Cheick >> >> Unfortunately, this patch is causing U-Boot CI test failed: >> seehttps://source.denx.de/u-boot/custodians/u-boot-stm/-/jobs/1054426 >> >> More precisely ut_dm_dm_test_cros_ec_pwm, see test/dm/cros_ec_pwm.c >> >> Either update test/dm/cros_ec_pwm.c or another solution is simply to >> clamp duty_ns to period_ns as following ? >> >> + if (duty_ns > period_ns) >> + duty_ns = period_ns; >> + >> >> Patrice >> >> >>> ___ >>> Uboot-stm32 mailing list >>> uboot-st...@st-md-mailman.stormreply.com >>> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32 > > Hi Patrice, > > It seems like this patch should finally be reverted. > > When the duty cycle exceeds the period, some drivers already clamp the value > of the duty cycle to the maximum value or do not apply the duty cycle. > > So, I will check the duty cycle in|drivers/pwm/pwm-stm32.c|and > return|-EINVAL|when it exceeds the period. > > Thanks, > > Cheick ok, i will remove your PWM series from the STM32_U-boot_custodian/next branch. Thanks Patrice >
Re: [PATCH v2 1/4] i2c: omap24xx_i2c: Remove unused CONFIG_I2C_REPEATED_START
Hello Aniket, On 10.03.25 11:36, Aniket Limaye wrote: Remove unused piece of code under CONFIG_I2C_REPEATED_START which does not have any Kconfig entry at all. Signed-off-by: Aniket Limaye --- drivers/i2c/omap24xx_i2c.c | 10 +- 1 file changed, 1 insertion(+), 9 deletions(-) Thanks! Reviewed-by: Heiko Schocher bye, Heiko -- -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v2 1/4] riscv: dt-binding: k1: Add reset driver binding definition.
Add dt-binding for reset driver. Signed-off-by: Huan Zhou --- include/dt-bindings/reset/spacemit-k1-reset.h | 118 ++ 1 file changed, 118 insertions(+) diff --git a/include/dt-bindings/reset/spacemit-k1-reset.h b/include/dt-bindings/reset/spacemit-k1-reset.h new file mode 100644 index ..74db58b27ef875aa2cfe99bd28ed959116b46536 --- /dev/null +++ b/include/dt-bindings/reset/spacemit-k1-reset.h @@ -0,0 +1,118 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2022 Spacemit Inc. + * Copyright (C) 2025 Huan Zhou + */ + +#ifndef __DT_BINDINGS_RESET_SAPCEMIT_K1_H__ +#define __DT_BINDINGS_RESET_SAPCEMIT_K1_H__ +/* APBC */ +#defineRESET_UART1 1 +#defineRESET_UART2 2 +#defineRESET_GPIO3 +#defineRESET_PWM04 +#defineRESET_PWM15 +#defineRESET_PWM26 +#defineRESET_PWM37 +#defineRESET_PWM48 +#defineRESET_PWM59 +#defineRESET_PWM610 +#defineRESET_PWM711 +#defineRESET_PWM812 +#defineRESET_PWM913 +#defineRESET_PWM10 14 +#defineRESET_PWM11 15 +#defineRESET_PWM12 16 +#defineRESET_PWM13 17 +#defineRESET_PWM14 18 +#defineRESET_PWM15 19 +#defineRESET_PWM16 20 +#defineRESET_PWM17 21 +#defineRESET_PWM18 22 +#defineRESET_PWM19 23 +#defineRESET_SSP324 +#defineRESET_UART3 25 +#defineRESET_RTC 26 +#defineRESET_TWSI0 27 +#defineRESET_TIMERS1 28 +#defineRESET_AIB 29 +#defineRESET_TIMERS2 30 +#defineRESET_ONEWIRE 31 +#defineRESET_SSPA0 32 +#defineRESET_SSPA1 33 +#defineRESET_DRO 34 +#defineRESET_IR 35 +#defineRESET_TWSI1 36 +#defineRESET_TSEN37 +#defineRESET_TWSI2 38 +#defineRESET_TWSI4 39 +#defineRESET_TWSI5 40 +#defineRESET_TWSI6 41 +#defineRESET_TWSI7 42 +#defineRESET_TWSI8 43 +#defineRESET_IPC_AP2AUD 44 +#defineRESET_UART4 45 +#defineRESET_UART5 46 +#defineRESET_UART6 47 +#defineRESET_UART7 48 +#defineRESET_UART8 49 +#defineRESET_UART9 50 +#defineRESET_CAN051 + +/* MPMU */ +#defineRESET_WDT 52 + +/* APMU */ +#defineRESET_JPG53 +#defineRESET_CSI54 +#defineRESET_CCIC2_PHY 55 +#defineRESET_CCIC3_PHY 56 +#defineRESET_ISP57 +#defineRESET_ISP_AHB58 +#defineRESET_ISP_CI 59 +#defineRESET_ISP_CPP60 +#defineRESET_LCD61 +#defineRESET_DSI_ESC62 +#defineRESET_V2D63 +#defineRESET_MIPI 64 +#defineRESET_LCD_SPI65 +#defineRESET_LCD_SPI_BUS 66 +#defineRESET_LCD_SPI_HBUS 67 +#defineRESET_LCD_MCLK 68 +#defineRESET_CCIC_4X 69 +#defineRESET_CCIC1_PHY70 +#defineRESET_SDH_AXI 71 +#defineRESET_SDH0 72 +#defineRESET_SDH1 73 +#defineRESET_USB_AXI 74 +#defineRESET_USBP1_AXI75 +#defineRESET_USB3_0 76 +#defineRESET_QSPI 77 +#defineRESET_QSPI_BUS 78 +#defineRESET_DMA 79 +#defineRESET_AES 80 +#defineRESET_VPU 81 +#defineRESET_GPU 82 +#defineRESET_SDH2 83 +#defineRESET_MC 84 +#defineRESET_EM_AXI 85 +#defineRESET_EM 86 +#defineRESET_AUDIO_SYS87 +#defineRESET_HDMI 88 +#defineRESET_PCIE089 +#defineRESET_PCIE190 +#defineRESET_PCIE291 +#defineRESET_EMAC092 +#defineRESET_EMAC193 + +/* APBC2 */ +#defineRESET_SEC_UART194 +#defineRESET_SEC_SSP2 95 +#defineRESET_SEC_TWSI396 +#defineRESET_SEC_RTC 97 +#defineRESET_SEC_TIMERS0 98 +#defineRESET_SEC_KPC 99 +#defineRESET_SEC_GPIO 100 +#defineRESET_NUMBER 101 + +#endif -- 2.39.5
Re: [PATCH v2 2/4] i2c: omap24xx_i2c: Use new function __omap24_i2c_xfer_msg()
Hello Aniket, On 10.03.25 11:36, Aniket Limaye wrote: Remove __omap24_i2c_read/write() usage from omap_i2c_xfer() in favour of the more flexible __omap24_i2c_xfer_msg(). Consequently, these are also no longer needed when DM_I2C is enabled. New function __omap24_i2c_xfer_msg() will take care of individual read OR write transfers with a target device. It goes through below sequence: - Program the provided Target Chip address (OMAP_I2C_SA_REG) - Program the provided Data len (OMAP_I2C_CNT_REG) - Program the provided Control register flags (OMAP_I2C_CON_REG) - Read from or Write to the provided Data buffer (OMAP_I2C_DATA_REG) For a detailed programming guide, refer to the TRM[0] (12.1.3.4 I2C Programming Guide). This patch by itself should be a transparent change. However this is needed for implementing a proper Repeated Start (Sr) functionality for i2c_msgs. Previous implementation for omap_i2c_xfer called __omap24_i2c_read/write functions, with hardcoded addr=0 and alen=0 for each i2c_msg. Each of these calls would program the registers always with a Stop bit set, not allowing for a repeated start between i2c_msgs in the same xfer(). [0]: https://www.ti.com/lit/zip/spruj28 (TRM) Signed-off-by: Aniket Limaye --- v2: - Use proper error codes in __omap24_i2c_xfer_msg() - Use proper error prints to indicate omap24xx i2c driver - Link to v1: https://lore.kernel.org/u-boot/20250304220546.866602-2-a-lim...@ti.com/ --- drivers/i2c/omap24xx_i2c.c | 143 +++-- 1 file changed, 123 insertions(+), 20 deletions(-) Thanks! Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v2 3/4] riscv: dts: k1: add reset controller node in device tree
Add reset-controller in k1 device tree.
Signed-off-by: Huan Zhou
---
arch/riscv/dts/k1.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/riscv/dts/k1.dtsi b/arch/riscv/dts/k1.dtsi
index
514be453dbaf6713cdf4ad5a5d653488297ebb83..b3e3f81d4dfa6e64dd4a00625280e43b014a6915
100644
--- a/arch/riscv/dts/k1.dtsi
+++ b/arch/riscv/dts/k1.dtsi
@@ -455,5 +455,20 @@
reg-io-width = <4>;
status = "reserved"; /* for TEE usage */
};
+
+ reset: reset-controller@d405 {
+ compatible = "spacemit,k1-reset";
+ reg = <0x0 0xd405 0x0 0x209c>,
+ <0x0 0xd4282800 0x0 0x400>,
+ <0x0 0xd4015000 0x0 0x1000>,
+ <0x0 0xd409 0x0 0x1000>,
+ <0x0 0xd4282c00 0x0 0x400>,
+ <0x0 0xd844 0x0 0x98>,
+ <0x0 0xc000 0x0 0x4280>,
+ <0x0 0xf061 0x0 0x20>;
+ reg-names = "mpmu", "apmu", "apbc", "apbs", "ciu",
"dciu", "ddrc", "apbc2";
+ #reset-cells = <1>;
+ status = "disabled";
+ };
};
};
\ No newline at end of file
--
2.39.5
[PATCH] imx8m: soc: cope with existing optee node
On i.MX8M SoCs, the /firmware/optee Devicetree node is created just before
booting the OS when OP-TEE is found running. If the node already exists,
this results in an error, which prevents the OS to boot:
Could not create optee node.
ERROR: system-specific fdt fixup failed: FDT_ERR_EXISTS
- must RESET the board to recover.
failed to process device tree
On the i.MX8M systems where CONFIG_OF_SYSTEM_SETUP is defined, the
ft_add_optee_node() function is called before booting the OS. It will
create the OP-TEE Devicetree node and populate it with reserved memory
informations gathered at runtime.
On on most i.MX8M systems the Devicetree is built with an optee node if
CONFIG_OPTEE is defined. This node is indeed necessary for commands and
drivers communicating with OP-TEE, even before attempting OS boot.
The aforementioned issue can happen on the Compulab IOT-GATE-iMX8, which is
the only in-tree i.MX8M system where both CONFIG_OPTEE and
CONFIG_OF_SYSTEM_SETUP are defined (see the imx8mm-cl-iot-gate*
defconfigs).
Deal with an existing optee node gracefully at runtime to fix this issue.
Signed-off-by: Vincent Stehlé
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Tom Rini
Cc: Tim Harvey
---
arch/arm/mach-imx/imx8m/soc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 85dc8b51a14..567e8e9e81a 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1270,8 +1270,9 @@ static int ft_add_optee_node(void *fdt, struct bd_info
*bd)
}
}
+ /* Locate the optee node if it exists or create it. */
subpath = "optee";
- offs = fdt_add_subnode(fdt, offs, subpath);
+ offs = fdt_find_or_add_subnode(fdt, offs, subpath);
if (offs < 0) {
printf("Could not create %s node.\n", subpath);
return offs;
--
2.47.2
Re: Merge of v2025.04-rc4 in to next
On Mon, Mar 10, 2025 at 05:46:51PM -0600, Tom Rini wrote: > Hey, > > Attempting to merge v2025.04-rc4 in to -next fails on two files. One of > which is common/miiphyutil.c and is easily solved (miiphy_init() goes > away) and then lib/efi_loader/efi_net.c. The latter I need help with, > ideally one of you, as you understand the code in question, sends me the > merged file off-list and I'll drop that in, or points me at a tree with > the merge done and I'll work it out from there. Thanks! After talking with Heinrich on IRC this is resolved. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 3/4] i2c: omap24xx_i2c: support CONFIG for repeated start in DM_I2C xfer
Hello Aniket, On 10.03.25 11:36, Aniket Limaye wrote: Repeated Start Condition (Sr) can be used to transfer multiple i2c msgs without sending a Stop condition (P). So far, the driver default was to always send a Stop condition after every i2c msg. Add support for a config option (CONFIG_SYS_I2C_OMAP24XX_REPEATED_START) to disable sending the Stop condition by default. If this config is enabled, Stop condition will be sent only if explicitly requested in the msg flags OR if it is the last msg in the transfer. Consequently, handle the Repeated Start condition (Sr) in the next msg by not calling the wait_for_bb() check since it will simply timeout in the absence of a stop condition (BB will be 1 until Stop is programmed) Signed-off-by: Aniket Limaye --- v2: - fixup code formatting and comment blocks - CONFIG_I2C_REPEATED_START -> CONFIG_SYS_I2C_OMAP24XX_REPEATED_START - Link to v1: https://lore.kernel.org/u-boot/20250304220546.866602-3-a-lim...@ti.com/ --- drivers/i2c/omap24xx_i2c.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) Thanks! Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH v2 2/4] riscv: reset: k1: Add reset driver
Add spacemit reset driver. Signed-off-by: Huan Zhou --- drivers/reset/Kconfig | 7 + drivers/reset/Makefile| 1 + drivers/reset/reset-spacemit-k1.c | 548 ++ 3 files changed, 556 insertions(+) diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index fe5c1214f57a8b4d6f21b3a765bff813712ae3ff..9ee14a74211a5f1c23a35473a41044f7f2ebe61a 100644 --- a/drivers/reset/Kconfig +++ b/drivers/reset/Kconfig @@ -235,4 +235,11 @@ config RESET_AT91 This enables the Reset Controller driver support for Microchip/Atmel SoCs. Mainly used to expose assert/deassert methods to other drivers that require it. + +config RESET_SPACEMIT_K1 + bool "Support for SPACEMIT's K1 Reset driver" + depends on DM_RESET + help + Support for SPACEMIT's K1 Reset system. Basic Assert/Deassert + is supported. endmenu diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index d99a78c9828b7f870acff8de75ebdcff59edc137..a69432bad2fb5980012e6fcc094a3ed669d9a378 100644 --- a/drivers/reset/Makefile +++ b/drivers/reset/Makefile @@ -33,3 +33,4 @@ obj-$(CONFIG_RESET_ZYNQMP) += reset-zynqmp.o obj-$(CONFIG_RESET_DRA7) += reset-dra7.o obj-$(CONFIG_RESET_AT91) += reset-at91.o obj-$(CONFIG_$(PHASE_)RESET_JH7110) += reset-jh7110.o +obj-$(CONFIG_RESET_SPACEMIT_K1) += reset-spacemit-k1.o \ No newline at end of file diff --git a/drivers/reset/reset-spacemit-k1.c b/drivers/reset/reset-spacemit-k1.c new file mode 100644 index ..613e002fc4f666c3312c57f9a28fc72add6461ca --- /dev/null +++ b/drivers/reset/reset-spacemit-k1.c @@ -0,0 +1,548 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2022 Spacemit Inc. + * Copyright (C) 2025 Huan Zhou + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* APBC register offset */ +#define APBC_UART1_CLK_RST 0x0 +#define APBC_UART2_CLK_RST 0x4 +#define APBC_GPIO_CLK_RST 0x8 +#define APBC_PWM0_CLK_RST 0xc +#define APBC_PWM1_CLK_RST 0x10 +#define APBC_PWM2_CLK_RST 0x14 +#define APBC_PWM3_CLK_RST 0x18 +#define APBC_TWSI8_CLK_RST 0x20 +#define APBC_UART3_CLK_RST 0x24 +#define APBC_RTC_CLK_RST0x28 +#define APBC_TWSI0_CLK_RST 0x2c +#define APBC_TWSI1_CLK_RST 0x30 +#define APBC_TIMERS1_CLK_RST0x34 +#define APBC_TWSI2_CLK_RST 0x38 +#define APBC_AIB_CLK_RST0x3c +#define APBC_TWSI4_CLK_RST 0x40 +#define APBC_TIMERS2_CLK_RST0x44 +#define APBC_ONEWIRE_CLK_RST0x48 +#define APBC_TWSI5_CLK_RST 0x4c +#define APBC_DRO_CLK_RST0x58 +#define APBC_IR_CLK_RST 0x5c +#define APBC_TWSI6_CLK_RST 0x60 +#define APBC_TWSI7_CLK_RST 0x68 +#define APBC_TSEN_CLK_RST 0x6c + +#define APBC_UART4_CLK_RST 0x70 +#define APBC_UART5_CLK_RST 0x74 +#define APBC_UART6_CLK_RST 0x78 +#define APBC_SSP3_CLK_RST 0x7c + +#define APBC_SSPA0_CLK_RST 0x80 +#define APBC_SSPA1_CLK_RST 0x84 + +#define APBC_IPC_AP2AUD_CLK_RST 0x90 +#define APBC_UART7_CLK_RST 0x94 +#define APBC_UART8_CLK_RST 0x98 +#define APBC_UART9_CLK_RST 0x9c + +#define APBC_CAN0_CLK_RST 0xa0 +#define APBC_PWM4_CLK_RST 0xa8 +#define APBC_PWM5_CLK_RST 0xac +#define APBC_PWM6_CLK_RST 0xb0 +#define APBC_PWM7_CLK_RST 0xb4 +#define APBC_PWM8_CLK_RST 0xb8 +#define APBC_PWM9_CLK_RST 0xbc +#define APBC_PWM10_CLK_RST 0xc0 +#define APBC_PWM11_CLK_RST 0xc4 +#define APBC_PWM12_CLK_RST 0xc8 +#define APBC_PWM13_CLK_RST 0xcc +#define APBC_PWM14_CLK_RST 0xd0 +#define APBC_PWM15_CLK_RST 0xd4 +#define APBC_PWM16_CLK_RST 0xd8 +#define APBC_PWM17_CLK_RST 0xdc +#define APBC_PWM18_CLK_RST 0xe0 +#define APBC_PWM19_CLK_RST 0xe4 +/* end of APBC register offset */ + +/* MPMU register offset */ +#define MPMU_WDTPCR 0x200 +/* end of MPMU register offset */ + +/* APMU register offset */ +#define APMU_JPG_CLK_RES_CTRL 0x20 +#define APMU_CSI_CCIC2_CLK_RES_CTRL 0x24 +#define APMU_ISP_CLK_RES_CTRL 0x38 +#define APMU_LCD_CLK_RES_CTRL1 0x44 +#define APMU_LCD_SPI_CLK_RES_CTRL 0x48 +#define APMU_LCD_CLK_RES_CTRL2 0x4c +#define APMU_CCIC_CLK_RES_CTRL 0x50 +#define APMU_SDH0_CLK_RES_CTRL 0x54 +#define APMU_SDH1_CLK_RES_CTRL 0x58 +#define APMU_USB_CLK_RES_CTRL 0x5c +#define APMU_QSPI_CLK_RES_CTRL 0x60 +#define APMU_USB_CLK_RES_CTRL 0x5c +#define APMU_DMA_CLK_RES_CTRL 0x64 +#define APMU_AES_CLK_RES_CTRL 0x68 +#define APMU_VPU_CLK_RES_CTRL 0xa4 +#define APMU_GPU_CLK_RES_CTRL 0xcc +#define APMU_SDH2_CLK_RES_CTRL 0xe0 +#define APMU_PMUA_MC_CTRL 0xe8 +#define APMU_PMU_CC2_AP 0x100 +#define APMU_PMUA_EM_CLK_RES_CTRL 0x104 + +#define APMU_AUDIO_CLK_RES_CTRL 0x14c +#define APMU_HDMI_CLK_RES_CTRL 0x1B8 + +#define APMU_PCIE_
[PATCH v2 0/4] Add k1 reset driver for bananapi-bpif3 platform.
Add device tree bindings and basic reset controller driver for the BananaPi F3 board.This initial implementation supports the core reset functionality. Changed in v2: - fixed checkpatch error/warning. - Links to v1: https://lore.kernel.org/u-boot/20250304-reset-k1-v1-0-dc9510ff1...@per1cycle.org/ Signed-off-by: Huan Zhou --- Huan Zhou (4): riscv: dt-binding: k1: Add reset driver binding definition. riscv: reset: k1: Add reset driver riscv: dts: k1: add reset controller node in device tree Add reset config options for k1 arch/riscv/cpu/k1/Kconfig | 1 + arch/riscv/dts/k1.dtsi| 15 + configs/bananapi-f3_defconfig | 1 + drivers/reset/Kconfig | 7 + drivers/reset/Makefile| 1 + drivers/reset/reset-spacemit-k1.c | 548 ++ include/dt-bindings/reset/spacemit-k1-reset.h | 118 ++ 7 files changed, 691 insertions(+) --- base-commit: cf6354ab23bfc3337b1087d243e6be4af48abe84 change-id: 20250308-reset-k1-773cd93f5337 Best regards, -- Huan Zhou
[PATCH v2] spi: cadence_ospi: Add device reset via OSPI controller
Add support for flash device reset via OSPI controller
instead of using GPIO, as OSPI IP has device reset
feature on Versal Gen2 platform. Also add compatible
string for Versal Gen2 platform.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Changes in v2:
- Fixed the compilation issue for phycore_am62ax_a53_defconfig.
---
drivers/spi/cadence_ospi_versal.c | 19 +++
drivers/spi/cadence_qspi.c| 9 +
drivers/spi/cadence_qspi.h| 3 +++
3 files changed, 31 insertions(+)
diff --git a/drivers/spi/cadence_ospi_versal.c
b/drivers/spi/cadence_ospi_versal.c
index 816916de16d..fbeb0c6a85c 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -204,3 +204,22 @@ void cadence_qspi_apb_enable_linear_mode(bool enable)
~VERSAL_OSPI_LINEAR_MODE, VERSAL_AXI_MUX_SEL);
}
}
+
+int cadence_device_reset(struct udevice *bus)
+{
+ struct cadence_spi_priv *priv = dev_get_priv(bus);
+ u32 reg;
+
+ reg = readl(priv->regbase + CQSPI_REG_CONFIG);
+ reg |= CQSPI_REG_CONFIG_RESET_CFG_FLD_MASK;
+ writel(reg, priv->regbase + CQSPI_REG_CONFIG);
+
+ writel(reg & ~CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK, priv->regbase +
CQSPI_REG_CONFIG);
+ udelay(5);
+ writel(reg | CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK, priv->regbase +
CQSPI_REG_CONFIG);
+ udelay(150);
+ writel(reg & ~CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK, priv->regbase +
CQSPI_REG_CONFIG);
+ udelay(1200);
+
+ return 0;
+}
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 623904ecdad..a78c00db4ff 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -33,6 +33,11 @@ __weak int cadence_qspi_apb_dma_read(struct cadence_spi_priv
*priv,
return 0;
}
+__weak int cadence_device_reset(struct udevice *dev)
+{
+ return 0;
+}
+
__weak int cadence_qspi_flash_reset(struct udevice *dev)
{
return 0;
@@ -251,6 +256,9 @@ static int cadence_spi_probe(struct udevice *bus)
priv->wr_delay = 50 * DIV_ROUND_UP(NSEC_PER_SEC, priv->ref_clk_hz);
+ if (device_is_compatible(bus, "amd,versal2-ospi"))
+ return cadence_device_reset(bus);
+
/* Reset ospi flash device */
return cadence_qspi_flash_reset(bus);
@@ -452,6 +460,7 @@ static const struct dm_spi_ops cadence_spi_ops = {
static const struct udevice_id cadence_spi_ids[] = {
{ .compatible = "cdns,qspi-nor" },
{ .compatible = "ti,am654-ospi" },
+ { .compatible = "amd,versal2-ospi" },
{ }
};
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 1f9125cd239..731b6527cf3 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -45,6 +45,8 @@
#define CQSPI_REG_CONFIG_CLK_POLBIT(1)
#define CQSPI_REG_CONFIG_CLK_PHABIT(2)
#define CQSPI_REG_CONFIG_PHY_ENABLE_MASKBIT(3)
+#define CQSPI_REG_CONFIG_RESET_PIN_FLD_MASKBIT(5)
+#define CQSPI_REG_CONFIG_RESET_CFG_FLD_MASKBIT(6)
#define CQSPI_REG_CONFIG_DIRECT BIT(7)
#define CQSPI_REG_CONFIG_DECODE BIT(9)
#define CQSPI_REG_CONFIG_ENBL_DMA BIT(15)
@@ -310,5 +312,6 @@ int cadence_qspi_apb_exec_flash_cmd(void *reg_base,
unsigned int reg);
int cadence_qspi_flash_reset(struct udevice *dev);
ofnode cadence_qspi_get_subnode(struct udevice *dev);
void cadence_qspi_apb_enable_linear_mode(bool enable);
+int cadence_device_reset(struct udevice *dev);
#endif /* __CADENCE_QSPI_H__ */
--
2.34.1
Re: [PATCH] cmd: version: Get information about GCC and LD back
On 3/6/25 15:12, Michal Simek wrote:
On 3/6/25 15:02, Tom Rini wrote:
On Thu, Mar 06, 2025 at 11:12:30AM +0100, Michal Simek wrote:
U-Boot version command is no longer showing information about GCC and LD.
The reason is that version.h has been removed that's why CC_VERSION_STRING
and LD_VERSION_STRING are not pass.
Values are generated to generated/version_autogenerated.h which is sourced
in version.h.
Fixes: 54ecce2cbf90 ("version: Separate our version string from the version
command")
Signed-off-by: Michal Simek
---
Tom: Not sure if this has been done on purpose or not but this issue has
been reported by our regression team.
It wasn't on purpose, no. Did you put this through CI / confirm
sandbox_nocmdline still builds?
Nope I did not.
CI is not reporting any issue.
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/25029
Thanks,
Michal
Re: [PATCH v6 6/6] blkmap: pass information on ISO image to the OS
On Sun, 9 Mar 2025 at 14:29, Ilias Apalodimas
wrote:
>
> HI Sughosh,
>
> [.,.]
>
> > +static int pmem_node_efi_memmap_setup(void *fdt, ulong addr, u32 size)
> > +{
> > + int ret;
> > + efi_status_t status;
> > +
> > + ret = fdt_fixup_pmem_region(fdt, addr, size);
>
> As we discussed offline, this will never get called if bootefi has run
> before the final OS image we want to load.
Yes, we currently have the logic where if a DT is installed on the
configuration table, the DT does not get installed afresh. Only thing
I was wondering was if this logic was put in place for some specific
use-case. We are now going to change the logic completely so it should
not be that it breaks some current assumption made in the code
somewhere. But then like Heinrich mentioned in the other thread, this
change was made in 6182495e101 ("efi_loader: need either ACPI table or
device tree"), which was authored by him. So if he is suggesting that
we install a DT afresh, it should be fine.
I already have the patches ready. Will post them once I have done the
required testing. Thanks.
-sughosh
> The reason is that U-Boot checks the installed config table and skips
> the installation. Earlier versions where applying the fixup on the
> config table for that reason.
> Since Heinrich and you agreed that the DT can unconditionally be
> re-installed, I think you should send a v7 including that patch.
>
> Cheers
> /Ilias
Re: [PATCH 1/2] usb: gadget: Remove final remnants of CONFIG_USB_DEVICE
Hi, On Thu, 27 Feb 2025 14:51:00 -0600, Tom Rini wrote: > The lone user of the legacy USB device framework have been removed for > some time. Remove the final parts of the code that were missed. > > Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-dfu (u-boot-dfu-next) [1/2] usb: gadget: Remove final remnants of CONFIG_USB_DEVICE https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/7f061aba9af99d2e911418939f0dbd5b79911a1e [2/2] usb: gadget: Remove the legacy usbtty driver https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/6689b0c955f1ec885ed1acafc7c5d7c1565dbe63 -- Mattijs
Re: [PATCH v2 1/6] net: lwip: extend wget to support CA (root) certificates
On 3/9/25 12:00, Ilias Apalodimas wrote: > On Sun, 9 Mar 2025 at 12:58, Ilias Apalodimas > wrote: >> >> Hi Jerome, Heinrich >> >> On Wed, 5 Mar 2025 at 17:13, Jerome Forissier >> wrote: >>> >>> Hi Heinrich, >>> >>> On 3/5/25 16:07, Heinrich Schuchardt wrote: On 05.03.25 15:26, Jerome Forissier wrote: > Add the "cacert" (Certification Authority certificates) subcommand to > wget to pass root certificates to the code handling the HTTPS protocol. > The subcommand is enabled by the WGET_CACERT Kconfig symbol. > > Usage example: > > => dhcp > # Download some root certificates (note: not authenticated!) > => wget https://cacerts.digicert.com/DigiCertTLSECCP384RootG5.crt > # Provide root certificates > => wget cacert $fileaddr $filesize > # Enforce verification (it is optional by default) > => wget cacert required > # Forget the root certificates > => wget cacert 0 0 > # Disable verification > => wget cacert none > > Signed-off-by: Jerome Forissier > --- > cmd/Kconfig | 8 > cmd/net-lwip.c | 17 ++-- > net/lwip/wget.c | 102 ++-- > 3 files changed, 121 insertions(+), 6 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index 8dd42571abc..d469217c0ea 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -2177,6 +2177,14 @@ config WGET_HTTPS > help > Enable TLS over http for wget. > > +config WGET_CACERT > +bool "wget cacert" > +depends on CMD_WGET > +depends on WGET_HTTPS > +help > + Adds the "cacert" sub-command to wget to provide root certificates > + to the HTTPS engine. Must be in DER format. > + Shouldn't we build CA certs into U-Boot? Downloading certs from unsafe media is not a good replacement. >>> >>> That's the purpose of patch 4/6 [1]. Although downloading may still be a >>> valid option when used with hash verification as I mentioned in a reply to >>> Ilias in v1 [2]. >>> >> >> FWIW I think this still makes sense for peopke that don't want or can >> not add the cert in the u-boot binary, but can add a signed script to >> download it on the fly >> >> Reviewed-by: Ilias Apalodimas > > This still stands, but there are a few warning/errors on the entire > patchset. Can you address them and send a v3? Which warnings/errors? Which config? I see none with qemu_arm64_lwip_defconfig. Thanks, -- Jerome > > Thanks > /Ilias
Re: [PATCH] xilinx: versal: add firmware access to PMC multi Boot mode register
On 3/5/25 14:48, Prasad Kummari wrote:
Added extended support for retrieving the PMC muti boot mode
register via the firmware interface, which is preferred when
U-Boot runs in EL2 and cannot directly access PMC registers
via raw reads. Ideally, all secure registers should be accessed
via xilinx_pm_request(). Introduced the secure
zynqmp_pm_get_pmc_multi_boot_reg() call, which uses
xilinx_pm_request() to read the PMC multi boot mode register.
BootROM increments the MultiBoot register (PMC_MULTI_BOOT) read
address offset by 32 KB and retries. For SD and eMMC boot modes,
it can search up to 8191 FAT files for the identification string.
A 13-bit mask (0x1FFF) is applied to PMC_MULTI_BOOT_MASK to obtain
the correct values in BootROM.
Signed-off-by: Prasad Kummari
---
arch/arm/mach-versal/include/mach/hardware.h | 2 ++
board/xilinx/versal/board.c | 8 ++-
drivers/firmware/firmware-zynqmp.c | 23
include/zynqmp_firmware.h| 4
4 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-versal/include/mach/hardware.h
b/arch/arm/mach-versal/include/mach/hardware.h
index 9d1c2f0dcfc..b5f80a8e3a9 100644
--- a/arch/arm/mach-versal/include/mach/hardware.h
+++ b/arch/arm/mach-versal/include/mach/hardware.h
@@ -87,6 +87,8 @@ struct crp_regs {
#define JTAG_MODE 0x
#define BOOT_MODE_USE_ALT 0x100
#define BOOT_MODE_ALT_SHIFT 12
+#define PMC_MULTI_BOOT_REG 0xF1110004
+#define PMC_MULTI_BOOT_MASK0x1FFF
#define FLASH_RESET_GPIO 0xc
#define WPROT_CRP 0xF126001C
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 3046fd7e5f0..6c4a2f5ead6 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -60,12 +60,18 @@ static u8 versal_get_bootmode(void)
static u32 versal_multi_boot(void)
{
u8 bootmode = versal_get_bootmode();
+ u32 reg = 0;
/* Mostly workaround for QEMU CI pipeline */
if (bootmode == JTAG_MODE)
return 0;
- return readl(0xF1110004);
+ if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE) && current_el() != 3)
+ reg = zynqmp_pm_get_pmc_multi_boot_reg();
+ else
+ reg = readl(PMC_MULTI_BOOT_REG);
+
+ return reg & PMC_MULTI_BOOT_MASK;
}
int board_init(void)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 2adc132b4cc..584397ba29a 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -218,6 +218,29 @@ u32 zynqmp_pm_get_bootmode_reg(void)
return ret_payload[1];
}
+u32 zynqmp_pm_get_pmc_multi_boot_reg(void)
+{
+ int ret;
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+
+ ret = zynqmp_pm_is_function_supported(PM_IOCTL, IOCTL_READ_REG);
+ if (ret) {
+ printf("%s: IOCTL_READ_REG is not supported failed with error code:
%d\n"
+ , __func__, ret);
+ return 0;
+ }
+
+ ret = xilinx_pm_request(PM_IOCTL, PM_REG_PMC_GLOBAL_NODE,
IOCTL_READ_REG,
+ PMC_MULTI_BOOT_MODE_REG_OFFSET, 0, ret_payload);
+ if (ret) {
+ printf("%s: node 0x%x: get_bootmode 0x%x failed\n",
+ __func__, PM_REG_PMC_GLOBAL_NODE,
PMC_MULTI_BOOT_MODE_REG_OFFSET);
+ return 0;
+ }
+
+ return ret_payload[1];
+}
+
int zynqmp_pm_feature(const u32 api_id)
{
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index e7275f72fac..5474f66078c 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -458,6 +458,7 @@ int zynqmp_mmio_read(const u32 address, u32 *value);
int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
int zynqmp_pm_feature(const u32 api_id);
u32 zynqmp_pm_get_bootmode_reg(void);
+u32 zynqmp_pm_get_pmc_multi_boot_reg(void);
/* Type of Config Object */
#define PM_CONFIG_OBJECT_TYPE_BASE0x1U
@@ -504,4 +505,7 @@ struct zynqmp_ipi_msg {
#define CRP_BOOT_MODE_REG_NODE0x3001
#define CRP_BOOT_MODE_REG_OFFSET 0x200
+#define PM_REG_PMC_GLOBAL_NODE 0x3004
+#define PMC_MULTI_BOOT_MODE_REG_OFFSET 0x4
+
#endif /* _ZYNQMP_FIRMWARE_H_ */
Applied.
M
Re: [PATCH v2 4/6] net: lwip: add support for built-in root certificates
Hi Ilias,
On 3/9/25 12:33, Ilias Apalodimas wrote:
> Hi Jerome
>
> On Wed, 5 Mar 2025 at 16:27, Jerome Forissier
> wrote:
>>
>
> [...]
>
>> @@ -304,28 +304,34 @@ static int set_auth(enum auth_mode auth)
>>
>> return CMD_RET_SUCCESS;
>> }
>> +#endif
>>
>> -static int set_cacert(char * const saddr, char * const ssz)
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> +extern const char builtin_cacert[];
>> +extern const size_t builtin_cacert_size;
>> +static bool cacert_initialized;
>> +#endif
>
> These are better off under WGET_CACERT || WGET_BUILTIN_CACERT ?
No, because one can build with BUILTIN_CACERT=y and CACERT=n (the latter is for
the "wget cacert" command, which is not mandatory for built-in certs).
>
>> +
>> +#if CONFIG_IS_ENABLED(WGET_CACERT) || CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> +static int _set_cacert(const void *addr, size_t sz)
>> {
>> mbedtls_x509_crt crt;
>> - ulong addr, sz;
>> + void *p;
>> int ret;
>>
>> if (cacert)
>> free(cacert);
>>
>> - addr = hextoul(saddr, NULL);
>> - sz = hextoul(ssz, NULL);
>> -
>> if (!addr) {
>> cacert = NULL;
>> cacert_size = 0;
>> return CMD_RET_SUCCESS;
>> }
>>
>> - cacert = malloc(sz);
>> - if (!cacert)
>> + p = malloc(sz);
>> + if (!p)
>> return CMD_RET_FAILURE;
>> + cacert = p;
>> cacert_size = sz;
>>
>> memcpy(cacert, (void *)addr, sz);
>> @@ -340,10 +346,32 @@ static int set_cacert(char * const saddr, char * const
>> ssz)
>> return CMD_RET_FAILURE;
>> }
>>
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> + cacert_initialized = true;
>> +#endif
>> return CMD_RET_SUCCESS;
>> }
>> +
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> +static int set_cacert_builtin(void)
>> +{
>> + return _set_cacert(builtin_cacert, builtin_cacert_size);
>> +}
>> #endif
>>
>> +#if CONFIG_IS_ENABLED(WGET_CACERT)
>> +static int set_cacert(char * const saddr, char * const ssz)
>> +{
>> + ulong addr, sz;
>> +
>> + addr = hextoul(saddr, NULL);
>> + sz = hextoul(ssz, NULL);
>> +
>> + return _set_cacert((void *)addr, sz);
>> +}
>> +#endif
>> +#endif /* CONFIG_WGET_CACERT || CONFIG_WGET_BUILTIN_CACERT */
>> +
>> static int wget_loop(struct udevice *udev, ulong dst_addr, char *uri)
>> {
>> #if CONFIG_IS_ENABLED(WGET_HTTPS)
>> @@ -373,8 +401,15 @@ static int wget_loop(struct udevice *udev, ulong
>> dst_addr, char *uri)
>> memset(&conn, 0, sizeof(conn));
>> #if CONFIG_IS_ENABLED(WGET_HTTPS)
>> if (is_https) {
>> - char *ca = cacert;
>> - size_t ca_sz = cacert_size;
>> + char *ca;
>> + size_t ca_sz;
>> +
>> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
>> + if (!cacert_initialized)
>> + set_cacert_builtin();
>> +#endif
>
> The code and the rest of the patch seems fine, but the builtin vs
> downloaded cert is a bit confusing here.
> Since the built-in cert always gets initialized in the wget loop it
> would overwrite any certificates that are downloaded in memory?
The built-in certs are enabled only when cacert_initialized is false.
set_cacert_builtin() will set it to true (via _set_cacert()), so it will
happen only once. Note also that any successful "wget cacert" command
will also do the same. So effectively these two lines enable the
built-in certificates by default, that's all they do.
Cheers,
--
Jerome
>
> [...]
>
> Cheers
> /Ilias
[RESEND PATCH 2/3] emulation: qemu-sbsa: Select SYS_PCI_64BIT
qemu's sbsa-ref is always using a 64bit CPU and the PCI prefetch MMIO window is located above 4GiB, thus always enable SYS_PCI_64BIT. Signed-off-by: Patrick Rudolph --- board/emulation/qemu-sbsa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/emulation/qemu-sbsa/Kconfig b/board/emulation/qemu-sbsa/Kconfig index 72c76b351fa..f4ad63e681c 100644 --- a/board/emulation/qemu-sbsa/Kconfig +++ b/board/emulation/qemu-sbsa/Kconfig @@ -33,6 +33,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy select OF_SEPARATE select PCI select PCIE_ECAM_GENERIC + select SYS_PCI_64BIT select USB select GIC_V3 select GIC_V3_ITS -- 2.48.1
[PATCH v2 3/4] i2c: omap24xx_i2c: support CONFIG for repeated start in DM_I2C xfer
Repeated Start Condition (Sr) can be used to transfer multiple i2c msgs
without sending a Stop condition (P). So far, the driver default was to
always send a Stop condition after every i2c msg.
Add support for a config option (CONFIG_SYS_I2C_OMAP24XX_REPEATED_START)
to disable sending the Stop condition by default. If this config is
enabled, Stop condition will be sent only if explicitly requested in the
msg flags OR if it is the last msg in the transfer.
Consequently, handle the Repeated Start condition (Sr) in the next msg
by not calling the wait_for_bb() check since it will simply timeout in
the absence of a stop condition (BB will be 1 until Stop is programmed)
Signed-off-by: Aniket Limaye
---
v2:
- fixup code formatting and comment blocks
- CONFIG_I2C_REPEATED_START -> CONFIG_SYS_I2C_OMAP24XX_REPEATED_START
- Link to v1:
https://lore.kernel.org/u-boot/20250304220546.866602-3-a-lim...@ti.com/
---
drivers/i2c/omap24xx_i2c.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index 7c5d786e8e9..ad739b123e5 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -1066,18 +1066,28 @@ static int omap_i2c_xfer(struct udevice *bus, struct
i2c_msg *msg, int nmsgs)
u16 i2c_con_reg = 0;
debug("%s: %d messages\n", __func__, nmsgs);
- for (; nmsgs > 0; nmsgs--, msg++) {
- /* Wait until bus not busy */
- if (wait_for_bb(priv->regs, priv->ip_rev, priv->waitdelay))
- return -EREMOTEIO;
+ for (int i = 0; i < nmsgs; i++, msg++) {
+ /*
+* If previous msg sent a Stop or if this is the first msg
+* Wait until bus not busy
+*/
+ if ((i2c_con_reg & I2C_CON_STP) || (i == 0))
+ if (wait_for_bb(priv->regs, priv->ip_rev,
priv->waitdelay))
+ return -EREMOTEIO;
- /* Set Controller mode with Start and Stop bit */
- i2c_con_reg = I2C_CON_EN | I2C_CON_MST | I2C_CON_STT |
I2C_CON_STP;
+ /* Set Controller mode with Start bit */
+ i2c_con_reg = I2C_CON_EN | I2C_CON_MST | I2C_CON_STT;
/* Set Transmitter/Receiver mode if it is a write/read msg */
if (msg->flags & I2C_M_RD)
i2c_con_reg &= ~I2C_CON_TRX;
else
i2c_con_reg |= I2C_CON_TRX;
+ /* Send Stop condition (P) by default */
+ if (!IS_ENABLED(CONFIG_SYS_I2C_OMAP24XX_REPEATED_START))
+ i2c_con_reg |= I2C_CON_STP;
+ /* Send Stop if explicitly requested or if this is the last msg
*/
+ if ((msg->flags & I2C_M_STOP) || (i == nmsgs - 1))
+ i2c_con_reg |= I2C_CON_STP;
debug("%s: chip=0x%x, len=0x%x, i2c_con_reg=0x%x\n",
__func__, msg->addr, msg->len, i2c_con_reg);
--
2.48.1
[PATCH v2 1/4] i2c: omap24xx_i2c: Remove unused CONFIG_I2C_REPEATED_START
Remove unused piece of code under CONFIG_I2C_REPEATED_START which does
not have any Kconfig entry at all.
Signed-off-by: Aniket Limaye
---
drivers/i2c/omap24xx_i2c.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index ebe472e20cd..1fd5f5cc224 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -538,9 +538,7 @@ pr_exit:
/*
* i2c_read: Function now uses a single I2C read transaction with bulk transfer
* of the requested number of bytes (note that the 'i2c md' command
- * limits this to 16 bytes anyway). If CONFIG_I2C_REPEATED_START is
- * defined in the board config header, this transaction shall be with
- * Repeated Start (Sr) between the address and data phases; otherwise
+ * limits this to 16 bytes anyway).
* Stop-Start (P-S) shall be used (some I2C chips do require a P-S).
* The address (reg offset) may be 0, 1 or 2 bytes long.
* Function now reads correctly from chips that return more than one
@@ -608,16 +606,10 @@ static int __omap24_i2c_read(void __iomem *i2c_base, int
ip_rev, int waitdelay,
if (alen) {
/* Must write reg offset first */
-#ifdef CONFIG_I2C_REPEATED_START
- /* No stop bit, use Repeated Start (Sr) */
- omap_i2c_write_reg(i2c_base, ip_rev, I2C_CON_EN | I2C_CON_MST |
- I2C_CON_STT | I2C_CON_TRX, OMAP_I2C_CON_REG);
-#else
/* Stop - Start (P-S) */
omap_i2c_write_reg(i2c_base, ip_rev, I2C_CON_EN | I2C_CON_MST |
I2C_CON_STT | I2C_CON_STP | I2C_CON_TRX,
OMAP_I2C_CON_REG);
-#endif
/* Send register offset */
while (1) {
status = wait_for_event(i2c_base, ip_rev, waitdelay);
--
2.48.1
[PATCH v7 3/8] fdt: add support for adding pmem nodes
From: Masahisa Kojima
One of the problems OS installers face, when running in EFI, is that
the mounted ISO after calling ExitBootServices goes away. For some
distros this is a problem since they rely on finding some core packages
before continuing the installation. Distros have works around this --
e.g Fedora has a special kernel command line parameter called
inst.stage2 [0].
ACPI has NFIT and NVDIMM support to provide ramdisks to the OS, but we
don't have anything in place for DTs. Linux and device trees have support
for persistent memory devices. So add a function that can inject a pmem
node in a DT, so we can use it when launhing OS installers with EFI.
[0]
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/installation_guide/chap-anaconda-boot-options#sect-boot-options-installer
Signed-off-by: Masahisa Kojima
Signed-off-by: Sughosh Ganu
---
Changes since V6: None
boot/fdt_support.c| 41 -
include/fdt_support.h | 14 ++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 49efeec3681..e20b9759138 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -464,7 +465,6 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
do_fixup_by_compat(fdt, compat, prop, &tmp, 4, create);
}
-#ifdef CONFIG_ARCH_FIXUP_FDT_MEMORY
/*
* fdt_pack_reg - pack address and size array into the "reg"-suitable stream
*/
@@ -493,6 +493,7 @@ static int fdt_pack_reg(const void *fdt, void *buf, u64
*address, u64 *size,
return p - (char *)buf;
}
+#ifdef CONFIG_ARCH_FIXUP_FDT_MEMORY
#if CONFIG_NR_DRAM_BANKS > 4
#define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
#else
@@ -,3 +2223,41 @@ int fdt_valid(struct fdt_header **blobp)
}
return 1;
}
+
+int fdt_fixup_pmem_region(void *blob, ulong addr, u32 size)
+{
+ u64 pmem_start[2] = { 0 };
+ u64 pmem_size[2] = { 0 };
+ char pmem_node[32] = {0};
+ int nodeoffset, len;
+ int err;
+ u8 tmp[4 * 16]; /* Up to 64-bit address + 64-bit size */
+
+ if (!IS_ALIGNED(addr, SZ_2M) || !IS_ALIGNED(addr + size, SZ_2M)) {
+ printf("Start and end address must be 2MiB aligned\n");
+ return -1;
+ }
+
+ snprintf(pmem_node, sizeof(pmem_node), "pmem@%lx", addr);
+ nodeoffset = fdt_find_or_add_subnode(blob, 0, pmem_node);
+ if (nodeoffset < 0)
+ return nodeoffset;
+
+ err = fdt_setprop_string(blob, nodeoffset, "compatible", "pmem-region");
+ if (err)
+ return err;
+ err = fdt_setprop_empty(blob, nodeoffset, "volatile");
+ if (err)
+ return err;
+ pmem_start[0] = addr;
+ pmem_size[0] = size;
+ len = fdt_pack_reg(blob, tmp, pmem_start, pmem_size, 1);
+ err = fdt_setprop(blob, nodeoffset, "reg", tmp, len);
+ if (err < 0) {
+ printf("WARNING: could not set pmem %s %s.\n", "reg",
+ fdt_strerror(err));
+ return err;
+ }
+
+ return 0;
+}
diff --git a/include/fdt_support.h b/include/fdt_support.h
index f0ad2e6b365..b72cd2920de 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -507,4 +507,18 @@ void fdt_fixup_pstore(void *blob);
*/
int fdt_kaslrseed(void *blob, bool overwrite);
+/**
+ * fdt_fixup_pmem_region() - add a pmem node on the device tree
+ *
+ * This functions adds/updates a pmem node to the device tree.
+ * Usually used with EFI installers to preserve installer
+ * images
+ *
+ * @blob: device tree provided by caller
+ * @addr: start address of the pmem node
+ * @size: size of the memory of the pmem node
+ * Return: 0 on success or < 0 on failure
+ */
+int fdt_fixup_pmem_region(void *blob, ulong addr, u32 size);
+
#endif /* ifndef __FDT_SUPPORT_H */
--
2.34.1
[PATCH v7 0/8] Add pmem node for preserving distro ISO's
When installing a distro via EFI HTTP boot some OS installers expect the .iso image to be preserved and treat it as a "CDROM" to install packages. This is problematic in EFI, since U-Boot mounts the image, starts the installer, and eventually calls ExitBootServices. At that point the image U-Boot mounted disappears. Some distros don't care and download the missing packages from a web archive, while others halt the installation complaining they can't find certain packages. If the firmware uses ACPI, this is supported by using NFIT which provides NVDIMM ramdisks to the OS and preserves the image. We don't have anything in place for Device Trees though. Since DT supports persistent memory nodes (pmem) use those and preserve the .iso for installers. The issue can be reproduced by attempting an EFI HTTP boot with Ubuntu live server ISO, or a Rocky Linux ISO. The installation would fail with the failure to locate certain packages. The patches are adding support for adding the pmem node to the DT that is being passed to the OS, along with removing the memory region containing the ISO image from the EFI memory map. This is being done through a helper function in the blkmap driver which scans for all blkmap mappings and does the above configurations for the relevant mappings. This version of the patchset is adding two patches to the front of the series, which re-install a device-tree(DT) on the EFI configuration table afresh on every invocation of efi_install_fdt(). This fixes the issue of a stale DT being passed on to a OS in the scenario where the DT was already installed on the configuration table. Changes since V6: * Clean-up the copy_fdt() function in efi_helper.c - patch 1 * Re-install a new DT on every invocation of efi_install_fdt() - patch 2 Ilias Apalodimas (2): efi_loader: add a function to remove memory from the EFI map efi_loader: preserve installer images in pmem Masahisa Kojima (1): fdt: add support for adding pmem nodes Sughosh Ganu (5): efi_loader: remove unused code from copy_fdt() efi_loader: install device-tree on configuration table on every invocation blkmap: store type of blkmap slice in corresponding structure blkmap: add an attribute to preserve the mem mapping blkmap: pass information on ISO image to the OS boot/fdt_support.c| 41 - boot/image-fdt.c | 7 +++ cmd/blkmap.c | 9 +++- drivers/block/blkmap.c| 65 +-- drivers/block/blkmap_helper.c | 2 +- include/blkmap.h | 21 - include/efi.h | 13 ++ include/efi_loader.h | 18 include/fdt_support.h | 14 ++ lib/efi_loader/efi_bootmgr.c | 22 +++--- lib/efi_loader/efi_helper.c | 83 +++ lib/efi_loader/efi_memory.c | 56 --- 12 files changed, 302 insertions(+), 49 deletions(-) -- 2.34.1
[PATCH v7 8/8] blkmap: pass information on ISO image to the OS
The EFI HTTP boot puts the ISO installer image at some location in
memory. Information about this image has to be passed on to the OS
kernel, which is done by adding a persistent memory(pmem) node to the
devicetree(DT) that is passed to the OS. The OS kernel then gets
information about the presence of this ISO image and proceeds with the
installation.
In U-Boot, this ISO image gets mounted as a memory mapped blkmap
device slice, with the 'preserve' attribute. Add a helper function
which iterates through all such slices, and invokes a callback. The
callback adds the pmem node to the DT and removes the corresponding
memory region from the EFI memory map. Invoke this helper function as
part of the DT fixup which happens before booting the OS.
Signed-off-by: Sughosh Ganu
Reviewed-by: Tobias Waldekranz
---
Changes since V6: None
boot/image-fdt.c| 7 ++
drivers/block/blkmap.c | 45 +
include/blkmap.h| 17 ++
include/efi.h | 13 +++
lib/efi_loader/efi_helper.c | 40 +
5 files changed, 122 insertions(+)
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index 9d1598b1a93..8f718ad29f6 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -649,6 +650,12 @@ int image_setup_libfdt(struct bootm_headers *images, void
*blob, bool lmb)
if (!ft_verify_fdt(blob))
goto err;
+ if (CONFIG_IS_ENABLED(BLKMAP) && CONFIG_IS_ENABLED(EFI_LOADER)) {
+ fdt_ret = fdt_efi_pmem_setup(blob);
+ if (fdt_ret)
+ goto err;
+ }
+
/* after here we are using a livetree */
if (!of_live_active() && CONFIG_IS_ENABLED(EVENT)) {
struct event_ft_fixup fixup;
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index eefed615998..1a633c71d43 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -498,6 +498,51 @@ err:
return err;
}
+static bool blkmap_mem_preserve_slice(struct blkmap_slice *bms)
+{
+ return (bms->attr & (BLKMAP_SLICE_MEM | BLKMAP_SLICE_PRESERVE)) ==
+ (BLKMAP_SLICE_MEM | BLKMAP_SLICE_PRESERVE);
+}
+
+int blkmap_get_preserved_pmem_slice(int (*cb)(void *ctx, ulong addr,
+ u32 size), void *ctx)
+{
+ int ret;
+ u32 size;
+ ulong addr;
+ struct udevice *dev;
+ struct uclass *uc;
+ struct blkmap *bm;
+ struct blkmap_mem *bmm;
+ struct blkmap_slice *bms;
+ struct blk_desc *bd;
+
+ if (!cb) {
+ log_debug("%s: No callback passed to the function\n", __func__);
+ return 0;
+ }
+
+ uclass_id_foreach_dev(UCLASS_BLKMAP, dev, uc) {
+ bm = dev_get_plat(dev);
+ bd = dev_get_uclass_plat(bm->blk);
+
+ list_for_each_entry(bms, &bm->slices, node) {
+ if (!blkmap_mem_preserve_slice(bms))
+ continue;
+
+ bmm = container_of(bms, struct blkmap_mem, slice);
+ addr = (ulong)(uintptr_t)bmm->addr;
+ size = (u32)bms->blkcnt << bd->log2blksz;
+ ret = cb(ctx, addr, size);
+ if (ret)
+ return ret;
+ }
+ }
+
+ return 0;
+
+}
+
int blkmap_destroy(struct udevice *dev)
{
int err;
diff --git a/include/blkmap.h b/include/blkmap.h
index 754d8671b01..30ce80c0ad1 100644
--- a/include/blkmap.h
+++ b/include/blkmap.h
@@ -7,6 +7,7 @@
#ifndef _BLKMAP_H
#define _BLKMAP_H
+#include
#include
/**
@@ -104,4 +105,20 @@ int blkmap_destroy(struct udevice *dev);
int blkmap_create_ramdisk(const char *label, ulong image_addr, ulong
image_size,
struct udevice **devp);
+/**
+ * blkmap_get_preserved_pmem_slice() - Look for memory mapped preserved slice
+ * @cb: Callback function to call for the blkmap slice
+ * @ctx: Argument to be passed to the callback function
+ *
+ * The function is used to iterate through all the blkmap slices, looking
+ * specifically for memory mapped blkmap mapping which has been
+ * created with the preserve attribute. The function looks for such slices
+ * with the relevant attributes and then calls the callback function which
+ * then does additional configuration as needed.
+ *
+ * Return: 0 on success, negative error on failure
+ */
+int blkmap_get_preserved_pmem_slice(int (*cb)(void *ctx, ulong addr,
+ u32 size), void *ctx);
+
#endif /* _BLKMAP_H */
diff --git a/include/efi.h b/include/efi.h
index d005cb6181e..f9bbb175c3a 100644
--- a/include/efi.h
+++ b/include/efi.h
@@ -705,4 +705,17 @@ static inline bool efi_use_host_arch(void)
*/
int efi_get_pxe_arch(void);
+/**
+
[ANN] U-Boot v2025.04-rc4 released
Hey all, So it's release day and I have tagged and pushed things out. This will be merged to -next shortly. Continuing on with what I started after the -rc1 release, we had a call today and the link was https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N280N2tlcXE3aDVtbjlicnNkcm82YnA1bDAgODliZTdiODEzMTM2YmVjMDZhODNkZTRkYTU5NzQ1ZjBhYmQxMWMxYjgzNjA2MWFlMDZjMWM3ZGJjZDE4ZGY0MUBn&tmsrc=89be7b813136bec06a83de4da59745f0abd11c1b836061ae06c1c7dbcd18df41%40group.calendar.google.com and once again this is the same time as the previous meeting. The meeting details itself are: https://meet.google.com/btj-wgcg-euw March 11th, 2025. 9am (GMT -06:00) To join by phone: https://meet.google.com/tel/btj-wgcg-euw?pin=1307528552322&hs=1 Repeating what I said on the -rc3 release, I've been looking in to seeing how we could get modern project governance setup and some umbrella organization to handle financial matters, etc. To that end, I've been talking with the Software Freedom Conservancy (https://sfconservancy.org/) and they'll be on the call tomorrow as well to answer any questions people have. In terms of a changelog, git log --merges v2025.04-rc3..v2025.04-rc4 As always, more details in pull requests (or the tags referenced by them) will result in more details here. I plan to have one more rc after this and then the final release will be 07 April 2025. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/12] test_fs: Add exfat tests
On 3/10/25 10:37 PM, Tom Rini wrote: On Mon, Mar 10, 2025 at 09:37:36PM +0100, Marek Vasut wrote: On 3/10/25 4:30 PM, Tom Rini wrote: On Sat, Mar 08, 2025 at 09:12:16PM +0100, Marek Vasut wrote: Add tests for the exfat filesystem. These tests are largely an extension of the FS_GENERIC tests with the following notable exceptions. The filesystem image for exfat tests is generated using combination of exfatutils mkfs.exfat and python fattools. The fattols are capable Did you mean "exfatprogs" and not "exfatutils" ? But we need to update tools/docker/Dockerfile to list the tool there. It seems the CI container already has the tools in it ? Implicitly and not explicitly then. Where do I update the docker container, is that tools/docker/Dockerfile ? Yes, thanks. Added in V2, thanks. of generating exfat filesystem images too, but this is not used, the Presumably because "fattools mkfat" seems to have further external dependencies and so would be more of a pain to use. I don't think it does, but I think we should stick to tools which will be in production systems as much as possible, and that is mkfs.exfat from exfatprogs . The fattools is only used here because mkfs.exfat cannot create an image from list of files. Well, I tried "fattools mkfs.exfat" and it wanted tkinter to be installed, so that's why I'd not bother with it. Uh OK.
Re: [PATCH] ARM: stm32: Fix CONFIG_BOOTCOUNT_ALTBOOTCMD update on DH STM32MP1 DHSOM
On 2/21/25 18:09, Tom Rini wrote:
> On Fri, Feb 21, 2025 at 06:08:38PM +0100, Marek Vasut wrote:
>
>> The environment is missing closing quotes for string variable, but the
>> variable is empty on this system, remove the CONFIG_BOOTCOUNT_ALTBOOTCMD
>> assignment entirely.
>>
>> Fixes: 940135eea5df ("Kconfig: Move CONFIG_BOOTCOUNT_ALTBOOTCMD to Kconfig")
>> Signed-off-by: Marek Vasut
>
> Reviewed-by: Tom Rini
>
Applied to u-boot-stm32/next
Thanks
Patrice
Re: [PATCH v2 1/6] net: lwip: extend wget to support CA (root) certificates
On 3/10/25 12:49, Ilias Apalodimas wrote: > [...] > > FWIW I think this still makes sense for peopke that don't want or can not add the cert in the u-boot binary, but can add a signed script to download it on the fly Reviewed-by: Ilias Apalodimas >>> >>> This still stands, but there are a few warning/errors on the entire >>> patchset. Can you address them and send a v3? >> >> Which warnings/errors? Which config? I see none with >> qemu_arm64_lwip_defconfig. > > Ah my bad, it's checkpatch that has all that Yes, I think they're all false positives, or rather things we want to ignore for consistency with existing code. Thanks, -- Jerome > > Cheers > /Ilias >> >> Thanks, >> -- >> Jerome >> >>> >>> Thanks >>> /Ilias
Re: [PATCH v2 4/6] net: lwip: add support for built-in root certificates
On 3/10/25 12:52, Ilias Apalodimas wrote:
> Hi Jerome,
>
> [...]
>
>
+#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
+ cacert_initialized = true;
+#endif
return CMD_RET_SUCCESS;
}
+
+#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
+static int set_cacert_builtin(void)
+{
+ return _set_cacert(builtin_cacert, builtin_cacert_size);
+}
#endif
+#if CONFIG_IS_ENABLED(WGET_CACERT)
+static int set_cacert(char * const saddr, char * const ssz)
+{
+ ulong addr, sz;
+
+ addr = hextoul(saddr, NULL);
+ sz = hextoul(ssz, NULL);
+
+ return _set_cacert((void *)addr, sz);
+}
+#endif
+#endif /* CONFIG_WGET_CACERT || CONFIG_WGET_BUILTIN_CACERT */
+
static int wget_loop(struct udevice *udev, ulong dst_addr, char *uri)
{
#if CONFIG_IS_ENABLED(WGET_HTTPS)
@@ -373,8 +401,15 @@ static int wget_loop(struct udevice *udev, ulong
dst_addr, char *uri)
memset(&conn, 0, sizeof(conn));
#if CONFIG_IS_ENABLED(WGET_HTTPS)
if (is_https) {
- char *ca = cacert;
- size_t ca_sz = cacert_size;
+ char *ca;
+ size_t ca_sz;
+
+#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
+ if (!cacert_initialized)
+ set_cacert_builtin();
+#endif
>>>
>>> The code and the rest of the patch seems fine, but the builtin vs
>>> downloaded cert is a bit confusing here.
>>> Since the built-in cert always gets initialized in the wget loop it
>>> would overwrite any certificates that are downloaded in memory?
>>
>> The built-in certs are enabled only when cacert_initialized is false.
>> set_cacert_builtin() will set it to true (via _set_cacert()), so it will
>> happen only once. Note also that any successful "wget cacert" command
>> will also do the same. So effectively these two lines enable the
>> built-in certificates by default, that's all they do.
>
> Ok, so if you download a cert in memory and have u-boot with a builtin
> certificate, then the memory one will be overwritten in the first run.
No, because the downloaded cert must have be made active via "wget cacert
", which will set cacert_initialized to true, and thus the
built-in certs won't overwrite them. Or did I miss something?
Cheers,
--
Jerome
> This is not easy to solve, I was trying to think of ways to make the
> functionality clearer to users.
>
> Cheers
> /Ilias
>>
>> Cheers,
>> --
>> Jerome
>>
>>>
>>> [...]
>>>
>>> Cheers
>>> /Ilias
Re: [PATCH v2 1/3] ARM: dts: stm32: drop "st,button1" compatible
On 3/10/25 11:03, Patrice CHOTARD wrote:
>
>
> On 2/25/25 10:52, Patrice CHOTARD wrote:
>>
>>
>> On 2/24/25 19:39, Dario Binacchi wrote:
>>> It is pointless to use the custom compatible "st,button1" when
>>> stm32746g-eval.dts and stm32f769-disco.dts already contain the
>>> "gpio-keys" compatible, which is specifically used for button
>>> management.
>>>
>>> Signed-off-by: Dario Binacchi
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Drop gpio-keys node from stm32f746-disco-u-boot.dtsi
>>>
>>> arch/arm/dts/stm32746g-eval-u-boot.dtsi| 5 -
>>> arch/arm/dts/stm32f746-disco-u-boot.dtsi | 5 -
>>> arch/arm/dts/stm32f769-disco-u-boot.dtsi | 5 -
>>> board/st/stm32f746-disco/stm32f746-disco.c | 15 ---
>>> 4 files changed, 30 deletions(-)
>>>
>>> diff --git a/arch/arm/dts/stm32746g-eval-u-boot.dtsi
>>> b/arch/arm/dts/stm32746g-eval-u-boot.dtsi
>>> index 1c288acec992..f64329287357 100644
>>> --- a/arch/arm/dts/stm32746g-eval-u-boot.dtsi
>>> +++ b/arch/arm/dts/stm32746g-eval-u-boot.dtsi
>>> @@ -23,11 +23,6 @@
>>> spi0 = &qspi;
>>> };
>>>
>>> - button1 {
>>> - compatible = "st,button1";
>>> - button-gpio = <&gpioc 13 0>;
>>> - };
>>> -
>>> led1 {
>>> compatible = "st,led1";
>>> led-gpio = <&gpiof 10 0>;
>>> diff --git a/arch/arm/dts/stm32f746-disco-u-boot.dtsi
>>> b/arch/arm/dts/stm32f746-disco-u-boot.dtsi
>>> index 1b42d6cbbc19..a79fca261a2c 100644
>>> --- a/arch/arm/dts/stm32f746-disco-u-boot.dtsi
>>> +++ b/arch/arm/dts/stm32f746-disco-u-boot.dtsi
>>> @@ -23,11 +23,6 @@
>>> spi0 = &qspi;
>>> };
>>>
>>> - button1 {
>>> - compatible = "st,button1";
>>> - button-gpio = <&gpioi 11 0>;
>>> - };
>>> -
>>> led1 {
>>> compatible = "st,led1";
>>> led-gpio = <&gpioi 1 0>;
>>> diff --git a/arch/arm/dts/stm32f769-disco-u-boot.dtsi
>>> b/arch/arm/dts/stm32f769-disco-u-boot.dtsi
>>> index add55c96e21f..a50fba64dcd2 100644
>>> --- a/arch/arm/dts/stm32f769-disco-u-boot.dtsi
>>> +++ b/arch/arm/dts/stm32f769-disco-u-boot.dtsi
>>> @@ -23,11 +23,6 @@
>>> spi0 = &qspi;
>>> };
>>>
>>> - button1 {
>>> - compatible = "st,button1";
>>> - button-gpio = <&gpioa 0 0>;
>>> - };
>>> -
>>> led1 {
>>> compatible = "st,led1";
>>> led-gpio = <&gpioj 5 0>;
>>> diff --git a/board/st/stm32f746-disco/stm32f746-disco.c
>>> b/board/st/stm32f746-disco/stm32f746-disco.c
>>> index 8966a09501ed..65a39d965c72 100644
>>> --- a/board/st/stm32f746-disco/stm32f746-disco.c
>>> +++ b/board/st/stm32f746-disco/stm32f746-disco.c
>>> @@ -94,21 +94,6 @@ int board_late_init(void)
>>> dm_gpio_set_value(&gpio, 1);
>>> }
>>>
>>> - /* read button 1*/
>>> - node = fdt_node_offset_by_compatible(gd->fdt_blob, 0, "st,button1");
>>> - if (node < 0)
>>> - return -1;
>>> -
>>> - gpio_request_by_name_nodev(offset_to_ofnode(node), "button-gpio", 0,
>>> - &gpio, GPIOD_IS_IN);
>>> -
>>> - if (dm_gpio_is_valid(&gpio)) {
>>> - if (dm_gpio_get_value(&gpio))
>>> - puts("usr button is at HIGH LEVEL\n");
>>> - else
>>> - puts("usr button is at LOW LEVEL\n");
>>> - }
>>> -
>>> return 0;
>>> }
>>>
>> Reviewed-by: Patrice Chotard
>>
>> Thanks
>> Patrice
> Applied to u-boot-stm32/next
>
> Thanks
> Patrice
Applied to u-boot-stm32/next
Thanks
Patrice
Re: [PATCH] ARM: dts: stm32: Add support for STM32MP13xx DHCOR SoM and DHSBC rev.200 board
On 3/3/25 09:35, Patrice CHOTARD wrote:
>
>
> On 3/2/25 16:43, Marek Vasut wrote:
>> LDO2 is expansion connector supply on STM32MP13xx DHCOR DHSBC rev.200.
>> LDO5 is carrier board supply on STM32MP13xx DHCOR DHSBC rev.200. Keep
>> both regulators always enabled to make sure both the carrier board and
>> the expansion connector is always powered on and supplied with correct
>> voltage.
>>
>> Describe ST33TPHF2XSPI TPM 2.0 chip reset lines.
>>
>> This is a port of Linux kernel patch posted at:
>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250302152605.54792-1-ma...@denx.de/
>> This change shall be removed when the Linux kernel DT change lands
>> and Linux kernel DTs get synchronized with U-Boot DTs.
>>
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Tom Rini
>> Cc: u-b...@dh-electronics.com
>> Cc: u-boot@lists.denx.de
>> Cc: uboot-st...@st-md-mailman.stormreply.com
>> ---
>> .../dts/stm32mp135f-dhcor-dhsbc-u-boot.dtsi | 22 +++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp135f-dhcor-dhsbc-u-boot.dtsi
>> b/arch/arm/dts/stm32mp135f-dhcor-dhsbc-u-boot.dtsi
>> index d718aae16ca..eace94f5fa4 100644
>> --- a/arch/arm/dts/stm32mp135f-dhcor-dhsbc-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp135f-dhcor-dhsbc-u-boot.dtsi
>> @@ -23,3 +23,25 @@
>> &usbphyc {
>> bootph-all;
>> };
>> +
>> +&st33htph {
>> +reset-gpios = <&gpioe 12 GPIO_ACTIVE_LOW>;
>> +};
>> +
>> +/* LDO2 is expansion connector 3V3 supply on STM32MP13xx DHCOR DHSBC
>> rev.200 */
>> +&vdd_ldo2 {
>> +bootph-all;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +};
>> +
>> +/* LDO5 is carrier board 3V3 supply on STM32MP13xx DHCOR DHSBC rev.200 */
>> +&vdd_sd {
>> +bootph-all;
>> +regulator-always-on;
>> +regulator-boot-on;
>> +regulator-min-microvolt = <330>;
>> +regulator-max-microvolt = <330>;
>> +};
>
> Reviewed-by: Patrice Chotard
>
> Thanks
> Patrice
Applied to u-boot-stm32/next
Thanks
Patrice
Re: [PATCH 1/2] sunxi: h616: dram: Rework size detection
在 2025-03-09星期日的 07:31 +0100，Jernej Skrabec写道：
> Since there is quite a few possible DRAM configurations in terms of
> bus
> width, rank and rows and columns count, size detection algorithm must
> be
> very careful not to test combination which would be bigger than H616
> is
> actually capable of handling.
>
> Ideally, we should always detect memory aliasing, even for 4 GB
> memory
> size, which is the maximum amount of memory that H616 is capable of
> handling. For this reason, we have to configure minimum amount of
> supported rows when testing for columns and vice versa. This way test
> code will never step out of 4 GB boundary.
This is also the behavior of previous DRAM drivers.
>
> While at it, check for 17 rows maximum. This aligns code with BSP
> DRAM
> driver. There is probably no such configuration which would make
> sense
> with 4 GB memory.
I checked the JEDEC JESD79-4D document, and found that 18 rows are only
available for x4 dies, which are not compatible with these Allwinner
SoCs at all (not enough DQS pins).
Reviewed-by: Icenowy Zheng
>
> Signed-off-by: Jernej Skrabec
> ---
> arch/arm/mach-sunxi/dram_sun50i_h616.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun50i_h616.c b/arch/arm/mach-
> sunxi/dram_sun50i_h616.c
> index b3554cc64bf5..6f84e59e39cd 100644
> --- a/arch/arm/mach-sunxi/dram_sun50i_h616.c
> +++ b/arch/arm/mach-sunxi/dram_sun50i_h616.c
> @@ -1363,7 +1363,7 @@ static void mctl_auto_detect_rank_width(const
> struct dram_para *para,
> static void mctl_auto_detect_dram_size(const struct dram_para *para,
> struct dram_config *config)
> {
> - unsigned int shift;
> + unsigned int shift, cols, rows;
>
> /* max. config for columns, but not rows */
> config->cols = 11;
> @@ -1373,23 +1373,27 @@ static void mctl_auto_detect_dram_size(const
> struct dram_para *para,
> shift = config->bus_full_width + 1;
>
> /* detect column address bits */
> - for (config->cols = 8; config->cols < 11; config->cols++) {
> - if (mctl_mem_matches(1ULL << (config->cols + shift)))
> + for (cols = 8; cols < 11; cols++) {
> + if (mctl_mem_matches(1ULL << (cols + shift)))
> break;
> }
> - debug("detected %u columns\n", config->cols);
> + debug("detected %u columns\n", cols);
>
> /* reconfigure to make sure that all active rows are
> accessible */
> - config->rows = 18;
> + config->cols = 8;
> + config->rows = 17;
> mctl_core_init(para, config);
>
> /* detect row address bits */
> shift = config->bus_full_width + 4 + config->cols;
> - for (config->rows = 13; config->rows < 18; config->rows++) {
> - if (mctl_mem_matches(1ULL << (config->rows + shift)))
> + for (rows = 13; rows < 17; rows++) {
> + if (mctl_mem_matches(1ULL << (rows + shift)))
> break;
> }
> - debug("detected %u rows\n", config->rows);
> + debug("detected %u rows\n", rows);
> +
> + config->cols = cols;
> + config->rows = rows;
> }
>
> static unsigned long mctl_calc_size(const struct dram_config
> *config)
Re: [PATCH 08/12] fs: exfat: Fix conversion overflow errors
Hi Marek,
On 3/8/25 9:12 PM, Marek Vasut wrote:
Fix the following conversion overflow errors. The input field is already
limited to 3/2/1 bits using the bitwise and, move the parenthesis around
to avoid the bogus warning:
"
fs/exfat/utf.c: In function ‘utf8_to_wchar’:
fs/exfat/utf.c:165:23: warning: overflow in conversion from ‘int’ to ‘wchar_t’ {aka
‘short unsigned int’} changes value from ‘(int)(short unsigned int)*input << 18
& 1835008’ to ‘0’ [-Woverflow]
165 | *wc = ((wchar_t) input[0] & 0x07) << 18;
| ^
fs/exfat/utf.c:170:23: warning: overflow in conversion from ‘int’ to ‘wchar_t’ {aka
‘short unsigned int’} changes value from ‘(int)(short unsigned int)*input << 24
& 50331648’ to ‘0’ [-Woverflow]
170 | *wc = ((wchar_t) input[0] & 0x03) << 24;
| ^
fs/exfat/utf.c:175:23: warning: overflow in conversion from ‘int’ to ‘wchar_t’ {aka
‘short unsigned int’} changes value from ‘(int)(short unsigned int)*input << 30
& 1073741824’ to ‘0’ [-Woverflow]
175 | *wc = ((wchar_t) input[0] & 0x01) << 30;
| ^
"
Since this doesn't seem to be U-Boot-specific, any chance to open a Pull
Request on the project so we may be able to not carry this patch when
upgrading (yes, the last commit in the branch was two years ago, but it
seems the maintainer is still active on issues).
Considering that wchar_t is an unsigned short int and that USHRT_MAX is
0x (so 2B or 16b)...
Signed-off-by: Marek Vasut
---
Cc: Baruch Siach
Cc: Francesco Dolcini
Cc: Heinrich Schuchardt
Cc: Hiago De Franco
Cc: Ilias Apalodimas
Cc: Nam Cao
Cc: Simon Glass
Cc: Sughosh Ganu
Cc: Tom Rini
Cc: u-boot@lists.denx.de
---
fs/exfat/utf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/exfat/utf.c b/fs/exfat/utf.c
index b1d09e76478..5be8dcc2170 100644
--- a/fs/exfat/utf.c
+++ b/fs/exfat/utf.c
@@ -162,17 +162,17 @@ static const char* utf8_to_wchar(const char* input,
wchar_t* wc,
}
else if ((input[0] & 0xf8) == 0xf0)
{
- *wc = ((wchar_t) input[0] & 0x07) << 18;
+ *wc = (wchar_t)((input[0] & 0x07) << 18);
size = 4;
}
else if ((input[0] & 0xfc) == 0xf8)
{
- *wc = ((wchar_t) input[0] & 0x03) << 24;
+ *wc = (wchar_t)((input[0] & 0x03) << 24);
size = 5;
}
else if ((input[0] & 0xfe) == 0xfc)
{
- *wc = ((wchar_t) input[0] & 0x01) << 30;
+ *wc = (wchar_t)((input[0] & 0x01) << 30);
... wouldn't those still overflow? I assume unsigned short int like int
may have an architecture-dependent size, but seems to be at least 2B,
which wouldn't be enough to store all that?
Cheers,
Quentin
Re: [PATCH 11/12] pytest: requirements.txt: Include setuptools
On Mon, Mar 10, 2025 at 10:07:40PM +0100, Marek Vasut wrote: > On 3/10/25 2:55 PM, Tom Rini wrote: > > On Sat, Mar 08, 2025 at 09:12:15PM +0100, Marek Vasut wrote: > > > > > This seems to be needed for filesystem tests at least on > > > ubuntu 22.04 machines. Add setuptools into requirements.txt . > > > > > > Signed-off-by: Marek Vasut > > > --- > > > Cc: Baruch Siach > > > Cc: Francesco Dolcini > > > Cc: Heinrich Schuchardt > > > Cc: Hiago De Franco > > > Cc: Ilias Apalodimas > > > Cc: Nam Cao > > > Cc: Simon Glass > > > Cc: Sughosh Ganu > > > Cc: Tom Rini > > > Cc: u-boot@lists.denx.de > > > --- > > > test/py/requirements.txt | 1 + > > > 1 file changed, 1 insertion(+) > > > > This belongs in the requirements.txt for the tool that requires > > setuptools, not pytest. It's also listed as a required host tool / > > package in doc/builds/gcc.rst. Having just re-created the > > requirements.txt file, I don't want to add things that will get dropped > > again the next time. > > This seems to come from pylibfdt . I can drop this patch too. Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 12/12] test_fs: Add exfat tests
On Mon, Mar 10, 2025 at 09:37:36PM +0100, Marek Vasut wrote:
> On 3/10/25 4:30 PM, Tom Rini wrote:
> > On Sat, Mar 08, 2025 at 09:12:16PM +0100, Marek Vasut wrote:
> > > Add tests for the exfat filesystem. These tests are largely an
> > > extension of the FS_GENERIC tests with the following notable
> > > exceptions.
> > >
> > > The filesystem image for exfat tests is generated using combination
> > > of exfatutils mkfs.exfat and python fattools. The fattols are capable
> >
> > Did you mean "exfatprogs" and not "exfatutils" ? But we need to update
> > tools/docker/Dockerfile to list the tool there.
>
> It seems the CI container already has the tools in it ?
Implicitly and not explicitly then.
> Where do I update the docker container, is that tools/docker/Dockerfile ?
Yes, thanks.
> > > of generating exfat filesystem images too, but this is not used, the
> >
> > Presumably because "fattools mkfat" seems to have further external
> > dependencies and so would be more of a pain to use.
>
> I don't think it does, but I think we should stick to tools which will be in
> production systems as much as possible, and that is mkfs.exfat from
> exfatprogs . The fattools is only used here because mkfs.exfat cannot create
> an image from list of files.
Well, I tried "fattools mkfs.exfat" and it wanted tkinter to be
installed, so that's why I'd not bother with it.
> [...]
>
> > > test/py/requirements.txt | 1 +
> > > test/py/tests/fs_helper.py| 8 ++--
> > > test/py/tests/test_fs/conftest.py | 20 +++-
> > > test/py/tests/test_fs/test_ext.py | 20 ++--
> > > 4 files changed, 32 insertions(+), 17 deletions(-)
> >
> > We also need to update test/py/tests/test_fs/fstest_helpers.py to know
> > to call fsck.exfat.
>
> Fixed in V2, thanks.
>
> > [snip]
> > > @@ -64,6 +66,8 @@ def mk_fs(config, fs_type, size, prefix, src_dir=None,
> > > size_gran = 0x10):
> > > check_call(f'tune2fs -O ^metadata_csum {fs_img}',
> > > shell=True)
> > > elif fs_lnxtype == 'vfat' and src_dir:
> > > check_call(f'mcopy -i {fs_img} -vsmpQ {src_dir}/* ::/',
> > > shell=True)
> > > +elif fs_lnxtype == 'exfat' and src_dir:
> > > +check_call(f'fattools cp {src_dir}/* {fs_img}', shell=True)
> > > return fs_img
> > > except CalledProcessError:
> > > call(f'rm -f {fs_img}', shell=True)
> >
> > A cleanup to use fattools in both cases would be nice, as a follow-up.
> See above, I am not convinced we should go for fattools all across the
> board. Do you think we should ?
In that we can't drop dosfsutils entirely, it's not a big deal either
way.
--
Tom
signature.asc
Description: PGP signature
[PATCH] board: ti: am62px: rm-cfg: Add support for HC BCDMA
The first 4 block copy channels and rings on AM62P support High Capacity Block Copy. These channels have approximately 3x improvement over the normal Block copy channels when doing DDR-to-DDR copy. Currently, during allocation these channels do not have a separate interface and are allocated with normal BCDMA channels. Latest TIFS and DM firmware adds support for differentiating these High Capcity resources. This update is for allocating these new resource type to different hosts with below mentioned scheme. - --- - Resource A53_2 MCU_R5 WKUP_R5 - --- - BCDMA HC CHAN [4] => 2 (Primary) 1 (Primary) 1 (Primary) BCDMA HC CHAN RING [4] => 2 (Primary) 1 (Primary) 1 (Primary) BCDMA CHAN [4] => 18 (Primary)2 (Primary) 6 (Primary) BCDMA CHAN RING[4] => 18 (Primary)2 (Primary) 6 (Primary) Signed-off-by: Sparsh Kumar Signed-off-by: Sebin Francis Signed-off-by: Vishal Mahaveer --- This patch is based on commit 743c15b9fd (Merge patch series "This series adds support for file renaming to EFI_FILE_PROTOCOL.SetInfo().") of the next branch of U-Boot. board/ti/am62px/rm-cfg.yaml | 70 +++-- 1 file changed, 59 insertions(+), 11 deletions(-) diff --git a/board/ti/am62px/rm-cfg.yaml b/board/ti/am62px/rm-cfg.yaml index dc445a4b72f..73da85eeade 100644 --- a/board/ti/am62px/rm-cfg.yaml +++ b/board/ti/am62px/rm-cfg.yaml @@ -244,7 +244,7 @@ rm-cfg: subhdr: magic: 0x7B25 size: 8 -resasg_entries_size: 1048 +resasg_entries_size: 1112 reserved: 0 resasg_entries: - @@ -303,31 +303,55 @@ rm-cfg: reserved: 0 - start_resource: 0 +num_resource: 2 +type: 1676 +host_id: 12 +reserved: 0 +- +start_resource: 2 +num_resource: 1 +type: 1676 +host_id: 35 +reserved: 0 +- +start_resource: 2 +num_resource: 1 +type: 1676 +host_id: 36 +reserved: 0 +- +start_resource: 3 +num_resource: 1 +type: 1676 +host_id: 30 +reserved: 0 +- +start_resource: 4 num_resource: 18 type: 1677 host_id: 12 reserved: 0 - -start_resource: 18 +start_resource: 22 num_resource: 6 type: 1677 host_id: 35 reserved: 0 - -start_resource: 18 +start_resource: 22 num_resource: 6 type: 1677 host_id: 36 reserved: 0 - -start_resource: 24 +start_resource: 28 num_resource: 2 type: 1677 host_id: 30 reserved: 0 - -start_resource: 26 -num_resource: 6 +start_resource: 30 +num_resource: 2 type: 1677 host_id: 128 reserved: 0 @@ -387,31 +411,55 @@ rm-cfg: reserved: 0 - start_resource: 0 +num_resource: 2 +type: 1695 +host_id: 12 +reserved: 0 +- +start_resource: 2 +num_resource: 1 +type: 1695 +host_id: 35 +reserved: 0 +- +start_resource: 2 +num_resource: 1 +type: 1695 +host_id: 36 +reserved: 0 +- +start_resource: 3 +num_resource: 1 +type: 1695 +host_id: 30 +reserved: 0 +- +start_resource: 4 num_resource: 18 type: 1696 host_id: 12 reserved: 0 - -start_resource: 18 +start_resource: 22 num_resource: 6 type: 1696 host_id: 35 reserved: 0 - -start_resource: 18 +start_resource: 22 num_resource: 6 type: 1696 host_id: 36 reserved: 0 - -start_resource: 24 +start_resource: 28 num_resource: 2 type: 1696 host_id: 30 reserved: 0 - -start_resource: 26 -num_resource: 6 +start_resource: 30 +num_resource: 2 type: 1696 host_id: 128 reserved: 0 -- 2.43.0
Re: [PATCH 5/5] ARM: dts: stm32: Add TIMERS inverted PWM channel 3 on STM32MP135F-DK
On 3/6/25 15:15, Patrice CHOTARD wrote:
>
>
> On 3/6/25 11:56, Cheick Traore wrote:
>> The pwm source TIM1_CH3N channel (on PE12) in inverted polarity mode
>> will be used to manage the brightness of the panel backlight on
>> STM32MP135F-DK.
>>
>> Signed-off-by: Cheick Traore
>> ---
>>
>> arch/arm/dts/stm32mp13-pinctrl.dtsi | 15 +++
>> arch/arm/dts/stm32mp135f-dk.dts | 14 ++
>> 2 files changed, 29 insertions(+)
>>
>> diff --git a/arch/arm/dts/stm32mp13-pinctrl.dtsi
>> b/arch/arm/dts/stm32mp13-pinctrl.dtsi
>> index c01d39f03ea..52c2a9f24d7 100644
>> --- a/arch/arm/dts/stm32mp13-pinctrl.dtsi
>> +++ b/arch/arm/dts/stm32mp13-pinctrl.dtsi
>> @@ -215,6 +215,21 @@
>> };
>> };
>>
>> +pwm1_ch3n_pins_a: pwm1-ch3n-0 {
>> +pins {
>> +pinmux = ; /* TIM1_CH3N */
>> +bias-pull-down;
>> +drive-push-pull;
>> +slew-rate = <0>;
>> +};
>> +};
>> +
>> +pwm1_ch3n_sleep_pins_a: pwm1-ch3n-sleep-0 {
>> +pins {
>> +pinmux = ; /* TIM1_CH3N
>> */
>> +};
>> +};
>> +
>> pwm3_pins_a: pwm3-0 {
>> pins {
>> pinmux = ; /* TIM3_CH4 */
>> diff --git a/arch/arm/dts/stm32mp135f-dk.dts
>> b/arch/arm/dts/stm32mp135f-dk.dts
>> index eea740d097c..275823da3c6 100644
>> --- a/arch/arm/dts/stm32mp135f-dk.dts
>> +++ b/arch/arm/dts/stm32mp135f-dk.dts
>> @@ -9,6 +9,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "stm32mp135.dtsi"
>> #include "stm32mp13xf.dtsi"
>> @@ -207,6 +208,19 @@
>> status = "disabled";
>> };
>>
>> +&timers1 {
>> +/* spare dmas for other usage */
>> +/delete-property/dmas;
>> +/delete-property/dma-names;
>> +status = "okay";
>> +pwm1: pwm {
>> +pinctrl-0 = <&pwm1_ch3n_pins_a>;
>> +pinctrl-1 = <&pwm1_ch3n_sleep_pins_a>;
>> +pinctrl-names = "default", "sleep";
>> +status = "okay";
>> +};
>> +};
>> +
>> &timers3 {
>> /delete-property/dmas;
>> /delete-property/dma-names;
>
>
> Reviewed-by: Patrice Chotard
>
> Thanks
> Patrice
Applied to u-boot-stm32/next
Thanks
Patrice
Re: [PATCH 2/5] mach-stm32: add multifunction timer driver support
On 3/6/25 15:16, Patrice CHOTARD wrote:
>
>
> On 3/6/25 11:56, Cheick Traore wrote:
>> Add support for STM32MP timer multi-function driver.
>> These timers can be use as counter, trigger or pwm generator.
>> This driver will be used to manage the main resources of the timer to
>> provide them to the functionnalities which need these ones.
>>
>> Signed-off-by: Cheick Traore
>> ---
>>
>> arch/arm/mach-stm32mp/Kconfig | 6 ++
>> arch/arm/mach-stm32mp/Makefile | 1 +
>> arch/arm/mach-stm32mp/include/mach/timers.h | 55 ++
>> arch/arm/mach-stm32mp/timers.c | 82 +
>> 4 files changed, 144 insertions(+)
>> create mode 100644 arch/arm/mach-stm32mp/include/mach/timers.h
>> create mode 100644 arch/arm/mach-stm32mp/timers.c
>>
>> diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
>> index 25663a99464..002da2e3d3b 100644
>> --- a/arch/arm/mach-stm32mp/Kconfig
>> +++ b/arch/arm/mach-stm32mp/Kconfig
>> @@ -153,6 +153,12 @@ config CMD_STM32KEY
>> This command is used to evaluate the secure boot on stm32mp SOC,
>> it is deactivated by default in real products.
>>
>> +config MFD_STM32_TIMERS
>> +bool "STM32 multifonction timer support"
>> +help
>> + Select this to enable support for the multifunction timer found on
>> + STM32 devices.
>> +
>> source "arch/arm/mach-stm32mp/Kconfig.13x"
>> source "arch/arm/mach-stm32mp/Kconfig.15x"
>> source "arch/arm/mach-stm32mp/Kconfig.25x"
>> diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
>> index db7ed19bd91..103e3410ad9 100644
>> --- a/arch/arm/mach-stm32mp/Makefile
>> +++ b/arch/arm/mach-stm32mp/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_STM32MP15X) += stm32mp1/
>> obj-$(CONFIG_STM32MP13X) += stm32mp1/
>> obj-$(CONFIG_STM32MP25X) += stm32mp2/
>>
>> +obj-$(CONFIG_MFD_STM32_TIMERS) += timers.o
>> obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o
>> ifndef CONFIG_XPL_BUILD
>> obj-y += cmd_stm32prog/
>> diff --git a/arch/arm/mach-stm32mp/include/mach/timers.h
>> b/arch/arm/mach-stm32mp/include/mach/timers.h
>> new file mode 100644
>> index 000..a84465bb28e
>> --- /dev/null
>> +++ b/arch/arm/mach-stm32mp/include/mach/timers.h
>> @@ -0,0 +1,55 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2025, STMicroelectronics - All Rights Reserved
>> + * Author: Cheick Traore
>> + *
>> + * Originally based on the Linux kernel v6.1
>> include/linux/mfd/stm32-timers.h.
>> + */
>> +
>> +#ifndef __STM32_TIMERS_H
>> +#define __STM32_TIMERS_H
>> +
>> +#include
>> +
>> +#define TIM_CR1 0x00/* Control Register 1 */
>> +#define TIM_CR2 0x04/* Control Register 2 */
>> +#define TIM_SMCR0x08/* Slave mode control reg */
>> +#define TIM_DIER0x0C/* DMA/interrupt register */
>> +#define TIM_SR 0x10/* Status register */
>> +#define TIM_EGR 0x14/* Event Generation Reg*/
>> +#define TIM_CCMR1 0x18/* Capt/Comp 1 Mode Reg*/
>> +#define TIM_CCMR2 0x1C/* Capt/Comp 2 Mode Reg*/
>> +#define TIM_CCER0x20/* Capt/Comp Enable Reg*/
>> +#define TIM_CNT 0x24/* Counter */
>> +#define TIM_PSC 0x28/* Prescaler */
>> +#define TIM_ARR 0x2c/* Auto-Reload Register*/
>> +#define TIM_CCRx(x) (0x34 + 4 * ((x) - 1)) /* Capt/Comp Register x (x ∈
>> {1, .. 4}) */
>> +#define TIM_BDTR0x44/* Break and Dead-Time Reg */
>> +#define TIM_DCR 0x48/* DMA control register*/
>> +#define TIM_DMAR0x4C/* DMA register for transfer */
>> +#define TIM_TISEL 0x68/* Input Selection */
>> +
>> +#define TIM_CR1_CEN BIT(0) /* Counter Enable */
>> +#define TIM_CR1_ARPEBIT(7)
>> +#define TIM_CCER_CCXE (BIT(0) | BIT(4) | BIT(8) | BIT(12))
>> +#define TIM_CCER_CC1E BIT(0)
>> +#define TIM_CCER_CC1P BIT(1) /* Capt/Comp 1 Polarity */
>> +#define TIM_CCER_CC1NE BIT(2) /* Capt/Comp 1N out Ena*/
>> +#define TIM_CCER_CC1NP BIT(3) /* Capt/Comp 1N Polarity */
>> +#define TIM_CCMR_PE BIT(3) /* Channel Preload Enable */
>> +#define TIM_CCMR_M1 (BIT(6) | BIT(5)) /* Channel PWM Mode 1 */
>> +#define TIM_BDTR_MOEBIT(15) /* Main Output Enable */
>> +#define TIM_EGR_UG BIT(0) /* Update Generation */
>> +
>> +#define MAX_TIM_PSC 0x
>> +
>> +struct stm32_timers_plat {
>> +void __iomem *base;
>> +};
>> +
>> +struct stm32_timers_priv {
>> +u32 max_arr;
>> +ulong rate;
>> +};
>> +
>> +#endif
>> diff --git a/arch/arm/mach-stm32mp/timers.c b/arch/arm/mach-stm32mp/timers.c
>> new file mode 100644
>> index 000..a3207895f40
>> --- /dev/null
>> +++ b/arch/arm/mach-stm32mp/timers.c
>> @@ -0,0 +1,82 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2025, STMicro
Re: [PATCH] configs: stm32f769-disco: Fix console cmdline
On 2/11/25 17:49, Patrice CHOTARD wrote: > > > On 2/11/25 10:12, Linus Walleij wrote: >> The Linux cmdline encoded in the defconfig is wrong, the >> STM32 USART driver registers as ttySTM0 not ttyS0. >> >> Signed-off-by: Linus Walleij >> --- >> configs/stm32f769-disco_defconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/configs/stm32f769-disco_defconfig >> b/configs/stm32f769-disco_defconfig >> index >> 5be221afd2facb0af4a3a3f8df0f24fb34eaf10d..9edda0e36b2e92c3dbe3298a3da04bd731dac452 >> 100644 >> --- a/configs/stm32f769-disco_defconfig >> +++ b/configs/stm32f769-disco_defconfig >> @@ -18,7 +18,7 @@ CONFIG_AUTOBOOT_KEYED=y >> CONFIG_AUTOBOOT_PROMPT="Hit SPACE in %d seconds to stop autoboot.\n" >> CONFIG_AUTOBOOT_STOP_STR=" " >> CONFIG_USE_BOOTARGS=y >> -CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk consoleblank=0 >> ignore_loglevel" >> +CONFIG_BOOTARGS="console=ttySTM0,115200n8 earlyprintk consoleblank=0 >> ignore_loglevel" >> CONFIG_SYS_PBSIZE=1050 >> # CONFIG_DISPLAY_CPUINFO is not set >> CONFIG_CYCLIC_MAX_CPU_TIME_US=8000 >> >> --- >> base-commit: cb3612dfe3fd9a702dc3657aae15b07974f9aa0b >> change-id: 20250211-stm32f769-uart-fix-66650ddf9c80 >> >> Best regards, > > > Hi Linus > > Reviewed-by: Patrice Chotard > > Thanks > Patrice Applied to u-boot-stm32/next Thanks Patrice
Re: [PATCH] ARM: stm32mp: Fix dram_bank_mmu_setup() for ram_top=0
On 3/10/25 09:24, Patrice CHOTARD wrote:
>
>
> On 3/9/25 03:05, Marek Vasut wrote:
>> On STM32MP15xx with 1 GiB of DRAM, the gd->ram_top becomes 0,
>> because DRAM base 0xc000 + DRAM size 0x4000 leads to
>> gd->ram_top overflow which resets it to 0. Handle this special
>> case simply by checking for gd->ram_top being zero, and if it
>> is, assume there is no addr >= gd->ram_top .
>>
>> This fixes boot hang on STM32MP15xx with 1 GiB of DRAM.
>>
>> Fixes: 25fb58e88aba ("ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB
>> located above ram_top")
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Ilias Apalodimas
>> Cc: Lukasz Majewski
>> Cc: Marek Vasut
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Simon Glass
>> Cc: Sughosh Ganu
>> Cc: Tom Rini
>> Cc: u-boot@lists.denx.de
>> Cc: uboot-st...@st-md-mailman.stormreply.com
>> ---
>> arch/arm/mach-stm32mp/stm32mp1/cpu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-stm32mp/stm32mp1/cpu.c
>> b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
>> index cb1b84c9af9..d5eaf6711b6 100644
>> --- a/arch/arm/mach-stm32mp/stm32mp1/cpu.c
>> +++ b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
>> @@ -82,7 +82,7 @@ void dram_bank_mmu_setup(int bank)
>> option = DCACHE_DEFAULT_OPTION;
>> if (use_lmb &&
>> (lmb_is_reserved_flags(i << MMU_SECTION_SHIFT, LMB_NOMAP) ||
>> -addr >= gd->ram_top)
>> + (gd->ram_top && addr >= gd->ram_top))
>> )
>> option = 0; /* INVALID ENTRY in TLB */
>> set_section_dcache(i, option);
>
>
> Hi Marek
>
> Reviewed-by: Patrice Chotard
>
> Thanks
> Patrice
>
Applied to u-boot-stm32/master
Thanks
Patrice
Re: [PATCH] ARM: stm32mp: Fix dram_bank_mmu_setup() for ram_top=0
On 3/9/25 03:05, Marek Vasut wrote:
> On STM32MP15xx with 1 GiB of DRAM, the gd->ram_top becomes 0,
> because DRAM base 0xc000 + DRAM size 0x4000 leads to
> gd->ram_top overflow which resets it to 0. Handle this special
> case simply by checking for gd->ram_top being zero, and if it
> is, assume there is no addr >= gd->ram_top .
>
> This fixes boot hang on STM32MP15xx with 1 GiB of DRAM.
>
> Fixes: 25fb58e88aba ("ARM: stm32mp: Fix dram_bank_mmu_setup() for LMB located
> above ram_top")
> Signed-off-by: Marek Vasut
> ---
> Cc: Ilias Apalodimas
> Cc: Lukasz Majewski
> Cc: Marek Vasut
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Simon Glass
> Cc: Sughosh Ganu
> Cc: Tom Rini
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/mach-stm32mp/stm32mp1/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> index cb1b84c9af9..d5eaf6711b6 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/cpu.c
> @@ -82,7 +82,7 @@ void dram_bank_mmu_setup(int bank)
> option = DCACHE_DEFAULT_OPTION;
> if (use_lmb &&
> (lmb_is_reserved_flags(i << MMU_SECTION_SHIFT, LMB_NOMAP) ||
> - addr >= gd->ram_top)
> + (gd->ram_top && addr >= gd->ram_top))
> )
> option = 0; /* INVALID ENTRY in TLB */
> set_section_dcache(i, option);
Hi Marek
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH 11/12] pytest: requirements.txt: Include setuptools
On 3/10/25 2:55 PM, Tom Rini wrote: On Sat, Mar 08, 2025 at 09:12:15PM +0100, Marek Vasut wrote: This seems to be needed for filesystem tests at least on ubuntu 22.04 machines. Add setuptools into requirements.txt . Signed-off-by: Marek Vasut --- Cc: Baruch Siach Cc: Francesco Dolcini Cc: Heinrich Schuchardt Cc: Hiago De Franco Cc: Ilias Apalodimas Cc: Nam Cao Cc: Simon Glass Cc: Sughosh Ganu Cc: Tom Rini Cc: u-boot@lists.denx.de --- test/py/requirements.txt | 1 + 1 file changed, 1 insertion(+) This belongs in the requirements.txt for the tool that requires setuptools, not pytest. It's also listed as a required host tool / package in doc/builds/gcc.rst. Having just re-created the requirements.txt file, I don't want to add things that will get dropped again the next time. This seems to come from pylibfdt . I can drop this patch too.
Re: [PATCH 08/12] fs: exfat: Fix conversion overflow errors
On 3/10/25 12:17 PM, Quentin Schulz wrote:
Hi Marek,
Hi,
On 3/8/25 9:12 PM, Marek Vasut wrote:
Fix the following conversion overflow errors. The input field is already
limited to 3/2/1 bits using the bitwise and, move the parenthesis around
to avoid the bogus warning:
"
fs/exfat/utf.c: In function ‘utf8_to_wchar’:
fs/exfat/utf.c:165:23: warning: overflow in conversion from ‘int’ to
‘wchar_t’ {aka ‘short unsigned int’} changes value from ‘(int)(short
unsigned int)*input << 18 & 1835008’ to ‘0’ [-Woverflow]
165 | *wc = ((wchar_t) input[0] & 0x07) << 18;
| ^
fs/exfat/utf.c:170:23: warning: overflow in conversion from ‘int’ to
‘wchar_t’ {aka ‘short unsigned int’} changes value from ‘(int)(short
unsigned int)*input << 24 & 50331648’ to ‘0’ [-Woverflow]
170 | *wc = ((wchar_t) input[0] & 0x03) << 24;
| ^
fs/exfat/utf.c:175:23: warning: overflow in conversion from ‘int’ to
‘wchar_t’ {aka ‘short unsigned int’} changes value from ‘(int)(short
unsigned int)*input << 30 & 1073741824’ to ‘0’ [-Woverflow]
175 | *wc = ((wchar_t) input[0] & 0x01) << 30;
| ^
"
Since this doesn't seem to be U-Boot-specific, any chance to open a Pull
Request on the project so we may be able to not carry this patch when
upgrading (yes, the last commit in the branch was two years ago, but it
seems the maintainer is still active on issues).
Considering that wchar_t is an unsigned short int and that USHRT_MAX is
0x (so 2B or 16b)...
In fact, this error does not even appear in upstream , because upstream
does not use -fshort-wchar compiler flag . U-Boot does use this compiler
flags since 4a85663ec7ed ("kbuild: Enable -fshort-wchar") .
So I wonder if this might be the right fix here instead:
diff --git a/fs/exfat/Makefile b/fs/exfat/Makefile
index 550c0683d65..8ca112cf0e9 100644
--- a/fs/exfat/Makefile
+++ b/fs/exfat/Makefile
@@ -1,6 +1,9 @@
# SPDX-License-Identifier: GPL-2.0+
#
+# The utf.o does really need 32bit wchar_t
+CFLAGS_REMOVE_utf.o := -fshort-wchar
+
obj-$(CONFIG_FS_EXFAT) += \
cluster.o \
io.o \
Re: [PATCH 07/12] fs: exfat: Add U-Boot porting layer
On 3/10/25 4:18 PM, Tom Rini wrote: On Sat, Mar 08, 2025 at 09:12:11PM +0100, Marek Vasut wrote: Add U-Boot adjustments to the libexfat code and integrate the result into U-Boot filesystem layer. This provides full read-write exfat support for U-Boot available via generic filesystem interface. [snip] diff --git a/fs/exfat/Kconfig b/fs/exfat/Kconfig new file mode 100644 index 000..9f2703a01ee --- /dev/null +++ b/fs/exfat/Kconfig @@ -0,0 +1,4 @@ +config FS_EXFAT + bool "Enable EXFAT filesystem support" + help + This provides read/write support for EXFAT filesystem. Since it looks like you're intentionally not adding exfat-prefixed commands and only using the generic_fs commands, this needs to imply CMD_FS_GENERIC if CMDLINE so that it can be used. diff --git a/fs/exfat/Makefile b/fs/exfat/Makefile new file mode 100644 index 000..824237b6c26 --- /dev/null +++ b/fs/exfat/Makefile @@ -0,0 +1,13 @@ +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-$(CONFIG_FS_EXFAT) = \ Filesystems are where we have all of the anti-patterns of "obj-... =" rather than "+=". It's not a you-must change, but it'd be good to be consistent with most of the tree. The rest seems fine, thanks. Fixed in v2, thanks.
[PATCH v2 4/4] drivers: i2c: Kconfig: Add CONFIG_SYS_I2C_OMAP24XX_REPEATED_START
Add a Kconfig option to disable sending Stop conditions between multiple i2c_msgs within a single xfer. Enable this config by default for ARCH_K3 platforms. Signed-off-by: Aniket Limaye --- v2: - CONFIG_I2C_REPEATED_START -> CONFIG_SYS_I2C_OMAP24XX_REPEATED_START - Link to v1: https://lore.kernel.org/u-boot/20250304220546.866602-4-a-lim...@ti.com/ --- drivers/i2c/Kconfig | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index cdae6825736..41bac5db5a5 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -503,6 +503,15 @@ config SYS_I2C_OMAP24XX help Add support for the OMAP2+ I2C driver. +config SYS_I2C_OMAP24XX_REPEATED_START + bool "Enable I2C repeated start" + depends on SYS_I2C_OMAP24XX + default y if ARCH_K3 + help + Enable support for repeated start. Updates driver defaults to not + send a Stop condition and issue Repeated Start (Sr) for subsequent + i2c msgs. + config SYS_I2C_RCAR_I2C bool "Renesas R-Car I2C driver" depends on (RCAR_GEN2 || RCAR_64) && DM_I2C -- 2.48.1
Re: [PATCH 1/5] dm: pwm: Check if duty_ns is lower than period_ns
On 3/6/25 15:13, Patrice CHOTARD wrote: > > > On 3/6/25 11:56, Cheick Traore wrote: >> It was possible to provide a duty_ns greater than period_ns to >> "pwm config" command. The framework must check the values before >> providing them to drivers. >> >> Signed-off-by: Cheick Traore >> --- >> >> drivers/pwm/pwm-uclass.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/pwm/pwm-uclass.c b/drivers/pwm/pwm-uclass.c >> index 6543db1d623..b4491f7dcd4 100644 >> --- a/drivers/pwm/pwm-uclass.c >> +++ b/drivers/pwm/pwm-uclass.c >> @@ -27,6 +27,9 @@ int pwm_set_config(struct udevice *dev, uint channel, uint >> period_ns, >> if (!ops->set_config) >> return -ENOSYS; >> >> +if (duty_ns > period_ns) >> +return -EINVAL; >> + >> return ops->set_config(dev, channel, period_ns, duty_ns); >> } >> > Reviewed-by: Patrice Chotard > > Thanks > Patrice Applied to u-boot-stm32/next Thanks Patrice
Re: [PATCH v2 1/6] net: lwip: extend wget to support CA (root) certificates
[...] > >>> > >> > >> FWIW I think this still makes sense for peopke that don't want or can > >> not add the cert in the u-boot binary, but can add a signed script to > >> download it on the fly > >> > >> Reviewed-by: Ilias Apalodimas > > > > This still stands, but there are a few warning/errors on the entire > > patchset. Can you address them and send a v3? > > Which warnings/errors? Which config? I see none with > qemu_arm64_lwip_defconfig. Ah my bad, it's checkpatch that has all that Cheers /Ilias > > Thanks, > -- > Jerome > > > > > Thanks > > /Ilias
[RESEND PATCH 1/3] pci_auto: Downgrade prefetch if necessary
Legacy PCI devices, like qemu's Bochs VGA device, are allowed to have prefetchable 32-bit BARs, while PCIe devices are not allowed to have 32-bit prefetchable BARs. Typically prefetchable BARs are 64-bit and typically the prefetch MMIO window is also 64-bit and placed above 4GiB, as it's the case on qemu sbsa-ref. Currently the U-Boot code assumes that prefetchable BARs are 64-bit BARs and always tries to assign them into the prefetch MMIO window. When a 32-bit BAR is marked as prefetch, but the prefetch area is not within the first 4GiB of the address space, then downgrade the BAR and place it in the non-prefetch MMIO window. For prefetch BARs there's no downside on being placed in non prefetch MMIO areas, besides the possible slower performance when a driver tries to map it Write-Combine. TEST: Fixes pci_auto on QEMU sbsa-ref fails to autoconfigure BAR0. Signed-off-by: Patrick Rudolph --- drivers/pci/pci_auto.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c index 90f81886445..e68e31a8227 100644 --- a/drivers/pci/pci_auto.c +++ b/drivers/pci/pci_auto.c @@ -107,7 +107,8 @@ static void dm_pciauto_setup_device(struct udevice *dev, } if (prefetch && - (bar_response & PCI_BASE_ADDRESS_MEM_PREFETCH)) + (bar_response & PCI_BASE_ADDRESS_MEM_PREFETCH) && + (found_mem64 || prefetch->bus_lower < 0x1ULL)) bar_res = prefetch; else bar_res = mem; -- 2.48.1
[RESEND PATCH 3/3] emulation: qemu-sbsa: Enable PCI enumeration
Enable PCI enumeration by default to get the Bochs display driver up and running before the boot medium is scanned. This is just to enhance the user-experience while booting the machine. TEST: U-Boot logo, version, log output and the U-Boot shell is visible on the display device. Signed-off-by: Patrick Rudolph --- board/emulation/qemu-sbsa/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/emulation/qemu-sbsa/Kconfig b/board/emulation/qemu-sbsa/Kconfig index f4ad63e681c..728cecae6b3 100644 --- a/board/emulation/qemu-sbsa/Kconfig +++ b/board/emulation/qemu-sbsa/Kconfig @@ -49,6 +49,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply CFI_FLASH imply SYS_MTDPARTS_RUNTIME imply SET_DFU_ALT_INFO + imply PCI_INIT_R if DEBUG_UART -- 2.48.1
Re: [Uboot-stm32] [PATCH 1/5] dm: pwm: Check if duty_ns is lower than period_ns
On 3/10/25 11:00, Patrice CHOTARD wrote: > > > On 3/6/25 15:13, Patrice CHOTARD wrote: >> >> >> On 3/6/25 11:56, Cheick Traore wrote: >>> It was possible to provide a duty_ns greater than period_ns to >>> "pwm config" command. The framework must check the values before >>> providing them to drivers. >>> >>> Signed-off-by: Cheick Traore >>> --- >>> >>> drivers/pwm/pwm-uclass.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/pwm/pwm-uclass.c b/drivers/pwm/pwm-uclass.c >>> index 6543db1d623..b4491f7dcd4 100644 >>> --- a/drivers/pwm/pwm-uclass.c >>> +++ b/drivers/pwm/pwm-uclass.c >>> @@ -27,6 +27,9 @@ int pwm_set_config(struct udevice *dev, uint channel, >>> uint period_ns, >>> if (!ops->set_config) >>> return -ENOSYS; >>> >>> + if (duty_ns > period_ns) >>> + return -EINVAL; >>> + >>> return ops->set_config(dev, channel, period_ns, duty_ns); >>> } >>> >> Reviewed-by: Patrice Chotard >> >> Thanks >> Patrice > Applied to u-boot-stm32/next > > Thanks > Patrice Hi Cheick Unfortunately, this patch is causing U-Boot CI test failed: see https://source.denx.de/u-boot/custodians/u-boot-stm/-/jobs/1054426 More precisely ut_dm_dm_test_cros_ec_pwm, see test/dm/cros_ec_pwm.c Either update test/dm/cros_ec_pwm.c or another solution is simply to clamp duty_ns to period_ns as following ? + if (duty_ns > period_ns) + duty_ns = period_ns; + Patrice > ___ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
Re: [PATCH v2 4/6] net: lwip: add support for built-in root certificates
On Mon, 10 Mar 2025 at 14:13, Jerome Forissier
wrote:
>
>
>
> On 3/10/25 12:52, Ilias Apalodimas wrote:
> > Hi Jerome,
> >
> > [...]
> >
> >
>
> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
> + cacert_initialized = true;
> +#endif
> return CMD_RET_SUCCESS;
> }
> +
> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
> +static int set_cacert_builtin(void)
> +{
> + return _set_cacert(builtin_cacert, builtin_cacert_size);
> +}
> #endif
>
> +#if CONFIG_IS_ENABLED(WGET_CACERT)
> +static int set_cacert(char * const saddr, char * const ssz)
> +{
> + ulong addr, sz;
> +
> + addr = hextoul(saddr, NULL);
> + sz = hextoul(ssz, NULL);
> +
> + return _set_cacert((void *)addr, sz);
> +}
> +#endif
> +#endif /* CONFIG_WGET_CACERT || CONFIG_WGET_BUILTIN_CACERT */
> +
> static int wget_loop(struct udevice *udev, ulong dst_addr, char *uri)
> {
> #if CONFIG_IS_ENABLED(WGET_HTTPS)
> @@ -373,8 +401,15 @@ static int wget_loop(struct udevice *udev, ulong
> dst_addr, char *uri)
> memset(&conn, 0, sizeof(conn));
> #if CONFIG_IS_ENABLED(WGET_HTTPS)
> if (is_https) {
> - char *ca = cacert;
> - size_t ca_sz = cacert_size;
> + char *ca;
> + size_t ca_sz;
> +
> +#if CONFIG_IS_ENABLED(WGET_BUILTIN_CACERT)
> + if (!cacert_initialized)
> + set_cacert_builtin();
> +#endif
> >>>
> >>> The code and the rest of the patch seems fine, but the builtin vs
> >>> downloaded cert is a bit confusing here.
> >>> Since the built-in cert always gets initialized in the wget loop it
> >>> would overwrite any certificates that are downloaded in memory?
> >>
> >> The built-in certs are enabled only when cacert_initialized is false.
> >> set_cacert_builtin() will set it to true (via _set_cacert()), so it will
> >> happen only once. Note also that any successful "wget cacert" command
> >> will also do the same. So effectively these two lines enable the
> >> built-in certificates by default, that's all they do.
> >
> > Ok, so if you download a cert in memory and have u-boot with a builtin
> > certificate, then the memory one will be overwritten in the first run.
>
> No, because the downloaded cert must have be made active via "wget cacert
> ", which will set cacert_initialized to true, and thus the
> built-in certs won't overwrite them. Or did I miss something?
Nop I did, when reading the patch. But should the command that clears
the downloaded cert set cacert_initialized; to false now?
Thanks
/Ilias
>
> Cheers,
> --
> Jerome
>
> > This is not easy to solve, I was trying to think of ways to make the
> > functionality clearer to users.
> >
> > Cheers
> > /Ilias
> >>
> >> Cheers,
> >> --
> >> Jerome
> >>
> >>>
> >>> [...]
> >>>
> >>> Cheers
> >>> /Ilias
[PATCH v3 2/8] efi_loader: expose symbols to be used by the EFI network stack
The following symbols are exposed:
- efi_reinstall_protocol_interface
This is done so that the device path protocol interface
of the network device can be changed internally by u-boot
when a new bootfile gets downloaded.
- eth_set_dev
To support multiple network udevices
- efi_close_event
This comes in preparation to support unregistering
an EFI network device from the EFI network stack when
the underlying U-boot device gets removed
- efi_[dis]connect_controller
The EFI network driver uses ConnectController to add a
NIC to the EFI network stack.
- efi_uninstall_protocol_interface
connect_controler for the efi network driver can install
protocols, which need to be uninstalled in disconnect_controller
- EFI_SIMPLE_NETWORK_PROTOCOL_GUID
Signed-off-by: Adriano Cordova
---
(no changes since v1)
include/efi_loader.h| 17 +
include/net-common.h| 1 +
lib/efi_loader/efi_boottime.c | 21 ++---
lib/efi_loader/efi_net.c| 2 +-
lib/efi_selftest/efi_selftest_snp.c | 1 -
5 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 1d75d97ebbc..6a17a41dbad 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -321,6 +321,8 @@ extern const efi_guid_t efi_guid_host_dev;
#endif
/* GUID of the EFI_BLOCK_IO_PROTOCOL */
extern const efi_guid_t efi_block_io_guid;
+/* GUID of the EFI_SIMPLE_NETWORK_PROTOCOL */
+extern const efi_guid_t efi_net_guid;
extern const efi_guid_t efi_global_variable_guid;
extern const efi_guid_t efi_guid_console_control;
extern const efi_guid_t efi_guid_device_path;
@@ -733,6 +735,10 @@ efi_status_t efi_search_protocol(const efi_handle_t handle,
efi_status_t efi_add_protocol(const efi_handle_t handle,
const efi_guid_t *protocol,
void *protocol_interface);
+/* Uninstall new protocol on a handle */
+efi_status_t efi_uninstall_protocol
+ (efi_handle_t handle, const efi_guid_t *protocol,
+void *protocol_interface, bool preserve);
/* Reinstall a protocol on a handle */
efi_status_t EFIAPI efi_reinstall_protocol_interface(
efi_handle_t handle,
@@ -748,6 +754,15 @@ efi_status_t EFIAPI
efi_install_multiple_protocol_interfaces(efi_handle_t *handle, ...);
efi_status_t EFIAPI
efi_uninstall_multiple_protocol_interfaces(efi_handle_t handle, ...);
+/* Connect and disconnect controller */
+efi_status_t EFIAPI efi_connect_controller(efi_handle_t controller_handle,
+ efi_handle_t *driver_image_handle,
+ struct efi_device_path
*remain_device_path,
+ bool recursive);
+efi_status_t EFIAPI efi_disconnect_controller(
+ efi_handle_t controller_handle,
+ efi_handle_t driver_image_handle,
+ efi_handle_t child_handle);
/* Get handles that support a given protocol */
efi_status_t EFIAPI efi_locate_handle_buffer(
enum efi_locate_search_type search_type,
@@ -768,6 +783,8 @@ efi_status_t efi_create_event(uint32_t type, efi_uintn_t
notify_tpl,
void *context),
void *notify_context, const efi_guid_t *group,
struct efi_event **event);
+/* Call this to close an event */
+efi_status_t EFIAPI efi_close_event(struct efi_event *event);
/* Call this to set a timer */
efi_status_t efi_set_timer(struct efi_event *event, enum efi_timer_delay type,
uint64_t trigger_time);
diff --git a/include/net-common.h b/include/net-common.h
index 29d31f37263..1d507b13b06 100644
--- a/include/net-common.h
+++ b/include/net-common.h
@@ -291,6 +291,7 @@ struct eth_ops {
#define eth_get_ops(dev) ((struct eth_ops *)(dev)->driver->ops)
struct udevice *eth_get_dev(void); /* get the current device */
+void eth_set_dev(struct udevice *dev); /* set a device */
unsigned char *eth_get_ethaddr(void); /* get the current device MAC */
int eth_rx(void); /* Check for received packets */
void eth_halt(void); /* stop SCC */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 5164cb15986..02ad9f7141f 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -60,9 +60,9 @@ static efi_handle_t current_image;
static volatile gd_t *efi_gd, *app_gd;
#endif
-static efi_status_t efi_uninstall_protocol
- (efi_handle_t handle, const efi_guid_t *protocol,
-void
Re: [GIT PULL] Please pull u-boot-dfu-next-20250310
On Mon, 10 Mar 2025 15:06:08 +0100, Mattijs Korpershoek wrote: > Please find the following developments/cleanups for next: > > Usb gadget: > - Remove legacy CONFIG_USB_DEVICE > - Remove legacy usbtty driver > > CI Job: > - https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/25060 > > [...] Merged into u-boot/next, thanks! -- Tom
Re: [PATCH v1] config: falcon: move CFG_SYS_SPI_* to Kconfig
On Mon, Mar 10, 2025 at 10:37 AM Anshul Dalal wrote: > > CFG_SYS_SPI_* are used in falcon boot to specify the offsets and size of > the repsective payloads. This patch moves them to Kconfig keeping the s/repsective/respective > values consistent for each of the effected boards. s/effected/affected > +config SYS_SPI_KERNEL_OFFS > + hex "Falcon mode: address of kernel payload in SPI flash" > + depends on SPL_SPI_FLASH_SUPPORT && SPL_OS_BOOT > + help > +Address within SPI-Flash from where the kernel payload is feteched s/feteched/fetched > +config SYS_SPI_ARGS_OFFS > + hex "Falcon mode: address of args payload in SPI flash" > + depends on SPL_SPI_FLASH_SUPPORT && SPL_OS_BOOT > + help > +Address within SPI-Flash from where the args payload (usually the > +dtb) is feteched in falcon boot. s/feteched/fetched Reviewed-by: Fabio Estevam
Re: [PATCH] spi: cadence_ospi: Add device reset via OSPI controller
On 3/10/25 09:03, Michal Simek wrote:
On 2/20/25 15:19, Venkatesh Yadav Abbarapu wrote:
Add support for flash device reset via OSPI controller
instead of using GPIO, as OSPI IP has device reset
feature on Versal Gen2 platform. Also add compatible
string for Versal Gen2 platform.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/spi/cadence_ospi_versal.c | 19 +++
drivers/spi/cadence_qspi.c | 4
drivers/spi/cadence_qspi.h | 4 +++-
3 files changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/cadence_ospi_versal.c b/drivers/spi/
cadence_ospi_versal.c
index 816916de16d..fbeb0c6a85c 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -204,3 +204,22 @@ void cadence_qspi_apb_enable_linear_mode(bool enable)
~VERSAL_OSPI_LINEAR_MODE, VERSAL_AXI_MUX_SEL);
}
}
+
+int cadence_device_reset(struct udevice *bus)
+{
+ struct cadence_spi_priv *priv = dev_get_priv(bus);
+ u32 reg;
+
+ reg = readl(priv->regbase + CQSPI_REG_CONFIG);
+ reg |= CQSPI_REG_CONFIG_RESET_CFG_FLD_MASK;
+ writel(reg, priv->regbase + CQSPI_REG_CONFIG);
+
+ writel(reg & ~CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK, priv->regbase +
CQSPI_REG_CONFIG);
+ udelay(5);
+ writel(reg | CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK, priv->regbase +
CQSPI_REG_CONFIG);
+ udelay(150);
+ writel(reg & ~CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK, priv->regbase +
CQSPI_REG_CONFIG);
+ udelay(1200);
+
+ return 0;
+}
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 623904ecdad..05356ad2e03 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -251,6 +251,9 @@ static int cadence_spi_probe(struct udevice *bus)
priv->wr_delay = 50 * DIV_ROUND_UP(NSEC_PER_SEC, priv->ref_clk_hz);
+ if (device_is_compatible(bus, "amd,versal2-ospi"))
+ return cadence_device_reset(bus);
+
/* Reset ospi flash device */
return cadence_qspi_flash_reset(bus);
@@ -452,6 +455,7 @@ static const struct dm_spi_ops cadence_spi_ops = {
static const struct udevice_id cadence_spi_ids[] = {
{ .compatible = "cdns,qspi-nor" },
{ .compatible = "ti,am654-ospi" },
+ { .compatible = "amd,versal2-ospi" },
{ }
};
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index 1f9125cd239..d7db37c1463 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -45,6 +45,8 @@
#define CQSPI_REG_CONFIG_CLK_POL BIT(1)
#define CQSPI_REG_CONFIG_CLK_PHA BIT(2)
#define CQSPI_REG_CONFIG_PHY_ENABLE_MASK BIT(3)
+#define CQSPI_REG_CONFIG_RESET_PIN_FLD_MASK BIT(5)
+#define CQSPI_REG_CONFIG_RESET_CFG_FLD_MASK BIT(6)
#define CQSPI_REG_CONFIG_DIRECT BIT(7)
#define CQSPI_REG_CONFIG_DECODE BIT(9)
#define CQSPI_REG_CONFIG_ENBL_DMA BIT(15)
@@ -310,5 +312,5 @@ int cadence_qspi_apb_exec_flash_cmd(void *reg_base,
unsigned int reg);
int cadence_qspi_flash_reset(struct udevice *dev);
ofnode cadence_qspi_get_subnode(struct udevice *dev);
void cadence_qspi_apb_enable_linear_mode(bool enable);
-
+int cadence_device_reset(struct udevice *dev);
This newline is nice. Anyway I have patched it.
#endif /* __CADENCE_QSPI_H__ */
Applied with small change in commit message to spell Versal Gen 2 properly.
CI found build issue for.
phycore_am62ax_a53_defconfig
That's why dropping this patch from my queue and please send v2 of this also
with above changes.
Thanks,
Michal
[PATCH v3 6/8] efi_loader: efi_net: Add device path cache
In preparation to support mutiple efi net udevices. Add a device path
cache to support device paths from multiple ethernet udevices.
The device paths can be added to the cache before EFI gets initialized and
the protocols get installed.
Signed-off-by: Adriano Cordova
---
(no changes since v1)
include/efi_loader.h | 23 +--
lib/efi_loader/efi_bootbin.c | 3 +-
lib/efi_loader/efi_device_path.c | 6 +-
lib/efi_loader/efi_http.c| 2 +-
lib/efi_loader/efi_ipconfig.c| 4 +-
lib/efi_loader/efi_net.c | 268 ++-
lib/efi_loader/efi_setup.c | 5 +-
7 files changed, 252 insertions(+), 59 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 47c043460eb..d387e583f20 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -129,15 +129,17 @@ static inline void efi_set_bootdev(const char *dev, const
char *devnr,
#if CONFIG_IS_ENABLED(NETDEVICES) && CONFIG_IS_ENABLED(EFI_LOADER)
/* Call this to update the current device path of the efi net device */
-efi_status_t efi_net_set_dp(const char *dev, const char *server);
+efi_status_t efi_net_new_dp(const char *dev, const char *server, struct
udevice *udev);
/* Call this to get the current device path of the efi net device */
-void efi_net_get_dp(struct efi_device_path **dp);
+void efi_net_dp_from_dev(struct efi_device_path **dp, struct udevice *udev,
bool cache_only);
void efi_net_get_addr(struct efi_ipv4_address *ip,
struct efi_ipv4_address *mask,
- struct efi_ipv4_address *gw);
+ struct efi_ipv4_address *gw,
+ struct udevice *dev);
void efi_net_set_addr(struct efi_ipv4_address *ip,
struct efi_ipv4_address *mask,
- struct efi_ipv4_address *gw);
+ struct efi_ipv4_address *gw,
+ struct udevice *dev);
efi_status_t efi_net_do_request(u8 *url, enum efi_http_method method, void
**buffer,
u32 *status_code, ulong *file_size, char
*headers_buffer);
#define MAX_HTTP_HEADERS_SIZE SZ_64K
@@ -151,13 +153,16 @@ struct http_header {
void efi_net_parse_headers(ulong *num_headers, struct http_header *headers);
#else
-static inline void efi_net_get_dp(struct efi_device_path **dp) { }
+static inline void efi_net_dp_from_dev(struct efi_device_path **dp,
+ struct udevice *udev, bool cache_only) { }
static inline void efi_net_get_addr(struct efi_ipv4_address *ip,
struct efi_ipv4_address *mask,
-struct efi_ipv4_address *gw) { }
+struct efi_ipv4_address *gw,
+struct udevice *dev) { }
static inline void efi_net_set_addr(struct efi_ipv4_address *ip,
struct efi_ipv4_address *mask,
-struct efi_ipv4_address *gw) { }
+struct efi_ipv4_address *gw,
+struct udevice *dev) { }
#endif
/* Maximum number of configuration tables */
@@ -649,8 +654,8 @@ int efi_disk_create_partitions(efi_handle_t parent, struct
blk_desc *desc,
/* Called by bootefi to make GOP (graphical) interface available */
efi_status_t efi_gop_register(void);
/* Called by bootefi to make the network interface available */
-efi_status_t efi_net_register(void);
-efi_status_t efi_net_do_start(void);
+efi_status_t efi_net_register(struct udevice *dev);
+efi_status_t efi_net_do_start(struct udevice *dev);
/* Called by efi_net_register to make the ip4 config2 protocol available */
efi_status_t efi_ipconfig_register(const efi_handle_t handle,
struct efi_ip4_config2_protocol *ip4config);
diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
index 10ec5e9ada3..deafb2ce1c2 100644
--- a/lib/efi_loader/efi_bootbin.c
+++ b/lib/efi_loader/efi_bootbin.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
static struct efi_device_path *bootefi_image_path;
static struct efi_device_path *bootefi_device_path;
@@ -67,7 +68,7 @@ static efi_status_t calculate_paths(const char *dev, const
char *devnr,
#if IS_ENABLED(CONFIG_NETDEVICES)
if (!strcmp(dev, "Net") || !strcmp(dev, "Http")) {
- ret = efi_net_set_dp(dev, devnr);
+ ret = efi_net_new_dp(dev, devnr, eth_get_dev());
if (ret != EFI_SUCCESS)
return ret;
}
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 64183d40340..c9bf2726fe2 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1048,7 +1048,7 @@ struct efi_device_path *efi_dp_from_http(const char
*server, struct udevice *dev
(!server && IS_ENABLED(CONFIG_NET_
[PATCH v7 7/8] blkmap: add an attribute to preserve the mem mapping
Some blkmap memory mapped devices might have to be be relevant even
after U-Boot passes control to the next image as part of the platform
boot. An example of such a mapping would be an OS installer ISO image,
information for which has to be provided to the OS kernel. Use the
'preserve' attribute for such mappings. The code for adding a pmem
node to the device-tree then checks if this attribute is set, and adds
a node only for mappings which have this attribute.
Signed-off-by: Sughosh Ganu
Reviewed-by: Tobias Waldekranz
Reviewed-by: Ilias Apalodimas
---
Changes since V6: None
cmd/blkmap.c | 9 +++--
drivers/block/blkmap.c| 12
drivers/block/blkmap_helper.c | 2 +-
include/blkmap.h | 4 +++-
4 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/cmd/blkmap.c b/cmd/blkmap.c
index 164f80f1387..86a123b1cd3 100644
--- a/cmd/blkmap.c
+++ b/cmd/blkmap.c
@@ -62,13 +62,18 @@ static int do_blkmap_map_mem(struct map_ctx *ctx, int argc,
char *const argv[])
{
phys_addr_t addr;
int err;
+ bool preserve = false;
if (argc < 2)
return CMD_RET_USAGE;
addr = hextoul(argv[1], NULL);
- err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr);
+ if (argc == 3 && !strcmp(argv[2], "preserve"))
+ preserve = true;
+
+ err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr,
+ preserve);
if (err) {
printf("Unable to map %#llx at block 0x" LBAF ": %d\n",
(unsigned long long)addr, ctx->blknr, err);
@@ -221,7 +226,7 @@ U_BOOT_CMD_WITH_SUBCMDS(
"blkmap create - create device\n"
"blkmap destroy - destroy device\n"
"blkmap maplinear-
device mapping\n"
- "blkmap mapmem - memory mapping\n",
+ "blkmap mapmem [preserve] - memory
mapping\n",
U_BOOT_SUBCMD_MKENT(info, 2, 1, do_blkmap_common),
U_BOOT_SUBCMD_MKENT(part, 2, 1, do_blkmap_common),
U_BOOT_SUBCMD_MKENT(dev, 4, 1, do_blkmap_common),
diff --git a/drivers/block/blkmap.c b/drivers/block/blkmap.c
index 453510cca62..eefed615998 100644
--- a/drivers/block/blkmap.c
+++ b/drivers/block/blkmap.c
@@ -19,6 +19,7 @@ struct blkmap;
/* Attributes of blkmap slice */
#define BLKMAP_SLICE_LINEARBIT(0)
#define BLKMAP_SLICE_MEM BIT(1)
+#define BLKMAP_SLICE_PRESERVE BIT(2)
/**
* struct blkmap_slice - Region mapped to a blkmap
@@ -241,7 +242,7 @@ static void blkmap_mem_destroy(struct blkmap *bm, struct
blkmap_slice *bms)
}
int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
-void *addr, bool remapped)
+void *addr, bool remapped, bool preserve)
{
struct blkmap *bm = dev_get_plat(dev);
struct blkmap_mem *bmm;
@@ -266,6 +267,9 @@ int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
.remapped = remapped,
};
+ if (preserve)
+ bmm->slice.attr |= BLKMAP_SLICE_PRESERVE;
+
err = blkmap_slice_add(bm, &bmm->slice);
if (err)
free(bmm);
@@ -276,11 +280,11 @@ int __blkmap_map_mem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
int blkmap_map_mem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
void *addr)
{
- return __blkmap_map_mem(dev, blknr, blkcnt, addr, false);
+ return __blkmap_map_mem(dev, blknr, blkcnt, addr, false, false);
}
int blkmap_map_pmem(struct udevice *dev, lbaint_t blknr, lbaint_t blkcnt,
- phys_addr_t paddr)
+ phys_addr_t paddr, bool preserve)
{
struct blkmap *bm = dev_get_plat(dev);
struct blk_desc *bd = dev_get_uclass_plat(bm->blk);
@@ -291,7 +295,7 @@ int blkmap_map_pmem(struct udevice *dev, lbaint_t blknr,
lbaint_t blkcnt,
if (!addr)
return -ENOMEM;
- err = __blkmap_map_mem(dev, blknr, blkcnt, addr, true);
+ err = __blkmap_map_mem(dev, blknr, blkcnt, addr, true, preserve);
if (err)
unmap_sysmem(addr);
diff --git a/drivers/block/blkmap_helper.c b/drivers/block/blkmap_helper.c
index bfba14110d2..2f1bc28ee5d 100644
--- a/drivers/block/blkmap_helper.c
+++ b/drivers/block/blkmap_helper.c
@@ -28,7 +28,7 @@ int blkmap_create_ramdisk(const char *label, ulong
image_addr, ulong image_size,
bm = dev_get_plat(bm_dev);
desc = dev_get_uclass_plat(bm->blk);
blknum = image_size >> desc->log2blksz;
- ret = blkmap_map_pmem(bm_dev, 0, blknum, image_addr);
+ ret = blkmap_map_pmem(bm_dev, 0, blknum, image_addr, true);
if (ret) {
log_err("Unable to map %#llx at block %d : %d\n",
(unsigned long long)image_addr, 0, ret);
diff --git a/include/blkmap.h b/include/blkmap.h
index d53095437fa..754d8671b01 100644
--- a/include/blkmap.h
+++ b/include/b
[PATCH v3 3/8] efi_loader: efi_setup: Add efi_start_obj_list() to efi_setup.c
The coomand bootefi calls efi_init_obj_list to do the efi set up
before launching an .efi payload, but efi_init_obj_list is called
only once. There are some initializations which depend on the
environment and should be done each time a payload gets launched and
not only once. A motivation for this changes is the following order
of events:
1. Launch an EFI application (e.g. bootefi hello)
2. Change the ip address
3. Launch another application which uses the pxe protocol
As the EFI pxe protocol was initialized when the handles
for efi net were created in 1., the ip was hardcoded there.
In this example, another possibility would be to make a callback for ip
address changes to go all the way up to efi_net.
Signed-off-by: Adriano Cordova
---
(no changes since v1)
lib/efi_loader/efi_setup.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index aa59bc7779d..164586742ae 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -12,6 +12,7 @@
#include
#include
+#define OBJ_LIST_INITIALIZED 0
#define OBJ_LIST_NOT_INITIALIZED 1
efi_status_t efi_obj_list_initialized = OBJ_LIST_NOT_INITIALIZED;
@@ -208,6 +209,18 @@ out:
return -1;
}
+/**
+ * efi_start_obj_list() - Start EFI object list
+ *
+ * Return: status code
+ */
+static efi_status_t efi_start_obj_list(void)
+{
+ efi_status_t ret = EFI_SUCCESS;
+
+ return ret;
+}
+
/**
* efi_init_obj_list() - Initialize and populate EFI object list
*
@@ -217,7 +230,9 @@ efi_status_t efi_init_obj_list(void)
{
efi_status_t ret = EFI_SUCCESS;
- /* Initialize once only */
+ /* Initialize only once, but start every time if correctly initialized*/
+ if (efi_obj_list_initialized == OBJ_LIST_INITIALIZED)
+ return efi_start_obj_list();
if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
return efi_obj_list_initialized;
@@ -349,6 +364,10 @@ efi_status_t efi_init_obj_list(void)
if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK) &&
!IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY))
ret = efi_launch_capsules();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
+ ret = efi_start_obj_list();
out:
efi_obj_list_initialized = ret;
return ret;
--
2.48.1
[PATCH v3 5/8] efi_loader: efi_device_path: Pass net udevice as argument
In preparation to support multiple EFI net objects, support
constructing device paths using an ethernet device different
than the default. Add a udevice argument to the device path
generation, and keep the callsites with eth_get_dev() to
preserve existing functionality.
Signed-off-by: Adriano Cordova
---
(no changes since v1)
include/efi_loader.h | 4 ++--
lib/efi_loader/efi_device_path.c | 20
lib/efi_loader/efi_net.c | 5 +++--
3 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index c2fb3e66eb9..47c043460eb 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -925,8 +925,8 @@ struct efi_device_path *efi_dp_from_part(struct blk_desc
*desc, int part);
struct efi_device_path *efi_dp_part_node(struct blk_desc *desc, int part);
struct efi_device_path *efi_dp_from_file(const struct efi_device_path *dp,
const char *path);
-struct efi_device_path *efi_dp_from_eth(void);
-struct efi_device_path *efi_dp_from_http(const char *server);
+struct efi_device_path *efi_dp_from_eth(struct udevice *dev);
+struct efi_device_path *efi_dp_from_http(const char *server, struct udevice
*dev);
struct efi_device_path *efi_dp_from_mem(uint32_t mem_type,
uint64_t start_address,
size_t size);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index c0633a736b6..64183d40340 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -954,20 +954,20 @@ struct efi_device_path *efi_dp_from_uart(void)
return buf;
}
-struct efi_device_path __maybe_unused *efi_dp_from_eth(void)
+struct efi_device_path __maybe_unused *efi_dp_from_eth(struct udevice *dev)
{
void *buf, *start;
unsigned dpsize = 0;
- assert(eth_get_dev());
+ assert(dev);
- dpsize += dp_size(eth_get_dev());
+ dpsize += dp_size(dev);
start = buf = efi_alloc(dpsize + sizeof(END));
if (!buf)
return NULL;
- buf = dp_fill(buf, eth_get_dev());
+ buf = dp_fill(buf, dev);
*((struct efi_device_path *)buf) = END;
@@ -984,11 +984,13 @@ struct efi_device_path __maybe_unused
*efi_dp_from_eth(void)
* @ip:IPv4 local address
* @mask: network mask
* @srv: IPv4 remote/server address
+ * @dev: net udevice
* Return: pointer to device path, NULL on error
*/
static struct efi_device_path *efi_dp_from_ipv4(struct efi_ipv4_address *ip,
struct efi_ipv4_address *mask,
-struct efi_ipv4_address *srv)
+struct efi_ipv4_address *srv,
+struct udevice *dev)
{
struct efi_device_path *dp1, *dp2, *pos;
struct {
@@ -1010,7 +1012,7 @@ static struct efi_device_path *efi_dp_from_ipv4(struct
efi_ipv4_address *ip,
pos = &dp.end;
memcpy(pos, &END, sizeof(END));
- dp1 = efi_dp_from_eth();
+ dp1 = efi_dp_from_eth(dev);
if (!dp1)
return NULL;
@@ -1029,9 +1031,10 @@ static struct efi_device_path *efi_dp_from_ipv4(struct
efi_ipv4_address *ip,
* and an END node.
*
* @server:URI of remote server
+ * @dev: net udevice
* Return: pointer to HTTP device path, NULL on error
*/
-struct efi_device_path *efi_dp_from_http(const char *server)
+struct efi_device_path *efi_dp_from_http(const char *server, struct udevice
*dev)
{
struct efi_device_path *dp1, *dp2;
struct efi_device_path_uri *uridp;
@@ -1047,10 +1050,11 @@ struct efi_device_path *efi_dp_from_http(const char
*server)
efi_net_get_addr(&ip, &mask, NULL);
- dp1 = efi_dp_from_ipv4(&ip, &mask, NULL);
+ dp1 = efi_dp_from_ipv4(&ip, &mask, NULL, dev);
if (!dp1)
return NULL;
+
strcpy(tmp, "http://";);
if (server) {
diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index 68051852dd8..ebb7f4afd3c 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -951,6 +951,7 @@ efi_status_t efi_net_register(void)
&netobj->net);
if (r != EFI_SUCCESS)
goto failure_to_add_protocol;
+
if (!net_dp)
efi_net_set_dp("Net", NULL);
r = efi_add_protocol(&netobj->header, &efi_guid_device_path,
@@ -1078,9 +1079,9 @@ efi_status_t efi_net_set_dp(const char *dev, const char
*server)
net_dp = NULL;
if (!strcmp(dev, "Net"))
- net_dp = efi_dp_from_eth();
+ net_dp = efi_dp_from_eth(eth_get_dev());
else if (!strcmp(dev, "Http"))
- net_dp = efi_dp_from_http(server);
+ net_dp = efi_dp_from_http(server, eth_get_dev());
[PATCH v3 7/8] efi_loader: efi_net: Add dhcp cache
Add a dhcp cache to store the DHCP ACKs received by the U-Boot network
stack.
Signed-off-by: Adriano Cordova
---
(no changes since v1)
lib/efi_loader/efi_net.c | 55 +++-
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c
index f65287ad6ab..2fac39ae513 100644
--- a/lib/efi_loader/efi_net.c
+++ b/lib/efi_loader/efi_net.c
@@ -24,12 +24,12 @@
#include
#include
+#define MAX_NUM_DHCP_ENTRIES 10
#define MAX_NUM_DP_ENTRIES 10
const efi_guid_t efi_net_guid = EFI_SIMPLE_NETWORK_PROTOCOL_GUID;
static const efi_guid_t efi_pxe_base_code_protocol_guid =
EFI_PXE_BASE_CODE_PROTOCOL_GUID;
-static struct efi_pxe_packet *dhcp_ack;
static void *new_tx_packet;
static void *transmit_buffer;
static uchar **receive_buffer;
@@ -61,6 +61,15 @@ static struct wget_http_info efi_wget_info = {
};
#endif
+struct dhcp_entry {
+ struct efi_pxe_packet *dhcp_ack;
+ struct udevice *dev;
+ bool is_valid;
+};
+
+static struct dhcp_entry dhcp_cache[MAX_NUM_DHCP_ENTRIES];
+static int next_dhcp_entry;
+
/*
* The notification function of this event is called in every timer cycle
* to check if a new network packet has been received.
@@ -317,6 +326,7 @@ static efi_status_t EFIAPI efi_net_shutdown(struct
efi_simple_network *this)
eth_set_dev(netobj->dev);
env_set("ethact", eth_get_name());
eth_halt();
+
this->int_status = 0;
wait_for_packet->is_signaled = false;
this->mode->state = EFI_NETWORK_STARTED;
@@ -718,18 +728,28 @@ out:
*/
void efi_net_set_dhcp_ack(void *pkt, int len)
{
- int maxsize = sizeof(*dhcp_ack);
+ struct efi_pxe_packet **dhcp_ack;
+ struct udevice *dev;
+
+ dhcp_ack = &dhcp_cache[next_dhcp_entry].dhcp_ack;
+
+ /* For now this function gets called only by the current device */
+ dev = eth_get_dev();
- if (!dhcp_ack) {
- dhcp_ack = malloc(maxsize);
- if (!dhcp_ack)
+ int maxsize = sizeof(**dhcp_ack);
+
+ if (!*dhcp_ack) {
+ *dhcp_ack = malloc(maxsize);
+ if (!*dhcp_ack)
return;
}
- memset(dhcp_ack, 0, maxsize);
- memcpy(dhcp_ack, pkt, min(len, maxsize));
+ memset(*dhcp_ack, 0, maxsize);
+ memcpy(*dhcp_ack, pkt, min(len, maxsize));
- if (netobj)
- netobj->pxe_mode.dhcp_ack = *dhcp_ack;
+ dhcp_cache[next_dhcp_entry].is_valid = true;
+ dhcp_cache[next_dhcp_entry].dev = dev;
+ next_dhcp_entry++;
+ next_dhcp_entry %= MAX_NUM_DHCP_ENTRIES;
}
/**
@@ -1036,7 +1056,7 @@ set_addr:
efi_status_t efi_net_register(struct udevice *dev)
{
efi_status_t r;
- int i;
+ int i, j;
if (!dev) {
/* No network device active, don't expose any */
@@ -1123,8 +1143,19 @@ efi_status_t efi_net_register(struct udevice *dev)
netobj->pxe.set_station_ip = efi_pxe_base_code_set_station_ip;
netobj->pxe.set_packets = efi_pxe_base_code_set_packets;
netobj->pxe.mode = &netobj->pxe_mode;
- if (dhcp_ack)
- netobj->pxe_mode.dhcp_ack = *dhcp_ack;
+
+ /*
+* Scan dhcp entries for one corresponding
+* to this udevice, from newest to oldest
+*/
+ i = (next_dhcp_entry + MAX_NUM_DHCP_ENTRIES - 1) % MAX_NUM_DHCP_ENTRIES;
+ for (j = 0; dhcp_cache[i].is_valid && j < MAX_NUM_DHCP_ENTRIES;
+i = (i + MAX_NUM_DHCP_ENTRIES - 1) % MAX_NUM_DHCP_ENTRIES, j++) {
+ if (dev == dhcp_cache[i].dev) {
+ netobj->pxe_mode.dhcp_ack = *dhcp_cache[i].dhcp_ack;
+ break;
+ }
+ }
/*
* Create WaitForPacket event.
--
2.48.1
Re: [PATCH 11/12] pytest: requirements.txt: Include setuptools
On 3/10/25 10:31 PM, Tom Rini wrote: On Mon, Mar 10, 2025 at 10:07:40PM +0100, Marek Vasut wrote: On 3/10/25 2:55 PM, Tom Rini wrote: On Sat, Mar 08, 2025 at 09:12:15PM +0100, Marek Vasut wrote: This seems to be needed for filesystem tests at least on ubuntu 22.04 machines. Add setuptools into requirements.txt . Signed-off-by: Marek Vasut --- Cc: Baruch Siach Cc: Francesco Dolcini Cc: Heinrich Schuchardt Cc: Hiago De Franco Cc: Ilias Apalodimas Cc: Nam Cao Cc: Simon Glass Cc: Sughosh Ganu Cc: Tom Rini Cc: u-boot@lists.denx.de --- test/py/requirements.txt | 1 + 1 file changed, 1 insertion(+) This belongs in the requirements.txt for the tool that requires setuptools, not pytest. It's also listed as a required host tool / package in doc/builds/gcc.rst. Having just re-created the requirements.txt file, I don't want to add things that will get dropped again the next time. This seems to come from pylibfdt . I can drop this patch too. Thanks. Dropped.
