Re: [PATCH v2 0/2] Change DRAM message and add RAM doc
On Wed, 19 Mar 2025 19:33:25 +0530, Neha Malcom Francis wrote: > This short series is an ongoing effort to make RAM utilization clearer for > easier debugging and understanding of code. Intention is for users to quickly > be able to identify the CONFIGs needed to modify for their RAM usecase. > > Neha Malcom Francis (2): > board_f: Modify DRAM message > doc: memory: Add documentation for system RAM > > [...] Applied to u-boot/master, thanks! [1/2] board_f: Modify DRAM message commit: 7dfe3cdc6c58f428803b0f1698bbd4b283103adf [2/2] doc: memory: Add documentation for system RAM commit: 284ef1bbcefcf3180592ed48f522c79618099bd6 -- Tom
Re: Rate of innovation in the project (Was: Re: Rate of change in the project)
On Mon, Apr 07, 2025 at 10:45:24PM +1200, Simon Glass wrote: > Hi Tom, > > On Mon, 7 Apr 2025 at 10:53, Tom Rini wrote: > > > > On Mon, Apr 07, 2025 at 09:15:42AM +1200, Simon Glass wrote: > > > Hi Tom, > > > > > > On Fri, 4 Apr 2025 at 03:27, Tom Rini wrote: > > > > > > > > On Thu, Apr 03, 2025 at 12:55:38PM +1300, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 3 Apr 2025 at 11:35, Tom Rini wrote: > > > > > > > > > > > > On Thu, Apr 03, 2025 at 08:22:13AM +1300, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Wed, 2 Apr 2025 at 06:18, Tom Rini wrote: > > > > > > > > > > > > > > > > On Wed, Apr 02, 2025 at 04:45:37AM +1300, Simon Glass wrote: > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > On Tue, 1 Apr 2025 at 04:51, Tom Rini > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Mar 28, 2025 at 11:42:20PM +, Simon Glass wrote: > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > On Mon, 10 Mar 2025 at 09:53, Tom Rini > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Mar 07, 2025 at 08:46:31AM -0600, Tom Rini > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Thu, Mar 06, 2025 at 09:10:47AM -0700, Simon Glass > > > > > > > > > > > > > wrote: > > > > > > > > > > > > [snip] > > > > > > > > > > > > > > Again, back to this thread, if you want me to > > > > > > > > > > > > > > migrate things, consider > > > > > > > > > > > > > > applying the sunxi patches as I have described > > > > > > > > > > > > > > above. I will then look > > > > > > > > > > > > > > at the next target for bootstd. But while you hold > > > > > > > > > > > > > > this up, I cannot > > > > > > > > > > > > > > move forward with more bootstd migration. It > > > > > > > > > > > > > > doesn't seem that much to > > > > > > > > > > > > > > ask. > > > > > > > > > > > > > > > > > > > > > > > > > > I will take another look at what's still relevant. > > > > > > > > > > > > > But I believe it's > > > > > > > > > > > > > still blocked on the fact that it changes behavior > > > > > > > > > > > > > and breaks users. > > > > > > > > > > > > > > > > > > > > > > > > In details: > > > > > > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-2-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > > > Now that the underlying BLK problem is resolved, this > > > > > > > > > > > > can just be > > > > > > > > > > > > dropped I believe. Removing the BLK dependency from > > > > > > > > > > > > BOOTSTD can happen > > > > > > > > > > > > when you're supporting a flow that lacks a BLK device > > > > > > > > > > > > entirely. This > > > > > > > > > > > > would be another reminder as to why putting unrelated > > > > > > > > > > > > changes in a > > > > > > > > > > > > series is a problem. > > > > > > > > > > > > > > > > > > > > > > OK, then just don't apply this patch. Problem solved? > > > > > > > > > > > > > > > > > > > > Well, for a hypothetical v6 you would not include it, sure. > > > > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > > > This is fine. > > > > > > > > > > > > > > > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20241113150938.1534931-4-...@chromium.org/ > > > > > > > > > > > > > > > > > > > > > > > > This is not fine. This is also not a sunxi problem. It > > > > > > > > > > > > means that we > > > > > > > > > > > > should drop bootmgr from rockchip, where the conversion > > > > > > > > > > > > has already > > > > > > > > > > > > taken place, and would need to drop it from future > > > > > > > > > > > > conversion too. > > > > > > > > > > > > Neither of which are desirable changes. > > > > > > > > > > > > > > > > > > > > > > Why do you say that? I don't understand how this relates > > > > > > > > > > > to rockchip > > > > > > > > > > > or why we would need to drop bootmgr from that. > > > > > > > > > > > > > > > > > > > > Then you don't have enough of a grasp of the details of the > > > > > > > > > > area you're > > > > > > > > > > trying to solve problems in? Or maybe you need to refresh > > > > > > > > > > yourself on > > > > > > > > > > the details of the area you're trying to work in. > > > > > > > > > > > > > > > > > > Or perhaps there isn't a problem? The sunxi case is special > > > > > > > > > because we > > > > > > > > > have a FEL boothmeth. That isn't present on rockchip, for > > > > > > > > > example. > > > > > > > > > > > > > > > > Again, you seem to have forgotten what the problems with the > > > > > > > > series > > > > > > > > were. > > > > > > > > > > > > > > No, it's just that we disagree on the path forward. > > > > > > > > > > > > Then why did you bring up FEL? That's the part of the migration > > > > > > which is > > > > > > NOT a problem, I keep being reminde
[PATCH v2 26/30] phy: rockchip-inno-usb2: Add support for clkout_ctl_phy
The 480m clk is controlled using regs in the PHY address space and not
in the USB GRF address space on e.g. RK3528 and RK3506.
Add a clkout_ctl_phy usb2phy_reg to handle enable/disable of the 480m
clk on these SoCs.
Signed-off-by: Jonas Karlman
---
v2: New patch
---
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 43 ++-
1 file changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 43f6e020a6a0..f40a86bc9dae 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -40,11 +40,13 @@ struct rockchip_usb2phy_port_cfg {
struct rockchip_usb2phy_cfg {
unsigned int reg;
struct usb2phy_reg clkout_ctl;
+ struct usb2phy_reg clkout_ctl_phy;
const struct rockchip_usb2phy_port_cfg port_cfgs[USB2PHY_NUM_PORTS];
};
struct rockchip_usb2phy {
struct regmap *reg_base;
+ struct regmap *phy_base;
struct clk phyclk;
const struct rockchip_usb2phy_cfg *phy_cfg;
};
@@ -165,6 +167,22 @@ static struct phy_ops rockchip_usb2phy_ops = {
.of_xlate = rockchip_usb2phy_of_xlate,
};
+static void rockchip_usb2phy_clkout_ctl(struct clk *clk, struct regmap **base,
+ const struct usb2phy_reg **clkout_ctl)
+{
+ struct udevice *parent = dev_get_parent(clk->dev);
+ struct rockchip_usb2phy *priv = dev_get_priv(parent);
+ const struct rockchip_usb2phy_cfg *phy_cfg = priv->phy_cfg;
+
+ if (priv->phy_cfg->clkout_ctl_phy.enable) {
+ *base = priv->phy_base;
+ *clkout_ctl = &phy_cfg->clkout_ctl_phy;
+ } else {
+ *base = priv->reg_base;
+ *clkout_ctl = &phy_cfg->clkout_ctl;
+ }
+}
+
/**
* round_rate() - Adjust a rate to the exact rate a clock can provide.
* @clk: The clock to manipulate.
@@ -185,13 +203,14 @@ ulong rockchip_usb2phy_clk_round_rate(struct clk *clk,
ulong rate)
*/
int rockchip_usb2phy_clk_enable(struct clk *clk)
{
- struct udevice *parent = dev_get_parent(clk->dev);
- struct rockchip_usb2phy *priv = dev_get_priv(parent);
- const struct rockchip_usb2phy_cfg *phy_cfg = priv->phy_cfg;
+ const struct usb2phy_reg *clkout_ctl;
+ struct regmap *base;
+
+ rockchip_usb2phy_clkout_ctl(clk, &base, &clkout_ctl);
/* turn on 480m clk output if it is off */
- if (!property_enabled(priv->reg_base, &phy_cfg->clkout_ctl)) {
- property_enable(priv->reg_base, &phy_cfg->clkout_ctl, true);
+ if (!property_enabled(base, clkout_ctl)) {
+ property_enable(base, clkout_ctl, true);
/* waiting for the clk become stable */
usleep_range(1200, 1300);
@@ -208,12 +227,13 @@ int rockchip_usb2phy_clk_enable(struct clk *clk)
*/
int rockchip_usb2phy_clk_disable(struct clk *clk)
{
- struct udevice *parent = dev_get_parent(clk->dev);
- struct rockchip_usb2phy *priv = dev_get_priv(parent);
- const struct rockchip_usb2phy_cfg *phy_cfg = priv->phy_cfg;
+ const struct usb2phy_reg *clkout_ctl;
+ struct regmap *base;
+
+ rockchip_usb2phy_clkout_ctl(clk, &base, &clkout_ctl);
/* turn off 480m clk output */
- property_enable(priv->reg_base, &phy_cfg->clkout_ctl, false);
+ property_enable(base, clkout_ctl, false);
return 0;
}
@@ -281,7 +301,10 @@ static int rockchip_usb2phy_probe(struct udevice *dev)
return ret;
}
- return 0;
+ if (priv->phy_cfg->clkout_ctl_phy.enable)
+ ret = regmap_init_mem_index(dev_ofnode(dev), &priv->phy_base,
0);
+
+ return ret;
}
static int rockchip_usb2phy_bind(struct udevice *dev)
--
2.49.0
Re: [PATCH v4 06/10] rockchip: binman: Use the FIT template in the SPI image
Hi Jonas, Simon, On 3/29/25 4:06 PM, Jonas Karlman wrote: From: Simon Glass At present simple-bin-spi relies on the u-boot.itb file created by the simple-bin image. Use the template to avoid this, since Binman may change to process images in parallel in the future. Signed-off-by: Simon Glass Signed-off-by: Jonas Karlman --- Changes in v4: - Drop filename for the SPI FIT - Split from "VBE serial part H: Implement VBE on Rockchip RK3399" Changes in v3: - Keep the filename for the SPI FIT This is an alternative for the issue reported and fixed in [1] and [2]. [1] https://lore.kernel.org/u-boot/20250129132529.807031-3-na...@radxa.com/ [2] https://lore.kernel.org/u-boot/20250220-has_rom-u-boot-rockchip-spi-bin-v2-3-d1768ee87...@cherry.de/ What about squashing with patch 04/10 ? Reviewed-by: Quentin Schulz Thanks! Quentin
[PATCH v3 5/8] doc: add DeepComputing FML13V01 documentation
Describe building U-Boot for the board and booting. Carve out common information for JH7110 boards into an include. Signed-off-by: Heinrich Schuchardt --- v3: rebased v2: carve out common information for JH7110 boards into an include --- doc/board/starfive/deepcomputing_fml13v01.rst | 80 +++ doc/board/starfive/index.rst | 1 + doc/board/starfive/jh7110_common.rst | 66 +++ 3 files changed, 147 insertions(+) create mode 100644 doc/board/starfive/deepcomputing_fml13v01.rst create mode 100644 doc/board/starfive/jh7110_common.rst diff --git a/doc/board/starfive/deepcomputing_fml13v01.rst b/doc/board/starfive/deepcomputing_fml13v01.rst new file mode 100644 index 000..5d9612483b4 --- /dev/null +++ b/doc/board/starfive/deepcomputing_fml13v01.rst @@ -0,0 +1,80 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +DeepComputing Framework Motherboard (FLM13V01) +== + +The DeepComputing Framework motherboard (FLM13V01) can be combined with a +13 inch Framework laptop chassis to provide a complete laptop. + +U-Boot for the board uses the same binaries as the VisionFive 2 board. +Currently only serial console output is supported by mainline U-Boot. + +Building + + +Setup the cross compilation environment variable: + +.. code-block:: bash + + export CROSS_COMPILE=riscv64-linux-gnu- + +The M-mode software OpenSBI provides the supervisor binary interface (SBI) and +is responsible for the switch to S-Mode. It is a prerequisite for building +U-Boot. Support for the JH7110 was introduced in OpenSBI 1.2. It is recommended +to use a current release. + +.. code-block:: bash + +git clone https://github.com/riscv/opensbi.git +cd opensbi +make PLATFORM=generic FW_TEXT_START=0x4000 FW_OPTIONS=0 +export OPENSBI="$(pwd)/build/platform/generic/firmware/fw_dynamic.bin" + +Now build U-Boot SPL and main U-Boot. + +.. code-block:: bash + +cd +make starfive_visionfive2_defconfig +make + +This will generate the U-Boot SPL image (spl/u-boot-spl.bin.normal.out) as well +as the FIT image (u-boot.itb) with OpenSBI, U-Boot, and device-trees. + +Device-tree selection +- + +The product ID stored in the board EEPROM is used by U-Boot SPL to select the +right configuration and device-tree from the u-boot.itb FIT image. + +Furthermore if variable $fdtfile has not been saved in the environment it is +set based on the product ID to *starfive/jh7110-deepcomputing-fml13v01.dtb*. + +To overrule this default the variable can be set manually and saved in the +environment + +.. code-block:: console + +setenv fdtfile my_device-tree.dtb +env save + +Power switch + + +A tiny power switch is located in right upper corner of the board. + +Open case detection +--- + +The board has an open case detection switch. Red lights will flash and the +board will not boot if the switch is not held down. + +UART + + +UART 0 is exposed via the side channel contacts SBU1 and SBU2 of the lower, +right USB C connector. A USB C cable and a breakout board are needed for +physical access. It depends on the cable orientation on which of SBU1 and SBU2 +you will find RX and TX. The signal voltage is 3.3 V. The baud rate is 115200. + +.. include:: jh7110_common.rst diff --git a/doc/board/starfive/index.rst b/doc/board/starfive/index.rst index 2cba1b6dc56..66abc6f9d98 100644 --- a/doc/board/starfive/index.rst +++ b/doc/board/starfive/index.rst @@ -6,6 +6,7 @@ StarFive .. toctree:: :maxdepth: 1 + deepcomputing_fml13v01 milk-v_mars pine64_star64 visionfive2 diff --git a/doc/board/starfive/jh7110_common.rst b/doc/board/starfive/jh7110_common.rst new file mode 100644 index 000..44ccd612ff4 --- /dev/null +++ b/doc/board/starfive/jh7110_common.rst @@ -0,0 +1,66 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Boot source selection +- + +The board provides DIP switches to select the device for loading the boot +firmware. + +=== === === +Boot source SW1 SW2 +=== === === +UARTOFF OFF +SD-card ON OFF +eMMCOFF ON +SPI flash ON ON +=== === === + +Flashing a new U-Boot version +- + +U-Boot SPL is provided as file spl/u-boot-spl.bin.normal.out. Main U-Boot is +in file u-boot.itb. + +Assuming your new U-Boot version is on partition 1 of an SD-card you could +install it to the SPI flash with: + +.. code-block:: console + +sf probe +load mmc 1:1 $kernel_addr_r u-boot-spl.bin.normal.out +sf update $kernel_addr_r 0 $filesize +load mmc 1:1 $kernel_addr_r u-boot.itb +sf update $kernel_addr_r 0x10 $filesize + +For loading the files from a TFTP server refer to the dhcp and tftpboot +commands. + +After updating U-Boot you may want to erase a saved environment and reboot. + +.. code-block:: console + +env erase +reset + +Boot
Re: [EXT] [PATCH] crypto: fsl - Fix RNG generation for lengths greater than 16 bytes
On 4/9/2025 9:19 AM, Gaurav Jain wrote:
> Hi Pawel
>
>> From: Paweł Kochanowski
>>
>> Hi Gaurav,
>>
>> What we see is that the jr_enqueue() called by run_descriptor_jr() swaps the
>> endianness of the descriptor in place (by modifying the data pointed by
>> desc_add):
>>
>> /* The descriptor must be submitted to SEC block as per endianness
>> * of the SEC Block.
>> * So, if the endianness of Core and SEC block is different, each
>> word
>> * of the descriptor will be byte-swapped.
>> */
>> for (i = 0; i < length; i++) {
>> desc_word = desc_addr[i];
>> sec_out32((uint32_t *)&desc_addr[i], desc_word);
>> }
>>
>> So the sequence looks like this:
>> 1. caam_rng_probe sets correct descriptor in ` caam_rng_priv *priv` 2.
>> caam_rng_read is called with 32B 3. caam_rng_read_one->run_descriptor_jr() is
>> called to generate 16B with `priv->desc` containing valid descriptor 4. The
>> descriptor is swapped in jr_enqueue() before passing it to job ring
>
> I see you are right. In Linux, caam endianness is handled at the time of
> creating the descriptor.
> But In Uboot, caam endianness is not handled at the time of descriptor
> creation.
>
IMO the U-Boot approach is broken.
The handling of endianness must be done at creation time, only then we know
how to interpret the data and perform adequate byteswaps.
U-Boot makes the assumption that everything should be 4-byte swapped,
but there are cases when the swap has to be done 8-byte wide (for example
address pointers or 8-byte immediate data).
> 5. The loop in
>> caam_rng_read is called second time, this time the `priv->desc` contain
>> swapped
>> data.
>>
>> Interesting thing is that the job still succeeds and that some data are
>> present in
>> the buffers, but maybe swapped descriptor can also be a valid one?
> I agree that the descriptor should be reinitialized for each RNG job.
I would advise against this, considering what I said above.
Handling endianness should be done only once.
Regards,
Horia
Re: [PATCH 00/13] board: dragonboard410c: Various fixes and cleanup
On 4/7/25 18:59, Stephan Gerhold wrote: The DB410c U-Boot port has not been updated much lately. This series includes various fixes and cleanup to bring it back into better shape. I've also added myself as new maintainer (and Sam as reviewer), since Ramon has not been active on the U-Boot mailing list for over a year now. Signed-off-by: Stephan Gerhold Thanks for this! Awesome cleanup. Really no other words, this is art :D Reviewed-by: Caleb Connolly > --- Stephan Gerhold (13): mach-snapdragon: Fix EL2 boot on DragonBoard 410c board: dragonboard410c: Fix RAM size board: dragonboard410c: Fix BD address board: dragonboard410c: Drop UNSTUFF_BITS() macro board: dragonboard410c: Drop reflash functionality board: dragonboard410c: Drop unused linux_image board: dragonboard410c: Use dynamically allocated load addresses board: dragonboard410c: Fix counter frequency board: dragonboard410c: Enable RTL8152 ethernet board: dragonboard410c: Use BOOTSTD instead of DISTRO_DEFAULTS board: dragonboard410c: Enable support for Android boot images board: dragonboard410c: Use button_cmd instead of custom code board: dragonboard410c: Update maintainers arch/arm/Kconfig | 2 +- arch/arm/dts/apq8016-sbc-u-boot.dtsi | 2 +- board/qualcomm/dragonboard410c/MAINTAINERS | 3 +- board/qualcomm/dragonboard410c/dragonboard410c.c | 67 +++--- board/qualcomm/dragonboard410c/dragonboard410c.env | 38 ++-- configs/dragonboard410c_defconfig | 10 ++-- include/configs/dragonboard410c.h | 11 7 files changed, 35 insertions(+), 98 deletions(-) --- base-commit: 4b2895adb0ab94fdaabd6c19cef4d72986483461 change-id: 20250407-db410c-fixes-85c6a6de2716 Best regards, -- Caleb (they/them)
Re: [PATCH v4 08/10] rockchip: binman: Use the skip-at-start prop in simple-bin image
Hi Simon,
On 4/9/25 3:22 PM, Simon Glass wrote:
Hi Quentin,
On Wed, 9 Apr 2025 at 04:57, Quentin Schulz wrote:
Hi Jonas, Simon,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
From: Simon Glass
The simple-bin image is normally written to MMC media at block 64, which
is a 32K offset from start of storage media.
Set the skip-at-start property to 0x8000 (32 KiB) so that fdtmap and
other embedded binman symbols in the output binary is referencing image
offsets correctly.
Shouldn't we have this commit BEFORE we add the `fdtmap` node since we
know it's wrong before this commit?
Signed-off-by: Simon Glass
Signed-off-by: Jonas Karlman
---
Changes in v4:
- Drop defconfig changes
- Split from "VBE serial part H: Implement VBE on Rockchip RK3399"
Changes in v2:
- Move this patch to the end of the series
- Drop 0x8000 offset for SPI
---
arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index fb38b7b80c43..65b81bf58626 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -154,6 +154,7 @@
simple-bin {
filename = "u-boot-rockchip.bin";
pad-byte = <0xff>;
+ skip-at-start = <0x8000>;
mkimage {
filename = "idbloader.img";
@@ -178,7 +179,7 @@
#else
u-boot-img {
#endif
- offset = ;
+ offset = <(CONFIG_SPL_PAD_TO + 0x8000)>;
This is confusing. The documentation states:
"""
offset:
This sets the offset of an entry within the image or section containing
it.
"""
My understanding is that it should be relative to the beginning of the
image but this now needs the knowledge of where it will be stored on the
MMC device (via the value in skip-at-start).
Why is skip-at-start automatically deducted from offset?
This is how binman works[1]. We are trying to use the feature designs
Why is it deducted?
Cheers,
Quentin
Re: [PATCH v4 08/10] rockchip: binman: Use the skip-at-start prop in simple-bin image
Hi Quentin,
On Wed, 9 Apr 2025 at 07:32, Quentin Schulz wrote:
>
> Hi Simon,
>
> On 4/9/25 3:22 PM, Simon Glass wrote:
> > Hi Quentin,
> >
> > On Wed, 9 Apr 2025 at 04:57, Quentin Schulz
> > wrote:
> >>
> >> Hi Jonas, Simon,
> >>
> >> On 3/29/25 4:06 PM, Jonas Karlman wrote:
> >>> From: Simon Glass
> >>>
> >>> The simple-bin image is normally written to MMC media at block 64, which
> >>> is a 32K offset from start of storage media.
> >>>
> >>> Set the skip-at-start property to 0x8000 (32 KiB) so that fdtmap and
> >>> other embedded binman symbols in the output binary is referencing image
> >>> offsets correctly.
> >>>
> >>
> >> Shouldn't we have this commit BEFORE we add the `fdtmap` node since we
> >> know it's wrong before this commit?
> >>
> >>> Signed-off-by: Simon Glass
> >>> Signed-off-by: Jonas Karlman
> >>> ---
> >>> Changes in v4:
> >>> - Drop defconfig changes
> >>> - Split from "VBE serial part H: Implement VBE on Rockchip RK3399"
> >>>
> >>> Changes in v2:
> >>> - Move this patch to the end of the series
> >>> - Drop 0x8000 offset for SPI
> >>> ---
> >>>arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
> >>>1 file changed, 2 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
> >>> b/arch/arm/dts/rockchip-u-boot.dtsi
> >>> index fb38b7b80c43..65b81bf58626 100644
> >>> --- a/arch/arm/dts/rockchip-u-boot.dtsi
> >>> +++ b/arch/arm/dts/rockchip-u-boot.dtsi
> >>> @@ -154,6 +154,7 @@
> >>>simple-bin {
> >>>filename = "u-boot-rockchip.bin";
> >>>pad-byte = <0xff>;
> >>> + skip-at-start = <0x8000>;
> >>>
> >>>mkimage {
> >>>filename = "idbloader.img";
> >>> @@ -178,7 +179,7 @@
> >>>#else
> >>>u-boot-img {
> >>>#endif
> >>> - offset = ;
> >>> + offset = <(CONFIG_SPL_PAD_TO + 0x8000)>;
> >>
> >> This is confusing. The documentation states:
> >>
> >> """
> >> offset:
> >> This sets the offset of an entry within the image or section
> >> containing
> >> it.
> >> """
> >>
> >> My understanding is that it should be relative to the beginning of the
> >> image but this now needs the knowledge of where it will be stored on the
> >> MMC device (via the value in skip-at-start).
> >>
> >> Why is skip-at-start automatically deducted from offset?
> >
> > This is how binman works[1]. We are trying to use the feature designs
>
> Why is it deducted?
Are you asking why skip-at-start is deducted from the offset?
Regards,
Simon
[PATCH v2] common: Add CONFIG_SKIP_RELOCATE
Add a check for CONFIG_SKIP_RELOCATE in reserve_uboot to skip the
relocation of the U-Boot image.
CONFIG_SKIP_RELOCATE skips relocation of U-Boot to the end of RAM
allowing for systems that have extremely limited RAM to run U-Boot.
Signed-off-by: Jesse Taube
Reviewed-by: Tom Rini
Reviewed-by: Caleb Connolly
---
V1 -> V2:
- Drop "default n"
- s/ram/RAM/g
---
Kconfig | 6 ++
common/board_f.c | 7 +++
2 files changed, 13 insertions(+)
diff --git a/Kconfig b/Kconfig
index 6379a454166..1b35ddc36a3 100644
--- a/Kconfig
+++ b/Kconfig
@@ -443,6 +443,12 @@ config TOOLS_DEBUG
it is possible to set breakpoints on particular lines, single-step
debug through the source code, etc.
+config SKIP_RELOCATE
+ bool "Skips relocation of U-Boot to end of RAM"
+ help
+ Skips relocation of U-Boot allowing for systems that have extremely
+ limited RAM to run U-Boot.
+
endif # EXPERT
config PHYS_64BIT
diff --git a/common/board_f.c b/common/board_f.c
index 99616fdac80..d51696b8eda 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -476,6 +476,13 @@ static int reserve_trace(void)
static int reserve_uboot(void)
{
+ /*
+* This should be the first place GD_FLG_SKIP_RELOC is read from.
+* Set GD_FLG_SKIP_RELOC flag if CONFIG_SKIP_RELOCATE is enabled.
+*/
+ if (CONFIG_IS_ENABLED(SKIP_RELOCATE))
+ gd->flags |= GD_FLG_SKIP_RELOC;
+
if (!(gd->flags & GD_FLG_SKIP_RELOC)) {
/*
* reserve memory for U-Boot code, data & bss
--
2.49.0
[PATCH] arm: mach-k3: am62ax: fix MCU_CLKOUT0 parent clock mux
Much like what was fixed on the AM62x and AM62Px platforms[0]. The
CU_CLKOUT0 has two (25mhz and 50mhz) mux options however the clock
structure incorrectly duplicated the first 50mhz option twice. Fix this
for the AM62A platforms so the 25mhz option is selectable.
[0] https://lore.kernel.org/all/20250408161211.3165588-1-parth105...@gmail.com/
Reported-by: Parth Pancholi
Signed-off-by: Bryan Brattlof
---
arch/arm/mach-k3/r5/am62ax/clk-data.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/r5/am62ax/clk-data.c
b/arch/arm/mach-k3/r5/am62ax/clk-data.c
index d950b35e0beb7..85b39a0655add 100644
--- a/arch/arm/mach-k3/r5/am62ax/clk-data.c
+++ b/arch/arm/mach-k3/r5/am62ax/clk-data.c
@@ -64,7 +64,7 @@ static const char * const
sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
static const char * const clkout0_ctrl_out0_parents[] = {
"hsdiv4_16fft_main_2_hsdivout1_clk",
- "hsdiv4_16fft_main_2_hsdivout1_clk",
+ "hsdiv4_16fft_main_2_hsdivout1_clk10",
};
static const char * const main_emmcsd0_refclk_sel_out0_parents[] = {
@@ -180,6 +180,7 @@ static const struct clk_data clk_list[] = {
CLK_DIV("hsdiv4_16fft_main_1_hsdivout1_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681084, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_1_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_1_foutvcop_clk", 0x681088, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_2_hsdivout1_clk",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682084, 0, 7, 0, 0),
+ CLK_DIV("hsdiv4_16fft_main_2_hsdivout1_clk10",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682084, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_main_2_hsdivout2_clk",
"pllfracf_ssmod_16fft_main_2_foutvcop_clk", 0x682088, 0, 7, 0, 0),
CLK_DIV("hsdiv4_16fft_mcu_0_hsdivout0_clk",
"pllfracf_ssmod_16fft_mcu_0_foutvcop_clk", 0x4040080, 0, 7, 0, 0),
CLK_MUX_PLLCTRL("sam62_pll_ctrl_wrap_main_0_sysclkout_clk",
sam62_pll_ctrl_wrap_main_0_sysclkout_clk_parents, 2, 0x41, 0),
@@ -272,7 +273,7 @@ static const struct dev_clk soc_dev_clk_data[] = {
DEV_CLK(146, 5, "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(157, 20, "clkout0_ctrl_out0"),
DEV_CLK(157, 21, "hsdiv4_16fft_main_2_hsdivout1_clk"),
- DEV_CLK(157, 22, "hsdiv4_16fft_main_2_hsdivout1_clk"),
+ DEV_CLK(157, 22, "hsdiv4_16fft_main_2_hsdivout1_clk10"),
DEV_CLK(157, 24, "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk"),
DEV_CLK(157, 25, "board_0_ddr0_ck0_out"),
DEV_CLK(157, 40, "mshsi2c_main_0_porscl"),
---
base-commit: 9d9fbdab0e9664bff147109cc89ad2786f6ecd83
change-id: 20250409-r5-eth-fix-10ffe90a9eb5
Best regards,
--
Bryan Brattlof
Re: Issue with booting FIT image using Yocto with raspberry pi cm4
Hello Christopher,
Thanks for your suggestion, I tried to apply the patches (last one I had
some issues with, as it did not apply directly on scarthgap branch). Still
has similar boot issues
with the fitImage (inflate error -3).
Some questions:
- Is the default uboot load and entry address 0x0008 reasonable (also
load/entry for the kernel), or might it need adjustment?
- Could it be that the CONFIG_SYS_BOOTM_LEN needs adjustment to handle the
decompress kernel size?
Many thanks,
Andreas Enbacka
On Wed, Apr 9, 2025 at 11:34 AM Christopher Obbard <
christopher.obb...@linaro.org> wrote:
> Hi Andreas,
>
> Can you please try with this series from Simon?
> https://lore.kernel.org/u-boot/20241220003447.2913443-1-...@chromium.org/
> It solved booting mainline kernel on CM4 for me (albeit not with FIT
> images).
>
>
> Thanks,
>
> Chris
>
> On Tue, 8 Apr 2025 at 19:23, Andreas Enbacka wrote:
> >
> > Hello everyone,
> >
> > I am working on building a custom image targeting the raspberry pi cm4
> > using Yocto / meta-raspberrypi (scarthgap release) and u-boot.
> >
> > The kernel and rootfs booted without issues before switching to using fit
> > image. I build the yocto image with kernel type / class set to fitImage.
> > For building u-boot I have specified e.g., CONFIG_FIT=y and similar
> > parameters.
> >
> > When booting the board, u-boot loads the fitImage (around 10MB in size)
> and
> > shows the kernel / device tree blob info (kernel is gzip compressed).
> > However, the process fails when u-boot executes "Uncompressing kernel..",
> > with Error: inflate() returned -3. This leads to a boot loop.
> >
> > I tried manually executing
> > 'load mmc 0:1 ${kernel_addr_r} fitImage; bootm
> > ${kernel_addr_r}#conf-bcm-2711-rpi-4-b.dtb', but it results in same
> error.
> >
> > The kernel_addr_r is set as 0x0008.
> >
> > Any information about this would be greatly appreciated.
> >
> > Best regards,
> > Andreas Enbacka
>
Re: [PATCH] RFC: ext4: Add a few overflow checks in the writing code
On Wed, Apr 09, 2025 at 03:02:37PM -0600, Simon Glass wrote: > From: Simon Glass > > Some memory allocations make use of data from the disk, so add some > overflow checks. > > Adjust LOG2_BLOCK_SIZE() so it is easier to read. > > Note: This is a trial to help figure out the best way to deal with these > sorts of things. Feedback welcome. > > Signed-off-by: Simon Glass > --- > > fs/ext4/ext4_write.c | 24 > include/ext_common.h | 3 +-- > 2 files changed, 21 insertions(+), 6 deletions(-) I'd like to see us grab the current include/linux/overflow.h from the Linux kernel and make use of that rather than further call the built-ins directly. But yes, we should do something here in general. -- Tom signature.asc Description: PGP signature
Re: [PATCH 05/18] net/net: fix switch/case fallthrough annotations
On Wed, Apr 09, 2025 at 11:41:37AM +0100, Andre Przywara wrote:
> On Tue, 8 Apr 2025 19:46:46 -0600
> Tom Rini wrote:
>
> Hi Tom,
>
> > On Wed, Apr 09, 2025 at 12:53:47AM +0100, Andre Przywara wrote:
> > > On Tue, 8 Apr 2025 16:29:18 -0600
> > > Tom Rini wrote:
> > >
> > > Hi Tom,
> > >
> > > thanks for staying on this!
> > >
> > > > On Thu, Mar 27, 2025 at 03:33:00PM +, Andre Przywara wrote:
> > > >
> > > > > The net_check_prereq() routine in the generic network handling code
> > > > > mixes case: labels with #ifdef's, which makes predicting fallthrough
> > > > > situations tricky. We had two "fall through" comments in the code, but
> > > > > at the wrong places.
> > > > >
> > > > > Remove one unneeded comment (no annotations necessary between just
> > > > > empty
> > > > > labels), and move one other instance to the right place (before any
> > > > > label sequence).
> > > > > This makes GCC's implicit fallthrough checker happy.
> > > > >
> > > > > Signed-off-by: Andre Przywara
> > > > > Reviewed-by: Tom Rini
> > > > > ---
> > > > > net/net.c | 3 +--
> > > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/net/net.c b/net/net.c
> > > > > index 5219367e391..f191f16357c 100644
> > > > > --- a/net/net.c
> > > > > +++ b/net/net.c
> > > > > @@ -1525,7 +1525,6 @@ static int net_check_prereq(enum proto_t
> > > > > protocol)
> > > > > #if defined(CONFIG_CMD_NFS)
> > > > > case NFS:
> > > > > #endif
> > > > > - /* Fall through */
> > > > > case TFTPGET:
> > > > > case TFTPPUT:
> > > > > if (IS_ENABLED(CONFIG_IPV6) && use_ip6) {
> > > > > @@ -1539,11 +1538,11 @@ static int net_check_prereq(enum proto_t
> > > > > protocol)
> > > > > puts("*** ERROR: `serverip' not set\n");
> > > > > return 1;
> > > > > }
> > > > > + fallthrough;
> > > > > #if defined(CONFIG_CMD_PING) || \
> > > > > defined(CONFIG_CMD_DNS) || defined(CONFIG_PROT_UDP)
> > > > > common:
> > > > > #endif
> > > > > - /* Fall through */
> > > > >
> > > > > case NETCONS:
> > > > > case FASTBOOT_UDP:
> > > >
> > > > So this one is harder than it looks. With clang, we cannot seemingly
> > > > have:
> > > > fallthrough;
> > > > #if defined(CONFIG_CMD_PING) || \
> > > > defined(CONFIG_CMD_DNS) || defined(CONFIG_PROT_UDP)
> > > > common:
> > > > #endif
> > > >
> > > > And gcc was failing on:
> > > > }
> > > > #if defined(CONFIG_CMD_PING) || \
> > > > defined(CONFIG_CMD_DNS) || defined(CONFIG_PROT_UDP)
> > > > common:
> > > > #endif
> > > > fallthrough;
> > >
> > > Yes, later stages of the CI told me so already ;-)
> > >
> > > > Maybe we can move the label to inside the next set of cases, and then
> > > > also add CONFIG_CMD_PING6 to the checks, as that also has 'goto
> > > > common;'
> > >
> > > I found some other solution: dropping the #if's around the common:
> > > label, then marking this with __maybe_unused instead. Seems to work for
> > > both GCC and clang, and makes the code even more readable.
> > >
> > > Will send this among the other gazillion fixes I meanwhile added in a
> > > v2, to a mailbox near you.
> > > If you can't wait: sunxi/fallthrough has the bits, though not yet split
> > > up and without commit messages. Still not passing all checks, but the
> > > CI builds seem to stop early, before revealing all issues, so this is a
> > > piecemeal job :-(
> >
> > I thought I had tried what you suggest but maybe didn't quite get things
> > aligned right (but I also modified sandbox so it would trigger the
> > unused warning). That said, I'm applying most of v1 now'ish, and have
> > only stopped as part of trying to narrow down the seemingly random
> > evb-ast2600 CI failure.
>
> Can you hold back with this patch here for now? I will send my new version
> of this one later, which passes more CI. I didn't find more overlaps
> between this and my new series, so I wonder if you could apply what you
> think is ready from this one (definitely minus this patch, but maybe
> others), and then I send another series with new fixes plus what's left
> from this one. This would avoid me sending a v2 of this just because of
> this one patch.
I'm planning on applying everything except this one, and 18/18
currently, so that works yes?
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v4 09/10] rockchip: binman: Support use of crc32 for SPL_FIT_SIGNATURE
Hi Quentin,
On 2025-04-09 13:06, Quentin Schulz wrote:
> Hi Jonas,
>
> On 3/29/25 4:06 PM, Jonas Karlman wrote:
>> Use of SHA256 checksum validation on ARMv7 SoCs can be very time
>> consuming compared to ARMv8 SoCs with Crypto Extensions.
>>
>> Add support for use of the crc32 hash algo when SHA256 is not supported.
>> Also use a HAS_HASH to simplify the ifdefs when no known hash algo is
>> compiled.
>>
>> Signed-off-by: Jonas Karlman
>
> I don't know enough about general security but this very much looks like
> a bad idea to me.
>
> https://web.archive.org/web/20170210173741/http://www.derkeiler.com/Newsgroups/sci.crypt/2003-07/1451.html
>
> """
> While properly designed CRC's are good at detecting random errors in
> the data (due to e.g. line noise), the CRC is useless as a secure
> indicator of intentional manipulation of the data. And this is
> because it's not hard at all to modify the data to produce any CRC
> you desire (e.g. the same CRC as the original data, to try to
> disguise your data manipulation).
> """
>
> (yes I took the "first" link my web search engine returned me, thanks
> confirmation bias!).
I am fully aware, and the fallback to use crc32, and current primarily
use of sha256, should not be considered a security feature. It is
intended purely for a checksum validation of the binary blob after it
has been loaded into memory and before U-Boot otherwise unconditionally
jumps to and execute the loaded blob of binary code.
>
> I don't want to give people a false sense of security. If it really
> comes down to it, I'd rather have an explicit Kconfig symbol to set this
> value (maybe have a `choice` even) and be very clear about security
> implications.
Prior to the addition of the hash { algo=sha256 }, there was no checksum
test and U-Boot SPL would unconditionally jump to the loaded data, even
if it had been corrupted, was only halfway written or otherwise
overwritten.
The addition of crc32 instead of sha256 is just to allow older board
variants with weaker SoCs to at least have some sort of checksum
validation in use without affecting the boot time too much.
On my rk3228 board, validation using sha256 could take a few seconds,
and with crc32 it could be measured in ms.
To me, having at least some default checksum validation is preferred
over none at all.
Regards,
Jonas
>
> Cheers,
> Quentin
[PATCH RFC 2/4] lib: rsa: use FIT_ALGO_PROP constant instead of "algo" in FIT
From: Quentin Schulz
Some FIT image properties have their string represented in
include/image.h via constants. FIT_ALGO_PROP does exist and would fit the
bill so let's use it instead of using a hardcoded string.
Signed-off-by: Quentin Schulz
---
lib/rsa/rsa-verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index
4a0418a75f18e21e80612240aa626c0a240bc38c..e92767baae9bdac8bcaad41202f28e1fa6c23cf9
100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -448,7 +448,7 @@ static int rsa_verify_with_keynode(struct image_sign_info
*info,
return -EBADF;
}
- algo = fdt_getprop(blob, node, "algo", NULL);
+ algo = fdt_getprop(blob, node, FIT_ALGO_PROP, NULL);
if (!algo) {
debug("%s: Missing 'algo' property\n", __func__);
return -EFAULT;
--
2.49.0
Re: [PATCH v4 09/10] rockchip: binman: Support use of crc32 for SPL_FIT_SIGNATURE
Hi Jonas,
On 4/9/25 5:38 PM, Jonas Karlman wrote:
Hi Quentin,
On 2025-04-09 13:06, Quentin Schulz wrote:
Hi Jonas,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
Use of SHA256 checksum validation on ARMv7 SoCs can be very time
consuming compared to ARMv8 SoCs with Crypto Extensions.
Add support for use of the crc32 hash algo when SHA256 is not supported.
Also use a HAS_HASH to simplify the ifdefs when no known hash algo is
compiled.
Signed-off-by: Jonas Karlman
I don't know enough about general security but this very much looks like
a bad idea to me.
https://web.archive.org/web/20170210173741/http://www.derkeiler.com/Newsgroups/sci.crypt/2003-07/1451.html
"""
While properly designed CRC's are good at detecting random errors in
the data (due to e.g. line noise), the CRC is useless as a secure
indicator of intentional manipulation of the data. And this is
because it's not hard at all to modify the data to produce any CRC
you desire (e.g. the same CRC as the original data, to try to
disguise your data manipulation).
"""
(yes I took the "first" link my web search engine returned me, thanks
confirmation bias!).
I am fully aware, and the fallback to use crc32, and current primarily
use of sha256, should not be considered a security feature. It is
intended purely for a checksum validation of the binary blob after it
has been loaded into memory and before U-Boot otherwise unconditionally
jumps to and execute the loaded blob of binary code.
I don't want to give people a false sense of security. If it really
comes down to it, I'd rather have an explicit Kconfig symbol to set this
value (maybe have a `choice` even) and be very clear about security
implications.
Prior to the addition of the hash { algo=sha256 }, there was no checksum
test and U-Boot SPL would unconditionally jump to the loaded data, even
if it had been corrupted, was only halfway written or otherwise
overwritten.
The addition of crc32 instead of sha256 is just to allow older board
variants with weaker SoCs to at least have some sort of checksum
validation in use without affecting the boot time too much.
On my rk3228 board, validation using sha256 could take a few seconds,
and with crc32 it could be measured in ms.
To me, having at least some default checksum validation is preferred
over none at all.
Except if this confuses people into thinking they have a secure system
except they use CRC32 instead of something more appropriate like SHA256.
It seems like the "hash" node presence doesn't mean a FIT conf or image
node is signed. I also don't see many device trees with a signature
node... which is kinda odd. Looking a bit into the signature node in the
spec and binman tests, it's not clear to me if the hash node is reused
by the signature node if if exists and if their algo should match and
what exactly is checked by the signature node (like signing the hash
string contained in the hash node(s) listed in sign-images property, or
(re-)generating a hash of those and signing it at build time?
If
a) it is not possible to have a hash node's algo differ from a signature
node's algo, then I'm fine with this as crc32 won't be allowed
b) the signature node regenerates a hash regardless of the hash in the
hash node, meaning the signature will be "appropriately secure"
regardless of the algorithm listed in the hash node, then I'm fine with
it too,
c) it is possible to sign a crc32 hash, don't want it :)
@Simon, do you have some hints about this?
Cheers,
Quentin
Re: [PATCH v4 07/10] rockchip: binman: Include a compatible string in each configuration
Hi Quentin, On Wed, 9 Apr 2025 at 04:03, Quentin Schulz wrote: > > Hi Jonas, Simon, > > On 3/29/25 4:06 PM, Jonas Karlman wrote: > > From: Simon Glass > > > > Provide a compatible string in the config nodes that U-Boot can use to > > help decide which configuration to use. > > > > Can you tell us more about this? See [1] > > I don't think mkimage -l/dumpimage -l actually provide that information > and the docs are sparse as to what "so that things work correctly with > FIT's configuration-matching algortihm." means. > > Looking a bit into tools/binman/ftest.py it seems like it's a way to > expose the DT compatible property from within the first entry in `fdt` > array property (a DTB) into the configuration node in the fit image. Yes, the root compatible string is how we decide which devicetree to use. > > I think it'd make sense to update dumpimage/mkimage/etc... to dump that > information as well? Yes, I think that might be useful > > Reviewed-by: Quentin Schulz > > Thanks! > Quentin [1] https://fitspec.osfw.foundation/#configuration-nodes
Re: [PATCH 2/2] riscv: Provide __image_copy_{start_end} symbols in linkerscript
Hi Yao,
On Tue, 8 Apr 2025 at 03:32, Yao Zi wrote:
>
> On Mon, Apr 07, 2025 at 01:10:32PM +0200, Jonas Karlman wrote:
> > Hi,
> >
> > On 2025-04-07 05:37, Yao Zi wrote:
> > > Binman looks for __image_copy_start to determine the base address of an
> > > entry if elf-base-sym isn't specified, which is missing in RISC-V port.
> > > This causes binman skips RISC-V SPL entries without filling addresses
> > > into its .binman_sym_table section.
> > >
> > > This patch defines __image_copy_start in linkerscript of both SPL and
> > > proper U-Boot to ensure binman_sym functions correctly with the default
> > > binman.dtsi. The paired symbol, __image_copy_end, is introduced as well
> > > for completeness.
> > >
> > > Signed-off-by: Yao Zi
> > > ---
> > > arch/riscv/cpu/u-boot-spl.lds | 2 ++
> > > arch/riscv/cpu/u-boot.lds | 3 +++
> > > 2 files changed, 5 insertions(+)
> > >
> > > diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
> > > index 907094620bd..18eb62c01c6 100644
> > > --- a/arch/riscv/cpu/u-boot-spl.lds
> > > +++ b/arch/riscv/cpu/u-boot-spl.lds
> > > @@ -16,6 +16,7 @@ ENTRY(_start)
> > > SECTIONS
> > > {
> > > . = ALIGN(4);
> > > + __image_copy_start = ADDR(.text);
> > > .text : {
> > > arch/riscv/cpu/start.o (.text)
> > > *(.text*)
> > > @@ -46,6 +47,7 @@ SECTIONS
> > >
> > > _end = .;
> > > _image_binary_end = .;
> > > + _image_copy_end = .;
> >
> > This looks like a typo, should probably be with two _ ?
>
> Yes, thanks for catching this. I'll correct it and apply Simon's tag in
> v2. Simon, is it okay for you?
Yes.
Regards,
Simon
Re: [PATCH 0/5] patman: Separate gitutil fully
Hi Tom, On Tue, 8 Apr 2025 at 16:13, Tom Rini wrote: > > On Mon, Apr 07, 2025 at 10:51:42PM +1200, Simon Glass wrote: > > > > > The gitutil module uses Patman's settings module, which is not allowed > > as it is supposed to be a separate package. This series ties up this > > dependency. > > > > This series depends on these two patches being applied: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250227192735.406389-1-...@chromium.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20250328130225.2607974-1-...@chromium.org/ > > > > > > Simon Glass (5): > > patman: Untangle settings from gitutil > > patman: Pass the alias dict into gitutil.build_email_list() > > patman: Pass the alias dict into gitutil.email_patches() > > patman: Pass aliases to Series.MakeCcFile() > > patman: Update Series.ShowActions() to pass alias > > > > tools/patman/control.py | 11 --- > > tools/patman/func_test.py | 8 > > tools/patman/series.py| 32 ++-- > > tools/u_boot_pylib/gitutil.py | 34 ++ > > 4 files changed, 48 insertions(+), 37 deletions(-) > > I just want to reiterate my question / request to host these outside of > the U-Boot sources themselves so they can be managed (both in the sense > of U-Boot as user and as maintainer of sources) following normal Python > best practices? I'd be fine even with something under > https://source.denx.de/u-boot//patman, etc. Yes I am working towards that. This series cleans up something missed in the last series. After this series there is really just 'patchstream' left, which is used by buildman and patman. I haven't quite come to terms with the idea of moving it to u_boot_pylib yet. What are the best practices you are referring to? As to location, I can keep it in my tree and just delete it from yours if you like. Regards, Simon
Re: [PATCH v4 08/10] rockchip: binman: Use the skip-at-start prop in simple-bin image
Hi Simon,
On 4/9/25 3:33 PM, Simon Glass wrote:
Hi Quentin,
On Wed, 9 Apr 2025 at 07:32, Quentin Schulz wrote:
Hi Simon,
On 4/9/25 3:22 PM, Simon Glass wrote:
Hi Quentin,
On Wed, 9 Apr 2025 at 04:57, Quentin Schulz wrote:
Hi Jonas, Simon,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
From: Simon Glass
The simple-bin image is normally written to MMC media at block 64, which
is a 32K offset from start of storage media.
Set the skip-at-start property to 0x8000 (32 KiB) so that fdtmap and
other embedded binman symbols in the output binary is referencing image
offsets correctly.
Shouldn't we have this commit BEFORE we add the `fdtmap` node since we
know it's wrong before this commit?
Signed-off-by: Simon Glass
Signed-off-by: Jonas Karlman
---
Changes in v4:
- Drop defconfig changes
- Split from "VBE serial part H: Implement VBE on Rockchip RK3399"
Changes in v2:
- Move this patch to the end of the series
- Drop 0x8000 offset for SPI
---
arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index fb38b7b80c43..65b81bf58626 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -154,6 +154,7 @@
simple-bin {
filename = "u-boot-rockchip.bin";
pad-byte = <0xff>;
+ skip-at-start = <0x8000>;
mkimage {
filename = "idbloader.img";
@@ -178,7 +179,7 @@
#else
u-boot-img {
#endif
- offset = ;
+ offset = <(CONFIG_SPL_PAD_TO + 0x8000)>;
This is confusing. The documentation states:
"""
offset:
This sets the offset of an entry within the image or section containing
it.
"""
My understanding is that it should be relative to the beginning of the
image but this now needs the knowledge of where it will be stored on the
MMC device (via the value in skip-at-start).
Why is skip-at-start automatically deducted from offset?
This is how binman works[1]. We are trying to use the feature designs
Why is it deducted?
Are you asking why skip-at-start is deducted from the offset?
Yes
Regards,
Simon
[PATCH] boot: Add missing code for bootz_run()
The bootz method is special in that it uses its own implementation of
several of the bootm states.
The existing do_bootz() function calls bootz_run() but first does a few
other things. These are missing in the direct call to bootz_run(). I
probably missed this because bootz_start() sets up its own
struct bootm_info so I assumed it was independent. While the struct
itself is independent, changes to the images member (which is a pointer)
persist.
Move the required code into bootz_run()
This change was manually tested on an rpi2 with postmarketOS added,
using standard boot and also the 'bootz' command.
Signed-off-by: Simon Glass
Fixes: 47eda7e80ea ("boot: pxe: Use bootm_...() functions where possible")
Reported-by: Svyatoslav Ryhel
---
boot/bootm.c | 33 ++
cmd/bootz.c | 65 +++-
2 files changed, 36 insertions(+), 62 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 7807579d5e6..0e63dd4adf3 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1185,6 +1185,39 @@ int bootm_run(struct bootm_info *bmi)
int bootz_run(struct bootm_info *bmi)
{
+ struct bootm_headers *images = bmi->images;
+ ulong zi_start, zi_end;
+ int ret;
+
+ ret = bootm_run_states(bmi, BOOTM_STATE_START);
+ if (ret)
+ return ret;
+
+ images->ep = bmi->addr_img ? hextoul(bmi->addr_img, NULL) :
+ image_load_addr;
+
+ ret = bootz_setup(images->ep, &zi_start, &zi_end);
+ if (ret)
+ return ret;
+
+ lmb_reserve(images->ep, zi_end - zi_start);
+
+ /*
+* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
+* have a header that provide this informaiton.
+*/
+ if (bootm_find_images(images->ep, bmi->conf_ramdisk, bmi->conf_fdt,
+ images->ep, zi_end - zi_start))
+ return -EINVAL;
+
+ /*
+* We are doing the BOOTM_STATE_LOADOS state ourselves, so must
+* disable interrupts ourselves
+*/
+ bootm_disable_interrupts();
+
+ images->os.os = IH_OS_LINUX;
+
return boot_run(bmi, "bootz", 0);
}
diff --git a/cmd/bootz.c b/cmd/bootz.c
index 787203f5bd7..acf0c92a42f 100644
--- a/cmd/bootz.c
+++ b/cmd/bootz.c
@@ -20,56 +20,6 @@ int __weak bootz_setup(ulong image, ulong *start, ulong *end)
return -1;
}
-/*
- * zImage booting support
- */
-static int bootz_start(struct cmd_tbl *cmdtp, int flag, int argc,
- char *const argv[], struct bootm_headers *images)
-{
- ulong zi_start, zi_end;
- struct bootm_info bmi;
- int ret;
-
- bootm_init(&bmi);
- if (argc)
- bmi.addr_img = argv[0];
- if (argc > 1)
- bmi.conf_ramdisk = argv[1];
- if (argc > 2)
- bmi.conf_fdt = argv[2];
- /* do not set up argc and argv[] since nothing uses them */
-
- ret = bootm_run_states(&bmi, BOOTM_STATE_START);
-
- /* Setup Linux kernel zImage entry point */
- if (!argc) {
- images->ep = image_load_addr;
- debug("* kernel: default image load address = 0x%08lx\n",
- image_load_addr);
- } else {
- images->ep = hextoul(argv[0], NULL);
- debug("* kernel: cmdline image address = 0x%08lx\n",
- images->ep);
- }
-
- ret = bootz_setup(images->ep, &zi_start, &zi_end);
- if (ret != 0)
- return 1;
-
- lmb_reserve(images->ep, zi_end - zi_start);
-
- /*
-* Handle the BOOTM_STATE_FINDOTHER state ourselves as we do not
-* have a header that provide this informaiton.
-*/
- if (bootm_find_images(image_load_addr, cmd_arg1(argc, argv),
- cmd_arg2(argc, argv), images->ep,
- zi_end - zi_start))
- return 1;
-
- return 0;
-}
-
int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
struct bootm_info bmi;
@@ -78,17 +28,6 @@ int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
/* Consume 'bootz' */
argc--; argv++;
- if (bootz_start(cmdtp, flag, argc, argv, &images))
- return 1;
-
- /*
-* We are doing the BOOTM_STATE_LOADOS state ourselves, so must
-* disable interrupts ourselves
-*/
- bootm_disable_interrupts();
-
- images.os.os = IH_OS_LINUX;
-
bootm_init(&bmi);
if (argc)
bmi.addr_img = argv[0];
@@ -99,8 +38,10 @@ int do_bootz(struct cmd_tbl *cmdtp, int flag, int argc, char
*const argv[])
bmi.cmd_name = "bootz";
ret = bootz_run(&bmi);
+ if (ret)
+ return CMD_RET_FAILURE;
- return ret;
+ return 0;
}
U_BOOT_LONGHELP(bootz,
--
2.43.0
base-commit: ea9e72801c4c3e3542afe40f89e7e0822cabfcf8
bran
Re: [PATCH 5/5] configs: dragonboard820: updates
On 4/7/25 19:56, Jorge Ramirez-Ortiz wrote: Configure GPIO and CLK_STUBS CLK_STUBS is required for MMC initialization Signed-off-by: Jorge Ramirez-Ortiz Reviewed-by: Neil Armstrong Reviewed-by: Caleb Connolly > --- configs/dragonboard820c_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/dragonboard820c_defconfig b/configs/dragonboard820c_defconfig index e29bea7deb2..2a5b7212f74 100644 --- a/configs/dragonboard820c_defconfig +++ b/configs/dragonboard820c_defconfig @@ -45,4 +45,6 @@ CONFIG_PINCTRL_QCOM_APQ8096=y CONFIG_DM_PMIC=y CONFIG_PMIC_QCOM=y CONFIG_MSM_SERIAL=y +CONFIG_MSM_GPIO=y CONFIG_SPMI_MSM=y +CONFIG_CLK_STUB=y -- Caleb (they/them)
Re: [PATCH v4 08/10] rockchip: binman: Use the skip-at-start prop in simple-bin image
Hi Quentin,
On 2025-04-09 12:57, Quentin Schulz wrote:
> Hi Jonas, Simon,
>
> On 3/29/25 4:06 PM, Jonas Karlman wrote:
>> From: Simon Glass
>>
>> The simple-bin image is normally written to MMC media at block 64, which
>> is a 32K offset from start of storage media.
>>
>> Set the skip-at-start property to 0x8000 (32 KiB) so that fdtmap and
>> other embedded binman symbols in the output binary is referencing image
>> offsets correctly.
>>
>
> Shouldn't we have this commit BEFORE we add the `fdtmap` node since we
> know it's wrong before this commit?
Sure, this series could/should probably be reordered into, patches with:
- fixes
- no functional change
- functional change
- new features
My understanding is that the binman symbols is not really used by
Rockchip in current configuration, yet symbols is embedded into the
binary utput and possible also with the fdtmap. So the order has no
practical change/diff.
Will reorder patches in a v5.
>
>> Signed-off-by: Simon Glass
>> Signed-off-by: Jonas Karlman
>> ---
>> Changes in v4:
>> - Drop defconfig changes
>> - Split from "VBE serial part H: Implement VBE on Rockchip RK3399"
>>
>> Changes in v2:
>> - Move this patch to the end of the series
>> - Drop 0x8000 offset for SPI
>> ---
>> arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
>> b/arch/arm/dts/rockchip-u-boot.dtsi
>> index fb38b7b80c43..65b81bf58626 100644
>> --- a/arch/arm/dts/rockchip-u-boot.dtsi
>> +++ b/arch/arm/dts/rockchip-u-boot.dtsi
>> @@ -154,6 +154,7 @@
>> simple-bin {
>> filename = "u-boot-rockchip.bin";
>> pad-byte = <0xff>;
>> +skip-at-start = <0x8000>;
>>
>> mkimage {
>> filename = "idbloader.img";
>> @@ -178,7 +179,7 @@
>> #else
>> u-boot-img {
>> #endif
>> -offset = ;
>> +offset = <(CONFIG_SPL_PAD_TO + 0x8000)>;
>
> This is confusing. The documentation states:
>
> """
> offset:
> This sets the offset of an entry within the image or section containing
> it.
> """
>
> My understanding is that it should be relative to the beginning of the
> image but this now needs the knowledge of where it will be stored on the
> MMC device (via the value in skip-at-start).
This was also my understanding but Simon has a different view and for
the simple-bin image that is mainly targeted MMC storage this could
possible be okay.
If there is any slight objection of this I would rather just drop this
patch for now and it can be part of Simon's next VBE part series.
Regards,
Jonas
>
> Why is skip-at-start automatically deducted from offset?
>
> Cheers,
> Quentin
[PATCH RFC 3/4] boot/fit: declare (and use) new constant for conf's compatible prop
From: Quentin Schulz
Fit conf node may have a compatible property[1] which stores the root
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This adds (and uses) this constant for FIT node parsing.
Note that this property may also appear in fpga image nodes[3] but that
isn't done in this commit.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
[3] https://fitspec.osfw.foundation/#images-node 2.3.2 Conditionally mandatory
property
Signed-off-by: Quentin Schulz
---
boot/image-fit.c | 2 +-
include/image.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/boot/image-fit.c b/boot/image-fit.c
index
7c822a39fd85554a716d9cada54cbaf91b3ec24a..52dbd7e96180da306da7f1516e8a3ab18a51ea33
100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1756,7 +1756,7 @@ int fit_conf_find_compat(const void *fit, const void *fdt)
continue;
/* If there's a compat property in the config node, use that. */
- if (fdt_getprop(fit, noffset, "compatible", NULL)) {
+ if (fdt_getprop(fit, noffset, FIT_COMPAT_PROP, NULL)) {
fdt = fit;/* search in FIT image */
compat_noffset = noffset; /* search under config node */
} else {/* Otherwise extract it from the kernel FDT. */
diff --git a/include/image.h b/include/image.h
index
c1db8383459c9d7ce1ecc318b4627a7066e5..c8286f2ffd32ed312f25d5d8cdc0a601f8e02f2f
100644
--- a/include/image.h
+++ b/include/image.h
@@ -1103,6 +1103,7 @@ int booti_setup(ulong image, ulong *relocated_addr, ulong
*size,
#define FIT_STANDALONE_PROP"standalone"
#define FIT_SCRIPT_PROP"script"
#define FIT_PHASE_PROP "phase"
+#define FIT_COMPAT_PROP"compatible"
#define FIT_MAX_HASH_LEN HASH_MAX_DIGEST_SIZE
--
2.49.0
Re: [PATCH 0/5] patman: Separate gitutil fully
On Wed, Apr 09, 2025 at 07:04:48AM -0600, Simon Glass wrote: > Hi Tom, > > On Tue, 8 Apr 2025 at 16:13, Tom Rini wrote: > > > > On Mon, Apr 07, 2025 at 10:51:42PM +1200, Simon Glass wrote: > > > > > > > > The gitutil module uses Patman's settings module, which is not allowed > > > as it is supposed to be a separate package. This series ties up this > > > dependency. > > > > > > This series depends on these two patches being applied: > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250227192735.406389-1-...@chromium.org/ > > > https://patchwork.ozlabs.org/project/uboot/patch/20250328130225.2607974-1-...@chromium.org/ > > > > > > > > > Simon Glass (5): > > > patman: Untangle settings from gitutil > > > patman: Pass the alias dict into gitutil.build_email_list() > > > patman: Pass the alias dict into gitutil.email_patches() > > > patman: Pass aliases to Series.MakeCcFile() > > > patman: Update Series.ShowActions() to pass alias > > > > > > tools/patman/control.py | 11 --- > > > tools/patman/func_test.py | 8 > > > tools/patman/series.py| 32 ++-- > > > tools/u_boot_pylib/gitutil.py | 34 ++ > > > 4 files changed, 48 insertions(+), 37 deletions(-) > > > > I just want to reiterate my question / request to host these outside of > > the U-Boot sources themselves so they can be managed (both in the sense > > of U-Boot as user and as maintainer of sources) following normal Python > > best practices? I'd be fine even with something under > > https://source.denx.de/u-boot//patman, etc. > > Yes I am working towards that. This series cleans up something missed > in the last series. > > After this series there is really just 'patchstream' left, which is > used by buildman and patman. I haven't quite come to terms with the > idea of moving it to u_boot_pylib yet. > > What are the best practices you are referring to? Hosting python projects in their own repository, and versioning them and managing them via pip/etc. > As to location, I can keep it in my tree and just delete it from yours > if you like. That would be very silly. Aside from the whole thing about you needing to close down your fork, which this isn't even about. -- Tom signature.asc Description: PGP signature
[PATCH RFC 4/4] boot/fit: print all configuration node compatibles
From: Quentin Schulz
Fit conf node may have a compatible property[1] which stores the
compatible of the first blob in the fdt property of the node. This can
be used to automatically select the proper conf node based on the
compatible from the running U-Boot (matching the former's compatible
with the latter)[2].
This brings the ability to mkimage/dumpimage to print the compatibles of
the configuration node(s). U-Boot CLI commands such as iminfo also see
this addition to their output.
[1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph
[2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot
Signed-off-by: Quentin Schulz
---
boot/image-fit.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/boot/image-fit.c b/boot/image-fit.c
index
52dbd7e96180da306da7f1516e8a3ab18a51ea33..4a3656c97a2c4ef8ca85177b08e3447baeed1877
100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -323,6 +323,17 @@ static void fit_conf_print(const void *fit, int noffset,
const char *p)
printf("%s\n", uname);
}
+ for (fdt_index = 0;
+uname = fdt_stringlist_get(fit, noffset, FIT_COMPAT_PROP,
+ fdt_index, NULL), uname;
+fdt_index++) {
+ if (fdt_index == 0)
+ printf("%s Compatible: ", p);
+ else
+ printf("%s", p);
+ printf("%s\n", uname);
+ }
+
uname = fdt_getprop(fit, noffset, FIT_FPGA_PROP, NULL);
if (uname)
printf("%s FPGA: %s\n", p, uname);
--
2.49.0
Re: [PATCH v4 07/10] rockchip: binman: Include a compatible string in each configuration
Hi Jonas, Simon, On 4/9/25 5:05 PM, Jonas Karlman wrote: Hi Quentin, On 2025-04-09 12:02, Quentin Schulz wrote: Hi Jonas, Simon, On 3/29/25 4:06 PM, Jonas Karlman wrote: From: Simon Glass Provide a compatible string in the config nodes that U-Boot can use to help decide which configuration to use. Can you tell us more about this? I think the VBE can use this to determine what config/fdt would be used in a multi-dtb FIT image. This also sparked an idea to use this compatible for board selection in SPL instead of the description (fdtfile) field. I have started to play around with a board_fit_config_compatible_match() a few patches in at [1], e.g.: - WIP: boot: fit: add board_fit_config_compatible_match() - WIP: rockchip: implement fit config compatible match for boards [1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/for-next That could also be used for having board specific TPL+SPL and use a single multi-dtb FIT with U-Boot proper and multiple fdt/config nodes, one for each board. I don't think mkimage -l/dumpimage -l actually provide that information and the docs are sparse as to what "so that things work correctly with FIT's configuration-matching algortihm." means. Looking a bit into tools/binman/ftest.py it seems like it's a way to expose the DT compatible property from within the first entry in `fdt` array property (a DTB) into the configuration node in the fit image. Seems like it's a bit more involved than that, c.f. https://fitspec.osfw.foundation/#select-a-configuration-to-boot Thanks both of you for the pointers. I think it'd make sense to update dumpimage/mkimage/etc... to dump that information as well? I think so too, I know there are a few load/entry addresses for some image type that is also not shown by dumpimage. This is something that can be improved in a different series. I've sent something for this compatible conf node property: https://lore.kernel.org/u-boot/20250409-fit-compat-v1-0-56df89ef4...@cherry.de/T/#t But indeed, seems like we're missing printing the "script" property and many others related to signing for example. There's also a few image properties that are only printed based on the type, e.g. "Architecture" only for kernel, standalone, ramdisk, firmware and fdt types, "OS" onylk for kernel, ramdisk and firmware. Not sure what the reasoning is. Cheers, Quentin
[PATCH RFC 1/4] boot/fit: use constants for property strings
From: Quentin Schulz
Some properties have their string represented in include/image.h via
constants, so let's use those constants instead of using a hardcoded
string.
Signed-off-by: Quentin Schulz
---
boot/common_fit.c | 4 ++--
boot/image-fit.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/common_fit.c b/boot/common_fit.c
index
a2f9b8d83c3b66a39ae0e172445d162f5146578a..fd434fe28e1908596365c9d31892a73ec97c36e3
100644
--- a/boot/common_fit.c
+++ b/boot/common_fit.c
@@ -46,12 +46,12 @@ int fit_find_config_node(const void *fdt)
return -EINVAL;
}
- dflt_conf_name = fdt_getprop(fdt, conf, "default", &len);
+ dflt_conf_name = fdt_getprop(fdt, conf, FIT_DEFAULT_PROP, &len);
for (node = fdt_first_subnode(fdt, conf);
node >= 0;
node = fdt_next_subnode(fdt, node)) {
- name = fdt_getprop(fdt, node, "description", &len);
+ name = fdt_getprop(fdt, node, FIT_DESC_PROP, &len);
if (!name) {
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf("%s: Missing FDT description in DTB\n",
diff --git a/boot/image-fit.c b/boot/image-fit.c
index
41ab1f552b04d6a5731625ce8c03e17730f8d0cd..7c822a39fd85554a716d9cada54cbaf91b3ec24a
100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1760,7 +1760,7 @@ int fit_conf_find_compat(const void *fit, const void *fdt)
fdt = fit;/* search in FIT image */
compat_noffset = noffset; /* search under config node */
} else {/* Otherwise extract it from the kernel FDT. */
- kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
+ kfdt_name = fdt_getprop(fit, noffset, FIT_FDT_PROP,
&len);
if (!kfdt_name) {
debug("No fdt property found.\n");
continue;
--
2.49.0
[PATCH 0/2] arm64: versal2: Read an eeprom
Read an eeprom after relocation if multi dtb's are disabled. Padmarao Begari (2): arm64: versal2: Remove dtb reselect and multi dtb board: amd: Read an eeprom after relocation board/amd/versal2/board.c | 3 +++ configs/amd_versal2_virt_defconfig | 2 -- 2 files changed, 3 insertions(+), 2 deletions(-) -- 2.44.1
[PATCH] board: xilinx: Store board info data in data section
Line 171 in README is describing that before relocation no code
should use global variable because global variables are placed
to BSS section which is initialized to 0 after relocation.
In the case of ZynqMP, where DTB reselection is enabled, the EEPROM
is read again after relocation. This prevents the issue from being
observed. However, in Versal Gen 2, where DTB reselection is also
enabled, the EEPROM is not read after relocation because it is not
yet wired in board_init(). This leads to a situation where the code
accesses an incorrect memory location, because none is really
checking the board_info is valid or not. To fix, move the board_info
into the data section and also check whether it is valid or not.
Signed-off-by: Padmarao Begari
---
board/xilinx/common/board.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index deea6c71103..8ffe7429901 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -80,7 +80,7 @@ struct xilinx_board_description {
};
static int highest_id = -1;
-static struct xilinx_board_description *board_info;
+static struct xilinx_board_description *board_info __section(".data");
#define XILINX_I2C_DETECTION_BITS sizeof(struct fru_common_hdr)
@@ -468,6 +468,9 @@ int board_late_init_xilinx(void)
ret |= env_set_addr("bootm_size", (void *)bootm_size);
for (id = 0; id <= highest_id; id++) {
+ if (!board_info)
+ break;
+
desc = &board_info[id];
if (desc && desc->header == EEPROM_HEADER_MAGIC) {
if (desc->manufacturer[0])
--
2.44.1
Re: [PATCH 4/5] clk: stub: add qcom,glink-smd-rpm
On 4/7/25 19:56, Jorge Ramirez-Ortiz wrote:
Add support for the resource power manager clocks over SMD/GLINK to be
stubbed.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Sumit Garg
Reviewed-by: Neil Armstrong
Reviewed-by: Caleb Connolly
Thanks!> ---
drivers/clk/clk-stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-stub.c b/drivers/clk/clk-stub.c
index 5fbbb07b7f7..38ed0d094fa 100644
--- a/drivers/clk/clk-stub.c
+++ b/drivers/clk/clk-stub.c
@@ -14,7 +14,7 @@
static const struct udevice_id nop_parent_ids[] = {
{ .compatible = "qcom,rpm-proc" },
{ .compatible = "qcom,glink-rpm" },
- { .compatible = "qcom,rpm-sm6115" },
+ { .compatible = "qcom,glink-smd-rpm" },
{ }
};
--
Caleb (they/them)
Re: [PATCH v4 09/10] rockchip: binman: Support use of crc32 for SPL_FIT_SIGNATURE
Hi Quentin,
On Wed, 9 Apr 2025 at 10:11, Quentin Schulz wrote:
>
> Hi Jonas,
>
> On 4/9/25 5:38 PM, Jonas Karlman wrote:
> > Hi Quentin,
> >
> > On 2025-04-09 13:06, Quentin Schulz wrote:
> >> Hi Jonas,
> >>
> >> On 3/29/25 4:06 PM, Jonas Karlman wrote:
> >>> Use of SHA256 checksum validation on ARMv7 SoCs can be very time
> >>> consuming compared to ARMv8 SoCs with Crypto Extensions.
> >>>
> >>> Add support for use of the crc32 hash algo when SHA256 is not supported.
> >>> Also use a HAS_HASH to simplify the ifdefs when no known hash algo is
> >>> compiled.
> >>>
> >>> Signed-off-by: Jonas Karlman
> >>
> >> I don't know enough about general security but this very much looks like
> >> a bad idea to me.
> >>
> >> https://web.archive.org/web/20170210173741/http://www.derkeiler.com/Newsgroups/sci.crypt/2003-07/1451.html
> >>
> >> """
> >> While properly designed CRC's are good at detecting random errors in
> >> the data (due to e.g. line noise), the CRC is useless as a secure
> >> indicator of intentional manipulation of the data. And this is
> >> because it's not hard at all to modify the data to produce any CRC
> >> you desire (e.g. the same CRC as the original data, to try to
> >> disguise your data manipulation).
> >> """
> >>
> >> (yes I took the "first" link my web search engine returned me, thanks
> >> confirmation bias!).
> >
> > I am fully aware, and the fallback to use crc32, and current primarily
> > use of sha256, should not be considered a security feature. It is
> > intended purely for a checksum validation of the binary blob after it
> > has been loaded into memory and before U-Boot otherwise unconditionally
> > jumps to and execute the loaded blob of binary code.
> >
> >>
> >> I don't want to give people a false sense of security. If it really
> >> comes down to it, I'd rather have an explicit Kconfig symbol to set this
> >> value (maybe have a `choice` even) and be very clear about security
> >> implications.
> >
> > Prior to the addition of the hash { algo=sha256 }, there was no checksum
> > test and U-Boot SPL would unconditionally jump to the loaded data, even
> > if it had been corrupted, was only halfway written or otherwise
> > overwritten.
> >
> > The addition of crc32 instead of sha256 is just to allow older board
> > variants with weaker SoCs to at least have some sort of checksum
> > validation in use without affecting the boot time too much.
> >
> > On my rk3228 board, validation using sha256 could take a few seconds,
> > and with crc32 it could be measured in ms.
> >
> > To me, having at least some default checksum validation is preferred
> > over none at all.
> >
>
> Except if this confuses people into thinking they have a secure system
> except they use CRC32 instead of something more appropriate like SHA256.
>
> It seems like the "hash" node presence doesn't mean a FIT conf or image
> node is signed. I also don't see many device trees with a signature
> node... which is kinda odd. Looking a bit into the signature node in the
> spec and binman tests, it's not clear to me if the hash node is reused
> by the signature node if if exists and if their algo should match and
> what exactly is checked by the signature node (like signing the hash
> string contained in the hash node(s) listed in sign-images property, or
> (re-)generating a hash of those and signing it at build time?
>
> If
> a) it is not possible to have a hash node's algo differ from a signature
> node's algo, then I'm fine with this as crc32 won't be allowed
> b) the signature node regenerates a hash regardless of the hash in the
> hash node, meaning the signature will be "appropriately secure"
> regardless of the algorithm listed in the hash node, then I'm fine with
> it too,
> c) it is possible to sign a crc32 hash, don't want it :)
>
> @Simon, do you have some hints about this?
In fit.py :
# The hash subnodes here are for mkimage, not binman.
entry.SetUpdateHash(False)
so yes they are independent, so far as Binman is concerned.
But of course, configuration signing relies on hashes in the image
nodes, so at least one strong hash is needed.
Regards,
Simon
Re: [PATCH] tiny-printf: Handle formatting of %p with an extra Kconfig
On Wed, Apr 09, 2025 at 02:33:08PM +0200, Michael Walle wrote: > Hi, > > > >> The formatting with %pa / %pap behaves like %x, which results in an > > >> incorrect value being output. To improve this, a new fine-tuning > > >> Kconfig XPL_USE_TINY_PRINTF_POINTER_SUPPORT for pointer formatting > > >> has been added. If it is enabled, the output of %pa / %pap should > > >> be correct, and if it is disabled, the pointer formatting is > > >> completely unsupported. In addition to indicate unsupported formatting, > > >> '?' will be output. This allows enabling pointer formatting only > > >> when needed. For SPL_NET and NET_LWIP it is selected by default. > > >> Then it also supports the formatting with %pm, %pM and %pI4. > > >> > > >> Signed-off-by: Christoph Niedermaier > > >> --- > > >> Cc: Tom Rini > > >> Cc: Simon Glass > > >> Cc: Michael Walle > > >> Cc: Quentin Schulz > > >> Cc: Marek Vasut > > >> Cc: Benedikt Spranger > > >> Cc: Jerome Forissier > > >> Cc: John Ogness > > >> Cc: Ilias Apalodimas > > >> --- > > >> Kconfig| 1 + > > >> common/spl/Kconfig | 1 + > > >> lib/Kconfig| 8 > > >> lib/tiny-printf.c | 45 +++-- > > >> 4 files changed, 29 insertions(+), 26 deletions(-) > > >> > > >> diff --git a/Kconfig b/Kconfig > > >> index 6379a454166..4d13717294c 100644 > > >> --- a/Kconfig > > >> +++ b/Kconfig > > >> @@ -757,6 +757,7 @@ config NET > > >> > > >> config NET_LWIP > > >> bool "Use lwIP for networking stack" > > >> +select XPL_USE_TINY_PRINTF_POINTER_SUPPORT if > > >> SPL_USE_TINY_PRINTF || TPL_USE_TINY_PRINTF || VPL_USE_TINY_PRINTF > > >> imply NETDEVICES > > >> help > > >>Include networking support based on the lwIP (lightweight IP) > > >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > >> index 94e118f8465..72736dbecf5 100644 > > >> --- a/common/spl/Kconfig > > >> +++ b/common/spl/Kconfig > > >> @@ -1096,6 +1096,7 @@ config SPL_DM_SPI_FLASH > > >> config SPL_NET > > >> bool "Support networking" > > >> depends on !NET_LWIP > > >> +select XPL_USE_TINY_PRINTF_POINTER_SUPPORT if > > >> SPL_USE_TINY_PRINTF || TPL_USE_TINY_PRINTF || VPL_USE_TINY_PRINTF > > >> help > > >>Enable support for network devices (such as Ethernet) in SPL. > > >>This permits SPL to load U-Boot over a network link rather > > >> than > > >> diff --git a/lib/Kconfig b/lib/Kconfig > > >> index 1a683dea670..62e28d4a1f3 100644 > > >> --- a/lib/Kconfig > > >> +++ b/lib/Kconfig > > >> @@ -253,6 +253,14 @@ config VPL_USE_TINY_PRINTF > > >> > > >>The supported format specifiers are %c, %s, %u/%d and %x. > > >> > > >> +config XPL_USE_TINY_PRINTF_POINTER_SUPPORT > > >> +bool "Extend tiny printf with the pointer formatting %p" > > >> +depends on SPL_USE_TINY_PRINTF || TPL_USE_TINY_PRINTF || > > >> VPL_USE_TINY_PRINTF > > >> +help > > >> + This option enables the formatting of pointers %p. It supports > > >> + %p and %pa / %pap. If this option is selected by SPL_NET or > > >> NET_LWIP > > >> + it also supports the formatting with %pm, %pM and %pI4. > > > > > > This isn't quite what I'd like to see. I don't want to start using the > > > literal XPL namespace as that will lead to confusion down the line. > > > > OK, in V2 I will only support SPL. > > > > > Since we only have SPL_NET, I think we should name this symbol > > > SPL_USE_TINY_PRINTF_POINTER_SUPPORT, not ask about it (so bool without > > > "prompt text" following), and select from SPL_NET if > > > SPL_USE_TINY_PRINTF. > > IIRC, the old one also enabled the pointer support if DEBUG is > enabled. I don't think this will work with Kconfig. I was looking around for, but didn't quite see, a good existing option to "if .." around the prompt text for. > > Now you will get the output '?' when using formatting with %p or %pa. > > If someone wants to use the pointer support e.g. %pa in pinctrl-single.c > > and is restricted to use tiny printf, then it would be good to have > > the option to enable it manually and not be forced to enable SPL_NET or > > NET_LWIP to have the pointer support enabled. In this case, it makes > > sense to allow switching it on in menuconfig. > > FWIW, I'm also fine with enabling full printf support as long as the > tiny one doesn't print misleading values. I'm not sure if the one non-debug %pa print in pinctrl-single.c is really triggered within SPL, and I do hope that the way this patch is otherwise done will make it easier if someone needs %pa to work when debugging a problem in SPL, and can't enable full printf due to space. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] net-lwip: wget: add LMB and buffer checks
On 4/9/25 16:17, Heinrich Schuchardt wrote:
> On 09.04.25 14:20, Jerome Forissier wrote:
>> Legacy NET wget invokes a store_block() function which performs buffer
>> validation (LMB, address wrapping). Do the same with NET_LWIP.
>>
>> Signed-off-by: Jerome Forissier
>> Suggested-by: Sughosh Ganu
>> ---
>> net/lwip/wget.c | 49 +
>> 1 file changed, 41 insertions(+), 8 deletions(-)
>>
>> diff --git a/net/lwip/wget.c b/net/lwip/wget.c
>> index 14f27d42998..746c8164d66 100644
>> --- a/net/lwip/wget.c
>> +++ b/net/lwip/wget.c
>> @@ -6,6 +6,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include "lwip/altcp_tls.h"
>> #include
>> @@ -201,11 +202,44 @@ static int parse_legacy_arg(char *arg, char *nurl,
>> size_t rem)
>> return 0;
>> }
>>
>
> Please, add Sphinx style descriptions to all functions.
OK
>> +static int store_block(struct wget_ctx *ctx, void *src, u16_t len)
>> +{
>> + ulong store_addr = ctx->daddr;
>> + uchar *ptr;
>> +
>> + /* Avoid overflow */
>> + if (wget_info->buffer_size && wget_info->buffer_size < ctx->size + len)
>> + return -1;
>> +
>> + if (CONFIG_IS_ENABLED(LMB) && wget_info->set_bootdev) {
>> + if (store_addr + len < store_addr ||
>> + lmb_read_check(store_addr, len)) {
>> + printf("\nwget error: ");
>> + printf("trying to overwrite reserved memory...\n");
>
> Output while an EFI application is consuming the HTTP protocol should be
> avoided as it is not compatible with the EFI console.
What does printf() do in this case (EFI application)? If it's just ignored
then I suppose it should be OK to have the printf() right where the error
occurs, no?
> If you want console output in the wget command, please, implement it
> there and not in a library function called by efi_net_do_request().
That will make the code slightly more complicated, although not much (some
additional status in struct wget_ctx).
Regards,
--
Jerome
>
>> + return -1;
>> + }
>> + }
>> +
>> + ptr = map_sysmem(store_addr, len);
>> + memcpy(ptr, src, len);
>> + unmap_sysmem(ptr);
>> +
>> + ctx->daddr += len;
>> + ctx->size += len;
>> + if (ctx->size - ctx->prevsize > PROGRESS_PRINT_STEP_BYTES) {
>> + printf("#");
>
> ditto
>
> Best regards
>
> Heinrich
>
>> + ctx->prevsize = ctx->size;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static err_t httpc_recv_cb(void *arg, struct altcp_pcb *pcb, struct pbuf
>> *pbuf,
>> err_t err)
>> {
>> struct wget_ctx *ctx = arg;
>> struct pbuf *buf;
>> + err_t ret;
>>
>> if (!pbuf)
>> return ERR_BUF;
>> @@ -214,18 +248,17 @@ static err_t httpc_recv_cb(void *arg, struct altcp_pcb
>> *pcb, struct pbuf *pbuf,
>> ctx->start_time = get_timer(0);
>>
>> for (buf = pbuf; buf; buf = buf->next) {
>> - memcpy((void *)ctx->daddr, buf->payload, buf->len);
>> - ctx->daddr += buf->len;
>> - ctx->size += buf->len;
>> - if (ctx->size - ctx->prevsize > PROGRESS_PRINT_STEP_BYTES) {
>> - printf("#");
>> - ctx->prevsize = ctx->size;
>> + if (store_block(ctx, buf->payload, buf->len) < 0) {
>> + altcp_abort(pcb);
>> + ret = ERR_BUF;
>> + goto out;
>> }
>> }
>> -
>> altcp_recved(pcb, pbuf->tot_len);
>> + ret = ERR_OK;
>> +out:
>> pbuf_free(pbuf);
>> - return ERR_OK;
>> + return ret;
>> }
>>
>> static void httpc_result_cb(void *arg, httpc_result_t httpc_result,
>
Re: [PATCH v1] configs: set SPL_TEXT_BASE by default for k3 platforms
On Wed, Apr 09, 2025 at 06:17:37PM +0530, Anshul Dalal wrote: > SPL_TEXT_BASE is used as the load address for the main domain SPL on k3 > platforms. > > Since the config value is the same for every board, this patch sets the > value 0x8008 as default for all ARCH_K3 and deletes the instances of > SPL_TEXT_BASE in individual defconfigs. > > Signed-off-by: Anshul Dalal [snip] > --- > common/spl/Kconfig | 1 + > configs/am62ax_evm_a53_defconfig | 1 - > configs/am62px_evm_a53_defconfig | 1 - > configs/am62x_beagleplay_a53_defconfig | 1 - > configs/am62x_evm_a53_defconfig| 1 - > configs/am64x_evm_a53_defconfig| 1 - > configs/am65x_evm_a53_defconfig| 1 - > configs/iot2050_defconfig | 1 - > configs/j7200_evm_a72_defconfig| 1 - > configs/j721e_beagleboneai64_a72_defconfig | 1 - > configs/j721e_evm_a72_defconfig| 1 - > configs/j721s2_evm_a72_defconfig | 1 - > configs/j722s_evm_a53_defconfig| 1 - > configs/j784s4_evm_a72_defconfig | 1 - > configs/phycore_am62ax_a53_defconfig | 1 - > configs/phycore_am62x_a53_defconfig| 1 - > configs/phycore_am64x_a53_defconfig| 1 - > configs/verdin-am62_a53_defconfig | 1 - > 18 files changed, 1 insertion(+), 17 deletions(-) > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > index 94e118f8465..a84b96ebce4 100644 > --- a/common/spl/Kconfig > +++ b/common/spl/Kconfig > @@ -271,6 +271,7 @@ config SPL_TEXT_BASE > default 0x4020 if OMAP34XX > default 0x402F4000 if AM43XX > default 0x402F0400 if AM33XX > + default 0x8008 if ARCH_K3 > default 0x00908000 if ARCH_MX6 > default 0x00912000 if ARCH_MX7 > default 0x40301350 if OMAP54XX This should probably be ARCH_K3 && ARM64, and then also different line for the R5 side? -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/5] patman: Separate gitutil fully
Hi Tom, On Wed, 9 Apr 2025 at 07:04, Simon Glass wrote: > > Hi Tom, > > On Tue, 8 Apr 2025 at 16:13, Tom Rini wrote: > > > > On Mon, Apr 07, 2025 at 10:51:42PM +1200, Simon Glass wrote: > > > > > > > > The gitutil module uses Patman's settings module, which is not allowed > > > as it is supposed to be a separate package. This series ties up this > > > dependency. > > > > > > This series depends on these two patches being applied: > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20250227192735.406389-1-...@chromium.org/ > > > https://patchwork.ozlabs.org/project/uboot/patch/20250328130225.2607974-1-...@chromium.org/ > > > > > > > > > Simon Glass (5): > > > patman: Untangle settings from gitutil > > > patman: Pass the alias dict into gitutil.build_email_list() > > > patman: Pass the alias dict into gitutil.email_patches() > > > patman: Pass aliases to Series.MakeCcFile() > > > patman: Update Series.ShowActions() to pass alias > > > > > > tools/patman/control.py | 11 --- > > > tools/patman/func_test.py | 8 > > > tools/patman/series.py| 32 ++-- > > > tools/u_boot_pylib/gitutil.py | 34 ++ > > > 4 files changed, 48 insertions(+), 37 deletions(-) > > > > I just want to reiterate my question / request to host these outside of > > the U-Boot sources themselves so they can be managed (both in the sense > > of U-Boot as user and as maintainer of sources) following normal Python > > best practices? I'd be fine even with something under > > https://source.denx.de/u-boot//patman, etc. > > Yes I am working towards that. This series cleans up something missed > in the last series. > > After this series there is really just 'patchstream' left, which is > used by buildman and patman. I haven't quite come to terms with the > idea of moving it to u_boot_pylib yet. > > What are the best practices you are referring to? > > As to location, I can keep it in my tree and just delete it from yours > if you like. BTW I'm working on better support for handling lots of series, as mentioned a while back. I need to add some docs, but will send some patches at some point in the next month. Regards, Simon
Re: [PATCH 33/34] sunxi: A523: add DT files from Linux v3 branch
Hi Andre,
On 11:35 Sun 23 Mar , Andre Przywara wrote:
> This imports the (preliminary) devicetree files for the boards with the
> new Allwinner A523/T527/H728 SoCs, including the basic SoC .dtsi.
>
> Those files have been reviewed and confirmed, but have not been merged
> into the official kernel repositories yet.
>
> Pending upstream kernel repository:
> https://github.com/apritzel/linux/commits/a523-v3/
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/dts/sun55i-a523.dtsi | 598 +
> arch/arm/dts/sun55i-a527-radxa-a5e.dts | 299 +
> arch/arm/dts/sun55i-h728-x96qpro+.dts | 287
> arch/arm/dts/sun55i-t527-avaota-a1.dts | 308 +
> 4 files changed, 1492 insertions(+)
> create mode 100644 arch/arm/dts/sun55i-a523.dtsi
> create mode 100644 arch/arm/dts/sun55i-a527-radxa-a5e.dts
> create mode 100644 arch/arm/dts/sun55i-h728-x96qpro+.dts
> create mode 100644 arch/arm/dts/sun55i-t527-avaota-a1.dts
>
> diff --git a/arch/arm/dts/sun55i-a523.dtsi b/arch/arm/dts/sun55i-a523.dtsi
> new file mode 100644
> index 000..ee485899ba0
> --- /dev/null
> +++ b/arch/arm/dts/sun55i-a523.dtsi
> @@ -0,0 +1,598 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
> +// Copyright (C) 2023-2024 Arm Ltd.
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
[...]
> + ohci1: usb@4200400 {
> + compatible = "allwinner,sun55i-a523-ohci",
> + "generic-ohci";
> + reg = <0x4200400 0x100>;
> + interrupts = ;
> + clocks = <&ccu CLK_BUS_OHCI1>,
> + <&ccu CLK_USB_OHCI1>;
> + resets = <&ccu RST_BUS_OHCI1>;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + status = "disabled";
> + };
> +
> + r_ccu: clock-controller@701 {
> + compatible = "allwinner,sun55i-a523-r-ccu";
> + reg = <0x701 0x250>;
> + clocks = <&osc24M>,
> + <&rtc CLK_OSC32K>,
> + <&rtc CLK_IOSC>,
> + <&ccu CLK_PLL_PERIPH0_200M>,
[...]
> + <&ccu CLK_PLL_AUDIO0_4X>;
U-Boot 2025.04-rc5-00056-g1ef486ead58d (Apr 09 2025 - 22:06:21 +0800) Allwinner
Technology
CPU: Allwinner A523 (SUN55I)
Model: Radxa A5E
DRAM: 4 GiB
sunxi_set_gate: (CLK#35) unhandled
Core: 77 devices, 21 uclasses, devicetree: separate
..
I've got a "CLK unhandled" err, checked and found CLK_PLL_AUDIO0_4X is not
implemtend in clk driver - drivers/clk/sunxi/clk_a523.c
do you have any idea why this clk gate not implemented?
or somehow, I guess we could drop it from uboot if not used
(or no need to keep sync with kernel dts? I did no further check)
--
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55
Re: [PATCH v4 07/10] rockchip: binman: Include a compatible string in each configuration
Hi Quentin,
On 2025-04-09 12:02, Quentin Schulz wrote:
> Hi Jonas, Simon,
>
> On 3/29/25 4:06 PM, Jonas Karlman wrote:
>> From: Simon Glass
>>
>> Provide a compatible string in the config nodes that U-Boot can use to
>> help decide which configuration to use.
>>
>
> Can you tell us more about this?
I think the VBE can use this to determine what config/fdt would be used
in a multi-dtb FIT image.
This also sparked an idea to use this compatible for board selection in SPL
instead of the description (fdtfile) field. I have started to play around
with a board_fit_config_compatible_match() a few patches in at [1], e.g.:
- WIP: boot: fit: add board_fit_config_compatible_match()
- WIP: rockchip: implement fit config compatible match for boards
[1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/for-next
That could also be used for having board specific TPL+SPL and use a
single multi-dtb FIT with U-Boot proper and multiple fdt/config nodes,
one for each board.
>
> I don't think mkimage -l/dumpimage -l actually provide that information
> and the docs are sparse as to what "so that things work correctly with
> FIT's configuration-matching algortihm." means.
>
> Looking a bit into tools/binman/ftest.py it seems like it's a way to
> expose the DT compatible property from within the first entry in `fdt`
> array property (a DTB) into the configuration node in the fit image.
>
> I think it'd make sense to update dumpimage/mkimage/etc... to dump that
> information as well?
I think so too, I know there are a few load/entry addresses for some
image type that is also not shown by dumpimage. This is something that
can be improved in a different series.
For FIT you can always use: dtc -I dtb -O dts u-boot.itb
[...]
configurations {
default = "config-1";
config-1 {
compatible = "radxa,e20c\0rockchip,rk3528";
loadables = "u-boot\0atf-2\0atf-3";
firmware = "atf-1";
fdt = "fdt-1";
description = "rockchip/rk3528-radxa-e20c.dtb";
};
config-2 {
compatible = "radxa,rock-2a\0rockchip,rk3528";
loadables = "u-boot\0atf-2\0atf-3";
firmware = "atf-1";
fdt = "fdt-2";
description = "rockchip/rk3528-rock-2a.dtb";
};
config-3 {
compatible = "radxa,rock-2f\0rockchip,rk3528";
loadables = "u-boot\0atf-2\0atf-3";
firmware = "atf-1";
fdt = "fdt-3";
description = "rockchip/rk3528-rock-2f.dtb";
};
};
[...]
Regards,
Jonas
>
> Reviewed-by: Quentin Schulz
>
> Thanks!
> Quentin
Re: [PATCH 12/13] board: dragonboard410c: Use button_cmd instead of custom code
On 07/04/2025 18:59, Stephan Gerhold wrote:
Simplify the board code by using the new BUTTON_CMD functionality, instead
of implementing this separately using C code. This allows disabling or
customizing this functionality if wanted.
Signed-off-by: Stephan Gerhold
---
board/qualcomm/dragonboard410c/dragonboard410c.c | 22 --
board/qualcomm/dragonboard410c/dragonboard410c.env | 2 ++
configs/dragonboard410c_defconfig | 2 +-
3 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.c
b/board/qualcomm/dragonboard410c/dragonboard410c.c
index
697e3c9b08b5c874912eb66ff4f0b3d32deaae01..4698b9d5e3e47a9b0389d9f6bafab9dd6db56a41
100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.c
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.c
@@ -51,28 +51,6 @@ static void msm_generate_mac_addr(u8 *mac)
put_unaligned_be32(msm_board_serial(), &mac[2]);
}
-/* Check for vol- button - if pressed - stop autoboot */
-int misc_init_r(void)
-{
- struct udevice *btn;
- int ret;
- enum button_state_t state;
-
- ret = button_get_by_label("vol_down", &btn);
- if (ret < 0) {
- printf("Couldn't find power button!\n");
- return ret;
- }
-
- state = button_get_state(btn);
- if (state == BUTTON_ON) {
- env_set("preboot", "setenv preboot; run fastboot");
- printf("vol_down pressed - Starting fastboot.\n");
- }
-
- return 0;
-}
-
int qcom_late_init(void)
{
char serial[16];
diff --git a/board/qualcomm/dragonboard410c/dragonboard410c.env
b/board/qualcomm/dragonboard410c/dragonboard410c.env
index
71f929b646cc305cf5223cd3462fe2350bc8093e..38399d65c640ee18261529ee3101b268700fa004
100644
--- a/board/qualcomm/dragonboard410c/dragonboard410c.env
+++ b/board/qualcomm/dragonboard410c/dragonboard410c.env
@@ -2,3 +2,5 @@
initrd_high=0x
fastboot=fastboot -l $fastboot_addr_r usb 0
boot_targets=usb mmc1 mmc0 pxe
+button_cmd_0_name=vol_down
+button_cmd_0=run fastboot
diff --git a/configs/dragonboard410c_defconfig
b/configs/dragonboard410c_defconfig
index
414dda6778c95eb3fdcd6ef522d8c7d0ef9219fa..449d48a3c004117b832ad620d49beb681a9bda68
100644
--- a/configs/dragonboard410c_defconfig
+++ b/configs/dragonboard410c_defconfig
@@ -14,6 +14,7 @@ CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_SYS_LOAD_ADDR=0x8008
CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 410C"
CONFIG_REMAKE_ELF=y
+CONFIG_BUTTON_CMD=y
CONFIG_FIT=y
CONFIG_BOOTSTD_FULL=y
CONFIG_OF_BOARD_SETUP=y
@@ -22,7 +23,6 @@ CONFIG_SYS_CBSIZE=512
CONFIG_SYS_PBSIZE=548
# CONFIG_DISPLAY_CPUINFO is not set
# CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_MISC_INIT_R=y
CONFIG_SYS_PROMPT="dragonboard410c => "
CONFIG_CMD_MD5SUM=y
CONFIG_CMD_MEMINFO=y
Reviewed-by: Neil Armstrong
Re: [PATCH] boot: Add missing code for bootz_run()
ср, 9 квіт. 2025 р. о 18:57 Simon Glass пише:
>
> The bootz method is special in that it uses its own implementation of
> several of the bootm states.
>
> The existing do_bootz() function calls bootz_run() but first does a few
> other things. These are missing in the direct call to bootz_run(). I
> probably missed this because bootz_start() sets up its own
> struct bootm_info so I assumed it was independent. While the struct
> itself is independent, changes to the images member (which is a pointer)
> persist.
>
> Move the required code into bootz_run()
>
> This change was manually tested on an rpi2 with postmarketOS added,
> using standard boot and also the 'bootz' command.
>
> Signed-off-by: Simon Glass
> Fixes: 47eda7e80ea ("boot: pxe: Use bootm_...() functions where possible")
> Reported-by: Svyatoslav Ryhel
> ---
>
It is not cleanly applicable to current u-boot/next with your pxe
changes present, but overall it fixes booting on my devices. Thank
you.
Tested-by: Svyatoslav Ryhel # LG P895
Re: [PATCH V2] tiny-printf: Improve %X formatting
On Thu, 20 Mar 2025 20:01:47 +0100, Christoph Niedermaier wrote: > If tiny printf is used with 0x%08X (upper case X) the output is > always 0x. It could be confusing if upper case instead > of lower case is used intentionally or accidentally because the > actual value is not output. To avoid this confusion, treat output > of %X as %x. As a compromise for tiny printf, the hex value is > then output correctly, but in lower case. This is done to keep it > tiny printf small. > > [...] Applied to u-boot/master, thanks! [1/1] tiny-printf: Improve %X formatting commit: 51b8679b94ea22ffb91925cf56df1950fd4b0e12 -- Tom
Re: [PATCH] pinctrl: qcom: handle reserved ranges
On 4/1/25 10:46, Neil Armstrong via groups.io wrote:
From: Caleb Connolly
Some Qualcomm boards feature reserved ranges of pins which are protected
by firmware. Attempting to read or write any registers associated with
these pins results the board resetting.
Add support for parsing these ranges from devicetree and ensure that the
pinctrl and GPIO drivers don't try to interact with these pins.
Signed-off-by: Caleb Connolly
Signed-off-by: Neil Armstrong
---
arch/arm/mach-snapdragon/include/mach/gpio.h | 15 +++
drivers/gpio/msm_gpio.c | 9
drivers/pinctrl/qcom/pinctrl-qcom.c | 64
3 files changed, 88 insertions(+)
...
+#define MSM_PINCTRL_MAX_RESERVED_RANGES 32
+
struct msm_pinctrl_priv {
phys_addr_t base;
struct msm_pinctrl_data *data;
+ u32 reserved_ranges[MSM_PINCTRL_MAX_RESERVED_RANGES * 2];
+ int reserved_ranges_count;
};
Why storing of reserved pins isn't implemented using bitmap?
DECLARE_BITMAP(reserved_pins, 256);
would only consume 32 bytes, instead of 256+4 like here.
Do I miss something?
---
Regards,
Alexey Minnekhanov
Re: (subset) [PATCH 00/18] Annotate switch/case fallthrough cases
On Thu, 27 Mar 2025 15:32:55 +, Andre Przywara wrote: > C's implicit fallthrough behaviour in switch/case statements can lead to > subtle bugs. Quite some while ago many compilers introduced warnings in > those cases, requiring intentional fallthrough's to be annotated. > > So far we were not enabling that compiler option, so many ambiguities > and some bugs in the code went unnoticed. > > [...] Applied to u-boot/master, thanks! [01/18] spl: mmc: properly annotate fallthrough commit: a6a9d3273346138fadb1a173fc2f5e9d0e61215a [02/18] zlib: annotate switch/case fallthrough cases commit: 3d907a5a490b79b876a3f9c325b483a116f29b7e [03/18] gadget: f_thor: annotate switch/case fallthrough commit: 2938eb1e022d7e1de23d89f941bc07b0776a2549 [04/18] use proper fallthrough annotations commit: 26b2482f124ba831e40a44ea0cb093203fd8d747 [06/18] fastboot: annotate switch/case fallthrough case commit: 06b1ebfe521d2729cd97db7dfed62469081f0ec3 [07/18] net: sun8i-emac: annotate fallthrough commit: 5ddb7d1265633d855889831bcad0ee4b9ea4a0d3 [08/18] usb: ohci-hcd: annotate switch/case fallthrough commit: 921e4d480dff3206020eacd4873795d0e57d7c20 [09/18] usb: xhci: annotate switch/case fallthrough properly commit: 4d108c884b5bd5cef13fa1eb11a65eefd4c48d3f [10/18] video: annotate switch/case fall-through commit: 2c22efbb37b00fc353ffee56bf0b54c38639e08e [11/18] net: e1000: annotate switch/case fallthrough commit: 960d3d933dbda88aed6d4fcf0711dbc7448ffd83 [12/18] mtd: ubi: annotate fallthrough commit: 64bc0124581b49093f5c348f5debe8889a56fedd [13/18] arm: mach-k3: am62p: annotate switch/case fallthrough commit: bc3e28e11b7a8b0fb1765556642409e4006a33f7 [14/18] mtd: spi-nor-tiny: annotate switch/case fallthrough commit: 452dfcc3b461c1bfbc2126623f42f551000a9ca3 [15/18] mtd: rawnand: nand_base: annotate switch/case fallthrough commit: 3f61113c276ffe52380cec159b47e6024249ee2d [16/18] cmd: pmic: annotate switch/case fallthrough commit: d29a90c8ce4a2e27f502f5ac5a051f7bcfd66e11 [17/18] cmd: spl: annotate switch/case fallthrough commit: 9ce2986e7e57277bac3c528412c0bb4443b7003a -- Tom
Re: [PATCH 0/5] acpi: simplify updating ACPI table header checksum
On Sat, 22 Mar 2025 00:21:15 +0100, Heinrich Schuchardt wrote: > Introduce a new function to update ACPI table headers. > This allows to simplify the existing code. > > Heinrich Schuchardt (5): > acpi: new function acpi_update_checksum() > acpi: simplify updating header checksum > x86/acpi: simplify updating header checksum > qemu-sbsa: simplify updating ACPI table header checksum > arm: simplify updating ACPI table header checksum > > [...] Applied to u-boot/master, thanks! [1/5] acpi: new function acpi_update_checksum() commit: 69e61d46d2dcdcf84a3a7aed7cf74ac3b3b850fd [2/5] acpi: simplify updating header checksum commit: bbc78592b16d164fbb252455d6a60afb3ee52709 [3/5] x86/acpi: simplify updating header checksum commit: e0055ac9bbd3059c961b1d7f98dcff276502c847 [4/5] qemu-sbsa: simplify updating ACPI table header checksum commit: 5eca1696d25f61ad58582820f8477360c81b8b7b [5/5] arm: simplify updating ACPI table header checksum commit: fecc50b0517d362b4db173b08a769f7b975d8255 -- Tom
Re: [PATCH 1/3] arm: gic-v3: Scan for subnodes
On Thu, 20 Mar 2025 13:51:56 +0100, Patrick Rudolph wrote: > According to the binding [1] the ITS node should be a subnode of the > GICv3 node. Since the ITS node has it's own driver, manually probe for > possible subnodes after binding since dm_scan_fdt() is not recursive. > > 1: > https://www.kernel.org/doc/Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic-v3.txt > > > [...] Applied to u-boot/master, thanks! [1/3] arm: gic-v3: Scan for subnodes commit: 6554cb460bfc0d1a21406da49bf44f029b5aa185 [2/3] emulation: qemu-sbsa: Move ITS node into GICv3 node commit: d5a060b01b322231725dfc38090d8dc5e080cd33 [3/3] emulation: qemu-sbsa: Fill in correct ITS ID commit: 65504478fe44f6dd8b61907efa4eaeba5b79cbf5 -- Tom
Re: [PATCH] ata: ahci: remove bad free
On Mon, 24 Mar 2025 09:34:06 +0100, Vincent Stehlé wrote: > In the case of a memory allocation error, the ahci_port_start() function > tries to free the `pp' pointer. > This pointer was not dynamically allocated but does in fact point to an > element of the port[] array member of the struct ahci_uc_priv. > Remove the erroneous call to free() to fix this. > > > [...] Applied to u-boot/master, thanks! [1/1] ata: ahci: remove bad free commit: a345f44a60f57a2741cda9315312d3df28bc22f0 -- Tom
Re: [PATCH] CI: Disable evb-ast2600
On Wed, 09 Apr 2025 18:31:21 -0600, Tom Rini wrote: > Currently, this platform is failing in CI due to seemingly platform > specific reasons. For now, remove it from CI until the maintainers have > a chance to look in to it. > > Applied to u-boot/master, thanks! [1/1] CI: Disable evb-ast2600 commit: 8a2cf6307a2ccc09c39dde486b6d9375b78c82c2 -- Tom
[PATCH] CI: Disable evb-ast2600
Currently, this platform is failing in CI due to seemingly platform
specific reasons. For now, remove it from CI until the maintainers have
a chance to look in to it.
Signed-off-by: Tom Rini
---
While it's poor form to apply changes quickly after posting, this has
been reported by 3 separate custodians having CI fail due to this change
being triggered in their tree. I will be applying this shortly to
unblock others.
Cc: Eugen Hristev
Cc: Kever Yang
Cc: Marek Vasut
Cc: Ryan Chen
Cc: Chia-Wei Wang
Cc: Aspeed BMC SW team
Cc: Joel Stanley
---
.azure-pipelines.yml | 4
.gitlab-ci.yml | 7 ---
2 files changed, 11 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index d5cfa59a8a61..7a33d403a77c 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -420,10 +420,6 @@ stages:
TEST_PY_BD: "evb-ast2500"
TEST_PY_ID: "--id qemu"
TEST_PY_TEST_SPEC: "not sleep"
-evb_ast2600:
- TEST_PY_BD: "evb-ast2600"
- TEST_PY_ID: "--id qemu"
- TEST_PY_TEST_SPEC: "not sleep"
vexpress_ca9x4:
TEST_PY_BD: "vexpress_ca9x4"
TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 0f27e67abb99..42ec28a9ad8b 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -328,13 +328,6 @@ evb-ast2500 test.py:
TEST_PY_ID: "--id qemu"
<<: *buildman_and_testpy_dfn
-evb-ast2600 test.py:
- variables:
-TEST_PY_BD: "evb-ast2600"
-TEST_PY_TEST_SPEC: "not sleep"
-TEST_PY_ID: "--id qemu"
- <<: *buildman_and_testpy_dfn
-
sandbox_flattree test.py:
tags:
- ${DEFAULT_AMD64_TAG}
--
2.43.0
Re: [PATCH 2/2] qcom_defconfig: Disable MMC HS200 mode support
On Tue, Apr 08, 2025 at 02:13:55PM +0200, Caleb Connolly wrote: > > > On 4/8/25 06:29, Sumit Garg wrote: > > On Mon, Apr 07, 2025 at 04:30:44PM +0200, Caleb Connolly wrote: > > > > > > > > > On 4/7/25 15:28, Sumit Garg wrote: > > > > From: Sumit Garg > > > > > > > > Currently the msm_sdhci doesn't yet support DLL configurations which are > > > > required to enable bus speeds greater that 100MHz. So disable HS200 mode > > > > support as of now as it requires bus speeds of 200MHz. > > > > > > > > This should fix eMMC issues reported on RB1. > > > > > > This fixes the write corruption issues? Nice find!! > > > > Yeah, thanks. > > > > > > > > Is this a problem on ALL Qualcomm platforms? the sdcard seems to work fine > > > on other boards, would this reduce their performance? > > > > Yes this problem should affect all Qualcomm platforms but it hasn't been > > seen there as mostly SD cards available don't support HS200 mode. The SD > > cards usually works in high speed mode whose performance remains > > unaffected by this change. It only affects RB1/RB2 as eMMC flash on > > these support HS200 mode but the U-Boot driver currently is incapable of > > supporting that. > > Ok awesome. Could you include this info in the commit message? Then Sure, I can expand the commit message. > > Reviewed-by: Caleb Connolly > Thanks. -Sumit
Re: [PATCH v2 1/2] net-lwip: wget: add LMB and buffer checks
On 09.04.25 14:20, Jerome Forissier wrote:
Legacy NET wget invokes a store_block() function which performs buffer
validation (LMB, address wrapping). Do the same with NET_LWIP.
Signed-off-by: Jerome Forissier
Suggested-by: Sughosh Ganu
---
net/lwip/wget.c | 49 +
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/net/lwip/wget.c b/net/lwip/wget.c
index 14f27d42998..746c8164d66 100644
--- a/net/lwip/wget.c
+++ b/net/lwip/wget.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include "lwip/altcp_tls.h"
#include
@@ -201,11 +202,44 @@ static int parse_legacy_arg(char *arg, char *nurl, size_t
rem)
return 0;
}
Please, add Sphinx style descriptions to all functions.
+static int store_block(struct wget_ctx *ctx, void *src, u16_t len)
+{
+ ulong store_addr = ctx->daddr;
+ uchar *ptr;
+
+ /* Avoid overflow */
+ if (wget_info->buffer_size && wget_info->buffer_size < ctx->size + len)
+ return -1;
+
+ if (CONFIG_IS_ENABLED(LMB) && wget_info->set_bootdev) {
+ if (store_addr + len < store_addr ||
+ lmb_read_check(store_addr, len)) {
+ printf("\nwget error: ");
+ printf("trying to overwrite reserved memory...\n");
Output while an EFI application is consuming the HTTP protocol should be
avoided as it is not compatible with the EFI console.
If you want console output in the wget command, please, implement it
there and not in a library function called by efi_net_do_request().
+ return -1;
+ }
+ }
+
+ ptr = map_sysmem(store_addr, len);
+ memcpy(ptr, src, len);
+ unmap_sysmem(ptr);
+
+ ctx->daddr += len;
+ ctx->size += len;
+ if (ctx->size - ctx->prevsize > PROGRESS_PRINT_STEP_BYTES) {
+ printf("#");
ditto
Best regards
Heinrich
+ ctx->prevsize = ctx->size;
+ }
+
+ return 0;
+}
+
static err_t httpc_recv_cb(void *arg, struct altcp_pcb *pcb, struct pbuf
*pbuf,
err_t err)
{
struct wget_ctx *ctx = arg;
struct pbuf *buf;
+ err_t ret;
if (!pbuf)
return ERR_BUF;
@@ -214,18 +248,17 @@ static err_t httpc_recv_cb(void *arg, struct altcp_pcb
*pcb, struct pbuf *pbuf,
ctx->start_time = get_timer(0);
for (buf = pbuf; buf; buf = buf->next) {
- memcpy((void *)ctx->daddr, buf->payload, buf->len);
- ctx->daddr += buf->len;
- ctx->size += buf->len;
- if (ctx->size - ctx->prevsize > PROGRESS_PRINT_STEP_BYTES) {
- printf("#");
- ctx->prevsize = ctx->size;
+ if (store_block(ctx, buf->payload, buf->len) < 0) {
+ altcp_abort(pcb);
+ ret = ERR_BUF;
+ goto out;
}
}
-
altcp_recved(pcb, pbuf->tot_len);
+ ret = ERR_OK;
+out:
pbuf_free(pbuf);
- return ERR_OK;
+ return ret;
}
static void httpc_result_cb(void *arg, httpc_result_t httpc_result,
Re: [PATCH] net: dhcpv6: remove excluded middle expression
Hi Bryan,
On 4/8/25 23:57, Bryan Brattlof wrote:
> !A || (A && B) is equivalent to !A || B
>
> Drop the middle expression from the statement
>
> Signed-off-by: Bryan Brattlof
> ---
> net/dhcpv6.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/dhcpv6.c b/net/dhcpv6.c
> index 54619ee698362..65ec48ef665e5 100644
> --- a/net/dhcpv6.c
> +++ b/net/dhcpv6.c
> @@ -473,8 +473,7 @@ static int dhcp6_check_advertise_packet(uchar *rx_pkt,
> unsigned int len)
>* server UID, save the new server UID and preference
>*/
> if (!sm_params.server_uid.uid_ptr ||
> - (sm_params.server_uid.uid_ptr &&
> - sm_params.server_uid.preference <
> sm_params.rx_status.preference)) {
> + sm_params.server_uid.preference <
> sm_params.rx_status.preference) {
> rx_uid_size = sm_params.rx_status.server_uid_size;
> if (sm_params.server_uid.uid_ptr)
> free(sm_params.server_uid.uid_ptr);
Reviewed-by: Jerome Forissier
Thanks,
--
Jerome
[PATCH v2 0/2] NET_LWIP LMB fixes
Two small patches fixing issues with tftp and wget when the network stack is NET_LWIP and LMB is enabled. Changes in v2: - The wget patch adds a call to altcp_abort(). Otherwise the transfer continues and we try to write later blocks which makes no sense if one has been rejected already. Thanks Sughosh G. for testing and reporting. - The tftp patch is unchanged. Jerome Forissier (2): net-lwip: wget: add LMB and buffer checks net-lwip: tftp: add LMB and buffer checks net/lwip/tftp.c | 45 ++--- net/lwip/wget.c | 49 + 2 files changed, 75 insertions(+), 19 deletions(-) -- 2.43.0
Re: [PATCH v2] common: Add CONFIG_SKIP_RELOCATE
On Wed, Apr 9, 2025 at 3:17 PM Jesse Taube wrote: > > Add a check for CONFIG_SKIP_RELOCATE in reserve_uboot to skip the > relocation of the U-Boot image. > CONFIG_SKIP_RELOCATE skips relocation of U-Boot to the end of RAM > allowing for systems that have extremely limited RAM to run U-Boot. > > Signed-off-by: Jesse Taube > Reviewed-by: Tom Rini > Reviewed-by: Caleb Connolly Reviewed-by: Fabio Estevam
Community meeting April 8th 2025 (was: Re: [ANN] U-Boot v2025.04 released)
Hi Everyone, On 4/8/25 00:00, Tom Rini wrote: Hey all, It's release day and here's v2025.04. We had some last minute issues reported, but then also resolved. I want to thank everyone that's contributed to this release, not just in terms of code, but documentation, testing and otherwise ensuring things go as smoothly as they can. In terms of a changelog, git log --merges v2025.04-rc5..v2025.04 contains what I've pulled since the last RC or: git log --merges v2025.01..v2025.04 for changes since the last full release. As always, more details in pull requests (or the tags referenced by them) will result in more details here. As is becoming reguarly scheduled, we have a community meeting tomorrow (for me anyhow). The meeting details itself are: https://meet.google.com/btj-wgcg-euw April 7th, 2025. 9am (GMT -06:00) To join by phone: https://meet.google.com/tel/btj-wgcg-euw?pin=3D1307528552322&hs=3D1 The meeting can be added to your calendar via the link on https://www.u-boot.org/ Here are the notes from the meeting, please feel free to clarify any points I might have missed or gotten wrong. Thanks Tom for chairing. # U-Boot Community meeting April 8 2025 * Tom intro: next merged into master, small delay * Heinrich: ACPI has regular regressions due to lack of testing in CI * tom proposes adding another QEMU defconfig with ACPI enabled * Heinrich: Ubuntu images being used in CI are getting too old * tom: has a patch to update to GCC 14 * tom: opened an issue, Simon to investigate (link?) * tom: already tested new GCC/LLVM, no new warnings. * tom: will rebuild docker container this week, adding byacc for binman to enable IMX8 testing * state of Simons patches re: bootflow/EFI/standard boot * issue with standard boot that the EFI bootmgr option is always at the top * heinrich: proposes a new virtual device that can be ordered anywhere * heinrich will investigate in the next few weeks * tom: modernising the Makefile * tom: which platforms are still using old stuff? will consider disabling or removing boards * tom: e.g. watchdog (deadline 2019), legacy i2c (deadline 2022.04) * caleb: FdtFile revival * context: https://github.com/systemd/systemd/issues/36835 * would enable picking DTB matching your kernel version * heinrich: robh thinks we should match on compatible instead. Simon also agrees * heinrich: fine with adding this patch * simon: significant harm - compatible is the only right way to match, anything else is a workaround * caleb/tom: agrees in theory, but in practise this isn't what we witness. Having a compressed blob of all DTs would be ideal, and compresses well, but nobody is doing this.. * heinrich: U-Boot is also not the only firmware, we can't expect EDK2 to start shipping this. * Ilias: Agrees, best of the bad options * simon: what would be the right solution? * caleb: have the kernel emit a file with compatible -> fdtfile lookups since that's faster to read * Bryan Brattlof: what about overlays? * caleb: probably you have a more vertically integrated system * bryan: customers want yocto and a redhat image that works ootb * tom/simon: bloblist: * tom: if bloblist is enabled it MUST have the DT, set the "mandatory passage flag" * simon: OF_BLOBLIST means DT is in bloblist * tom: it's a bad idea to divorce standard passage handoff from bloblist, but if it eases some issues for now and we can revisit in a ~year that might be best * ilias: we have discussed this before. doesn't think OF_BLOBLIST should exist, because the info is discoverable at runtime. * ilias: we have a standard (firmware handoff), why do we need another implementation? * tom: hoping to reconcile over time between fw handoff and bloblist * tom: to re-iterate what Simon said: dt should be either in bloblist, embedded, or discovered through board specific means. Need to avoid conflating consuming bloblist and creating bloblist (e.g. in SPL). * tom: in SPL, if we don't have a bloblist, we don't need a config option. * tom: we should remove BLOBLIST_FIXED * simon: we can get rid of BLOBLIST_FIXED if we have a register hand-off firmware (x86) * out of time... Tom ok to add OF_BLOBLIST if we remove BLOBLIST_FIXED. Hopes that in ~1 year we'll all agree that we want the same thing... The merge window is formally open again. I will be merging next in to master shortly. The v2025.07 release is scheduled for Monday, July 7th, 2025 and the merge window will close and -rc1 will be released on the 28th of April, and then the next window will open with -rc2, two weeks later. The keen-eyed among you might notice that I fixed some incorrect -rc1 dates in the future planning section, including for this cycle. Thanks all! -- Caleb (they/them)
RE: [PATCH v2 4/8] board: starfive: spl: support DeepComputing FML13V01
> On 31.03.25 15:24, Heinrich Schuchardt wrote:
>
> On the DeepComputing Framework motherboard (FML13V01) choose the
> matching FIT configuration.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> rebased
> ---
> board/starfive/visionfive2/spl.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/board/starfive/visionfive2/spl.c
> b/board/starfive/visionfive2/spl.c
> index 13a48939c8f..52f75471de5 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -125,7 +125,10 @@ int board_fit_config_name_match(const char
> *name)
> if (strncmp(name, "starfive/", 9))
> return -EINVAL;
> name += 9;
> - if (!strncmp(product_id, "VF7110", 6)) {
> + if (!strncmp(product_id, "FML13V01", 8) &&
> + !strcmp(name, "jh7110-deepcomputing-fml13v01")) {
> + return 0;
> + } else if (!strncmp(product_id, "VF7110", 6)) {
> version = get_pcb_revision_from_eeprom();
> if ((version == 'b' || version == 'B') &&
> !strcmp(name, "jh7110-starfive-visionfive-2-v1.3b"))
Reviewed-by: Hal Feng
Best regards,
Hal
RE: [EXT] [PATCH] crypto: fsl - Fix RNG generation for lengths greater than 16 bytes
Hi Pawel
> -Original Message-
> From: Paweł Kochanowski
> Sent: Tuesday, April 8, 2025 4:30 PM
> To: Gaurav Jain ; u-boot@lists.denx.de
> Cc: Priyanka Jain ; Gabriel Nesteruk
> ; Pankaj Gupta ; Horia Geanta
>
> Subject: RE: [EXT] [PATCH] crypto: fsl - Fix RNG generation for lengths
> greater
> than 16 bytes
>
> [You don't often get email from pkochanow...@sii.pl. Learn why this is
> important
> at https://aka.ms/LearnAboutSenderIdentification ]
>
> Caution: This is an external email. Please take care when clicking links or
> opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> Hi Gaurav,
>
> What we see is that the jr_enqueue() called by run_descriptor_jr() swaps the
> endianness of the descriptor in place (by modifying the data pointed by
> desc_add):
>
> /* The descriptor must be submitted to SEC block as per endianness
> * of the SEC Block.
> * So, if the endianness of Core and SEC block is different, each word
> * of the descriptor will be byte-swapped.
> */
> for (i = 0; i < length; i++) {
> desc_word = desc_addr[i];
> sec_out32((uint32_t *)&desc_addr[i], desc_word);
> }
>
> So the sequence looks like this:
> 1. caam_rng_probe sets correct descriptor in ` caam_rng_priv *priv` 2.
> caam_rng_read is called with 32B 3. caam_rng_read_one->run_descriptor_jr() is
> called to generate 16B with `priv->desc` containing valid descriptor 4. The
> descriptor is swapped in jr_enqueue() before passing it to job ring
I see you are right. In Linux, caam endianness is handled at the time of
creating the descriptor.
But In Uboot, caam endianness is not handled at the time of descriptor creation.
5. The loop in
> caam_rng_read is called second time, this time the `priv->desc` contain
> swapped
> data.
>
> Interesting thing is that the job still succeeds and that some data are
> present in
> the buffers, but maybe swapped descriptor can also be a valid one?
I agree that the descriptor should be reinitialized for each RNG job.
I am also not sure how the swapped descriptor worked second time.
> The effect that we see is that when leaving the command executing this
> sequence
> we get an exception in "unrelated" place..
After your change you stop seeing this exception? Are you sure it is related to
rng descriptor?
>
> This is what we see when printing descriptor in the caam_rng_read_one on
> LS1046A:
>
> First iteration:
> 0: B085
> 1: 8252
> 2: 60340010
> 3: 0
> 4: FBC94DC0
4th word is seqoutptr: sgf pre ext (ews). Have you also modified the descriptor
?
Regards
Gaurav
>
> Second iteration:
> 0: 050080B0
> 1: 02005082
> 2: 10003460
> 3: 0
> 4: C04DC9FB
>
> BR,
> Pawel.
>
> > From: Gaurav Jain
> > Sent: Tuesday, April 8, 2025 12:09 PM
> >
> > Can you explain more details about this issue. Where it is being
> > modified in
> > run_descriptor_jr() ?
> > Regards
> > Gaurav
> >
> > > -Original Message-
> > > From: Pawel Kochanowski
> > > Sent: Monday, April 7, 2025 6:17 PM
> > > To: u-boot@lists.denx.de
> > > Cc: Priyanka Jain ; Gaurav Jain
> > > ; Gabriel Nesteruk ; Paweł
> > > Kochanowski
> > > Subject: [EXT] [PATCH] crypto: fsl - Fix RNG generation for lengths
> > > greater than 16 bytes
> > >
> > > [You don't often get email from pkochanow...@sii.pl. Learn why this
> > > is important at https://aka.ms/LearnAboutSenderIdentification ]
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the
> > 'Report this email'
> > > button
> > >
> > >
> > > From: Gabriel Nesteruk
> > >
> > > Reinitialize the descriptor for each RNG job, as it may be modified
> > > by run_descriptor_jr().
> > > Failing to do so can result in memory corruption when
> > > dm_rng_read() is called a second time on NXP devices with
> > > CONFIG_SYS_FSL_SEC_BE enabled.
> > >
> > > Signed-off-by: Gabriel Nesteruk
> > > Signed-off-by: Pawel Kochanowski
> > > ---
> > > drivers/crypto/fsl/rng.c | 14 ++
> > > 1 file changed, 6 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/crypto/fsl/rng.c b/drivers/crypto/fsl/rng.c
> > > index
> > > 06364948052..440b26e3c94 100644
> > > --- a/drivers/crypto/fsl/rng.c
> > > +++ b/drivers/crypto/fsl/rng.c
> > > @@ -27,8 +27,14 @@ struct caam_rng_priv { static int
> > > caam_rng_read_one(struct caam_rng_priv *priv) {
> > > int size = ALIGN(CAAM_RNG_MAX_FIFO_STORE_SIZE,
> > > ARCH_DMA_MINALIGN);
> > > + ulong rng_desc_size = ALIGN(CAAM_RNG_DESC_LEN,
> > > + ARCH_DMA_MINALIGN);
> > > int ret;
> > >
> > > + inline_cnstr_jobdesc_rng(priv->desc, priv->data,
> > > + CAAM_RNG_MAX_FIFO_STORE_SIZE);
> > > + flush_dcache_range((unsigned long)priv->desc,
> > > + (unsigned long)priv->desc + rng_desc_size);
> > > +
> > > ret = run_descriptor_jr(priv-
RE: [PATCH v2 3/8] board: starfive: DeepComputing FML13V01 fdt selection
> On 31.03.25 15:24, Heinrich Schuchardt wrote:
>
> We support all JH7110 boards with starfive_visionfive2_defconfig.
> The relevant device-tree is selected at runtime based on EEPROM data.
>
> Support setting $fdtfile to the file name of the DeepComputing Framework
> motherboard (FML13V01) device-tree.
>
> Signed-off-by: Heinrich Schuchardt
> Reviewed-by: Hal Feng
> ---
> v2:
> no change
> ---
> board/starfive/visionfive2/starfive_visionfive2.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
> b/board/starfive/visionfive2/starfive_visionfive2.c
> index 3940d45b13f..55daf730c81 100644
> --- a/board/starfive/visionfive2/starfive_visionfive2.c
> +++ b/board/starfive/visionfive2/starfive_visionfive2.c
> @@ -17,6 +17,8 @@
> DECLARE_GLOBAL_DATA_PTR;
> #define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
> #define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
> +#define FDTFILE_FML13V01 \
> + "starfive/jh7110-deepcomputing-fml13v01.dtb"
> #define FDTFILE_MILK_V_MARS \
> "starfive/jh7110-milkv-mars.dtb"
> #define FDTFILE_MILK_V_MARS_CM \
> @@ -67,7 +69,9 @@ static void set_fdtfile(void)
> log_err("Can't read EEPROM\n");
> return;
> }
> - if (!strncmp(product_id, "MARC", 4)) {
> + if (!strncmp(product_id, "FML13V01", 8)) {
> + fdtfile = FDTFILE_FML13V01;
> + } else if (!strncmp(product_id, "MARC", 4)) {
> if (get_mmc_size_from_eeprom())
> fdtfile = FDTFILE_MILK_V_MARS_CM;
> else
As Mars CM (Lite) is no longer supported since patch [1], this patch should be
updated.
[1] https://lore.kernel.org/all/20250327175550.529248-...@freeshell.de/
Best regards,
Hal
[PATCH 1/2] arm64: versal2: Remove dtb reselect and multi dtb
Presently the multi dtb's are not using on versal Gen 2 platform, so remove CONFIG_DTB_RESELECT and CONFIG_MULTI_DTB_FIT from defconfig. Signed-off-by: Padmarao Begari --- configs/amd_versal2_virt_defconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/configs/amd_versal2_virt_defconfig b/configs/amd_versal2_virt_defconfig index 9911caa0e46..1b8bd17fa8e 100644 --- a/configs/amd_versal2_virt_defconfig +++ b/configs/amd_versal2_virt_defconfig @@ -64,8 +64,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_CMD_UBI=y CONFIG_PARTITION_TYPE_GUID=y CONFIG_OF_BOARD=y -CONFIG_DTB_RESELECT=y -CONFIG_MULTI_DTB_FIT=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_LWIP=y -- 2.44.1
Re: [PATCH v4 09/10] rockchip: binman: Support use of crc32 for SPL_FIT_SIGNATURE
Hi Simon,
On 4/9/25 6:35 PM, Simon Glass wrote:
Hi Quentin,
On Wed, 9 Apr 2025 at 10:11, Quentin Schulz wrote:
Hi Jonas,
On 4/9/25 5:38 PM, Jonas Karlman wrote:
Hi Quentin,
On 2025-04-09 13:06, Quentin Schulz wrote:
Hi Jonas,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
Use of SHA256 checksum validation on ARMv7 SoCs can be very time
consuming compared to ARMv8 SoCs with Crypto Extensions.
Add support for use of the crc32 hash algo when SHA256 is not supported.
Also use a HAS_HASH to simplify the ifdefs when no known hash algo is
compiled.
Signed-off-by: Jonas Karlman
I don't know enough about general security but this very much looks like
a bad idea to me.
https://web.archive.org/web/20170210173741/http://www.derkeiler.com/Newsgroups/sci.crypt/2003-07/1451.html
"""
While properly designed CRC's are good at detecting random errors in
the data (due to e.g. line noise), the CRC is useless as a secure
indicator of intentional manipulation of the data. And this is
because it's not hard at all to modify the data to produce any CRC
you desire (e.g. the same CRC as the original data, to try to
disguise your data manipulation).
"""
(yes I took the "first" link my web search engine returned me, thanks
confirmation bias!).
I am fully aware, and the fallback to use crc32, and current primarily
use of sha256, should not be considered a security feature. It is
intended purely for a checksum validation of the binary blob after it
has been loaded into memory and before U-Boot otherwise unconditionally
jumps to and execute the loaded blob of binary code.
I don't want to give people a false sense of security. If it really
comes down to it, I'd rather have an explicit Kconfig symbol to set this
value (maybe have a `choice` even) and be very clear about security
implications.
Prior to the addition of the hash { algo=sha256 }, there was no checksum
test and U-Boot SPL would unconditionally jump to the loaded data, even
if it had been corrupted, was only halfway written or otherwise
overwritten.
The addition of crc32 instead of sha256 is just to allow older board
variants with weaker SoCs to at least have some sort of checksum
validation in use without affecting the boot time too much.
On my rk3228 board, validation using sha256 could take a few seconds,
and with crc32 it could be measured in ms.
To me, having at least some default checksum validation is preferred
over none at all.
Except if this confuses people into thinking they have a secure system
except they use CRC32 instead of something more appropriate like SHA256.
It seems like the "hash" node presence doesn't mean a FIT conf or image
node is signed. I also don't see many device trees with a signature
node... which is kinda odd. Looking a bit into the signature node in the
spec and binman tests, it's not clear to me if the hash node is reused
by the signature node if if exists and if their algo should match and
what exactly is checked by the signature node (like signing the hash
string contained in the hash node(s) listed in sign-images property, or
(re-)generating a hash of those and signing it at build time?
If
a) it is not possible to have a hash node's algo differ from a signature
node's algo, then I'm fine with this as crc32 won't be allowed
b) the signature node regenerates a hash regardless of the hash in the
hash node, meaning the signature will be "appropriately secure"
regardless of the algorithm listed in the hash node, then I'm fine with
it too,
c) it is possible to sign a crc32 hash, don't want it :)
@Simon, do you have some hints about this?
In fit.py :
# The hash subnodes here are for mkimage, not binman.
entry.SetUpdateHash(False)
so yes they are independent, so far as Binman is concerned.
But of course, configuration signing relies on hashes in the image
nodes, so at least one strong hash is needed.
Would/Could/Should those image node hash subnodes be autogenerated
during signing based on the selected algo? In which case, only the algo
in the signature subnode would actually matter from security PoV.
Cheers,
Quentin
[PATCH 0/6] Qualcomm: cleanup OF_LIVE fixup and fix RB1/2
Introduce a new event to signal that the live tree has been built, allowing boards to perform fixups on the tree before devices are bound. Crucially this allows for devices to be enabled or disabled, but also allows for properties that are parsed during the bind stage to be modified (such as dr_mode for dwc3). With this in place, mach-snapdragon is switched over to use the event and some hacky U-Boot specific DT overrides (which had to be undone prior to booting an image) are removed in favour of fixing up the livetree (which is not passed on to further boot stages). Finally, some minor fixes are made for the QCM2290 RB1 board, the sdcard is enabled and it now uses USB host mode in U-Boot like it's bigger sibling the RB2. --- Caleb Connolly (6): event: signal when livetree has been built mach-snapdragon: use EVT_OF_LIVE_INIT to apply DT fixups mach-snapdragon: of_fixup: skip disabled USB nodes clk/qcom: qcm2290: show clock name in set_rate() mach-snapdragon: of_fixup: set dr_mode for RB1/2 boards pinctrl: qcom: qcm2290: fix off by 1 in pin_count arch/arm/dts/qrb4210-rb2-u-boot.dtsi | 6 - arch/arm/mach-snapdragon/board.c | 1 - arch/arm/mach-snapdragon/of_fixup.c| 41 -- arch/arm/mach-snapdragon/qcom-priv.h | 14 common/event.c | 3 +++ drivers/clk/qcom/clock-qcm2290.c | 2 +- drivers/pinctrl/qcom/pinctrl-qcm2290.c | 2 +- include/event.h| 9 lib/of_live.c | 3 +++ 9 files changed, 41 insertions(+), 40 deletions(-) --- base-commit: e4ffc6a323586d700d88c73c319c25c740aedb49 change-id: 20250409-livetree-fixup-0d7451cc3af3 Caleb Connolly
[PATCH 4/6] clk/qcom: qcm2290: show clock name in set_rate()
The device name is always clk_qcom... Not very useful.
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-qcm2290.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/clock-qcm2290.c b/drivers/clk/qcom/clock-qcm2290.c
index
1326b770c3ebd723120de4b6657aafac726023d6..fad104fb91aec8917de66b63dd546926c8856011
100644
--- a/drivers/clk/qcom/clock-qcm2290.c
+++ b/drivers/clk/qcom/clock-qcm2290.c
@@ -87,9 +87,9 @@ static ulong qcm2290_set_rate(struct clk *clk, ulong rate)
{
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
const struct freq_tbl *freq;
- debug("%s: clk %s rate %lu\n", __func__, clk->dev->name, rate);
+ debug("%s: clk %s rate %lu\n", __func__, qcm2290_clks[clk->id].name,
rate);
switch (clk->id) {
case GCC_QUPV3_WRAP0_S4_CLK: /*UART2*/
freq = qcom_find_freq(ftbl_gcc_qupv3_wrap0_s0_clk_src, rate);
--
2.49.0
[PATCH 5/6] mach-snapdragon: of_fixup: set dr_mode for RB1/2 boards
The RB1 and RB2 have a single USB controller which is manually muxed
between a type-c port and an internal USB hub via a DIP switch. OTG is
supported in Linux, but the DWC3 driver in U-Boot can only handle a
single mode, and defaults to peripheral mode.
We did hack around this on the RB2, but the RB1 got left out.
Now that we can fix up the live tree before devices are bound, drop the
DTS hacks and do the fixup at runtime instead.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/qrb4210-rb2-u-boot.dtsi | 6 --
arch/arm/mach-snapdragon/of_fixup.c | 28 ++--
2 files changed, 14 insertions(+), 20 deletions(-)
diff --git a/arch/arm/dts/qrb4210-rb2-u-boot.dtsi
b/arch/arm/dts/qrb4210-rb2-u-boot.dtsi
deleted file mode 100644
index
7d1375f38c44d7bd54c022fa3d390f666a35d6ee..
--- a/arch/arm/dts/qrb4210-rb2-u-boot.dtsi
+++ /dev/null
@@ -1,6 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-
-/* This is usually OTG but U-Boot doesn't support that properly */
-&usb_dwc3 {
- dr_mode = "host";
-};
diff --git a/arch/arm/mach-snapdragon/of_fixup.c
b/arch/arm/mach-snapdragon/of_fixup.c
index
b39036e8e0890fdf834a0dfe6966ef3dd365f3d2..62b329e2c90d7e0a374838968ab5707333edbf03
100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -98,8 +98,21 @@ static int fixup_qcom_dwc3(struct device_node *glue_np)
log_err("Failed to set 'maximum-speed' property: %d\n", ret);
return ret;
}
+ /*
+* The RB1/2 boards only have a single USB controller and it's muxed
between the type-C port
+* and a USB hub. Since we can't do OTG in U-Boot properly we prefer to
put it into host mode.
+*/
+ if (of_device_is_compatible(gd->of_root, "qcom,qrb4210-rb2", NULL,
NULL) ||
+ of_device_is_compatible(gd->of_root, "qcom,qrb2210-rb1", NULL,
NULL)) {
+ ret = of_write_prop(dwc3, "dr_mode", sizeof("host"), "host");
+ if (ret) {
+ log_err("Failed to set 'dr_mode' property: %d\n", ret);
+ return ret;
+ }
+ }
+
return 0;
}
static void fixup_usb_nodes(void)
@@ -162,21 +175,8 @@ static int qcom_of_fixup_nodes(void)
}
EVENT_SPY_SIMPLE(EVT_OF_LIVE_INIT, qcom_of_fixup_nodes);
-int ft_board_setup(void *blob, struct bd_info __maybe_unused *bd)
+int ft_board_setup(void __maybe_unused *blob, struct bd_info __maybe_unused
*bd)
{
- struct fdt_header *fdt = blob;
- int node;
-
- /* On RB1/2 we need to fix-up the dr_mode */
- if (!fdt_node_check_compatible(fdt, 0, "qcom,qrb4210-rb2") ||
- !fdt_node_check_compatible(fdt, 0, "qcom,qrb2210-rb1")) {
- fdt_for_each_node_by_compatible(node, blob, 0, "snps,dwc3") {
- log_debug("%s: Setting 'dr_mode' to OTG\n",
fdt_get_name(blob, node, NULL));
- fdt_setprop_string(fdt, node, "dr_mode", "otg");
- break;
- }
- }
-
return 0;
}
--
2.49.0
[PATCH 1/6] event: signal when livetree has been built
OF_LIVE offers a variety of benefits, one of them being that the live
tree can be modified without caring about the underlying FDT. This is
particularly valuable for working around U-Boot limitations like lacking
USB superspeed support on Qualcomm platforms, no runtime OTG, or
peripherals like the sdcard being broken (and displaying potentially
worrying error messages).
Add an event to signal when the live tree has been built so that we can
apply fixups to it directly before devices are bound.
Signed-off-by: Caleb Connolly
---
common/event.c | 3 +++
include/event.h | 9 +
lib/of_live.c | 3 +++
3 files changed, 15 insertions(+)
diff --git a/common/event.c b/common/event.c
index
dda569d447851f559a83f98fb7b1f3543156eab5..8d7513eb10b61919e1e784481dfdcc076be14986
100644
--- a/common/event.c
+++ b/common/event.c
@@ -47,8 +47,11 @@ const char *const type_name[] = {
"ft_fixup",
/* main loop events */
"main_loop",
+
+ /* livetree has been built */
+ "of_live_init",
};
_Static_assert(ARRAY_SIZE(type_name) == EVT_COUNT, "event type_name size");
#endif
diff --git a/include/event.h b/include/event.h
index
75141a192a48b0931667632f41be8ff4d6139f7c..3fc673ba635ed45467aae8587705d37bef1c2a3f
100644
--- a/include/event.h
+++ b/include/event.h
@@ -152,8 +152,17 @@ enum event_t {
* A non-zero return value causes the boot to fail.
*/
EVT_MAIN_LOOP,
+ /**
+* @EVT_OF_LIVE_INIT:
+* This event is triggered immediately after the live device tree has
been
+* built. This allows for machine specific fixups to be done to the
live tree
+* (like disabling known-unsupported devices) before DM init happens.
This
+* event is only available if OF_LIVE is enabled and is only used after
relocation.
+*/
+ EVT_OF_LIVE_INIT,
+
/**
* @EVT_COUNT:
* This constants holds the maximum event number + 1 and is used when
* looping over all event classes.
diff --git a/lib/of_live.c b/lib/of_live.c
index
90b9459ede313e492e28c8556c730f3bd8aaa9df..e1962b8f1fb9d8c2c87d04ca4e238a1e4d00376a
100644
--- a/lib/of_live.c
+++ b/lib/of_live.c
@@ -10,8 +10,9 @@
#define LOG_CATEGORY LOGC_DT
#include
+#include
#include
#include
#include
#include
@@ -334,8 +335,10 @@ int of_live_build(const void *fdt_blob, struct device_node
**rootp)
return ret;
}
debug("%s: stop\n", __func__);
+ event_notify_null(EVT_OF_LIVE_INIT);
+
return ret;
}
void of_live_free(struct device_node *root)
--
2.49.0
[PATCH 6/6] pinctrl: qcom: qcm2290: fix off by 1 in pin_count
There are 134 pins not 133, oops! This fixes the sdcard on the RB1 as
the pins now all get configured correctly.
Fixes: 0ecb8cfcb930 ("pinctrl: qcom: add qcm2290 pinctrl driver")
Signed-off-by: Caleb Connolly
---
drivers/pinctrl/qcom/pinctrl-qcm2290.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-qcm2290.c
b/drivers/pinctrl/qcom/pinctrl-qcm2290.c
index
0cce663e6d584d229e7521f88fedf8aa19da..84f76b63b93ad78182524661dba561672feb4c85
100644
--- a/drivers/pinctrl/qcom/pinctrl-qcm2290.c
+++ b/drivers/pinctrl/qcom/pinctrl-qcm2290.c
@@ -44,9 +44,9 @@ static int qcm2290_get_function_mux(__maybe_unused unsigned
int pin, unsigned in
}
struct msm_pinctrl_data qcm2290_data = {
.pin_data = {
- .pin_count = 133,
+ .pin_count = 134,
.special_pins_start = 127,
},
.functions_count = ARRAY_SIZE(msm_pinctrl_functions),
.get_function_name = qcm2290_get_function_name,
--
2.49.0
[PATCH 2/6] mach-snapdragon: use EVT_OF_LIVE_INIT to apply DT fixups
This will now apply fixups prior to devices being bound, which makes it
possible to enable/disable devices and adjust more properties that might
be read before devices probe.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/board.c | 1 -
arch/arm/mach-snapdragon/of_fixup.c | 7 ++-
arch/arm/mach-snapdragon/qcom-priv.h | 14 --
3 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index
deae4d323789eab75d5fe735159b4cd820c02c45..3ab75f0fce02ecffd476ebe2aa606b1a9024bbec
100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -305,9 +305,8 @@ void __weak qcom_board_init(void)
int board_init(void)
{
show_psci_version();
- qcom_of_fixup_nodes();
qcom_board_init();
return 0;
}
diff --git a/arch/arm/mach-snapdragon/of_fixup.c
b/arch/arm/mach-snapdragon/of_fixup.c
index
1ea0c18c2f2789a8aa054cd95bb9e4308d6b3384..d4e24059212c552de7fa7555d2ab8a1ea4fc4cb2
100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -21,8 +21,9 @@
#include
#include
#include
+#include
#include
#include
#include
#include
@@ -149,14 +150,18 @@ static void fixup_power_domains(void)
func(__VA_ARGS__); \
debug(#func " took %lluus\n", timer_get_us() - start); \
} while (0)
-void qcom_of_fixup_nodes(void)
+static int qcom_of_fixup_nodes(void)
{
time_call(fixup_usb_nodes);
time_call(fixup_power_domains);
+
+ return 0;
}
+EVENT_SPY_SIMPLE(EVT_OF_LIVE_INIT, qcom_of_fixup_nodes);
+
int ft_board_setup(void *blob, struct bd_info __maybe_unused *bd)
{
struct fdt_header *fdt = blob;
int node;
diff --git a/arch/arm/mach-snapdragon/qcom-priv.h
b/arch/arm/mach-snapdragon/qcom-priv.h
index
74d39197b89f4e769299b06214c26ee829ecdce0..4f398e2ba374f27811afd2ccf6e72037d0f9ee7f
100644
--- a/arch/arm/mach-snapdragon/qcom-priv.h
+++ b/arch/arm/mach-snapdragon/qcom-priv.h
@@ -8,19 +8,5 @@ void qcom_configure_capsule_updates(void);
#else
void qcom_configure_capsule_updates(void) {}
#endif /* EFI_HAVE_CAPSULE_SUPPORT */
-#if CONFIG_IS_ENABLED(OF_LIVE)
-/**
- * qcom_of_fixup_nodes() - Fixup Qualcomm DT nodes
- *
- * Adjusts nodes in the live tree to improve compatibility with U-Boot.
- */
-void qcom_of_fixup_nodes(void);
-#else
-static inline void qcom_of_fixup_nodes(void)
-{
- log_debug("Unable to dynamically fixup USB nodes, please enable
CONFIG_OF_LIVE\n");
-}
-#endif /* OF_LIVE */
-
#endif /* __QCOM_PRIV_H__ */
--
2.49.0
RE: [PATCH v3 4/8] board: starfive: spl: support DeepComputing FML13V01
> On 09.04.25 15:19, Heinrich Schuchardt wrote:
>
> On the DeepComputing Framework motherboard (FML13V01) choose the
> matching FIT configuration.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> v3:
> no change
> v2:
> rebased
> ---
> board/starfive/visionfive2/spl.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/board/starfive/visionfive2/spl.c
> b/board/starfive/visionfive2/spl.c
> index 3e4d3e21988..9a3081ef06f 100644
> --- a/board/starfive/visionfive2/spl.c
> +++ b/board/starfive/visionfive2/spl.c
> @@ -125,7 +125,10 @@ int board_fit_config_name_match(const char
> *name)
> if (strncmp(name, "starfive/", 9))
> return -EINVAL;
> name += 9;
> - if (!strncmp(product_id, "VF7110", 6)) {
> + if (!strncmp(product_id, "FML13V01", 8) &&
> + !strcmp(name, "jh7110-deepcomputing-fml13v01")) {
> + return 0;
> + } else if (!strncmp(product_id, "VF7110", 6)) {
> version = get_pcb_revision_from_eeprom();
> if ((version == 'b' || version == 'B') &&
> !strcmp(name, "jh7110-starfive-visionfive-2-v1.3b"))
Reviewed-by: Hal Feng
Best regards,
Hal
Re: [PATCH] tiny-printf: Handle formatting of %p with an extra Kconfig
Hi, > >> The formatting with %pa / %pap behaves like %x, which results in an > >> incorrect value being output. To improve this, a new fine-tuning > >> Kconfig XPL_USE_TINY_PRINTF_POINTER_SUPPORT for pointer formatting > >> has been added. If it is enabled, the output of %pa / %pap should > >> be correct, and if it is disabled, the pointer formatting is > >> completely unsupported. In addition to indicate unsupported formatting, > >> '?' will be output. This allows enabling pointer formatting only > >> when needed. For SPL_NET and NET_LWIP it is selected by default. > >> Then it also supports the formatting with %pm, %pM and %pI4. > >> > >> Signed-off-by: Christoph Niedermaier > >> --- > >> Cc: Tom Rini > >> Cc: Simon Glass > >> Cc: Michael Walle > >> Cc: Quentin Schulz > >> Cc: Marek Vasut > >> Cc: Benedikt Spranger > >> Cc: Jerome Forissier > >> Cc: John Ogness > >> Cc: Ilias Apalodimas > >> --- > >> Kconfig| 1 + > >> common/spl/Kconfig | 1 + > >> lib/Kconfig| 8 > >> lib/tiny-printf.c | 45 +++-- > >> 4 files changed, 29 insertions(+), 26 deletions(-) > >> > >> diff --git a/Kconfig b/Kconfig > >> index 6379a454166..4d13717294c 100644 > >> --- a/Kconfig > >> +++ b/Kconfig > >> @@ -757,6 +757,7 @@ config NET > >> > >> config NET_LWIP > >>bool "Use lwIP for networking stack" > >> + select XPL_USE_TINY_PRINTF_POINTER_SUPPORT if SPL_USE_TINY_PRINTF || > >> TPL_USE_TINY_PRINTF || VPL_USE_TINY_PRINTF > >>imply NETDEVICES > >>help > >> Include networking support based on the lwIP (lightweight IP) > >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > >> index 94e118f8465..72736dbecf5 100644 > >> --- a/common/spl/Kconfig > >> +++ b/common/spl/Kconfig > >> @@ -1096,6 +1096,7 @@ config SPL_DM_SPI_FLASH > >> config SPL_NET > >>bool "Support networking" > >>depends on !NET_LWIP > >> + select XPL_USE_TINY_PRINTF_POINTER_SUPPORT if SPL_USE_TINY_PRINTF || > >> TPL_USE_TINY_PRINTF || VPL_USE_TINY_PRINTF > >>help > >> Enable support for network devices (such as Ethernet) in SPL. > >> This permits SPL to load U-Boot over a network link rather than > >> diff --git a/lib/Kconfig b/lib/Kconfig > >> index 1a683dea670..62e28d4a1f3 100644 > >> --- a/lib/Kconfig > >> +++ b/lib/Kconfig > >> @@ -253,6 +253,14 @@ config VPL_USE_TINY_PRINTF > >> > >> The supported format specifiers are %c, %s, %u/%d and %x. > >> > >> +config XPL_USE_TINY_PRINTF_POINTER_SUPPORT > >> + bool "Extend tiny printf with the pointer formatting %p" > >> + depends on SPL_USE_TINY_PRINTF || TPL_USE_TINY_PRINTF || > >> VPL_USE_TINY_PRINTF > >> + help > >> +This option enables the formatting of pointers %p. It supports > >> +%p and %pa / %pap. If this option is selected by SPL_NET or NET_LWIP > >> +it also supports the formatting with %pm, %pM and %pI4. > > > > This isn't quite what I'd like to see. I don't want to start using the > > literal XPL namespace as that will lead to confusion down the line. > > OK, in V2 I will only support SPL. > > > Since we only have SPL_NET, I think we should name this symbol > > SPL_USE_TINY_PRINTF_POINTER_SUPPORT, not ask about it (so bool without > > "prompt text" following), and select from SPL_NET if > > SPL_USE_TINY_PRINTF. IIRC, the old one also enabled the pointer support if DEBUG is enabled. I don't think this will work with Kconfig. > Now you will get the output '?' when using formatting with %p or %pa. > If someone wants to use the pointer support e.g. %pa in pinctrl-single.c > and is restricted to use tiny printf, then it would be good to have > the option to enable it manually and not be forced to enable SPL_NET or > NET_LWIP to have the pointer support enabled. In this case, it makes > sense to allow switching it on in menuconfig. FWIW, I'm also fine with enabling full printf support as long as the tiny one doesn't print misleading values. -michael signature.asc Description: PGP signature
Re: [PATCH v4 0/3] EFI Capsule update explicitly sets dfu_alt_info
Hi, st 26. 2. 2025 v 23:36 odesílatel Jonathan Humphreys napsal: > > For capsule update, explicitly set the dfu_alt_info environment variable > before the DFU operation, and then restore it to the original value. > Previously, the dfu_alt_info environment variable was set with the > set_dfu_alt_info() function. > > The problem with setting the capsule update's dfu_alt_info setting in > set_dfu_alt_info() is that set_dfu_alt_info() lacks the context of what DFU > operation is being performed (eg, capsule update, DFU boot, listing the > alt_info, etc) so the capsule update setting was overwriting the setting > for other DFU operations. > > Changes from v1: > - use log_err() instead of pr_err() > - create a local copy of the original dfu_alt_info environment variable to > be used to later restore it, rather than just a pointer to the stored > value, because changing its value to the EFI capsule update setting will > cause the original string location to be freed. > - even in the case of a DFU operation error, restore the dfu_alt_info > environment variable to its original value. > - return EFI_EXIT based error codes if setting environment variables fails > Link to v1: > https://lore.kernel.org/r/20250203215351.2840144-1-j-humphr...@ti.com > > Changes from v2: > - add patch for xilinx boards to set the dfu_string member with the created > dfu_alt_info string for capsule updates > Link to v2: > https://lore.kernel.org/r/20250206154719.3032322-1-j-humphr...@ti.com > > Changes from v3: > - in case that the dfu_alt_info env variable is set and we save a copy > using strdup(), check that strdup() doesn't fail > - separate the reporting of an error due to the DFU operation from failure > to restore the dfu_alt_info environment variable. In the latter case, > just emit a warning and return success for the DFU operation. > Link to v3: > https://lore.kernel.org/r/20250213195351.3518305-1-j-humphr...@ti.com > > Tested-by: Michal Simek > > Jonathan Humphreys (2): > efi_firmware: set EFI capsule dfu_alt_info env explicitly > board: remove capsule update support in set_dfu_alt_info() > > Michal Simek (1): > xilinx: dfu: Fill directly update_info.dfu_string > > board/beagle/beagleboneai64/beagleboneai64.c | 8 --- > board/beagle/beagleplay/beagleplay.c | 8 --- > .../aml-a311d-cc/aml-a311d-cc.c | 2 - > .../aml-s805x-ac/aml-s805x-ac.c | 2 - > .../aml-s905d3-cc/aml-s905d3-cc.c | 2 - > board/phytec/common/k3/board.c| 8 --- > board/ti/am62px/evm.c | 8 --- > board/ti/am62x/evm.c | 8 --- > board/ti/am64x/evm.c | 8 --- > board/ti/j721e/evm.c | 8 --- > board/ti/j784s4/evm.c | 8 --- > board/xilinx/common/board.h | 3 + > board/xilinx/versal/board.c | 16 +++--- > board/xilinx/zynq/board.c | 16 +++--- > board/xilinx/zynqmp/zynqmp.c | 16 +++--- > lib/efi_loader/Kconfig| 2 - > lib/efi_loader/efi_firmware.c | 56 --- > 17 files changed, 72 insertions(+), 107 deletions(-) > > -- > 2.34.1 > Is anybody going to take this series? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 1/2] arm: dts: Add override for RB1
On 4/9/25 14:35, Sumit Garg wrote:
On Tue, Apr 08, 2025 at 04:43:49PM +0200, Caleb Connolly wrote:
On 4/8/25 15:46, Sumit Garg wrote:
On Tue, Apr 08, 2025 at 02:17:29PM +0200, Caleb Connolly wrote:
On 4/7/25 15:28, Sumit Garg wrote:
From: Sumit Garg
Add U-Boot override for RB1 to for USB in host mode as OTG mode isn't
supported. Also, disable sdhc_2 as it's currently not supported, sdhc_1
works fine though.
Signed-off-by: Sumit Garg
---
arch/arm/dts/qrb2210-rb1-u-boot.dtsi | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 arch/arm/dts/qrb2210-rb1-u-boot.dtsi
diff --git a/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
new file mode 100644
index 000..1e136ee405a
--- /dev/null
+++ b/arch/arm/dts/qrb2210-rb1-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* This is usually OTG but U-Boot doesn't support that properly */
+&usb_dwc3 {
+ dr_mode = "host";
+};
+
+/* SDHC_2 isn't supported in U-Boot as of now */
I'd rather avoid disabling this here, I guess it's just missing clocks and
regulators which doesn't justify modifying DT. An error that mmc1 couldn't
be enabled seems fine to me?
I totally echo with your thinking that we should avoid modifying DT but
at the same point we shouldn't enable peripherals in U-Boot which throws
errors. It's also possible that U-Boot misconfiguring mmc1 which might
I disagree, DT isn't enabling or disabling peripherals, it's describing
hardware.
It would be helpful if you can describe the use-case for "status"
property then.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#status
These all describe the functionality of hardware, since implementation
details of the software (U-Boot) which is parsing the DT has absolutely
nothing to do with it.>
U-Boot lacking proper support for that hardware isn't a good
justification to disable it. Especially since you might boot Linux with the
same DT and now have no working sdcard for seemingly no reason.
We shouldn't use same DT unless both U-Boot and Linux support that
without modifications and *not* being in a broken state. The similar argument
holds true for USB OTG mode too.
Well, the main difference with the OTG fixup is that we undo it later
on, so if we boot an OS with this DT it won't have the override -- our
hacks aren't exposed.
An error in U-Boot is exactly the behaviour we want to see, masking it only
created confusion.> turn as a problem for later stages.
IMO, our first priority should be to fix U-Boot issues and then see if
we can use unmodified DT.
I have been totally working with a remote lab to fix issues on RB1. I
will soon get one on my desk then I will be able to fix mmc1 too.
In that case we can surely land the proper fixes for 2025.07 anyway, so I'd
just keep the errors until then.
Fixing errors in mainline will help other people confidence who are
trying to boot U-Boot on RB1. If you still have a strong preference to
keep SD card support enabled in broken state then I can live with that
until I fix it for real.
I decided to just have a crack at it and managed to get everything
cleaned up. sdcard seems to work on my RB1 with these patches on top of
qcom-next and the u-boot specific DTS hacks are removed.
USB phy init seems to fail for me, but the board I'm testing on is some
super early DVT so I'm hoping it's a silicon issue
Please give these a spin and let me know how it goes.
https://lore.kernel.org/u-boot/20250409-livetree-fixup-v1-0-76dfea80b...@linaro.org
Kind regards,>
-Sumit
--
Caleb (they/them)
Re: [PATCH] hmibsc_defconfig: disable DM_USB_GADGET
On Wed, 02 Apr 2025 16:28:03 +0200, Caleb Connolly wrote: > As with the db410c this breaks linking as it conflicts with the USB > controller used by these platforms. > > This fixes building after DM_USB_GADGET was enabled by default for > mach-snapdragon. > > > [...] Applied, thanks! [1/1] hmibsc_defconfig: disable DM_USB_GADGET https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commit/ddbb13b6a4a3 Best regards, -- Caleb Connolly
[PATCH v2 1/2] net-lwip: wget: add LMB and buffer checks
Legacy NET wget invokes a store_block() function which performs buffer
validation (LMB, address wrapping). Do the same with NET_LWIP.
Signed-off-by: Jerome Forissier
Suggested-by: Sughosh Ganu
---
net/lwip/wget.c | 49 +
1 file changed, 41 insertions(+), 8 deletions(-)
diff --git a/net/lwip/wget.c b/net/lwip/wget.c
index 14f27d42998..746c8164d66 100644
--- a/net/lwip/wget.c
+++ b/net/lwip/wget.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include "lwip/altcp_tls.h"
#include
@@ -201,11 +202,44 @@ static int parse_legacy_arg(char *arg, char *nurl, size_t
rem)
return 0;
}
+static int store_block(struct wget_ctx *ctx, void *src, u16_t len)
+{
+ ulong store_addr = ctx->daddr;
+ uchar *ptr;
+
+ /* Avoid overflow */
+ if (wget_info->buffer_size && wget_info->buffer_size < ctx->size + len)
+ return -1;
+
+ if (CONFIG_IS_ENABLED(LMB) && wget_info->set_bootdev) {
+ if (store_addr + len < store_addr ||
+ lmb_read_check(store_addr, len)) {
+ printf("\nwget error: ");
+ printf("trying to overwrite reserved memory...\n");
+ return -1;
+ }
+ }
+
+ ptr = map_sysmem(store_addr, len);
+ memcpy(ptr, src, len);
+ unmap_sysmem(ptr);
+
+ ctx->daddr += len;
+ ctx->size += len;
+ if (ctx->size - ctx->prevsize > PROGRESS_PRINT_STEP_BYTES) {
+ printf("#");
+ ctx->prevsize = ctx->size;
+ }
+
+ return 0;
+}
+
static err_t httpc_recv_cb(void *arg, struct altcp_pcb *pcb, struct pbuf *pbuf,
err_t err)
{
struct wget_ctx *ctx = arg;
struct pbuf *buf;
+ err_t ret;
if (!pbuf)
return ERR_BUF;
@@ -214,18 +248,17 @@ static err_t httpc_recv_cb(void *arg, struct altcp_pcb
*pcb, struct pbuf *pbuf,
ctx->start_time = get_timer(0);
for (buf = pbuf; buf; buf = buf->next) {
- memcpy((void *)ctx->daddr, buf->payload, buf->len);
- ctx->daddr += buf->len;
- ctx->size += buf->len;
- if (ctx->size - ctx->prevsize > PROGRESS_PRINT_STEP_BYTES) {
- printf("#");
- ctx->prevsize = ctx->size;
+ if (store_block(ctx, buf->payload, buf->len) < 0) {
+ altcp_abort(pcb);
+ ret = ERR_BUF;
+ goto out;
}
}
-
altcp_recved(pcb, pbuf->tot_len);
+ ret = ERR_OK;
+out:
pbuf_free(pbuf);
- return ERR_OK;
+ return ret;
}
static void httpc_result_cb(void *arg, httpc_result_t httpc_result,
--
2.43.0
Re: [PATCH v2] net: dhcp6: Send DHCPv6 using multicast MAC
Hi Sean, On 3/24/25 21:48, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > In IPv6, the broadcast MAC address is not used. Instead, it should use > the multicast address (see RFC RFC2464). > > Add IPV6_ALL_NODE_ETH_ADDR macro for clarity. > > Signed-off-by: Sean Edmond > --- > include/net6.h | 10 ++ > net/dhcpv6.c | 12 ++-- > net/dhcpv6.h | 8 +++- > 3 files changed, 23 insertions(+), 7 deletions(-) Reviewed-by: Jerome Forissier [...] Thanks, -- Jerome
[PATCH v1] configs: set SPL_TEXT_BASE by default for k3 platforms
SPL_TEXT_BASE is used as the load address for the main domain SPL on k3 platforms. Since the config value is the same for every board, this patch sets the value 0x8008 as default for all ARCH_K3 and deletes the instances of SPL_TEXT_BASE in individual defconfigs. Signed-off-by: Anshul Dalal --- common/spl/Kconfig | 1 + configs/am62ax_evm_a53_defconfig | 1 - configs/am62px_evm_a53_defconfig | 1 - configs/am62x_beagleplay_a53_defconfig | 1 - configs/am62x_evm_a53_defconfig| 1 - configs/am64x_evm_a53_defconfig| 1 - configs/am65x_evm_a53_defconfig| 1 - configs/iot2050_defconfig | 1 - configs/j7200_evm_a72_defconfig| 1 - configs/j721e_beagleboneai64_a72_defconfig | 1 - configs/j721e_evm_a72_defconfig| 1 - configs/j721s2_evm_a72_defconfig | 1 - configs/j722s_evm_a53_defconfig| 1 - configs/j784s4_evm_a72_defconfig | 1 - configs/phycore_am62ax_a53_defconfig | 1 - configs/phycore_am62x_a53_defconfig| 1 - configs/phycore_am64x_a53_defconfig| 1 - configs/verdin-am62_a53_defconfig | 1 - 18 files changed, 1 insertion(+), 17 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 94e118f8465..a84b96ebce4 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -271,6 +271,7 @@ config SPL_TEXT_BASE default 0x4020 if OMAP34XX default 0x402F4000 if AM43XX default 0x402F0400 if AM33XX + default 0x8008 if ARCH_K3 default 0x00908000 if ARCH_MX6 default 0x00912000 if ARCH_MX7 default 0x40301350 if OMAP54XX diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig index bf6e9639901..9f47b35ffde 100644 --- a/configs/am62ax_evm_a53_defconfig +++ b/configs/am62ax_evm_a53_defconfig @@ -15,7 +15,6 @@ CONFIG_DM_RESET=y CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK_R_ADDR=0x8200 -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x80a0 CONFIG_SPL_BSS_MAX_SIZE=0x8 diff --git a/configs/am62px_evm_a53_defconfig b/configs/am62px_evm_a53_defconfig index 30b4a24ee9a..572e5d3dc4a 100644 --- a/configs/am62px_evm_a53_defconfig +++ b/configs/am62px_evm_a53_defconfig @@ -13,7 +13,6 @@ CONFIG_ENV_SIZE=0x4 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am62p5-sk" -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y diff --git a/configs/am62x_beagleplay_a53_defconfig b/configs/am62x_beagleplay_a53_defconfig index a8a73166597..fd578df5792 100644 --- a/configs/am62x_beagleplay_a53_defconfig +++ b/configs/am62x_beagleplay_a53_defconfig @@ -11,7 +11,6 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am625-beagleplay" -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index 6527200259e..09a7bdd6544 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -12,7 +12,6 @@ CONFIG_SF_DEFAULT_SPEED=2500 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am625-sk" -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index a501f3f567e..b3266cc64c8 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -16,7 +16,6 @@ CONFIG_ENV_SIZE=0x2 CONFIG_DM_GPIO=y CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am642-evm" -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index e9b736714a5..75c33a0d256 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -19,7 +19,6 @@ CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y CONFIG_SPL_STACK_R_ADDR=0x8200 -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x80a0 CONFIG_SPL_BSS_MAX_SIZE=0x8 diff --git a/configs/iot2050_defconfig b/configs/iot2050_defconfig index 2d5f18e5bd4..bd441e83cd1 100644 --- a/configs/iot2050_defconfig +++ b/configs/iot2050_defconfig @@ -21,7 +21,6 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK_R_ADDR=0x8200 -CONFIG_SPL_TEXT_BASE=0x8008 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x80a0 CONFIG_SPL_BSS_MAX_SIZE=0x8 diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig index ac5b10ba149..d2422b1a1bd 100644 --- a/configs/j7200_evm_a72_defconfig +++ b/configs/j7200_evm_a72_defconfig @@ -22,7 +22,
[PATCH v2 07/30] arm64: dts: rockchip: Add SARADC node for RK3528
Add a device tree node for the SARADC controller used by RK3528.
Signed-off-by: Jonas Karlman
Link: https://lore.kernel.org/r/20250304201642.831218-4-jo...@kwiboo.se
Signed-off-by: Heiko Stuebner
[ upstream commit: 6e58302c84ce90aadbecd41efe1f69098a6f91e5 ]
(cherry picked from commit 8ba64ba5cb301bca777ba7f0d2a2a72f49af5ff2)
Signed-off-by: Jonas Karlman
---
dts/upstream/src/arm64/rockchip/rk3528.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/dts/upstream/src/arm64/rockchip/rk3528.dtsi
b/dts/upstream/src/arm64/rockchip/rk3528.dtsi
index 4be53868f324..c2eaa0c6ea90 100644
--- a/dts/upstream/src/arm64/rockchip/rk3528.dtsi
+++ b/dts/upstream/src/arm64/rockchip/rk3528.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
/ {
compatible = "rockchip,rk3528";
@@ -455,6 +456,18 @@
status = "disabled";
};
+ saradc: adc@ffae {
+ compatible = "rockchip,rk3528-saradc";
+ reg = <0x0 0xffae 0x0 0x1>;
+ clocks = <&cru CLK_SARADC>, <&cru PCLK_SARADC>;
+ clock-names = "saradc", "apb_pclk";
+ interrupts = ;
+ resets = <&cru SRST_P_SARADC>;
+ reset-names = "saradc-apb";
+ #io-channel-cells = <1>;
+ status = "disabled";
+ };
+
pinctrl: pinctrl {
compatible = "rockchip,rk3528-pinctrl";
rockchip,grf = <&ioc_grf>;
--
2.49.0
[PATCH] mips: octeon: remove unused middle expression
!A || (A && B) is equivalent to !A || B
Drop the unused middle expression to simplify the statement.
Signed-off-by: Bryan Brattlof
---
arch/mips/mach-octeon/cvmx-helper-board.c | 3 +--
arch/mips/mach-octeon/cvmx-helper.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/mips/mach-octeon/cvmx-helper-board.c
b/arch/mips/mach-octeon/cvmx-helper-board.c
index 6dcc4e557e12f..8d9388983b79c 100644
--- a/arch/mips/mach-octeon/cvmx-helper-board.c
+++ b/arch/mips/mach-octeon/cvmx-helper-board.c
@@ -386,8 +386,7 @@ cvmx_helper_link_info_t
__cvmx_helper_board_link_get_from_dt(int ipd_port)
/* If the link is down or the link is up but we still register
* the module as being absent, re-check mod_abs.
*/
- if (!result.s.link_up ||
- (result.s.link_up && sfp_info->last_mod_abs))
+ if (!result.s.link_up || sfp_info->last_mod_abs)
__cvmx_helper_update_sfp(ipd_port, sfp_info, result);
sfp_info = sfp_info->next_iface_sfp;
}
diff --git a/arch/mips/mach-octeon/cvmx-helper.c
b/arch/mips/mach-octeon/cvmx-helper.c
index ccec57edf844d..7dcaa1ac8d990 100644
--- a/arch/mips/mach-octeon/cvmx-helper.c
+++ b/arch/mips/mach-octeon/cvmx-helper.c
@@ -1729,7 +1729,7 @@ cvmx_helper_link_info_t cvmx_helper_link_get(int
xipd_port)
sfp_info = cvmx_helper_cfg_get_sfp_info(xiface, index);
while (sfp_info) {
- if ((!result.s.link_up || (result.s.link_up &&
sfp_info->last_mod_abs)))
+ if (!result.s.link_up || sfp_info->last_mod_abs)
cvmx_sfp_check_mod_abs(sfp_info,
sfp_info->mod_abs_data);
sfp_info = sfp_info->next_iface_sfp;
}
---
base-commit: 9d9fbdab0e9664bff147109cc89ad2786f6ecd83
change-id: 20250409-octeon-middle-expressions-db40bef5578a
Best regards,
--
Bryan Brattlof
Re: [PATCH 0/6] usb: host: ehci-msm: Clean up and fix crashes
On 4/7/25 11:54, Stephan Gerhold wrote: The ehci-msm driver has several subtle issues and stale code. Most of them are minor and do not cause issues during normal usage. The last patch is the most critical, it fixes a reported crash when stopping/re-configuring USB, which has been around for a few months now. Signed-off-by: Stephan Gerhold Acked-by: Caleb Connolly I'd appreciate a T-b from Sam or some other MSM8916 device, but this all looks good to me! Kind regards,> --- Stephan Gerhold (6): usb: host: ehci-msm: Fix pointer check usb: host: echi-msm: Drop ulpi definitions usb: host: ehci-msm: Disable clocks after all register accesses usb: host: ehci-msm: Use clk bulk helpers usb: host: ehci-msm: Drop redundant EHCI register writes usb: host: ehci-msm: Register ULPI PHY through NOP wrapper drivers/usb/host/ehci-msm.c | 146 1 file changed, 67 insertions(+), 79 deletions(-) --- base-commit: 0efe8ea57fc7a1a6fc5f64fb3cf6bc4a1a4fc219 change-id: 20250121-ehci-msm-fixes-b1ed17a1eaea Best regards, -- Caleb (they/them)
[PATCH RFC 0/4] fit: print conf node compatibles + use property string constants
This does a bit of "cleanup" by reusing constants for some FIT properties instead of having the same string in multiple places. Additionally, this adds a new constant for the compatible property in FIT configuration nodes[1] which is useful for FIT images with multiple FIT configuration nodes to support multiple devices in the same blob. U-Boot will try to figure out which node to select based on that compatible[2]. However, if this property is missing (and the first blob in the fdt property of the configuration node is uncompressed), the compatible from the root node of the associated kernel FDT will be used for the autoselection mechanism. For now, I only print the property if it exists, but maybe it'd make sense to expose the fallback one if it's missing, hence the RFC state for this series. [1] https://fitspec.osfw.foundation/#optional-properties compatible paragraph [2] https://fitspec.osfw.foundation/#select-a-configuration-to-boot Signed-off-by: Quentin Schulz --- Quentin Schulz (4): boot/fit: use constants for property strings lib: rsa: use FIT_ALGO_PROP constant instead of "algo" in FIT boot/fit: declare (and use) new constant for conf's compatible prop boot/fit: print all configuration node compatibles boot/common_fit.c| 4 ++-- boot/image-fit.c | 15 +-- include/image.h | 1 + lib/rsa/rsa-verify.c | 2 +- 4 files changed, 17 insertions(+), 5 deletions(-) --- base-commit: 341cafc31e4c6941a1b05feb18d18c99ffaebcc1 change-id: 20250409-fit-compat-ebe94f690b08 Best regards, -- Quentin Schulz
[PATCH 3/6] mach-snapdragon: of_fixup: skip disabled USB nodes
There's no need to waste time fixing up nodes that aren't used on this
device. Skip them.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/of_fixup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-snapdragon/of_fixup.c
b/arch/arm/mach-snapdragon/of_fixup.c
index
d4e24059212c552de7fa7555d2ab8a1ea4fc4cb2..b39036e8e0890fdf834a0dfe6966ef3dd365f3d2
100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -107,8 +107,10 @@ static void fixup_usb_nodes(void)
struct device_node *glue_np = NULL;
int ret;
while ((glue_np = of_find_compatible_node(glue_np, NULL, "qcom,dwc3")))
{
+ if (!of_device_is_available(glue_np))
+ continue;
ret = fixup_qcom_dwc3(glue_np);
if (ret)
log_warning("Failed to fixup node %s: %d\n",
glue_np->name, ret);
}
--
2.49.0
Re: [PATCH v4 09/10] rockchip: binman: Support use of crc32 for SPL_FIT_SIGNATURE
Hi Quentin,
On 2025-04-09 18:11, Quentin Schulz wrote:
> Hi Jonas,
>
> On 4/9/25 5:38 PM, Jonas Karlman wrote:
>> Hi Quentin,
>>
>> On 2025-04-09 13:06, Quentin Schulz wrote:
>>> Hi Jonas,
>>>
>>> On 3/29/25 4:06 PM, Jonas Karlman wrote:
Use of SHA256 checksum validation on ARMv7 SoCs can be very time
consuming compared to ARMv8 SoCs with Crypto Extensions.
Add support for use of the crc32 hash algo when SHA256 is not supported.
Also use a HAS_HASH to simplify the ifdefs when no known hash algo is
compiled.
Signed-off-by: Jonas Karlman
>>>
>>> I don't know enough about general security but this very much looks like
>>> a bad idea to me.
>>>
>>> https://web.archive.org/web/20170210173741/http://www.derkeiler.com/Newsgroups/sci.crypt/2003-07/1451.html
>>>
>>> """
>>> While properly designed CRC's are good at detecting random errors in
>>> the data (due to e.g. line noise), the CRC is useless as a secure
>>> indicator of intentional manipulation of the data. And this is
>>> because it's not hard at all to modify the data to produce any CRC
>>> you desire (e.g. the same CRC as the original data, to try to
>>> disguise your data manipulation).
>>> """
>>>
>>> (yes I took the "first" link my web search engine returned me, thanks
>>> confirmation bias!).
>>
>> I am fully aware, and the fallback to use crc32, and current primarily
>> use of sha256, should not be considered a security feature. It is
>> intended purely for a checksum validation of the binary blob after it
>> has been loaded into memory and before U-Boot otherwise unconditionally
>> jumps to and execute the loaded blob of binary code.
>>
>>>
>>> I don't want to give people a false sense of security. If it really
>>> comes down to it, I'd rather have an explicit Kconfig symbol to set this
>>> value (maybe have a `choice` even) and be very clear about security
>>> implications.
>>
>> Prior to the addition of the hash { algo=sha256 }, there was no checksum
>> test and U-Boot SPL would unconditionally jump to the loaded data, even
>> if it had been corrupted, was only halfway written or otherwise
>> overwritten.
>>
>> The addition of crc32 instead of sha256 is just to allow older board
>> variants with weaker SoCs to at least have some sort of checksum
>> validation in use without affecting the boot time too much.
>>
>> On my rk3228 board, validation using sha256 could take a few seconds,
>> and with crc32 it could be measured in ms.
>>
>> To me, having at least some default checksum validation is preferred
>> over none at all.
>>
>
> Except if this confuses people into thinking they have a secure system
> except they use CRC32 instead of something more appropriate like SHA256.
>
> It seems like the "hash" node presence doesn't mean a FIT conf or image
> node is signed.
Correct, current use of a hash node does not indicate any type of
signature validation, only that a hash value should be calculated and
added in the final FIT output.
The signature node must be added separately and/or injected at a later
stage, and for that the algo prop use a {checksum_algo},{crypto_algo}
format. Where checksum_algo = [sha1, sha256, sha384, sha512] and
crypto_algo = [rsa2048, rsa3072, rsa4096, ecdsa256, ecdsa384, secp521r1].
See tools/image-sig-host.c for supported algos.
> I also don't see many device trees with a signature
> node... which is kinda odd. Looking a bit into the signature node in the
> spec and binman tests, it's not clear to me if the hash node is reused
> by the signature node if if exists and if their algo should match and
> what exactly is checked by the signature node (like signing the hash
> string contained in the hash node(s) listed in sign-images property, or
> (re-)generating a hash of those and signing it at build time?
I have not looked into how signing and signature validation works, and
if the checksum in signature { algo } must match the one used in
hash { algo }.
My personal interest have only ever been to add bare minimum checksum
validation in order to avoid executing code that is known to be broken
(a basic checksum test fails).
>
> If
> a) it is not possible to have a hash node's algo differ from a signature
> node's algo, then I'm fine with this as crc32 won't be allowed
> b) the signature node regenerates a hash regardless of the hash in the
> hash node, meaning the signature will be "appropriately secure"
> regardless of the algorithm listed in the hash node, then I'm fine with
> it too,
> c) it is possible to sign a crc32 hash, don't want it :)
To actually validate a signature in SPL you would need to enable support
for RSA or ECDSA in SPL, without it only checksum validation may happen.
So yes, to get a proper secure solution there is much more to do than
just select a checksum algo. You need to correctly handle a signing key,
sign FIT, preferably also sign the rk boot image, burn public cert in
OTP and more.
Not sure what you want me to do here, in my mind the us
[PATCH 2/2] board: amd: Read an eeprom after relocation
Read an eeprom after relocation which also shows information from
eeprom wired via nvmem aliases.
When DTB reselection is enabled eeprom is read before relocation
too but information is not showed. The issue about two i2c reads
in this case will be address separately.
Signed-off-by: Padmarao Begari
---
board/amd/versal2/board.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/board/amd/versal2/board.c b/board/amd/versal2/board.c
index 5651d516a9e..5b995aaf9b2 100644
--- a/board/amd/versal2/board.c
+++ b/board/amd/versal2/board.c
@@ -32,6 +32,9 @@ int board_init(void)
{
printf("EL Level:\tEL%d\n", current_el());
+ if (CONFIG_IS_ENABLED(DM_I2C) && CONFIG_IS_ENABLED(I2C_EEPROM))
+ xilinx_read_eeprom();
+
return 0;
}
--
2.44.1
[PATCH] RFC: ext4: Add a few overflow checks in the writing code
From: Simon Glass
Some memory allocations make use of data from the disk, so add some
overflow checks.
Adjust LOG2_BLOCK_SIZE() so it is easier to read.
Note: This is a trial to help figure out the best way to deal with these
sorts of things. Feedback welcome.
Signed-off-by: Simon Glass
---
fs/ext4/ext4_write.c | 24
include/ext_common.h | 3 +--
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/fs/ext4/ext4_write.c b/fs/ext4/ext4_write.c
index d109ed6e90d..ebb1dad4fc9 100644
--- a/fs/ext4/ext4_write.c
+++ b/fs/ext4/ext4_write.c
@@ -108,8 +108,15 @@ int ext4fs_get_bgdtable(void)
{
int status;
struct ext_filesystem *fs = get_fs();
- int gdsize_total = ROUND(fs->no_blkgrp * fs->gdsize, fs->blksz);
+ size_t alloc_size;
+ int gdsize_total;
+
+ if (__builtin_mul_overflow(fs->no_blkgrp, fs->gdsize, &alloc_size))
+ return -1;
+ gdsize_total = ROUND(alloc_size, fs->blksz);
fs->no_blk_pergdt = gdsize_total / fs->blksz;
+ if (!fs->no_blk_pergdt)
+ return -1;
/* allocate memory for gdtable */
fs->gdtable = zalloc(gdsize_total);
@@ -117,7 +124,7 @@ int ext4fs_get_bgdtable(void)
return -ENOMEM;
/* read the group descriptor table */
status = ext4fs_devread((lbaint_t)fs->gdtable_blkno * fs->sect_perblk,
- 0, fs->blksz * fs->no_blk_pergdt, fs->gdtable);
+ 0, gdsize_total, fs->gdtable);
if (status == 0)
goto fail;
@@ -599,10 +606,17 @@ int ext4fs_init(void)
int i;
uint32_t real_free_blocks = 0;
struct ext_filesystem *fs = get_fs();
+ size_t alloc_size;
+
+ /* check for a reasonable block size, no more than 64K */
+ if (LOG2_BLOCK_SIZE(ext4fs_root) > 16)
+ goto fail;
/* populate fs */
fs->blksz = EXT2_BLOCK_SIZE(ext4fs_root);
fs->sect_perblk = fs->blksz >> fs->dev_desc->log2blksz;
+ if (!fs->sect_perblk)
+ goto fail;
/* get the superblock */
fs->sb = zalloc(SUPERBLOCK_SIZE);
@@ -629,7 +643,9 @@ int ext4fs_init(void)
}
/* load all the available bitmap block of the partition */
- fs->blk_bmaps = zalloc(fs->no_blkgrp * sizeof(char *));
+ if (__builtin_mul_overflow(fs->no_blkgrp, sizeof(char *), &alloc_size))
+ goto fail;
+ fs->blk_bmaps = zalloc(alloc_size);
if (!fs->blk_bmaps)
goto fail;
for (i = 0; i < fs->no_blkgrp; i++) {
@@ -649,7 +665,7 @@ int ext4fs_init(void)
}
/* load all the available inode bitmap of the partition */
- fs->inode_bmaps = zalloc(fs->no_blkgrp * sizeof(unsigned char *));
+ fs->inode_bmaps = zalloc(alloc_size);
if (!fs->inode_bmaps)
goto fail;
for (i = 0; i < fs->no_blkgrp; i++) {
diff --git a/include/ext_common.h b/include/ext_common.h
index 6e17fbd2771..35d3a1844eb 100644
--- a/include/ext_common.h
+++ b/include/ext_common.h
@@ -67,8 +67,7 @@ struct cmd_tbl;
#define EXT2_BLOCK_SIZE(data) (1 << LOG2_BLOCK_SIZE(data))
/* Log2 size of ext2 block in bytes. */
-#define LOG2_BLOCK_SIZE(data) (le32_to_cpu\
- (data->sblock.log2_block_size) \
+#define LOG2_BLOCK_SIZE(data) (le32_to_cpu((data)->sblock.log2_block_size) \
+ EXT2_MIN_BLOCK_LOG_SIZE)
#define EXT2_FT_DIR2
--
2.43.0
base-commit: ea9e72801c4c3e3542afe40f89e7e0822cabfcf8
branch: sec
Re: [PATCH 10/14] pinctrl: rockchip: constify rockchip_pin_ctrl for RK3308
On 2025/1/29 20:42, Quentin Schulz wrote:
From: Quentin Schulz
There's no need to modify private data from the controller, so let's
make that struct const.
Signed-off-by: Quentin Schulz
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/pinctrl/rockchip/pinctrl-rk3308.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/rockchip/pinctrl-rk3308.c
b/drivers/pinctrl/rockchip/pinctrl-rk3308.c
index
2cd91b10a3bdbb55cf1e1a56a1b3a240a2899047..5c0e34a7baad835c54f6975017d7e183db5cd84d
100644
--- a/drivers/pinctrl/rockchip/pinctrl-rk3308.c
+++ b/drivers/pinctrl/rockchip/pinctrl-rk3308.c
@@ -421,7 +421,7 @@ static struct rockchip_pin_bank rk3308_pin_banks[] = {
IOMUX_8WIDTH_2BIT),
};
-static struct rockchip_pin_ctrl rk3308_pin_ctrl = {
+static const struct rockchip_pin_ctrl rk3308_pin_ctrl = {
.pin_banks = rk3308_pin_banks,
.nr_banks = ARRAY_SIZE(rk3308_pin_banks),
.grf_mux_offset = 0x0,
Re: [PATCH v4 0/3] EFI Capsule update explicitly sets dfu_alt_info
Michal Simek writes: > Hi, > > st 26. 2. 2025 v 23:36 odesílatel Jonathan Humphreys > napsal: >> >> For capsule update, explicitly set the dfu_alt_info environment variable >> before the DFU operation, and then restore it to the original value. >> Previously, the dfu_alt_info environment variable was set with the >> set_dfu_alt_info() function. >> >> The problem with setting the capsule update's dfu_alt_info setting in >> set_dfu_alt_info() is that set_dfu_alt_info() lacks the context of what DFU >> operation is being performed (eg, capsule update, DFU boot, listing the >> alt_info, etc) so the capsule update setting was overwriting the setting >> for other DFU operations. >> >> Changes from v1: >> - use log_err() instead of pr_err() >> - create a local copy of the original dfu_alt_info environment variable to >> be used to later restore it, rather than just a pointer to the stored >> value, because changing its value to the EFI capsule update setting will >> cause the original string location to be freed. >> - even in the case of a DFU operation error, restore the dfu_alt_info >> environment variable to its original value. >> - return EFI_EXIT based error codes if setting environment variables fails >> Link to v1: >> https://lore.kernel.org/r/20250203215351.2840144-1-j-humphr...@ti.com >> >> Changes from v2: >> - add patch for xilinx boards to set the dfu_string member with the created >> dfu_alt_info string for capsule updates >> Link to v2: >> https://lore.kernel.org/r/20250206154719.3032322-1-j-humphr...@ti.com >> >> Changes from v3: >> - in case that the dfu_alt_info env variable is set and we save a copy >> using strdup(), check that strdup() doesn't fail >> - separate the reporting of an error due to the DFU operation from failure >> to restore the dfu_alt_info environment variable. In the latter case, >> just emit a warning and return success for the DFU operation. >> Link to v3: >> https://lore.kernel.org/r/20250213195351.3518305-1-j-humphr...@ti.com >> >> Tested-by: Michal Simek >> >> Jonathan Humphreys (2): >> efi_firmware: set EFI capsule dfu_alt_info env explicitly >> board: remove capsule update support in set_dfu_alt_info() >> >> Michal Simek (1): >> xilinx: dfu: Fill directly update_info.dfu_string >> >> board/beagle/beagleboneai64/beagleboneai64.c | 8 --- >> board/beagle/beagleplay/beagleplay.c | 8 --- >> .../aml-a311d-cc/aml-a311d-cc.c | 2 - >> .../aml-s805x-ac/aml-s805x-ac.c | 2 - >> .../aml-s905d3-cc/aml-s905d3-cc.c | 2 - >> board/phytec/common/k3/board.c| 8 --- >> board/ti/am62px/evm.c | 8 --- >> board/ti/am62x/evm.c | 8 --- >> board/ti/am64x/evm.c | 8 --- >> board/ti/j721e/evm.c | 8 --- >> board/ti/j784s4/evm.c | 8 --- >> board/xilinx/common/board.h | 3 + >> board/xilinx/versal/board.c | 16 +++--- >> board/xilinx/zynq/board.c | 16 +++--- >> board/xilinx/zynqmp/zynqmp.c | 16 +++--- >> lib/efi_loader/Kconfig| 2 - >> lib/efi_loader/efi_firmware.c | 56 --- >> 17 files changed, 72 insertions(+), 107 deletions(-) >> >> -- >> 2.34.1 >> > > Is anybody going to take this series? > > Thanks, > Michal > > -- > Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 > w: www.monstr.eu p: +42-0-721842854 > Maintainer of Linux kernel - Xilinx Microblaze > Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs > U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs I believe it is Heinrich Schuchardt's queue. Heinrich, is there anything else to be closed? Thanks Jon
Re: [PATCH] mach-k3: common_fdt: Fix Label Issue
On 4/7/25 10:26, Neha Malcom Francis wrote:
Hi Udit
On 07/04/25 13:51, Kumar, Udit wrote:
Hi Daniel.
Thanks for patch
On 4/7/2025 11:37 AM, Daniel Schultz wrote:
Labels are not allowed before declarations. Add a semicolon after the
label to introduce an empty statement. This will fix following error:
arch/arm/mach-k3/common_fdt.c: In function 'fdt_fixup_reserved':
arch/arm/mach-k3/common_fdt.c:156:2: error: a label can only be part
of a statement and a declaration is not a statement
156 | struct fdt_memory carveout = {
| ^~
make[1]: *** [scripts/Makefile.build:256:
arch/arm/mach-k3/common_fdt.o] Error 1
make: *** [Makefile:1919: arch/arm/mach-k3] Error 2
Is there some specific compiler option you are using, Sorry but I don't
see this error .
i just build sha id e458e103d4f5fb7aaf13e744c65916ab3ba4a18d of next
I had run into the same issue when I was using v10.1 of the Arm GNU
toolchain, moving to v14.2, I no longer see it.
I'm currently using "aarch64-linux-gnu-gcc (Ubuntu
9.4.0-1ubuntu1~20.04.2) 9.4.0" with just make.
Fixes: 096aa229a9e ("mach-k3: common_fdt: create a reserved memory node")
Signed-off-by: Daniel Schultz
---
I'm open to other suggestions! This is just the easiest way to fix this
compile error. BTW, master is fine since 096aa229a9e is only on next.
arch/arm/mach-k3/common_fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/common_fdt.c
b/arch/arm/mach-k3/common_fdt.c
index 361b0c0b31b..7178918a12c 100644
--- a/arch/arm/mach-k3/common_fdt.c
+++ b/arch/arm/mach-k3/common_fdt.c
@@ -152,7 +152,7 @@ int fdt_fixup_reserved(void *blob, const char *name,
}
}
-add_carveout:
+add_carveout: ;
struct fdt_memory carveout = {
.start = new_address,
.end = new_address + new_size - 1,
My suggestion will be to move this struct at start of function.
and change only size here
carveout.end = new_address + new_size - 1;
sounds good.
- Daniel
[PATCH v3 2/8] riscv: dts: jh7110: add DeepComputing FML13V01 device-tree
Add the u-boot device-tree include needed to support the DeepComputing Framework motherboard (FML13V01). Signed-off-by: Heinrich Schuchardt Reviewed-by: Sumit Garg Reviewed-by: Hal Feng --- v3: no change v2: no change --- arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi diff --git a/arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi b/arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi new file mode 100644 index 000..ab882d07f6f --- /dev/null +++ b/arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi @@ -0,0 +1,7 @@ +// SPDX-License-Identifier: GPL-2.0 OR MIT +/* + * Copyright (C) 2024 StarFive Technology Co., Ltd. + */ + +#include "jh7110-common-u-boot.dtsi" +#include "starfive-visionfive2-binman.dtsi" -- 2.48.1
[PATCH v3 4/8] board: starfive: spl: support DeepComputing FML13V01
On the DeepComputing Framework motherboard (FML13V01) choose the matching
FIT configuration.
Signed-off-by: Heinrich Schuchardt
---
v3:
no change
v2:
rebased
---
board/starfive/visionfive2/spl.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/board/starfive/visionfive2/spl.c b/board/starfive/visionfive2/spl.c
index 3e4d3e21988..9a3081ef06f 100644
--- a/board/starfive/visionfive2/spl.c
+++ b/board/starfive/visionfive2/spl.c
@@ -125,7 +125,10 @@ int board_fit_config_name_match(const char *name)
if (strncmp(name, "starfive/", 9))
return -EINVAL;
name += 9;
- if (!strncmp(product_id, "VF7110", 6)) {
+ if (!strncmp(product_id, "FML13V01", 8) &&
+ !strcmp(name, "jh7110-deepcomputing-fml13v01")) {
+ return 0;
+ } else if (!strncmp(product_id, "VF7110", 6)) {
version = get_pcb_revision_from_eeprom();
if ((version == 'b' || version == 'B') &&
!strcmp(name, "jh7110-starfive-visionfive-2-v1.3b"))
--
2.48.1
[PATCH v3 0/8] board: starfive: DeepComputing FML13V01
We use starfive_visionfive2_defconfig for supporting JH7110 based boards. The DeepComputing Framework motherboard is a new JH7110 device with upstream kernel support since v6.13. Add support and documentation for the board. This patches are prerequisite: [PATCH 1/1] riscv: dts: jh7110: add bootph-pre-ram for &pllclk https://lore.kernel.org/u-boot/20250330162421.238483-1-heinrich.schucha...@canonical.com/T/#u [PATCH v1] board: starfive: Remove compatible boards Milk-V Mars CM and Mars CM Lite https://lore.kernel.org/all/20250327175550.529248-...@freeshell.de/ v3: Rebase upon Milk-V Mars CM removal patch v2: Rebase upon orgin/next Carve out common documentation of JH7110 boards Drop patch for binman config - not needed anymore Add information about the debug UART Heinrich Schuchardt (8): configs: add jh7110-deepcomputing-fml13v01 to VF2 defconfig riscv: dts: jh7110: add DeepComputing FML13V01 device-tree board: starfive: DeepComputing FML13V01 fdt selection board: starfive: spl: support DeepComputing FML13V01 doc: add DeepComputing FML13V01 documentation doc: starfive: use consistent formatting doc: starfive: use jh7110_common.rst doc: jh7110: describe debug UART .../jh7110-deepcomputing-fml13v01-u-boot.dtsi | 7 ++ board/starfive/visionfive2/spl.c | 5 +- .../visionfive2/starfive_visionfive2.c| 6 +- configs/starfive_visionfive2_defconfig| 2 +- doc/board/starfive/deepcomputing_fml13v01.rst | 80 +++ doc/board/starfive/index.rst | 1 + doc/board/starfive/jh7110_common.rst | 80 +++ doc/board/starfive/milk-v_mars.rst| 18 + doc/board/starfive/pine64_star64.rst | 26 ++ doc/board/starfive/visionfive2.rst| 47 ++- 10 files changed, 192 insertions(+), 80 deletions(-) create mode 100644 arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi create mode 100644 doc/board/starfive/deepcomputing_fml13v01.rst create mode 100644 doc/board/starfive/jh7110_common.rst -- 2.48.1
[PATCH v3 3/8] board: starfive: DeepComputing FML13V01 fdt selection
We support all JH7110 boards with starfive_visionfive2_defconfig.
The relevant device-tree is selected at runtime based on EEPROM data.
Support setting $fdtfile to the file name of the DeepComputing Framework
motherboard (FML13V01) device-tree.
Signed-off-by: Heinrich Schuchardt
Reviewed-by: Hal Feng
---
v3:
rebased upon Mars CM removal patch
v2:
no change
---
board/starfive/visionfive2/starfive_visionfive2.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index b8cd509bc89..5fe888d4072 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -17,6 +17,8 @@
DECLARE_GLOBAL_DATA_PTR;
#define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
#define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
+#define FDTFILE_FML13V01 \
+ "starfive/jh7110-deepcomputing-fml13v01.dtb"
#define FDTFILE_MILK_V_MARS \
"starfive/jh7110-milkv-mars.dtb"
#define FDTFILE_VISIONFIVE2_1_2A \
@@ -63,7 +65,9 @@ static void set_fdtfile(void)
log_err("Can't read EEPROM\n");
return;
}
- if (!strncmp(product_id, "MARS", 4)) {
+ if (!strncmp(product_id, "FML13V01", 8)) {
+ fdtfile = FDTFILE_FML13V01;
+ } else if (!strncmp(product_id, "MARS", 4)) {
fdtfile = FDTFILE_MILK_V_MARS;
} else if (!strncmp(product_id, "VF7110", 6)) {
version = get_pcb_revision_from_eeprom();
--
2.48.1
[PATCH 2/5] board: st: common: fix dfu alt buffer clearing
The set_dfu_alt_info() function calls the ALLOC_CACHE_ALIGN_BUFFER()
macro to declare a `buf' variable pointer into an array allocated on the
stack. It then calls the memset() function to clear the useable portion
of the array using the idiomatic expression `sizeof(buf)'.
While this would indeed work fine for an array, in the present case we
end up clearing only the size of a pointer.
Fix this by specifying the explicit size `DFU_ALT_BUF_LEN' instead.
Fixes: ec2933e543df ("board: stm32mp1: move set_dfu_alt_info in st common
directory")
Signed-off-by: Vincent Stehlé
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Tom Rini
Cc: Marek Vasut
---
board/st/common/stm32mp_dfu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
index 1db8e45480e..8c1f80b678a 100644
--- a/board/st/common/stm32mp_dfu.c
+++ b/board/st/common/stm32mp_dfu.c
@@ -105,7 +105,7 @@ void set_dfu_alt_info(char *interface, char *devstr)
if (env_get("dfu_alt_info"))
return;
- memset(buf, 0, sizeof(buf));
+ memset(buf, 0, DFU_ALT_BUF_LEN);
snprintf(buf, DFU_ALT_BUF_LEN,
"ram 0=%s", CONFIG_DFU_ALT_RAM0);
--
2.47.2
[PATCH v3 7/8] doc: starfive: use jh7110_common.rst
To avoid duplicate maintenance just include jh7110_common.rst to describe the usage of the different boot sources. Signed-off-by: Heinrich Schuchardt --- v3: no change v2: new patch --- doc/board/starfive/milk-v_mars.rst | 12 + doc/board/starfive/pine64_star64.rst | 18 + doc/board/starfive/visionfive2.rst | 39 +--- 3 files changed, 3 insertions(+), 66 deletions(-) diff --git a/doc/board/starfive/milk-v_mars.rst b/doc/board/starfive/milk-v_mars.rst index aba9c9c53d4..ce4539a46f1 100644 --- a/doc/board/starfive/milk-v_mars.rst +++ b/doc/board/starfive/milk-v_mars.rst @@ -57,13 +57,6 @@ environment or the configuration variable CONFIG_DEFAULT_FDT_FILE can be used to set to provide a default value. -Boot source selection -- - -The board provides the DIP switches MSEL[1:0] to select the boot device out of -SPI flash, eMMC, SD-card, UART. To select booting from SD-card set the DIP -switches MSEL[1:0] to 10. - Preparing the SD-Card - @@ -105,7 +98,4 @@ Copy U-Boot to the SD card sudo cp jh7110-starfive-visionfive-2.dtb /mnt/ sudo umount /mnt -Booting - -Once you plugin the sdcard and power up, you should see the U-Boot prompt. +.. include:: jh7110_common.rst diff --git a/doc/board/starfive/pine64_star64.rst b/doc/board/starfive/pine64_star64.rst index 1df4b68e4a0..d1752c452da 100644 --- a/doc/board/starfive/pine64_star64.rst +++ b/doc/board/starfive/pine64_star64.rst @@ -55,19 +55,6 @@ environment or the configuration variable CONFIG_DEFAULT_FDT_FILE can be used to set to provide a default value. -Boot source selection -- - -Boot mode is selected by an MSEL-DIP marked S1804 and GPIO_0 position adjacent -to the 40pin GPIO header. ON/ONKE and number markings of the MSEL-DIP are -misleading; Instead refer to the ``L`` (0) and ``H`` (1) silkscreen for -accurate selection. - -+ (QSPI) Flash: 00 -+ SD: 01 -+ EMMC: 10 -+ UART: 11 - Preparing the SD-Card - @@ -109,10 +96,7 @@ Copy U-Boot to the SD card sudo cp jh7110-starfive-visionfive-2.dtb /mnt/ sudo umount /mnt -Booting - -Once you plugin the sdcard and power up, you should see the U-Boot prompt. +.. include:: jh7110_common.rst Serial Number and MAC address issues diff --git a/doc/board/starfive/visionfive2.rst b/doc/board/starfive/visionfive2.rst index 44e7fcb3a48..6f3c572f1f8 100644 --- a/doc/board/starfive/visionfive2.rst +++ b/doc/board/starfive/visionfive2.rst @@ -132,13 +132,7 @@ Program the SD card sudo cp jh7110-starfive-visionfive-2.dtb /mnt/ sudo umount /mnt -Booting - -The board provides the DIP switches MSEL[1:0] to select the boot device. -To select booting from SD-card set the DIP switches MSEL[1:0] to 10. - -Once you plugin the sdcard and power up, you should see the U-Boot prompt. +.. include:: jh7110_common.rst Sample boot log from StarFive VisionFive2 board --- @@ -479,34 +473,3 @@ Sample boot log from StarFive VisionFive2 board Welcome to Buildroot buildroot login: - -Booting from SPI - - -Use Building steps from "Booting from MMC using U-Boot SPL" section. - -Partition the SPI in Linux via mtdblock. (Require to boot the board in -SD boot mode by enabling MTD block in Linux) - -Use prebuilt image from here [1], which support to partition the SPI flash. - - -Program the SPI (Require to boot the board in SD boot mode) - -Execute below steps on U-Boot proper, - -.. code-block:: none - - sf probe - fatload mmc 1:3 $kernel_addr_r u-boot.itb - sf update $kernel_addr_r 0x10 $filesize - - fatload mmc 1:3 $kernel_addr_r u-boot-spl.bin.normal.out - sf update $kernel_addr_r 0x0 $filesize - - -Power off the board - -Change DIP switches MSEL[1:0] are set to 00, select the boot mode to flash - -Power up the board. -- 2.48.1
[PATCH RFT v2 2/3] fastboot: blk: switch emmc to use the block helpers
From: Dmitrii Merkurev
Switch the mmc backend to this new shared block helpers,
reducing block logic and only leaving MMC specific logic.
Signed-off-by: Dmitrii Merkurev
Signed-off-by: Neil Armstrong
---
drivers/fastboot/fb_mmc.c | 210 +++---
1 file changed, 12 insertions(+), 198 deletions(-)
diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
index
dca7c222f35659b22d327541b245760a6a6d7b35..11d9c8e84602c7434733c060b84c91c38772ac9f
100644
--- a/drivers/fastboot/fb_mmc.c
+++ b/drivers/fastboot/fb_mmc.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -20,10 +21,6 @@
#define BOOT_PARTITION_NAME "boot"
-struct fb_mmc_sparse {
- struct blk_desc *dev_desc;
-};
-
static int raw_part_get_info_by_name(struct blk_desc *dev_desc,
const char *name,
struct disk_partition *info)
@@ -114,118 +111,10 @@ static int part_get_info_by_name_or_alias(struct
blk_desc **dev_desc,
return do_get_part_info(dev_desc, name, info);
}
-/**
- * fb_mmc_blk_write() - Write/erase MMC in chunks of FASTBOOT_MAX_BLK_WRITE
- *
- * @block_dev: Pointer to block device
- * @start: First block to write/erase
- * @blkcnt: Count of blocks
- * @buffer: Pointer to data buffer for write or NULL for erase
- */
-static lbaint_t fb_mmc_blk_write(struct blk_desc *block_dev, lbaint_t start,
-lbaint_t blkcnt, const void *buffer)
-{
- lbaint_t blk = start;
- lbaint_t blks_written;
- lbaint_t cur_blkcnt;
- lbaint_t blks = 0;
- int i;
-
- for (i = 0; i < blkcnt; i += FASTBOOT_MAX_BLK_WRITE) {
- cur_blkcnt = min((int)blkcnt - i, FASTBOOT_MAX_BLK_WRITE);
- if (buffer) {
- if (fastboot_progress_callback)
- fastboot_progress_callback("writing");
- blks_written = blk_dwrite(block_dev, blk, cur_blkcnt,
- buffer + (i *
block_dev->blksz));
- } else {
- if (fastboot_progress_callback)
- fastboot_progress_callback("erasing");
- blks_written = blk_derase(block_dev, blk, cur_blkcnt);
- }
- blk += blks_written;
- blks += blks_written;
- }
- return blks;
-}
-
-static lbaint_t fb_mmc_sparse_write(struct sparse_storage *info,
- lbaint_t blk, lbaint_t blkcnt, const void *buffer)
-{
- struct fb_mmc_sparse *sparse = info->priv;
- struct blk_desc *dev_desc = sparse->dev_desc;
-
- return fb_mmc_blk_write(dev_desc, blk, blkcnt, buffer);
-}
-
-static lbaint_t fb_mmc_sparse_reserve(struct sparse_storage *info,
- lbaint_t blk, lbaint_t blkcnt)
-{
- return blkcnt;
-}
-
-static void write_raw_image(struct blk_desc *dev_desc,
- struct disk_partition *info, const char *part_name,
- void *buffer, u32 download_bytes, char *response)
-{
- lbaint_t blkcnt;
- lbaint_t blks;
-
- /* determine number of blocks to write */
- blkcnt = ((download_bytes + (info->blksz - 1)) & ~(info->blksz - 1));
- blkcnt = lldiv(blkcnt, info->blksz);
-
- if (blkcnt > info->size) {
- pr_err("too large for partition: '%s'\n", part_name);
- fastboot_fail("too large for partition", response);
- return;
- }
-
- puts("Flashing Raw Image\n");
-
- blks = fb_mmc_blk_write(dev_desc, info->start, blkcnt, buffer);
-
- if (blks != blkcnt) {
- pr_err("failed writing to device %d\n", dev_desc->devnum);
- fastboot_fail("failed writing to device", response);
- return;
- }
-
- printf(" wrote " LBAFU " bytes to '%s'\n", blkcnt * info->blksz,
- part_name);
- fastboot_okay(NULL, response);
-}
-
-#if defined(CONFIG_FASTBOOT_MMC_BOOT_SUPPORT) || \
- defined(CONFIG_FASTBOOT_MMC_USER_SUPPORT)
-static int fb_mmc_erase_mmc_hwpart(struct blk_desc *dev_desc)
-{
- lbaint_t blks;
-
- debug("Start Erasing mmc hwpart[%u]...\n", dev_desc->hwpart);
-
- blks = fb_mmc_blk_write(dev_desc, 0, dev_desc->lba, NULL);
-
- if (blks != dev_desc->lba) {
- pr_err("Failed to erase mmc hwpart[%u]\n", dev_desc->hwpart);
- return 1;
- }
-
- printf(" erased %llu bytes from mmc hwpart[%u]\n",
- (u64)(dev_desc->lba * dev_desc->blksz), dev_desc->hwpart);
-
- return 0;
-}
-#endif
-
#ifdef CONFIG_FASTBOOT_MMC_BOOT_SUPPORT
static void fb_mmc_boot_ops(struct blk_desc *dev_desc, void *buffer,
int hwpart, u32 buff_sz, char *response)
{
- lbaint_t blkcnt;
- lbaint_t blks;
- unsigned long blksz;
Re: Issue with booting FIT image using Yocto with raspberry pi cm4
Hi Andreas,
Can you please try with this series from Simon?
https://lore.kernel.org/u-boot/20241220003447.2913443-1-...@chromium.org/
It solved booting mainline kernel on CM4 for me (albeit not with FIT images).
Thanks,
Chris
On Tue, 8 Apr 2025 at 19:23, Andreas Enbacka wrote:
>
> Hello everyone,
>
> I am working on building a custom image targeting the raspberry pi cm4
> using Yocto / meta-raspberrypi (scarthgap release) and u-boot.
>
> The kernel and rootfs booted without issues before switching to using fit
> image. I build the yocto image with kernel type / class set to fitImage.
> For building u-boot I have specified e.g., CONFIG_FIT=y and similar
> parameters.
>
> When booting the board, u-boot loads the fitImage (around 10MB in size) and
> shows the kernel / device tree blob info (kernel is gzip compressed).
> However, the process fails when u-boot executes "Uncompressing kernel..",
> with Error: inflate() returned -3. This leads to a boot loop.
>
> I tried manually executing
> 'load mmc 0:1 ${kernel_addr_r} fitImage; bootm
> ${kernel_addr_r}#conf-bcm-2711-rpi-4-b.dtb', but it results in same error.
>
> The kernel_addr_r is set as 0x0008.
>
> Any information about this would be greatly appreciated.
>
> Best regards,
> Andreas Enbacka
[PATCH RESEND] firmware: scmi: support to manage SCMI protocol drivers with a linker-genetated array
From: Alice Guo
U_BOOT_SCMI_PROTO_DRIVER macro is used to add a SCMI protocol driver to
scmi_proto_driver list. scmi_proto_driver_get() function can be used to
match a SCMI protocol id and its driver.
Signed-off-by: Alice Guo
---
drivers/firmware/scmi/scmi_agent-uclass.c | 16
include/scmi_agent-uclass.h | 15 +++
2 files changed, 31 insertions(+)
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index e6e43ae936a..ea79cfa0cf2 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -352,6 +352,22 @@ static int scmi_fill_base_info(struct udevice *agent,
struct udevice *dev)
return 0;
}
+static struct driver *scmi_proto_driver_get(unsigned int proto_id)
+{
+ struct scmi_proto_driver *start, *entry;
+ int n_ents;
+
+ start = ll_entry_start(struct scmi_proto_driver, scmi_proto_driver);
+ n_ents = ll_entry_count(struct scmi_proto_driver, scmi_proto_driver);
+
+ for (entry = start; entry != start + n_ents; entry++) {
+ if (entry->match->proto_id == proto_id)
+ return entry->driver;
+ }
+
+ return NULL;
+}
+
/*
* SCMI agent devices binds devices of various uclasses depending on
* the FDT description. scmi_bind_protocol() is a generic bind sequence
diff --git a/include/scmi_agent-uclass.h b/include/scmi_agent-uclass.h
index 33e0e18c30d..842c56858af 100644
--- a/include/scmi_agent-uclass.h
+++ b/include/scmi_agent-uclass.h
@@ -115,4 +115,19 @@ struct scmi_agent_ops {
struct scmi_msg *msg);
};
+struct scmi_proto_match {
+ unsigned int proto_id;
+};
+
+struct scmi_proto_driver {
+ struct driver *driver;
+ const struct scmi_proto_match *match;
+};
+
+#define U_BOOT_SCMI_PROTO_DRIVER(__name, __match) \
+ ll_entry_declare(struct scmi_proto_driver, __name, scmi_proto_driver) =
{ \
+ .driver = llsym(struct driver, __name, driver), \
+ .match = __match, \
+ }
+
#endif /* _SCMI_TRANSPORT_UCLASS_H */
--
2.43.0
Re: [PATCH v4 01/10] rockchip: binman: Correct the OS prop for U-Boot
Hi Jonas, Simon,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
From: Simon Glass
The U-Boot image is currently being identified as an invalid OS in
spl_fit_image_get_os() due to case sensitive compare.
Use the correct lower-case value to fix this.
Fixes: e0c0efff2a02 ("rockchip: Support building the all output files in
binman")
Signed-off-by: Simon Glass
Signed-off-by: Jonas Karlman
---
Changes in v4:
- Update commit message
- Split from "VBE serial part H: Implement VBE on Rockchip RK3399"
---
arch/arm/dts/rockchip-u-boot.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index c8c928c7e508..e9ed1d4b5738 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -50,7 +50,7 @@
u-boot {
description = "U-Boot";
type = "standalone";
- os = "U-Boot";
+ os = "u-boot";
It seems like it's not the only place where this is wrong?
$ git grep 'os.*=.*U-Boot'
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi:
os = "U-Boot";
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi:
os = "U-Boot";
arch/arm/dts/k3-binman.dtsi:os =
"U-Boot";
arch/arm/dts/k3-binman.dtsi:os =
"U-Boot";
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi:
os = "U-Boot";
arch/arm/dts/socfpga_soc64_fit-u-boot.dtsi:
os = "U-Boot";
arch/riscv/dts/binman.dtsi:os =
"U-Boot";
tools/binman/entries.rst:os = "U-Boot";
tools/binman/etype/fit.py:os = "U-Boot";
tools/binman/test/343_fit_encrypt_data.dts:
os = "U-Boot";
tools/binman/test/344_fit_encrypt_data_no_key.dts:
os = "U-Boot";
So we should probably fix those as well.
Cheers,
Quentin
Re: [PATCH v4 02/10] rockchip: binman: Factor out arch and compression
Hi Jonas, Simon,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
From: Simon Glass
Declare arch and compression at the top of the file to avoid needing
ifdefs in every usage.
Add a few comments to help with the remaining #ifdefs.
Signed-off-by: Simon Glass
Signed-off-by: Jonas Karlman
---
Changes in v4:
- Split from "VBE serial part H: Implement VBE on Rockchip RK3399"
---
arch/arm/dts/rockchip-u-boot.dtsi | 44 +++
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi
b/arch/arm/dts/rockchip-u-boot.dtsi
index e9ed1d4b5738..2b01dc660562 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -5,6 +5,20 @@
#include
+#ifdef CONFIG_ARM64
+#define ARCH "arm64"
+#else
+#define ARCH "arm"
+#endif
+
I would refrain from using ARCH here as it's something we already use to
specify the architecture to build (e.g. make ARCH=arm64 CROSS_COMPILE=...).
Maybe FIT_ARCH?
+#if defined(CONFIG_SPL_GZIP)
+#define COMP "gzip"
+#elif defined(CONFIG_SPL_LZMA)
+#define COMP "lzma"
+#else
+#define COMP "none"
+#endif
+
This is specific to the U-Boot proper image node only, maybe we should
have this constant named more appropriately, e.g. FIT_PROPER_COMP or
something like that?
Reading the symbols also, I believe their help text is misleading or
confusing (at least the _GZIP ones, _ZSTD seems okay).
Also, I'm wondering if it actually makes sense to force a specific
U-Boot proper compression algorithm based on a symbol of what
decompression algorithms are supported in U-Boot SPL. Like, why should
gzip be picked if I also have lzma enabled? In any case, nothing related
to this patch.
/ {
binman: binman {
multiple-images;
@@ -51,26 +65,12 @@
description = "U-Boot";
type = "standalone";
os = "u-boot";
-#ifdef CONFIG_ARM64
- arch = "arm64";
-#else
- arch = "arm";
-#endif
-#if defined(CONFIG_SPL_GZIP)
- compression = "gzip";
-#elif defined(CONFIG_SPL_LZMA)
- compression = "lzma";
-#else
- compression = "none";
-#endif
+ arch = ARCH;
+ compression = COMP;
load = ;
entry = ;
u-boot-nodtb {
-#if defined(CONFIG_SPL_GZIP)
- compress = "gzip";
-#elif defined(CONFIG_SPL_LZMA)
- compress = "lzma";
-#endif
+ compress = COMP;
};
#ifdef CONFIG_SPL_FIT_SIGNATURE
hash {
@@ -84,7 +84,7 @@
fit,operation = "split-elf";
description = "ARM Trusted Firmware";
type = "firmware";
- arch = "arm64";
+ arch = ARCH;
os = "arm-trusted-firmware";
compression = "none";
fit,load;
@@ -103,7 +103,7 @@
fit,operation = "split-elf";
description = "TEE";
type = "tee";
- arch = "arm64";
+ arch = ARCH;
os = "tee";
compression = "none";
fit,load;
@@ -119,11 +119,11 @@
};
#endif
};
-#else
+#else /* !CONFIG_ARM64 */
op-tee {
description = "OP-TEE";
type = "tee";
- arch = "arm";
+ arch = ARCH;
os = "tee";
compression = "none";
load = <(CFG_SYS_SDRAM_BASE +
0x840)>;
Wondering if we couldn't put some of the Aarch32 and Aarch64 OP-TEE OS
node(s) in common?
The change is fine, finding a more appropriate name for COMP and ARCH
and it's all good.
Cheers,
Quentin
Re: [PATCH v4 07/10] rockchip: binman: Include a compatible string in each configuration
Hi Jonas, Simon, On 3/29/25 4:06 PM, Jonas Karlman wrote: From: Simon Glass Provide a compatible string in the config nodes that U-Boot can use to help decide which configuration to use. Can you tell us more about this? I don't think mkimage -l/dumpimage -l actually provide that information and the docs are sparse as to what "so that things work correctly with FIT's configuration-matching algortihm." means. Looking a bit into tools/binman/ftest.py it seems like it's a way to expose the DT compatible property from within the first entry in `fdt` array property (a DTB) into the configuration node in the fit image. I think it'd make sense to update dumpimage/mkimage/etc... to dump that information as well? Reviewed-by: Quentin Schulz Thanks! Quentin
[PATCH v3 8/8] doc: jh7110: describe debug UART
Provide the settings for using the debug UART in SPL. Signed-off-by: Heinrich Schuchardt --- v3: no change v2: new patch --- doc/board/starfive/jh7110_common.rst | 14 ++ 1 file changed, 14 insertions(+) diff --git a/doc/board/starfive/jh7110_common.rst b/doc/board/starfive/jh7110_common.rst index 44ccd612ff4..3c939d50de7 100644 --- a/doc/board/starfive/jh7110_common.rst +++ b/doc/board/starfive/jh7110_common.rst @@ -64,3 +64,17 @@ u-boot.itb via the Y-modem protocol. Due to restrictions of the boot ROM not all X-modem implementations are compatible. The package tio (https://github.com/tio/tio) has been found to be usable. + +Debug UART +-- + +By default the SBI interface is used for the debug UART. But this only works +in main U-Boot. To enable the debug UART in SPL, too, use the following +settings:: + +CONFIG_DEBUG_UART=y +CONFIG_DEBUG_UART_NS16550=y +CONFIG_DEBUG_UART_BASE=0x1000 +CONFIG_SPL_DEBUG_UART_BASE=0x1000 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEBUG_UART_SHIFT=2 -- 2.48.1
Re: [PATCH v4 03/10] rockchip: binman: Add an fdtmap
Hi Jonas, Simon, On 3/29/25 4:06 PM, Jonas Karlman wrote: From: Simon Glass Add an fdtmap so it is possible to look at the image with 'binman ls'. Signed-off-by: Simon Glass Signed-off-by: Jonas Karlman Reviewed-by: Quentin Schulz Thanks! Quentin
Re: [PATCH v4 04/10] rockchip: binman: Create a template for the FIT
Hi Jonas, Simon,
On 3/29/25 4:06 PM, Jonas Karlman wrote:
[...]
-#if defined(CONFIG_ARM64) || defined(CONFIG_SPL_OPTEE_IMAGE)
+#ifdef HAS_FIT
fit {
type = "blob";
filename = "u-boot.itb";
Use the template for the SPI here already instead of splitting it in a
separate commit?
Reviewed-by: Quentin Schulz
Thanks!
Quentin
