Pull request doc-2023-10-rc5-2
Dear Tom, The following changes since commit 252592214f79d8206c3cf0056a8827a0010214e0: Merge tag 'doc-2023-10-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-09-09 09:33:02 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/doc-2023-10-rc5-2 for you to fetch changes up to 8bd7d08407f986fe3c69f3e198f6f7152e12dea8: binman: doc: fix reference tag placement for Logging section (2023-09-16 18:17:25 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/17746 Pull request doc-2023-10-rc5-2 Documentation: * fix code comments referring to doc/develop/expo.rst * remove unused values from Chromebook kernel command line * correct reference tag placement in tools/binman/binman.rst Others: * test: fix build dependency for event unit tests Heinrich Schuchardt (1): test: build dependency for event unit tests Jaewon Jung (1): doc: delete unused values kernel command line Massimo Pegorer (2): expo: Fix documentation reference binman: doc: fix reference tag placement for Logging section boot/expo_build.c | 6 +++--- doc/board/google/chromebook_coral.rst | 4 ++-- doc/usage/cmd/bootflow.rst| 4 ++-- include/expo.h| 2 +- test/common/Makefile | 2 +- tools/binman/binman.rst | 2 +- 6 files changed, 10 insertions(+), 10 deletions(-)
Re: [PATCH v2 2/2] riscv: dts: starfive: generate u-boot-spl.bin.normal.out
On 9/17/23 00:19, Jonas Karlman wrote:
On 2023-09-06 14:00, Heinrich Schuchardt wrote:
The StarFive VisionFive 2 board cannot load spl/u-boot-spl.bin but needs a
prefixed header. We have referring to a vendor tool (spl_tool) for this
task. 'mkimage -T sfspl' can generate the prefixed file.
Use binman to invoke mkimage for the generation of file
spl/u-boot-spl.bin.normal.out.
Update the documentation.
Signed-off-by: Heinrich Schuchardt
Tested-by: Chanho Park
---
v2:
Fix a typo in a comment in tools/sfspl.c
Add Tested-by credit
---
.../dts/jh7110-starfive-visionfive-2-u-boot.dtsi | 10 ++
doc/board/starfive/visionfive2.rst | 14 ++
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
index 13f69da31e..defe2b605f 100644
--- a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
+++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
@@ -103,4 +103,14 @@
};
};
};
+ u-boot-spl {
+ filename = "spl/u-boot-spl.bin.normal.out";
+
+ mkimage {
+ args = "-T sfspl";
+ blob {
+ filename = "spl/u-boot-spl.bin";
+ };
+ };
+ };
This should probably be:
mkimage {
filename = "spl/u-boot-spl.bin.normal.out";
args = "-T sfspl";
u-boot-spl {
};
};
@Jonas
If I replace the node u-boot-spl by the suggested mkimage node, I get a
file spl/u-boot-spl.bin.normal.out which is identical to
spl/u-boot-spl.bin. It lacks the header that mkimage should create.
Replacing the blob node by a u-boot-spl node is possible. Whether it is
better readable is a matter of taste.
@Simon:
Could you, please, have a look at doc/develop/package/entries.rst. It
seems not to fully describe how binman is controlled via the device-tree.
* A blob sub-node for the mkimage node is not described.
* A mkimage node which is not a direct subnode of binman is not mentioned.
* Why the target filename must be outside of the mkimage node in my case
is not evident.
Maybe a more formal description of the schema in a yaml file would help.
Best regards
Heinrich
Regards,
Jonas
};
diff --git a/doc/board/starfive/visionfive2.rst
b/doc/board/starfive/visionfive2.rst
index 941899a0a4..f5575ab68b 100644
--- a/doc/board/starfive/visionfive2.rst
+++ b/doc/board/starfive/visionfive2.rst
@@ -65,18 +65,8 @@ Now build the U-Boot SPL and U-Boot proper
make starfive_visionfive2_defconfig
make
OPENSBI=$(opensbi_dir)/opensbi/build/platform/generic/firmware/fw_dynamic.bin
-This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb)
-
-u-boot-spl.bin cannot be used directly on StarFive VisionFive2,we need
-to convert the u-boot-spl.bin to u-boot-spl.bin.normal.out with
-the below command:
-
- ./spl_tool -c -f $(Uboot_PATH)/spl/u-boot-spl.bin
-
-More detailed description of spl_tool,please refer spl_tool documenation.
-(Note: spl_tool git repo is at
https://github.com/starfive-tech/Tools/tree/master/spl_tool)
-
-This will generate u-boot-spl.bin.normal.out file.
+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 and U-Boot.
Flashing
Re: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
Hi Frank,
On 2023-08-20 18:00, Frank Wunderlich wrote:
> From: Frank Wunderlich
>
> Add Bananapi R2 Pro board.
>
> Till now evb dts could be used, but iodomain is different
> (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro)
> and with iodomain driver this can cause hardware fault.
>
> Devicetree in mainline-Linux:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts
>
> Signed-off-by: Frank Wunderlich
> ---
> v3:
> - disable gmac0 as switch-driver is not yet ready to attach to the mac
> v2:
> - drop switch-node for now as u-boot driver works differently to linux
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 +
> arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++
> configs/bpi-r2pro-rk3568_defconfig| 101
> 4 files changed, 675 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts
> create mode 100644 configs/bpi-r2pro-rk3568_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index bd518064f35f..767bf9db39fb 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -182,7 +182,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> rk3568-nanopi-r5s.dtb \
> rk3568-odroid-m1.dtb \
> rk3568-radxa-e25.dtb \
> - rk3568-rock-3a.dtb
> + rk3568-rock-3a.dtb \
> + rk3568-bpi-r2pro.dtb
>
> dtb-$(CONFIG_ROCKCHIP_RK3588) += \
> rk3588-edgeble-neu6a-io.dtb \
> diff --git a/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> new file mode 100644
> index ..382a52a28b10
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> + */
> +
> +#include "rk356x-u-boot.dtsi"
> +
> +/ {
> + chosen {
> + stdout-path = &uart2;
> + u-boot,spl-boot-order = "same-as-spl", &sdmmc0, &sdhci;
This is the default order in rk356x-u-boot.dtsi and can be dropped.
> + };
> +};
> +
> +&sdmmc0 {
> + status = "okay";
sdmmc0 is already enabled in rk3568-bpi-r2pro.dts
> +};
> +
> +&uart2 {
> + clock-frequency = <2400>;
> + bootph-pre-ram;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3568-bpi-r2pro.dts
> b/arch/arm/dts/rk3568-bpi-r2pro.dts
> new file mode 100644
> index ..e4fcbb8a1174
> --- /dev/null
> +++ b/arch/arm/dts/rk3568-bpi-r2pro.dts
Should be a 1:1 copy from kernel.
[...]
> diff --git a/configs/bpi-r2pro-rk3568_defconfig
> b/configs/bpi-r2pro-rk3568_defconfig
> new file mode 100644
> index ..e8936261eab3
> --- /dev/null
> +++ b/configs/bpi-r2pro-rk3568_defconfig
> @@ -0,0 +1,101 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_COUNTER_FREQUENCY=2400
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_TEXT_BASE=0x00a0
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_NR_DRAM_BANKS=2
> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
> +CONFIG_DEFAULT_DEVICE_TREE="rk3568-bpi-r2pro"
> +CONFIG_ROCKCHIP_RK3568=y
> +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
> +CONFIG_SPL_SERIAL=y
> +CONFIG_SPL_STACK_R_ADDR=0x60
> +CONFIG_SPL_STACK=0x40
> +CONFIG_DEBUG_UART_BASE=0xFE66
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_SYS_LOAD_ADDR=0xc00800
> +CONFIG_DEBUG_UART=y
> +CONFIG_FIT=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
> +#CONFIG_OF_SYSTEM_SETUP=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-bpi-r2pro"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_MAX_SIZE=0x4
> +CONFIG_SPL_PAD_TO=0x7f8000
> +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> +CONFIG_SPL_BSS_START_ADDR=0x400
> +CONFIG_SPL_BSS_MAX_SIZE=0x4000
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_ATF=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_PMIC=y
> +CONFIG_CMD_REGULATOR=y
> +# CONFIG_SPL_DOS_PARTITION is not set
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_OF_LIVE=y
> +CONFIG_NET=n
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_SPL_REGMAP=y
> +CONFIG_SPL_SYSCON=y
> +CONFIG_SPL_CLK=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_ROCKCHIP_GPIO_V2=y
This Kconfig option does not exits.
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MISC=y
> +CONFIG_SUPPORT_EMMC_RPMB=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_SDMA=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
Please drop CONFIG_ETH_DESIGNWARE and CONFIG_G
Re: [PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot
On Sat, Sep 16, 2023 at 03:14:58PM +0200, Ryan Lahfa wrote:
> Currently, it seems like the `initrd_filesize` was uninitialized for a
> while.
>
> This is particularly problematic when attempting to `zboot` with a
> initrd with a size coming from `label->initrd`, because it will provide
> you with a 0-long initrd at boot time, making the kernel fail to
> continue the boot.
>
> This fixes the issue and I confirmed it enable me booting a U-Boot on
> QEMU x86_64 q35 with NixOS kernel and initrds.
>
> Signed-off-by: Ryan Lahfa
> Cc: Tom Rini
> Cc: Simon Glass
> Cc: Bin Meng
> Cc: Zhaofeng Li
> Cc: Heinrich Schuchardt
> Cc: Ramon Fried
> Cc: Artem Lapkin
Reviewed-by: Tom Rini
And since you mentioned it in the follow-up, here's the tag so patchwork
will pick it up:
Fixes: 085cbdafca9c ("pxe: simplify label_boot()")
Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PULL] u-boot-usb/next
On Sat, Sep 16, 2023 at 12:16:18PM +0200, Marek Vasut wrote: > The following changes since commit 2fe4b54556ea6271237b35de68dc458bfceab94c: > > Merge branch '2023-09-14-remove-NEEDS_MANUAL_RELOC' into next (2023-09-14 > 16:23:49 -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next > > for you to fetch changes up to 2caf974b5fac69a1b778e64503f2c107a8d7c3a3: > > board: usb: Replace legacy usb_gadget_handle_interrupts() (2023-09-15 > 23:38:02 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
On 2023-09-16 18:45, Frank Wunderlich wrote: > Am 16. September 2023 18:07:44 MESZ schrieb Marek Vasut : >> On 9/16/23 16:18, Frank Wunderlich wrote: >>> Hi, >>> >>> just a friedly reminder. would be great if it can be merged in next >>> uboot-version. >> >> +CC Tom >> >>> regards Frank >>> >>> Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr Von: "Frank Wunderlich" An: u-boot@lists.denx.de Cc: "Frank Wunderlich" , "Simon Glass" , "Philipp Tomsich" , "Kever Yang" , "Marek Vasut" , "Jonas Karlman" Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board From: Frank Wunderlich Add Bananapi R2 Pro board. Till now evb dts could be used, but iodomain is different (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) and with iodomain driver this can cause hardware fault. Devicetree in mainline-Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts >> >> What would be real helpful is a commit ID from which the DT was copied , so >> it can be easily updated in the future. > > It is no plain copy...i removed parts not relevant for uboot now (from > current linux version). E.g. switch driver is currently bundled in mtk > ethernet driver and using different devicetree structure than linux dsa > driver. We have to separate it before we can use it on r2pro. But this will > take some time...also pcie(-phy) does not have a driver yet,so before adding > dead code i dropped these parts for now. pcie(-phy) should have a working driver for rk3568 as of v2023.10-rc2, and is extended to support PCIe bifurcation with the following series: rockchip: rk3568: Fix use of PCIe bifurcation https://patchwork.ozlabs.org/project/uboot/list/?series=366997&state=* Regards, Jonas > > regards Frank
Re: [PATCH v2 2/2] riscv: dts: starfive: generate u-boot-spl.bin.normal.out
On 2023-09-06 14:00, Heinrich Schuchardt wrote:
> The StarFive VisionFive 2 board cannot load spl/u-boot-spl.bin but needs a
> prefixed header. We have referring to a vendor tool (spl_tool) for this
> task. 'mkimage -T sfspl' can generate the prefixed file.
>
> Use binman to invoke mkimage for the generation of file
> spl/u-boot-spl.bin.normal.out.
>
> Update the documentation.
>
> Signed-off-by: Heinrich Schuchardt
> Tested-by: Chanho Park
> ---
> v2:
> Fix a typo in a comment in tools/sfspl.c
> Add Tested-by credit
> ---
> .../dts/jh7110-starfive-visionfive-2-u-boot.dtsi | 10 ++
> doc/board/starfive/visionfive2.rst | 14 ++
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> index 13f69da31e..defe2b605f 100644
> --- a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> @@ -103,4 +103,14 @@
> };
> };
> };
> + u-boot-spl {
> + filename = "spl/u-boot-spl.bin.normal.out";
> +
> + mkimage {
> + args = "-T sfspl";
> + blob {
> + filename = "spl/u-boot-spl.bin";
> + };
> + };
> + };
This should probably be:
mkimage {
filename = "spl/u-boot-spl.bin.normal.out";
args = "-T sfspl";
u-boot-spl {
};
};
Regards,
Jonas
> };
> diff --git a/doc/board/starfive/visionfive2.rst
> b/doc/board/starfive/visionfive2.rst
> index 941899a0a4..f5575ab68b 100644
> --- a/doc/board/starfive/visionfive2.rst
> +++ b/doc/board/starfive/visionfive2.rst
> @@ -65,18 +65,8 @@ Now build the U-Boot SPL and U-Boot proper
> make starfive_visionfive2_defconfig
> make
> OPENSBI=$(opensbi_dir)/opensbi/build/platform/generic/firmware/fw_dynamic.bin
>
> -This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb)
> -
> -u-boot-spl.bin cannot be used directly on StarFive VisionFive2,we need
> -to convert the u-boot-spl.bin to u-boot-spl.bin.normal.out with
> -the below command:
> -
> - ./spl_tool -c -f $(Uboot_PATH)/spl/u-boot-spl.bin
> -
> -More detailed description of spl_tool,please refer spl_tool documenation.
> -(Note: spl_tool git repo is at
> https://github.com/starfive-tech/Tools/tree/master/spl_tool)
> -
> -This will generate u-boot-spl.bin.normal.out file.
> +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 and U-Boot.
>
> Flashing
>
Re: [PATCH v2 1/2] tools: mkimage: Add StarFive SPL image support
On Wed, 2023-09-06 at 14:00, Heinrich Schuchardt wrote:
> The StarFive JH7110 base boards require a header to be prefixed to the SPL
> binary image. This has previously done with a vendor tool 'spl_tool'
> published under a GPL-2-or-later license. Integrate this capability into
> mkimage.
>
> Signed-off-by: Heinrich Schuchardt
> Tested-by: Chanho Park
Tested-by: Milan P. Stanić
> ---
> v2:
> no change except for Tested-by credit
> ---
> boot/image.c| 1 +
> include/image.h | 1 +
> tools/Makefile | 1 +
> tools/sfspl.c | 174
> 4 files changed, 177 insertions(+)
> create mode 100644 tools/sfspl.c
>
> diff --git a/boot/image.c b/boot/image.c
> index 5c4f9b807d..3a99d2e897 100644
> --- a/boot/image.c
> +++ b/boot/image.c
> @@ -182,6 +182,7 @@ static const table_entry_t uimage_type[] = {
> { IH_TYPE_SUNXI_TOC0, "sunxi_toc0", "Allwinner TOC0 Boot Image"
> },
> { IH_TYPE_FDT_LEGACY, "fdt_legacy", "legacy Image with Flat
> Device Tree ", },
> { IH_TYPE_RENESAS_SPKG, "spkgimage", "Renesas SPKG Image" },
> + { IH_TYPE_STARFIVE_SPL, "sfspl", "StarFive SPL Image" },
> { -1, "", "", },
> };
>
> diff --git a/include/image.h b/include/image.h
> index 01a6787d21..5f85bf84a2 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -231,6 +231,7 @@ enum image_type_t {
> IH_TYPE_SUNXI_TOC0, /* Allwinner TOC0 Boot Image */
> IH_TYPE_FDT_LEGACY, /* Binary Flat Device Tree Blob in a
> Legacy Image */
> IH_TYPE_RENESAS_SPKG, /* Renesas SPKG image */
> + IH_TYPE_STARFIVE_SPL, /* StarFive SPL image */
>
> IH_TYPE_COUNT, /* Number of image types */
> };
> diff --git a/tools/Makefile b/tools/Makefile
> index 3d0c4b0dd6..1aa1e36137 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -123,6 +123,7 @@ dumpimage-mkimage-objs := aisimage.o \
> pblimage.o \
> pbl_crc32.o \
> renesas_spkgimage.o \
> + sfspl.o \
> vybridimage.o \
> stm32image.o \
> $(ROCKCHIP_OBS) \
> diff --git a/tools/sfspl.c b/tools/sfspl.c
> new file mode 100644
> index 00..ec18a0a77e
> --- /dev/null
> +++ b/tools/sfspl.c
> @@ -0,0 +1,174 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright Heinrich Schuchardt
> + *
> + * The StarFive JH7110 requires to prepend a header to u-boot-spl.bin
> describing
> + * the payload length and CRC32.
> + *
> + * This module implements support in mkimage and dumpimage for this file
> format.
> + *
> + * StarFive's spl_tool available under GPL-2.0-and-later at
> + * https://github.com/starfive-tech/Tools implements writing the same file
> + * format and served as a reference.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include "imagetool.h"
> +
> +#define DEFAULT_VERSION 0x01010101
> +#define DEFAULT_BACKUP 0x20U
> +#define DEFAULT_OFFSET 0x240
> +
> +/**
> + * struct spl_hdr - header for SPL on JH7110
> + *
> + * All fields are low-endian.
> + */
> +struct spl_hdr {
> + /** @offset:offset to SPL header (0x240) */
> + unsigned int offset;
> + /** @bkp_offs: address of backup SPL, defaults to DEFAULT_BACKUP */
> + unsigned int bkp_offs;
> + /** @zero1: set to zero */
> + unsigned int zero1[159];
> + /** @version: header version, defaults to DEFAULT_VERSION */
> + unsigned int version;
> + /** @file_size: file size */
> + unsigned int file_size;
> + /** @hdr_size: size of the file header (0x400) */
> + unsigned int hdr_size;
> + /** @crc32: CRC32 */
> + unsigned int crc32;
> + /** @zero2: set to zero */
> + unsigned int zero2[91];
> +};
> +
> +static int sfspl_check_params(struct image_tool_params *params)
> +{
> + /* Only the RISC-V architecture is supported */
> + if (params->Aflag && params->arch != IH_ARCH_RISCV)
> + return EXIT_FAILURE;
> +
> + return EXIT_SUCCESS;
> +}
> +
> +static int sfspl_verify_header(unsigned char *buf, int size,
> +struct image_tool_params *params)
> +{
> + struct spl_hdr *hdr = (void *)buf;
> + unsigned int hdr_size = le32_to_cpu(hdr->hdr_size);
> + unsigned int file_size = le32_to_cpu(hdr->file_size);
> + unsigned int crc = le32_to_cpu(hdr->crc32);
> + unsigned int crc_check;
> +
> + if (size < 0 ||
> + (size_t)size < sizeof(struct spl_hdr) ||
> + (size_t)size < hdr_size + file_size) {
> + printf("Truncated file\n");
> + return EXIT_FAILURE;
> + }
> + if (hdr->version != DEFAULT_VERSION) {
> + printf("Unknown file format version\n");
> + return EXIT_FAILURE;
> + }
> + crc_check = cr
Re: [PATCH v2 2/2] riscv: dts: starfive: generate u-boot-spl.bin.normal.out
On Wed, 2023-09-06 at 14:00, Heinrich Schuchardt wrote:
> The StarFive VisionFive 2 board cannot load spl/u-boot-spl.bin but needs a
> prefixed header. We have referring to a vendor tool (spl_tool) for this
> task. 'mkimage -T sfspl' can generate the prefixed file.
>
> Use binman to invoke mkimage for the generation of file
> spl/u-boot-spl.bin.normal.out.
>
> Update the documentation.
>
> Signed-off-by: Heinrich Schuchardt
> Tested-by: Chanho Park
Tested-by: Milan P. Stanić
> ---
> v2:
> Fix a typo in a comment in tools/sfspl.c
> Add Tested-by credit
> ---
> .../dts/jh7110-starfive-visionfive-2-u-boot.dtsi | 10 ++
> doc/board/starfive/visionfive2.rst | 14 ++
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> index 13f69da31e..defe2b605f 100644
> --- a/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2-u-boot.dtsi
> @@ -103,4 +103,14 @@
> };
> };
> };
> + u-boot-spl {
> + filename = "spl/u-boot-spl.bin.normal.out";
> +
> + mkimage {
> + args = "-T sfspl";
> + blob {
> + filename = "spl/u-boot-spl.bin";
> + };
> + };
> + };
> };
> diff --git a/doc/board/starfive/visionfive2.rst
> b/doc/board/starfive/visionfive2.rst
> index 941899a0a4..f5575ab68b 100644
> --- a/doc/board/starfive/visionfive2.rst
> +++ b/doc/board/starfive/visionfive2.rst
> @@ -65,18 +65,8 @@ Now build the U-Boot SPL and U-Boot proper
> make starfive_visionfive2_defconfig
> make
> OPENSBI=$(opensbi_dir)/opensbi/build/platform/generic/firmware/fw_dynamic.bin
>
> -This will generate spl/u-boot-spl.bin and FIT image (u-boot.itb)
> -
> -u-boot-spl.bin cannot be used directly on StarFive VisionFive2,we need
> -to convert the u-boot-spl.bin to u-boot-spl.bin.normal.out with
> -the below command:
> -
> - ./spl_tool -c -f $(Uboot_PATH)/spl/u-boot-spl.bin
> -
> -More detailed description of spl_tool,please refer spl_tool documenation.
> -(Note: spl_tool git repo is at
> https://github.com/starfive-tech/Tools/tree/master/spl_tool)
> -
> -This will generate u-boot-spl.bin.normal.out file.
> +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 and U-Boot.
>
> Flashing
>
[PATCH v1 2/2] board: visionfive2: Fixup memory size passed to kernel
Use fdt_fixup_memory to make the memory size data from dtb match
the actual size.
Signed-off-by: Shengyu Qu
Tested-by: Milan P. Stanić
---
board/starfive/visionfive2/starfive_visionfive2.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/board/starfive/visionfive2/starfive_visionfive2.c
b/board/starfive/visionfive2/starfive_visionfive2.c
index 9847e0efdb..700b60ac74 100644
--- a/board/starfive/visionfive2/starfive_visionfive2.c
+++ b/board/starfive/visionfive2/starfive_visionfive2.c
@@ -12,7 +12,9 @@
#include
#include
#include
+#include
+DECLARE_GLOBAL_DATA_PTR;
#define JH7110_L2_PREFETCHER_BASE_ADDR 0x203
#define JH7110_L2_PREFETCHER_HART_OFFSET 0x2000
@@ -76,3 +78,8 @@ void *board_fdt_blob_setup(int *err)
return (ulong *)&_end;
}
+
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ return fdt_fixup_memory(blob, 0x4000, gd->ram_size);
+}
--
2.42.0
[PATCH v1 1/2] configs: visionfive2: Enable CONFIG_OF_BOARD_SETUP
Enable CONFIG_OF_BOARD_SETUP, so we could use ft_board_setup() to fixup memory size passed to kernel. Signed-off-by: Shengyu Qu Tested-by: Milan P. Stanić --- configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index 2376dad538..4d1459a3c2 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -36,6 +36,7 @@ CONFIG_SPL_OPENSBI_LOAD_ADDR=0x4000 CONFIG_ARCH_RV64I=y CONFIG_CMODEL_MEDANY=y CONFIG_RISCV_SMODE=y +CONFIG_OF_BOARD_SETUP=y # CONFIG_OF_BOARD_FIXUP is not set CONFIG_FIT=y CONFIG_DISTRO_DEFAULTS=y -- 2.42.0
[PATCH v1 0/2] Fix memory size problem on Visionfive 2
Currently, we pass u-boot device tree to kernel on Starfive Visionfive 2 , and this is wrong since u-boot dts is not sync with Linux for this board. Jami's patch[1] fixes this problem, but we are still sending unmodified version to kernel that doesn't have a correct memory size info. This series are based on Jami's work and provide a fix for that. [1] https://patchwork.ozlabs.org/project/uboot/cover/20230911153253.20701-1-jamipkettu...@gmail.com/ Shengyu Qu (2): configs: visionfive2: Enable CONFIG_OF_BOARD_SETUP board: visionfive2: Fixup memory size passed to kernel board/starfive/visionfive2/starfive_visionfive2.c | 7 +++ configs/starfive_visionfive2_defconfig| 1 + 2 files changed, 8 insertions(+) -- 2.42.0
Re: bootstd: CACHE Misaligned operation errors (Marvell Armada 385)
Hi Simon,
On Fri, Sep 15, 2023 at 8:40 PM Tony Dinh wrote:
>
> On Fri, Sep 15, 2023 at 6:32 PM Tony Dinh wrote:
> >
> > Hi Tom, Hi Simon,
> >
> > On Wed, Sep 13, 2023 at 9:53 PM Tony Dinh wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, Sep 13, 2023 at 8:38 PM Simon Glass wrote:
> > > >
> > > > Hi Tom,
> > > >
> > > > On Wed, 13 Sept 2023 at 14:14, Tom Rini wrote:
> > > > >
> > > > > On Wed, Sep 13, 2023 at 12:56:53PM -0700, Tony Dinh wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Wed, Sep 13, 2023 at 9:22 AM Tom Rini wrote:
> > > > > > >
> > > > > > > On Tue, Sep 12, 2023 at 12:38:00PM -0700, Tony Dinh wrote:
> > > > > > >
> > > > > > > > I've been testing the boostd for a few Marvell boards and
> > > > > > > > seeing this
> > > > > > > > error on the Thecus N2350 (Marvell Armada 385, dual-core CPU).
> > > > > > > > The
> > > > > > > > "bootflow scan scsi" command triggered the "CACHE: Misaligned
> > > > > > > > operation at range" error. However, this error did not affect
> > > > > > > > the
> > > > > > > > result of the scan, i.e. the bootflow for scsi partition was
> > > > > > > > created
> > > > > > > > correctly, and u-boot is running normally.
> > > > > > > >
> > > > > > > > Enabling CONFIG_SYS_DCACHE_OFF got rid of the errors altogether.
> > > > > > > > Perhaps this is a case where the DCACHE is not required and
> > > > > > > > should be
> > > > > > > > turned off?
> > > > > > > >
> > > > > > > > Please see the log after the break below.
> > > > > > >
> > > > > > > Can you please try -next ? There's at least one SCSI related
> > > > > > > cache
> > > > > > > alignment fix there that's not in master, thanks.
> > > > > >
> > > > > > Unfortunately I got the same errors. This time the ranges are
> > > > > > different, of course.
> > > > > >
> > > > > > master:
> > > > > >
> > > > > > N2350 > bootflow scan scsi
> > > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > > CACHE: Misaligned operation at range [3fb99f88, 3fb9a388]
> > > > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > > > 0x3fb99f88
> > > > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > > > 0x3fb9a388
> > > > > >
> > > > > > next:
> > > > > >
> > > > > > N2350 > bootflow scan scsi
> > > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > > CACHE: Misaligned operation at range [3fb80388, 3fb80788]
> > > > > > ERROR: v7_outer_cache_inval_range - start address is not aligned -
> > > > > > 0x3fb80388
> > > > > > ERROR: v7_outer_cache_inval_range - stop address is not aligned -
> > > > > > 0x3fb80788
> > > > >
> > > > > Can you debug to where these calls are so we can align these buffers?
> > > > > See 02660defdc8a ("scsi: Cache align temporary buffer") for an
> > > > > example.
> > > >
> > > > I wonder if we need to use memalign() when allocating memory to read
> > > > things from the media? But I am not sure which file time is being read,
> > > > or which bootmeth it is.
> > >
> > > Looks like we probably need to align the buffer tempbuff.
> > >
> > > /drivers/scsi/scsi.c
> > > static int scsi_detect_dev(struct udevice *dev, int target, int lun,
> > > struct blk_desc *dev_desc)
> > > {
> > > unsigned char perq, modi;
> > > lbaint_t capacity;
> > > unsigned long blksz;
> > > struct scsi_cmd *pccb = (struct scsi_cmd *)&tempccb;
> > > int count, err;
> > >
> > > pccb->target = target;
> > > pccb->lun = lun;
> > > pccb->pdata = (unsigned char *)&tempbuff;
> > > pccb->datalen = 512;
> > >
> > > If you look at the log I posted previously, this error shows up during
> > > "bootflow scan scsi".
> > >
> >
> > Taking the hint from Simon. I turned on log_debug and can see where
> > the alignment is not correct. It is fs.c fs_read_alloc(). The
> > memalign() call here probably needs to be revised to take into
> > consideration ARCH_DMA_MINALIGN somehow? It is 64 for armv7.
> >
> > diff --git a/fs/fs.c b/fs/fs.c
> > index 2b815b1db0..b70281532e 100644
> > --- a/fs/fs.c
> > +++ b/fs/fs.c
> > @@ -1019,9 +1019,12 @@ int fs_read_alloc(const char *fname, ulong
> > size, uint align, void **bufp)
> > int ret;
> >
> > buf = memalign(align, size + 1);
> > + log_debug("aligned buf addr 0x%x\n", (unsigned int)buf);
> > +
> > if (!buf)
> > return log_msg_ret("buf", -ENOMEM);
> > addr = map_to_sysmem(buf);
> > + log_debug("aligned buf sysmem addr 0x%x\n", (unsigned int)addr);
> >
> > ret = fs_read(fname, addr, 0, size, &bytes_read);
> > if (ret) {
> >
> > Please see the log below after the break.
>
> Actually, it looks like the fix should be in bootmeth_script.c.
>
> diff --git a/boot/bootmeth_script.c b/boot/bootmeth_script.c
> index 0269e0f9b0..68e77aa50a 100644
> --- a/boot/bootmeth_script.c
> +++ b/boot/bootmeth_script
Re: Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
On 9/16/23 18:45, Frank Wunderlich wrote: Am 16. September 2023 18:07:44 MESZ schrieb Marek Vasut : On 9/16/23 16:18, Frank Wunderlich wrote: Hi, just a friedly reminder. would be great if it can be merged in next uboot-version. +CC Tom regards Frank Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr Von: "Frank Wunderlich" An: u-boot@lists.denx.de Cc: "Frank Wunderlich" , "Simon Glass" , "Philipp Tomsich" , "Kever Yang" , "Marek Vasut" , "Jonas Karlman" Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board From: Frank Wunderlich Add Bananapi R2 Pro board. Till now evb dts could be used, but iodomain is different (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) and with iodomain driver this can cause hardware fault. Devicetree in mainline-Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts What would be real helpful is a commit ID from which the DT was copied , so it can be easily updated in the future. It is no plain copy...i removed parts not relevant for uboot now (from current linux version). Ouch, please don't do that. Instead, if you really do need to drop some nodes from U-Boot control DT, say board.dts, introduce new file called board-u-boot.dtsi and add '/delete-node/ &the_node_to_remove;' lines to remove nodes while DTC is processing the DT into .dtb . This way, the imported board.dts from Linux can be later synchronized with newer version of Linux DT, and the U-Boot specific changes are in a separate file. The U-Boot build system will first concatenate the files, i.e. cat board.dts board-u-boot.dtsi > temp.dts and then run DTC on the temp.dts , so whatever changes you do in the board-u-boot.dtsi will be processed after the original board.dts is processed by DTC (DTC processes the input DTS in order). E.g. switch driver is currently bundled in mtk ethernet driver and using different devicetree structure than linux dsa driver. We have to separate it before we can use it on r2pro. But this will take some time...also pcie(-phy) does not have a driver yet,so before adding dead code i dropped these parts for now. See above, that should do the trick.
Re: Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
Am 16. September 2023 18:07:44 MESZ schrieb Marek Vasut : >On 9/16/23 16:18, Frank Wunderlich wrote: >> Hi, >> >> just a friedly reminder. would be great if it can be merged in next >> uboot-version. > >+CC Tom > >> regards Frank >> >> >>> Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr >>> Von: "Frank Wunderlich" >>> An: u-boot@lists.denx.de >>> Cc: "Frank Wunderlich" , "Simon Glass" >>> , "Philipp Tomsich" , "Kever >>> Yang" , "Marek Vasut" , "Jonas >>> Karlman" >>> Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board >>> >>> From: Frank Wunderlich >>> >>> Add Bananapi R2 Pro board. >>> >>> Till now evb dts could be used, but iodomain is different >>> (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) >>> and with iodomain driver this can cause hardware fault. >>> >>> Devicetree in mainline-Linux: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts > >What would be real helpful is a commit ID from which the DT was copied , so it >can be easily updated in the future. It is no plain copy...i removed parts not relevant for uboot now (from current linux version). E.g. switch driver is currently bundled in mtk ethernet driver and using different devicetree structure than linux dsa driver. We have to separate it before we can use it on r2pro. But this will take some time...also pcie(-phy) does not have a driver yet,so before adding dead code i dropped these parts for now. regards Frank
Re: Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
On 9/16/23 16:18, Frank Wunderlich wrote: Hi, just a friedly reminder. would be great if it can be merged in next uboot-version. +CC Tom regards Frank Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr Von: "Frank Wunderlich" An: u-boot@lists.denx.de Cc: "Frank Wunderlich" , "Simon Glass" , "Philipp Tomsich" , "Kever Yang" , "Marek Vasut" , "Jonas Karlman" Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board From: Frank Wunderlich Add Bananapi R2 Pro board. Till now evb dts could be used, but iodomain is different (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) and with iodomain driver this can cause hardware fault. Devicetree in mainline-Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts What would be real helpful is a commit ID from which the DT was copied , so it can be easily updated in the future.
Aw: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board
Hi, just a friedly reminder. would be great if it can be merged in next uboot-version. regards Frank > Gesendet: Sonntag, 20. August 2023 um 18:00 Uhr > Von: "Frank Wunderlich" > An: u-boot@lists.denx.de > Cc: "Frank Wunderlich" , "Simon Glass" > , "Philipp Tomsich" , "Kever > Yang" , "Marek Vasut" , "Jonas > Karlman" > Betreff: [PATCH v3] board: rockchip: Add Bananapi R2Pro Board > > From: Frank Wunderlich > > Add Bananapi R2 Pro board. > > Till now evb dts could be used, but iodomain is different > (evb has 1v8 on vccio2 and vccio4 which are 3v3 on r2pro) > and with iodomain driver this can cause hardware fault. > > Devicetree in mainline-Linux: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dts > > Signed-off-by: Frank Wunderlich > --- > v3: > - disable gmac0 as switch-driver is not yet ready to attach to the mac > v2: > - drop switch-node for now as u-boot driver works differently to linux > --- > arch/arm/dts/Makefile | 3 +- > arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi | 23 + > arch/arm/dts/rk3568-bpi-r2pro.dts | 549 ++ > configs/bpi-r2pro-rk3568_defconfig| 101 > 4 files changed, 675 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3568-bpi-r2pro.dts > create mode 100644 configs/bpi-r2pro-rk3568_defconfig
Re: [PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot
On Sat, Sep 16, 2023 at 03:14:58PM +0200, Ryan Lahfa wrote:
> Currently, it seems like the `initrd_filesize` was uninitialized for a
> while.
>
> This is particularly problematic when attempting to `zboot` with a
> initrd with a size coming from `label->initrd`, because it will provide
> you with a 0-long initrd at boot time, making the kernel fail to
> continue the boot.
>
> This fixes the issue and I confirmed it enable me booting a U-Boot on
> QEMU x86_64 q35 with NixOS kernel and initrds.
The original message was lost because I do not use `git send-email` that
often but, this issue appears to be introduced in
085cbdafca9c3d7bc2f27523a343f61db82f2ccb ("pxe: simplify label_boot()").
Kind regards,
--
Ryan Lahfa
[PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot
Currently, it seems like the `initrd_filesize` was uninitialized for a
while.
This is particularly problematic when attempting to `zboot` with a
initrd with a size coming from `label->initrd`, because it will provide
you with a 0-long initrd at boot time, making the kernel fail to
continue the boot.
This fixes the issue and I confirmed it enable me booting a U-Boot on
QEMU x86_64 q35 with NixOS kernel and initrds.
Signed-off-by: Ryan Lahfa
Cc: Tom Rini
Cc: Simon Glass
Cc: Bin Meng
Cc: Zhaofeng Li
Cc: Heinrich Schuchardt
Cc: Ramon Fried
Cc: Artem Lapkin
---
boot/pxe_utils.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index d13c47dd94..fa5e88ab95 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -556,6 +556,8 @@ static int label_boot(struct pxe_context *ctx, struct
pxe_label *label)
}
initrd_addr_str = env_get("ramdisk_addr_r");
+ /* Copy the actual initrd size inside the initrd_filesize */
+ snprintf(initrd_filesize, sizeof(initrd_filesize), "%lx", size);
size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
initrd_addr_str, size);
if (size >= sizeof(initrd_str))
--
2.42.0
zboot: [PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot
The reason for this is that initrd_filesize is constantly equal to zero
or more specifically, potentially uninitialized memory.
I believe this was introduced in
085cbdafca9c3d7bc2f27523a343f61db82f2ccb ("pxe: simplify label_boot()"),
diff here:
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index b08aee9896..defbe465e4 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -532,11 +532,10 @@ static int label_boot(struct pxe_context *ctx, struct
pxe_label *label)
}
initrd_addr_str = env_get("ramdisk_addr_r");
- strcpy(initrd_filesize, simple_xtoa(size));
-
- strncpy(initrd_str, initrd_addr_str, 18);
- strcat(initrd_str, ":");
- strncat(initrd_str, initrd_filesize, 9);
+ size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
+ initrd_addr_str, size);
+ if (size >= sizeof(initrd_str))
+ return 1;
}
if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",
The initrd_filesize completely disappears.
We re-copy the size information inside initrd_filesize, maybe, too
naively, something may have to be done to reduce the overflow potential
if it exist at all.
pxe_utils.c |2 ++
1 file changed, 2 insertions(+)
Re: [PATCH] MAINTAINERS: ufs: Change Bhupesh's email address
On 9/16/23 2:36 AM, Marek Vasut wrote: On 9/15/23 20:14, Bhupesh Sharma wrote: > Set my current personal email in the MAINTAINERS file. Why this change so soon ? Did linaro raise any concerns about the maintainership ? No, I am going to pursue things out of Linaro now, but still related to Qcom upstream. Thanks
Re: [PATCH] USB: gadget: atmel: fix transfer of queued requests
On 9/13/23 17:00, Artur Rojek wrote: In the existing implementation, multiple requests queued up on an endpoint are subject to getting evicted without transmission. For both control and bulk endpoints, their respective logic found in usba_control_irq()/usba_ep_irq() guarantees that TX FIFO is empty before data is sent out, and that request_complete() gets called once the transaction has been finished. At this point however, if any additional requests are found on the endpoint queue, they will be processed by submit_next_request(), which makes no checks against the above conditions, trashing data on a busy FIFO and neglecting completion handlers. Fix the above issues by removing the calls to submit_next_request(), and thus forcing the pending requests to be processed on the next pass of the respective endpoint logic. While at it, remove a DBG message, as that branch becomes part of regular flow. This restores mass storage mode operation on Microchip ATSAMA5D27 SoC. Updated subject prefix to lowercase usb: and applied to usb/next, thanks.
[PULL] u-boot-usb/next
The following changes since commit 2fe4b54556ea6271237b35de68dc458bfceab94c: Merge branch '2023-09-14-remove-NEEDS_MANUAL_RELOC' into next (2023-09-14 16:23:49 -0400) are available in the Git repository at: git://source.denx.de/u-boot-usb.git next for you to fetch changes up to 2caf974b5fac69a1b778e64503f2c107a8d7c3a3: board: usb: Replace legacy usb_gadget_handle_interrupts() (2023-09-15 23:38:02 +0200) Marek Vasut (17): dm: usb: udc: Factor out plain udevice handler functions usb: sandbox: Add DM_USB_GADGET support configs: sandbox: Enable DM_USB_GADGET cmd: fastboot: Use plain udevice for UDC controller interaction cmd: rockusb: Use plain udevice for UDC controller interaction cmd: sdp: Reorder variable declaration cmd: thordown: Reorder variable declaration cmd: ums: Use plain udevice for UDC controller interaction dfu: Detach the controller on error dfu: Use plain udevice for UDC controller interaction spl: sdp: Detach the controller on error sdp: Use plain udevice for UDC controller interaction thordown: Use plain udevice for UDC controller interaction usb: gadget: acm: Use plain udevice for UDC controller interaction usb: gadget: ether: Use plain udevice for UDC controller interaction dm: usb: udc: Drop legacy udevice handler functions board: usb: Replace legacy usb_gadget_handle_interrupts() arch/arm/mach-rockchip/board.c | 4 +- board/purism/librem5/spl.c | 4 +- board/samsung/common/exynos5-dt.c | 4 +- board/st/stih410-b2260/board.c | 4 +- board/ti/am43xx/board.c | 6 +-- cmd/fastboot.c | 7 ++-- cmd/rockusb.c | 7 ++-- cmd/thordown.c | 24 ++-- cmd/usb_gadget_sdp.c| 15 +--- cmd/usb_mass_storage.c | 10 +++-- common/dfu.c| 19 ++ common/spl/spl_sdp.c| 20 ++ configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_noinst_defconfig| 1 + configs/sandbox_spl_defconfig | 1 + configs/sandbox_vpl_defconfig | 1 + drivers/usb/dwc3/core.c | 6 +-- drivers/usb/dwc3/dwc3-omap.c| 8 ++-- drivers/usb/gadget/at91_udc.c | 2 +- drivers/usb/gadget/atmel_usba_udc.c | 3 +- drivers/usb/gadget/ci_udc.c | 4 +- drivers/usb/gadget/dwc2_udc_otg.c | 12 +- drivers/usb/gadget/ether.c | 20 +- drivers/usb/gadget/f_acm.c | 13 --- drivers/usb/gadget/f_mass_storage.c | 8 ++-- drivers/usb/gadget/f_sdp.c | 10 ++--- drivers/usb/gadget/f_thor.c | 74 +++-- drivers/usb/gadget/udc/Makefile | 2 +- drivers/usb/gadget/udc/udc-uclass.c | 57 ++-- drivers/usb/host/usb-sandbox.c | 6 ++- drivers/usb/musb-new/musb_uboot.c | 2 +- include/dwc3-omap-uboot.h | 2 +- include/dwc3-uboot.h| 2 +- include/linux/usb/gadget.h | 32 include/sdp.h | 6 +-- include/thor.h | 4 +- include/usb_mass_storage.h | 2 +- 39 files changed, 214 insertions(+), 191 deletions(-)
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Hi Jonas,
Il giorno mer 6 set 2023 alle ore 09:11 Jonas Karlman
ha scritto:
>
> Hi Massimo,
>
> On 2023-09-06 07:15, Massimo Pegorer wrote:
> > Hi Jonas,
> >
> > Il giorno lun 4 set 2023 alle ore 18:52 Jonas Karlman
> > ha scritto:
> >>
> >> Hi Massimo,
> >>
> >> On 2023-09-04 17:05, Massimo Pegorer wrote:
> >>> Hi,
> >>>
> >>> Is there any way for binman to package FIT with U-Boot TF-A and
> >>> OP-TEE, using bl32 binary provided by Rockchip as TEE?
> >>>
> >>> I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but
> >>> binman failed.
> >>>
> >>> In my poor understanding of Python code, it seems binman accepts only
> >>> ELF format or a binary format starting with optee_v1_header, but
> >>> binaries provided by Rockchip in rkbin repository do not have this
> >>> header.
> >>
> >> One way that I have used/tested before was to create a tee.elf version
> >> using something like:
> >>
> >> $ aarch64-linux-gnu-objcopy -B aarch64 -I binary -O elf64-littleaarch64
> >> xxx_bl32_vX.YZ.bin bl32.o
> >> $ aarch64-linux-gnu-ld bl32.o -T tee.ld -o tee.elf
> >>
> >> tee.ld:
> >>
> >> ENTRY(_binary_bl32_bin_start);
> >>
> >> SECTIONS
> >> {
> >> . = 0x0840;
> >> .data : {
> >> *(.data)
> >> }
> >> }
> >>
> >
> > Thank you so much! I've been able to load and execute
> > rk3308_bl32_v2.05.bin using 0x0020 as load address instead of
> > 0x0840 in the tee.ld. This is the value I found in
> > rkbin/RKTRUST/RK3308TRUST.ini.
> >
> > Everything then goes smooth till kernel panic, but this can depends on
> > kernel build options I suspect (it is just a "random" kernel image I
> > had). I need to investigate more.
> >
> > DDR V2.07 6ede97a868 wesley.yao 22/11/29-19:27:02
> > 08
> > REG2C: 0x0034, 0x0034
> > In
> > 589MHz
> > DDR3
> > Col=10 Bank=3 Row=15 Size=512MB
> > OUT: sdram_init finish.
> >
> > U-Boot SPL 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
> > Trying to boot from MMC1
> > INFO:Preloader serial: 0
> > NOTICE: BL31: v1.3(release):0252d5c8f
> > NOTICE: BL31: Built : 07:51:11, Sep 28 2022
> > INFO:Lastlog: last=0x10, realtime=0x102000, size=0x2000
> > INFO:ARM GICv2 driver initialized
> > INFO:Using opteed sec cpu_context!
> > INFO:boot cpu mask: 1
> > INFO:plat_rockchip_pmu_init: pd status 0xe b
> > INFO:BL31: Initializing runtime services
> > INFO:BL31: Initializing BL32
> > I/TC:
> > I/TC: OP-TEE version: 3.13.0-651-gd84087907 #hisping.lin (gcc version
> > 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
> > 10.2-2020.11 (arm-10.16))) #8 Fri Sep 16 16:15:04 CST 2022 aarch64
> > I/TC: Primary CPU initializing
> > I/TC: Primary CPU switching to normal world boot
> > INFO:BL31: Preparing for EL3 exit to normal world
> > INFO:Entry point address = 0x60
> > INFO:SPSR = 0x3c9
> >
> >
> > U-Boot 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
> >
> > Model: Radxa ROCK Pi S
> > DRAM: 512 MiB (effective 510 MiB)
> > Core: 284 devices, 21 uclasses, devicetree: separate
> > MMC: mmc@ff48: 1, mmc@ff49: 0, mmc@ff4a: 2
> > Loading Environment from nowhere... OK
> > rockchip_dnl_key_pressed read board id failed
> > Net:
> > Error: ethernet@ff4e address not set.
> > No ethernet found.
> >
> > Hit any key to stop autoboot: 0
> > ** Booting bootflow 'mmc@ff48.bootdev.part_1' with script
> > 4414108 bytes read in 189 ms (22.3 MiB/s)
> > ## Loading kernel from FIT Image at 0068 ...
> >Using 'config-1' configuration
> >Trying 'kernel-1' kernel subimage
> > Description: ARM64 OpenWrt Linux-6.1.46
> > Type: Kernel Image
> > Compression: lzma compressed
> > Data Start: 0x006800e8
> > Data Size:4379870 Bytes = 4.2 MiB
> > Architecture: AArch64
> > OS: Linux
> > Load Address: 0x0320
> > Entry Point: 0x0320
> > Hash algo:crc32
> > Hash value: a99f6703
> > Hash algo:sha1
> > Hash value: 642b4e5d4bdab91260c07510ff9d1b13ada03add
> >Verifying Hash Integrity ... crc32+ sha1+ OK
> > ## Loading fdt from FIT Image at 0068 ...
> >Using 'config-1' configuration
> >Trying 'fdt-1' fdt subimage
> > Description: ARM64 OpenWrt radxa_rock-pi-s device tree blob
> > Type: Flat Device Tree
> > Compression: uncompressed
> > Data Start: 0x00aad708
> > Data Size:32335 Bytes = 31.6 KiB
> > Architecture: AArch64
> > Hash algo:crc32
> > Hash value: 3d67cbee
> > Hash algo:sha1
> > Hash value: 82c778864784d98ae4150916adac497000e34c6a
> >Verifying Hash Integrity ... crc32+ sha1+ OK
> >Booting using the fdt blob at 0xaad708
> > Working FDT set to aad708
> >Uncompressing Kernel Image
> >Loading Device Tree to 1df25000, end 1df2fe4e ... OK
> > Working FDT set to 1df25000
> >
> > Starting kernel ...
> >
> > [0.00] B
[PATCH 4/4] spl: atf: Reduce SPL code size
Previous fix commit increases code size of a few bytes. This minor
rework finally reduces SPL size of about 64-72 bytes (tested with
buildman on several aarch64 boards).
Signed-off-by: Massimo Pegorer
---
common/spl/spl_atf.c | 42 +++---
1 file changed, 19 insertions(+), 23 deletions(-)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 0d8db2d14e..fa79f73be2 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -209,7 +209,19 @@ static void spl_enter_atf(uintptr_t bl31_entry, uintptr_t
bl32_entry,
atf_entry(bl31_params, (void *)fdt_addr);
}
-static int spl_fit_images_find(void *blob, int os)
+static void spl_fit_images_get_entry(void *blob, int node, uintptr_t *entry_p)
+{
+ ulong val;
+
+ if (fit_image_get_entry(blob, node, &val))
+ if (fit_image_get_load(blob, node, &val))
+ return;
+
+ debug("%s: entry point 0x%lx\n", __func__, val);
+ *entry_p = val;
+}
+
+static int spl_fit_images_get_os_entry(void *blob, int os, uintptr_t *entry_p)
{
int parent, node, ndepth = 0;
const void *data;
@@ -231,41 +243,28 @@ static int spl_fit_images_find(void *blob, int os)
if (!data)
continue;
- if (genimg_get_os_id(data) == os)
- return node;
+ if (genimg_get_os_id(data) == os) {
+ spl_fit_images_get_entry(blob, node, entry_p);
+ return 0;
+ }
};
return -FDT_ERR_NOTFOUND;
}
-void spl_fit_images_get_entry(void *blob, int node, uintptr_t *entry_p)
-{
- ulong val;
-
- if (fit_image_get_entry(blob, node, &val))
- if (fit_image_get_load(blob, node, &val))
- return;
-
- debug("%s: entry point 0x%lx\n", __func__, val);
- *entry_p = val;
-}
-
void spl_invoke_atf(struct spl_image_info *spl_image)
{
uintptr_t bl32_entry = 0;
uintptr_t bl33_entry = CONFIG_TEXT_BASE;
void *blob = spl_image->fdt_addr;
uintptr_t platform_param = (uintptr_t)blob;
- int node;
/*
* Find (in /fit-images) the TEE binary entry point address
* (or load address if entry point is missing) and pass it as
* the BL3-2 entry point. This is optional.
*/
- node = spl_fit_images_find(blob, IH_OS_TEE);
- if (node >= 0)
- spl_fit_images_get_entry(blob, node, &bl32_entry);
+ spl_fit_images_get_os_entry(blob, IH_OS_TEE, &bl32_entry);
/*
* Find (in /fit-images) the U-Boot binary entry point address
@@ -273,10 +272,7 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
* the BL3-3 entry point.
* This will need to be extended to support Falcon mode.
*/
-
- node = spl_fit_images_find(blob, IH_OS_U_BOOT);
- if (node >= 0)
- spl_fit_images_get_entry(blob, node, &bl33_entry);
+ spl_fit_images_get_os_entry(blob, IH_OS_U_BOOT, &bl33_entry);
/*
* If ATF_NO_PLATFORM_PARAM is set, we override the platform
--
2.34.1
[PATCH 3/4] spl: atf: Fix potential but not occurring bug
Bug: function spl_fit_images_get_entry returns uninitialized variable
val if both fit_image_get_entry() and fit_image_get_load() fail (note
that both of them do not set val on failure). Fix: use val only if
entry or load address has been retrieved successfully.
Note: in real world a failure of fit_image_get_load() will make current
SPL flow to break on loading images, see spl_load_fit_image(), before
entering spl_invoke_atf().
Signed-off-by: Massimo Pegorer
---
common/spl/spl_atf.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 3d022ed4e7..0d8db2d14e 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -238,17 +238,16 @@ static int spl_fit_images_find(void *blob, int os)
return -FDT_ERR_NOTFOUND;
}
-uintptr_t spl_fit_images_get_entry(void *blob, int node)
+void spl_fit_images_get_entry(void *blob, int node, uintptr_t *entry_p)
{
ulong val;
- int ret;
- ret = fit_image_get_entry(blob, node, &val);
- if (ret)
- ret = fit_image_get_load(blob, node, &val);
+ if (fit_image_get_entry(blob, node, &val))
+ if (fit_image_get_load(blob, node, &val))
+ return;
debug("%s: entry point 0x%lx\n", __func__, val);
- return val;
+ *entry_p = val;
}
void spl_invoke_atf(struct spl_image_info *spl_image)
@@ -266,7 +265,7 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
*/
node = spl_fit_images_find(blob, IH_OS_TEE);
if (node >= 0)
- bl32_entry = spl_fit_images_get_entry(blob, node);
+ spl_fit_images_get_entry(blob, node, &bl32_entry);
/*
* Find (in /fit-images) the U-Boot binary entry point address
@@ -277,7 +276,7 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
node = spl_fit_images_find(blob, IH_OS_U_BOOT);
if (node >= 0)
- bl33_entry = spl_fit_images_get_entry(blob, node);
+ spl_fit_images_get_entry(blob, node, &bl33_entry);
/*
* If ATF_NO_PLATFORM_PARAM is set, we override the platform
--
2.34.1
[PATCH 2/4] image: fit: Improve functions description comments
Load and entry addresses are returned in ulong variables, which are 32 or 64 bit depending on architecture. Specify that on failure these functions do not set memory pointed by load / entry argument: this detail is relavant for correct functions usage. Signed-off-by: Massimo Pegorer --- boot/image-fit.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/boot/image-fit.c b/boot/image-fit.c index 3cc556b727..7e87a513e7 100644 --- a/boot/image-fit.c +++ b/boot/image-fit.c @@ -869,10 +869,11 @@ static int fit_image_get_address(const void *fit, int noffset, char *name, * fit_image_get_load() - get load addr property for given component image node * @fit: pointer to the FIT format image header * @noffset: component image node offset - * @load: pointer to the uint32_t, will hold load address + * @load: pointer to ulong, will hold load address * * fit_image_get_load() finds load address property in a given component * image node. If the property is found, its value is returned to the caller. + * Otherwise, on failure, *load will be left untouched. * * returns: * 0, on success @@ -887,14 +888,11 @@ int fit_image_get_load(const void *fit, int noffset, ulong *load) * fit_image_get_entry() - get entry point address property * @fit: pointer to the FIT format image header * @noffset: component image node offset - * @entry: pointer to the uint32_t, will hold entry point address - * - * This gets the entry point address property for a given component image - * node. + * @entry: pointer to ulong, will hold entry point address * * fit_image_get_entry() finds entry point address property in a given - * component image node. If the property is found, its value is returned - * to the caller. + * component image node. If the property is found, its value is returned + * to the caller. Otherwise, on failure, *entry will be left untouched. * * returns: * 0, on success -- 2.34.1
[PATCH 1/4] spl: atf: Improve comments and code readability
Rename bl31_entry static function to avoid name clash with its first
argument. Fix spaces misuse. Describe code accurately: load address
is used if getting entry point address fails, and not if addresses
differ. Remove not up-to-date comment about BL3-2 usage.
Signed-off-by: Massimo Pegorer
---
common/spl/spl_atf.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/common/spl/spl_atf.c b/common/spl/spl_atf.c
index 2c10252834..3d022ed4e7 100644
--- a/common/spl/spl_atf.c
+++ b/common/spl/spl_atf.c
@@ -189,10 +189,10 @@ static inline void raw_write_daif(unsigned int daif)
typedef void (*atf_entry_t)(struct bl31_params *params, void *plat_params);
-static void bl31_entry(uintptr_t bl31_entry, uintptr_t bl32_entry,
- uintptr_t bl33_entry, uintptr_t fdt_addr)
+static void spl_enter_atf(uintptr_t bl31_entry, uintptr_t bl32_entry,
+ uintptr_t bl33_entry, uintptr_t fdt_addr)
{
- atf_entry_t atf_entry = (atf_entry_t)bl31_entry;
+ atf_entry_t atf_entry = (atf_entry_t)bl31_entry;
void *bl31_params;
if (CONFIG_IS_ENABLED(ATF_LOAD_IMAGE_V2))
@@ -240,7 +240,7 @@ static int spl_fit_images_find(void *blob, int os)
uintptr_t spl_fit_images_get_entry(void *blob, int node)
{
- ulong val;
+ ulong val;
int ret;
ret = fit_image_get_entry(blob, node, &val);
@@ -253,25 +253,25 @@ uintptr_t spl_fit_images_get_entry(void *blob, int node)
void spl_invoke_atf(struct spl_image_info *spl_image)
{
- uintptr_t bl32_entry = 0;
- uintptr_t bl33_entry = CONFIG_TEXT_BASE;
+ uintptr_t bl32_entry = 0;
+ uintptr_t bl33_entry = CONFIG_TEXT_BASE;
void *blob = spl_image->fdt_addr;
uintptr_t platform_param = (uintptr_t)blob;
int node;
/*
-* Find the OP-TEE binary (in /fit-images) load address or
-* entry point (if different) and pass it as the BL3-2 entry
-* point, this is optional.
+* Find (in /fit-images) the TEE binary entry point address
+* (or load address if entry point is missing) and pass it as
+* the BL3-2 entry point. This is optional.
*/
node = spl_fit_images_find(blob, IH_OS_TEE);
if (node >= 0)
bl32_entry = spl_fit_images_get_entry(blob, node);
/*
-* Find the U-Boot binary (in /fit-images) load addreess or
-* entry point (if different) and pass it as the BL3-3 entry
-* point.
+* Find (in /fit-images) the U-Boot binary entry point address
+* (or load address if entry point is missing) and pass it as
+* the BL3-3 entry point.
* This will need to be extended to support Falcon mode.
*/
@@ -281,17 +281,13 @@ void spl_invoke_atf(struct spl_image_info *spl_image)
/*
* If ATF_NO_PLATFORM_PARAM is set, we override the platform
-* parameter and always pass 0. This is a workaround for
+* parameter and always pass 0. This is a workaround for
* older ATF versions that have insufficiently robust (or
* overzealous) argument validation.
*/
if (CONFIG_IS_ENABLED(ATF_NO_PLATFORM_PARAM))
platform_param = 0;
- /*
-* We don't provide a BL3-2 entry yet, but this will be possible
-* using similar logic.
-*/
- bl31_entry(spl_image->entry_point, bl32_entry,
- bl33_entry, platform_param);
+ spl_enter_atf(spl_image->entry_point, bl32_entry,
+ bl33_entry, platform_param);
}
--
2.34.1
[PATCH 0/4] spl: atf: Fix potential bug on getting FIT data
If both fit_image_get_entry() and fit_image_get_load() calls fail, an uninitialized variable value is passed to TF-A as BL3-2 and/or BL3-3 entry point in spl_invoke_atf(). In real world of current SPL flow this is not expected to occur because a fit_image_get_load() failure should break boot during images loading phase, and thus before entering spl_invoke_atf(). Update improve and fix comments. A minor rework slightly reduces SPL code size up to 72 bytes. Note: I am not enough confident about uintptr_t and ulong sizes matching within all architectures, otherwise straightforward pass of bl3x_entry reference to fit_image_get_xxx would be fine. Massimo Pegorer (4): spl: atf: Improve comments and code readability image: fit: Improve functions description comments spl: atf: Fix potential but not occurring bug spl: atf: Reduce SPL code size boot/image-fit.c | 12 +++ common/spl/spl_atf.c | 75 +++- 2 files changed, 38 insertions(+), 49 deletions(-) -- 2.34.1
