Re: [PATCH RFC 0/4] efi: CapsuleUpdate: support for dynamic GUIDs
Hi Caleb On Fri, 26 Apr 2024 at 17:19, Caleb Connolly wrote: > > As more boards adopt support for the EFI CapsuleUpdate mechanism, there > is a growing issue of being able to target updates to them properly. The > current mechanism of hardcoding UUIDs for each board at compile time is > unsustainable, and maintaining lists of GUIDs is similarly cumbersome. > > In this series, I propose that we adopt v5 GUIDs, these are generated > by using a well-known salt GUID as well as board specific information > (like the model/revision), these are hashed together and the result is > truncated to form a new UUID. > > The well-known salt GUID can be specific to the architecture (SoC > vendor), or OEM. Exact rules on how these are used (e.g. if vendors > should be told to generate their own for their products, and if that > can be added upstream, etc) will need to be decided. > > Specifically, the following fields are used to generate a GUID for a > particular fw_image: > > * namespace salt > * soc name > * board model (usually from dt root model property) > * board compatible (usually the first entry in the dt root compatible > array). > * fw_image name (the string identifying the specific image, especially > relevant for board that can update multiple images). > > Once generated, the GUIDs can be printed with the "%pUs" format string, > these can then be stored externally to U-Boot. > > The SoC name field might be controversial, it could be generated from > the last entry in the dt root compatible in most cases, or in some board > specific way. It might make sense to remove this field if it is > unfeasible for some boards. > > == Usage == > > Boards can integrate dynamic UUID support as follows: > > 1. Adjust Kconfig to depend on EFI_CAPSULE_DYNAMIC_UUIDS if >EFI_HAVE_CAPSULE_SUPPORT > 2. Skip setting the fw_images image_type_id property. > 3. In board_init() (or anywhere before the EFI subsystem is >initialised), add a call to efi_capsule_update_info_gen_ids() with >the board specific info. > > == Limitations == > > * Changing GUIDs > > The primary limitation with this approach is that if any of the source > fields change, so will the GUID for the board. It is therefore pretty > important to ensure that GUID changes are caught during development. > > * Supporting multiple boards with a single image > > This now requires having an entry with the GUID for every board which > might lead to larger UpdateCapsule images. > > == Tooling == > > Not part of this RFC is a tool to generate the GUIDs outside of U-Boot. > I suspect this might be a requirement, but it makes sense to decide on > what fields we use first. Yes, tooling would be good. > > The tool should take in the salt, DTB, and a list of fw_image names. It > could also accept values to overwrite the individual fields if they > aren't derived from the DTB for some reason. It would then generate the > expected GUID. > > A potential idea here would be to integrate this into the build system > so that it prints a warning if the GUID changes. > There's work being done in that direction as far as capsules are concerned. Apart from the u-boot binary from your board, the build system should also generate binaries Thanks /Ilias > == TOOD == > > Missing from this RFC are unit tests for the dynamic UUID feature, these > will be implemented for future revisions. > > I would appreciate any feedback on the above. > > This follows a related discussion started by Ilias: > https://lore.kernel.org/u-boot/cac_iwjjnha4gmf897mqyzndbgjfg8k4kwgstxwuy72wkyli...@mail.gmail.com/ > > --- > Caleb Connolly (4): > lib: uuid: add UUID v5 support > efi: add a helper to generate dynamic UUIDs > doc: uefi: document dynamic GUID generation > sandbox: switch to dynamic UUIDs > > arch/Kconfig | 1 + > board/sandbox/sandbox.c | 28 +++- > doc/develop/uefi/uefi.rst| 35 +++ > include/efi_loader.h | 28 > include/uuid.h | 16 > lib/Kconfig | 8 > lib/efi_loader/Kconfig | 14 ++ > lib/efi_loader/efi_capsule.c | 33 + > lib/uuid.c | 33 + > 9 files changed, 183 insertions(+), 13 deletions(-) > --- > change-id: 20240422-b4-dynamic-uuid-1a5ab1486c27 > base-commit: d097f9e1299a3bdb7de468f0d9bbc63932f461cd > > // Caleb (they/them) >
Re: [PATCH] arm: exynos: Migrate E850-96 board to OF_UPSTREAM
+ Krzysztof, Fyi..
On Fri, 24 May 2024 at 03:33, Sam Protsenko wrote:
>
> Use upstream device tree files and bindings. To do so:
> - imply (enable) OF_UPSTREAM option for E850-96 target
> - point DEFAULT_DEVICE_TREE in E850-96 config to upstream dts
> - remove now not needed local dts files, binding docs and headers
> - update MAINTAINERS correspondingly
>
> Upstream device tree files for Exynos850 SoC and E850-96 board are
> pretty much the same as local (removed) ones, so the conversion is
> rather straightforward and painless in this case. The appended dts file
> (arch/arm/dts/exynos850-e850-96-u-boot.dtsi) stays unchanged.
>
> The only remaining local dt-bindings doc for E850-96 board is
> exynos-pmu.yaml. It wasn't removed as it's quite different from Linux
> kernel version. Particularly U-Boot local version of exynos-pmu.yaml
> describes "samsung,uart-debug-1" property, which is not present in Linux
> kernel binding. Later it might be upstreamed to Linux kernel, and once
> it's done the U-Boot exynos-pmu.yaml binding can be removed.
>
> No functional change.
>
> Signed-off-by: Sam Protsenko
> ---
> MAINTAINERS | 7 +-
> arch/arm/dts/Makefile | 1 -
> arch/arm/dts/exynos850-e850-96.dts| 273 --
> arch/arm/dts/exynos850-pinctrl.dtsi | 663 --
> arch/arm/dts/exynos850.dtsi | 809 --
> arch/arm/mach-exynos/Kconfig | 1 +
> configs/e850-96_defconfig | 2 +-
> .../clock/samsung,exynos850-clock.yaml| 307 ---
> .../soc/samsung/exynos-usi.yaml | 162
> include/dt-bindings/clock/exynos850.h | 337
> include/dt-bindings/soc/samsung,exynos-usi.h | 17 -
> 11 files changed, 3 insertions(+), 2576 deletions(-)
> delete mode 100644 arch/arm/dts/exynos850-e850-96.dts
> delete mode 100644 arch/arm/dts/exynos850-pinctrl.dtsi
> delete mode 100644 arch/arm/dts/exynos850.dtsi
> delete mode 100644
> doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml
> delete mode 100644 doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
> delete mode 100644 include/dt-bindings/clock/exynos850.h
> delete mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h
>
Acked-by: Sumit Garg
-Sumit
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 638b2fdd442f..f8afd7d51e2e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -578,19 +578,14 @@ F:drivers/clk/exynos/clk.h
> ARM SAMSUNG EXYNOS850 SOC
> M: Sam Protsenko
> S: Maintained
> -F: arch/arm/dts/exynos850-pinctrl.dtsi
> -F: arch/arm/dts/exynos850.dtsi
> -F: doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml
> F: drivers/clk/exynos/clk-exynos850.c
> F: drivers/pinctrl/exynos/pinctrl-exynos850.c
> -F: include/dt-bindings/clock/exynos850.h
>
> ARM SAMSUNG SOC DRIVERS
> M: Sam Protsenko
> S: Maintained
> -F: doc/device-tree-bindings/soc/samsung/*
> +F: doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
> F: drivers/soc/samsung/*
> -F: include/dt-bindings/soc/samsung,*.h
>
> ARM SANCLOUD
> M: Paul Barker
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a5c82ebf7a5f..4b72d9f64863 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -31,7 +31,6 @@ dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
> dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb
> dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb
> dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
> -dtb-$(CONFIG_TARGET_E850_96) += exynos850-e850-96.dtb
>
> dtb-$(CONFIG_ARCH_APPLE) += \
> t8103-j274.dtb \
> diff --git a/arch/arm/dts/exynos850-e850-96.dts
> b/arch/arm/dts/exynos850-e850-96.dts
> deleted file mode 100644
> index f074df8982b3..
> --- a/arch/arm/dts/exynos850-e850-96.dts
> +++ /dev/null
> @@ -1,273 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * WinLink E850-96 board device tree source
> - *
> - * Copyright (C) 2018 Samsung Electronics Co., Ltd.
> - * Copyright (C) 2021 Linaro Ltd.
> - *
> - * Device tree source file for WinLink's E850-96 board which is based on
> - * Samsung Exynos850 SoC.
> - */
> -
> -/dts-v1/;
> -
> -#include "exynos850.dtsi"
> -#include
> -#include
> -#include
> -
> -/ {
> - model = "WinLink E850-96 board";
> - compatible = "winlink,e850-96", "samsung,exynos850";
> -
> - aliases {
> - mmc0 = _0;
> - serial0 = _0;
> - };
> -
> - chosen {
> - stdout-path = _0;
> - };
> -
> - connector {
> - compatible = "gpio-usb-b-connector", "usb-b-connector";
> - label = "micro-USB";
> - type = "micro";
> - vbus-supply = <_usb_host_vbus>;
> - id-gpios = < 0 GPIO_ACTIVE_LOW>;
> - pinctrl-names = "default";
> -
Re: [PATCH v2 2/5] dt-bindings: clock: qcom: ipq4019: drop downstream file
On Thu, 23 May 2024 at 23:08, Robert Marko wrote: > > IPQ4019 clock dt-bindings are available in Linux upstream, and we can just > use those instead of carrying a downstream file that matches the upstream one > anyway. > > Signed-off-by: Robert Marko > --- > Changes in v2: > * Drop the downstream dt-bindings header as it matches the upstream Linux one > > include/dt-bindings/clock/qcom,gcc-ipq4019.h | 169 --- > 1 file changed, 169 deletions(-) > delete mode 100644 include/dt-bindings/clock/qcom,gcc-ipq4019.h > Reviewed-by: Sumit Garg -Sumit > diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h > b/include/dt-bindings/clock/qcom,gcc-ipq4019.h > deleted file mode 100644 > index 7e8a7be6dc..00 > --- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h > +++ /dev/null > @@ -1,169 +0,0 @@ > -/* Copyright (c) 2015 The Linux Foundation. All rights reserved. > - * > - * Permission to use, copy, modify, and/or distribute this software for any > - * purpose with or without fee is hereby granted, provided that the above > - * copyright notice and this permission notice appear in all copies. > - * > - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > - * > - */ > -#ifndef __QCOM_CLK_IPQ4019_H__ > -#define __QCOM_CLK_IPQ4019_H__ > - > -#define GCC_DUMMY_CLK 0 > -#define AUDIO_CLK_SRC 1 > -#define BLSP1_QUP1_I2C_APPS_CLK_SRC2 > -#define BLSP1_QUP1_SPI_APPS_CLK_SRC3 > -#define BLSP1_QUP2_I2C_APPS_CLK_SRC4 > -#define BLSP1_QUP2_SPI_APPS_CLK_SRC5 > -#define BLSP1_UART1_APPS_CLK_SRC 6 > -#define BLSP1_UART2_APPS_CLK_SRC 7 > -#define GCC_USB3_MOCK_UTMI_CLK_SRC 8 > -#define GCC_APPS_CLK_SRC 9 > -#define GCC_APPS_AHB_CLK_SRC 10 > -#define GP1_CLK_SRC11 > -#define GP2_CLK_SRC12 > -#define GP3_CLK_SRC13 > -#define SDCC1_APPS_CLK_SRC 14 > -#define FEPHY_125M_DLY_CLK_SRC 15 > -#define WCSS2G_CLK_SRC 16 > -#define WCSS5G_CLK_SRC 17 > -#define GCC_APSS_AHB_CLK 18 > -#define GCC_AUDIO_AHB_CLK 19 > -#define GCC_AUDIO_PWM_CLK 20 > -#define GCC_BLSP1_AHB_CLK 21 > -#define GCC_BLSP1_QUP1_I2C_APPS_CLK22 > -#define GCC_BLSP1_QUP1_SPI_APPS_CLK23 > -#define GCC_BLSP1_QUP2_I2C_APPS_CLK24 > -#define GCC_BLSP1_QUP2_SPI_APPS_CLK25 > -#define GCC_BLSP1_UART1_APPS_CLK 26 > -#define GCC_BLSP1_UART2_APPS_CLK 27 > -#define GCC_DCD_XO_CLK 28 > -#define GCC_GP1_CLK29 > -#define GCC_GP2_CLK30 > -#define GCC_GP3_CLK31 > -#define GCC_BOOT_ROM_AHB_CLK 32 > -#define GCC_CRYPTO_AHB_CLK 33 > -#define GCC_CRYPTO_AXI_CLK 34 > -#define GCC_CRYPTO_CLK 35 > -#define GCC_ESS_CLK36 > -#define GCC_IMEM_AXI_CLK 37 > -#define GCC_IMEM_CFG_AHB_CLK 38 > -#define GCC_PCIE_AHB_CLK 39 > -#define GCC_PCIE_AXI_M_CLK 40 > -#define GCC_PCIE_AXI_S_CLK 41 > -#define GCC_PCNOC_AHB_CLK 42 > -#define GCC_PRNG_AHB_CLK 43 > -#define GCC_QPIC_AHB_CLK 44 > -#define GCC_QPIC_CLK 45 > -#define GCC_SDCC1_AHB_CLK 46 > -#define GCC_SDCC1_APPS_CLK 47 > -#define GCC_SNOC_PCNOC_AHB_CLK 48 > -#define GCC_SYS_NOC_125M_CLK 49 > -#define GCC_SYS_NOC_AXI_CLK50 > -#define GCC_TCSR_AHB_CLK 51 > -#define GCC_TLMM_AHB_CLK 52 > -#define
Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On Thu, May 23, 2024 at 04:01:31PM +, Brunham, Kalen wrote: > I can see that efi_device_path.c and efi_disk.c both #include blk.h. OK, yes. But what I'm asking of Heinrich is, can we easily and cleanly make that support conditional? Or is there some underlying requirement at play here? > > -Original Message- > From: Tom Rini > Sent: Thursday, May 23, 2024 11:33 AM > To: Brunham, Kalen ; Heinrich Schuchardt > > Cc: U-Boot@lists.denx.de > Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 > > On Wed, May 22, 2024 at 05:22:24PM +, Brunham, Kalen wrote: > > > Hi Tom, > > > > BLK is currently a dependency for EFI_LOADER as shown in the snippet from > > lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER > > requires a block device? If I remove this depends on BLK line, then I can > > enable EFI and successfully simulate the EFI hello world on my test design. > > > > > > config EFI_LOADER > > bool "Support running UEFI applications" > > depends on OF_LIBFDT && ( \ > > ARM && (SYS_CPU = arm1136 || \ > > SYS_CPU = arm1176 || \ > > SYS_CPU = armv7 || \ > > SYS_CPU = armv8) || \ > > X86 || RISCV || SANDBOX) > > # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB > > depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT > > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > > depends on BLK > > depends on !EFI_APP > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 > > Do you recall why this is Heinrich? > > -- > Tom -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/7] dts: beagleplay: binman: Include firmware capsules binman nodes
On Thu, May 23, 2024 at 04:09:38PM -0500, Jon Humphreys wrote: > Tom Rini writes: > > > On Wed, May 22, 2024 at 11:12:35PM -0500, Jon Humphreys wrote: > >> Tom Rini writes: > >> > >> > On Tue, May 21, 2024 at 09:20:26PM -0500, Jon Humphreys wrote: > >> >> Tom Rini writes: > >> >> > >> >> > On Fri, Apr 19, 2024 at 04:28:16PM -0500, Jonathan Humphreys wrote: > >> >> > > >> >> >> Fill in the BeaglePlay's capsule GUID properties of the base binman > >> >> >> capsule > >> >> >> nodes. > >> >> >> > >> >> >> Signed-off-by: Jonathan Humphreys > >> >> >> --- > >> >> >> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 27 > >> >> >> > >> >> >> arch/arm/dts/k3-am625-r5-beagleplay.dts | 15 +++ > >> >> >> 2 files changed, 42 insertions(+) > >> >> > > >> >> > This series introduces failure to build in CI, and it's a little > >> >> > tricky > >> >> > to replicate locally, depending on your environment. You first need to > >> >> > NOT have BINMAN_INDIRS set and instead be using fake binaries. Second, > >> >> > it seems python version dependent perhaps? I don't see this on my > >> >> > host, > >> >> > but by: > >> >> > - Using the CI container > >> >> > - Setting up a virtualenv inside of it > >> >> > - pip install -r tools/buildman/requirements.txt > >> >> > I get: > >> >> > $ ./tools/buildman/buildman --keep-outputs --reproducible-builds > >> >> > -dvel --force-build -PEWM --output /tmp/am62x_beagleplay_r5 --board > >> >> > am62x_beagleplay_r5 > >> >> > Building current source for 1 boards (1 thread, 12 jobs per thread) > >> >> >arm: + am62x_beagleplay_r5 > >> >> > +(am62x_beagleplay_r5) Image 'tiboot3-am62x-gp-evm.bin' is missing > >> >> > optional external blobs but is still functional: ti-fs-gp.bin > >> >> > +(am62x_beagleplay_r5) > >> >> > +(am62x_beagleplay_r5) /binman/tiboot3-am62x-gp-evm.bin/ti-fs-gp.bin > >> >> > (ti-sysfw/ti-fs-firmware-am62x-gp.bin): > >> >> > +(am62x_beagleplay_r5)Missing blob > >> >> > +(am62x_beagleplay_r5) binman: object of type 'NoneType' has no len() > >> >> > +(am62x_beagleplay_r5) make[1]: *** [Makefile:1126: .binman_stamp] > >> >> > Error 1 > >> >> > +(am62x_beagleplay_r5) make: *** [Makefile:177: sub-make] Error 2 > >> >> > 001 /1 am62x_beagleplay_r5 > >> >> > >> >> Tom, this is failing in the CI container because the container is > >> >> missing > >> >> the mkeficapsule tool. > >> >> > >> >> To solve this, we just need to add it to the CI container. > >> >> > >> >> My understanding of binman's handling of missing bintools is that it > >> >> should > >> >> gracefully continue with fake data, so that buildman can successfully > >> >> test > >> >> out builds for boards even when you don't have all the required > >> >> bintools. > >> >> If I have that correct, I can also create a patch to properly handle > >> >> this > >> >> when using mkeficapsule. But I want to verify this is the desired > >> >> behavior, > >> >> since mkeficapsule isn't a unique or vendor specific tool, so shouldn't > >> >> we > >> >> require it as part of the U-Boot build environment and err out if it is > >> >> missing? > >> > > >> > Perhaps it's a binman issue since we build mkeficapsule or at least > >> > should be? Neha? > >> > > >> > >> Never mind - I figured it out. > >> > >> The mkeficapsule tools is built by u-boot if TOOLS_MKEFICAPSULE config is > >> set. I didn't explicitly set it because it is implied by > >> EFI_CAPSULE_ON_DISK config. But this is only set for the A core u-boot, as > >> that is what would apply the capsules. SPL running on the R cores does not > >> need this. But that then means that the R core u-boot builds don't have > >> TOOLS_MKEFICAPSULE set and if that is all that is being built (as in the > >> case of buildman), the mkeficapsule tool isn't built and so is missing. > >> > >> So I need to explicitly set TOOLS_MKEFICAPSULE in the R core defconfigs. > >> I'll repost the patches. > > > > Interesting. My next thought here is that whatever symbol is allowing > > for "make a capsule" should be select'ing TOOLS_MKEFICAPSULE and so the > > current logic is a bit flawed. I'm just not sure off-hand where it > > should be instead, do you have some ideas now? Thanks. > > There is no config that indicates that capsules will be generated for the > resulting binary. The only thing I can think of is to scan the board's DTB > for the presence of a capsule binman node, and then set the > TOOLS_MKEFICAPSULE config. But this seems very complicated to do at > build time. Yeah, that's the wrong direction I think. We should perhaps just make TOOLS_MKEFICAPSULE default y if EFI_LOADER instead. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 15/19] board: am62px: Define capsule update firmware info
Hi Jonathan
Thanks for working on this
On Thu, May 09, 2024 at 11:41:19AM -0500, Jonathan Humphreys wrote:
> Define the firmware components updatable via EFI capsule update, including
> defining capsule GUIDs for the various firmware components for the AM62px
> SK.
>
> Signed-off-by: Jonathan Humphreys
> ---
> board/ti/am62px/evm.c| 32
> include/configs/am62px_evm.h | 24
> 2 files changed, 56 insertions(+)
>
> diff --git a/board/ti/am62px/evm.c b/board/ti/am62px/evm.c
> index 97a95ce8cc2..6d0f66e5dc0 100644
> --- a/board/ti/am62px/evm.c
> +++ b/board/ti/am62px/evm.c
> @@ -6,6 +6,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -13,6 +14,37 @@
> #include
> #include
>
> +struct efi_fw_image fw_images[] = {
It's better if we add an
#if IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT)
for both of the structs that follow (and it applies to all your patches)
> + {
> + .image_type_id = AM62PX_SK_TIBOOT3_IMAGE_GUID,
> + .fw_name = u"AM62PX_SK_TIBOOT3",
> + .image_index = 1,
> + },
> + {
> + .image_type_id = AM62PX_SK_SPL_IMAGE_GUID,
> + .fw_name = u"AM62PX_SK_SPL",
> + .image_index = 2,
> + },
> + {
> + .image_type_id = AM62PX_SK_UBOOT_IMAGE_GUID,
> + .fw_name = u"AM62PX_SK_UBOOT",
> + .image_index = 3,
> + }
> +};
> +
> +struct efi_capsule_update_info update_info = {
> + .dfu_string = "sf 0:0=tiboot3.bin raw 0 8;"
> + "tispl.bin raw 8 20;u-boot.img raw 28 40",
> + .num_images = ARRAY_SIZE(fw_images),
> + .images = fw_images,
> +};
I haven't worked on any TI platforms lately so I cant say much about the
naming and the flash regions. The definition seems correct
> +
> +void set_dfu_alt_info(char *interface, char *devstr)
> +{
> + if (IS_ENABLED(CONFIG_EFI_HAVE_CAPSULE_SUPPORT))
> + env_set("dfu_alt_info", update_info.dfu_string);
> +}
There's a CONFIG_SET_DFU_ALT_INFO symbol. This better if we add a check here
as well
> +
> int board_init(void)
> {
> return 0;
> diff --git a/include/configs/am62px_evm.h b/include/configs/am62px_evm.h
> index 06b12860e21..57a1ba9dc3c 100644
> --- a/include/configs/am62px_evm.h
> +++ b/include/configs/am62px_evm.h
> @@ -8,6 +8,30 @@
> #ifndef __CONFIG_AM62PX_EVM_H
> #define __CONFIG_AM62PX_EVM_H
>
[...]
Regards
/Ilias
[PATCH] arm: exynos: Migrate E850-96 board to OF_UPSTREAM
Use upstream device tree files and bindings. To do so:
- imply (enable) OF_UPSTREAM option for E850-96 target
- point DEFAULT_DEVICE_TREE in E850-96 config to upstream dts
- remove now not needed local dts files, binding docs and headers
- update MAINTAINERS correspondingly
Upstream device tree files for Exynos850 SoC and E850-96 board are
pretty much the same as local (removed) ones, so the conversion is
rather straightforward and painless in this case. The appended dts file
(arch/arm/dts/exynos850-e850-96-u-boot.dtsi) stays unchanged.
The only remaining local dt-bindings doc for E850-96 board is
exynos-pmu.yaml. It wasn't removed as it's quite different from Linux
kernel version. Particularly U-Boot local version of exynos-pmu.yaml
describes "samsung,uart-debug-1" property, which is not present in Linux
kernel binding. Later it might be upstreamed to Linux kernel, and once
it's done the U-Boot exynos-pmu.yaml binding can be removed.
No functional change.
Signed-off-by: Sam Protsenko
---
MAINTAINERS | 7 +-
arch/arm/dts/Makefile | 1 -
arch/arm/dts/exynos850-e850-96.dts| 273 --
arch/arm/dts/exynos850-pinctrl.dtsi | 663 --
arch/arm/dts/exynos850.dtsi | 809 --
arch/arm/mach-exynos/Kconfig | 1 +
configs/e850-96_defconfig | 2 +-
.../clock/samsung,exynos850-clock.yaml| 307 ---
.../soc/samsung/exynos-usi.yaml | 162
include/dt-bindings/clock/exynos850.h | 337
include/dt-bindings/soc/samsung,exynos-usi.h | 17 -
11 files changed, 3 insertions(+), 2576 deletions(-)
delete mode 100644 arch/arm/dts/exynos850-e850-96.dts
delete mode 100644 arch/arm/dts/exynos850-pinctrl.dtsi
delete mode 100644 arch/arm/dts/exynos850.dtsi
delete mode 100644 doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml
delete mode 100644 doc/device-tree-bindings/soc/samsung/exynos-usi.yaml
delete mode 100644 include/dt-bindings/clock/exynos850.h
delete mode 100644 include/dt-bindings/soc/samsung,exynos-usi.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 638b2fdd442f..f8afd7d51e2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -578,19 +578,14 @@ F:drivers/clk/exynos/clk.h
ARM SAMSUNG EXYNOS850 SOC
M: Sam Protsenko
S: Maintained
-F: arch/arm/dts/exynos850-pinctrl.dtsi
-F: arch/arm/dts/exynos850.dtsi
-F: doc/device-tree-bindings/clock/samsung,exynos850-clock.yaml
F: drivers/clk/exynos/clk-exynos850.c
F: drivers/pinctrl/exynos/pinctrl-exynos850.c
-F: include/dt-bindings/clock/exynos850.h
ARM SAMSUNG SOC DRIVERS
M: Sam Protsenko
S: Maintained
-F: doc/device-tree-bindings/soc/samsung/*
+F: doc/device-tree-bindings/soc/samsung/exynos-pmu.yaml
F: drivers/soc/samsung/*
-F: include/dt-bindings/soc/samsung,*.h
ARM SANCLOUD
M: Paul Barker
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a5c82ebf7a5f..4b72d9f64863 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -31,7 +31,6 @@ dtb-$(CONFIG_EXYNOS7420) += exynos7420-espresso7420.dtb
dtb-$(CONFIG_TARGET_A5Y17LTE) += exynos78x0-axy17lte.dtb
dtb-$(CONFIG_TARGET_A3Y17LTE) += exynos78x0-axy17lte.dtb
dtb-$(CONFIG_TARGET_A7Y17LTE) += exynos78x0-axy17lte.dtb
-dtb-$(CONFIG_TARGET_E850_96) += exynos850-e850-96.dtb
dtb-$(CONFIG_ARCH_APPLE) += \
t8103-j274.dtb \
diff --git a/arch/arm/dts/exynos850-e850-96.dts
b/arch/arm/dts/exynos850-e850-96.dts
deleted file mode 100644
index f074df8982b3..
--- a/arch/arm/dts/exynos850-e850-96.dts
+++ /dev/null
@@ -1,273 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * WinLink E850-96 board device tree source
- *
- * Copyright (C) 2018 Samsung Electronics Co., Ltd.
- * Copyright (C) 2021 Linaro Ltd.
- *
- * Device tree source file for WinLink's E850-96 board which is based on
- * Samsung Exynos850 SoC.
- */
-
-/dts-v1/;
-
-#include "exynos850.dtsi"
-#include
-#include
-#include
-
-/ {
- model = "WinLink E850-96 board";
- compatible = "winlink,e850-96", "samsung,exynos850";
-
- aliases {
- mmc0 = _0;
- serial0 = _0;
- };
-
- chosen {
- stdout-path = _0;
- };
-
- connector {
- compatible = "gpio-usb-b-connector", "usb-b-connector";
- label = "micro-USB";
- type = "micro";
- vbus-supply = <_usb_host_vbus>;
- id-gpios = < 0 GPIO_ACTIVE_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <_usb_det_pins>;
-
- port {
- usb_dr_connector: endpoint {
- remote-endpoint = <_drd_sw>;
- };
- };
- };
-
- /*
-* RAM: 4 GiB (eMCP):
-* - 2 GiB at 0x8000
-* - 2 GiB at 0x88000
-
Re: [PATCH 1/2 V2] Revert "board: rockchip: Add early ADC button detect for RGxx3"
On Thu, May 23, 2024 at 11:47:41AM +0800, Kever Yang wrote:
>
> On 2024/5/21 23:45, Chris Morgan wrote:
> > From: Chris Morgan
> >
> > This reverts commit 41a60d0e5cef54a59596a58940fa7c9cf071034b.
> >
> > On some of the supported devices the adc detect code always returns
> > that the button has been pushed, and as a result the device will
> > not boot normally.
>
> Have you check the key input voltage with voltameter which can identify is
> hardware issue or software issue.
It's a software issue. I confirmed I actually could have fixed it by
using the ADC driver (which sets up the interrupt registers correctly).
However, there is something to be said of keeping things simple. I
should have taken your advice from the get-go and just done that.
Thank you.
Chris
>
>
> Thanks,
>
> - Kever
>
> >
> > Signed-off-by: Chris Morgan
> > ---
> > board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 64 --
> > 1 file changed, 64 deletions(-)
> >
> > diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
> > b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
> > index 099eea60c3..5c57b902d1 100644
> > --- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
> > +++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
> > @@ -6,14 +6,12 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -21,8 +19,6 @@
> > #include
> > #include
> > -#define BOOT_BROM_DOWNLOAD 0xef08a53c
> > -
> > #define GPIO0_BASE0xfdd6
> > #define GPIO4_BASE0xfe77
> > #define GPIO_SWPORT_DR_L 0x
> > @@ -36,14 +32,6 @@
> > #define GPIO_WRITEMASK(bits) ((bits) << 16)
> > -#define SARADC_BASE0xfe72
> > -#define SARADC_DATA0x
> > -#define SARADC_STAS0x0004
> > -#define SARADC_ADC_STATUS BIT(0)
> > -#define SARADC_CTRL0x0008
> > -#define SARADC_INPUT_SRC_MSK 0x7
> > -#define SARADC_POWER_CTRL BIT(3)
> > -
> > #define DTB_DIR "rockchip/"
> > struct rg3xx_model {
> > @@ -169,64 +157,12 @@ static const struct rg353_panel rg353_panel_details[]
> > = {
> > },
> > };
> > -/*
> > - * The device has internal eMMC, and while some devices have an exposed
> > - * clk pin you can ground to force a bypass not all devices do. As a
> > - * result it may be possible for some devices to become a perma-brick
> > - * if a corrupted TPL or SPL stage with a valid header is flashed to
> > - * the internal eMMC. Add functionality to read ADC channel 0 (the func
> > - * button) as early as possible in the boot process to provide some
> > - * protection against this. If we ever get an open TPL stage, we should
> > - * consider moving this function there.
> > - */
> > -void read_func_button(void)
> > -{
> > - int ret;
> > - u32 reg;
> > -
> > - /* Turn off SARADC to reset it. */
> > - writel(0, (SARADC_BASE + SARADC_CTRL));
> > -
> > - /* Enable channel 0 and power on SARADC. */
> > - writel(((0 & SARADC_INPUT_SRC_MSK) | SARADC_POWER_CTRL),
> > - (SARADC_BASE + SARADC_CTRL));
> > -
> > - /*
> > -* Wait for data to be ready. Use timeout of 2us from
> > -* rockchip_saradc driver.
> > -*/
> > - ret = readl_poll_timeout((SARADC_BASE + SARADC_STAS), reg,
> > -!(reg & SARADC_ADC_STATUS), 2);
> > - if (ret) {
> > - printf("ADC Timeout");
> > - return;
> > - }
> > -
> > - /* Read the data from the SARADC. */
> > - reg = readl((SARADC_BASE + SARADC_DATA));
> > -
> > - /* Turn the SARADC back off so it's ready to be used again. */
> > - writel(0, (SARADC_BASE + SARADC_CTRL));
> > -
> > - /*
> > -* If the value is less than 30 the button is being pressed.
> > -* Reset the device back into Rockchip download mode.
> > -*/
> > - if (reg <= 30) {
> > - printf("download key pressed, entering download mode...");
> > - writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
> > - do_reset(NULL, 0, 0, NULL);
> > - }
> > -};
> > -
> > /*
> >* Start LED very early so user knows device is on. Set color
> >* to red.
> >*/
> > void spl_board_init(void)
> > {
> > - read_func_button();
> > -
> > /* Set GPIO0_C5, GPIO0_C6, and GPIO0_C7 to output. */
> > writel(GPIO_WRITEMASK(GPIO_C7 | GPIO_C6 | GPIO_C5) | \
> >(GPIO_C7 | GPIO_C6 | GPIO_C5),
Re: [PATCH v2 4/7] dts: beagleplay: binman: Include firmware capsules binman nodes
Tom Rini writes: > On Wed, May 22, 2024 at 11:12:35PM -0500, Jon Humphreys wrote: >> Tom Rini writes: >> >> > On Tue, May 21, 2024 at 09:20:26PM -0500, Jon Humphreys wrote: >> >> Tom Rini writes: >> >> >> >> > On Fri, Apr 19, 2024 at 04:28:16PM -0500, Jonathan Humphreys wrote: >> >> > >> >> >> Fill in the BeaglePlay's capsule GUID properties of the base binman >> >> >> capsule >> >> >> nodes. >> >> >> >> >> >> Signed-off-by: Jonathan Humphreys >> >> >> --- >> >> >> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 27 >> >> >> arch/arm/dts/k3-am625-r5-beagleplay.dts | 15 +++ >> >> >> 2 files changed, 42 insertions(+) >> >> > >> >> > This series introduces failure to build in CI, and it's a little tricky >> >> > to replicate locally, depending on your environment. You first need to >> >> > NOT have BINMAN_INDIRS set and instead be using fake binaries. Second, >> >> > it seems python version dependent perhaps? I don't see this on my host, >> >> > but by: >> >> > - Using the CI container >> >> > - Setting up a virtualenv inside of it >> >> > - pip install -r tools/buildman/requirements.txt >> >> > I get: >> >> > $ ./tools/buildman/buildman --keep-outputs --reproducible-builds -dvel >> >> > --force-build -PEWM --output /tmp/am62x_beagleplay_r5 --board >> >> > am62x_beagleplay_r5 >> >> > Building current source for 1 boards (1 thread, 12 jobs per thread) >> >> >arm: + am62x_beagleplay_r5 >> >> > +(am62x_beagleplay_r5) Image 'tiboot3-am62x-gp-evm.bin' is missing >> >> > optional external blobs but is still functional: ti-fs-gp.bin >> >> > +(am62x_beagleplay_r5) >> >> > +(am62x_beagleplay_r5) /binman/tiboot3-am62x-gp-evm.bin/ti-fs-gp.bin >> >> > (ti-sysfw/ti-fs-firmware-am62x-gp.bin): >> >> > +(am62x_beagleplay_r5)Missing blob >> >> > +(am62x_beagleplay_r5) binman: object of type 'NoneType' has no len() >> >> > +(am62x_beagleplay_r5) make[1]: *** [Makefile:1126: .binman_stamp] >> >> > Error 1 >> >> > +(am62x_beagleplay_r5) make: *** [Makefile:177: sub-make] Error 2 >> >> > 001 /1 am62x_beagleplay_r5 >> >> >> >> Tom, this is failing in the CI container because the container is missing >> >> the mkeficapsule tool. >> >> >> >> To solve this, we just need to add it to the CI container. >> >> >> >> My understanding of binman's handling of missing bintools is that it >> >> should >> >> gracefully continue with fake data, so that buildman can successfully test >> >> out builds for boards even when you don't have all the required bintools. >> >> If I have that correct, I can also create a patch to properly handle this >> >> when using mkeficapsule. But I want to verify this is the desired >> >> behavior, >> >> since mkeficapsule isn't a unique or vendor specific tool, so shouldn't we >> >> require it as part of the U-Boot build environment and err out if it is >> >> missing? >> > >> > Perhaps it's a binman issue since we build mkeficapsule or at least >> > should be? Neha? >> > >> >> Never mind - I figured it out. >> >> The mkeficapsule tools is built by u-boot if TOOLS_MKEFICAPSULE config is >> set. I didn't explicitly set it because it is implied by >> EFI_CAPSULE_ON_DISK config. But this is only set for the A core u-boot, as >> that is what would apply the capsules. SPL running on the R cores does not >> need this. But that then means that the R core u-boot builds don't have >> TOOLS_MKEFICAPSULE set and if that is all that is being built (as in the >> case of buildman), the mkeficapsule tool isn't built and so is missing. >> >> So I need to explicitly set TOOLS_MKEFICAPSULE in the R core defconfigs. >> I'll repost the patches. > > Interesting. My next thought here is that whatever symbol is allowing > for "make a capsule" should be select'ing TOOLS_MKEFICAPSULE and so the > current logic is a bit flawed. I'm just not sure off-hand where it > should be instead, do you have some ideas now? Thanks. > There is no config that indicates that capsules will be generated for the resulting binary. The only thing I can think of is to scan the board's DTB for the presence of a capsule binman node, and then set the TOOLS_MKEFICAPSULE config. But this seems very complicated to do at build time. Jon > -- > Tom
Re: [PATCH v5 4/6] configs: am62x_evm_*: Enable USB and DFU support
Martyn Welch writes: > From: Sjoerd Simons > > Provide config fragments to enable USB host as well as USB gadget and DFU > support for a53 and r5. This relevant fragment is included into the > am62x EVM a53 defconfig. For the r5, due to the smaller available size, > the config fragment also disables support for persistent storage to free > up space for USB support. This fragment needs to be included is DFU > booting is desired. > > The CONFIG_DFU_SF option is placed in the defconfig rather than the > fragment as this is known not to be supported on all boards that can > support DFU. > > Signed-off-by: Sjoerd Simons > Signed-off-by: Martyn Welch > --- > Changes in v5: > - Switch to config fragment for a53 most DFU configuration > > Changes in v4: > - Move R5 dfu config to a config fragment rather then a full defconfig > - Don't enable XHCI for the R5 SPL, unneeded > > Changes in v3: > - Run savedefconfig to adjust to more recent u-boot > > Changes in v2: > - Create a seperate defconfig for R5 > > > > configs/am62x_a53_usbdfu.config | 30 ++ > configs/am62x_evm_a53_defconfig | 2 ++ > configs/am62x_r5_usbdfu.config | 28 > 3 files changed, 60 insertions(+) > create mode 100644 configs/am62x_a53_usbdfu.config > create mode 100644 configs/am62x_r5_usbdfu.config > > diff --git a/configs/am62x_a53_usbdfu.config b/configs/am62x_a53_usbdfu.config > new file mode 100644 > index 00..3a19cf2328 > --- /dev/null > +++ b/configs/am62x_a53_usbdfu.config > @@ -0,0 +1,29 @@ > +CONFIG_SYS_MALLOC_LEN=0x200 > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_SPL_RAM_SUPPORT=y > +CONFIG_SPL_RAM_DEVICE=y > +CONFIG_SPL_USB_GADGET=y > +CONFIG_SPL_DFU=y > +CONFIG_CMD_DFU=y > +CONFIG_CMD_USB=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > +CONFIG_DFU_MMC=y > +CONFIG_DFU_RAM=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 > +CONFIG_SYS_DFU_MAX_FILE_SIZE=0x80 > +CONFIG_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_SPL_DM_USB_GADGET=y > +CONFIG_USB_XHCI_HCD=y > +CONFIG_USB_XHCI_DWC3=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_AM62=y > +CONFIG_USB_DWC3_AM62=y > +CONFIG_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 > +CONFIG_USB_GADGET_DOWNLOAD=y > diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig > index 6c708dcb05..16294a6a79 100644 > --- a/configs/am62x_evm_a53_defconfig > +++ b/configs/am62x_evm_a53_defconfig > @@ -68,6 +68,7 @@ CONFIG_SPL_OF_TRANSLATE=y > CONFIG_CLK=y > CONFIG_SPL_CLK=y > CONFIG_CLK_TI_SCI=y > +CONFIG_DFU_SF=y > CONFIG_DMA_CHANNELS=y > CONFIG_TI_K3_NAVSS_UDMA=y > CONFIG_TI_SCI_PROTOCOL=y > @@ -111,3 +112,5 @@ CONFIG_SPL_SYSRESET=y > CONFIG_SYSRESET_TI_SCI=y > CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 > CONFIG_EFI_SET_TIME=y > + > +#include > diff --git a/configs/am62x_r5_usbdfu.config b/configs/am62x_r5_usbdfu.config > new file mode 100644 > index 00..772bb2ab93 > --- /dev/null > +++ b/configs/am62x_r5_usbdfu.config > @@ -0,0 +1,28 @@ > +CONFIG_SPL_ENV_SUPPORT=y > +CONFIG_SYSCON=y > +CONFIG_SPL_SYSCON=y > +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x5000 > +CONFIG_MISC=y > +CONFIG_USB=y > +CONFIG_DM_USB_GADGET=y > +CONFIG_SPL_DM_USB_GADGET=y > +CONFIG_USB_DWC3=y > +CONFIG_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_GENERIC=y > +CONFIG_SPL_USB_DWC3_AM62=y > +CONFIG_USB_GADGET=y > +CONFIG_SPL_USB_GADGET=y > +CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments" > +CONFIG_USB_GADGET_VENDOR_NUM=0x0451 > +CONFIG_USB_GADGET_PRODUCT_NUM=0x6165 > +CONFIG_USB_GADGET_DOWNLOAD=y > +CONFIG_SPL_DFU=y > +# CONFIG_SPL_MMC is not set > +# CONFIG_SPL_FS_FAT is not set > +# CONFIG_SPL_LIBDISK_SUPPORT is not set > +# CONFIG_SPL_SPI is not set > +# CONFIG_SPL_SYS_MALLOC is not set > +# CONFIG_CMD_GPT is not set > +# CONFIG_CMD_MMC is not set > +# CONFIG_CMD_FAT is not set > +# CONFIG_MMC_SDHCI is not set > -- > 2.43.0 Hi all, it appears that this patch breaks OSPI DFU on the board. In particular, changing the CONFIG_SYS_DFU_DATA_BUF_SIZE seems to be the culprit. I see the error as a DFU timeout when applying capsules. SF: Detected s28hs512t with page size 256 Bytes, erase size 256 KiB, total 64 MiB jedec_spi_nor flash@0: flash operation timed out #DFU write failed Jon
Re: [PATCH] arm: mach-k3: am62p: Fixup TF-A/OP-TEE reserved-memory node in FDT
On Thu, May 23, 2024 at 12:22:56PM -0500, Bryan Brattlof wrote:
> On May 23, 2024 thus sayeth Bryan Brattlof:
> > On May 23, 2024 thus sayeth Andrew Davis:
> > > On 5/23/24 11:43 AM, Bryan Brattlof wrote:
> > > > The address we load TFA and OPTEE is configurable by the
> > > > CONFIG_K3_{ATF,OPTEE)_LOAD_ADDR, but the DT node reservations remain
> > > > static which can cause some confusion about where exactly these firmware
> > > > are exactly. Fix this by updating the reserved-memory{} nodes when the
> > > > loaded address does not match the address in DT.
> > > >
> > > > Reported-by: Andrew Davis
> > > > Signed-off-by: Bryan Brattlof
> > > > ---
> > > > Hello everyone,
> > > >
> > > > This is a little fixup to avoid any confusion once we're in the kernel.
> > > > Because TF-A can be configured in U-Boot to be anywhere we want, we need
> > > > up update the reserved-memory{} node with this change.
> > > >
> > > > Thanks for reviewing
> > > > ~Bryan
> > > > ---
> > > > arch/arm/mach-k3/Makefile | 1 +
> > > > arch/arm/mach-k3/am62p5_fdt.c | 16
> > >
> > > You'll want to rebase this on -next, these _fdt.c files all got moved
> > > into directories for each SoC.
> > >
> >
> > Ah! my bad, you're right this belongs in -next. v2 incoming momentarily
> >
>
> Wait no on second thought, this needs to be in v2024.07 also. I'll leave
> this for Tom for -master and maybe send out another version for -next to
> preempt the merge conflict for v2024.10?
If this needs to go in master then git should hopefully do the right
thing when I merge the next rc tag in.
--
Tom
signature.asc
Description: PGP signature
[PATCH v2 4/5] net: add Qualcomm ESS EDMA adapter
This adds the driver for the ESS EDMA ethernet adapter
found inside of Qualcomm IPQ40xx SoC series.
This driver also integrates the built in modified QCA8337N
switch support as they are tightly integrated.
Co-Developed-by: Gabor Juhos
Signed-off-by: Gabor Juhos
Signed-off-by: Robert Marko
---
Changes in v2:
* Adapt to the Linux pending DT node instead
* Check if port node is enabled
drivers/net/Kconfig |8 +
drivers/net/Makefile |1 +
drivers/net/essedma.c | 1185 +
drivers/net/essedma.h | 198 +++
4 files changed, 1392 insertions(+)
create mode 100644 drivers/net/essedma.c
create mode 100644 drivers/net/essedma.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b2d7b49976..9b7626e1c5 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -307,6 +307,14 @@ config EEPRO100
This driver supports Intel(R) PRO/100 82557/82559/82559ER fast
ethernet family of adapters.
+config ESSEDMA
+ bool "Qualcomm ESS Edma support"
+ depends on DM_ETH && ARCH_IPQ40XX
+ select PHYLIB
+ help
+ This driver supports ethernet DMA adapter found in
+ Qualcomm IPQ40xx series SoC-s.
+
config ETH_SANDBOX
depends on SANDBOX
default y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index dc3404519d..8533793de5 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
obj-$(CONFIG_E1000) += e1000.o
obj-$(CONFIG_E1000_SPI) += e1000_spi.o
obj-$(CONFIG_EEPRO100) += eepro100.o
+obj-$(CONFIG_ESSEDMA) += essedma.o
obj-$(CONFIG_ETHOC) += ethoc.o
obj-$(CONFIG_ETH_DESIGNWARE) += designware.o
obj-$(CONFIG_ETH_DESIGNWARE_MESON8B) += dwmac_meson8b.o
diff --git a/drivers/net/essedma.c b/drivers/net/essedma.c
new file mode 100644
index 00..1be125bafd
--- /dev/null
+++ b/drivers/net/essedma.c
@@ -0,0 +1,1185 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2024 Sartura Ltd.
+ *
+ * Author: Robert Marko
+ *
+ * Copyright (c) 2021 Toco Technologies FZE
+ * Copyright (c) 2021 Gabor Juhos
+ *
+ * Qualcomm ESS EDMA ethernet driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "essedma.h"
+
+#define EDMA_MAX_PKT_SIZE (PKTSIZE_ALIGN + PKTALIGN)
+
+#define EDMA_RXQ_ID0
+#define EDMA_TXQ_ID0
+
+/* descriptor ring */
+struct edma_ring {
+ u16 count; /* number of descriptors in the ring */
+ void *hw_desc; /* descriptor ring virtual address */
+ unsigned int hw_size; /* hw descriptor ring length in bytes */
+ dma_addr_t dma; /* descriptor ring physical address */
+ u16 head; /* next Tx descriptor to fill */
+ u16 tail; /* next Tx descriptor to clean */
+};
+
+struct ess_switch {
+ phys_addr_t base;
+ struct phy_device *phydev[ESS_PORTS_NUM];
+ u32 phy_mask;
+ ofnode ports_node;
+ phy_interface_t port_wrapper_mode;
+ int num_phy;
+};
+
+struct essedma_priv {
+ phys_addr_t base;
+ struct clk ess_clk;
+ struct reset_ctl ess_rst;
+ struct udevice *mdio_dev;
+ struct ess_switch esw;
+ phys_addr_t psgmii_base;
+ struct edma_ring tpd_ring;
+ struct edma_ring rfd_ring;
+};
+
+static void esw_port_loopback_set(struct ess_switch *esw, int port,
+ bool enable)
+{
+ u32 t;
+
+ t = readl(esw->base + ESS_PORT_LOOKUP_CTRL(port));
+ if (enable)
+ t |= ESS_PORT_LOOP_BACK_EN;
+ else
+ t &= ~ESS_PORT_LOOP_BACK_EN;
+ writel(t, esw->base + ESS_PORT_LOOKUP_CTRL(port));
+}
+
+static void esw_port_loopback_set_all(struct ess_switch *esw, bool enable)
+{
+ int i;
+
+ for (i = 1; i < ESS_PORTS_NUM; i++)
+ esw_port_loopback_set(esw, i, enable);
+}
+
+static void ess_reset(struct udevice *dev)
+{
+ struct essedma_priv *priv = dev_get_priv(dev);
+
+ reset_assert(>ess_rst);
+ mdelay(10);
+
+ reset_deassert(>ess_rst);
+ mdelay(10);
+}
+
+void qca8075_ess_reset(struct udevice *dev)
+{
+ struct essedma_priv *priv = dev_get_priv(dev);
+ struct phy_device *psgmii_phy;
+ int i, val;
+
+ /* Find the PSGMII PHY */
+ psgmii_phy = priv->esw.phydev[priv->esw.num_phy - 1];
+
+ /* Fix phy psgmii RX 20bit */
+ phy_write(psgmii_phy, MDIO_DEVAD_NONE, MII_BMCR, 0x005b);
+
+ /* Reset phy psgmii */
+ phy_write(psgmii_phy, MDIO_DEVAD_NONE, MII_BMCR, 0x001b);
+
+ /* Release reset phy psgmii */
+ phy_write(psgmii_phy, MDIO_DEVAD_NONE, MII_BMCR, 0x005b);
+ for (i = 0; i < 100; i++) {
+ val = phy_read_mmd(psgmii_phy, MDIO_MMD_PMAPMD, 0x28);
+ if (val & 0x1)
+ break;
+ mdelay(1);
+ }
+ if (i >= 100)
+
[PATCH v2 5/5] arm: dts: add IPQ4019 ESS EDMA U-Boot additions
IPQ4019 ESS EDMA support is not yet in upstream Linux, so for now lets use
the latest pending Linux DTS node for wired networking.
Signed-off-by: Robert Marko
---
Chanes in v2:
* Use the latest pending Linux DT node for EDMA instead
arch/arm/dts/qcom-ipq4019-u-boot.dtsi | 104 ++
1 file changed, 104 insertions(+)
create mode 100644 arch/arm/dts/qcom-ipq4019-u-boot.dtsi
diff --git a/arch/arm/dts/qcom-ipq4019-u-boot.dtsi
b/arch/arm/dts/qcom-ipq4019-u-boot.dtsi
new file mode 100644
index 00..079f41
--- /dev/null
+++ b/arch/arm/dts/qcom-ipq4019-u-boot.dtsi
@@ -0,0 +1,104 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/ {
+ soc {
+ switch: switch@c00 {
+ compatible = "qcom,ipq4019-ess";
+ reg = <0xc00 0x8>, <0x98000 0x800>, <0xc08
0x8000>;
+ reg-names = "base", "psgmii_phy", "edma";
+ resets = < ESS_PSGMII_ARES>, < ESS_RESET>;
+ reset-names = "psgmii", "ess";
+ clocks = < GCC_ESS_CLK>;
+ clock-names = "ess";
+ mdio = <>;
+ interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ swport1: port@1 { /* MAC1 */
+ reg = <1>;
+ label = "lan1";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport2: port@2 { /* MAC2 */
+ reg = <2>;
+ label = "lan2";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport3: port@3 { /* MAC3 */
+ reg = <3>;
+ label = "lan3";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport4: port@4 { /* MAC4 */
+ reg = <4>;
+ label = "lan4";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+
+ swport5: port@5 { /* MAC5 */
+ reg = <5>;
+ label = "wan";
+ phy-handle = <>;
+ phy-mode = "psgmii";
+
+ status = "disabled";
+ };
+ };
+ };
+ };
+};
+
+ {
+ psgmiiphy: psgmii-phy@5 {
+ reg = <5>;
+ };
+};
--
2.45.1
[PATCH v2 2/5] dt-bindings: clock: qcom: ipq4019: drop downstream file
IPQ4019 clock dt-bindings are available in Linux upstream, and we can just use those instead of carrying a downstream file that matches the upstream one anyway. Signed-off-by: Robert Marko --- Changes in v2: * Drop the downstream dt-bindings header as it matches the upstream Linux one include/dt-bindings/clock/qcom,gcc-ipq4019.h | 169 --- 1 file changed, 169 deletions(-) delete mode 100644 include/dt-bindings/clock/qcom,gcc-ipq4019.h diff --git a/include/dt-bindings/clock/qcom,gcc-ipq4019.h b/include/dt-bindings/clock/qcom,gcc-ipq4019.h deleted file mode 100644 index 7e8a7be6dc..00 --- a/include/dt-bindings/clock/qcom,gcc-ipq4019.h +++ /dev/null @@ -1,169 +0,0 @@ -/* Copyright (c) 2015 The Linux Foundation. All rights reserved. - * - * Permission to use, copy, modify, and/or distribute this software for any - * purpose with or without fee is hereby granted, provided that the above - * copyright notice and this permission notice appear in all copies. - * - * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES - * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF - * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR - * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES - * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN - * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF - * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - * - */ -#ifndef __QCOM_CLK_IPQ4019_H__ -#define __QCOM_CLK_IPQ4019_H__ - -#define GCC_DUMMY_CLK 0 -#define AUDIO_CLK_SRC 1 -#define BLSP1_QUP1_I2C_APPS_CLK_SRC2 -#define BLSP1_QUP1_SPI_APPS_CLK_SRC3 -#define BLSP1_QUP2_I2C_APPS_CLK_SRC4 -#define BLSP1_QUP2_SPI_APPS_CLK_SRC5 -#define BLSP1_UART1_APPS_CLK_SRC 6 -#define BLSP1_UART2_APPS_CLK_SRC 7 -#define GCC_USB3_MOCK_UTMI_CLK_SRC 8 -#define GCC_APPS_CLK_SRC 9 -#define GCC_APPS_AHB_CLK_SRC 10 -#define GP1_CLK_SRC11 -#define GP2_CLK_SRC12 -#define GP3_CLK_SRC13 -#define SDCC1_APPS_CLK_SRC 14 -#define FEPHY_125M_DLY_CLK_SRC 15 -#define WCSS2G_CLK_SRC 16 -#define WCSS5G_CLK_SRC 17 -#define GCC_APSS_AHB_CLK 18 -#define GCC_AUDIO_AHB_CLK 19 -#define GCC_AUDIO_PWM_CLK 20 -#define GCC_BLSP1_AHB_CLK 21 -#define GCC_BLSP1_QUP1_I2C_APPS_CLK22 -#define GCC_BLSP1_QUP1_SPI_APPS_CLK23 -#define GCC_BLSP1_QUP2_I2C_APPS_CLK24 -#define GCC_BLSP1_QUP2_SPI_APPS_CLK25 -#define GCC_BLSP1_UART1_APPS_CLK 26 -#define GCC_BLSP1_UART2_APPS_CLK 27 -#define GCC_DCD_XO_CLK 28 -#define GCC_GP1_CLK29 -#define GCC_GP2_CLK30 -#define GCC_GP3_CLK31 -#define GCC_BOOT_ROM_AHB_CLK 32 -#define GCC_CRYPTO_AHB_CLK 33 -#define GCC_CRYPTO_AXI_CLK 34 -#define GCC_CRYPTO_CLK 35 -#define GCC_ESS_CLK36 -#define GCC_IMEM_AXI_CLK 37 -#define GCC_IMEM_CFG_AHB_CLK 38 -#define GCC_PCIE_AHB_CLK 39 -#define GCC_PCIE_AXI_M_CLK 40 -#define GCC_PCIE_AXI_S_CLK 41 -#define GCC_PCNOC_AHB_CLK 42 -#define GCC_PRNG_AHB_CLK 43 -#define GCC_QPIC_AHB_CLK 44 -#define GCC_QPIC_CLK 45 -#define GCC_SDCC1_AHB_CLK 46 -#define GCC_SDCC1_APPS_CLK 47 -#define GCC_SNOC_PCNOC_AHB_CLK 48 -#define GCC_SYS_NOC_125M_CLK 49 -#define GCC_SYS_NOC_AXI_CLK50 -#define GCC_TCSR_AHB_CLK 51 -#define GCC_TLMM_AHB_CLK 52 -#define GCC_USB2_MASTER_CLK53 -#define GCC_USB2_SLEEP_CLK 54 -#define GCC_USB2_MOCK_UTMI_CLK 55 -#define GCC_USB3_MASTER_CLK56 -#define GCC_USB3_SLEEP_CLK
[PATCH v2 3/5] clock: qcom: ipq4019: add missing networking resets
IPQ4019 has more networking related resets that will be required for future
wired networking support, so lets add them.
This syncs the driver with Linux.
Signed-off-by: Robert Marko
Reviewed-by: Caleb Connolly
---
drivers/clk/qcom/clock-ipq4019.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/clock-ipq4019.c b/drivers/clk/qcom/clock-ipq4019.c
index e416c9cdb0..2773bbc2d4 100644
--- a/drivers/clk/qcom/clock-ipq4019.c
+++ b/drivers/clk/qcom/clock-ipq4019.c
@@ -205,6 +205,12 @@ static const struct qcom_reset_map gcc_ipq4019_resets[] = {
[GCC_TCSR_BCR] = {0x22000, 0},
[GCC_MPM_BCR] = {0x24000, 0},
[GCC_SPDM_BCR] = {0x25000, 0},
+ [ESS_MAC1_ARES] = {0x1200C, 0},
+ [ESS_MAC2_ARES] = {0x1200C, 1},
+ [ESS_MAC3_ARES] = {0x1200C, 2},
+ [ESS_MAC4_ARES] = {0x1200C, 3},
+ [ESS_MAC5_ARES] = {0x1200C, 4},
+ [ESS_PSGMII_ARES] = {0x1200C, 5},
};
static struct msm_clk_data ipq4019_clk_data = {
--
2.45.1
[PATCH v2 1/5] clock: qcom: ipq4019: add ESS clock
ESS clock is the Ethernet Subsystem clock, so lets add it as its already configured by SBL1. Signed-off-by: Robert Marko Reviewed-by: Caleb Connolly --- drivers/clk/qcom/clock-ipq4019.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/clk/qcom/clock-ipq4019.c b/drivers/clk/qcom/clock-ipq4019.c index 0492e536e7..e416c9cdb0 100644 --- a/drivers/clk/qcom/clock-ipq4019.c +++ b/drivers/clk/qcom/clock-ipq4019.c @@ -125,6 +125,9 @@ static int ipq4019_clk_enable(struct clk *clk) case GCC_USB2_MOCK_UTMI_CLK: /* These clocks is already initialized by SBL1 */ return 0; + case GCC_ESS_CLK: + /* This clock is already initialized by SBL1 */ + return 0; default: return -EINVAL; } -- 2.45.1
Re: [PATCH 1/2 v5] board: starfive: support Pine64 Star64 board
On Wednesday, May 22nd, 2024 at 9:40 PM, E Shattow wrote:
> On Wed, May 22, 2024 at 12:13?PM H Bell dmoo...@protonmail.com wrote:
>
> > + {"/soc/ethernet@1604/mdio/ethernet-phy@1",
> > + "tx-internal-delay-ps", "300"},
>
>
> Note this 300uS value for tx-internal-delay-ps differs from
> pre-loaded firmware on Star64:
> ethernet-phy@1 tx_delay_sel = <0x00>;
>
>
> I would prefer to this (even if it is wrong) same as the pre-loaded
> firmware has done. Tuning patches can be applied in some
> future series. Is there a noticeable difference in function to change
> this value from how the pre-loaded firmware does this?
I agree that it should stick to the pre-loaded firmware wherever possible
but I found that using the 0 value on the tx_delay_sel meant that the device
would not properly send packets over the network (and would not get granted
an IP over DHCP), and found (going in steps of 150) that 300 worked.
Re: [PATCH] arm: mach-k3: am62p: Fixup TF-A/OP-TEE reserved-memory node in FDT
On May 23, 2024 thus sayeth Bryan Brattlof:
> On May 23, 2024 thus sayeth Andrew Davis:
> > On 5/23/24 11:43 AM, Bryan Brattlof wrote:
> > > The address we load TFA and OPTEE is configurable by the
> > > CONFIG_K3_{ATF,OPTEE)_LOAD_ADDR, but the DT node reservations remain
> > > static which can cause some confusion about where exactly these firmware
> > > are exactly. Fix this by updating the reserved-memory{} nodes when the
> > > loaded address does not match the address in DT.
> > >
> > > Reported-by: Andrew Davis
> > > Signed-off-by: Bryan Brattlof
> > > ---
> > > Hello everyone,
> > >
> > > This is a little fixup to avoid any confusion once we're in the kernel.
> > > Because TF-A can be configured in U-Boot to be anywhere we want, we need
> > > up update the reserved-memory{} node with this change.
> > >
> > > Thanks for reviewing
> > > ~Bryan
> > > ---
> > > arch/arm/mach-k3/Makefile | 1 +
> > > arch/arm/mach-k3/am62p5_fdt.c | 16
> >
> > You'll want to rebase this on -next, these _fdt.c files all got moved
> > into directories for each SoC.
> >
>
> Ah! my bad, you're right this belongs in -next. v2 incoming momentarily
>
Wait no on second thought, this needs to be in v2024.07 also. I'll leave
this for Tom for -master and maybe send out another version for -next to
preempt the merge conflict for v2024.10?
~Bryan
Re: [PATCH] arm: mach-k3: am62p: Fixup TF-A/OP-TEE reserved-memory node in FDT
On May 23, 2024 thus sayeth Andrew Davis:
> On 5/23/24 11:43 AM, Bryan Brattlof wrote:
> > The address we load TFA and OPTEE is configurable by the
> > CONFIG_K3_{ATF,OPTEE)_LOAD_ADDR, but the DT node reservations remain
> > static which can cause some confusion about where exactly these firmware
> > are exactly. Fix this by updating the reserved-memory{} nodes when the
> > loaded address does not match the address in DT.
> >
> > Reported-by: Andrew Davis
> > Signed-off-by: Bryan Brattlof
> > ---
> > Hello everyone,
> >
> > This is a little fixup to avoid any confusion once we're in the kernel.
> > Because TF-A can be configured in U-Boot to be anywhere we want, we need
> > up update the reserved-memory{} node with this change.
> >
> > Thanks for reviewing
> > ~Bryan
> > ---
> > arch/arm/mach-k3/Makefile | 1 +
> > arch/arm/mach-k3/am62p5_fdt.c | 16
>
> You'll want to rebase this on -next, these _fdt.c files all got moved
> into directories for each SoC.
>
Ah! my bad, you're right this belongs in -next. v2 incoming momentarily
Thanks Andrew
~Bryan
[PATCH v2 2/3] rockchip: Use common bss and stack addresses on PX30
From: Quentin Schulz
See commit 008ba0d56d00 ("rockchip: Add common default bss and stack
addresses") for memory layout. This migrates PX30 to use the new layout,
except for TPL. Indeed, PX30 is extremely limited in SRAM, so we need to
be extra careful about what goes into the TPL and how much we can
allocate there, so let's keep the current value for
TPL_SYS_MALLOC_F_LEN (already present in the PX30-specific Kconfig, from
an earlier commit).
This will allow us to use the same memory layout on one more Rockchip
SoC, which is always a nice thing. Additionally, this will make it
easier to fix U-Boot proper pre-reloc running out of memory on PX30 in a
subsequent commit.
Reviewed-by: Kever Yang
Tested-by: Heiko Stuebner
Signed-off-by: Quentin Schulz
---
arch/arm/mach-rockchip/px30/Kconfig | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-rockchip/px30/Kconfig
b/arch/arm/mach-rockchip/px30/Kconfig
index e39472604c3..dcf9eb8144b 100644
--- a/arch/arm/mach-rockchip/px30/Kconfig
+++ b/arch/arm/mach-rockchip/px30/Kconfig
@@ -68,8 +68,11 @@ config ROCKCHIP_STIMER_BASE
config SYS_SOC
default "px30"
+config ROCKCHIP_COMMON_STACK_ADDR
+ default y
+
config SYS_MALLOC_F_LEN
- default 0x400
+ default 0x400 if !SPL_SHARES_INIT_SP_ADDR
config SPL_SERIAL
default y
--
2.45.1
[PATCH v2 3/3] rockchip: ringneck_px30: Use common bss and stack addresses
From: Quentin Schulz U-Boot proper pre-reloc is currently running out of memory and it is thus impossible to boot into U-Boot CLI. Fix this by migrating to the common bss and stack addresses for PX30, which drastically increases the size of the pre-reloc allocation pool (8 times bigger now). The memory layout in SPL and U-Boot proper now match the other SoCs' using ROCKCHIP_COMMON_STACK_ADDR. Reviewed-by: Kever Yang Tested-by: Heiko Stuebner Signed-off-by: Quentin Schulz --- configs/ringneck-px30_defconfig | 18 +++--- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig index 0df1b8a59ac..94179dca3ae 100644 --- a/configs/ringneck-px30_defconfig +++ b/configs/ringneck-px30_defconfig @@ -2,27 +2,15 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_COUNTER_FREQUENCY=2400 CONFIG_ARCH_ROCKCHIP=y -CONFIG_TEXT_BASE=0x0020 -CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_SPL_GPIO=y -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=0x40 CONFIG_DEFAULT_DEVICE_TREE="px30-ringneck-haikou" -CONFIG_SPL_TEXT_BASE=0x CONFIG_DM_RESET=y CONFIG_ROCKCHIP_PX30=y +# CONFIG_TPL_ROCKCHIP_COMMON_BOARD is not set CONFIG_TARGET_RINGNECK_PX30=y -CONFIG_TPL_LIBGENERIC_SUPPORT=y +# CONFIG_TPL_LIBCOMMON_SUPPORT is not set CONFIG_SPL_DRIVERS_MISC=y -CONFIG_SPL_STACK_R_ADDR=0x60 -CONFIG_SPL_STACK=0x40 -CONFIG_SPL_HAS_BSS_LINKER_SECTION=y -CONFIG_SPL_BSS_START_ADDR=0x400 -CONFIG_SPL_BSS_MAX_SIZE=0x4000 -CONFIG_SPL_STACK_R=y CONFIG_DEBUG_UART_BASE=0xFF03 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SYS_LOAD_ADDR=0x800800 @@ -41,11 +29,11 @@ CONFIG_SPL_PAD_TO=0x0 CONFIG_SPL_BOARD_INIT=y CONFIG_SPL_BOOTROM_SUPPORT=y # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set -# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_SYS_MALLOC=y CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200 CONFIG_SPL_ATF=y # CONFIG_TPL_FRAMEWORK is not set +# CONFIG_TPL_SYS_MALLOC_SIMPLE is not set # CONFIG_CMD_BOOTD is not set # CONFIG_CMD_ELF is not set # CONFIG_CMD_IMI is not set -- 2.45.1
[PATCH v2 1/3] rockchip: px30: default TPL_SYS_MALLOC_F_LEN to 0x600 on PX30 Kconfig level
From: Quentin Schulz This is the kind of setting that typically doesn't need to be changed between boards based on the same SoC, so let's make it the default in PX30 Kconfig so we don't have to care about it in the defconfig if we don't want to. Reviewed-by: Heiko Stuebner Reviewed-by: Kever Yang Tested-by: Heiko Stuebner Signed-off-by: Quentin Schulz --- arch/arm/mach-rockchip/px30/Kconfig | 3 +++ configs/evb-px30_defconfig| 1 - configs/firefly-px30_defconfig| 1 - configs/odroid-go2_defconfig | 1 - configs/px30-core-ctouch2-of10-px30_defconfig | 1 - configs/px30-core-ctouch2-px30_defconfig | 1 - configs/px30-core-edimm2.2-px30_defconfig | 1 - configs/ringneck-px30_defconfig | 1 - 8 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-rockchip/px30/Kconfig b/arch/arm/mach-rockchip/px30/Kconfig index 23f8f430c4a..e39472604c3 100644 --- a/arch/arm/mach-rockchip/px30/Kconfig +++ b/arch/arm/mach-rockchip/px30/Kconfig @@ -83,6 +83,9 @@ config TPL_TEXT_BASE config TPL_STACK default 0xff0e4fff +config TPL_SYS_MALLOC_F_LEN + default 0x600 + config DEBUG_UART_CHANNEL int "Mux channel to use for debug UART2/UART3" depends on DEBUG_UART_BOARD_INIT diff --git a/configs/evb-px30_defconfig b/configs/evb-px30_defconfig index 07c56a45ec0..73a3c6120e0 100644 --- a/configs/evb-px30_defconfig +++ b/configs/evb-px30_defconfig @@ -16,7 +16,6 @@ CONFIG_ROCKCHIP_PX30=y CONFIG_TARGET_EVB_PX30=y CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/configs/firefly-px30_defconfig b/configs/firefly-px30_defconfig index e5377dcdf3d..0a14b393667 100644 --- a/configs/firefly-px30_defconfig +++ b/configs/firefly-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_TARGET_EVB_PX30=y CONFIG_DEBUG_UART_CHANNEL=1 CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/configs/odroid-go2_defconfig b/configs/odroid-go2_defconfig index 99d7149a44c..3c1abb83ed9 100644 --- a/configs/odroid-go2_defconfig +++ b/configs/odroid-go2_defconfig @@ -19,7 +19,6 @@ CONFIG_TARGET_ODROID_GO2=y CONFIG_DEBUG_UART_CHANNEL=1 CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/configs/px30-core-ctouch2-of10-px30_defconfig b/configs/px30-core-ctouch2-of10-px30_defconfig index a2801ec7796..87a39e115df 100644 --- a/configs/px30-core-ctouch2-of10-px30_defconfig +++ b/configs/px30-core-ctouch2-of10-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_TARGET_PX30_CORE=y CONFIG_DEBUG_UART_CHANNEL=1 CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/configs/px30-core-ctouch2-px30_defconfig b/configs/px30-core-ctouch2-px30_defconfig index cc33e275742..7162c117beb 100644 --- a/configs/px30-core-ctouch2-px30_defconfig +++ b/configs/px30-core-ctouch2-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_TARGET_PX30_CORE=y CONFIG_DEBUG_UART_CHANNEL=1 CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/configs/px30-core-edimm2.2-px30_defconfig b/configs/px30-core-edimm2.2-px30_defconfig index 99e1b2fc7ae..1182f60358f 100644 --- a/configs/px30-core-edimm2.2-px30_defconfig +++ b/configs/px30-core-edimm2.2-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_TARGET_PX30_CORE=y CONFIG_DEBUG_UART_CHANNEL=1 CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y diff --git a/configs/ringneck-px30_defconfig b/configs/ringneck-px30_defconfig index 67a44eda684..0df1b8a59ac 100644 --- a/configs/ringneck-px30_defconfig +++ b/configs/ringneck-px30_defconfig @@ -17,7 +17,6 @@ CONFIG_ROCKCHIP_PX30=y CONFIG_TARGET_RINGNECK_PX30=y CONFIG_TPL_LIBGENERIC_SUPPORT=y CONFIG_SPL_DRIVERS_MISC=y -CONFIG_TPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL_STACK_R_ADDR=0x60 CONFIG_SPL_STACK=0x40 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y -- 2.45.1
[PATCH v2 0/3] rockchip: ringneck-px30: migrate to common bss and stack addresses
PX30 Ringneck ran out of memory in the allocation pool of U-Boot proper pre-reloc. Something needed to be done. Jonas did migrate a few SoCs already to this common bss+stack addresses so it made sense to follow the same route for one additional SoC: PX30. The migration of other PX30-based boards will happen in next branch instead, this one however is required for Ringneck to still reach U-Boot CLI. Odroid-Go2 reaches the CLI without the patches in v1. Unknown status for the other boards. @Tom/Kever, please merge this on master. To: Simon Glass To: Philipp Tomsich To: Kever Yang To: Heiko Stuebner To: Jagan Teki To: Suniel Mahesh To: Quentin Schulz To: Klaus Goger Cc: tr...@konsulko.com Cc: jo...@kwiboo.se Cc: u-boot@lists.denx.de Signed-off-by: Quentin Schulz Changes in v2: - remove non-ringneck patches, they'll be for next instead - Link to v1: https://lore.kernel.org/r/20240521-px30-2024-07-rc-v1-0-62109c84d...@cherry.de --- Quentin Schulz (3): rockchip: px30: default TPL_SYS_MALLOC_F_LEN to 0x600 on PX30 Kconfig level rockchip: Use common bss and stack addresses on PX30 rockchip: ringneck_px30: Use common bss and stack addresses arch/arm/mach-rockchip/px30/Kconfig | 8 +++- configs/evb-px30_defconfig| 1 - configs/firefly-px30_defconfig| 1 - configs/odroid-go2_defconfig | 1 - configs/px30-core-ctouch2-of10-px30_defconfig | 1 - configs/px30-core-ctouch2-px30_defconfig | 1 - configs/px30-core-edimm2.2-px30_defconfig | 1 - configs/ringneck-px30_defconfig | 19 +++ 8 files changed, 10 insertions(+), 23 deletions(-) --- base-commit: a7f0154c412859323396111dd0c09dbafbc153cb change-id: 20240521-px30-2024-07-rc-7136f6241d29 Best regards, -- Quentin Schulz
Re: [PATCH] arm: mach-k3: am62p: Fixup TF-A/OP-TEE reserved-memory node in FDT
On 5/23/24 11:43 AM, Bryan Brattlof wrote:
The address we load TFA and OPTEE is configurable by the
CONFIG_K3_{ATF,OPTEE)_LOAD_ADDR, but the DT node reservations remain
static which can cause some confusion about where exactly these firmware
are exactly. Fix this by updating the reserved-memory{} nodes when the
loaded address does not match the address in DT.
Reported-by: Andrew Davis
Signed-off-by: Bryan Brattlof
---
Hello everyone,
This is a little fixup to avoid any confusion once we're in the kernel.
Because TF-A can be configured in U-Boot to be anywhere we want, we need
up update the reserved-memory{} node with this change.
Thanks for reviewing
~Bryan
---
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/am62p5_fdt.c | 16
You'll want to rebase this on -next, these _fdt.c files all got moved
into directories for each SoC.
Andrew
arch/arm/mach-k3/am62px/Kconfig | 1 +
3 files changed, 18 insertions(+)
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 1bd523329a4f8..4e9d0925f13f5 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o
+obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_fdt.o
endif
ifeq ($(CONFIG_SPL_BUILD),y)
obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
diff --git a/arch/arm/mach-k3/am62p5_fdt.c b/arch/arm/mach-k3/am62p5_fdt.c
new file mode 100644
index 0..d67f012a5dcc4
--- /dev/null
+++ b/arch/arm/mach-k3/am62p5_fdt.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include "common_fdt.h"
+#include
+
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+ fdt_fixup_reserved(blob, "tfa", CONFIG_K3_ATF_LOAD_ADDR, 0x8);
+ fdt_fixup_reserved(blob, "optee", CONFIG_K3_OPTEE_LOAD_ADDR, 0x180);
+
+ return 0;
+}
diff --git a/arch/arm/mach-k3/am62px/Kconfig b/arch/arm/mach-k3/am62px/Kconfig
index 38a9e6811b119..76ae86b66222f 100644
--- a/arch/arm/mach-k3/am62px/Kconfig
+++ b/arch/arm/mach-k3/am62px/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM62P5_A53_EVM
bool "TI K3 based AM62P5 EVM running on A53"
select ARM64
select BINMAN
+ select OF_SYSTEM_SETUP
config TARGET_AM62P5_R5_EVM
bool "TI K3 based AM62P5 EVM running on R5"
---
base-commit: a7f0154c412859323396111dd0c09dbafbc153cb
change-id: 20240520-am62p-fdt-fix-7c51e1a1cd54
Best regards,
Re: [PATCH 16/16] efi: LoongArch: Implement everything
在2024年5月23日五月 下午5:26，Heinrich Schuchardt写道： >> diff --git a/arch/loongarch/lib/reloc_loongarch_efi.c >> b/arch/loongarch/lib/reloc_loongarch_efi.c >> new file mode 100644 >> index ..32a7d792103d >> --- /dev/null >> +++ b/arch/loongarch/lib/reloc_loongarch_efi.c > > The code seems to be very similar for all architectures. I wonder if one > implementation could cover them all. Not for MIPS due to differences on psABI dynamic relocations. We still need to handle differences between Rel and Rela and other tiny bits. I think most architectures have their relocation handling code rooted from gnu-efi. Thanks - Jiaxun > > Best regards > > Heinrich > -- - Jiaxun
[PATCH] arm: mach-k3: am62p: Fixup TF-A/OP-TEE reserved-memory node in FDT
The address we load TFA and OPTEE is configurable by the
CONFIG_K3_{ATF,OPTEE)_LOAD_ADDR, but the DT node reservations remain
static which can cause some confusion about where exactly these firmware
are exactly. Fix this by updating the reserved-memory{} nodes when the
loaded address does not match the address in DT.
Reported-by: Andrew Davis
Signed-off-by: Bryan Brattlof
---
Hello everyone,
This is a little fixup to avoid any confusion once we're in the kernel.
Because TF-A can be configured in U-Boot to be anywhere we want, we need
up update the reserved-memory{} node with this change.
Thanks for reviewing
~Bryan
---
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/am62p5_fdt.c | 16
arch/arm/mach-k3/am62px/Kconfig | 1 +
3 files changed, 18 insertions(+)
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 1bd523329a4f8..4e9d0925f13f5 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
obj-$(CONFIG_SOC_K3_J784S4) += j784s4_fdt.o
+obj-$(CONFIG_SOC_K3_AM62P5) += am62p5_fdt.o
endif
ifeq ($(CONFIG_SPL_BUILD),y)
obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
diff --git a/arch/arm/mach-k3/am62p5_fdt.c b/arch/arm/mach-k3/am62p5_fdt.c
new file mode 100644
index 0..d67f012a5dcc4
--- /dev/null
+++ b/arch/arm/mach-k3/am62p5_fdt.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include "common_fdt.h"
+#include
+
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+ fdt_fixup_reserved(blob, "tfa", CONFIG_K3_ATF_LOAD_ADDR, 0x8);
+ fdt_fixup_reserved(blob, "optee", CONFIG_K3_OPTEE_LOAD_ADDR, 0x180);
+
+ return 0;
+}
diff --git a/arch/arm/mach-k3/am62px/Kconfig b/arch/arm/mach-k3/am62px/Kconfig
index 38a9e6811b119..76ae86b66222f 100644
--- a/arch/arm/mach-k3/am62px/Kconfig
+++ b/arch/arm/mach-k3/am62px/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM62P5_A53_EVM
bool "TI K3 based AM62P5 EVM running on A53"
select ARM64
select BINMAN
+ select OF_SYSTEM_SETUP
config TARGET_AM62P5_R5_EVM
bool "TI K3 based AM62P5 EVM running on R5"
---
base-commit: a7f0154c412859323396111dd0c09dbafbc153cb
change-id: 20240520-am62p-fdt-fix-7c51e1a1cd54
Best regards,
--
Bryan Brattlof
Re: [PATCH 06/16] LoongArch: skeleton and headers
On 22.05.24 17:34, Jiaxun Yang wrote: Commit for directories, Kconfig, Makefile and headers Some of them are copied from linux, some of them are derived from other architectures, the rest are wriiten on my own. Signed-off-by: Jiaxun Yang --- arch/Kconfig | 15 + arch/loongarch/Kconfig | 40 + arch/loongarch/Makefile| 19 + arch/loongarch/config.mk | 23 + arch/loongarch/cpu/Makefile|5 + arch/loongarch/cpu/u-boot.lds | 85 ++ arch/loongarch/dts/Makefile| 13 + arch/loongarch/include/asm/acpi_table.h|8 + arch/loongarch/include/asm/addrspace.h | 87 ++ .../include/asm/arch-generic/entry-init.h | 15 + arch/loongarch/include/asm/asm.h | 186 +++ arch/loongarch/include/asm/atomic.h| 12 + arch/loongarch/include/asm/barrier.h | 138 ++ arch/loongarch/include/asm/bitops.h| 156 +++ arch/loongarch/include/asm/byteorder.h | 22 + arch/loongarch/include/asm/cache.h | 24 + arch/loongarch/include/asm/config.h| 11 + arch/loongarch/include/asm/cpu.h | 123 ++ arch/loongarch/include/asm/dma-mapping.h | 27 + arch/loongarch/include/asm/global_data.h | 43 + arch/loongarch/include/asm/gpio.h | 11 + arch/loongarch/include/asm/io.h| 399 ++ arch/loongarch/include/asm/linkage.h | 11 + arch/loongarch/include/asm/loongarch.h | 1468 arch/loongarch/include/asm/posix_types.h | 87 ++ arch/loongarch/include/asm/processor.h | 11 + arch/loongarch/include/asm/ptrace.h| 33 + arch/loongarch/include/asm/regdef.h| 42 + arch/loongarch/include/asm/sections.h |8 + arch/loongarch/include/asm/setjmp.h| 25 + arch/loongarch/include/asm/spl.h | 11 + arch/loongarch/include/asm/string.h| 11 + arch/loongarch/include/asm/system.h| 74 + arch/loongarch/include/asm/types.h | 37 + arch/loongarch/include/asm/u-boot-loongarch.h | 23 + arch/loongarch/include/asm/u-boot.h| 30 + arch/loongarch/include/asm/unaligned.h | 11 + arch/loongarch/lib/Makefile|5 + 38 files changed, 3349 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index abd406d48841..236b0e637385 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -70,6 +70,20 @@ config ARM select SUPPORT_ACPI select SUPPORT_OF_CONTROL +config LOONGARCH + bool "LoongArch architecture" + select CREATE_ARCH_SYMLINK + select SUPPORT_OF_CONTROL + select OF_CONTROL + select DM + select DM_EVENT + imply DM_SERIAL + imply BLK + imply CLK + imply MTD + imply TIMER + imply CMD_DM + config M68K bool "M68000 architecture" select HAVE_PRIVATE_LIBGCC @@ -496,6 +510,7 @@ config SYS_NONCACHED_MEMORY source "arch/arc/Kconfig" source "arch/arm/Kconfig" +source "arch/loongarch/Kconfig" source "arch/m68k/Kconfig" source "arch/microblaze/Kconfig" source "arch/mips/Kconfig" diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig new file mode 100644 index ..4e8e9d4ee88b --- /dev/null +++ b/arch/loongarch/Kconfig @@ -0,0 +1,40 @@ +menu "LoongArch architecture" + depends on LOONGARCH + +config SYS_ARCH + default "loongarch" + +choice + prompt "Target select" + +endchoice + +# board-specific options below + +# platform-specific options below + +# architecture-specific options below +choice + prompt "Base ISA" + +config ARCH_LA64 While having short symbols is generally good, I would prefer something self explanatory: ARCH_LOONGARCH64. Best regards Heinrich + bool "LoongArch64" + select 64BIT + select PHYS_64BIT + help + Choose this option to target the LoongArch64 base ISA. + +endchoice + +config DMA_ADDR_T_64BIT + bool + default y if 64BIT + +config STACK_SIZE_SHIFT + int + default 14 + +config OF_BOARD_FIXUP + default y if OF_SEPARATE + +endmenu diff --git a/arch/loongarch/Makefile b/arch/loongarch/Makefile new file mode 100644 index ..288c695a634d --- /dev/null +++ b/arch/loongarch/Makefile @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2024 Jiaxun yang +# + +ARCH_FLAGS = -march=loongarch64 -mabi=lp64s -msoft-float + +ifeq ($(CONFIG_$(SPL_)FRAMEPOINTER),y) + ARCH_FLAGS += -fno-omit-frame-pointer +endif + +PLATFORM_CPPFLAGS += $(ARCH_FLAGS) + +head-y :=
Re: [PATCH 03/15] net-lwip: add DHCP support and dhcp commmand
On Wed, May 22, 2024 at 06:00:03PM +0200, Jerome Forissier wrote: > Add what it takes to enable CONFIG_NETDEVICES with CONFIG_NET_LWIP and > enable DHCP as well as the dhcp command (CONFIG_CMD_DHCP_LWIP). > - net-lwip/net-lwip.c is mostly empty for now. It will provide functions > similar to net/net.c except based on the lwIP stack > - include/net-lwip.h is a replacement for include/net.h which is unused > when CONFIG_NET_LWIP is enabled. Declarations from the latter will be > transferred to the former as needed when new network commands are ported > on top of lwIP. > - CONFIG_CMD_TFTPBOOT_LWIP is introduced due to CONFIG_BOOTMETH_EFI having > an implicit dependency on do_tftpb(). > > Signed-off-by: Jerome Forissier I don't like a new symbol for re-implementing each command. To me, the user should pick lwIP or traditional stack, and CMD_DHCP gives the DHCP command and so forth, and so the Makefile gets reworked as needed. -- Tom signature.asc Description: PGP signature
Re: [PATCH 16/16] efi: LoongArch: Implement everything
On 22.05.24 17:34, Jiaxun Yang wrote: Implement crt, reloc, linker scripts, wire things up in Makefiles and Kconfig. Signed-off-by: Jiaxun Yang --- arch/loongarch/config.mk | 4 + arch/loongarch/lib/Makefile | 12 ++ arch/loongarch/lib/crt0_loongarch_efi.S | 182 +++ arch/loongarch/lib/elf_loongarch_efi.lds | 76 + arch/loongarch/lib/reloc_loongarch_efi.c | 107 ++ lib/efi_loader/Kconfig | 2 +- 6 files changed, 382 insertions(+), 1 deletion(-) diff --git a/arch/loongarch/config.mk b/arch/loongarch/config.mk index 7c247400e361..bae4566e9b62 100644 --- a/arch/loongarch/config.mk +++ b/arch/loongarch/config.mk @@ -21,3 +21,7 @@ endif PLATFORM_CPPFLAGS += -fpic PLATFORM_RELFLAGS += -fno-common -ffunction-sections -fdata-sections LDFLAGS_u-boot+= --gc-sections -static -pie + +EFI_LDS:= elf_loongarch_efi.lds +EFI_CRT0 := crt0_loongarch_efi.o +EFI_RELOC := reloc_loongarch_efi.o diff --git a/arch/loongarch/lib/Makefile b/arch/loongarch/lib/Makefile index e65e66357a9b..17d2b1160b41 100644 --- a/arch/loongarch/lib/Makefile +++ b/arch/loongarch/lib/Makefile @@ -12,3 +12,15 @@ ifeq ($(CONFIG_$(SPL_)SYSRESET),) obj-y += reset.o endif obj-y += setjmp.o + +# For building EFI apps +CFLAGS_NON_EFI := -fstack-protector-strong +CFLAGS_$(EFI_CRT0) := $(CFLAGS_EFI) +CFLAGS_REMOVE_$(EFI_CRT0) := $(CFLAGS_NON_EFI) + +CFLAGS_$(EFI_RELOC) := $(CFLAGS_EFI) +CFLAGS_REMOVE_$(EFI_RELOC) := $(CFLAGS_NON_EFI) + +extra-$(CONFIG_CMD_BOOTEFI_HELLO_COMPILE) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_CMD_BOOTEFI_SELFTEST) += $(EFI_CRT0) $(EFI_RELOC) +extra-$(CONFIG_EFI) += $(EFI_CRT0) $(EFI_RELOC) diff --git a/arch/loongarch/lib/crt0_loongarch_efi.S b/arch/loongarch/lib/crt0_loongarch_efi.S new file mode 100644 index ..5be47045ad8a --- /dev/null +++ b/arch/loongarch/lib/crt0_loongarch_efi.S @@ -0,0 +1,182 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * crt0-efi-loongarch.S - PE/COFF header for LoongArch EFI applications + * + * Copright (C) 2024 Jiaxun Yang + */ + +#include +#include + +#ifdef __loongarch64 +#define PE_MACHINE IMAGE_FILE_MACHINE_LOONGARCH64 +#define PE_MAGICIMAGE_NT_OPTIONAL_HDR64_MAGIC +#define IMG_CHARACTERISTICS \ + (IMAGE_FILE_EXECUTABLE_IMAGE | \ +IMAGE_FILE_LINE_NUMS_STRIPPED | \ +IMAGE_FILE_LOCAL_SYMS_STRIPPED | \ +IMAGE_FILE_LARGE_ADDRESS_AWARE | \ +IMAGE_FILE_DEBUG_STRIPPED) +#else +#define PE_MACHINE IMAGE_FILE_MACHINE_LOONGARCH32 +#define PE_MAGICIMAGE_NT_OPTIONAL_HDR32_MAGIC +#define IMG_CHARACTERISTICS \ + (IMAGE_FILE_EXECUTABLE_IMAGE | \ +IMAGE_FILE_LINE_NUMS_STRIPPED | \ +IMAGE_FILE_LOCAL_SYMS_STRIPPED | \ +IMAGE_FILE_DEBUG_STRIPPED) +#endif + + .section.text.head + + /* +* Magic "MZ" signature for PE/COFF +*/ + .globl ImageBase +ImageBase: + .short IMAGE_DOS_SIGNATURE /* 'MZ' */ + .skip 58 + .long pe_header - ImageBase /* Offset to the PE header */ +pe_header: + .long IMAGE_NT_SIGNATURE /* 'PE' */ +coff_header: + .short PE_MACHINE /* LoongArch 64/32-bit */ + .short 3 /* nr_sections */ + .long 0 /* TimeDateStamp */ + .long 0 /* PointerToSymbolTable */ + .long 0 /* NumberOfSymbols */ + .short section_table - optional_header /* SizeOfOptionalHeader */ + .short IMG_CHARACTERISTICS /* Characteristics */ +optional_header: + .short PE_MAGIC/* PE32(+) format */ + .byte 0x02/* MajorLinkerVersion */ + .byte 0x14/* MinorLinkerVersion */ + .long _edata - _start /* SizeOfCode */ + .long 0 /* SizeOfInitializedData */ + .long 0 /* SizeOfUninitializedData */ + .long _start - ImageBase /* AddressOfEntryPoint */ + .long _start - ImageBase /* BaseOfCode */ +#ifndef __loongarch64 + .long 0 /* BaseOfData */ +#endif + +extra_header_fields: + LONG0 + .long 0x200 /* SectionAlignment */ + .long 0x200 /* FileAlignment */ + .short 0 /* MajorOperatingSystemVersion */ + .short 0 /* MinorOperatingSystemVersion */ + .short 1 /* MajorImageVersion */ + .short 0 /* MinorImageVersion */ +
Re: [PATCH 15/16] efi: LoongArch: Define LoongArch bits everywhere
在2024年5月23日五月 下午5:14，Heinrich Schuchardt写道：
[...]
> Looking at
> https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html:
>
> There the following symbols are mentioned:
>
> __loongarch__
> __loongarch_grlen
>
>
> Table 15.
> C/C++ Built-in Macros Provided for Compatibility with Historical Code
> marks __loongarch64 as deprecated.
Thanks, will use new macros instead.
>
>> +#define BOOTENV_EFI_PXE_ARCH "0x27"
>> +#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00039:UNDI:003000"
>
> Where are the 32bit defines?
Since we don't have CONFIG_ARCH_LA32 in U-Boot yet I leave 32 bit alone.
Those will need to be added when we get 32-bit ready.
>
> Cf.
> https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
>
> 0x00 0x25 LoongArch 32-bit UEFI
> 0x00 0x26 LoongArch 32-bit UEFI boot from http
> 0x00 0x27 LoongArch 64-bit UEFI
> 0x00 0x28 LoongArch 64-bit UEFI boot from http
>
[...]
>> +#elif defined(CONFIG_LOONGARCH)
>> +asm volatile ("break 0xf\n");
>
> Can we use an undefined instruction here as for the other architectures,
> please.
LoongArch have way too many hidden opcodes that is not documented & will
not trigger exception. It's pretty hard for me to identify an opcode that
can trigger exception on all hardware (and including future hardware).
Meanwhile, breakpoint instruction with an invalid hint can always generate
an SIGILL.
Thanks
>
> Best regards
>
> Heinrich
>
>> #elif defined(CONFIG_SANDBOX)
>> #if (HOST_ARCH == HOST_ARCH_ARM || HOST_ARCH == HOST_ARCH_AARCH64)
>> asm volatile (".word 0xe7f7defb\n");
>>
--
- Jiaxun
Re: [PATCH 15/16] efi: LoongArch: Define LoongArch bits everywhere
On 22.05.24 17:34, Jiaxun Yang wrote:
They are all coming from UEFI spec, Microsoft PE sepc,
%s/PE sepc/PE-COFF specification/
or IANA websites.
Signed-off-by: Jiaxun Yang
---
boot/bootmeth_efi.c | 2 ++
include/asm-generic/pe.h | 2 ++
include/config_distro_bootcmd.h | 5 +
include/efi_default_filename.h| 2 ++
lib/efi_loader/efi_image_loader.c | 7 +++
lib/efi_loader/efi_runtime.c | 4
lib/efi_selftest/efi_selftest_miniapp_exception.c | 2 ++
7 files changed, 24 insertions(+)
diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
index aebc5207fc01..b0207dac49c5 100644
--- a/boot/bootmeth_efi.c
+++ b/boot/bootmeth_efi.c
@@ -41,6 +41,8 @@ static int get_efi_pxe_arch(void)
return 0x19;
else if (IS_ENABLED(CONFIG_ARCH_RV64I))
return 0x1b;
+ else if (IS_ENABLED(CONFIG_ARCH_LA64))
+ return 0x27;
else if (IS_ENABLED(CONFIG_SANDBOX))
return 0; /* not used */
diff --git a/include/asm-generic/pe.h b/include/asm-generic/pe.h
index cd5b6ad62bf0..fb93f2621715 100644
--- a/include/asm-generic/pe.h
+++ b/include/asm-generic/pe.h
@@ -38,6 +38,8 @@
#define IMAGE_FILE_MACHINE_ARM64 0xaa64
#define IMAGE_FILE_MACHINE_RISCV320x5032
#define IMAGE_FILE_MACHINE_RISCV640x5064
+#define IMAGE_FILE_MACHINE_LOONGARCH32 0x6232
+#define IMAGE_FILE_MACHINE_LOONGARCH64 0x6264
/* Header magic constants */
#define IMAGE_NT_OPTIONAL_HDR32_MAGIC 0x010b
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 2a136b96a6d9..f8c3a4bb70ae 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -118,6 +118,8 @@
#define BOOTEFI_NAME "bootriscv32.efi"
#elif defined(CONFIG_ARCH_RV64I)
#define BOOTEFI_NAME "bootriscv64.efi"
+#elif defined(CONFIG_ARCH_LA64)
+#define BOOTEFI_NAME "bootloongarch64.efi"
#endif
#endif
@@ -366,6 +368,9 @@
#elif defined(CONFIG_ARCH_RV64I) || ((defined(__riscv) && __riscv_xlen == 64))
#define BOOTENV_EFI_PXE_ARCH "0x1b"
#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00027:UNDI:003000"
+#elif defined(CONFIG_ARCH_LA64) || defined(__loongarch64)
Looking at
https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html:
There the following symbols are mentioned:
__loongarch__
__loongarch_grlen
Table 15.
C/C++ Built-in Macros Provided for Compatibility with Historical Code
marks __loongarch64 as deprecated.
+#define BOOTENV_EFI_PXE_ARCH "0x27"
+#define BOOTENV_EFI_PXE_VCI "PXEClient:Arch:00039:UNDI:003000"
Where are the 32bit defines?
Cf.
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml
0x00 0x25 LoongArch 32-bit UEFI
0x00 0x26 LoongArch 32-bit UEFI boot from http
0x00 0x27 LoongArch 64-bit UEFI
0x00 0x28 LoongArch 64-bit UEFI boot from http
#elif defined(CONFIG_SANDBOX)
# error "sandbox EFI support is only supported on ARM and x86"
#else
diff --git a/include/efi_default_filename.h b/include/efi_default_filename.h
index 77932984b557..fac25039fd31 100644
--- a/include/efi_default_filename.h
+++ b/include/efi_default_filename.h
@@ -47,6 +47,8 @@
#define BOOTEFI_NAME "BOOTRISCV32.EFI"
#elif defined(CONFIG_ARCH_RV64I)
#define BOOTEFI_NAME "BOOTRISCV64.EFI"
+#elif defined(CONFIG_ARCH_LA64)
+#define BOOTEFI_NAME "BOOTLOONGARCH64.EFI"
#else
#error Unsupported UEFI architecture
#endif
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 604243603289..cb0619f27e8a 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -50,6 +50,13 @@ static int machines[] = {
#if defined(__riscv) && (__riscv_xlen == 64)
IMAGE_FILE_MACHINE_RISCV64,
#endif
+
+#if defined(__loongarch64)
marks __loongarch64 is deprecated.
+ IMAGE_FILE_MACHINE_LOONGARCH64,
+#endif
+#if defined(__loongarch32)
ditto
+ IMAGE_FILE_MACHINE_LOONGARCH32,
+#endif
0 };
/**
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 011bcd04836d..45bdf45b5812 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -76,6 +76,10 @@ struct dyn_sym {
#else
#error unknown riscv target
#endif
+#elif defined(__loongarch__)
+#define R_RELATIVE R_LARCH_RELATIVE
+#define R_MASK 0xULL
+#define IS_RELA1
#else
#error Need to add relocation awareness
#endif
diff --git a/lib/efi_selftest/efi_selftest_miniapp_exception.c
b/lib/efi_selftest/efi_selftest_miniapp_exception.c
index f668cdac4ab2..1e500a5ccc35 100644
--- a/lib/efi_selftest/efi_selftest_miniapp_exception.c
+++ b/lib/efi_selftest/efi_selftest_miniapp_exception.c
@@ -35,6 +35,8 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
asm volatile (".word
RE: [PATCH 1/1] Added arm64 assembly for examples/api crt0
I can see that efi_device_path.c and efi_disk.c both #include blk.h. -Original Message- From: Tom Rini Sent: Thursday, May 23, 2024 11:33 AM To: Brunham, Kalen ; Heinrich Schuchardt Cc: U-Boot@lists.denx.de Subject: Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0 On Wed, May 22, 2024 at 05:22:24PM +, Brunham, Kalen wrote: > Hi Tom, > > BLK is currently a dependency for EFI_LOADER as shown in the snippet from > lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER requires > a block device? If I remove this depends on BLK line, then I can enable EFI > and successfully simulate the EFI hello world on my test design. > > > config EFI_LOADER > bool "Support running UEFI applications" > depends on OF_LIBFDT && ( \ > ARM && (SYS_CPU = arm1136 || \ > SYS_CPU = arm1176 || \ > SYS_CPU = armv7 || \ > SYS_CPU = armv8) || \ > X86 || RISCV || SANDBOX) > # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB > depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > depends on BLK > depends on !EFI_APP > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 Do you recall why this is Heinrich? -- Tom
Re: [PATCH 00/16] LoongArch initial support
On Thu, 23 May 2024 at 16:39, Jiaxun Yang wrote: > > > > 在2024年5月23日五月 下午4:25，Tom Rini写道： > > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote: > > > >> Hi all, > >> > >> Sorry for flooding the mailing list recently, yet another huge RFC series > >> ahead. > >> > >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as > >> suggested > >> by Heinrich. > > > > My big feedback here, and it applies to all of your other series as > > well, is to please update CI to make use of and test this. On the Docker > > side, update tools/docker/Dockerfile as needed. For Azure, you can tell > > it to use a different image and then follow the documentation on > > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab > > you can at least use their "linter" to make sure that your additions > > have the correct syntax. Thanks. > > Hi Tom, > > Thanks for the feedback, I thought CI is for custodians only :-) Well when this lands you'll become a custodian ;-) > Do you mean I should include azure/gitlab pipeline file to create > pipeline for those new qemu targets? > > Thanks > > > > > -- > > Tom > > > > 附件: > > * signature.asc > > -- > - Jiaxun
Re: [PATCH 00/16] LoongArch initial support
On Thu, May 23, 2024 at 04:38:52PM +0100, Jiaxun Yang wrote: > > > 在2024年5月23日五月 下午4:25，Tom Rini写道： > > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote: > > > >> Hi all, > >> > >> Sorry for flooding the mailing list recently, yet another huge RFC series > >> ahead. > >> > >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as > >> suggested > >> by Heinrich. > > > > My big feedback here, and it applies to all of your other series as > > well, is to please update CI to make use of and test this. On the Docker > > side, update tools/docker/Dockerfile as needed. For Azure, you can tell > > it to use a different image and then follow the documentation on > > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab > > you can at least use their "linter" to make sure that your additions > > have the correct syntax. Thanks. > > Hi Tom, > > Thanks for the feedback, I thought CI is for custodians only :-) > > Do you mean I should include azure/gitlab pipeline file to create > pipeline for those new qemu targets? Yes, just like the rest of the QEMU targets. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] LoongArch initial support
在2024年5月23日五月 下午4:25，Tom Rini写道： > On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote: > >> Hi all, >> >> Sorry for flooding the mailing list recently, yet another huge RFC series >> ahead. >> >> So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as >> suggested >> by Heinrich. > > My big feedback here, and it applies to all of your other series as > well, is to please update CI to make use of and test this. On the Docker > side, update tools/docker/Dockerfile as needed. For Azure, you can tell > it to use a different image and then follow the documentation on > https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab > you can at least use their "linter" to make sure that your additions > have the correct syntax. Thanks. Hi Tom, Thanks for the feedback, I thought CI is for custodians only :-) Do you mean I should include azure/gitlab pipeline file to create pipeline for those new qemu targets? Thanks > > -- > Tom > > 附件: > * signature.asc -- - Jiaxun
Re: [PATCH 1/1] Added arm64 assembly for examples/api crt0
On Wed, May 22, 2024 at 05:22:24PM +, Brunham, Kalen wrote: > Hi Tom, > > BLK is currently a dependency for EFI_LOADER as shown in the snippet from > lib/efi_loader/Kconfig below. Perhaps the question is why EFI_LOADER requires > a block device? If I remove this depends on BLK line, then I can enable EFI > and successfully simulate the EFI hello world on my test design. > > > config EFI_LOADER > bool "Support running UEFI applications" > depends on OF_LIBFDT && ( \ > ARM && (SYS_CPU = arm1136 || \ > SYS_CPU = arm1176 || \ > SYS_CPU = armv7 || \ > SYS_CPU = armv8) || \ > X86 || RISCV || SANDBOX) > # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB > depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT > # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB > depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT > depends on BLK > depends on !EFI_APP > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8 Do you recall why this is Heinrich? -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/16] LoongArch initial support
On Wed, May 22, 2024 at 04:34:43PM +0100, Jiaxun Yang wrote: > Hi all, > > Sorry for flooding the mailing list recently, yet another huge RFC series > ahead. > > So after working on MIPS, arm64be and Xtensa I'm now on LoongArch, as > suggested > by Heinrich. My big feedback here, and it applies to all of your other series as well, is to please update CI to make use of and test this. On the Docker side, update tools/docker/Dockerfile as needed. For Azure, you can tell it to use a different image and then follow the documentation on https://docs.u-boot.org/en/latest/develop/ci_testing.html and for GitLab you can at least use their "linter" to make sure that your additions have the correct syntax. Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 4/7] dts: beagleplay: binman: Include firmware capsules binman nodes
On Wed, May 22, 2024 at 11:12:35PM -0500, Jon Humphreys wrote: > Tom Rini writes: > > > On Tue, May 21, 2024 at 09:20:26PM -0500, Jon Humphreys wrote: > >> Tom Rini writes: > >> > >> > On Fri, Apr 19, 2024 at 04:28:16PM -0500, Jonathan Humphreys wrote: > >> > > >> >> Fill in the BeaglePlay's capsule GUID properties of the base binman > >> >> capsule > >> >> nodes. > >> >> > >> >> Signed-off-by: Jonathan Humphreys > >> >> --- > >> >> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 27 > >> >> arch/arm/dts/k3-am625-r5-beagleplay.dts | 15 +++ > >> >> 2 files changed, 42 insertions(+) > >> > > >> > This series introduces failure to build in CI, and it's a little tricky > >> > to replicate locally, depending on your environment. You first need to > >> > NOT have BINMAN_INDIRS set and instead be using fake binaries. Second, > >> > it seems python version dependent perhaps? I don't see this on my host, > >> > but by: > >> > - Using the CI container > >> > - Setting up a virtualenv inside of it > >> > - pip install -r tools/buildman/requirements.txt > >> > I get: > >> > $ ./tools/buildman/buildman --keep-outputs --reproducible-builds -dvel > >> > --force-build -PEWM --output /tmp/am62x_beagleplay_r5 --board > >> > am62x_beagleplay_r5 > >> > Building current source for 1 boards (1 thread, 12 jobs per thread) > >> >arm: + am62x_beagleplay_r5 > >> > +(am62x_beagleplay_r5) Image 'tiboot3-am62x-gp-evm.bin' is missing > >> > optional external blobs but is still functional: ti-fs-gp.bin > >> > +(am62x_beagleplay_r5) > >> > +(am62x_beagleplay_r5) /binman/tiboot3-am62x-gp-evm.bin/ti-fs-gp.bin > >> > (ti-sysfw/ti-fs-firmware-am62x-gp.bin): > >> > +(am62x_beagleplay_r5)Missing blob > >> > +(am62x_beagleplay_r5) binman: object of type 'NoneType' has no len() > >> > +(am62x_beagleplay_r5) make[1]: *** [Makefile:1126: .binman_stamp] Error > >> > 1 > >> > +(am62x_beagleplay_r5) make: *** [Makefile:177: sub-make] Error 2 > >> > 001 /1 am62x_beagleplay_r5 > >> > >> Tom, this is failing in the CI container because the container is missing > >> the mkeficapsule tool. > >> > >> To solve this, we just need to add it to the CI container. > >> > >> My understanding of binman's handling of missing bintools is that it should > >> gracefully continue with fake data, so that buildman can successfully test > >> out builds for boards even when you don't have all the required bintools. > >> If I have that correct, I can also create a patch to properly handle this > >> when using mkeficapsule. But I want to verify this is the desired behavior, > >> since mkeficapsule isn't a unique or vendor specific tool, so shouldn't we > >> require it as part of the U-Boot build environment and err out if it is > >> missing? > > > > Perhaps it's a binman issue since we build mkeficapsule or at least > > should be? Neha? > > > > Never mind - I figured it out. > > The mkeficapsule tools is built by u-boot if TOOLS_MKEFICAPSULE config is > set. I didn't explicitly set it because it is implied by > EFI_CAPSULE_ON_DISK config. But this is only set for the A core u-boot, as > that is what would apply the capsules. SPL running on the R cores does not > need this. But that then means that the R core u-boot builds don't have > TOOLS_MKEFICAPSULE set and if that is all that is being built (as in the > case of buildman), the mkeficapsule tool isn't built and so is missing. > > So I need to explicitly set TOOLS_MKEFICAPSULE in the R core defconfigs. > I'll repost the patches. Interesting. My next thought here is that whatever symbol is allowing for "make a capsule" should be select'ing TOOLS_MKEFICAPSULE and so the current logic is a bit flawed. I'm just not sure off-hand where it should be instead, do you have some ideas now? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH 11/15] cmd: bdinfo: enable -e when CONFIG_CMD_NET_LWIP=y
On Wed, May 22, 2024 at 06:00:11PM +0200, Jerome Forissier wrote: > Support "bdinfo -e" when lwIP is selected. > > Signed-off-by: Jerome Forissier Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 15/42] mmc: dw_mmc: Improve coding style
Hi Sam, On 5/23/24 1:31 AM, Sam Protsenko wrote: Fix most of checkpatch warnings and other obvious style issues. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH v2] ARM: imx: verdin-imx8mm: Set CAN oscillator frequency based on model
On Wed, May 22, 2024 at 03:23:51PM +0200, Marek Vasut wrote:
> On 5/22/24 8:39 AM, Francesco Dolcini wrote:
> > > diff --git a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
> > > b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
> > > index 55c02653da6..ef632d95f0a 100644
> > > --- a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
> > > +++ b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
> > > @@ -125,6 +125,36 @@ int board_phys_sdram_size(phys_size_t *size)
> > > #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
> > > int ft_board_setup(void *blob, struct bd_info *bd)
> > > {
> > > + const char *canoscpath = "/oscillator";
> > > + int freq = 4000;/* 40 MHz is used on most variants */
> > > + int canoscoff, ret;
> > > +
> > > + canoscoff = fdt_path_offset(blob, canoscpath);
> > > + if (canoscoff < 0) /* No CAN oscillator found. */
> > > + goto exit;
> > > +
> > > + /*
> > > + * The actual "prodid" (PID4 in Toradex naming) that have the CAN
> > > + * functionality are 0055 and 0059. Special case 20 MHz variant
> > > + * here:
> > > + * - 0055, V1.1A, V1.1B, V1.1C and V1.1D, use a 20MHz oscillator
> > > + * - 0059, V1.1A and V1.1B, use a 20MHz oscillator
> > > + */
> >
> > Any reason why you ignored my suggestion here? The variants you list
> > here are the only one with a 20MHz oscillator, and this is correct.
> >
> > What is not correct is that 0055/0059 are the only variant with CAN
> > functionality. We have other "prodid" with CAN functionality.
> >
> > With that said, the code is correct, thanks. I appreciate you taking care
> > of this.
>
> So ... what should I change for V3 ?
>
> Maybe just create me a diff I can squash into the patch before resend ? (I
> think I am a bit confused, I thought I addressed all the V1 feedback)
Sorry for the confusion, here the diff.
With that please add
Reviewed-by: Francesco Dolcini
diff --git a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
index ef632d95f0a5..59cc28f652f1 100644
--- a/board/toradex/verdin-imx8mm/verdin-imx8mm.c
+++ b/board/toradex/verdin-imx8mm/verdin-imx8mm.c
@@ -134,11 +134,10 @@ int ft_board_setup(void *blob, struct bd_info *bd)
goto exit;
/*
-* The actual "prodid" (PID4 in Toradex naming) that have the CAN
-* functionality are 0055 and 0059. Special case 20 MHz variant
-* here:
-* - 0055, V1.1A, V1.1B, V1.1C and V1.1D, use a 20MHz oscillator
-* - 0059, V1.1A and V1.1B, use a 20MHz oscillator
+* The followings "prodid" (PID4 in Toradex naming) use
+* a 20MHz CAN oscillator:
+* - 0055, V1.1A, V1.1B, V1.1C and V1.1D
+* - 0059, V1.1A and V1.1B
*/
if ((tdx_hw_tag.ver_major == 1 && tdx_hw_tag.ver_minor == 1) &&
((tdx_hw_tag.prodid == VERDIN_IMX8MMQ_IT &&
Re: [PATCH 14/42] mmc: dw_mmc: Use CONFIG_IS_ENABLED() to check config options
Hi Sam, On 5/23/24 1:31 AM, Sam Protsenko wrote: Use CONFIG_IS_ENABLED() macro to check config options as recommended by checkpatch, instead of checking those with just #ifdef CONFIG_... No functional change. There are actual functional changes in here. defined(CONFIG_DM_MMC) != CONFIG_IS_ENABLED(DM_MMC) Currently, if one has SPL_MMC and MMC_DW_ROCKCHIP defined, it'll build the SPL variant of MMC_DW_ROCKCHIP but guarding only with the U-Boot proper symbols, meaning, essentially the SPL and proper variant of rockchip_dw_mmc.o are more or less identical. I think we can argue this isn't proper and should be fixed. I think we need to migrate all the MMC_DW drivers to use $(SPL_TPL_) in there and create the symbols in Kconfig with the appropriate dependencies. We'll likely also need to modify a bunch of defconfigs or make SPL_MMC_DW_ROCKCHIP default y if MMC_DW_ROCKCHIP for example, so that we don't break current support (it's pretty much expected to have MMC support in SPL). I may have misinterpreted this, so please let me know where I am wrong in my assumptions here, but this does look like more work than just this. Cheers, Quentin
Re: [PATCH 12/15] configs: add qemu_arm64_lwip_defconfig
On Wed, May 22, 2024 at 06:00:12PM +0200, Jerome Forissier wrote: > Add qemu_arm64_lwip_defconfig which was created from > qemu_arm64_defconfig with CONFIG_NET_LWIP enabled. > > Signed-off-by: Jerome Forissier > --- > configs/qemu_arm64_lwip_defconfig | 70 +++ > 1 file changed, 70 insertions(+) > create mode 100644 configs/qemu_arm64_lwip_defconfig > > diff --git a/configs/qemu_arm64_lwip_defconfig > b/configs/qemu_arm64_lwip_defconfig > new file mode 100644 > index 00..c8dadbce37 > --- /dev/null > +++ b/configs/qemu_arm64_lwip_defconfig > @@ -0,0 +1,70 @@ > +CONFIG_ARM=y > +CONFIG_POSITION_INDEPENDENT=y > +CONFIG_ARCH_QEMU=y Setting aside that I would like lwip to default to y, at least in the first few iterations (so that testing is easier), this should be using the #include method rather than duplicating the whole config. -- Tom signature.asc Description: PGP signature
Re: [PATCH 02/15] net-lwip: import lwIP library under lib/lwip
On Wed, May 22, 2024 at 06:00:02PM +0200, Jerome Forissier wrote:
> Import the Lightweight IP (lwIP) library as lib/lwip. The code is built
> when CONFIG_NET_LWIP=y.
>
> The lwIP code was imported with the following commands:
>
> (cd /tmp && git clone https://git.savannah.gnu.org/git/lwip.git -b
> STABLE-2_2_0_RELEASE)
> mkdir -p lib/lwip
> cp -R /tmp/lwip/src/{api,core,include} lib/lwip/
> mkdir -p lib/lwip/netif && cp /tmp/lwip/src/netif/ethernet.c lib/lwip/netif/
> mkdir -p lib/lwip/apps/tftp && cp /tmp/lwip/src/apps/tftp/tftp.c
> lib/lwip/apps/tftp/
> mkdir -p lib/lwip/apps/http && cp /tmp/lwip/src/apps/http/http_client.c
> lib/lwip/apps/http/
>
> The list of object files added to lib/liwip/Makefile was given by:
>
> (cd lib/lwip && find . -name \*.c | sort | sed 's@\./@\t@' | sed 's/\.c$/.o
> \\/') >>lib/liwip/Makefile
>
> These files are adaptation layers written specially for U-Boot:
>
> lib/lwip/u-boot/arch/cc.h
> lib/lwip/u-boot/arch/sys_arch.h (empty)
> lib/lwip/u-boot/limits.h (empty)
> lib/lwip/u-boot/lwipopts.h
>
> They were initially contributed by Maxim in a previous RFC patch series.
>
> Signed-off-by: Jerome Forissier
> Co-developed-by: Maxim Uvarov
> Cc: Maxim Uvarov
As I believe I've said before, this needs to be a subtree moving
forward.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 09/42] mmc: dw_mmc: Extract setting the DMA descriptor into a separate routine
Hi Sam, On 5/23/24 1:31 AM, Sam Protsenko wrote: Make dwmci_prepare_data() function easier to read by extracting the preparation of IDMAC descriptor into a dedicated function. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 08/42] mmc: dw_mmc: Extract DMA transfer handling code into a separate routine
Hi Sam, On 5/23/24 1:31 AM, Sam Protsenko wrote: Make dwmci_send_cmd() easier to read by moving the DMA transfer handling code into a dedicated function. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 05/42] mmc: dw_mmc: Extract FIFO init into a separate routine
Hi Sam, On 5/23/24 1:30 AM, Sam Protsenko wrote: Move FIFO threshold initialization into a separate function to make dwmci_init() more readable. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 04/42] mmc: dw_mmc: Extract waiting for data busy into a separate routine
Hi Sam, On 5/23/24 1:30 AM, Sam Protsenko wrote: Waiting for data busy is a logically separate operation and should be implemented as a separate routine. Follow Linux kernel example and extract it from dwmci_send_cmd(). This way it doesn't clutter dwmci_send_cmd() function, and can be reused later in other cases. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 03/42] mmc: dw_mmc: Move struct idmac to dw_mmc.c
Hi Sam, On 5/23/24 1:30 AM, Sam Protsenko wrote: struct idmac is only used in dw_mmc.c, so move it there from dwmmc.h to avoid cluttering the interface in the header. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 02/42] mmc: dw_mmc: Remove unused version field from struct dwmci_host
Hi Sam, On 5/23/24 1:30 AM, Sam Protsenko wrote: Nobody seems to use it, so just remove it. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 01/42] mmc: dw_mmc: Remove common.h
Hi Sam, On 5/23/24 1:30 AM, Sam Protsenko wrote: common.h header is marked for removal treewide and shouldn't be used. Remove it from DW MMC driver. No functional change. Signed-off-by: Sam Protsenko Reviewed-by: Quentin Schulz Thanks, Quentin
Re: [PATCH 06/42] mmc: dw_mmc: Extract clock on/off code into a separate routine
Hi Sam,
On 5/23/24 1:30 AM, Sam Protsenko wrote:
Extract clock control code into a separate routine to avoid code
duplication in dwmci_setup_bus().
No functional change.
There are some differences though.
Signed-off-by: Sam Protsenko
---
drivers/mmc/dw_mmc.c | 60
1 file changed, 33 insertions(+), 27 deletions(-)
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index cbfb8d3b8683..40b9b034f793 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -412,11 +412,33 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
return ret;
}
-static int dwmci_setup_bus(struct dwmci_host *host, u32 freq)
+static int dwmci_control_clken(struct dwmci_host *host, bool on)
{
- u32 div, status;
+ const u32 val = on ? DWMCI_CLKEN_ENABLE | DWMCI_CLKEN_LOW_PWR : 0;
+ const u32 cmd_only_clk = DWMCI_CMD_PRV_DAT_WAIT | DWMCI_CMD_UPD_CLK;
int timeout = 1;
+ u32 status;
+
+ dwmci_writel(host, DWMCI_CLKENA, val);
+
+ /* Inform CIU */
+ dwmci_writel(host, DWMCI_CMD, DWMCI_CMD_START | cmd_only_clk);
+ do {
+ status = dwmci_readl(host, DWMCI_CMD);
+ if (timeout-- < 0) {
+ debug("%s: Timeout!\n", __func__);
+ return -ETIMEDOUT;
+ }
+ } while (status & DWMCI_CMD_START);
+
+ return 0;
+}
+
+static int dwmci_setup_bus(struct dwmci_host *host, u32 freq)
+{
+ u32 div;
unsigned long sclk;
+ int ret;
if ((freq == host->clock) || (freq == 0))
return 0;
@@ -439,35 +461,19 @@ static int dwmci_setup_bus(struct dwmci_host *host, u32
freq)
else
div = DIV_ROUND_UP(sclk, 2 * freq);
- dwmci_writel(host, DWMCI_CLKENA, 0);
+ /* Disable clock */
dwmci_writel(host, DWMCI_CLKSRC, 0);
+ ret = dwmci_control_clken(host, false);
Here, CLKENA and CLKSRC are swapped. The kernel still calls CLKENA
before CLKSRC, is this really safe? (I have no documentation so cannot
tell). E.g., we could have CLKSRC register be a way to select the clock
parent/source, 0 could be 24MHz crystal for example, so switching to
this new parent before disabling the clock output would likely result in
glitches?
+ if (ret)
+ return ret;
+ /* Set clock to desired speed */
dwmci_writel(host, DWMCI_CLKDIV, div);
Same here, CLKDIV is set now after the CIU is informed, is this an
issue? We may want to set the clock speed before we enable the clock
again. Right now it's setting the desired speed while disabled, inform
the CIU, enable the clock, inform the CIU. This now does, disable the
clock, inform the CIU, set the desired speed, enable the clock, inform
the CIU. We may need to wait for the clock to stabilize before enabling
it? Again, just making guesses, no documentation for me here :/
- dwmci_writel(host, DWMCI_CMD, DWMCI_CMD_PRV_DAT_WAIT |
- DWMCI_CMD_UPD_CLK | DWMCI_CMD_START);
- do {
- status = dwmci_readl(host, DWMCI_CMD);
- if (timeout-- < 0) {
- debug("%s: Timeout!\n", __func__);
- return -ETIMEDOUT;
- }
- } while (status & DWMCI_CMD_START);
-
- dwmci_writel(host, DWMCI_CLKENA, DWMCI_CLKEN_ENABLE |
- DWMCI_CLKEN_LOW_PWR);
-
- dwmci_writel(host, DWMCI_CMD, DWMCI_CMD_PRV_DAT_WAIT |
- DWMCI_CMD_UPD_CLK | DWMCI_CMD_START);
-
- timeout = 1;
- do {
- status = dwmci_readl(host, DWMCI_CMD);
- if (timeout-- < 0) {
- debug("%s: Timeout!\n", __func__);
- return -ETIMEDOUT;
- }
- } while (status & DWMCI_CMD_START);
+ /* Enable clock */
+ ret = dwmci_control_clken(host, true);
+ if (ret)
+ return ret;
host->clock = freq;
Cheers,
Quentin
Re: [PATCH 09/15] net-lwip: add support for EFI_HTTP_BOOT
On 5/22/24 20:19, Ilias Apalodimas wrote:
> Hi Jerome,
>
> On Wed, 22 May 2024 at 19:04, Jerome Forissier
> wrote:
>>
>> Implement the wget_with_dns() function which is needed by
>> CONFIG_EFI_HTTP_BOOT=y. Note that there is no dependency added on
>> CONFIG_CMD_DNS_LWIP because CONFIG_CMD_WGET_LWIP natively supports
>> hostname resolution.
>>
>> Signed-off-by: Jerome Forissier
>> ---
>> lib/efi_loader/Kconfig | 5 +++--
>> net-lwip/wget.c| 16
>> 2 files changed, 19 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
>> index 430bb7f0f7..9d8dc8c756 100644
>> --- a/lib/efi_loader/Kconfig
>> +++ b/lib/efi_loader/Kconfig
>> @@ -505,8 +505,9 @@ config EFI_RISCV_BOOT_PROTOCOL
>>
>> config EFI_HTTP_BOOT
>> bool "EFI HTTP Boot support"
>> - select CMD_DNS
>> - select CMD_WGET
>> + select CMD_DNS if NET
>> + select CMD_WGET if NET
>> + select CMD_WGET_LWIP if NET_LWIP
>> select BLKMAP
>> help
>> Enabling this option adds EFI HTTP Boot support. It allows to
>> diff --git a/net-lwip/wget.c b/net-lwip/wget.c
>> index 0ed8b77c47..a3e65dc80e 100644
>> --- a/net-lwip/wget.c
>> +++ b/net-lwip/wget.c
>> @@ -166,3 +166,19 @@ int do_wget(struct cmd_tbl *cmdtp, int flag, int argc,
>> char * const argv[])
>>
>> return CMD_RET_FAILURE;
>> }
>> +
>> +#if defined(CONFIG_EFI_HTTP_BOOT)
>> +int wget_with_dns(ulong dst_addr, char *uri)
>> +{
>> + char addr_str[11];
>> + struct cmd_tbl cmdtp = {};
>> + char *argv[] = { "wget", addr_str, uri };
>> +
>> + snprintf(addr_str, sizeof(addr_str), "0x%lx", dst_addr);
>> +
>> + if (do_wget(, 0, ARRAY_SIZE(argv), argv) == CMD_RET_SUCCESS)
>> + return 0;
>> +
>
> Calling a command directly feels a bit weird.
> Can we do this instead:
> - Split do_wget in patch #7 and carve out 2 functions. The first will
> prepare the arguments and the second will call httpc_get_file_dns()
> and run the loop
> - Once that's split you can use the newly split function here and
> avoid calling a command
Addressed in next version. I have implemented wget_with_dns() in patch #7
to that #9 doesn't need to add any code. And do_wget() simply calls
wget_with_dns().
Thanks.
--
Jerome
>
> Thanks
> /Ilias
>> + return -1;
>> +}
>> +#endif
>> --
>> 2.40.1
>>
Re: [PATCH 10/15] test: dm: dsa, eth: disable tests when CONFIG_NET_LWIP=y
On Wed, 22 May 2024 at 19:08, Ilias Apalodimas
wrote:
>
> Hi Jerome,
>
> On Wed, 22 May 2024 at 19:04, Jerome Forissier
> wrote:
> >
> > Some sandbox tests make strong assumptions on how the network stack is
> > implemented. For example, the ping tests assume that ARP resolution
> > occurs upon sending out the ICMP packet. This is not always the case
> > with the lwIP stack which can cache ARP information.
> > Therefore, disable these tests when CONFIG_NET_LWIP is enabled.
>
> Is the ARP Caching the only issue?
> U-Boot isn't supposed to use the network stack that much, so it might
> be a better idea to disable arp-caching in LWIP (assuming it's
> doable). We might even get a few size of bytes back
You end up hitting an arp cache a lot because of references to say
DNS, IP GW or server end point for downloading, so while at first it
doesn't appear you'd need it you also don't want to do ARP for every
packet sent.
Peter
> Cheers
> /Ilias
> >
> > Signed-off-by: Jerome Forissier
> > ---
> > test/dm/dsa.c | 2 ++
> > test/dm/eth.c | 4
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/test/dm/dsa.c b/test/dm/dsa.c
> > index c857106eaf..147e2a4afe 100644
> > --- a/test/dm/dsa.c
> > +++ b/test/dm/dsa.c
> > @@ -59,6 +59,7 @@ static int dm_test_dsa_probe(struct unit_test_state *uts)
> >
> > DM_TEST(dm_test_dsa_probe, UT_TESTF_SCAN_FDT);
> >
> > +#if !defined(CONFIG_NET_LWIP)
> > /* This test sends ping requests with the local address through each DSA
> > port
> > * via the sandbox DSA master Eth.
> > */
> > @@ -80,3 +81,4 @@ static int dm_test_dsa(struct unit_test_state *uts)
> > }
> >
> > DM_TEST(dm_test_dsa, UT_TESTF_SCAN_FDT);
> > +#endif /* !defined(CONFIG_NET_LWIP) */
> > diff --git a/test/dm/eth.c b/test/dm/eth.c
> > index bb3dcc6b95..cf97b1c1ab 100644
> > --- a/test/dm/eth.c
> > +++ b/test/dm/eth.c
> > @@ -170,6 +170,7 @@ static int dm_test_ip6_make_lladdr(struct
> > unit_test_state *uts)
> > DM_TEST(dm_test_ip6_make_lladdr, UT_TESTF_SCAN_FDT);
> > #endif
> >
> > +#if !defined(CONFIG_NET_LWIP)
> > static int dm_test_eth(struct unit_test_state *uts)
> > {
> > net_ping_ip = string_to_ip("1.1.2.2");
> > @@ -298,6 +299,7 @@ static int dm_test_eth_act(struct unit_test_state *uts)
> > return 0;
> > }
> > DM_TEST(dm_test_eth_act, UT_TESTF_SCAN_FDT);
> > +#endif /* !CONFIG_NET_LWIP */
> >
> > /* Ensure that all addresses are loaded properly */
> > static int dm_test_ethaddr(struct unit_test_state *uts)
> > @@ -332,6 +334,7 @@ static int dm_test_ethaddr(struct unit_test_state *uts)
> > }
> > DM_TEST(dm_test_ethaddr, UT_TESTF_SCAN_FDT);
> >
> > +#if !defined(CONFIG_NET_LWIP)
> > /* The asserts include a return on fail; cleanup in the caller */
> > static int _dm_test_eth_rotate1(struct unit_test_state *uts)
> > {
> > @@ -616,6 +619,7 @@ static int dm_test_eth_async_ping_reply(struct
> > unit_test_state *uts)
> > }
> >
> > DM_TEST(dm_test_eth_async_ping_reply, UT_TESTF_SCAN_FDT);
> > +#endif /* !CONFIG_NET_LWIP */
> >
> > #if IS_ENABLED(CONFIG_IPV6_ROUTER_DISCOVERY)
> >
> > --
> > 2.40.1
> >
Re: [PATCH v2 0/6] Introduce UBI block device
On Thu, May 23, 2024 at 12:51:33PM +0200, Michael Nazzareno Trimarchi wrote: > Hi > > We queue them this afternoon Thank you. I also wanted to remind you that there is still a similiar patchest with mtdblock support (https://lore.kernel.org/all/20240506135607.aprjqn7uyng2jgp5@cab-wsm-0029881/) that should be applied to bracnh before this. > > Michael > > On Thu, May 23, 2024 at 12:49 PM Alexey Romanov > wrote: > > > > > > Hi Michael, > > > > On Mon, May 06, 2024 at 03:59:52PM +0200, Michael Nazzareno Trimarchi wrote: > > > Hi Alexey > > > > > > Sorry will will put on CI > > > > Any news? > > > > > > > > Michael > > > > > > On Mon, May 6, 2024 at 3:58 PM Alexey Romanov > > > wrote: > > > > > > > > Hello! Ping. > > > > > > > > On Mon, Mar 25, 2024 at 05:41:42PM +0300, Alexey Romanov wrote: > > > > > Hello! > > > > > > > > > > This series adds support for the UBI block device, which > > > > > allows to read/write data block by block. For example, > > > > > it can now be used for BCB or Android AB command: > > > > > > > > > > $ bcb load ubi 0 part_name > > > > > > > > > > Tested only on SPI NAND, so bind is made only for > > > > > SPI NAND drivers. Can be used with mtdblock device [1]. > > > > > > > > > > --- > > > > > > > > > > Changes V1 -> V2 [2]: > > > > > > > > > > - Rebased over mtdblock v2 patchset [3]. > > > > > - Compile UBI partitions support only if CONFIG_BLK option > > > > >is enabled. > > > > > > > > > > - Links: > > > > > > > > > > [1] > > > > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > > > > [2] > > > > > https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/ > > > > > [3] > > > > > https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/ > > > > > > > > > > Alexey Romanov (6): > > > > > ubi: allow to read from volume with offset > > > > > ubi: allow to write to volume with offset > > > > > drivers: introduce UBI block abstraction > > > > > disk: don't try search for partition type if already set > > > > > disk: support UBI partitions > > > > > spinand: bind UBI block > > > > > > > > > > cmd/ubi.c | 77 +++-- > > > > > disk/part.c | 7 ++ > > > > > drivers/block/blk-uclass.c | 1 + > > > > > drivers/mtd/nand/spi/core.c | 8 ++- > > > > > drivers/mtd/ubi/Makefile| 1 + > > > > > drivers/mtd/ubi/block.c | 130 > > > > > > > > > > drivers/mtd/ubi/part.c | 99 +++ > > > > > env/ubi.c | 16 ++--- > > > > > include/part.h | 2 + > > > > > include/ubi_uboot.h | 8 ++- > > > > > 10 files changed, 332 insertions(+), 17 deletions(-) > > > > > create mode 100644 drivers/mtd/ubi/block.c > > > > > create mode 100644 drivers/mtd/ubi/part.c > > > > > > > > > > -- > > > > > 2.34.1 > > > > > > > > > > > > > -- > > > > Thank you, > > > > Alexey > > > > > > > > > > > > -- > > > Michael Nazzareno Trimarchi > > > Co-Founder & Chief Executive Officer > > > M. +39 347 913 2170 > > > mich...@amarulasolutions.com > > > __ > > > > > > Amarula Solutions BV > > > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > > > T. +31 (0)85 111 9172 > > > i...@amarulasolutions.com > > > www.amarulasolutions.com > > > > -- > > Thank you, > > Alexey > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > mich...@amarulasolutions.com > __ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com -- Thank you, Alexey
Re: [PATCH v2 0/6] Introduce UBI block device
Hi Michael, On Mon, May 06, 2024 at 03:59:52PM +0200, Michael Nazzareno Trimarchi wrote: > Hi Alexey > > Sorry will will put on CI Any news? > > Michael > > On Mon, May 6, 2024 at 3:58 PM Alexey Romanov > wrote: > > > > Hello! Ping. > > > > On Mon, Mar 25, 2024 at 05:41:42PM +0300, Alexey Romanov wrote: > > > Hello! > > > > > > This series adds support for the UBI block device, which > > > allows to read/write data block by block. For example, > > > it can now be used for BCB or Android AB command: > > > > > > $ bcb load ubi 0 part_name > > > > > > Tested only on SPI NAND, so bind is made only for > > > SPI NAND drivers. Can be used with mtdblock device [1]. > > > > > > --- > > > > > > Changes V1 -> V2 [2]: > > > > > > - Rebased over mtdblock v2 patchset [3]. > > > - Compile UBI partitions support only if CONFIG_BLK option > > >is enabled. > > > > > > - Links: > > > > > > [1] > > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > > [2] > > > https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/ > > > [3] > > > https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/ > > > > > > Alexey Romanov (6): > > > ubi: allow to read from volume with offset > > > ubi: allow to write to volume with offset > > > drivers: introduce UBI block abstraction > > > disk: don't try search for partition type if already set > > > disk: support UBI partitions > > > spinand: bind UBI block > > > > > > cmd/ubi.c | 77 +++-- > > > disk/part.c | 7 ++ > > > drivers/block/blk-uclass.c | 1 + > > > drivers/mtd/nand/spi/core.c | 8 ++- > > > drivers/mtd/ubi/Makefile| 1 + > > > drivers/mtd/ubi/block.c | 130 > > > drivers/mtd/ubi/part.c | 99 +++ > > > env/ubi.c | 16 ++--- > > > include/part.h | 2 + > > > include/ubi_uboot.h | 8 ++- > > > 10 files changed, 332 insertions(+), 17 deletions(-) > > > create mode 100644 drivers/mtd/ubi/block.c > > > create mode 100644 drivers/mtd/ubi/part.c > > > > > > -- > > > 2.34.1 > > > > > > > -- > > Thank you, > > Alexey > > > > -- > Michael Nazzareno Trimarchi > Co-Founder & Chief Executive Officer > M. +39 347 913 2170 > mich...@amarulasolutions.com > __ > > Amarula Solutions BV > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > T. +31 (0)85 111 9172 > i...@amarulasolutions.com > www.amarulasolutions.com -- Thank you, Alexey
Re: [PATCH v2] arm: dts: k3-j7200: Move to OF_UPSTREAM
On Tue, 21 May 2024 at 11:18, Aniket Limaye wrote:
>
> Move to using OF_UPSTREAM config and thus using the devicetree-rebasing
> subtree.
>
> Signed-off-by: Aniket Limaye
> ---
>
> Boot logs:
> https://gist.github.com/aniket-l/aab91bb12d2495c54da094fca49c369f
>
> Changes in v2:
> - Rebased to next
> - Removed dependency on binman templating series [1] as per [2]
>
> [1]: https://lore.kernel.org/all/20240322131011.1029620-1-n-fran...@ti.com/
> [2]: https://lore.kernel.org/u-boot/20240520095916.1809962-1-n-fran...@ti.com/
>
> ---
> arch/arm/dts/Makefile |1 -
> arch/arm/dts/k3-j7200-binman.dtsi |2 +-
> .../k3-j7200-common-proc-board-u-boot.dtsi| 14 +-
> arch/arm/dts/k3-j7200-common-proc-board.dts | 396 -
> arch/arm/dts/k3-j7200-main.dtsi | 1284 -
> arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 647 -
> arch/arm/dts/k3-j7200-som-p0.dtsi | 327 -
> arch/arm/dts/k3-j7200-thermal.dtsi| 47 -
> arch/arm/dts/k3-j7200.dtsi| 164 ---
> configs/j7200_evm_a72_defconfig |3 +-
> 10 files changed, 8 insertions(+), 2877 deletions(-)
> delete mode 100644 arch/arm/dts/k3-j7200-common-proc-board.dts
> delete mode 100644 arch/arm/dts/k3-j7200-main.dtsi
> delete mode 100644 arch/arm/dts/k3-j7200-mcu-wakeup.dtsi
> delete mode 100644 arch/arm/dts/k3-j7200-som-p0.dtsi
> delete mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
> delete mode 100644 arch/arm/dts/k3-j7200.dtsi
>
Acked-by: Sumit Garg
-Sumit
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f7032f1e175..ea8fee8e25c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1194,7 +1194,6 @@ dtb-$(CONFIG_SOC_K3_AM654) += \
>
> dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
> k3-j721e-r5-common-proc-board.dtb \
> - k3-j7200-common-proc-board.dtb \
> k3-j7200-r5-common-proc-board.dtb \
> k3-j721e-sk.dtb \
> k3-j721e-r5-sk.dtb \
> diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
> b/arch/arm/dts/k3-j7200-binman.dtsi
> index 06db8659876..b6e0aa37971 100644
> --- a/arch/arm/dts/k3-j7200-binman.dtsi
> +++ b/arch/arm/dts/k3-j7200-binman.dtsi
> @@ -180,7 +180,7 @@
>
> #ifdef CONFIG_TARGET_J7200_A72_EVM
>
> -#define SPL_J7200_EVM_DTB "spl/dts/k3-j7200-common-proc-board.dtb"
> +#define SPL_J7200_EVM_DTB "spl/dts/ti/k3-j7200-common-proc-board.dtb"
> #define J7200_EVM_DTB "u-boot.dtb"
>
> {
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> index 485f17c5f06..045ef170e17 100644
> --- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
> @@ -26,8 +26,12 @@
> _mcu_wakeup {
> bootph-all;
>
> - chipid@4314 {
> + wkup_conf: bus@4300 {
> bootph-all;
> +
> + chipid: chipid@14 {
> + bootph-all;
> + };
> };
> };
>
> @@ -40,14 +44,6 @@
> };
>
> _udmap {
> - reg = <0x0 0x285c 0x0 0x100>,
> - <0x0 0x284c 0x0 0x4000>,
> - <0x0 0x2a80 0x0 0x4>,
> - <0x0 0x284a 0x0 0x4000>,
> - <0x0 0x2aa0 0x0 0x4>,
> - <0x0 0x2840 0x0 0x2000>;
> - reg-names = "gcfg", "rchan", "rchanrt", "tchan",
> - "tchanrt", "rflow";
> bootph-all;
> };
>
> diff --git a/arch/arm/dts/k3-j7200-common-proc-board.dts
> b/arch/arm/dts/k3-j7200-common-proc-board.dts
> deleted file mode 100644
> index cee2b4b0eb8..000
> --- a/arch/arm/dts/k3-j7200-common-proc-board.dts
> +++ /dev/null
> @@ -1,396 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0
> -/*
> - * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
> - */
> -
> -/dts-v1/;
> -
> -#include "k3-j7200-som-p0.dtsi"
> -#include
> -#include
> -#include
> -
> -#include "k3-serdes.h"
> -
> -/ {
> - compatible = "ti,j7200-evm", "ti,j7200";
> - model = "Texas Instruments J7200 EVM";
> -
> - aliases {
> - serial0 = _uart0;
> - serial1 = _uart0;
> - serial2 = _uart0;
> - serial3 = _uart1;
> - serial5 = _uart3;
> - mmc0 = _sdhci0;
> - mmc1 = _sdhci1;
> - };
> -
> - chosen {
> - stdout-path = "serial2:115200n8";
> - };
> -
> - evm_12v0: fixedregulator-evm12v0 {
> - /* main supply */
> - compatible = "regulator-fixed";
> - regulator-name = "evm_12v0";
> - regulator-min-microvolt = <1200>;
> - regulator-max-microvolt = <1200>;
> - regulator-always-on;
> -
Re: [PATCH v2 0/6] Introduce UBI block device
Hi We queue them this afternoon Michael On Thu, May 23, 2024 at 12:49 PM Alexey Romanov wrote: > > > Hi Michael, > > On Mon, May 06, 2024 at 03:59:52PM +0200, Michael Nazzareno Trimarchi wrote: > > Hi Alexey > > > > Sorry will will put on CI > > Any news? > > > > > Michael > > > > On Mon, May 6, 2024 at 3:58 PM Alexey Romanov > > wrote: > > > > > > Hello! Ping. > > > > > > On Mon, Mar 25, 2024 at 05:41:42PM +0300, Alexey Romanov wrote: > > > > Hello! > > > > > > > > This series adds support for the UBI block device, which > > > > allows to read/write data block by block. For example, > > > > it can now be used for BCB or Android AB command: > > > > > > > > $ bcb load ubi 0 part_name > > > > > > > > Tested only on SPI NAND, so bind is made only for > > > > SPI NAND drivers. Can be used with mtdblock device [1]. > > > > > > > > --- > > > > > > > > Changes V1 -> V2 [2]: > > > > > > > > - Rebased over mtdblock v2 patchset [3]. > > > > - Compile UBI partitions support only if CONFIG_BLK option > > > >is enabled. > > > > > > > > - Links: > > > > > > > > [1] > > > > https://lore.kernel.org/all/20240227100441.1811047-1-avroma...@salutedevices.com/ > > > > [2] > > > > https://lore.kernel.org/all/20240306134906.1179285-1-avroma...@salutedevices.com/ > > > > [3] > > > > https://lore.kernel.org/all/20240307130726.1582487-1-avroma...@salutedevices.com/ > > > > > > > > Alexey Romanov (6): > > > > ubi: allow to read from volume with offset > > > > ubi: allow to write to volume with offset > > > > drivers: introduce UBI block abstraction > > > > disk: don't try search for partition type if already set > > > > disk: support UBI partitions > > > > spinand: bind UBI block > > > > > > > > cmd/ubi.c | 77 +++-- > > > > disk/part.c | 7 ++ > > > > drivers/block/blk-uclass.c | 1 + > > > > drivers/mtd/nand/spi/core.c | 8 ++- > > > > drivers/mtd/ubi/Makefile| 1 + > > > > drivers/mtd/ubi/block.c | 130 > > > > drivers/mtd/ubi/part.c | 99 +++ > > > > env/ubi.c | 16 ++--- > > > > include/part.h | 2 + > > > > include/ubi_uboot.h | 8 ++- > > > > 10 files changed, 332 insertions(+), 17 deletions(-) > > > > create mode 100644 drivers/mtd/ubi/block.c > > > > create mode 100644 drivers/mtd/ubi/part.c > > > > > > > > -- > > > > 2.34.1 > > > > > > > > > > -- > > > Thank you, > > > Alexey > > > > > > > > -- > > Michael Nazzareno Trimarchi > > Co-Founder & Chief Executive Officer > > M. +39 347 913 2170 > > mich...@amarulasolutions.com > > __ > > > > Amarula Solutions BV > > Joop Geesinkweg 125, 1114 AB, Amsterdam, NL > > T. +31 (0)85 111 9172 > > i...@amarulasolutions.com > > www.amarulasolutions.com > > -- > Thank you, > Alexey -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 mich...@amarulasolutions.com __ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 i...@amarulasolutions.com www.amarulasolutions.com
[PATCH] image: Set load_end on partial loads
When decompressing, it's possible that the algorithm only performs
a partial decompression.
This usually happens when CONFIG_SYS_BOOTM_LEN is too small for
the uncompressed image.
When that happens, image_decomp() returns an error and *load_end == load.
The error is then handled by handle_decomp_error().
handle_decomp_error() expects the number of uncompressed bytes in
uncomp_size but receives *load_end - load == load - load == 0.
Because of this, handle_decomp_error does not report the expected
"Image too large: increase CONFIG_SYS_BOOTM_LEN" error message.
Modify the image_decomp() logic to always report the decompressed size,
even when a partial decompression happened.
Signed-off-by: Mattijs Korpershoek
---
This has been tested on an AM62X SK EVM board with a big lz4 image and
the default CONFIG_SYS_BOOTM_LEN of 0x80.
This has also been tested on sandbox using:
=> ut compression
---
boot/image.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/boot/image.c b/boot/image.c
index 073931cd7a3f..4f48e6eb563d 100644
--- a/boot/image.c
+++ b/boot/image.c
@@ -531,10 +531,10 @@ int image_decomp(int comp, ulong load, ulong image_start,
int type,
printf("Unimplemented compression type %d\n", comp);
return ret;
}
- if (ret)
- return ret;
*load_end = load + image_len;
+ if (ret)
+ return ret;
return 0;
}
---
base-commit: a7f0154c412859323396111dd0c09dbafbc153cb
change-id: 20240523-image-partial-decomp-d6604e998e3a
Best regards,
--
Mattijs Korpershoek
Re: [PATCH v2] board: rockchip: add ArmSoM Sige7 Rk3588 board
On Wed, 22 May 2024 at 23:33, Quentin Schulz wrote: > > Hi Jianfeng Liu, > > On 5/22/24 6:58 PM, Jianfeng Liu wrote: > [...] > > Note that these commits: > > - e18e5e8188f2 (arm64: dts: rockchip: add USBDP phys on rk3588) > > - 6fca4edb93d3 (arm64: dts: rockchip: Add rk3588 GPU node) > > are not synced to u-boot, so I remove usb3 drd nodes and gpu from kernel > > devicetree. > [...]> diff --git > a/dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts > b/dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts > > new file mode 100644 > > index 00..c7b46536ec > > --- /dev/null > > +++ b/dts/upstream/src/arm64/rockchip/rk3588-armsom-sige7.dts > > Sorry, I failed to explain properly what was expected. > > dts/upstream should never be touched except with > dts/update-dts-subtree.sh script. > > Sadly, your board is not supported in v6.9 yet, only in the upcoming > v6.10 :/ > > So we have two options, we keep the dts in arch/arm/dts/ like you used > to do, until we merge v6.10 dts in U-Boot (probably for v2024.10?), or > we cherry-pick the changes for your board with dts/update-dts-subtree.sh > script, see the instructions in the docs Tom has started writing: > https://lore.kernel.org/u-boot/20240517174930.1028063-2-tr...@konsulko.com/. > I would very much like to see someone starting to look into the second > option :) > > However... it seems we'll likely need to also cherry-pick patches for > the GPU (should probably be straightforward as nothing would be using > the GPU anyway in U-Boot) and the USBDP PHY... but this one we would > need to update all -u-boot.dtsi for rk3588(s) boards that have it > already to make it use the new label/DT, make sure that the driver still > works... etc. Maybe not a small feat, but someone will have to do it at > some point anyway :) > > You'd be the first one to do this cherry-picking into dts/upstream, so > it'd be really interesting to us if you could provide feedback on what > is unclear/not working, etc... so we can update the documentation or fix > tools if they were to be insufficient. +1 Although it is very much similar to normal cherry-picking patches, the dts/update-dts-subtree.sh script is just there to hide the git subtree specific details. -Sumit > > Looking forward to your next patch, > Cheers, > Quentin
Re: [PATCH] arm: dts: mvebu: Migrate to upstream DT for Synology DS116 (Armada 385) board
On Thu, 23 May 2024 at 03:22, Tony Dinh wrote:
>
> Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the
> DEFAULT_DEVICE_TREE in DS116 defconfig. Remove current DTS in
> arch/arm/dts/ directory.
>
> Signed-off-by: Tony Dinh
> ---
>
> arch/arm/dts/Makefile | 1 -
> arch/arm/dts/armada-385-synology-ds116.dts | 291 -
> configs/ds116_defconfig| 3 +-
> 3 files changed, 2 insertions(+), 293 deletions(-)
> delete mode 100644 arch/arm/dts/armada-385-synology-ds116.dts
>
Acked-by: Sumit Garg
-Sumit
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index a5c82ebf7a..75f7e616b4 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -155,7 +155,6 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
> armada-385-atl-x530.dtb \
> armada-385-atl-x530DP.dtb \
> armada-385-db-88f6820-amc.dtb \
> - armada-385-synology-ds116.dtb \
> armada-385-thecus-n2350.dtb \
> armada-385-turris-omnia.dtb \
> armada-388-clearfog.dtb \
> diff --git a/arch/arm/dts/armada-385-synology-ds116.dts
> b/arch/arm/dts/armada-385-synology-ds116.dts
> deleted file mode 100644
> index 82a0373f7f..00
> --- a/arch/arm/dts/armada-385-synology-ds116.dts
> +++ /dev/null
> @@ -1,291 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> -/*
> - * Device Tree file for Synology DS116 NAS
> - *
> - * Copyright (C) 2017 Willy Tarreau
> - */
> -
> -/dts-v1/;
> -#include "armada-385.dtsi"
> -#include
> -
> -/ {
> - model = "Synology DS116";
> - compatible = "marvell,a385-gp", "marvell,armada385",
> "marvell,armada380";
> -
> - chosen {
> - stdout-path = "serial0:115200n8";
> - };
> -
> - memory {
> - device_type = "memory";
> - reg = <0x 0x4000>; /* 1 GB */
> - };
> -
> - soc {
> - ranges = - MBUS_ID(0x01, 0x1d) 0 0xfff0 0x10
> - MBUS_ID(0x09, 0x19) 0 0xf110 0x1
> - MBUS_ID(0x09, 0x15) 0 0xf111 0x1
> - MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
> -
> - internal-regs {
> - i2c@11000 {
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins>;
> - status = "okay";
> - clock-frequency = <10>;
> -
> - eeprom@57 {
> - compatible = "atmel,24c64";
> - reg = <0x57>;
> - };
> - };
> -
> - serial@12000 {
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins>;
> - status = "okay";
> - };
> -
> - serial@12100 {
> - /* A PIC16F1829 is connected to uart1 at 9600
> bps,
> -* and takes single-character orders :
> -* "1" : power off // already handled by
> the poweroff node
> -* "2" : short beep
> -* "3" : long beep
> -* "4" : turn the power LED ON
> -* "5" : flash the power LED
> -* "6" : turn the power LED OFF
> -* "7" : turn the status LED OFF
> -* "8" : turn the status LED ON
> -* "9" : flash the status LED
> -* "A" : flash the motherboard LED (D8)
> -* "B" : turn the motherboard LED OFF
> -* "C" : hard reset
> -*/
> - pinctrl-names = "default";
> - pinctrl-0 = <_pins>;
> - status = "okay";
> - };
> -
> - poweroff@12100 {
> - compatible = "synology,power-off";
> - reg = <0x12100 0x100>;
> - clocks = < 0>;
> - };
> -
> - ethernet@7 {
> - pinctrl-names = "default";
> - phy = <>;
> - phy-mode = "sgmii";
> - buffer-manager = <>;
> - bm,pool-long = <0>;
> - status = "okay";
> -
Re: [PATCH v3] abootimg: Add init_boot image support
Hi Roman, Thank you for the patch. On jeu., mai 23, 2024 at 07:06, Roman Stratiienko wrote: > Quote from [1]: > > "For devices launching with Android 13, the generic ramdisk is removed > from the boot image and placed in a separate init_boot image. > This change leaves the boot image with only the GKI kernel." > > While at it, update wrong error handling message when vendor_boot > cannot be loaded. > > [1]: https://source.android.com/docs/core/architecture/partitions/generic-boot > Signed-off-by: Roman Stratiienko > Reviewed-by: Mattijs Korpershoek To confirm, v3 applies without any conflicts. This series was initially assigned to Tom on patchwork, so it's up to him to see when he wants to pick this up. [...]
[PATCH v3] abootimg: Add init_boot image support
Quote from [1]:
"For devices launching with Android 13, the generic ramdisk is removed
from the boot image and placed in a separate init_boot image.
This change leaves the boot image with only the GKI kernel."
While at it, update wrong error handling message when vendor_boot
cannot be loaded.
[1]: https://source.android.com/docs/core/architecture/partitions/generic-boot
Signed-off-by: Roman Stratiienko
Reviewed-by: Mattijs Korpershoek
---
Changes in v2:
- Addressed review comments v1
Changes in v3:
- Rebased on top of latest u-boot/next
boot/image-board.c | 13 ++---
cmd/abootimg.c | 26 +-
include/image.h| 7 +++
3 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/boot/image-board.c b/boot/image-board.c
index b7884b8c5d..f212401304 100644
--- a/boot/image-board.c
+++ b/boot/image-board.c
@@ -406,13 +406,20 @@ static int select_ramdisk(struct bootm_headers *images,
const char *select, u8 a
if (IS_ENABLED(CONFIG_ANDROID_BOOT_IMAGE)) {
int ret;
if (IS_ENABLED(CONFIG_CMD_ABOOTIMG)) {
- void *boot_img =
map_sysmem(get_abootimg_addr(), 0);
+ ulong boot_img = get_abootimg_addr();
+ ulong init_boot_img = get_ainit_bootimg_addr();
void *vendor_boot_img =
map_sysmem(get_avendor_bootimg_addr(), 0);
+ void *ramdisk_img;
- ret = android_image_get_ramdisk(boot_img,
vendor_boot_img,
+ if (init_boot_img == -1)
+ ramdisk_img = map_sysmem(boot_img, 0);
+ else
+ ramdisk_img = map_sysmem(init_boot_img,
0);
+
+ ret = android_image_get_ramdisk(ramdisk_img,
vendor_boot_img,
rd_datap,
rd_lenp);
unmap_sysmem(vendor_boot_img);
- unmap_sysmem(boot_img);
+ unmap_sysmem(ramdisk_img);
} else {
void *ptr = map_sysmem(images->os.start, 0);
diff --git a/cmd/abootimg.c b/cmd/abootimg.c
index 88c77d9992..327712a536 100644
--- a/cmd/abootimg.c
+++ b/cmd/abootimg.c
@@ -14,6 +14,7 @@
/* Please use abootimg_addr() macro to obtain the boot image address */
static ulong _abootimg_addr = -1;
+static ulong _ainit_bootimg_addr = -1;
static ulong _avendor_bootimg_addr = -1;
ulong get_abootimg_addr(void)
@@ -21,6 +22,11 @@ ulong get_abootimg_addr(void)
return (_abootimg_addr == -1 ? image_load_addr : _abootimg_addr);
}
+ulong get_ainit_bootimg_addr(void)
+{
+ return _ainit_bootimg_addr;
+}
+
ulong get_avendor_bootimg_addr(void)
{
return _avendor_bootimg_addr;
@@ -179,7 +185,7 @@ static int do_abootimg_addr(struct cmd_tbl *cmdtp, int
flag, int argc,
char *endp;
ulong img_addr;
- if (argc < 2 || argc > 3)
+ if (argc < 2 || argc > 4)
return CMD_RET_USAGE;
img_addr = hextoul(argv[1], );
@@ -190,16 +196,26 @@ static int do_abootimg_addr(struct cmd_tbl *cmdtp, int
flag, int argc,
_abootimg_addr = img_addr;
- if (argc == 3) {
+ if (argc > 2) {
img_addr = simple_strtoul(argv[2], , 16);
if (*endp != '\0') {
- printf("Error: Wrong vendor image address\n");
+ printf("Error: Wrong vendor_boot image address\n");
return CMD_RET_FAILURE;
}
_avendor_bootimg_addr = img_addr;
}
+ if (argc == 4) {
+ img_addr = simple_strtoul(argv[3], , 16);
+ if (*endp != '\0') {
+ printf("Error: Wrong init_boot image address\n");
+ return CMD_RET_FAILURE;
+ }
+
+ _ainit_bootimg_addr = img_addr;
+ }
+
return CMD_RET_SUCCESS;
}
@@ -243,7 +259,7 @@ static int do_abootimg_dump(struct cmd_tbl *cmdtp, int
flag, int argc,
}
static struct cmd_tbl cmd_abootimg_sub[] = {
- U_BOOT_CMD_MKENT(addr, 3, 1, do_abootimg_addr, "", ""),
+ U_BOOT_CMD_MKENT(addr, 4, 1, do_abootimg_addr, "", ""),
U_BOOT_CMD_MKENT(dump, 2, 1, do_abootimg_dump, "", ""),
U_BOOT_CMD_MKENT(get, 5, 1, do_abootimg_get, "", ""),
};
@@ -271,7 +287,7 @@ static int do_abootimg(struct cmd_tbl *cmdtp, int flag, int
argc,
U_BOOT_CMD(
abootimg, CONFIG_SYS_MAXARGS, 0, do_abootimg,
"manipulate Android Boot Image",
- "addr []>\n"
+ "addr [ []]\n"
"- set the address in RAM where boot image is located\n"
" ($loadaddr is used by default)\n"
"abootimg dump dtb\n"
diff --git
Re: [PATCH v2] abootimg: Add init_boot image support
чт, 23 мая 2024 г. в 09:41, Mattijs Korpershoek :
>
> Hi Roman,
>
> Thank you for the patch.
>
> On mer., mai 22, 2024 at 21:26, Roman Stratiienko
> wrote:
>
> > Quote from [1]:
> >
> > "For devices launching with Android 13, the generic ramdisk is removed
> > from the boot image and placed in a separate init_boot image.
> > This change leaves the boot image with only the GKI kernel."
> >
> > While at it, update wrong error handling message when vendor_boot
> > cannot be loaded.
> >
> > [1]:
> > https://source.android.com/docs/core/architecture/partitions/generic-boot
> > Signed-off-by: Roman Stratiienko
>
> Reviewed-by: Mattijs Korpershoek
>
> Note: this patch still does not apply on master nor next:
>
> $ ~/work/upstream/u-boot/ git show --pretty='%h ("%s")' HEAD --no-patch
> a7f0154c4128 ("Prepare v2024.07-rc3")
>
> $ ~/work/upstream/u-boot/ b4 shazam -s -l
> 20240522212645.87250-1-r.stratiie...@gmail.com
>
> [...]
>
> Total patches: 1
> ---
> Applying: abootimg: Add init_boot image support
> Patch failed at 0001 abootimg: Add init_boot image support
> error: sha1 information is lacking or useless (cmd/abootimg.c).
> error: could not build fake ancestor
> hint: Use 'git am --show-current-patch=diff' to see the failed patch
> hint: When you have resolved this problem, run "git am --continue".
> hint: If you prefer to skip this patch, run "git am --skip" instead.
> hint: To restore the original branch and stop patching, run "git am --abort".
> hint: Disable this message with "git config advice.mergeConflict false"
>
> - master: a7f0154c4128 ("Prepare v2024.07-rc3")
> - next: 377e91c162ab ("Merge patch series "Clean-up patch set for MbedTLS
> integration"")
>
> Looking further down below, we can see that this patch has the "abootimg
> load" command, which is introduced in these series:
> https://lore.kernel.org/r/20240519191856.2582174-1-r.stratiie...@gmail.com
>
> Please consider rebasing on either master or next before sending.
Ahh. I see. Sorry for the inconvenience. I will rebase and send v3.
>
>
> > ---
> > boot/image-board.c | 13 ++---
> > cmd/abootimg.c | 26 +-
> > include/image.h| 7 +++
> > 3 files changed, 38 insertions(+), 8 deletions(-)
>
> [...]
>
> >
> >
> > static struct cmd_tbl cmd_abootimg_sub[] = {
> > - U_BOOT_CMD_MKENT(addr, 3, 1, do_abootimg_addr, "", ""),
> > + U_BOOT_CMD_MKENT(addr, 4, 1, do_abootimg_addr, "", ""),
> > U_BOOT_CMD_MKENT(dump, 2, 1, do_abootimg_dump, "", ""),
> > U_BOOT_CMD_MKENT(get, 5, 1, do_abootimg_get, "", ""),
> > U_BOOT_CMD_MKENT(load, 5, 1, do_abootimg_load, "", ""),
> > @@ -376,7 +392,7 @@ static int do_abootimg(struct cmd_tbl *cmdtp, int flag,
> > int argc,
> > U_BOOT_CMD(
> > abootimg, CONFIG_SYS_MAXARGS, 0, do_abootimg,
> > "manipulate Android Boot Image",
> > - "addr []>\n"
> > + "addr [
> > []]\n"
> > "- set the address in RAM where boot image is located\n"
> > " ($loadaddr is used by default)\n"
> > "abootimg dump dtb\n"
>
> [...]
Re: [PATCH v2] abootimg: Add init_boot image support
Hi Roman,
Thank you for the patch.
On mer., mai 22, 2024 at 21:26, Roman Stratiienko
wrote:
> Quote from [1]:
>
> "For devices launching with Android 13, the generic ramdisk is removed
> from the boot image and placed in a separate init_boot image.
> This change leaves the boot image with only the GKI kernel."
>
> While at it, update wrong error handling message when vendor_boot
> cannot be loaded.
>
> [1]: https://source.android.com/docs/core/architecture/partitions/generic-boot
> Signed-off-by: Roman Stratiienko
Reviewed-by: Mattijs Korpershoek
Note: this patch still does not apply on master nor next:
$ ~/work/upstream/u-boot/ git show --pretty='%h ("%s")' HEAD --no-patch
a7f0154c4128 ("Prepare v2024.07-rc3")
$ ~/work/upstream/u-boot/ b4 shazam -s -l
20240522212645.87250-1-r.stratiie...@gmail.com
[...]
Total patches: 1
---
Applying: abootimg: Add init_boot image support
Patch failed at 0001 abootimg: Add init_boot image support
error: sha1 information is lacking or useless (cmd/abootimg.c).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
- master: a7f0154c4128 ("Prepare v2024.07-rc3")
- next: 377e91c162ab ("Merge patch series "Clean-up patch set for MbedTLS
integration"")
Looking further down below, we can see that this patch has the "abootimg
load" command, which is introduced in these series:
https://lore.kernel.org/r/20240519191856.2582174-1-r.stratiie...@gmail.com
Please consider rebasing on either master or next before sending.
> ---
> boot/image-board.c | 13 ++---
> cmd/abootimg.c | 26 +-
> include/image.h| 7 +++
> 3 files changed, 38 insertions(+), 8 deletions(-)
[...]
>
>
> static struct cmd_tbl cmd_abootimg_sub[] = {
> - U_BOOT_CMD_MKENT(addr, 3, 1, do_abootimg_addr, "", ""),
> + U_BOOT_CMD_MKENT(addr, 4, 1, do_abootimg_addr, "", ""),
> U_BOOT_CMD_MKENT(dump, 2, 1, do_abootimg_dump, "", ""),
> U_BOOT_CMD_MKENT(get, 5, 1, do_abootimg_get, "", ""),
> U_BOOT_CMD_MKENT(load, 5, 1, do_abootimg_load, "", ""),
> @@ -376,7 +392,7 @@ static int do_abootimg(struct cmd_tbl *cmdtp, int flag,
> int argc,
> U_BOOT_CMD(
> abootimg, CONFIG_SYS_MAXARGS, 0, do_abootimg,
> "manipulate Android Boot Image",
> - "addr []>\n"
> + "addr [ []]\n"
> "- set the address in RAM where boot image is located\n"
> " ($loadaddr is used by default)\n"
> "abootimg dump dtb\n"
[...]
[PATCH] doc: board: sophgo: milkv_duo: Update Milk-V Duo documentation
Add detailed steps for compiling U-Boot and OpenSBI, generating the firmware package with fiptool, and booting the board. Signed-off-by: Kongyang Liu --- doc/board/sophgo/milkv_duo.rst | 41 +- 1 file changed, 30 insertions(+), 11 deletions(-) diff --git a/doc/board/sophgo/milkv_duo.rst b/doc/board/sophgo/milkv_duo.rst index cb2ed1ad98..a88db5b903 100644 --- a/doc/board/sophgo/milkv_duo.rst +++ b/doc/board/sophgo/milkv_duo.rst @@ -20,31 +20,50 @@ Building .. code-block:: console export CROSS_COMPILE= + +3. Compile U-Boot + +.. code-block:: console + cd make milkv_duo_defconfig make -This will generate u-boot-dtb.bin +This will generate u-boot.bin and u-boot.dtb -Booting -~~~ -Currently, we rely on vendor FSBL(First Stage Boot Loader) to initialize the -clock and load the u-boot image, then bootup from it. +4. Compile OpenSBI + +.. code-block:: console -Alternatively, to run u-boot-dtb.bin on top of FSBL, follow these steps: + cd + make PLATFORM=generic FW_FDT_PATH=/u-boot.dtb -1. Use the vendor-provided tool to create a unified fip.bin file containing - FSBL, OpenSBI, and U-Boot. +This will generate fw_dynamic.bin -2. Place the generated fip.bin file into the FAT partition of the SD card. +4. Generate firmware image package -3. Insert the SD card into the board and power it on. +Fiptool(https://github.com/sophgo/fiptool) is used to generate fip file. + +.. code-block:: console + + git clone https://github.com/sophgo/fiptool + cd fiptool + ./fiptool \ + --fsbl data/fsbl/cv180x.bin \ + --opensbi /fw_dynamic.bin \ + --uboot /u-boot.bin \ + +This will generate fip.bin + +Booting +~~~ +1. Place the generated fip.bin file into the FAT partition of the SD card. +2. Insert the SD card into the board and power it on. The board will automatically execute the FSBL from the fip.bin file. Subsequently, it will transition to OpenSBI, and finally, OpenSBI will invoke U-Boot. - Sample boot log from Milk-V Duo board ~ .. code-block:: none -- 2.41.0
Re: [PATCH 1/3] arm: dts: k3-am642-evm-u-boot: Add remoteproc-name for PRU cores
Hi Andrew,
On 5/22/2024 9:38 PM, Andrew Davis wrote:
> On 5/22/24 1:36 AM, MD Danish Anwar wrote:
>> Add remoteproc-name property for PRU cores.
>>
>> Signed-off-by: MD Danish Anwar
>> ---
>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 44 +++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> index 705b3baa81..25ddace74e 100644
>> --- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> +++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
>> @@ -11,6 +11,50 @@
>> };
>> };
>> +_0 {
>> + remoteproc-name = "pru0_0";
>
> Why do we need all these? Looks like we fallback to using `dev->name` if
> these are not set, does that not work for us here?
>
Yes we will fallback to `dev->name` if `remoteproc-name` is not set but
in our case two different PRU cores will have same `dev->name`. As a
result the API rproc_name_is_unique() will return false and as a result
the probe will fail for the PRU cores.
Example: In k3-am64-main.dtsi, both pru0_0 [1] and pru1_0 [2] will have
dev->name as "pru@34000" same goes for rtu and txpru as well.
pru0_0: pru@34000 {
compatible = "ti,am642-pru";
reg = <0x34000 0x3000>,
<0x22000 0x100>,
<0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am64x-pru0_0-fw";
};
pru1_0: pru@34000 {
compatible = "ti,am642-pru";
reg = <0x34000 0x4000>,
<0x22000 0x100>,
<0x22400 0x100>;
reg-names = "iram", "control", "debug";
firmware-name = "am64x-pru1_0-fw";
};
To avoid this, we are setting the "remoteproc-name" property in
-u-boot.dtsi. Same is done for AM65x as well [3].
[1]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1276
[2]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/dts/upstream/src/arm64/ti/k3-am64-main.dtsi#L1417
[3]
https://elixir.bootlin.com/u-boot/v2024.07-rc3/source/arch/arm/dts/k3-am654-base-board-u-boot.dtsi#L168
> Andrew
>
>> +};
>> +
>> +_0 {
>> + remoteproc-name = "rtu0_0";
>> +};
>> +
>> +_pru0_0 {
>> + remoteproc-name = "tx_pru0_0";
>> +};
>> +
>> +_1 {
>> + remoteproc-name = "pru0_1";
>> +};
>> +
>> +_1 {
>> + remoteproc-name = "rtu0_1";
>> +};
>> +
>> +_pru0_1 {
>> + remoteproc-name = "tx_pru0_1";
>> +};
>> +
>> +_0 {
>> + remoteproc-name = "pru1_0";
>> +};
>> +
>> +_0 {
>> + remoteproc-name = "rtu1_0";
>> +};
>> +
>> +_pru1_0 {
>> + remoteproc-name = "tx_pru1_0";
>> +};
>> +
>> +_1 {
>> + remoteproc-name = "pru1_1";
>> +};
>> +
>> +_1 {
>> + remoteproc-name = "rtu1_1";
>> +};
>> +
>> _timer0 {
>> clock-frequency = <2>;
>> };
--
Thanks and Regards,
Md Danish Anwar
Re: [PATCH] abootimg: Add init_boot image support
Hi Roman,
On jeu., mai 23, 2024 at 00:35, Roman Stratiienko
wrote:
[...]
>> >
>> > static struct cmd_tbl cmd_abootimg_sub[] = {
>> > - U_BOOT_CMD_MKENT(addr, 3, 1, do_abootimg_addr, "", ""),
>> > + U_BOOT_CMD_MKENT(addr, 4, 1, do_abootimg_addr, "", ""),
>> > U_BOOT_CMD_MKENT(dump, 2, 1, do_abootimg_dump, "", ""),
>> > U_BOOT_CMD_MKENT(get, 5, 1, do_abootimg_get, "", ""),
>> > U_BOOT_CMD_MKENT(load, 5, 1, do_abootimg_load, "", ""),
>> > @@ -375,7 +391,7 @@ static int do_abootimg(struct cmd_tbl *cmdtp, int
>> > flag, int argc,
>> > U_BOOT_CMD(
>> > abootimg, CONFIG_SYS_MAXARGS, 0, do_abootimg,
>> > "manipulate Android Boot Image",
>> > - "addr []>\n"
>> > + "addr [
>> > []]\n"
>> > "- set the address in RAM where boot image is located\n"
>> > " ($loadaddr is used by default)\n"
>>
>> Please include the help text update in the documentation:
>> doc/android/boot-image.rst
>
> That documentation does not mention 'abootimg addr' command at the moment.
> I do not see an easy way to add it in a way that makes sense.
>
I see. I will send a documentation update later then.
>>
>> > "abootimg dump dtb\n"
>> > diff --git a/include/image.h b/include/image.h
>> > index be3c73a72e..b1fd6b3149 100644
[...]
