Fit Signature booting without public key
Hi All, I recently came upon a discussion that had happened a while back [0]. I want to continue the discussion as I believe the issue still persists and the checks around fit signature booting are still the same, that allows booting the fit without changing the uboot dtb. Allowing the signed fit image without this seems to be a bypass that is available and should not be allowed without any gate to it for people who'd like to enforce these signing checks. Let me know if there is a config already available for it and if not, are there any plans to enable such a config in future. Would like to hear your opinions on this as I believe this should be fixed as soon as possible. [0]: https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boots-without-public-key Regards, Manorit
Re: [PATCH] Fix sparse checks processing
Le 15/05/2023 à 23:12, Tom Rini a écrit :
> On Fri, May 05, 2023 at 10:39:39AM +0200, Christophe Leroy wrote:
>
>> A lot of errors are encountered when building with sparse checking
>> activated (make C=1 or make C=2).
>>
>> Many of them are fixed in Linux.
>>
>> Resynchronise Makefile and include/linux/build_bug.h with Linux
>> kernel sources by porting the following Linux commits into u-boot:
>> - 6c49f359ca14 ("kbuild: disable sparse warnings about unknown attributes")
>> - 80591e61a0f7 ("kbuild: tell sparse about the $ARCH")
>> - 8788994376d8 ("linux/build_bug.h: change type to int")
>> - 527edbc18a70 ("build_bug.h: remove most of dummy BUILD_BUG_ON stubs for
>> Sparse")
>> - c60d3b79423a ("build_bug.h: remove negative-array fallback for
>> BUILD_BUG_ON()")
>> - 14e83077d55f ("include: drop pointless __compiler_offsetof indirection")
>>
>> Also revert commit aa9e891c63 ("include/linux/stddef.h: avoid
>> 'warning: preprocessor token offsetof redefined'") because the
>> error it creates is worse than the warning it is trying to fix.
>>
>> Signed-off-by: Christophe Leroy
>
> First, I've applied to u-boot/next now. But second, I had mentioned CI
> testing too, but seeing the level of checker-error output on qemu-arm I
> am reluctant to add a test that should build-to-completion but error so
> much as I worry about it being seen as a low quality test.
>
Well, at least we can now start detecting and fixing them.
Also, I don't know how feasible it is, but in Linux kernel the robots
report new warnings/error only so that you know you are not adding new
ones with new commits. Could CI do that too ?
Christophe
Re: [PATCH] powerpc: Add support for CZ.NIC Turris 1.x routers
Happy Birthday for this patch?
On Monday 16 May 2022 11:01:19 Pali Rohár wrote:
> CZ.NIC Turris 1.0 and 1.1 are open source routers, they have dual-core
> PowerPC Freescale P2020 CPU and are based on Freescale P2020RDB-PC-A board.
>
> Hardware design is fully open source, all firmware and hardware design
> files are available at Turris project website:
>
> https://docs.turris.cz/hw/turris-1x/turris-1x/
> https://project.turris.cz/en/hardware.html
>
> This patch adds full U-Boot support for CZ.NIC Turris 1.x routers. P2020
> BootROM can load U-Boot either from NOR flash or from SD card. So there is
> defconfig file turris_1x_nor_defconfig which builds NOR version and
> defconfig file turris_1x_sdcard_defconfig which builds SD card version.
>
> Design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A
> board, so common board code from boards/freescale/p1_p2_rdb_pc directory is
> shared and linked also into Turris 1.x U-Boot board code.
>
> Turris 1.x code in this patch uses modern distroboot and can boot Linux
> kernel from various locations, including NAND, SD card, USB flash disks,
> NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers).
>
> Signed-off-by: Pali Rohár
>
> ---
>
> This patch depends on other powerpc patches:
> https://patchwork.ozlabs.org/bundle/pali/powerpc/
> ---
> arch/powerpc/cpu/mpc85xx/Kconfig | 6 +
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/turris1x-u-boot.dtsi | 13 +
> arch/powerpc/dts/turris1x.dts | 475 ++
> board/CZ.NIC/turris_1x/Kconfig| 177 ++
> board/CZ.NIC/turris_1x/MAINTAINERS| 11 +
> board/CZ.NIC/turris_1x/Makefile | 15 +
> board/CZ.NIC/turris_1x/ddr.c | 27 ++
> board/CZ.NIC/turris_1x/law.c | 13 +
> board/CZ.NIC/turris_1x/lbc.c | 26 ++
> board/CZ.NIC/turris_1x/tlb.c | 142
> board/CZ.NIC/turris_1x/turris_1x.c| 106 ++
> configs/turris_1x_nor_defconfig | 50 +++
> configs/turris_1x_sdcard_defconfig| 66
> include/configs/turris_1x.h | 381 +
> 15 files changed, 1509 insertions(+)
> create mode 100644 arch/powerpc/dts/turris1x-u-boot.dtsi
> create mode 100644 arch/powerpc/dts/turris1x.dts
> create mode 100644 board/CZ.NIC/turris_1x/Kconfig
> create mode 100644 board/CZ.NIC/turris_1x/MAINTAINERS
> create mode 100644 board/CZ.NIC/turris_1x/Makefile
> create mode 100644 board/CZ.NIC/turris_1x/ddr.c
> create mode 100644 board/CZ.NIC/turris_1x/law.c
> create mode 100644 board/CZ.NIC/turris_1x/lbc.c
> create mode 100644 board/CZ.NIC/turris_1x/tlb.c
> create mode 100644 board/CZ.NIC/turris_1x/turris_1x.c
> create mode 100644 configs/turris_1x_nor_defconfig
> create mode 100644 configs/turris_1x_sdcard_defconfig
> create mode 100644 include/configs/turris_1x.h
>
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig
> b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 6f8b7593d250..28f69e7c73d2 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -150,6 +150,11 @@ config TARGET_P2020RDB
> imply CMD_SATA
> imply SATA_SIL
>
> +config TARGET_TURRIS_1X
> + bool "Support Turris 1.x"
> + select SUPPORT_SPL
> + select ARCH_P2020
> +
> config TARGET_P2041RDB
> bool "Support P2041RDB"
> select ARCH_P2041
> @@ -1201,6 +1206,7 @@ config SYS_FSL_LBC_CLK_DIV
> config FSL_VIA
> bool
>
> +source "board/CZ.NIC/turris_1x/Kconfig"
> source "board/emulation/qemu-ppce500/Kconfig"
> source "board/freescale/corenet_ds/Kconfig"
> source "board/freescale/mpc8548cds/Kconfig"
> diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
> index a4b0d7ddc4ff..d6462101211e 100644
> --- a/arch/powerpc/dts/Makefile
> +++ b/arch/powerpc/dts/Makefile
> @@ -26,6 +26,7 @@ dtb-$(CONFIG_TARGET_T2080QDS) += t2080qds.dtb
> dtb-$(CONFIG_TARGET_T2080RDB) += t2080rdb.dtb
> dtb-$(CONFIG_TARGET_T4240RDB) += t4240rdb.dtb
> dtb-$(CONFIG_TARGET_TUGE1) += kmtuge1.dtb
> +dtb-$(CONFIG_TARGET_TURRIS_1X) += turris1x.dtb
> dtb-$(CONFIG_TARGET_TUXX1) += kmtuxa1.dtb
> dtb-$(CONFIG_TARGET_MCR3000) += mcr3000.dtb
> dtb-$(CONFIG_TARGET_GAZERBEAM) += gazerbeam.dtb
> diff --git a/arch/powerpc/dts/turris1x-u-boot.dtsi
> b/arch/powerpc/dts/turris1x-u-boot.dtsi
> new file mode 100644
> index ..aa758818d564
> --- /dev/null
> +++ b/arch/powerpc/dts/turris1x-u-boot.dtsi
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> + {
> + i2c@3000 {
> + u-boot,dm-pre-reloc;
> +
> + crypto@64 {
> + u-boot,dm-pre-reloc;
> + };
> + };
> +};
> +
> +#include "u-boot.dtsi"
> diff --git a/arch/powerpc/dts/turris1x.dts b/arch/powerpc/dts/turris1x.dts
> new file mode 100644
> index ..1b27c1b0bba6
> --- /dev/null
> +++ b/arch/powerpc/dts/turris1x.dts
> @@ -0,0 +1,475 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> +
Pull request efi-2023-07-rc3
Dear Tom, The following changes since commit e94fbdd2729fdcd570035d43f67adda8e0dfc115: Merge https://source.denx.de/u-boot/custodians/u-boot-x86 (2023-05-11 08:40:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2023-07-rc3 for you to fetch changes up to c7c0ca37673d8f1ae1c54dad1869101f566923f7: efi_loader: fix efi_dp_from_file() (2023-05-13 11:09:51 +0200) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16352 Pull request efi-2023-07-rc3 Documentation: * update the description of signature algorithms UEFI: * fix unaligned access to GUID in HII database protocol * fix launching EFI binaries loaded via semihosting * fix filling of file path in loaded image protocol for non-block devices Baruch Siach (5): doc: signature: update algorithms support description doc: signature: update algorithm addition description doc: signature: describe how to enable ECDSA doc: signature: trim the future work list doc: devicetree: fix u-boot.bin filename typo Heinrich Schuchardt (9): fwu: fix config FWU_MULTI_BANK_UPDATE efi_loader: print file path w/o boot device efi_loader: support booting semihosting file efi_loader: avoid #ifdef in efi_dp_from_name() efi_loader: duplicate code in efi_dp_from_name efi_loader: clean up efi_dp_from_file efi_loader: error code efi_dp_from_name() efi_loader: simplify efi_dp_from_name() efi_loader: fix efi_dp_from_file() Ilias Apalodimas (1): efi_loader: Fix warnings for unaligned accesses cmd/bootefi.c | 2 +- doc/develop/devicetree/control.rst | 2 +- doc/uImage.FIT/signature.txt | 15 +++ include/efi_api.h | 28 +++- include/efi_loader.h | 2 +- lib/efi_loader/efi_bootmgr.c | 13 +++--- lib/efi_loader/efi_device_path.c | 92 +- lib/efi_loader/helloworld.c| 8 ++-- lib/fwu_updates/Kconfig| 2 +- 9 files changed, 77 insertions(+), 87 deletions(-)
Re: [PATCH v5 01/17] riscv: cpu: jh7110: Add support for jh7110 SoC
On 2023/5/12 13:50, Bo Gan wrote:
> On 3/28/23 8:42 PM, Yanhong Wang wrote:
>> +void harts_early_init(void)
>> +{
>> + ulong *ptr;
>> + u8 *tmp;
>> + ulong len, remain;
>> + /*
>> + * Feature Disable CSR
>> + *
>> + * Clear feature disable CSR to '0' to turn on all features for
>> + * each core. This operation must be in M-mode.
>> + */
>> + if (CONFIG_IS_ENABLED(RISCV_MMODE))
>> + csr_write(CSR_U74_FEATURE_DISABLE, 0);
>> +
>> + /* clear L2 LIM memory
>> + * set __bss_end to 0x81F region to zero
>> + * The L2 Cache Controller supports ECC. ECC is applied to SRAM.
>> + * If it is not cleared, the ECC part is invalid, and an ECC error
>> + * will be reported when reading data.
>> + */
>> + ptr = (ulong *)&__bss_end;
>> + len = L2_LIM_MEM_END - (ulong)&__bss_end;
>> + remain = len % sizeof(ulong);
>> + len /= sizeof(ulong);
>> +
>> + while (len--)
>> + *ptr++ = 0;
>> +
>> + /* clear the remain bytes */
>> + if (remain) {
>> + tmp = (u8 *)ptr;
>> + while (remain--)
>> + *tmp++ = 0;
>> + }
>> +}
> Hi Yanhong, I know this is already merged, but it looks wrong to
> me.`harts_early_init`
> will be called by all harts in SPL. The per-hart stack sits between __bss_end
> and L2_LIM_MEM_END.
> Zeroing this region could overwrite the hart's stack, and other harts'
> stacks. The current
> implementation works likely because harts_early_init doesn't use any stack
> space, but it's up to
> the compiler and we can't guarantee that. If it were to save and restore `ra`
> register, then we
> would crash in function epilogue. Also, we are having data-races here,
> because harts are writing
> over each other's stack.
>
> My advice is that we should split the zeroing of L2 LIM into different places
> just before the
> region is to be used. For stacks, we can let each hart clearing its own
> stack, and for the malloc
> space, we can do so during malloc initialization. Doing so also gives us the
> benefit of catching
> the read of uninitialized data. In this approach, the L2_LIM_MEM_END macro is
> not needed anymore.
Hi，Bo Gan， I agree with you, there is some problem with the initialization of
the L2 LIM,
so, as you suggested, we should split the zeroing of L2 LIM into different
places.
Something like：
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 72adcefa0e..574ffc3d33 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -13,7 +13,6 @@
#include
#define CSR_U74_FEATURE_DISABLE0x7c1
-#define L2_LIM_MEM_END 0x81FUL
DECLARE_GLOBAL_DATA_PTR;
@@ -61,7 +60,7 @@ void harts_early_init(void)
{
ulong *ptr;
u8 *tmp;
- ulong len, remain;
+ ulong len, remain, init_end;
/*
* Feature Disable CSR
*
@@ -77,8 +76,10 @@ void harts_early_init(void)
* If it is not cleared, the ECC part is invalid, and an ECC error
* will be reported when reading data.
*/
+ init_end = CONFIG_SPL_STACK -CONFIG_VAL(SYS_MALLOC_F_LEN) - sizeof(*gd)
+ - CONFIG_NR_CPUS * BIT(CONFIG_STACK_SIZE_SHIFT);
ptr = (ulong *)&__bss_end;
- len = L2_LIM_MEM_END - (ulong)&__bss_end;
+ len = init_end - (ulong)&__bss_end;
remain = len % sizeof(ulong);
len /= sizeof(ulong);
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index dad22bfea8..46da9ec503 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -118,6 +118,20 @@ call_board_init_f_0:
mv sp, a0
#endif
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) && \
+ defined(CONFIG_STARFIVE_JH7110)
+
+ /* Set the stack region to zero */
+ li t0, 1
+ slli t1, t0, CONFIG_STACK_SIZE_SHIFT
+ mv t0, sp
+ sub t1, t0, t1
+clear_stack:
+ SREGzero, 0(t1)
+ addit1, t1, REGBYTES
+ blt t1, t0, clear_stack
+#endif
+
/* Configure proprietary settings and customized CSRs of harts */
call_harts_early_init:
jal harts_early_init
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 96ffb79a98..46e4e4abc7 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -162,6 +162,7 @@ void board_init_f_init_reserve(ulong base)
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* go down one 'early malloc arena' */
gd->malloc_base = base;
+ memset((void *)base, 0, CONFIG_VAL(SYS_MALLOC_F_LEN));
#endif
if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
Re: mmc: Read eMMC partition access bits before card reset
On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related patches: > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > Author: Pali Rohár > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says that > > > > > > > > all reset > > > > > > > > events will restore the access bits in PARTITION_CONFIG CSD > > > > > > > > register to > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > > register before > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > information which eMMC > > > > > > > > partition was in use before SPL/U-Boot was booted. For some > > > > > > > > platforms this > > > > > > > > is the way how to determinate boot partition from which > > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > 13:10:10 -0400) > > > > > > > > Trying to boot from MMC1 > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > -- > > > > > > > > Tom > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to hide > > > > > > > this code > > > > > > > behind CONFIG symbol and enable it only for mvebu. For example by > > > > > > > this: > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > > failure I > > > > > > reported was uSD and not eMMC. > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not know > > > > > if > > > > > card is SD or MMC. > > > > > > > > > > Martin, can you check if booting from SD card is working fine on mvebu > > > > > clearfog? > > > > > > > > > > > I see a failure with this commit on > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > fsm 0, hsts > > > > > > ... > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above one > > > > > > and > > > > > > the board is fine again. > > > > > > > > > > > > -- > > > > > > Tom > > > > > > > > > > Immediately after that "problematic code" is card reset function. So > > > > > another reason for failure is that card reset functionality does not > > > > > work correctly on your board / platform. > > > > > > > > Well, we're at two different platforms and controllers that this change > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > mx6cuboxi is still fine booting from uSD. Another TI platform from the > > > > same general era as am335x fails the same way (not a surprise), amlogic > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms are > > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI platforms > > > > that work are not ARCH_OMAP2PLUS). > > > > > > > > -- > > > > Tom > > > > > > And do you see this problem in SPL or in proper U-Boot? > > > > > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > > > qemu emulated version (to which can be attached gdb). But Nokia N900 is > > > without SPL. > > > > > > OK, so on am335x_evm mine is setup so I can X/Y modem boot it before it > > tries uSD. In this case, full U-Boot also fails: > > Loading Environment from FAT... omap_hsmmc_send_cmd: timedout waiting on > > cmd inhibit to clear > > ** Bad device specification mmc 0 ** > > > > Note that N900 in QEMU passes, but I suspect that's a matter of the > > emulator not being faithful to
Re: [PATCH v3 2/2] firmware: zynqmp: Move config object permission check
Hi,
first of all sorry for delay.
On 4/27/23 12:31, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Move the check of the permission to change a config object from
zynqmp_pmufw_node function to zynqmp_pmufw_load_config_object function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v3:
- Added
drivers/firmware/firmware-zynqmp.c | 32 +++---
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 2b1ad5d2c3..d12159fa78 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -70,20 +70,11 @@ int zynqmp_pmufw_config_close(void)
int zynqmp_pmufw_node(u32 id)
{
- static bool skip_config;
- int ret;
-
- if (skip_config)
- return 0;
-
/* Record power domain id */
xpm_configobject[NODE_ID_LOCATION] = id;
- ret = zynqmp_pmufw_load_config_object(xpm_configobject,
- sizeof(xpm_configobject));
-
- if (ret == -EACCES && id == NODE_OCM_BANK_0)
- skip_config = true;
+ zynqmp_pmufw_load_config_object(xpm_configobject,
+ sizeof(xpm_configobject));
This is not right.
It should be
return zynqmp_pmufw_load... for error propagation.
And tbh zynqmp_pmufw_config_close should also do the same thing.
The rest looks good to me.
Thanks,
Michal
In u-boot proper, what function in int_sequence_r list jumps to linux?
Hello u-boot experts, On qemu arm64 virt machine, I can start u-boot-spl and it loads u-boot(proper) from RAM ( CONFIG_SPL_RAM_SUPPORT=y, CONFIG_SPL_RAM_DEVICE=y) and executes it. Previously I have used u-boot-spl and used falcon mode to jump directly to linux on qemu virt machine and on actual board, but I had modified u-boot code to skip some parts and forced some parameters(in spl_image? Maybe) arbitrarily to my purpose. This time I'm trying to do u-boot-spl => u-boot => linux without changing u-boot source code. In u-boot-spl case, there is the part where it jumps to linux in the board_init_r function (in common/spl/spl.c). But u-boot(proper) case, in board_init_r function (in common/board_r.c) there is no such jump to linux. It just calls functions in init_sequence_r function pointer array. The array starts with initr_trace and ends with run_main_loop. When I run it, it runs the run_main_loop function and comes out to prompt. My question is : in what function am I supposed to jump to linux? I will appreciate any comment or answer. (using u-boot.v2022.07) Thank you. Chan Kim
Re: [PATCH v3 7/7] configs: rock5b-rk3588: add PCI drivers and command
On 5/6/23 12:44, Kever Yang wrote: On 2023/4/27 15:35, Eugen Hristev wrote: Add drivers for PCIe , phy, and command. Signed-off-by: Eugen Hristev Reviewed-by: Kever Yang Thanks, - Kever --- Hi Kever, Do you need me to resend this series as well ? If you need help in applying, or specifying the order of patches, let me know. I have rebased some of the series, order of applying at the moment is : https://patchwork.ozlabs.org/project/uboot/patch/20230515095950.23666-1-eugen.hris...@collabora.com/ and then https://patchwork.ozlabs.org/project/uboot/patch/20230515134403.38485-1-eugen.hris...@collabora.com/ if you apply these to your tree I can then send patches on top of your branch, if that is better for you ? Thanks, Eugen
Re: [PATCH] cmd: tlv_eeprom: fix signature for populate_serial_number function
Hi Heinrich,
Am 16.05.23 um 14:21 schrieb Heinrich Schuchardt:
On 5/16/23 10:27, Josua Mayer wrote:
populate_serial_number is not used internally for the tlv_eeprom
command, but rather provided as a library function for external use..
Remove the devnum that had recently been added by mistake, returning the
function to its original signature.
Instead place a 0-initialised member variable inside the function to
same purpose, along with a node that it only supports reading from the
%s/node/note/
Good find!
first EEPROM in the system.
Fixes: dfda0c0 ("cmd: tlv_eeprom: remove use of global variable
current_dev")
Signed-off-by: Josua Mayer
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heinrich Schuchardt
---
cmd/tlv_eeprom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 79796394c5c..0ca4d714645 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -1100,11 +1100,12 @@ int mac_read_from_eeprom(void)
*
* This function must be called after relocation.
*/
-int populate_serial_number(int devnum)
+int populate_serial_number(void)
If populate_serial_number() is to be used as a library function, it
should live in lib/ or possibly in drivers/misc/. The definition needs
to be provided in an include file. Otherwise the function should be
deleted.
Where will this library function be used?
I don't know for sure. GitHub search finds its use in board files on
some old ONIE u-boot forks.
Main purpose of this patch right now is to undo my accidental change and
restore the default behaviour:
The previous instance of devnum variable inside tlv_eeprom.c would have
had value 0 by default.
Shouldn't the EEPROM with the serial number be identified via the
device-tree?
Something like that would be nice.
However we also want to use identical device-tree between Linux and U-Boot.
I am not sure if we have such indication.
Best regards
Heinrich
{
char serialstr[257];
int eeprom_index;
struct tlvinfo_tlv *eeprom_tlv;
+ int devnum = 0; // TODO: support multiple EEPROMs
if (env_get("serial#"))
return 0;
- Josua Mayer
[PATCH v3] cmd: sf/nand: Print and return failure when 0 length is passed
For sf commands, when '0' length is passed for erase, update, write or
read, there might be undesired results. Ideally '0' length means nothing to
do.
So print 'ERROR: Invalid size 0' and return cmd failure when length '0' is
passed to sf commands. Same thing applies for nand commands also.
Example:
ZynqMP> sf erase 0 0
ERROR: Invalid size 0
ZynqMP> sf write 1 0 0
ERROR: Invalid size 0
ZynqMP> sf read 1 0 0
ERROR: Invalid size 0
ZynqMP> sf update 1000 1 0
ERROR: Invalid size 0
ZynqMP>
Signed-off-by: Ashok Reddy Soma
---
Changes in v3:
- Change printf to debug as it is too verbose
Changes in v2:
- Changed print from 'size is 0' to Invalid size 0 without quites.
- Modified description to be imperative
- Fixed typo in description from "samething" to "same thing"
cmd/legacy-mtd-utils.c | 5 +
cmd/sf.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/cmd/legacy-mtd-utils.c b/cmd/legacy-mtd-utils.c
index ac7139f84d..5903a90fe5 100644
--- a/cmd/legacy-mtd-utils.c
+++ b/cmd/legacy-mtd-utils.c
@@ -88,6 +88,11 @@ int mtd_arg_off_size(int argc, char *const argv[], int *idx,
loff_t *off,
return -1;
}
+ if (*size == 0) {
+ debug("ERROR: Invalid size 0\n");
+ return -1;
+ }
+
print:
printf("device %d ", *idx);
if (*size == chipsize)
diff --git a/cmd/sf.c b/cmd/sf.c
index 11b9c25896..55bef2f769 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -353,6 +353,11 @@ static int do_spi_flash_erase(int argc, char *const argv[])
if (ret != 1)
return CMD_RET_USAGE;
+ if (size == 0) {
+ debug("ERROR: Invalid size 0\n");
+ return CMD_RET_FAILURE;
+ }
+
/* Consistency checking */
if (offset + size > flash->size) {
printf("ERROR: attempting %s past flash size (%#x)\n",
--
2.17.1
[PATCH] scripts/Makefile.lib: change spelling of $(srctree)/arch/$(ARCH)/dts in dtc_cpp_flags
Currently, all in-tree .dts files (apart from some under test/ and tools/), reside in arch/$ARCH/dts. However, in the linux kernel tree, dts files for arm64 boards, and probably in the not too distant future [1], arm boards as well, live in subdirectories of that. For private forks, using a vendor or project subdirectory is also more convenient to clearly separate private code from upstream - in the same way that code under board/ is also split and easy to maintain. In order to prepare for us to follow suit and do the splitting of the in-tree .dts files, and to make life a little easier for private forks that already place dts files not directly in arch/$ARCH/dts, change the $(srctree)/arch/$(ARCH)/dts path to instead refer to the directory of the .dts file being compiled. This should be a no-op for all existing cases. [1] https://lore.kernel.org/lkml/20220328000915.15041-1-ansuels...@gmail.com/ Signed-off-by: Rasmus Villemoes --- scripts/Makefile.lib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 7b27224b5d..b67da75ba1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -186,7 +186,7 @@ u_boot_dtsi = $(strip $(u_boot_dtsi_options_debug) \ # Modified for U-Boot dtc_cpp_flags = -Wp,-MD,$(depfile).pre.tmp -nostdinc\ $(UBOOTINCLUDE) \ --I$(srctree)/arch/$(ARCH)/dts \ +-I$(dir $<) \ -I$(srctree)/arch/$(ARCH)/dts/include \ -I$(srctree)/include\ -D__ASSEMBLY__ \ -- 2.37.2
[RFC v2 3/3] cmd: tlv_eeprom: port to new shared tlv library
Rewrite tlv_eeprom command for using the new tlv library, and drop all
unused functions. From this point on, tlv_eeprom command internal
functions shall not be reused externally.
mac_read_from_eeprom & populate_serial_number are kept in place for now
as is, however these probably deserve a new location.
Signed-off-by: Josua Mayer
---
cmd/Kconfig| 9 +-
cmd/tlv_eeprom.c | 507 +++--
configs/clearfog_defconfig | 2 +-
include/tlv_eeprom.h | 148 ---
4 files changed, 92 insertions(+), 574 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 9c2149dc881..4b7ea8cd358 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -190,19 +190,14 @@ config CMD_REGINFO
config CMD_TLV_EEPROM
bool "tlv_eeprom"
- depends on I2C_EEPROM
- depends on !EEPROM_TLV_LIB
- select CRC32
+ depends on EEPROM_TLV_LIB
help
Display and program the system EEPROM data block in ONIE Tlvinfo
format. TLV stands for Type-Length-Value.
config SPL_CMD_TLV_EEPROM
bool "tlv_eeprom for SPL"
- depends on SPL_I2C_EEPROM
- depends on !SPL_EEPROM_TLV_LIB
- select SPL_DRIVERS_MISC
- select SPL_CRC32
+ depends on SPL_EEPROM_TLV_LIB
help
Read system EEPROM data block in ONIE Tlvinfo format from SPL.
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 0ca4d714645..02e1dd88d35 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -7,69 +7,36 @@
* Copyright (C) 2014 Srideep
* Copyright (C) 2013 Miles Tseng
* Copyright (C) 2014,2016 david_yang
+ * Copyright (C) 2023 Josua Mayer
*/
-#include
#include
-#include
-#include
-#include
-#include
-#include
+#include
#include
-#include
-#include
-#include
-
-#include "tlv_eeprom.h"
+#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
-#define MAX_TLV_DEVICES2
+#define DEBUG
-/* File scope function prototypes */
-static bool is_checksum_valid(u8 *eeprom);
-static int read_eeprom(int devnum, u8 *eeprom);
-static void show_eeprom(int devnum, u8 *eeprom);
static void decode_tlv(struct tlvinfo_tlv *tlv);
-static void update_crc(u8 *eeprom);
-static int prog_eeprom(int devnum, u8 *eeprom);
-static bool tlvinfo_find_tlv(u8 *eeprom, u8 tcode, int *eeprom_index);
-static bool tlvinfo_delete_tlv(u8 *eeprom, u8 code);
-static bool tlvinfo_add_tlv(u8 *eeprom, int tcode, char *strval);
+static bool tlvinfo_add_tlv(struct tlvinfo_priv *header, int tcode, char
*strval);
static int set_mac(char *buf, const char *string);
static int set_date(char *buf, const char *string);
static int set_bytes(char *buf, const char *string, int *converted_accum);
-static void show_tlv_devices(int current_dev);
-/* The EERPOM contents after being read into memory */
+/* The EEPROM contents after being read into memory */
static u8 eeprom[TLV_INFO_MAX_LEN];
-static struct udevice *tlv_devices[MAX_TLV_DEVICES];
-
-#define to_header(p) ((struct tlvinfo_header *)p)
-#define to_entry(p) ((struct tlvinfo_tlv *)p)
-
-#define HDR_SIZE sizeof(struct tlvinfo_header)
-#define ENT_SIZE sizeof(struct tlvinfo_tlv)
+static void show_tlv_devices(int current_dev);
static inline bool is_digit(char c)
{
return (c >= '0' && c <= '9');
}
-/**
- * is_valid_tlv
- *
- * Perform basic sanity checks on a TLV field. The TLV is pointed to
- * by the parameter provided.
- * 1. The type code is not reserved (0x00 or 0xFF)
- */
-static inline bool is_valid_tlv(struct tlvinfo_tlv *tlv)
-{
- return((tlv->type != 0x00) && (tlv->type != 0xFF));
-}
-
/**
* is_hex
*
@@ -78,79 +45,8 @@ static inline bool is_valid_tlv(struct tlvinfo_tlv *tlv)
static inline u8 is_hex(char p)
{
return (((p >= '0') && (p <= '9')) ||
- ((p >= 'A') && (p <= 'F')) ||
- ((p >= 'a') && (p <= 'f')));
-}
-
-/**
- * is_checksum_valid
- *
- * Validate the checksum in the provided TlvInfo EEPROM data. First,
- * verify that the TlvInfo header is valid, then make sure the last
- * TLV is a CRC-32 TLV. Then calculate the CRC over the EEPROM data
- * and compare it to the value stored in the EEPROM CRC-32 TLV.
- */
-static bool is_checksum_valid(u8 *eeprom)
-{
- struct tlvinfo_header *eeprom_hdr = to_header(eeprom);
- struct tlvinfo_tlv*eeprom_crc;
- unsigned int calc_crc;
- unsigned int stored_crc;
-
- // Is the eeprom header valid?
- if (!is_valid_tlvinfo_header(eeprom_hdr))
- return false;
-
- // Is the last TLV a CRC?
- eeprom_crc = to_entry([HDR_SIZE +
- be16_to_cpu(eeprom_hdr->totallen) - (ENT_SIZE + 4)]);
- if (eeprom_crc->type != TLV_CODE_CRC_32 || eeprom_crc->length != 4)
- return false;
-
- // Calculate the checksum
- calc_crc = crc32(0, (void *)eeprom,
-HDR_SIZE + be16_to_cpu(eeprom_hdr->totallen) - 4);
- stored_crc =
Re: [PATCH v3 2/2] firmware: zynqmp: Move config object permission check
On 5/16/23 13:23, Stefan Herbrechtsmeier wrote:
Hi,
Am 16.05.2023 um 10:26 schrieb Michal Simek:
Hi,
first of all sorry for delay.
On 4/27/23 12:31, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Move the check of the permission to change a config object from
zynqmp_pmufw_node function to zynqmp_pmufw_load_config_object function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v3:
- Added
drivers/firmware/firmware-zynqmp.c | 32 +++---
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 2b1ad5d2c3..d12159fa78 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -70,20 +70,11 @@ int zynqmp_pmufw_config_close(void)
int zynqmp_pmufw_node(u32 id)
{
- static bool skip_config;
- int ret;
-
- if (skip_config)
- return 0;
-
/* Record power domain id */
xpm_configobject[NODE_ID_LOCATION] = id;
- ret = zynqmp_pmufw_load_config_object(xpm_configobject,
- sizeof(xpm_configobject));
-
- if (ret == -EACCES && id == NODE_OCM_BANK_0)
- skip_config = true;
+ zynqmp_pmufw_load_config_object(xpm_configobject,
+ sizeof(xpm_configobject));
This is not right.
It should be
return zynqmp_pmufw_load... for error propagation.
At the moment the zynqmp_pmufw_node and zynqmp_pmufw_config_close doesn't return
an error. Should the zynqmp_pmufw_load_config_object return 0 or -EACCES if it
is skipped?
In context zynqmp_pmufw_node and it's dependency on returning EACESS for failure
case which your code depends on here
+ if (zynqmp_pmufw_node(NODE_OCM_BANK_0) == -EACCES) {
+ printf("PMUFW: No permission to change config
object\n");
+ skip = true;
+ }
And for second part around skip and return code. I would say what you have is
fine. It means returning -EACCES is appropriate here.
And as I see do_zynqmp_pmufw should also return that value. That command will
simply fail if there is no permission.
And for close part I would say the same. Error should be propagated.
I expect current command behavior when you call "pmufw node close" on regular
system will just pass but it should just fail because command wasn't successful.
Thanks,
Michal
Re: [PATCH] cmd: tlv_eeprom: fix signature for populate_serial_number function
On 5/16/23 13:49, Josua Mayer wrote:
Hi Heinrich,
Am 16.05.23 um 14:21 schrieb Heinrich Schuchardt:
On 5/16/23 10:27, Josua Mayer wrote:
populate_serial_number is not used internally for the tlv_eeprom
command, but rather provided as a library function for external use..
Remove the devnum that had recently been added by mistake, returning the
function to its original signature.
Instead place a 0-initialised member variable inside the function to
same purpose, along with a node that it only supports reading from the
%s/node/note/
Good find!
first EEPROM in the system.
Fixes: dfda0c0 ("cmd: tlv_eeprom: remove use of global variable
current_dev")
Signed-off-by: Josua Mayer
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heinrich Schuchardt
---
cmd/tlv_eeprom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 79796394c5c..0ca4d714645 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -1100,11 +1100,12 @@ int mac_read_from_eeprom(void)
*
* This function must be called after relocation.
*/
-int populate_serial_number(int devnum)
+int populate_serial_number(void)
If populate_serial_number() is to be used as a library function, it
should live in lib/ or possibly in drivers/misc/. The definition needs
to be provided in an include file. Otherwise the function should be
deleted.
Where will this library function be used?
I don't know for sure. GitHub search finds its use in board files on
some old ONIE u-boot forks.
Main purpose of this patch right now is to undo my accidental change and
restore the default behaviour:
The previous instance of devnum variable inside tlv_eeprom.c would have
had value 0 by default.
The right places to call the function might be
board/solidrun/clearfog/clearfog.c and board/kobol/helios4/helios4.c as
these platforms enable CMD_TLV_EEPROM. But I have no such board.
The function has remained unused in upstream U-Boot since 2020. If we do
not plan to use it, it should be removed.
Stefan and Dennis, what are your thoughts?
Best regards
Heinrich
Shouldn't the EEPROM with the serial number be identified via the
device-tree?
Something like that would be nice.
However we also want to use identical device-tree between Linux and U-Boot.
I am not sure if we have such indication.
Best regards
Heinrich
{
char serialstr[257];
int eeprom_index;
struct tlvinfo_tlv *eeprom_tlv;
+ int devnum = 0; // TODO: support multiple EEPROMs
if (env_get("serial#"))
return 0;
- Josua Mayer
RE: How should I build u-boot for qemu_arm64_defconfig and run it on arm64 qemu virt machine?
Hello all, I found by compiling u-boot-spl to start at 0x4020 and using -kernel option, I can make u-boot-spl start loaded and started from 0x4020. And then by loading the .itb file (FIT file) which contains u-boot proper binary at 0x4040 using -device loader option, and setting CONFIG_SPL_LOAD_FIT_ADDERSS to 0x4040 and I could make u-boot-spl execute u-boot at the end. To make .itb file, I used 'firmware = "uboot"' int the configuration, and 'type = "standalone"', 'os = "U-Boot"' and the 'uboot' image node. And I turned off SPL_BOOT_OS of course. I referenced the sample its files in u-boot. (I can't copy-paste the file now so I just tell you the key lines) Hope this helps someone layter. Thank you. Chan Kim >-Original Message- >From: U-Boot On Behalf Of 김찬 >Sent: Tuesday, May 9, 2023 3:13 PM >To: U-Boot Mailing List ; qemu-disc...@nongnu.org >Subject: RE: How should I build u-boot for qemu_arm64_defconfig and run it >on arm64 qemu virt machine? > > >Hi all, > >Hope someone who know this top reads this. >I made the pflashs.img with u-boot-spl and used it as the flash memory (from >address 0x ~). So the u-boot-spl program runs. >And I guess I have to load (using qemu command option) a kind of image that >contains u-boot proper and make the u-boot-spl to load u-boot proper at >another address from that image and jump to that address. >How can I make that image using mkimage if I have the u-boot.bin file? >I think the command should start like 'mkimage -O u-boot -T ... ' but I >don't know what type I should give for -T option. >I will be very much grateful If anyone tells me how to do it. >By the way, I want to check pci_init function once u-boot proper runs and I >found pci_init is called in board_init_r when u-boot proper runs. > >Thank you! >Chan Kim > >-Original Message- >From: "Chan Kim" >To: "U-Boot Mailing List" ; disc...@nongnu.org>; >Cc: >Sent: 2023-05-08 (월) 18:40:49 (UTC+09:00) >Subject: How should I build u-boot for qemu_arm64_defconfig and run it on >arm64 qemu virt machine? > >Hello experts, > > > >Today I tried this test from scratch. > >In my environment, CROSS_COMPILE=aarch64-none-elf. > >Under u-boot directory, when I do 'make CROSS_COMPILE=aarch64-none-elf- >qemu_arm64_defconfig' and 'make -j28', I see this error at the end. > > > >aarch64-none-elf-ld.bfd: invalid length for memory region .sram > > > >after examining it, I added in include/configs/qemu-arm.h, > > > >#define CONFIG_SPL_MAX_SIZE value to 0x40 > > > >After fixing it, I got another similar error for .sdram and I added in >include/configs/qemu-arm.h, > > > >#define CONFIG_SPL_BSS_START_ADDR 0x4080 > >#define CONFIG_SPL_BSS_MAX_SIZE 0x10 > > > >Now I can do 'make -j28' with no error. > >But I found I have both 'u-boot' and 'spl/u-boot-spl' generated and I >realized for this qemu_arm64_defconfig, CONFIG_SPL=y and I get both u-boot >proper and u-boot spl. (SPL: secondary program loader, proper: main >bootloader. SPL runs first and the proper runs next). > > > >Until now I did objcopy of the u-boot(proper) and then extended it to >0x40 byte. (the pflash size of the virt machine which starts at address >0x). > >$ aarch64-none-elf-objcopy -O binary u-boot.v2022.07/u-boot pflashp.img > >$ dd if=/dev/zero of=pflashp.img bs=1c count=1 seek=67108863 > > > >And the qemu command is : > >$ qemu-6.2.0/build/aarch64-softmmu/qemu-system-aarch64 -machine virt,gic- >version=max,secure=on,virtualization=true -cpu max -drive >if=pflash,file=pflashp.img -m 2G -nographic -device >loader,file=linux-5.15.68/arch/arm64/boot/Image,addr=0x8020 > > > >The qemu virt machine has RAM from 0x4000 until 0xbfff. > >And I could see u-boot runs and it waits input for 3 seconds and outputs the >u-boot prompt. > >This is running u-boot (proper) from address 0 but since I have u-boot-spl >too, I should run it from u-boot-spl first, shouldn't I? > > > >How am I supposed to run u-boot-spl and u-boot on this qemu machine? (from >lds files, it looks like they both start at address 0). > >(qemu machine is arm64 virt machine, qemu 6.2.0). > > > > > >Thank you. > > > >Chan Kim > > >
Re: [PATCH v3 2/2] firmware: zynqmp: Move config object permission check
Hi,
Am 16.05.2023 um 10:26 schrieb Michal Simek:
Hi,
first of all sorry for delay.
On 4/27/23 12:31, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Move the check of the permission to change a config object from
zynqmp_pmufw_node function to zynqmp_pmufw_load_config_object function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v3:
- Added
drivers/firmware/firmware-zynqmp.c | 32 +++---
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 2b1ad5d2c3..d12159fa78 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -70,20 +70,11 @@ int zynqmp_pmufw_config_close(void)
int zynqmp_pmufw_node(u32 id)
{
- static bool skip_config;
- int ret;
-
- if (skip_config)
- return 0;
-
/* Record power domain id */
xpm_configobject[NODE_ID_LOCATION] = id;
- ret = zynqmp_pmufw_load_config_object(xpm_configobject,
- sizeof(xpm_configobject));
-
- if (ret == -EACCES && id == NODE_OCM_BANK_0)
- skip_config = true;
+ zynqmp_pmufw_load_config_object(xpm_configobject,
+ sizeof(xpm_configobject));
This is not right.
It should be
return zynqmp_pmufw_load... for error propagation.
At the moment the zynqmp_pmufw_node and zynqmp_pmufw_config_close
doesn't return an error. Should the zynqmp_pmufw_load_config_object
return 0 or -EACCES if it is skipped?
Regards
Stefan
Re: [PATCH 3/3] clang: Link with --no-pie instead of --apply-dynamic-relocs
On 5/14/23 09:28, Tom Rini wrote: Hi Tom! How extensively have you tested this change? I tested it in building for the arm/sunxi target. U-Boot does not build at all (on Clang+LLD) in its current state: ld.lld: error: section type mismatch for .gnu.version_r >>> :(.gnu.version_r): SHT_GNU_verneed >>> output section .gnu: SHT_GNU_versym However, I don't think I've reasoned correctly that --no-pie is the correct flag to pass, since I do see in arch/arm/config.mk: # needed for relocation LDFLAGS_u-boot += -pie ...and by passing --no-pie, I am just turning that right back off, getting a non-relocatable binary. So I should (and do) withdraw this patch, and will work to understand the situation better before retrying. It does seem that the present rule in the ARM target is to make a binary that assumes a .text base but includes some .rel.dyn relocations to make it optionally relocatable, so whatever flag we pass to LLD should preserve that behavior without bringing in unwanted sections (versym sections, .dynsym, .dynstr, ...) We don't install ld.lld in our container environment right now (but should..) and from some local testing I forget if we need to pass further make logic in to have ld.lld be used instead. To support both LTO and non-LTO cases, I pass: LTO_FINAL_LDFLAGS=-fuse-ld=lld LD=ld.lld Cheers, Sam
Re: [RFC PATCH 13/17] sunxi: add early Allwinner R528/T113 SoC support
On 12/5/22 17:45, Andre Przywara wrote: diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 3763ec3d2e4..1cda5e2 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -148,6 +148,10 @@ static int gpio_init(void) sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0); sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0); sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP); +#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_R528) + sunxi_gpio_set_cfgpin(SUNXI_GPE(2), 6); + sunxi_gpio_set_cfgpin(SUNXI_GPE(3), 6); + sunxi_gpio_set_pull(SUNXI_GPE(3), SUNXI_GPIO_PULL_UP); #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV) sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0); sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0); I'm a relative outsider to sunxi, but it does look like the NCAT2 generation's MUX is a lot more flexible in its UART assignments: e.g. while H3's UART1-3 only had one set of pins each UART could use, the T113 (my target) supports anywhere from 2-6 (typically 4) different options for each of its UARTs. It is not as simple as configuring which UART is the serial console anymore, because different boards might wire the console header to different pins. My particular target uses UART3 on pins PB6/PB7, for example. Since this patchset is updating the PIO driver anyway, maybe it's worth updating the (preprocessor, not runtime) logic in gpio_init to support getting the UART TX/RX pins from Kconfig, validating that the CONFIG_CONS_INDEX and pin selection are compatible, and setting the correct MUX function for those pins with a value pulled from a table?
Re: [RFC PATCH 08/17] sunxi: introduce NCAT2 generation model
Hi Andre! Thank you for your efforts on this patchset; I've been test-driving it a bit myself this week. On 12/5/22 17:45, Andre Przywara wrote: +#define SUNXI_RTC_BASE 0x0700 +#define SUNXI_R_CPUCFG_BASE0x07000400 +#define SUNXI_PRCM_BASE0x0701 +#define SUNXI_R_WDOG_BASE 0x07020400 +#define SUNXI_R_UART_BASE 0x0708 +#define SUNXI_R_TWI_BASE 0x07081400 How sure are we that this memory map is consistent across the whole NCAT2 family? The documentation for my target (T113-S3) puts the RTC base at 0x0709, for example. I find no mention of there being a PRCM peripheral in this particular chip either. diff --git a/common/spl/Kconfig b/common/spl/Kconfig index fef01bdd7da..fdd64db498f 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -265,7 +265,7 @@ config SPL_TEXT_BASE default 0x402F0400 if AM33XX default 0x40301350 if OMAP54XX default 0x10060 if MACH_SUN50I || MACH_SUN50I_H5 || MACH_SUN9I - default 0x20060 if SUN50I_GEN_H6 + default 0x20060 if SUN50I_GEN_H6 || SUNXI_GEN_NCAT2 default 0x00060 if ARCH_SUNXI default 0xfffc if ARCH_ZYNQMP default 0x0 Would it also be good to change the default for CONFIG_SPL_STACK? As-is it defaults to 0x8000, which would put it in the BROM region. Allwinner's boot0 starts its stack at 0x48000, which I've been using. diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h index 2f8b220f750..04d7aa3d632 100644 --- a/include/sunxi_gpio.h +++ b/include/sunxi_gpio.h @@ -16,6 +16,9 @@ #elif defined(CONFIG_SUN50I_GEN_H6) #define SUNXI_PIO_BASE0x0300b000 #define SUNXI_R_PIO_BASE 0x07022000 +#elif defined(CONFIG_SUNXI_GEN_NCAT2) +#define SUNXI_PIO_BASE 0x0200 +#define SUNXI_R_PIO_BASE 0 #else #define SUNXI_PIO_BASE0x01c20800 #define SUNXI_R_PIO_BASE 0x01f02c00 Code elsewhere assumes that SUNXI_R_PIO_BASE is nonzero; on my local branch in particular I had to update arch/arm/mach-sunxi/board.c:gpio_init. Perhaps it would be better to leave SUNXI_R_PIO_BASE undefined in the chips where this gadget is missing? Much gratitude, Sam
Re: [PATCH] sunxi: Fix typo in include guard
On 5/15/23 03:48, Andre Przywara wrote: Ahoy, Andre! > How did you find this? Just by accident? I was wondering if we could > check the tree automatically for those accidents. I found it both automatically and by accident. :) My cross-compiler of choice is Clang (as I don't have to rebuild/reinstall it for each target) and its enabled-by-default -Wheader-guard diagnostic flagged that for me. Regards, Sam
RE: [External] - Re: Issues with bcm2835-host: let firmware manage the clock divisor
Stefan > -Original Message- > From: Stefan Wahren > Sent: Tuesday, May 16, 2023 12:54 AM > To: Vincent Fazio ; Nuno Gonçalves > ; u-boot@lists.denx.de; pbrobin...@gmail.com > Subject: Re: [External] - Re: Issues with bcm2835-host: let firmware manage > the clock divisor > > Am 15.05.23 um 19:57 schrieb Vincent Fazio: > > Stefan > > > > > I'm not sure I understand the question here re DT/OF. The "regression" in > the RPi firmware was noticed both in EDK2 and in U-Boot when reading from > the SD card. The regression was _not_ apparent in RPi Linux, at least from > what I recall from my testing at the time, meaning that whatever the RPi > Linux kernel was doing was working around the issue, which is probably why > the regression happened in the first place since U-Boot/EDK2 are not targets > for support from RPF. > > Okay, are you able to list the effected bootchains (starting from RPi firmware > to Linux)? > > Example for a bootchain: > > RPi firmware -> U-Boot -> Linux As far as I'm aware, the issue [0] documents : RPi Firmware -> U-Boot RPi Firmware -> EDK2 RPi Firmware -> Ultibo I did not notice degraded performance in RPi Linux, presumably due to clock delegation [1] If someone is using linux-stable vs RPi Linux, there may be some variation. This was nearly 2 years ago however, I'm heavily relying on what's been documented in the GH issue [0]. [0] https://github.com/raspberrypi/firmware/issues/1619 [1] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-917370376 -Vincent
[PATCH] cmd: tlv_eeprom: fix signature for populate_serial_number function
populate_serial_number is not used internally for the tlv_eeprom
command, but rather provided as a library function for external use..
Remove the devnum that had recently been added by mistake, returning the
function to its original signature.
Instead place a 0-initialised member variable inside the function to
same purpose, along with a node that it only supports reading from the
first EEPROM in the system.
Fixes: dfda0c0 ("cmd: tlv_eeprom: remove use of global variable current_dev")
Signed-off-by: Josua Mayer
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heinrich Schuchardt
---
cmd/tlv_eeprom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 79796394c5c..0ca4d714645 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -1100,11 +1100,12 @@ int mac_read_from_eeprom(void)
*
* This function must be called after relocation.
*/
-int populate_serial_number(int devnum)
+int populate_serial_number(void)
{
char serialstr[257];
int eeprom_index;
struct tlvinfo_tlv *eeprom_tlv;
+ int devnum = 0; // TODO: support multiple EEPROMs
if (env_get("serial#"))
return 0;
--
2.35.3
Re: [PATCH] cmd: tlv_eeprom: fix signature for populate_serial_number function
On 5/16/23 10:27, Josua Mayer wrote:
populate_serial_number is not used internally for the tlv_eeprom
command, but rather provided as a library function for external use..
Remove the devnum that had recently been added by mistake, returning the
function to its original signature.
Instead place a 0-initialised member variable inside the function to
same purpose, along with a node that it only supports reading from the
%s/node/note/
first EEPROM in the system.
Fixes: dfda0c0 ("cmd: tlv_eeprom: remove use of global variable current_dev")
Signed-off-by: Josua Mayer
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heinrich Schuchardt
---
cmd/tlv_eeprom.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmd/tlv_eeprom.c b/cmd/tlv_eeprom.c
index 79796394c5c..0ca4d714645 100644
--- a/cmd/tlv_eeprom.c
+++ b/cmd/tlv_eeprom.c
@@ -1100,11 +1100,12 @@ int mac_read_from_eeprom(void)
*
* This function must be called after relocation.
*/
-int populate_serial_number(int devnum)
+int populate_serial_number(void)
If populate_serial_number() is to be used as a library function, it
should live in lib/ or possibly in drivers/misc/. The definition needs
to be provided in an include file. Otherwise the function should be deleted.
Where will this library function be used?
Shouldn't the EEPROM with the serial number be identified via the
device-tree?
Best regards
Heinrich
{
char serialstr[257];
int eeprom_index;
struct tlvinfo_tlv *eeprom_tlv;
+ int devnum = 0; // TODO: support multiple EEPROMs
if (env_get("serial#"))
return 0;
[RFC v2 1/3] lib: add tlv_eeprom library
Create a new tlv library by rewriting parts, and reusing other parts of
the tlv_eeprom command. This library is intended to simplify reading tlv
data during system initialisation from board files, as well as increase
maintainability by defining a clear API and functionally decouple from
the command implementation.
Signed-off-by: Josua Mayer
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heinrich Schuchardt
---
cmd/Kconfig | 2 +
include/tlv_eeprom.h | 272
lib/Kconfig | 2 +
lib/Makefile | 2 +
lib/tlv/Kconfig | 18 ++
lib/tlv/Makefile | 4 +
lib/tlv/tlv_eeprom.c | 599 +++
7 files changed, 899 insertions(+)
create mode 100644 lib/tlv/Kconfig
create mode 100644 lib/tlv/Makefile
create mode 100644 lib/tlv/tlv_eeprom.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 365371fb511..9c2149dc881 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -191,6 +191,7 @@ config CMD_REGINFO
config CMD_TLV_EEPROM
bool "tlv_eeprom"
depends on I2C_EEPROM
+ depends on !EEPROM_TLV_LIB
select CRC32
help
Display and program the system EEPROM data block in ONIE Tlvinfo
@@ -199,6 +200,7 @@ config CMD_TLV_EEPROM
config SPL_CMD_TLV_EEPROM
bool "tlv_eeprom for SPL"
depends on SPL_I2C_EEPROM
+ depends on !SPL_EEPROM_TLV_LIB
select SPL_DRIVERS_MISC
select SPL_CRC32
help
diff --git a/include/tlv_eeprom.h b/include/tlv_eeprom.h
index fd45e5f6ebb..b08c98a5833 100644
--- a/include/tlv_eeprom.h
+++ b/include/tlv_eeprom.h
@@ -7,6 +7,8 @@
#ifndef __TLV_EEPROM_H_
#define __TLV_EEPROM_H_
+#if !defined(CONFIG_EEPROM_TLV_LIB) && !defined(CONFIG_SPL_EEPROM_TLV_LIB)
+
/*
* The Definition of the TlvInfo EEPROM format can be found at onie.org or
* github.com/onie
@@ -150,4 +152,274 @@ static inline bool is_valid_tlvinfo_header(struct
tlvinfo_header *hdr)
(be16_to_cpu(hdr->totallen) <= TLV_TOTAL_LEN_MAX));
}
+#else
+
+/*
+ * The Definition of the TlvInfo EEPROM format can be found at onie.org or
+ * github.com/onie
+ */
+
+#include
+#include
+#include
+
+/* tlv library internal state, per each tlv structure */
+struct tlvinfo_priv;
+
+/*
+ * TlvInfo header: Layout of the header for the TlvInfo format
+ *
+ * See the end of this file for details of this eeprom format
+ */
+struct __attribute__ ((__packed__)) tlvinfo_header {
+ charsignature[8]; /* 0x00 - 0x07 EEPROM Tag "TlvInfo" */
+ u8 version; /* 0x08Structure version*/
+ u16 totallen; /* 0x09 - 0x0A Length of all data which follows */
+};
+
+// Header Field Constants
+#define TLV_INFO_HEADER_SIZEsizeof(struct tlvinfo_header)
+#define TLV_INFO_ID_STRING "TlvInfo"
+#define TLV_INFO_VERSION0x01
+#define TLV_INFO_MAX_LEN2048
+#define TLV_TOTAL_LEN_MAX (TLV_INFO_MAX_LEN - TLV_INFO_HEADER_SIZE)
+
+/*
+ * TlvInfo TLV: Layout of a TLV field
+ */
+struct __attribute__ ((__packed__)) tlvinfo_tlv {
+ u8 type;
+ u8 length;
+ u8 value[];
+};
+
+#define TLV_INFO_ENTRY_SIZE sizeof(struct tlvinfo_tlv)
+/* Maximum length of a TLV value in bytes */
+#define TLV_VALUE_MAX_LEN255
+
+/**
+ * The TLV Types.
+ *
+ * Keep these in sync with tlv_code_list in cmd/tlv_eeprom.c
+ */
+#define TLV_CODE_PRODUCT_NAME 0x21
+#define TLV_CODE_PART_NUMBER0x22
+#define TLV_CODE_SERIAL_NUMBER 0x23
+#define TLV_CODE_MAC_BASE 0x24
+#define TLV_CODE_MANUF_DATE 0x25
+#define TLV_CODE_DEVICE_VERSION 0x26
+#define TLV_CODE_LABEL_REVISION 0x27
+#define TLV_CODE_PLATFORM_NAME 0x28
+#define TLV_CODE_ONIE_VERSION 0x29
+#define TLV_CODE_MAC_SIZE 0x2A
+#define TLV_CODE_MANUF_NAME 0x2B
+#define TLV_CODE_MANUF_COUNTRY 0x2C
+#define TLV_CODE_VENDOR_NAME0x2D
+#define TLV_CODE_DIAG_VERSION 0x2E
+#define TLV_CODE_SERVICE_TAG0x2F
+#define TLV_CODE_VENDOR_EXT 0xFD
+#define TLV_CODE_CRC_32 0xFE
+
+/* how many EEPROMs can be used */
+#define MAX_TLV_DEVICES2
+
+/*
+ * EEPROM<->TLV API
+ */
+
+/**
+ * Find EEPROM device by index.
+ *
+ * @index: index of eeprom in the system, 0 = first.
+ * @return: handle to eeprom device on success, error pointer otherwise.
+ */
+struct udevice *tlv_eeprom_get_by_index(unsigned int index);
+
+/**
+ * Read TLV formatted data from EEPROM.
+ *
+ * @dev: EEPROM device handle.
+ * @offset: Offset into EEPROM to read from.
+ * @buffer: Buffer for storing TLV structure.
+ * @buffer_size: Size of the buffer.
+ * @return: Buffer initialised with TLV structure, or error pointer.
+ */
+struct tlvinfo_priv *tlv_eeprom_read(struct udevice *dev, int offset, u8
*buffer, size_t buffer_size);
+
+/**
+ * Write TLV formatted data to EEPROM.
+ *
+ * @dev: EEPROM device handle.
+ * @offset: Offset into EEPROM to write to.
+ * @tlv: Pointer to TLV structure.
+ * @return: Status code.
+ */
+int tlv_eeprom_write(struct udevice
[RFC v2 2/3] mvebu: clearfog: convert tlv parsing to use new library
Update the existing code reading tlv data from eeprom to use the new tlv
library functions rather than relying on tlv_eeprom command internals.
Signed-off-by: Josua Mayer
---
board/solidrun/common/tlv_data.c | 46
configs/clearfog_defconfig | 4 ++-
2 files changed, 20 insertions(+), 30 deletions(-)
diff --git a/board/solidrun/common/tlv_data.c b/board/solidrun/common/tlv_data.c
index 11d6e4a1380..31b4b473c75 100644
--- a/board/solidrun/common/tlv_data.c
+++ b/board/solidrun/common/tlv_data.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
#include "tlv_data.h"
@@ -50,44 +51,31 @@ static void parse_tlv_vendor_ext(struct tlvinfo_tlv
*tlv_entry,
td->ram_size = val[5];
}
-static void parse_tlv_data(u8 *eeprom, struct tlvinfo_header *hdr,
- struct tlvinfo_tlv *entry, struct tlv_data *td)
+static void parse_tlv_data(u8 *eeprom, struct tlvinfo_priv *tlv,
+ struct tlv_data *td)
{
- unsigned int tlv_offset, tlv_len;
-
- tlv_offset = sizeof(struct tlvinfo_header);
- tlv_len = sizeof(struct tlvinfo_header) + be16_to_cpu(hdr->totallen);
- while (tlv_offset < tlv_len) {
- entry = (struct tlvinfo_tlv *)[tlv_offset];
-
- switch (entry->type) {
- case TLV_CODE_PRODUCT_NAME:
- store_product_name(entry, td);
- break;
- case TLV_CODE_VENDOR_EXT:
- parse_tlv_vendor_ext(entry, td);
- break;
- default:
- break;
- }
-
- tlv_offset += sizeof(struct tlvinfo_tlv) + entry->length;
- }
+ struct tlvinfo_tlv *entry;
+
+ entry = tlv_entry_next_by_code(tlv, NULL, TLV_CODE_PRODUCT_NAME);
+ if (!IS_ERR(entry))
+ store_product_name(entry, td);
+
+ entry = tlv_entry_next_by_code(tlv, NULL, TLV_CODE_VENDOR_EXT);
+ if (!IS_ERR(entry))
+ parse_tlv_vendor_ext(entry, td);
}
void read_tlv_data(struct tlv_data *td)
{
u8 eeprom_data[TLV_TOTAL_LEN_MAX];
- struct tlvinfo_header *tlv_hdr;
- struct tlvinfo_tlv *tlv_entry;
- int ret, i;
+ struct tlvinfo_priv *priv;
+ int i;
for (i = 0; i < 2; i++) {
- ret = read_tlvinfo_tlv_eeprom(eeprom_data, _hdr,
- _entry, i);
- if (ret < 0)
+ priv = tlv_eeprom_read(tlv_eeprom_get_by_index(i), 0,
eeprom_data, ARRAY_SIZE(eeprom_data));
+ if (IS_ERR(priv))
continue;
- parse_tlv_data(eeprom_data, tlv_hdr, tlv_entry, td);
+ parse_tlv_data(eeprom_data, priv, td);
}
}
diff --git a/configs/clearfog_defconfig b/configs/clearfog_defconfig
index b3ed1ec7bbe..fa86b23ef40 100644
--- a/configs/clearfog_defconfig
+++ b/configs/clearfog_defconfig
@@ -35,7 +35,7 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y
# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
CONFIG_SPL_I2C=y
CONFIG_SYS_MAXARGS=32
-CONFIG_CMD_TLV_EEPROM=y
+# CONFIG_CMD_TLV_EEPROM is not set
CONFIG_SPL_CMD_TLV_EEPROM=y
# CONFIG_CMD_FLASH is not set
CONFIG_CMD_GPIO=y
@@ -81,3 +81,5 @@ CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET=0x0
+CONFIG_EEPROM_TLV_LIB=y
+CONFIG_SPL_EEPROM_TLV_LIB=y
--
2.35.3
[RFC v2 0/3] lib: tlv_eeprom: refactor API
The existing tlv_eeprom functionality has been designed as a single application living as a uboot command. The split into individual library and command, as well as attempts using this functionality extensively for board-identification have revealed several short-comings, such as: - Inconsistent naming convention - Inconsistent order of arguments - Stateful functions - Complex inter-dependencies between functions - Control of low-level information such as header checksums by command - Difficult to extend - No clear separation between eeprom access and tlv format - No support for multiple entries with same code (e.g. vendor extension) Introduce a new API with clear names and support for duplicate tlv codes. Further rewrite the tlv_eeprom command, and the solidrun clearfog board logic to utilize these new functions. This is the second draft, I am looking for: - comments on the library functions names + descriptions - comments on the use of udevice pointers, especially wrt. "tlv_eeprom_get_by_index" function that I am not sure about keeping Please note that there are still bugs and untested functions in this version. I am planning to provide a complete result in the coming weeks. Josua Mayer (3): lib: add tlv_eeprom library mvebu: clearfog: convert tlv parsing to use new library cmd: tlv_eeprom: port to new shared tlv library board/solidrun/common/tlv_data.c | 46 +-- cmd/Kconfig | 7 +- cmd/tlv_eeprom.c | 507 +- configs/clearfog_defconfig | 2 + include/tlv_eeprom.h | 242 ++--- lib/Kconfig | 2 + lib/Makefile | 2 + lib/tlv/Kconfig | 18 + lib/tlv/Makefile | 4 + lib/tlv/tlv_eeprom.c | 599 +++ 10 files changed, 918 insertions(+), 511 deletions(-) create mode 100644 lib/tlv/Kconfig create mode 100644 lib/tlv/Makefile create mode 100644 lib/tlv/tlv_eeprom.c Cc: Stefan Roese Cc: Baruch Siach Cc: Heinrich Schuchardt -- 2.35.3
Re: mmc: Read eMMC partition access bits before card reset
On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > Author: Pali Rohár > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says > > > > > > > > > that all reset > > > > > > > > > events will restore the access bits in PARTITION_CONFIG > > > > > > > > > CSD register to > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > > > register before > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > information which eMMC > > > > > > > > > partition was in use before SPL/U-Boot was booted. For > > > > > > > > > some platforms this > > > > > > > > > is the way how to determinate boot partition from which > > > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > > 13:10:10 -0400) > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Tom > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to hide > > > > > > > > this code > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For example > > > > > > > > by this: > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > > > failure I > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not > > > > > > know if > > > > > > card is SD or MMC. > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine on > > > > > > mvebu > > > > > > clearfog? > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > fsm 0, hsts > > > > > > > ... > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above > > > > > > > one and > > > > > > > the board is fine again. > > > > > > > > > > > > > > -- > > > > > > > Tom > > > > > > > > > > > > Immediately after that "problematic code" is card reset function. So > > > > > > another reason for failure is that card reset functionality does not > > > > > > work correctly on your board / platform. > > > > > > > > > > Well, we're at two different platforms and controllers that this > > > > > change > > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > > > > the > > > > > same general era as am335x fails the same way (not a surprise), > > > > > amlogic > > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI platforms > > > > > are > > > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > > > > platforms > > > > > that work are not ARCH_OMAP2PLUS). > > > > > > > > > > -- > > > > > Tom > > > > > > > > And do you see this problem in SPL or in proper U-Boot? > > > > > > > > If omap2plus is problematic then I can do tests on Nokia N900 or at its > > > > qemu emulated version (to which can be attached gdb). But Nokia N900 is > > > > without SPL. > > > > > > > > > OK, so on am335x_evm
[GIT PULL] xilinx patches for v2023.07-rc3
Hi Tom, please pull these changes to your tree. CI is not showing any issue. https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/16372 Thanks, Michal The following changes since commit 177e506952a8ee34011590c4bd578d191fafb1ca: Merge branch '2023-05-13-bootstd-updates-and-improvements' (2023-05-14 11:27:18 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2023.07-rc3 for you to fetch changes up to 3f71daa16bf39561984dfbab9b1047e180c9e8ea: .mailmap: Map all Xilinx users mail ids to AMD (2023-05-15 09:33:57 +0200) Xilinx changes for v2023.07-rc3 .mailmap - Fix Xilinx IDs ZynqMP: - Fix R5 split boot mode - DT fixes - sync with Linux Xilinx: - Enable virtio and RNG support - Enable ADI ethernet phy SPI/Zynq: - Fix dummy byte calculation Algapally Santosh Sagar (2): .mailmap: Sort the mailmap ids in dictionary order .mailmap: Map all Xilinx users mail ids to AMD Ashok Reddy Soma (3): arm64: zynqmp: Fix issue of apps executing from R5 core 1 arm64: zynqmp: Enable ADIN ethernet phy arm64: versal: Enable ADIN ethernet phy Michal Simek (4): xilinx: Enable virtio mmio transport and devices ARM: zynq: Switch from earlyprintk to earlycon ARM: zynq: Sync Microzed board with Linux kernel arm64: zynqmp: Fix User MTD partition size Neal Frager (1): arch: arm: zynqmp: mp.c: tcminit halt both cores in split mode Stefan Herbrechtsmeier (1): Revert "spi: zynq_qspi: Use dummy buswidth in dummy byte calculation" .mailmap | 81 arch/arm/dts/zynq-dlc20-rev1.0.dts | 2 +- arch/arm/dts/zynq-microzed.dts | 44 +-- arch/arm/dts/zynqmp-sm-k26-revA.dts | 2 +- arch/arm/mach-zynqmp/mp.c| 28 --- configs/xilinx_versal_net_virt_defconfig | 5 ++ configs/xilinx_versal_virt_defconfig | 6 ++ configs/xilinx_zynqmp_virt_defconfig | 5 ++ drivers/spi/zynq_qspi.c | 10 +-- 9 files changed, 139 insertions(+), 44 deletions(-)
Re: [PATCH] include: Remove unused header files
On 5/16/23 16:09, Tom Rini wrote: On Tue, May 16, 2023 at 04:08:10PM +0300, Eugen Hristev wrote: On 5/15/23 21:01, Tom Rini wrote: As part of various code clean-ups we have on occasion missed removing unused header files. None of these files are referenced anywhere else at this point. Signed-off-by: Tom Rini --- arch/arm/include/asm/arch-bcmcygnus/configs.h | 18 - arch/arm/include/asm/arch-bcmnsp/configs.h| 17 - arch/arm/include/asm/arch-imxrt/imxrt.h | 10 - arch/arm/include/asm/arch-lpc32xx/gpio_grp.h | 39 - arch/arm/include/asm/arch-mx27/mxcmmc.h | 11 - arch/arm/include/asm/arch-mx6/opos6ul.h | 11 - arch/arm/include/asm/arch-mxs/regs-uartapp.h | 219 --- arch/arm/include/asm/arch-omap3/omap3-regs.h | 78 - arch/arm/include/asm/arch-omap5/mux_omap5.h | 317 arch/arm/include/asm/iproc-common/configs.h | 14 - .../include/asm/iproc-common/iproc_sdhci.h| 12 - arch/arm/include/asm/kona-common/kona_sdhci.h | 11 - arch/arm/mach-at91/include/mach/at91_rtt.h| 32 - arch/arm/mach-at91/include/mach/sama7-sfr.h | 59 - Hi Tom, The sama7 SFR is to be used with patches that are pending, not yet merged. Could you please avoid removing this file ? OK. Is that the only one? For future reference, it's best to not include headers / etc until they're going to be used. Thanks. Well, the fact is that the header file is part of the arch , thus going through the at91 tree, but it's referenced in some USB patches, that are assigned to Marek and going through the USB tree. Since he could not take the patches without the header, I applied it first, and now waiting for him to send the PR for the USB patches using it. You could ask why they are not in the same patch, well, Marek asked for separate patches for arch changes and USB changes. Eugen
Re: [RESEND PATCH v2 2/2] samsung: common: do not reset if cros-ec uclass is missing
On Tue, May 09, 2023 at 09:05:47PM +0200, Henrik Grimler wrote:
> Otherwise non-ChromeOS samsung devices, like the odroid boards, are
> stuck in a bootloop if CONFIG_CROS_EC is not enabled:
>
> <...>
> MMC: SAMSUNG SDHCI: 2, EXYNOS DWMMC: 0
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> cros-ec communications failure -96
>
> Please reset with Power+Refresh
>
> Cannot init cros-ec device
> resetting ...
>
> Issue started after commit e44d7e73fe0d ("dm: core: Switch
> uclass_*_device_err to use uclass_*_device_check").
>
> Signed-off-by: Henrik Grimler
> Reviewed-by: Simon Glass
> Reviewed-by: Minkyu Kang
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] video: tweak CONFIG_SPL_VIDEO description
On Tue, May 09, 2023 at 12:02:50PM +0100, John Keeping wrote: > Make it clear that this is the SPL option to avoid potential confusion > when the description for CONFIG_SPL_VIDEO is the same as that for > CONFIG_VIDEO. > > Signed-off-by: John Keeping Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND PATCH v2 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
On Tue, May 09, 2023 at 09:05:46PM +0200, Henrik Grimler wrote:
> This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
>
> Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
> there are data"") reverted the alternative fix that was added for
> Exynos 4 devices, causing an error when trying to boot from an sdcard:
>
> <...>
> Loading Environment from MMC... sdhci_send_command: Timeout for status
> update!
> mmc fail to send stop cmd
> <...>
>
> Re-add the quirk to allow booting from sdcards again.
>
> Signed-off-by: Henrik Grimler
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [GIT PULL] xilinx patches for v2023.07-rc3
On Tue, May 16, 2023 at 02:59:29PM +0200, Michal Simek wrote: > Hi Tom, > > please pull these changes to your tree. > CI is not showing any issue. > https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/pipelines/16372 > > Thanks, > Michal > > The following changes since commit 177e506952a8ee34011590c4bd578d191fafb1ca: > > Merge branch '2023-05-13-bootstd-updates-and-improvements' (2023-05-14 > 11:27:18 -0400) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2023.07-rc3 > > for you to fetch changes up to 3f71daa16bf39561984dfbab9b1047e180c9e8ea: > > .mailmap: Map all Xilinx users mail ids to AMD (2023-05-15 09:33:57 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v3 2/2] firmware: zynqmp: Move permission to change config object message
From: Stefan Herbrechtsmeier
Move the permission to change a config object message from
zynqmp_pmufw_load_config_object function to zynqmp_pmufw_node function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v4:
- Reword
- Move the check back to zynqmp_pmufw_node because the check need to be
run after the config object load.
- Return error in zynqmp_pmufw_config_close and zynqmp_pmufw_node
Changes in v3:
- Added
drivers/firmware/firmware-zynqmp.c | 36 ++
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 2b1ad5d2c3..6dc745bd14 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -63,29 +63,32 @@ static unsigned int xpm_configobject_close[] = {
int zynqmp_pmufw_config_close(void)
{
- zynqmp_pmufw_load_config_object(xpm_configobject_close,
- sizeof(xpm_configobject_close));
- return 0;
+ return zynqmp_pmufw_load_config_object(xpm_configobject_close,
+ sizeof(xpm_configobject_close));
}
int zynqmp_pmufw_node(u32 id)
{
- static bool skip_config;
- int ret;
+ static bool checked;
+ static bool skip;
- if (skip_config)
- return 0;
+ if (!checked) {
+ checked = true;
- /* Record power domain id */
- xpm_configobject[NODE_ID_LOCATION] = id;
+ if (zynqmp_pmufw_node(NODE_OCM_BANK_0) == -EACCES) {
+ printf("PMUFW: No permission to change config
object\n");
+ skip = true;
+ }
+ }
- ret = zynqmp_pmufw_load_config_object(xpm_configobject,
- sizeof(xpm_configobject));
+ if (skip)
+ return -EACCES;
- if (ret == -EACCES && id == NODE_OCM_BANK_0)
- skip_config = true;
+ /* Record power domain id */
+ xpm_configobject[NODE_ID_LOCATION] = id;
- return 0;
+ return zynqmp_pmufw_load_config_object(xpm_configobject,
+ sizeof(xpm_configobject));
}
static int do_pm_probe(void)
@@ -250,8 +253,6 @@ int zynqmp_pmufw_load_config_object(const void *cfg_obj,
size_t size)
err = xilinx_pm_request(PM_SET_CONFIGURATION, (u32)(u64)cfg_obj, 0, 0,
0, ret_payload);
if (err == XST_PM_NO_ACCESS) {
- if (((u32 *)cfg_obj)[NODE_ID_LOCATION] == NODE_OCM_BANK_0)
- printf("PMUFW: No permission to change config
object\n");
return -EACCES;
}
@@ -295,9 +296,6 @@ static int zynqmp_power_probe(struct udevice *dev)
ret >> ZYNQMP_PM_VERSION_MAJOR_SHIFT,
ret & ZYNQMP_PM_VERSION_MINOR_MASK);
- if (IS_ENABLED(CONFIG_ARCH_ZYNQMP))
- zynqmp_pmufw_node(NODE_OCM_BANK_0);
-
return 0;
};
--
2.30.2
[PATCH v3 1/2] firmware: zynqmp: Remove extraordinary return value
From: Stefan Herbrechtsmeier
Return a common -EACCES error value instead of a positive private error
value XST_PM_NO_ACCESS (2002) in zynqmp_pmufw_load_config_object
function if the config object is not loadable to simplify the error
checking.
Signed-off-by: Stefan Herbrechtsmeier
---
(no changes since v3)
Changes in v3:
- Rebase
Changes in v2:
- Use macro for node id
drivers/firmware/firmware-zynqmp.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index dc8e3ad2b9..2b1ad5d2c3 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -82,7 +82,7 @@ int zynqmp_pmufw_node(u32 id)
ret = zynqmp_pmufw_load_config_object(xpm_configobject,
sizeof(xpm_configobject));
- if (ret == XST_PM_NO_ACCESS && id == NODE_OCM_BANK_0)
+ if (ret == -EACCES && id == NODE_OCM_BANK_0)
skip_config = true;
return 0;
@@ -235,8 +235,7 @@ int zynqmp_pm_is_function_supported(const u32 api_id, const
u32 id)
*
* @cfg_obj: Pointer to the configuration object
* @size:Size of @cfg_obj in bytes
- * Return: 0 on success otherwise negative errno. If the config object
- * is not loadable returns positive errno XST_PM_NO_ACCESS(2002)
+ * Return: 0 on success otherwise negative errno.
*/
int zynqmp_pmufw_load_config_object(const void *cfg_obj, size_t size)
{
@@ -251,10 +250,8 @@ int zynqmp_pmufw_load_config_object(const void *cfg_obj,
size_t size)
err = xilinx_pm_request(PM_SET_CONFIGURATION, (u32)(u64)cfg_obj, 0, 0,
0, ret_payload);
if (err == XST_PM_NO_ACCESS) {
- if (((u32 *)cfg_obj)[NODE_ID_LOCATION] == NODE_OCM_BANK_0) {
+ if (((u32 *)cfg_obj)[NODE_ID_LOCATION] == NODE_OCM_BANK_0)
printf("PMUFW: No permission to change config
object\n");
- return err;
- }
return -EACCES;
}
--
2.30.2
[RFC PATCH] mmc: zynq_sdhci: Dependable card detect
From: Stefan Herbrechtsmeier
The card detect logic needs a short card present signal to work
dependable. Without a present card the SDHCI_CARD_STATE_STABLE signal is
not set dependable after a reset. Use the internal fixed card present
signal to initiate the card detect logic.
Signed-off-by: Stefan Herbrechtsmeier
---
On our hardware we get a "Sdhci card detect state not stable" error in
the SPL if no mmc card is present. It is unclear if this patch is the
correct solution, but a short card inserts or a fixed card present
signal leads to a SDHCI_CARD_STATE_STABLE signal with and without card.
drivers/mmc/zynq_sdhci.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index e44868aaec..a88feeb367 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -1075,6 +1075,26 @@ static int sdhci_zynqmp_set_dynamic_config(struct
arasan_sdhci_priv *priv,
return ret;
}
+ /* The card detect logic needs a short card present signal to work
+* dependable. Without a present card the SDHCI_CARD_STATE_STABLE
+* signal is not set dependable after a reset. Use the internal
+* fixed card present signal to initiate the card detect logic.
+*/
+ if (!dev_read_bool(dev, "non-removable")) {
+ ret = zynqmp_pm_set_sd_config(priv->node_id, SD_CONFIG_EMMC_SEL,
+ 1);
+ if (ret) {
+ dev_err(dev, "SD_CONFIG_EMMC_SEL failed\n");
+ return ret;
+ }
+ ret = zynqmp_pm_set_sd_config(priv->node_id, SD_CONFIG_EMMC_SEL,
+ 0);
+ if (ret) {
+ dev_err(dev, "SD_CONFIG_EMMC_SEL failed\n");
+ return ret;
+ }
+ }
+
return 0;
}
#endif
--
2.30.2
[PATCH v2] arm64: versal-net: Detect and display bootmode
Read boodmode register using versal_net_get_bootmode() in board_late_init
and prepare corresponding distro boot command sequence based on it.
versal_net_get_bootmode() will be changed to use smc calls later, but
for now directly reads the register.
Signed-off-by: Ashok Reddy Soma
---
Changes in v2:
- Remove check for mmc/sdhci node enabled or not in EMMC bootmode
- Remove check for sdhci node enabled or not in SD0 and SD1 bootmode
.../mach-versal-net/include/mach/hardware.h | 21
board/xilinx/versal-net/board.c | 114 ++
2 files changed, 135 insertions(+)
diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h
b/arch/arm/mach-versal-net/include/mach/hardware.h
index c5e4e22040..89b84a2efc 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -27,7 +27,13 @@ struct iou_scntrs_regs {
u32 base_frequency_id_register; /* 0x20 */
};
+struct crp_regs {
+ u32 reserved0[128];
+ u32 boot_mode_usr; /* 0x200 */
+};
+
#define VERSAL_NET_CRL_APB_BASEADDR0xEB5E
+#define VERSAL_NET_CRP_BASEADDR0xF126
#define VERSAL_NET_IOU_SCNTR_SECURE0xEC92
#define CRL_APB_TIMESTAMP_REF_CTRL_CLKACT_BIT BIT(25)
@@ -36,6 +42,7 @@ struct iou_scntrs_regs {
#define IOU_SCNTRS_CONTROL_EN 1
#define crlapb_base ((struct crlapb_regs *)VERSAL_NET_CRL_APB_BASEADDR)
+#define crp_base ((struct crp_regs *)VERSAL_NET_CRP_BASEADDR)
#define iou_scntr_secure ((struct iou_scntrs_regs
*)VERSAL_NET_IOU_SCNTR_SECURE)
#define PMC_TAP0xF11A
@@ -49,6 +56,20 @@ struct iou_scntrs_regs {
# define PLATFORM_VERSION_MASK GENMASK(31, 28)
#define PMC_TAP_USERCODE (PMC_TAP + 0x8)
+/* Bootmode setting values */
+#define BOOT_MODES_MASK0x000F
+#define QSPI_MODE_24BIT0x0001
+#define QSPI_MODE_32BIT0x0002
+#define SD_MODE0x0003 /* sd 0 */
+#define SD_MODE1 0x0005 /* sd 1 */
+#define EMMC_MODE 0x0006
+#define USB_MODE 0x0007
+#define OSPI_MODE 0x0008
+#define SD1_LSHFT_MODE 0x000E /* SD1 Level shifter */
+#define JTAG_MODE 0x
+#define BOOT_MODE_USE_ALT 0x100
+#define BOOT_MODE_ALT_SHIFT12
+
enum versal_net_platform {
VERSAL_NET_SILICON = 0,
VERSAL_NET_SPP = 1,
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index 6724c7290f..6595d6f3e8 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -165,8 +166,32 @@ int board_early_init_r(void)
return 0;
}
+static u8 versal_net_get_bootmode(void)
+{
+ u8 bootmode;
+ u32 reg = 0;
+
+ reg = readl(_base->boot_mode_usr);
+
+ if (reg >> BOOT_MODE_ALT_SHIFT)
+ reg >>= BOOT_MODE_ALT_SHIFT;
+
+ bootmode = reg & BOOT_MODES_MASK;
+
+ return bootmode;
+}
+
int board_late_init(void)
{
+ u8 bootmode;
+ struct udevice *dev;
+ int bootseq = -1;
+ int bootseq_len = 0;
+ int env_targets_len = 0;
+ const char *mode;
+ char *new_targets;
+ char *env_targets;
+
if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
debug("Saved variables - Skipping\n");
return 0;
@@ -175,6 +200,95 @@ int board_late_init(void)
if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
return 0;
+ bootmode = versal_net_get_bootmode();
+
+ puts("Bootmode: ");
+ switch (bootmode) {
+ case USB_MODE:
+ puts("USB_MODE\n");
+ mode = "usb_dfu0 usb_dfu1";
+ break;
+ case JTAG_MODE:
+ puts("JTAG_MODE\n");
+ mode = "jtag pxe dhcp";
+ break;
+ case QSPI_MODE_24BIT:
+ puts("QSPI_MODE_24\n");
+ mode = "xspi0";
+ break;
+ case QSPI_MODE_32BIT:
+ puts("QSPI_MODE_32\n");
+ mode = "xspi0";
+ break;
+ case OSPI_MODE:
+ puts("OSPI_MODE\n");
+ mode = "xspi0";
+ break;
+ case EMMC_MODE:
+ puts("EMMC_MODE\n");
+ mode = "mmc";
+ bootseq = dev_seq(dev);
+ break;
+ case SD_MODE:
+ puts("SD_MODE\n");
+ if (uclass_get_device_by_name(UCLASS_MMC,
+ "mmc@f104", )) {
+ puts("Boot from SD0 but without SD0 enabled!\n");
+ return -1;
+ }
+ debug("mmc0 device found at %p, seq %d\n", dev, dev_seq(dev));
+
+ mode = "mmc";
+ bootseq = dev_seq(dev);
+ break;
+ case SD1_LSHFT_MODE:
+
Re: [PATCH v3 1/3] Move bootorder and bootoption apis to lib
Hi Ilias,
I think we can address Heinrich's comments in a follow up patch set.
The concerns are more related to refactoring on the logic of existing
functions and less to the functionality we want to enable with these
patches.
Thanks.
Regards,
Raymond
On Tue, 16 May 2023 at 01:58, Ilias Apalodimas
wrote:
> Hi Raymond,
>
> Heinrichm you had some concerns on the previous version of this patchset
> wrt to the current code. Do you think the rework should take place here?
> Or are you ok in cleaning it up in a follow up series?
>
> Thanks
> /Ilias
> On Tue, May 02, 2023 at 12:12:17PM -0700, Raymond Mao wrote:
> > Rename and move bootorder and bootoption apis from cmd to lib
> > for re-use between eficonfig and bootmgr
> >
> > Signed-off-by: Raymond Mao
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> > efi_bootmgr_update_media_device_boot_option which means no boot
> > options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> > individual patches for each changed functionality
> >
> > cmd/bootmenu.c | 2 +-
> > cmd/eficonfig.c | 408 +--
> > include/efi_config.h | 5 -
> > include/efi_loader.h | 11 +
> > lib/efi_loader/efi_bootmgr.c | 380
> > lib/efi_loader/efi_helper.c | 25 +++
> > 6 files changed, 423 insertions(+), 408 deletions(-)
> >
> > diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
> > index 6baeedc69f..01daddca7b 100644
> > --- a/cmd/bootmenu.c
> > +++ b/cmd/bootmenu.c
> > @@ -351,7 +351,7 @@ static struct bootmenu_data *bootmenu_create(int
> delay)
> >* UEFI specification requires booting from removal media
> using
> >* a architecture-specific default image name such as
> BOOTAA64.EFI.
> >*/
> > - efi_ret = eficonfig_generate_media_device_boot_option();
> > + efi_ret = efi_bootmgr_update_media_device_boot_option();
> > if (efi_ret != EFI_SUCCESS && efi_ret != EFI_NOT_FOUND)
> > goto cleanup;
> >
> > diff --git a/cmd/eficonfig.c b/cmd/eficonfig.c
> > index 720f52b48b..82a80306f4 100644
> > --- a/cmd/eficonfig.c
> > +++ b/cmd/eficonfig.c
> > @@ -1134,43 +1134,6 @@ out:
> > return ret;
> > }
> >
> > -/**
> > - * eficonfig_get_unused_bootoption() - get unused "Boot" index
> > - *
> > - * @buf: pointer to the buffer to store boot option variable name
> > - * @buf_size:buffer size
> > - * @index: pointer to store the index in the BootOrder variable
> > - * Return: status code
> > - */
> > -efi_status_t eficonfig_get_unused_bootoption(u16 *buf, efi_uintn_t
> buf_size,
> > - unsigned int *index)
> > -{
> > - u32 i;
> > - efi_status_t ret;
> > - efi_uintn_t size;
> > -
> > - if (buf_size < u16_strsize(u"Boot"))
> > - return EFI_BUFFER_TOO_SMALL;
> > -
> > - for (i = 0; i <= 0x; i++) {
> > - size = 0;
> > - efi_create_indexed_name(buf, buf_size, "Boot", i);
> > - ret = efi_get_variable_int(buf, _global_variable_guid,
> > -NULL, , NULL, NULL);
> > - if (ret == EFI_BUFFER_TOO_SMALL)
> > - continue;
> > - else
> > - break;
> > - }
> > -
> > - if (i > 0x)
> > - return EFI_OUT_OF_RESOURCES;
> > -
> > - *index = i;
> > -
> > - return EFI_SUCCESS;
> > -}
> > -
> > /**
> > * eficonfig_set_boot_option() - set boot option
> > *
> > @@ -1208,46 +1171,6 @@ static efi_status_t eficonfig_set_boot_option(u16
> *varname, struct efi_device_pa
> > return ret;
> > }
> >
> > -/**
> > - * eficonfig_append_bootorder() - append new boot option in BootOrder
> variable
> > - *
> > - * @index: "Boot" index to append to BootOrder variable
> > - * Return: status code
> > - */
> > -efi_status_t eficonfig_append_bootorder(u16 index)
> > -{
> > - u16 *bootorder;
> > - efi_status_t ret;
> > - u16 *new_bootorder = NULL;
> > - efi_uintn_t last, size, new_size;
> > -
> > - /* append new boot option */
> > - bootorder = efi_get_var(u"BootOrder", _global_variable_guid,
> );
> > - last = size / sizeof(u16);
> > - new_size = size + sizeof(u16);
> > - new_bootorder = calloc(1, new_size);
> > - if (!new_bootorder) {
> > - ret = EFI_OUT_OF_RESOURCES;
> > - goto out;
> > - }
> > - memcpy(new_bootorder, bootorder, size);
> > - new_bootorder[last] = index;
> > -
> > - ret = efi_set_variable_int(u"BootOrder", _global_variable_guid,
> > -EFI_VARIABLE_NON_VOLATILE |
> > -EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > -EFI_VARIABLE_RUNTIME_ACCESS,
> > -new_size, new_bootorder,
Re: [PATCH v3 3/3] Load option with short device path for boot vars
Hi Ilias,
On Tue, 16 May 2023 at 01:57, Ilias Apalodimas
wrote:
> Hi Raymond,
>
> On Tue, May 02, 2023 at 12:12:21PM -0700, Raymond Mao wrote:
> > The boot variables automatically generated for removable medias
> > should be with short form of device path without device nodes.
> > This is a requirement for the case that a removable media is
> > plugged into a different port but is still able to work with the
> > existing boot variables.
> >
> > Signed-off-by: Raymond Mao
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> > efi_bootmgr_update_media_device_boot_option which means no boot
> > options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> > individual patches for each changed functionality
> >
> > cmd/bootmenu.c| 2 +-
> > cmd/eficonfig.c | 2 +-
> > include/efi_loader.h | 2 +-
> > lib/efi_loader/efi_bootmgr.c | 16 +---
> > lib/efi_loader/efi_disk.c | 2 +-
> > lib/efi_loader/efi_variable.c | 2 +-
> > lib/efi_loader/efi_variable_tee.c | 2 +-
> > 7 files changed, 19 insertions(+), 9 deletions(-)
>
> [...]
>
> > * @count: number of efi handle
> > + * @short_path: use short form device path for matching
> > * Return: status code
> > */
> > static efi_status_t efi_bootmgr_enumerate_boot_option(struct
> eficonfig_media_boot_option *opt,
> > efi_handle_t
> *volume_handles,
> > - efi_status_t count)
> > + efi_status_t count,
> > + bool short_path)
>
> Are there cases where the normal device path is used? If not we can get rid
> of the bool option entirely
>
[RM] At the moment no. I can revise the patch to remove the bool option if
we don't want to reserve the ability to support normal device paths for the
future.
>
> > {
> > u32 i;
> > struct efi_handler *handler;
> > @@ -387,6 +389,13 @@ static efi_status_t
> efi_bootmgr_enumerate_boot_option(struct eficonfig_media_boo
> > p = dev_name;
> > utf8_utf16_strncpy(, buf, strlen(buf));
> >
> > + /* use short form device path */
> > + if (short_path) {
> > + device_path = efi_dp_shorten(device_path);
> > + if (!device_path)
> > + continue;
> > + }
> > +
> > lo.label = dev_name;
> > lo.attributes = LOAD_OPTION_ACTIVE;
> > lo.file_path = device_path;
>
> [...]
>
> Thanks
> /Ilias
>
Re: [PATCH v3 2/3] Boot var automatic management for removable medias
Hi Ilias,
On Tue, 16 May 2023 at 01:59, Ilias Apalodimas
wrote:
> On Tue, May 02, 2023 at 12:12:19PM -0700, Raymond Mao wrote:
> > Changes for complying to EFI spec §3.5.1.1
> > 'Removable Media Boot Behavior'.
> > Boot variables can be automatically generated during a removable
> > media is probed. At the same time, unused boot variables will be
> > detected and removed.
> >
> > Signed-off-by: Raymond Mao
> > ---
> > Changes in v2
> > - Ignore EFI_NOT_FOUND returned from
> > efi_bootmgr_update_media_device_boot_option which means no boot
> > options scanned.
> > Changes in v3
> > - Split the patch into moving and renaming functions and
> > individual patches for each changed functionality
> >
> > lib/efi_loader/efi_disk.c | 7 +++
> > lib/efi_loader/efi_variable.c | 10 +-
> > lib/efi_loader/efi_variable_tee.c | 5 +
> > 3 files changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> > index d2256713a8..ca5f07f2ec 100644
> > --- a/lib/efi_loader/efi_disk.c
> > +++ b/lib/efi_loader/efi_disk.c
> > @@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
> > return -1;
> > }
> >
> > + /* only do the boot option management when UEFI sub-system is
> initialized */
> > + if (efi_obj_list_initialized == EFI_SUCCESS) {
> > + ret = efi_bootmgr_update_media_device_boot_option();
> > + if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
> > + return -1;
> > + }
> > +
> > return 0;
> > }
> >
> > diff --git a/lib/efi_loader/efi_variable.c
> b/lib/efi_loader/efi_variable.c
> > index be95ed44e6..fe71144358 100644
> > --- a/lib/efi_loader/efi_variable.c
> > +++ b/lib/efi_loader/efi_variable.c
> > @@ -476,6 +476,14 @@ efi_status_t efi_init_variables(void)
> > log_err("Invalid EFI variable seed\n");
> > }
> >
> > + ret = efi_init_secure_state();
> > + if (ret != EFI_SUCCESS)
> > + return ret;
> >
> > - return efi_init_secure_state();
> > + /* update boot option management after variable service
> initialized */
> > + ret = efi_bootmgr_update_media_device_boot_option();
> > + if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
> > + return ret;
> > +
> > + return EFI_SUCCESS;
> > }
> > diff --git a/lib/efi_loader/efi_variable_tee.c
> b/lib/efi_loader/efi_variable_tee.c
> > index dfef18435d..2995d4a583 100644
> > --- a/lib/efi_loader/efi_variable_tee.c
> > +++ b/lib/efi_loader/efi_variable_tee.c
> > @@ -748,5 +748,10 @@ efi_status_t efi_init_variables(void)
> > if (ret != EFI_SUCCESS)
> > return ret;
> >
> > + /* update boot option management after variable service
> initialized */
> > + ret = efi_bootmgr_update_media_device_boot_option();
> > + if (ret != EFI_SUCCESS && ret != EFI_NOT_FOUND)
> > + return ret;
>
> You don't need this if, just return ret
>
We have to differentiate EFI_NOT_FOUND here for no removable medias are
detected, otherwise efi_init_obj_list() will return failure if the return
code of efi_init_variables() is not EFI_SUCCESS.
>
> > +
> > return EFI_SUCCESS;
> > }
> > --
> > 2.25.1
> >
>
> Regards
> /Ilias
>
Re: [V3,1/1] riscv: Increase the upper bound of NR_CPUS to 4095
On 2/13/23 09:43, Leo Yu-Chi Liang wrote:
From: Xiang W
The maximum hart number is 32 and is determined by
the type of gd->arch.available_harts. However, various
RISC-V specifications allow the hart number to be greater
than 32. We can eliminate this limitation through bitmaps.
The patch modifies the upper bound of the hart number to 4095,
which is also the maximum hart number RISC-V Advanced Core Local
Interruptor Specification gives.
Some defconfigs, (e.g. qemu-riscv32_smode_defconfig,
qemu-riscv64_smode_defconfig, openpiton_riscv64_defconfig, ...)
do not define CONFIG_NR_CPUS, and may result in compile error,
so define CONFIG_NR_CPUS to be 1 if CONFIG_NR_CPUS is not defined.
Tested on sifive unmatched.
Signed-off-by: Xiang W
Signed-off-by: Leo Yu-Chi Liang
---
Changes v2 -> v3:
- Fix the calculation of the GD_AVAILABLE_HARTS start address
- Fix compilation error for defconfigs that do not define CONFIG_NR_CPUS
---
arch/riscv/Kconfig | 4 ++--
arch/riscv/cpu/start.S | 20 +++-
arch/riscv/include/asm/global_data.h | 8 +++-
arch/riscv/lib/smp.c | 2 +-
4 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ebc4bef220..063734cbb9 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -232,8 +232,8 @@ config SPL_SMP
all, single processor machines.
config NR_CPUS
- int "Maximum number of CPUs (2-32)"
- range 2 32
+ int "Maximum number of CPUs (2-4095)"
+ range 2 4095
Looking at patch
776e8aca0bad ("riscv: alloc space exhausted")
SYS_MALLOC_F_LEN needs to be increased if the number of CPUs is increased.
You could add an architecture specific rule to config.mk to adjust
SYS_MALLOC_F_LEN.
depends on SMP || SPL_SMP
default 8
help
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 4687bca3c9..ae19c2b43d 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -172,11 +172,21 @@ wait_for_gd_init:
bnezt1, 1b
/* register available harts in the available_harts mask */
- li t1, 1
- sll t1, t1, tp
- LREGt2, GD_AVAILABLE_HARTS(gp)
- or t2, t2, t1
- SREGt2, GD_AVAILABLE_HARTS(gp)
+ li t1, GD_AVAILABLE_HARTS
+ add t1, t1, gp
+#if defined(CONFIG_ARCH_RV64I)
+ srlit2, tp, 6
+ sllit2, t2, 3
+#elif defined(CONFIG_ARCH_RV32I)
+ srlit2, tp, 5
+ sllit2, t2, 2
+#endif
If QEMU provides > XLEN harts, this will result in a buffer overrun. You
must check against the size of available_harts.
+ add t1, t1, t2
+ LREGt2, 0(t1)
+ li t3, 1
+ sll t3, t3, tp
+ or t2, t2, t3
+ SREGt2, 0(t1)
amoswap.w.rl zero, zero, 0(t0)
#endif
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index 6fdc86dd8b..7e37e90db0 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -10,9 +10,15 @@
#ifndef __ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
+#include
#include
#include
#include
+#include
+
+#ifndef CONFIG_NR_CPUS
+#define CONFIG_NR_CPUS 1
CONFIG_ constants should not be defined in C code. Please, move this to
Kconfig.
The chosen value will create problems for QEMU. The fallback value
should be XLEN (BITS_PER_LONG) at least.
Best regards
Heinrich
+#endif
/* Architecture-specific global data */
struct arch_global_data {
@@ -29,7 +35,7 @@ struct arch_global_data {
#endif
#if !CONFIG_IS_ENABLED(XIP)
#ifdef CONFIG_AVAILABLE_HARTS
- ulong available_harts;
+ ulong available_harts[BITS_TO_LONGS(CONFIG_NR_CPUS)];
#endif
#endif
};
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
index 4f073a016f..511e3ed98d 100644
--- a/arch/riscv/lib/smp.c
+++ b/arch/riscv/lib/smp.c
@@ -48,7 +48,7 @@ static int send_ipi_many(struct ipi_data *ipi, int wait)
#if !CONFIG_IS_ENABLED(XIP)
#ifdef CONFIG_AVAILABLE_HARTS
/* skip if hart is not available */
- if (!(gd->arch.available_harts & (1 << reg)))
+ if (!test_bit(reg, gd->arch.available_harts))
continue;
#endif
#endif
Re: [PATCH 13/14] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
Hi Jonas,
On 5/9/23 14:16, Kever Yang wrote:
On 2023/4/22 09:23, Jonas Karlman wrote:
Add sfc and flash node to device tree and config options to enable
support for booting from SPI NOR flash on Radxa ROCK 5 Model B.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 24
arch/arm/dts/rk3588s-u-boot.dtsi | 20
arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
configs/rock5b-rk3588_defconfig | 10 ++
4 files changed, 55 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 4bbc19058c90..b63dd40deb6d 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -11,6 +11,7 @@
/ {
aliases {
mmc1 =
+ spi0 =
};
chosen {
@@ -43,6 +44,25 @@
pinctrl-0 = <_bus8 _clk _cmd _data_strobe
_rstnout>;
};
+ {
+ bootph-pre-ram;
Any reason why the sfc and flash are pre-ram and the pins bootph-all ?
+ u-boot,spl-sfc-no-dma;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ bootph-pre-ram;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2400>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ };
+};
+
{
bootph-all;
@@ -69,6 +89,10 @@
bootph-all;
};
+_pins {
+ bootph-all;
+};
+
_bus4 {
bootph-all;
};
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
b/arch/arm/dts/rk3588s-u-boot.dtsi
index cd7e6cb50ee2..d8a471a37fd1 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -104,6 +104,15 @@
};
};
+ sfc: spi@fe2b {
+ compatible = "rockchip,sfc";
+ reg = <0x0 0xfe2b 0x0 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_SFC>, < HCLK_SFC>;
+ clock-names = "clk_sfc", "hclk_sfc";
+ status = "disabled";
+ };
+
otp: nvmem@fecc {
compatible = "rockchip,rk3588-otp";
reg = <0x0 0xfecc 0x0 0x400>;
@@ -164,3 +173,14 @@
{
bootph-pre-ram;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+ offset = <0x8000>;
What is this offset referring to ?
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 18e67b5ca9b2..0e85893e0096 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -41,6 +41,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE
+ 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
[BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
+ [6] = "/spi@fe2b/flash@0",
Is this '6' meaning something in particular ? or just the next number in
line ?
};
static struct mm_region rk3588_mem_map[] = {
diff --git a/configs/rock5b-rk3588_defconfig
b/configs/rock5b-rk3588_defconfig
index 2f0a74ee5559..e6a903853fb7 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -8,15 +8,20 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
Any reason for changing the default mode ?
CONFIG_DEFAULT_DEVICE_TREE="rk3588-rock-5b"
CONFIG_ROCKCHIP_RK3588=y
CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
CONFIG_SPL_SERIAL=y
CONFIG_SPL_STACK_R_ADDR=0x60
CONFIG_TARGET_ROCK5B_RK3588=y
CONFIG_SPL_STACK=0x40
CONFIG_DEBUG_UART_BASE=0xFEB5
CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
CONFIG_SYS_LOAD_ADDR=0xc00800
CONFIG_DEBUG_UART=y
CONFIG_FIT=y
@@ -35,6 +40,8 @@ CONFIG_SPL_BSS_MAX_SIZE=0x4000
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
I have a feeling the default is 0x8, do you have any reason for the
change to 0x6 ?
CONFIG_SPL_ATF=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_GPT=y
@@ -59,6 +66,8 @@ CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
# CONFIG_SPL_MMC_SDHCI_SDMA is not set
CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_XTX=y
CONFIG_ETH_DESIGNWARE=y
CONFIG_GMAC_ROCKCHIP=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
@@ -69,6 +78,7 @@ CONFIG_SPL_RAM=y
CONFIG_BAUDRATE=150
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SFC=y
CONFIG_SYSRESET=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
Re: [PATCH] drivers: core: ofnode: fix typo in panel timing decode
On Thu, May 11, 2023 at 04:36:52PM +0200, Patrick Delaunay wrote:
> From: Raphael Gallais-Pou
>
> In case where a single timing resolution is implemented in the
> device-tree, the property is named "panel-timing", as specify
> in Linux kernel binding file:
>
> Documentation/devicetree/bindings/display/panel/panel-common.yaml
>
> # Display Timings
> panel-timing:
> description:
> Most display panels are restricted to a single resolution and
> require specific display timings. The panel-timing subnode expresses
> those
> timings.
> $ref: panel-timing.yaml#
>
> display-timings:
> description:
> Some display panels support several resolutions with different timings.
> The display-timings bindings supports specifying several timings and
> optionally specifying which is the native mode.
> $ref: display-timings.yaml#
>
> Fixes: 0347cc773270 ("drivers: core: ofnode: Add panel timing decode.")
> Signed-off-by: Raphael Gallais-Pou
> Signed-off-by: Patrick Delaunay
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v3] environment: ti: rproc: fix remoteproc environment variables
On Mon, May 15, 2023 at 12:22:42PM +0530, Manorit Chawdhry wrote:
> During refactor this seemed to have been missed.
>
> Fixes: 65dbb128fb45 ("include: environment: ti: Use .env for environment
> variables")
>
> Signed-off-by: Manorit Chawdhry
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v10] core: fdtaddr: use map_sysmem() as cast for the return (part 2)
On Wed, May 10, 2023 at 11:48:44PM +0200, Johan Jonker wrote: > For the devfdt_get_addr_size_index_ptr() function use > map_sysmem() function as cast for the return for use in > sandbox. > > Signed-off-by: Johan Jonker Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Fit Signature booting without public key
On Tue, May 16, 2023 at 12:11:24PM +0530, Manorit Chawdhry wrote: > Hi All, > > I recently came upon a discussion that had happened a while back [0]. > I want to continue the discussion as I believe the issue still persists > and the checks around fit signature booting are still the same, that > allows booting the fit without changing the uboot dtb. > > Allowing the signed fit image without this seems to be a bypass that is > available and should not be allowed without any gate to it for people > who'd like to enforce these signing checks. Let me know if there is a > config already available for it and if not, are there any plans to > enable such a config in future. Would like to hear your opinions on > this as I believe this should be fixed as soon as possible. > > [0]: > https://u-boot.denx.narkive.com/dEClg9dW/signed-fit-image-boots-without-public-key Yes, can you please reproduce the issue in question on the current tree, with a supported platform and provide the defconfig and steps you used for this issue? Thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH] include: Remove unused header files
On 5/15/23 21:01, Tom Rini wrote: As part of various code clean-ups we have on occasion missed removing unused header files. None of these files are referenced anywhere else at this point. Signed-off-by: Tom Rini --- arch/arm/include/asm/arch-bcmcygnus/configs.h | 18 - arch/arm/include/asm/arch-bcmnsp/configs.h| 17 - arch/arm/include/asm/arch-imxrt/imxrt.h | 10 - arch/arm/include/asm/arch-lpc32xx/gpio_grp.h | 39 - arch/arm/include/asm/arch-mx27/mxcmmc.h | 11 - arch/arm/include/asm/arch-mx6/opos6ul.h | 11 - arch/arm/include/asm/arch-mxs/regs-uartapp.h | 219 --- arch/arm/include/asm/arch-omap3/omap3-regs.h | 78 - arch/arm/include/asm/arch-omap5/mux_omap5.h | 317 arch/arm/include/asm/iproc-common/configs.h | 14 - .../include/asm/iproc-common/iproc_sdhci.h| 12 - arch/arm/include/asm/kona-common/kona_sdhci.h | 11 - arch/arm/mach-at91/include/mach/at91_rtt.h| 32 - arch/arm/mach-at91/include/mach/sama7-sfr.h | 59 - Hi Tom, The sama7 SFR is to be used with patches that are pending, not yet merged. Could you please avoid removing this file ? Thanks, Eugen
Re: [PATCH] include: Remove unused header files
On Tue, May 16, 2023 at 04:08:10PM +0300, Eugen Hristev wrote: > On 5/15/23 21:01, Tom Rini wrote: > > As part of various code clean-ups we have on occasion missed removing > > unused header files. None of these files are referenced anywhere else > > at this point. > > > > Signed-off-by: Tom Rini > > --- > > arch/arm/include/asm/arch-bcmcygnus/configs.h | 18 - > > arch/arm/include/asm/arch-bcmnsp/configs.h| 17 - > > arch/arm/include/asm/arch-imxrt/imxrt.h | 10 - > > arch/arm/include/asm/arch-lpc32xx/gpio_grp.h | 39 - > > arch/arm/include/asm/arch-mx27/mxcmmc.h | 11 - > > arch/arm/include/asm/arch-mx6/opos6ul.h | 11 - > > arch/arm/include/asm/arch-mxs/regs-uartapp.h | 219 --- > > arch/arm/include/asm/arch-omap3/omap3-regs.h | 78 - > > arch/arm/include/asm/arch-omap5/mux_omap5.h | 317 > > arch/arm/include/asm/iproc-common/configs.h | 14 - > > .../include/asm/iproc-common/iproc_sdhci.h| 12 - > > arch/arm/include/asm/kona-common/kona_sdhci.h | 11 - > > arch/arm/mach-at91/include/mach/at91_rtt.h| 32 - > > arch/arm/mach-at91/include/mach/sama7-sfr.h | 59 - > > Hi Tom, > > The sama7 SFR is to be used with patches that are pending, not yet merged. > Could you please avoid removing this file ? OK. Is that the only one? For future reference, it's best to not include headers / etc until they're going to be used. Thanks. -- Tom signature.asc Description: PGP signature
[PATCH 1/1] config: CONFIG_SPL_SIZE_LIMIT for VisionFive 2
The size of SPL including the 1 KiB header added by spl_tool may not exceed 128 KiB. Without the header this leaves 127 KiB for spl/u-boot-spl.bin. We should check this value when building to avoid oversized binaries. Signed-off-by: Heinrich Schuchardt --- configs/starfive_visionfive2_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index ffbc4b9476..4fb006753e 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -14,6 +14,7 @@ CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y CONFIG_SPL_STACK=0x818 +CONFIG_SPL_SIZE_LIMIT=0x1fc00 CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y -- 2.39.2
Re: [PATCH] include: Remove unused header files
On Tue, May 16, 2023 at 04:15:18PM +0300, Eugen Hristev wrote: > On 5/16/23 16:09, Tom Rini wrote: > > On Tue, May 16, 2023 at 04:08:10PM +0300, Eugen Hristev wrote: > > > On 5/15/23 21:01, Tom Rini wrote: > > > > As part of various code clean-ups we have on occasion missed removing > > > > unused header files. None of these files are referenced anywhere else > > > > at this point. > > > > > > > > Signed-off-by: Tom Rini > > > > --- > > > >arch/arm/include/asm/arch-bcmcygnus/configs.h | 18 - > > > >arch/arm/include/asm/arch-bcmnsp/configs.h| 17 - > > > >arch/arm/include/asm/arch-imxrt/imxrt.h | 10 - > > > >arch/arm/include/asm/arch-lpc32xx/gpio_grp.h | 39 - > > > >arch/arm/include/asm/arch-mx27/mxcmmc.h | 11 - > > > >arch/arm/include/asm/arch-mx6/opos6ul.h | 11 - > > > >arch/arm/include/asm/arch-mxs/regs-uartapp.h | 219 --- > > > >arch/arm/include/asm/arch-omap3/omap3-regs.h | 78 - > > > >arch/arm/include/asm/arch-omap5/mux_omap5.h | 317 > > > >arch/arm/include/asm/iproc-common/configs.h | 14 - > > > >.../include/asm/iproc-common/iproc_sdhci.h| 12 - > > > >arch/arm/include/asm/kona-common/kona_sdhci.h | 11 - > > > >arch/arm/mach-at91/include/mach/at91_rtt.h| 32 - > > > >arch/arm/mach-at91/include/mach/sama7-sfr.h | 59 - > > > > > > Hi Tom, > > > > > > The sama7 SFR is to be used with patches that are pending, not yet merged. > > > Could you please avoid removing this file ? > > > > OK. Is that the only one? For future reference, it's best to not > > include headers / etc until they're going to be used. Thanks. > > > > Well, the fact is that the header file is part of the arch , thus going > through the at91 tree, but it's referenced in some USB patches, that are > assigned to Marek and going through the USB tree. > Since he could not take the patches without the header, I applied it first, > and now waiting for him to send the PR for the USB patches using it. > You could ask why they are not in the same patch, well, Marek asked for > separate patches for arch changes and USB changes. Ah. Well, while I understand why that makes sense for the Linux kernel (there's so many subsystems and maintainers, how is one supposed to know if something has been reviewed) I'm quite happy to see things like this come in via one tree with the code having been acked/reviewed by the other. Not that this is likely to be a big deal moving forward, I'm unlikely to re-run this kind of check until after removing a number of platforms again. -- Tom signature.asc Description: PGP signature
Re: envtools lack extra settings since commit 86b9c3e4e4 ("env: Allow U-Boot scripts to be placed in
On Thu, May 11, 2023 at 08:16:49AM +0200, Christophe Leroy wrote: > After converting my targets from CFG_EXTRA_ENV_SETTINGS to > CONFIG_EXTRA_ENV_TEXT as suggested by Tom, I discovered that > fw_setenv doesn't set the entire defaut environment anymore. > > I tried to fix it with the below patch, but it fails qemu-x86 CI test, > see https://source.denx.de/u-boot/custodians/u-boot-mpc8xx/-/pipelines/16326 > That's the only CI test that fails AFAICS. > > Could you help with a solution ? This needs to be fixed. > > Thanks > Christophe > Resending with corrected addresses, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request efi-2023-07-rc3
On Tue, May 16, 2023 at 08:37:28AM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit e94fbdd2729fdcd570035d43f67adda8e0dfc115: > > Merge https://source.denx.de/u-boot/custodians/u-boot-x86 (2023-05-11 > 08:40:33 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-07-rc3 > > for you to fetch changes up to c7c0ca37673d8f1ae1c54dad1869101f566923f7: > > efi_loader: fix efi_dp_from_file() (2023-05-13 11:09:51 +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16352 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH] mmc: Do not read eMMC partition access bits by default on OMAP2PLUS and BCM283X
OMAP2PLUS and BCM283X mmc controllers do not work correctly with new emmc code which reads partition access bits prior mmc controller reset. So introduce a new config option MMC_ENABLE_PART_ACCESS, which is by default disabled for ARCH_OMAP2PLUS and ARCH_BCM283X; and selected for 32-bit mvebu mmc booting (which requires it). Signed-off-by: Pali Rohár --- arch/arm/mach-mvebu/Kconfig | 1 + drivers/mmc/Kconfig | 12 drivers/mmc/mmc.c | 2 ++ 3 files changed, 15 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index ac484c73f62d..fe691cd435e7 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -353,6 +353,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC imply SPL_GPIO imply SPL_LIBDISK_SUPPORT imply SPL_MMC + select MMC_ENABLE_PART_ACCESS if SPL_MMC select SUPPORT_EMMC_BOOT if SPL_MMC select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC select SPL_BOOTROM_SUPPORT diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index de01b9687bad..ea50dfdb62c5 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -107,6 +107,18 @@ config MMC_HW_PARTITIONING This adds a command and an API to do hardware partitioning on eMMC devices. +config MMC_ENABLE_PART_ACCESS + bool "Support for MMC partition access bits" + default n if ARCH_OMAP2PLUS || ARCH_BCM283X + default y + help + Read partition access bits from partition config register before card reset command + because these bits are reset to default value (User Data Area) during card reset. + This allows us to preserve original value of partition access bits used by the code + which loaded us (for example BootROM) and use it for board specific boot purposes. + . + This is required when U-Boot is using EXT_CSD_EXTRACT_PARTITION_ACCESS macro. + config SUPPORT_EMMC_RPMB bool "Support eMMC replay protected memory block (RPMB)" imply CMD_MMC_RPMB diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 9915610d82b1..fa3c4d1937c1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2864,6 +2864,7 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet) retry: mmc_set_initial_state(mmc); +#ifdef CONFIG_MMC_ENABLE_PART_ACCESS /* * Read partition access bits from partition config register before card reset command * because these bits are reset to default value (User Data Area) during card reset. @@ -2878,6 +2879,7 @@ retry: ext_csd[EXT_CSD_BOOT_MULT])) mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK; } +#endif /* Reset the Card */ err = mmc_go_idle(mmc); -- 2.20.1
Re: [PATCH 3/4] usb: Move SPL_USB_GADGET and related Kconfig symbols to drivers/usb/
On Sat, May 06, 2023 at 04:42:39PM +0200, Marek Vasut wrote: > To avoid piling up all the various Kconfig symbols in one place, i.e. > common/spl/Kconfig, move the USB Kconfig symbols into drivers/usb/ . > This commit moves SPL_USB_GADGET and related symbols. Fix typo and > rename SPL_USB_GADGET to "USB Gadget Support in SPL" . > > Update the gadget Makefile to match the symbol changes. > > Signed-off-by: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] usb: Move SPL_USB_HOST Kconfig symbol to drivers/usb/
On Sat, May 06, 2023 at 04:42:37PM +0200, Marek Vasut wrote: > To avoid piling up all the various Kconfig symbols in one place, i.e. > common/spl/Kconfig, move the USB Kconfig symbols into drivers/usb/ . > This commit moves SPL_USB_HOST and updates help text of both USB_HOST > and SPL_USB_HOST . > > Signed-off-by: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/4] usb: Move SPL_USB_STORAGE Kconfig symbol to drivers/usb/
On Sat, May 06, 2023 at 04:42:38PM +0200, Marek Vasut wrote: > To avoid piling up all the various Kconfig symbols in one place, i.e. > common/spl/Kconfig, move the USB Kconfig symbols into drivers/usb/ . > This commit moves SPL_USB_STORAGE and matching SYS_USB_FAT_BOOT_PARTITION . > > Signed-off-by: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
[PATCH v2] arm: mach-k3: am625_init: Add Erratum WA for RTC startup
From: Nishanth Menon
In the first silicon revision of the am62x family of SoCs, the hardware
wakeup event cannot be used if software is unable to unlock the RTC
device within one second after boot. To work around this limitation
unlock RTC as soon as possible in the boot flow to maximize our chance
of linux being able to use this device.
Add the erratum i2327 workaround to initialize the RTC.
Signed-off-by: Nishanth Menon
[b...@ti.com: rebased from 2021.01 and expanded commit and code messages]
Signed-off-by: Bryan Brattlof
---
arch/arm/mach-k3/am625_init.c | 46 +++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 026c4f9c02d71..787fe9229552f 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -15,6 +15,15 @@
#include
#include
+#define RTC_BASE_ADDRESS 0x2b1f
+#define REG_K3RTC_S_CNT_LSW(RTC_BASE_ADDRESS + 0x18)
+#define REG_K3RTC_KICK0(RTC_BASE_ADDRESS + 0x70)
+#define REG_K3RTC_KICK1(RTC_BASE_ADDRESS + 0x74)
+
+/* Magic values for lock/unlock */
+#define K3RTC_KICK0_UNLOCK_VALUE 0x83e70b13
+#define K3RTC_KICK1_UNLOCK_VALUE 0x95a4f1e0
+
/*
* This uninitialized global variable would normal end up in the .bss section,
* but the .bss is cleared between writing and reading this variable, so move
@@ -71,6 +80,42 @@ static __maybe_unused void enable_mcu_esm_reset(void)
writel(stat, CTRLMMR_MCU_RST_CTRL);
}
+#if defined(CONFIG_CPU_V7R)
+
+/*
+ * RTC Erratum i2327 Workaround for Silicon Revision 1
+ *
+ * Due to a bug in initial synchronization out of cold power on,
+ * IRQ status can get locked infinitely if we do not unlock RTC
+ *
+ * This workaround *must* be applied within 1 second of power on,
+ * So, this is closest point to be able to guarantee the max
+ * timing.
+ *
+ * https://www.ti.com/lit/er/sprz487c/sprz487c.pdf
+ */
+void rtc_erratumi2327_init(void)
+{
+ u32 counter;
+
+ /*
+* If counter has gone past 1, nothing we can do, leave
+* system locked! This is the only way we know if RTC
+* can be used for all practical purposes.
+*/
+ counter = readl(REG_K3RTC_S_CNT_LSW);
+ if (counter > 1)
+ return;
+ /*
+* Need to set this up at the very start
+* MUST BE DONE under 1 second of boot.
+*/
+ writel(K3RTC_KICK0_UNLOCK_VALUE, REG_K3RTC_KICK0);
+ writel(K3RTC_KICK1_UNLOCK_VALUE, REG_K3RTC_KICK1);
+ return;
+}
+#endif
+
void board_init_f(ulong dummy)
{
struct udevice *dev;
@@ -78,6 +123,7 @@ void board_init_f(ulong dummy)
#if defined(CONFIG_CPU_V7R)
setup_k3_mpu_regions();
+ rtc_erratumi2327_init();
#endif
/*
base-commit: 6e1852ca2c418e2536ead4b51c4d84a59926b3f1
--
2.40.1
[PULL] u-boot-sh/next_gpio
The following changes since commit 5d0b3dde115b0d26d414199678983d01b738ad1b: Merge branch '2023-05-15-build-system-updates' into next (2023-05-15 15:26:54 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sh.git next_gpio for you to fetch changes up to a74931a945960c84aa1a68169c6d3709730dfc12: gpio: renesas: Simplify .request/.rfree callbacks (2023-05-16 22:24:24 +0200) Pali Rohár (1): gpio: renesas: Simplify .request/.rfree callbacks drivers/gpio/gpio-rcar.c | 15 ++- 1 file changed, 2 insertions(+), 13 deletions(-)
Re: [RFC PATCH 13/17] sunxi: add early Allwinner R528/T113 SoC support
On Mon, 15 May 2023 20:52:23 -0600 Sam Edwards wrote: Hi Sam, > On 12/5/22 17:45, Andre Przywara wrote: > > diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c > > index 3763ec3d2e4..1cda5e2 100644 > > --- a/arch/arm/mach-sunxi/board.c > > +++ b/arch/arm/mach-sunxi/board.c > > @@ -148,6 +148,10 @@ static int gpio_init(void) > > sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0); > > sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0); > > sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP); > > +#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_R528) > > + sunxi_gpio_set_cfgpin(SUNXI_GPE(2), 6); > > + sunxi_gpio_set_cfgpin(SUNXI_GPE(3), 6); > > + sunxi_gpio_set_pull(SUNXI_GPE(3), SUNXI_GPIO_PULL_UP); > > #elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV) > > sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0); > > sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0); > > I'm a relative outsider to sunxi, but it does look like the NCAT2 > generation's MUX is a lot more flexible in its UART assignments: e.g. > while H3's UART1-3 only had one set of pins each UART could use, the > T113 (my target) supports anywhere from 2-6 (typically 4) different > options for each of its UARTs. It is not as simple as configuring which > UART is the serial console anymore, because different boards might wire > the console header to different pins. My particular target uses UART3 on > pins PB6/PB7, for example. Well, theoretically there are indeed quite some options, but in reality we find that most boards follow some reference design, and the *debug* UART is only ever using a very few of the possible settings. For the later (ARMv8) SoCs this is mostly UART0, but for the T113 it's apparently indeed UART3. I also changed that in the Github version, to use the very same PB6/7 UART3 mux as you. > Since this patchset is updating the PIO driver anyway, maybe it's worth > updating the (preprocessor, not runtime) logic in gpio_init to support > getting the UART TX/RX pins from Kconfig, validating that the > CONFIG_CONS_INDEX and pin selection are compatible, and setting the > correct MUX function for those pins with a value pulled from a table? Mmmh, that's an idea one could follow, as this function is indeed insane. I actually rewrote gpio_init() already, to replace the hard to read #ifdef's with actual C if statements, though that's still following the same idea as the current code. Let me have a look how this would look like. Cheers, Andre
Re: [RFC PATCH 08/17] sunxi: introduce NCAT2 generation model
On Mon, 15 May 2023 20:32:52 -0600 Sam Edwards wrote: Hi Sam, > Hi Andre! Thank you for your efforts on this patchset; I've been > test-driving it a bit myself this week. many thanks for having a look, that's much appreciated! > On 12/5/22 17:45, Andre Przywara wrote: > > > +#define SUNXI_RTC_BASE 0x0700 > > +#define SUNXI_R_CPUCFG_BASE0x07000400 > > +#define SUNXI_PRCM_BASE0x0701 > > +#define SUNXI_R_WDOG_BASE 0x07020400 > > +#define SUNXI_R_UART_BASE 0x0708 > > +#define SUNXI_R_TWI_BASE 0x07081400 > > How sure are we that this memory map is consistent across the whole > NCAT2 family? The documentation for my target (T113-S3) puts the RTC > base at 0x0709, for example. I find no mention of there being a PRCM > peripheral in this particular chip either. This whole memory map is somewhat of a legacy. Apart from a few addresses for the SPL needs we shouldn't have those defines at all. Some symbols are needed because there are other macros using them, although these then are eventually unused. I have some patches to remove most of the symbols, and patch 14/17 demonstrates some idea how to pin this down to what's really needed. For this particular case: this was copied from the H6 memory map, some addresses are just plain wrong for the D1 family. I will try to remove them as much as possible, leaving only the ones needed in. > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > index fef01bdd7da..fdd64db498f 100644 > > --- a/common/spl/Kconfig > > +++ b/common/spl/Kconfig > > @@ -265,7 +265,7 @@ config SPL_TEXT_BASE > > default 0x402F0400 if AM33XX > > default 0x40301350 if OMAP54XX > > default 0x10060 if MACH_SUN50I || MACH_SUN50I_H5 || MACH_SUN9I > > - default 0x20060 if SUN50I_GEN_H6 > > + default 0x20060 if SUN50I_GEN_H6 || SUNXI_GEN_NCAT2 > > default 0x00060 if ARCH_SUNXI > > default 0xfffc if ARCH_ZYNQMP > > default 0x0 > > Would it also be good to change the default for CONFIG_SPL_STACK? As-is > it defaults to 0x8000, which would put it in the BROM region. > Allwinner's boot0 starts its stack at 0x48000, which I've been using. Yeah, well spotted, this was a bug in this early RTC post. I never ran the SPL, because the DRAM code was missing still. I fixed the stack pointer meanwhile in an updated (and working) version on Github: https://github.com/apritzel/u-boot/commit/d5fa559abdf2#diff-19adb575625e29e7a996e0ffb1a266e24239d9b004f17154616220a3f17a24ed > > diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h > > index 2f8b220f750..04d7aa3d632 100644 > > --- a/include/sunxi_gpio.h > > +++ b/include/sunxi_gpio.h > > @@ -16,6 +16,9 @@ > > #elif defined(CONFIG_SUN50I_GEN_H6) > > #define SUNXI_PIO_BASE0x0300b000 > > #define SUNXI_R_PIO_BASE 0x07022000 > > +#elif defined(CONFIG_SUNXI_GEN_NCAT2) > > +#define SUNXI_PIO_BASE 0x0200 > > +#define SUNXI_R_PIO_BASE 0 > > #else > > #define SUNXI_PIO_BASE0x01c20800 > > #define SUNXI_R_PIO_BASE 0x01f02c00 > > Code elsewhere assumes that SUNXI_R_PIO_BASE is nonzero; on my local > branch in particular I had to update > arch/arm/mach-sunxi/board.c:gpio_init. Perhaps it would be better to > leave SUNXI_R_PIO_BASE undefined in the chips where this gadget is missing? I think leaving it undefined causes more problems, doesn't it? Looking at #define BANK_TO_GPIO(bank) in arch/arm/include/asm/arch-sunxi/gpio.h, specifically. I am saying that because that's what I tried first ;-) So where did you see problems? If you would (wrongly) reference PortL somewhere in SPL GPIO code, it would use a wrong pointer, but at least the code would still compile fine, wouldn't it? Cheers, Andre P.S. Could you try the github post? Then compiled and booted fine for me, and includes the DRAM code as well now: https://github.com/apritzel/u-boot/commits/t113s-mq-r-WIP
Re: [PATCH 13/14] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
On 2023-05-16 21:13, Eugen Hristev wrote:
> On 5/16/23 20:38, Jonas Karlman wrote:
>> Hi Eugen,
>>
>> On 2023-05-16 17:06, Eugen Hristev wrote:
>>> Hi Jonas,
>>>
>>> On 5/9/23 14:16, Kever Yang wrote:
On 2023/4/22 09:23, Jonas Karlman wrote:
> Add sfc and flash node to device tree and config options to enable
> support for booting from SPI NOR flash on Radxa ROCK 5 Model B.
>
> Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 24
> arch/arm/dts/rk3588s-u-boot.dtsi | 20
> arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
> configs/rock5b-rk3588_defconfig | 10 ++
> 4 files changed, 55 insertions(+)
>
> diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> index 4bbc19058c90..b63dd40deb6d 100644
> --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> @@ -11,6 +11,7 @@
> / {
> aliases {
> mmc1 =
> + spi0 =
> };
> chosen {
> @@ -43,6 +44,25 @@
> pinctrl-0 = <_bus8 _clk _cmd _data_strobe
> _rstnout>;
> };
> + {
> + bootph-pre-ram;
>>>
>>> Any reason why the sfc and flash are pre-ram and the pins bootph-all ?
>>
>> This used to be u-boot,dm-spl and was later replaced with bootph-pre-ram.
>>
>
> Right... but bootph-pre-ram means that the node is available in SPL
> right ? But it will not be available 'post-ram' ?
I was under the assumption that a node would be available at any later
stage, re-reading the dt-schema and checking Makefile I can now see that
nodes will only be available in:
TPL: nodes having bootph-all or bootph-pre-sram
SPL: nodes having bootph-all or bootph-pre-ram
U-Boot proper: all nodes regardless of any bootph prop
>
>> For fspim2_pins I used the same bootph as the other pins. Not sure why
>> the pins use bootph-all to begin with, sdmmc and sdhci use bootph-pre-ram
>> in rk3588s-u-boot.dtsi.
>>
>
> Because out of my understanding, the pins should be available in all
> bootstages, hence 'bootph-all' , they are needed all the time.
Fully agree and will have to change a few to bootph-all for RK3568 in a
v2 series.
>
> Please correct me if I am wrong, I am not very familiar with these new
> names yet.
>
> But 'pre-ram' suggests (at least to me) availability only in the initial
> stage (SPL)
>
> Otherwise what's the difference between bootph-all and bootph-pre-ram ?
> Maybe that difference would enlighten me
After reading up on the bootph props I think the following could be good
use for the Rockchip platform, where TPL main purpose is to init DRAM and
SPL main purpose is to load U-Boot proper/TF-A from storage:
- bootph-all for e.g. clock, ram, pinctrl and debug uart related nodes.
- bootph-pre-ram for any remaining node related to where
U-Boot proper/TF-A could be loaded from.
>
> Sorry for the long noise
>
>
>>>
> + u-boot,spl-sfc-no-dma;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + flash@0 {
> + bootph-pre-ram;
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2400>;
> + spi-rx-bus-width = <4>;
> + spi-tx-bus-width = <1>;
> + };
> +};
> +
> {
> bootph-all;
> @@ -69,6 +89,10 @@
> bootph-all;
> };
> +_pins {
> + bootph-all;
> +};
> +
> _bus4 {
> bootph-all;
> };
> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
> b/arch/arm/dts/rk3588s-u-boot.dtsi
> index cd7e6cb50ee2..d8a471a37fd1 100644
> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
> @@ -104,6 +104,15 @@
> };
> };
> + sfc: spi@fe2b {
> + compatible = "rockchip,sfc";
> + reg = <0x0 0xfe2b 0x0 0x4000>;
> + interrupts = ;
> + clocks = < SCLK_SFC>, < HCLK_SFC>;
> + clock-names = "clk_sfc", "hclk_sfc";
> + status = "disabled";
> + };
> +
> otp: nvmem@fecc {
> compatible = "rockchip,rk3588-otp";
> reg = <0x0 0xfecc 0x0 0x400>;
> @@ -164,3 +173,14 @@
> {
> bootph-pre-ram;
> };
> +
> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
> + {
> + simple-bin-spi {
> + mkimage {
> + args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
> + offset = <0x8000>;
>>>
>>> What is this offset referring to ?
>>
>> This offset is referring to the normal mmc 32 KiB offset that idbloader
>> is normally
Re: mmc: Read eMMC partition access bits before card reset
On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card > > > > > > > > > > > > reset > > > > > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" > > > > > > > > > > > > says that all reset > > > > > > > > > > > > events will restore the access bits in > > > > > > > > > > > > PARTITION_CONFIG CSD register to > > > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG > > > > > > > > > > > > CSD register before > > > > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > > > > information which eMMC > > > > > > > > > > > > partition was in use before SPL/U-Boot was booted. > > > > > > > > > > > > For some platforms this > > > > > > > > > > > > is the way how to determinate boot partition from > > > > > > > > > > > > which BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 > > > > > > > > > > > > - 13:10:10 -0400) > > > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to > > > > > > > > > > > > clear > > > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to > > > > > > > > > > > hide this code > > > > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For > > > > > > > > > > > example by this: > > > > > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? > > > > > > > > > > The failure I > > > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do > > > > > > > > > not know if > > > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine > > > > > > > > > on mvebu > > > > > > > > > clearfog? > > > > > > > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > > > > fsm 0, hsts > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the > > > > > > > > > > above one and > > > > > > > > > > the board is fine again. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > Immediately after that "problematic code" is card reset > > > > > > > > > function. So > > > > > > > > > another reason for failure is that card reset functionality > > > > > > > > > does not > > > > > > > > > work correctly on your board / platform. > > > > > > > > > > > > > > > > Well, we're at two different platforms and controllers that > > > > > > > > this change > > > > > > > > breaks things on, so I'm not sure where the fault is exactly. > > > > > > > >
Re: [PATCH 13/14] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
Hi Eugen,
On 2023-05-16 17:06, Eugen Hristev wrote:
> Hi Jonas,
>
> On 5/9/23 14:16, Kever Yang wrote:
>>
>> On 2023/4/22 09:23, Jonas Karlman wrote:
>>> Add sfc and flash node to device tree and config options to enable
>>> support for booting from SPI NOR flash on Radxa ROCK 5 Model B.
>>>
>>> Signed-off-by: Jonas Karlman
>> Reviewed-by: Kever Yang
>>
>> Thanks,
>> - Kever
>>> ---
>>> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 24
>>> arch/arm/dts/rk3588s-u-boot.dtsi | 20
>>> arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
>>> configs/rock5b-rk3588_defconfig | 10 ++
>>> 4 files changed, 55 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>>> b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>>> index 4bbc19058c90..b63dd40deb6d 100644
>>> --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>>> @@ -11,6 +11,7 @@
>>> / {
>>> aliases {
>>> mmc1 =
>>> + spi0 =
>>> };
>>> chosen {
>>> @@ -43,6 +44,25 @@
>>> pinctrl-0 = <_bus8 _clk _cmd _data_strobe
>>> _rstnout>;
>>> };
>>> + {
>>> + bootph-pre-ram;
>
> Any reason why the sfc and flash are pre-ram and the pins bootph-all ?
This used to be u-boot,dm-spl and was later replaced with bootph-pre-ram.
For fspim2_pins I used the same bootph as the other pins. Not sure why
the pins use bootph-all to begin with, sdmmc and sdhci use bootph-pre-ram
in rk3588s-u-boot.dtsi.
>
>>> + u-boot,spl-sfc-no-dma;
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <_pins>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + status = "okay";
>>> +
>>> + flash@0 {
>>> + bootph-pre-ram;
>>> + compatible = "jedec,spi-nor";
>>> + reg = <0>;
>>> + spi-max-frequency = <2400>;
>>> + spi-rx-bus-width = <4>;
>>> + spi-tx-bus-width = <1>;
>>> + };
>>> +};
>>> +
>>> {
>>> bootph-all;
>>> @@ -69,6 +89,10 @@
>>> bootph-all;
>>> };
>>> +_pins {
>>> + bootph-all;
>>> +};
>>> +
>>> _bus4 {
>>> bootph-all;
>>> };
>>> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
>>> b/arch/arm/dts/rk3588s-u-boot.dtsi
>>> index cd7e6cb50ee2..d8a471a37fd1 100644
>>> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
>>> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
>>> @@ -104,6 +104,15 @@
>>> };
>>> };
>>> + sfc: spi@fe2b {
>>> + compatible = "rockchip,sfc";
>>> + reg = <0x0 0xfe2b 0x0 0x4000>;
>>> + interrupts = ;
>>> + clocks = < SCLK_SFC>, < HCLK_SFC>;
>>> + clock-names = "clk_sfc", "hclk_sfc";
>>> + status = "disabled";
>>> + };
>>> +
>>> otp: nvmem@fecc {
>>> compatible = "rockchip,rk3588-otp";
>>> reg = <0x0 0xfecc 0x0 0x400>;
>>> @@ -164,3 +173,14 @@
>>> {
>>> bootph-pre-ram;
>>> };
>>> +
>>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>>> + {
>>> + simple-bin-spi {
>>> + mkimage {
>>> + args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
>>> + offset = <0x8000>;
>
> What is this offset referring to ?
This offset is referring to the normal mmc 32 KiB offset that idbloader
is normally written to. I used the offset prop so that the
u-boot-rockchip-spi.bin can be written to offset 0 of spi similar as is
currently done for rk3399.
>
>>> + };
>>> + };
>>> +};
>>> +#endif
>>> diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
>>> b/arch/arm/mach-rockchip/rk3588/rk3588.c
>>> index 18e67b5ca9b2..0e85893e0096 100644
>>> --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
>>> +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
>>> @@ -41,6 +41,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE
>>> + 1] = {
>>> [BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
>>> [BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
>>> [BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
>>> + [6] = "/spi@fe2b/flash@0",
>
> Is this '6' meaning something in particular ? or just the next number in
> line ?
The bootrom on rk3588 use value 6 when booting from the spi flash on my
ROCK 5B, normally bootrom have used value 3 (BROM_BOOTSOURCE_SPINOR) on
rk356x and earlier socs.
I have no idea what we should call this BOOTSOURCE, could not find any
define in vendor u-boot to help give this a proper name.
Kever: Any insights into what this value should be called?
>
>>> };
>>> static struct mm_region rk3588_mem_map[] = {
>>> diff --git a/configs/rock5b-rk3588_defconfig
>>> b/configs/rock5b-rk3588_defconfig
>>> index 2f0a74ee5559..e6a903853fb7 100644
>>> --- a/configs/rock5b-rk3588_defconfig
>>> +++ b/configs/rock5b-rk3588_defconfig
>>> @@ -8,15 +8,20 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>> CONFIG_NR_DRAM_BANKS=2
>>> CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>>> CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
>>> +CONFIG_SF_DEFAULT_SPEED=2400
>>> +CONFIG_SF_DEFAULT_MODE=0x2000
>
> Any reason for changing the default
Re: [PATCH] Fix sparse checks processing
On Tue, May 16, 2023 at 06:18:56AM +, Christophe Leroy wrote:
>
>
> Le 15/05/2023 à 23:12, Tom Rini a écrit :
> > On Fri, May 05, 2023 at 10:39:39AM +0200, Christophe Leroy wrote:
> >
> >> A lot of errors are encountered when building with sparse checking
> >> activated (make C=1 or make C=2).
> >>
> >> Many of them are fixed in Linux.
> >>
> >> Resynchronise Makefile and include/linux/build_bug.h with Linux
> >> kernel sources by porting the following Linux commits into u-boot:
> >> - 6c49f359ca14 ("kbuild: disable sparse warnings about unknown attributes")
> >> - 80591e61a0f7 ("kbuild: tell sparse about the $ARCH")
> >> - 8788994376d8 ("linux/build_bug.h: change type to int")
> >> - 527edbc18a70 ("build_bug.h: remove most of dummy BUILD_BUG_ON stubs for
> >> Sparse")
> >> - c60d3b79423a ("build_bug.h: remove negative-array fallback for
> >> BUILD_BUG_ON()")
> >> - 14e83077d55f ("include: drop pointless __compiler_offsetof indirection")
> >>
> >> Also revert commit aa9e891c63 ("include/linux/stddef.h: avoid
> >> 'warning: preprocessor token offsetof redefined'") because the
> >> error it creates is worse than the warning it is trying to fix.
> >>
> >> Signed-off-by: Christophe Leroy
> >
> > First, I've applied to u-boot/next now. But second, I had mentioned CI
> > testing too, but seeing the level of checker-error output on qemu-arm I
> > am reluctant to add a test that should build-to-completion but error so
> > much as I worry about it being seen as a low quality test.
> >
>
> Well, at least we can now start detecting and fixing them.
>
> Also, I don't know how feasible it is, but in Linux kernel the robots
> report new warnings/error only so that you know you are not adding new
> ones with new commits. Could CI do that too ?
In theory something like those could be adapted, and if you can either
test something for GitLab / Azure, or even something I can integrate in
to my release scripts like Coverity scan for after the fact new
introductions, I'd appreciate it.
--
Tom
signature.asc
Description: PGP signature
Re: mmc: Read eMMC partition access bits before card reset
On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" > > > > > > > > > > > says that all reset > > > > > > > > > > > events will restore the access bits in > > > > > > > > > > > PARTITION_CONFIG CSD register to > > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG > > > > > > > > > > > CSD register before > > > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > > > information which eMMC > > > > > > > > > > > partition was in use before SPL/U-Boot was booted. > > > > > > > > > > > For some platforms this > > > > > > > > > > > is the way how to determinate boot partition from > > > > > > > > > > > which BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > > > > 13:10:10 -0400) > > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to > > > > > > > > > > > clear > > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to > > > > > > > > > > hide this code > > > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For > > > > > > > > > > example by this: > > > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? > > > > > > > > > The failure I > > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do > > > > > > > > not know if > > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine > > > > > > > > on mvebu > > > > > > > > clearfog? > > > > > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > > > fsm 0, hsts > > > > > > > > > ... > > > > > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the > > > > > > > > > above one and > > > > > > > > > the board is fine again. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Tom > > > > > > > > > > > > > > > > Immediately after that "problematic code" is card reset > > > > > > > > function. So > > > > > > > > another reason for failure is that card reset functionality > > > > > > > > does not > > > > > > > > work correctly on your board / platform. > > > > > > > > > > > > > > Well, we're at two different platforms and controllers that this > > > > > > > change > > > > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > > > > mx6cuboxi is still fine booting from uSD. Another TI platform > > > > > > > from the > > > > > > > same general era as am335x fails the same way (not a surprise), > > > > > > > amlogic > > > > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > > >
Re: [PATCH 1/1] config: CONFIG_SPL_SIZE_LIMIT for VisionFive 2
On 5/16/23 21:33, Bo Gan wrote: On 5/16/23 6:11 AM, Heinrich Schuchardt wrote: The size of SPL including the 1 KiB header added by spl_tool may not exceed 128 KiB. Without the header this leaves 127 KiB for spl/u-boot-spl.bin. We should check this value when building to avoid oversized binaries. +CONFIG_SPL_SIZE_LIMIT=0x1fc00 Hi Heinrich, would you mind specify where the limit is coming from? I flashed my vf2 board with a ~140KiB SPL without any problem. https://github.com/starfive-tech/Tools/commit/8c5acc4e5eb7e4ad012463b05a5e3dbbfed1c38d seems to have changed the limit in the tooling. @Samin, Could you, please, indicate how the 180048 bytes was derived and what is the physical limit for the SPL size. Best regards Heinrich
Re: [External] - Re: Issues with bcm2835-host: let firmware manage the clock divisor
On Mon, May 15, 2023 at 1:10 PM Vincent Fazio wrote: > > All > > > -Original Message- > > From: Stefan Wahren > > Sent: Sunday, May 14, 2023 1:55 PM > > To: Nuno Gonçalves ; u-boot@lists.denx.de; Vincent > > Fazio ; pbrobin...@gmail.com > > Subject: [External] - Re: Issues with bcm2835-host: let firmware manage the > > clock divisor > > > > Hi Nuno, > > > > Am 14.05.23 um 14:06 schrieb Nuno Gonçalves: > > > Hi, after 85bdd28d2bb0827f311913e00e4e338f8e4e6565 (bcm2835-host: let > > > firmware manage the clock divisor), Linux fails to start the eMMC > > > memory on a CM3 most times (but it sometimes also works). > > > > thanks for your report. > > > > > > > > I am using Linux mainline and I wonder if this assumes the change in > > > which this was based also needs to be used in Linux? > > > > Yes, this is very likely. But how can U-Boot assume that at least Linux is > > booting afterwards. How about the other OSes with devicetree support? > > > > To be fair, I never tested with a linux kernel that was _not_ the RPi kernel, > but I did test on test this on 3b+ and CM3. We've included them in the Fedora builds since Spet 21 (2021.10 RC4) and it fixed the issues around the MMC clocking when the firmware changed. I've personally run it across most RPi platforms inc a CM3 device with upstream kernels with no issues and we've not had reports from users there either. > Feel free to revert; I honestly thought these patches died on the vine a year > or more ago. The was a lack of maintainer and I took that role over and went through the back log of patches, I pulled this one in as it was one of the ones we'd shipped with Fedora and it had fixed problems we had back then, if they've been resolved in other ways as well since I wasn't aware of. But that explains the lag in applying the patches. > > > > > > In that case I would think it's fair to revert until it comes to mainline. > > > > Actually from the original commit i wasn't able to see a real benefit from > > the > > change. Shorter boot time? > > The purpose of this commit and the previous (0a36afa) was to work around an > issue with a regression in RPi firmware [0] > > Since we couldn't guarantee what firmware payload was being used on an RPi or > that RPF wouldn't make a similar change in the future, it was important to > set the clock to something sane so mmc speeds didn't tank. The first commit > in the series may have been the only necessary commit to work around the > firmware regression, but I heard no negative responses on this list [1] nor > on the related GH issue[2] where others tested them. > > [0] https://github.com/raspberrypi/firmware/issues/1619 > [1] https://lists.denx.de/pipermail/u-boot/2021-November/465992.html > [2] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-931750755 > > > > > > > > > Thanks, > > > Nuno > > CAUTION: This email originated from outside of the organization. Do not > > click > > links or open attachments unless you recognize the sender and know the > > content is safe. >
[PATCH 3/3] doc: fix loady man-page
* loady may return $? = 1. * Move misplaced description Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/loady.rst | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/usage/cmd/loady.rst b/doc/usage/cmd/loady.rst index 718af6e128..3f8227ecf2 100644 --- a/doc/usage/cmd/loady.rst +++ b/doc/usage/cmd/loady.rst @@ -56,6 +56,9 @@ file transfer. 6165f => +Transfer can be cancelled by pressing 3 times after two seconds +of inactivity on terminal. + Configuration - @@ -65,10 +68,7 @@ Initial timeout in seconds while waiting for transfer is configured by config option CMD_LOADXY_TIMEOUT or by env variable $loadxy_timeout. Setting it to 0 means infinite timeout. -Transfer can be cancelled by pressing 3 times after two seconds -of inactivity on terminal. - Return value -The return value $? is always 0 (true). +The return value $? is 0 (true) on success, 1 (false) otherwise. -- 2.39.2
[PATCH 2/3] doc: loadx man-page
Provide a man-page for the loadx command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/loadx.rst | 77 + doc/usage/index.rst | 1 + 2 files changed, 78 insertions(+) create mode 100644 doc/usage/cmd/loadx.rst diff --git a/doc/usage/cmd/loadx.rst b/doc/usage/cmd/loadx.rst new file mode 100644 index 00..facca9b969 --- /dev/null +++ b/doc/usage/cmd/loadx.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +loadx command += + +Synopsis + + +:: + +loadx [addr [baud]] + +Description +--- + +The loadx command is used to transfer a file to the device via the serial line +using the XMODEM protocol. + +The number of transferred bytes is saved in environment variable filesize. + +addr +load address, defaults to environment variable loadaddr or if loadaddr is +not set to configuration variable CONFIG_SYS_LOAD_ADDR + +baud +baud rate for the ymodem transmission. After the transmission the baud +rate is reset to the original value. + +Example +--- + +In the example below the terminal emulation program picocom was used to +transfer a file to the device. + +.. code-block:: + +picocom --send-cmd 'sx -b vv' --baud 115200 /dev/ttyUSB0 + +After entering the loadx command the key sequence is used to +let picocom prompt for the file name. Picocom invokes the program sx for the +file transfer. + +:: + +=> loadx 6080 115200 +## Ready for binary (xmodem) download to 0x6080 at 115200 bps... +C +*** file: helloworld.efi +$ sx -b vv helloworld.efi +sx: cannot open vv: No such file or directory +Sending helloworld.efi, 24 blocks: Give your local XMODEM receive command now. +Xmodem sectors/kbytes sent: 0/ 0kRetry 0: NAK on sector +Bytes Sent: 3072 BPS:1147 + +Transfer incomplete + +*** exit status: 1 *** +## Total Size = 0x0c00 = 3072 Bytes +## Start Addr = 0x6080 +=> + +The transfer can be cancelled by pressing 3 times after two seconds +of inactivity on terminal. + +Configuration +- + +The command is only available if CONFIG_CMD_LOADB=y. + +Initial timeout in seconds while waiting for transfer is configured by +config option CMD_LOADXY_TIMEOUT or by env variable $loadxy_timeout. +Setting it to 0 means infinite timeout. + +Return value + + +The return value $? is 0 (true) on success, 1 (false) otherwise. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index f348848fc7..84ef8a9a42 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -65,6 +65,7 @@ Shell commands cmd/load cmd/loadb cmd/loadm + cmd/loadx cmd/loady cmd/mbr cmd/md -- 2.39.2
[PATCH 1/3] doc: loadb man-page
Provide a man-page for the loadb command. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/loadb.rst | 70 + doc/usage/index.rst | 1 + 2 files changed, 71 insertions(+) create mode 100644 doc/usage/cmd/loadb.rst diff --git a/doc/usage/cmd/loadb.rst b/doc/usage/cmd/loadb.rst new file mode 100644 index 00..b37d1d7b59 --- /dev/null +++ b/doc/usage/cmd/loadb.rst @@ -0,0 +1,70 @@ +.. SPDX-License-Identifier: GPL-2.0+: + +loadb command += + +Synopsis + + +:: + +loadb [addr [baud]] + +Description +--- + +The loady command is used to transfer a file to the device via the serial line +using the Kermit protocol. + +The number of transferred bytes is saved in environment variable filesize. + +addr +load address, defaults to environment variable loadaddr or if loadaddr is +not set to configuration variable CONFIG_SYS_LOAD_ADDR + +baud +baud rate for the Kermit transmission. After the transmission the baud +rate is reset to the original value. + +Example +--- + +In the example below the terminal emulation program picocom and G-Kermit +serve to transfer a file to a device. + +.. code-block:: bash + +picocom --baud 115200 --send-cmd "gkermit -iXvs" /dev/ttyUSB0 + +After entering the loadb command the key sequence is used to +let picocom prompt for the file name. Picocom invokes G-Kermit for the file +transfer. + +:: + +=> loadb 6080 115200 +## Ready for binary (kermit) download to 0x6080 at 115200 bps... + +*** file: helloworld.efi +$ gkermit -iXvs helloworld.efi +G-Kermit 2.01, The Kermit Project, 2021-11-15 +Escape back to your local Kermit and give a RECEIVE command. + +KERMIT READY TO SEND... +| +*** exit status: 0 *** +## Total Size = 0x0c00 = 3072 Bytes +## Start Addr = 0x6080 +=> + +The transfer can be cancelled by pressing . + +Configuration +- + +The command is only available if CONFIG_CMD_LOADB=y. + +Return value + + +The return value $? is 0 (true) on success, 1 (false) on error. diff --git a/doc/usage/index.rst b/doc/usage/index.rst index 0fde130a54..f348848fc7 100644 --- a/doc/usage/index.rst +++ b/doc/usage/index.rst @@ -63,6 +63,7 @@ Shell commands cmd/gpio cmd/host cmd/load + cmd/loadb cmd/loadm cmd/loady cmd/mbr -- 2.39.2
Re: [PATCH 4/4] usb: gadget: Add and use matching SPL USB ethernet gadget Kconfig symbols
On Sat, May 06, 2023 at 04:42:40PM +0200, Marek Vasut wrote: > Define SPL_USB_ETH_RNDIS symbol to make it possible to select USB > gadget ethernet support in SPL and U-Boot separately in Kconfig . > Make use of the new symbols in gadget Makefile and move the rndis.o > just below the now merged USB_ETHER symbol in Makefile. > > Signed-off-by: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH 13/14] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
On 5/16/23 20:38, Jonas Karlman wrote:
Hi Eugen,
On 2023-05-16 17:06, Eugen Hristev wrote:
Hi Jonas,
On 5/9/23 14:16, Kever Yang wrote:
On 2023/4/22 09:23, Jonas Karlman wrote:
Add sfc and flash node to device tree and config options to enable
support for booting from SPI NOR flash on Radxa ROCK 5 Model B.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 24
arch/arm/dts/rk3588s-u-boot.dtsi | 20
arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
configs/rock5b-rk3588_defconfig | 10 ++
4 files changed, 55 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 4bbc19058c90..b63dd40deb6d 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -11,6 +11,7 @@
/ {
aliases {
mmc1 =
+ spi0 =
};
chosen {
@@ -43,6 +44,25 @@
pinctrl-0 = <_bus8 _clk _cmd _data_strobe
_rstnout>;
};
+ {
+ bootph-pre-ram;
Any reason why the sfc and flash are pre-ram and the pins bootph-all ?
This used to be u-boot,dm-spl and was later replaced with bootph-pre-ram.
Right... but bootph-pre-ram means that the node is available in SPL
right ? But it will not be available 'post-ram' ?
For fspim2_pins I used the same bootph as the other pins. Not sure why
the pins use bootph-all to begin with, sdmmc and sdhci use bootph-pre-ram
in rk3588s-u-boot.dtsi.
Because out of my understanding, the pins should be available in all
bootstages, hence 'bootph-all' , they are needed all the time.
Please correct me if I am wrong, I am not very familiar with these new
names yet.
But 'pre-ram' suggests (at least to me) availability only in the initial
stage (SPL)
Otherwise what's the difference between bootph-all and bootph-pre-ram ?
Maybe that difference would enlighten me
Sorry for the long noise
+ u-boot,spl-sfc-no-dma;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ bootph-pre-ram;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2400>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ };
+};
+
{
bootph-all;
@@ -69,6 +89,10 @@
bootph-all;
};
+_pins {
+ bootph-all;
+};
+
_bus4 {
bootph-all;
};
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
b/arch/arm/dts/rk3588s-u-boot.dtsi
index cd7e6cb50ee2..d8a471a37fd1 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -104,6 +104,15 @@
};
};
+ sfc: spi@fe2b {
+ compatible = "rockchip,sfc";
+ reg = <0x0 0xfe2b 0x0 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_SFC>, < HCLK_SFC>;
+ clock-names = "clk_sfc", "hclk_sfc";
+ status = "disabled";
+ };
+
otp: nvmem@fecc {
compatible = "rockchip,rk3588-otp";
reg = <0x0 0xfecc 0x0 0x400>;
@@ -164,3 +173,14 @@
{
bootph-pre-ram;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+ offset = <0x8000>;
What is this offset referring to ?
This offset is referring to the normal mmc 32 KiB offset that idbloader
is normally written to. I used the offset prop so that the
u-boot-rockchip-spi.bin can be written to offset 0 of spi similar as is
currently done for rk3399.
Oh. I get it. thanks !
So it's the offset of 64 sectors that the rockchip tool needs.
I tried to write the u-boot-rockchip-spi.bin at offset 64 sectors, and
it boots into the SPL, but cannot read the FIT.
I tried to write it at offset 0, and then it boots correctly.
Interesting behavior.
Do you have to specify here the offset for the FIT, in binman ?
Or is it taken from CONFIG_SYS_SPI_U_BOOT_OFFS automatically ?
+ };
+ };
+};
+#endif
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 18e67b5ca9b2..0e85893e0096 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -41,6 +41,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE
+ 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
[BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
+ [6] = "/spi@fe2b/flash@0",
Is this '6' meaning something in particular ? or just the next number in
line ?
The bootrom on rk3588 use value 6 when booting from the spi flash on my
ROCK 5B, normally bootrom have used value 3 (BROM_BOOTSOURCE_SPINOR) on
rk356x and earlier socs.
I have no idea what we should call this BOOTSOURCE, could not find any
define in vendor u-boot to help give this a proper name.
Re: mmc: Read eMMC partition access bits before card reset
On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > > > On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > > > > On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > > > > > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > > > > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > > > > > > > On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > > > > > > > > On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > > > > > > > > > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > > > > > > > > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > > > > > > > please pull this next batch of mostly Marvell related > > > > > > > > > > > patches: > > > > > > > > > > > > > > > > > > > > NAK. With commit: > > > > > > > > > > commit 461fa17970de418a93832f734a595031c0b72128 > > > > > > > > > > Author: Pali Rohár > > > > > > > > > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > > > > > > > > > > > > > > > > > mmc: Read eMMC partition access bits before card reset > > > > > > > > > > > > > > > > > > > > eMMC specification in section "Access partitions" says > > > > > > > > > > that all reset > > > > > > > > > > events will restore the access bits in PARTITION_CONFIG > > > > > > > > > > CSD register to > > > > > > > > > > default User Data Area value (0b000). > > > > > > > > > > > > > > > > > > > > So read partition access bits from PARTITION_CONFIG CSD > > > > > > > > > > register before > > > > > > > > > > issuing card reset. This allows SPL/U-Boot to get > > > > > > > > > > information which eMMC > > > > > > > > > > partition was in use before SPL/U-Boot was booted. For > > > > > > > > > > some platforms this > > > > > > > > > > is the way how to determinate boot partition from which > > > > > > > > > > BootROM loaded SPL. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Pali Rohár > > > > > > > > > > > > > > > > > > > > My am335x_evm now fails to boot with: > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > > > > > > > > > 13:10:10 -0400) > > > > > > > > > > Trying to boot from MMC1 > > > > > > > > > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to > > > > > > > > > > clear > > > > > > > > > > spl: mmc init failed with error: -110 > > > > > > > > > > SPL: failed to boot from all boot devices > > > > > > > > > > ### ERROR ### Please RESET the board ### > > > > > > > > > > > > > > > > > > > > I can provide more details / test patches as needed. > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > I do not know what to do with this... The only idea is to > > > > > > > > > hide this code > > > > > > > > > behind CONFIG symbol and enable it only for mvebu. For > > > > > > > > > example by this: > > > > > > > > > > > > > > > > Well, maybe the problem is we're trying this on uSD cards? The > > > > > > > > failure I > > > > > > > > reported was uSD and not eMMC. > > > > > > > > > > > > > > Maybe it is that reason. Problem is that at this stage we do not > > > > > > > know if > > > > > > > card is SD or MMC. > > > > > > > > > > > > > > Martin, can you check if booting from SD card is working fine on > > > > > > > mvebu > > > > > > > clearfog? > > > > > > > > > > > > > > > I see a failure with this commit on > > > > > > > > rpi_3_32b, also from uSD boot. This time it's: > > > > > > > > Loading Environment from FAT... fsm 0, hsts > > > > > > > > fsm 0, hsts > > > > > > > > ... > > > > > > > > > > > > > > > > once in U-Boot itself. Going to the commit prior to the above > > > > > > > > one and > > > > > > > > the board is fine again. > > > > > > > > > > > > > > > > -- > > > > > > > > Tom > > > > > > > > > > > > > > Immediately after that "problematic code" is card reset function. > > > > > > > So > > > > > > > another reason for failure is that card reset functionality does > > > > > > > not > > > > > > > work correctly on your board / platform. > > > > > > > > > > > > Well, we're at two different platforms and controllers that this > > > > > > change > > > > > > breaks things on, so I'm not sure where the fault is exactly. My > > > > > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > > > > > the > > > > > > same general era as am335x fails the same way (not a surprise), > > > > > > amlogic > > > > > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > > > > > platforms are > > > > > > also fine with this. So maybe the Kconfig is fine, but we just want > > > > > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > > > > > platforms > > > > > > that work are not ARCH_OMAP2PLUS). > > > > > > > > > >
Re: [PATCH] gpio: renesas: Simplify .request/.rfree callbacks
PING?
Another patch mentioned today which stay there for more than 8 months?
On Tuesday 02 August 2022 12:06:55 Pali Rohár wrote:
> Remove identify wrapper functions.
>
> Signed-off-by: Pali Rohár
> ---
> drivers/gpio/gpio-rcar.c | 15 ++-
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
> index 138801850d3e..ba00bb459679 100644
> --- a/drivers/gpio/gpio-rcar.c
> +++ b/drivers/gpio/gpio-rcar.c
> @@ -130,20 +130,9 @@ static int rcar_gpio_get_function(struct udevice *dev,
> unsigned offset)
> return GPIOF_INPUT;
> }
>
> -static int rcar_gpio_request(struct udevice *dev, unsigned offset,
> - const char *label)
> -{
> - return pinctrl_gpio_request(dev, offset, label);
> -}
> -
> -static int rcar_gpio_free(struct udevice *dev, unsigned offset)
> -{
> - return pinctrl_gpio_free(dev, offset);
> -}
> -
> static const struct dm_gpio_ops rcar_gpio_ops = {
> - .request= rcar_gpio_request,
> - .rfree = rcar_gpio_free,
> + .request= pinctrl_gpio_request,
> + .rfree = pinctrl_gpio_free,
> .direction_input= rcar_gpio_direction_input,
> .direction_output = rcar_gpio_direction_output,
> .get_value = rcar_gpio_get_value,
> --
> 2.20.1
>
Re: [PATCH 1/1] config: CONFIG_SPL_SIZE_LIMIT for VisionFive 2
On 5/16/23 6:11 AM, Heinrich Schuchardt wrote: The size of SPL including the 1 KiB header added by spl_tool may not exceed 128 KiB. Without the header this leaves 127 KiB for spl/u-boot-spl.bin. We should check this value when building to avoid oversized binaries. +CONFIG_SPL_SIZE_LIMIT=0x1fc00 Hi Heinrich, would you mind specify where the limit is coming from? I flashed my vf2 board with a ~140KiB SPL without any problem.
Re: [PATCH v2 0/4] Remove misuse of env is nowhere driver
On Tue, 02 May 2023 12:23:01 +0200, Stefan Herbrechtsmeier wrote:
> From: Stefan Herbrechtsmeier
>
>
> When using a list of writeable variables, the initial values come from
> the built-in default environment since commit 5ab81058364b
> ("env: Complete generic support for writable list"). Remove unnecessary
> misuse of the env is nowhere driver as default environment.
>
> [...]
Applied to u-boot/next, thanks!
--
Tom
Re: [PULL] u-boot-sh/next_gpio
On Wed, May 17, 2023 at 01:48:49AM +0200, Marek Vasut wrote: > The following changes since commit 5d0b3dde115b0d26d414199678983d01b738ad1b: > > Merge branch '2023-05-15-build-system-updates' into next (2023-05-15 > 15:26:54 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sh.git next_gpio > > for you to fetch changes up to a74931a945960c84aa1a68169c6d3709730dfc12: > > gpio: renesas: Simplify .request/.rfree callbacks (2023-05-16 22:24:24 > +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 08/17] sunxi: introduce NCAT2 generation model
On Tue, 16 May 2023 17:53:38 -0600
Sam Edwards wrote:
Hi Sam,
> On 5/16/23 15:08, Andre Przywara wrote:
> > This whole memory map is somewhat of a legacy. Apart from a few
> > addresses for the SPL needs we shouldn't have those defines at all.
> > Some symbols are needed because there are other macros using them,
> > although these then are eventually unused.
> > I have some patches to remove most of the symbols, and patch 14/17
> > demonstrates some idea how to pin this down to what's really needed.
> >
> > For this particular case: this was copied from the H6 memory map, some
> > addresses are just plain wrong for the D1 family. I will try to remove
> > them as much as possible, leaving only the ones needed in.
>
> I see - the only "tangible" concern I had was the access to
> prcm->res_cal_ctrl done in
> arch/arm/mach-sunxi/clock_sun50i_h6.c:clock_init_safe
>
> This doesn't appear to upset the silicon but also doesn't seem necessary
> either -- and with how tight of a memory footprint SPL has to fit into,
What's the particular concern here? Compared to the A64 we are pretty
cool: it's Thumb2 code and we are at around 27KB, at least with my
toolchain. And I haven't tried, but I am pretty sure the BROM
loads more than 32K, as it does on the H6 and H616 already. The U-Boot
build system and the code already supports this - we rely on this for
the H616 - so we can lift the limit anytime, if really needed.
> I wanted to check whether this was just something undocumented or dead
> code that needed to be removed. It sounds like it's mostly the latter.
I haven't checked if the vendor boot0 does this. I am pretty sure there
is a PRCM block, it's just regularly not mentioned in the manuals.
> > So where did you see problems? If you would (wrongly) reference
> > PortL somewhere in SPL GPIO code, it would use a wrong pointer, but at
> > least the code would still compile fine, wouldn't it?
>
> The specific patch I had to apply (to arch/arm/mach-sunxi/board.c) was:
> /* Update PIO power bias configuration by copy hardware
> detected value */
> val = readl(SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> writel(val, SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> - val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> - writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> + if (SUNXI_R_PIO_BASE) {
> + val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
> + writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
> + }
Ah, I see, I indeed missed that. We seem to define all symbols anyway,
so we can even lose the #ifdef and use proper if's here.
Will incorporate that in the next drop.
> With SUNXI_R_PIO_BASE being 0, this was actually attempting to write to
> BROM. This might also be something that doesn't really upset the
> silicon, though: my debug environment is a concolic emulator I quickly
> hacked up to trace MMIO accesses, and it flagged the write to BROM as an
> error. It was easier to patch the SPL than to have the emulator ignore
> the error (and verify that the T113 was cool with it).
Ah yeah, the Allwinner interconnect is pretty relaxed about those
things: accesses to addresses with no device behind them are usually
ignored (RAZ/WI), where other platform might throw an external abort.
Writes to ROM areas are ignored as well.
> Since this kind of extraneous/erroneous init code tends to remain
> undetected when the symbols they need are dummied-out like this, I
> figured I'd give a nudge in the direction of instead *removing* the
> symbols where appropriate and fixing whatever breaks -- especially since
> we really need to be thrifty about SPL size. But that might also be
> something that happens in a later cleanup pass when the patchset is
> being prepared for upstream inclusion. :)
>
> > P.S. Could you try the github post? Then compiled and booted fine for
> > me, and includes the DRAM code as well now:
> > https://github.com/apritzel/u-boot/commits/t113s-mq-r-WIP
>
> Ooh, more up-to-date code, thanks for the link! I'll switch to using
> this instead going forward. My pulls from that branch might be
> relatively infrequent
Don't worry, I won't push to this anymore.
> since I'm also working on some patches for better
> Clang compatibility concurrent with the efforts here. Is this email
> thread a good venue for feedback against that branch or would you prefer
> that I use GitHub issues instead?
Please use this thread here, if you find something still wrong in the
branch. I just pushed it to github since someone asked for a fixed
and complete version, and I didn't have time to prepare a proper post
again.
I will hopefully post a proper version for upstreaming in the next days.
> Warm regards,
> Sam
>
> P.S. My target is the BMC on the Turing Pi 2 board.
Ah, interesting, didn't know that this is now a BMC - for a
SoC from Allwinner's arch nemesis Rockchip
[PATCH 3/4] usb: gadget: ether: Move probe function above driver structure
Move the driver probe function above the driver structure, so it
can be placed alongside other related functions, like upcoming
remove function. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
drivers/usb/gadget/ether.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 88c656c4dc0..2040b5b5081 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2486,20 +2486,6 @@ static int usb_eth_free_pkt(struct udevice *dev, uchar
*packet,
return rx_submit(ethdev, ethdev->rx_req, 0);
}
-static int usb_eth_probe(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
- struct eth_pdata *pdata = dev_get_plat(dev);
-
- priv->netdev = dev;
- l_priv = priv;
-
- get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
- eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
-
- return 0;
-}
-
static const struct eth_ops usb_eth_ops = {
.start = usb_eth_start,
.send = usb_eth_send,
@@ -2528,6 +2514,20 @@ int usb_ether_init(void)
return 0;
}
+static int usb_eth_probe(struct udevice *dev)
+{
+ struct ether_priv *priv = dev_get_priv(dev);
+ struct eth_pdata *pdata = dev_get_plat(dev);
+
+ priv->netdev = dev;
+ l_priv = priv;
+
+ get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
+ eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
+
+ return 0;
+}
+
U_BOOT_DRIVER(eth_usb) = {
.name = "usb_ether",
.id = UCLASS_ETH,
--
2.39.2
[PATCH 1/4] cmd: bind: Add unbind command with driver filter
Extend the driver core to perform lookup by both OF node and driver
bound to the node. Use this to look up specific device instances to
unbind from nodes in the unbind command. One example where this is
needed is USB peripheral controller, which may have multiple gadget
drivers bound to it. The unbind command has to select that specific
gadget driver instance to unbind from the controller, not unbind the
controller driver itself from the controller.
USB ethernet gadget usage looks as follows with this change. Notice
the extra 'usb_ether' addition in the 'unbind' command at the end.
"
bind /soc/usb-otg@4900 usb_ether
setenv ethact usb_ether
setenv loadaddr 0xc200
setenv ipaddr 10.0.0.2
setenv serverip 10.0.0.1
setenv netmask 255.255.255.0
tftpboot 0xc200 10.0.0.1:test.file
unbind /soc/usb-otg@4900 usb_ether
"
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
cmd/bind.c| 10 +-
drivers/core/device.c | 20 +++-
include/dm/device.h | 17 +
3 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/cmd/bind.c b/cmd/bind.c
index 4d1b7885e60..3137cdf6cb5 100644
--- a/cmd/bind.c
+++ b/cmd/bind.c
@@ -162,7 +162,7 @@ static int bind_by_node_path(const char *path, const char
*drv_name)
return 0;
}
-static int unbind_by_node_path(const char *path)
+static int unbind_by_node_path(const char *path, const char *drv_name)
{
struct udevice *dev;
int ret;
@@ -174,7 +174,7 @@ static int unbind_by_node_path(const char *path)
return -EINVAL;
}
- ret = device_find_global_by_ofnode(ofnode, );
+ ret = device_find_global_by_ofnode_driver(ofnode, drv_name, );
if (!dev || ret) {
printf("Cannot find a device with path %s\n", path);
@@ -214,9 +214,9 @@ static int do_bind_unbind(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_USAGE;
ret = bind_by_node_path(argv[1], argv[2]);
} else if (by_node && !bind) {
- if (argc != 2)
+ if (argc != 2 && argc != 3)
return CMD_RET_USAGE;
- ret = unbind_by_node_path(argv[1]);
+ ret = unbind_by_node_path(argv[1], argv[2]);
} else if (!by_node && bind) {
int index = (argc > 2) ? dectoul(argv[2], NULL) : 0;
@@ -251,7 +251,7 @@ U_BOOT_CMD(
U_BOOT_CMD(
unbind, 4, 0, do_bind_unbind,
"Unbind a device from a driver",
- "\n"
+ " []\n"
"unbind \n"
"unbind \n"
);
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 6e26b64fb81..52fceb69341 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -877,15 +877,17 @@ int device_get_child_by_of_offset(const struct udevice
*parent, int node,
}
static struct udevice *_device_find_global_by_ofnode(struct udevice *parent,
-ofnode ofnode)
+ofnode ofnode,
+const char *drv)
{
struct udevice *dev, *found;
- if (ofnode_equal(dev_ofnode(parent), ofnode))
+ if (ofnode_equal(dev_ofnode(parent), ofnode) &&
+ (!drv || (drv && !strcmp(parent->driver->name, drv
return parent;
device_foreach_child(dev, parent) {
- found = _device_find_global_by_ofnode(dev, ofnode);
+ found = _device_find_global_by_ofnode(dev, ofnode, drv);
if (found)
return found;
}
@@ -895,7 +897,15 @@ static struct udevice
*_device_find_global_by_ofnode(struct udevice *parent,
int device_find_global_by_ofnode(ofnode ofnode, struct udevice **devp)
{
- *devp = _device_find_global_by_ofnode(gd->dm_root, ofnode);
+ *devp = _device_find_global_by_ofnode(gd->dm_root, ofnode, NULL);
+
+ return *devp ? 0 : -ENOENT;
+}
+
+int device_find_global_by_ofnode_driver(ofnode ofnode, const char *drv,
+ struct udevice **devp)
+{
+ *devp = _device_find_global_by_ofnode(gd->dm_root, ofnode, drv);
return *devp ? 0 : -ENOENT;
}
@@ -904,7 +914,7 @@ int device_get_global_by_ofnode(ofnode ofnode, struct
udevice **devp)
{
struct udevice *dev;
- dev = _device_find_global_by_ofnode(gd->dm_root, ofnode);
+ dev = _device_find_global_by_ofnode(gd->dm_root, ofnode, NULL);
return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
}
diff --git a/include/dm/device.h b/include/dm/device.h
index b86bf90609b..5f05ae0924f 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -748,6 +748,23 @@ int device_get_child_by_of_offset(const struct udevice
*parent, int of_offset,
int device_find_global_by_ofnode(ofnode node, struct udevice **devp);
+/**
+ *
[PATCH 2/4] usb: gadget: ether: Inline functions used once
These functions here are only ever called once since drop of non-DM
networking code. Inline them. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
drivers/usb/gadget/ether.c | 48 +++---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 85c971e4c43..88c656c4dc0 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2273,10 +2273,11 @@ fail:
}
/*-*/
-static void _usb_eth_halt(struct ether_priv *priv);
+static void usb_eth_stop(struct udevice *dev);
-static int _usb_eth_init(struct ether_priv *priv)
+static int usb_eth_start(struct udevice *udev)
{
+ struct ether_priv *priv = dev_get_priv(udev);
struct eth_dev *dev = >ethdev;
struct usb_gadget *gadget;
unsigned long ts;
@@ -2347,12 +2348,13 @@ static int _usb_eth_init(struct ether_priv *priv)
rx_submit(dev, dev->rx_req, 0);
return 0;
fail:
- _usb_eth_halt(priv);
+ usb_eth_stop(udev);
return -1;
}
-static int _usb_eth_send(struct ether_priv *priv, void *packet, int length)
+static int usb_eth_send(struct udevice *udev, void *packet, int length)
{
+ struct ether_priv *priv = dev_get_priv(udev);
int retval;
void*rndis_pkt = NULL;
struct eth_dev *dev = >ethdev;
@@ -2419,15 +2421,9 @@ drop:
return -ENOMEM;
}
-static int _usb_eth_recv(struct ether_priv *priv)
-{
- usb_gadget_handle_interrupts(0);
-
- return 0;
-}
-
-static void _usb_eth_halt(struct ether_priv *priv)
+static void usb_eth_stop(struct udevice *udev)
{
+ struct ether_priv *priv = dev_get_priv(udev);
struct eth_dev *dev = >ethdev;
/* If the gadget not registered, simple return */
@@ -2459,31 +2455,12 @@ static void _usb_eth_halt(struct ether_priv *priv)
usb_gadget_release(0);
}
-static int usb_eth_start(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- return _usb_eth_init(priv);
-}
-
-static int usb_eth_send(struct udevice *dev, void *packet, int length)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- return _usb_eth_send(priv, packet, length);
-}
-
static int usb_eth_recv(struct udevice *dev, int flags, uchar **packetp)
{
struct ether_priv *priv = dev_get_priv(dev);
struct eth_dev *ethdev = >ethdev;
- int ret;
- ret = _usb_eth_recv(priv);
- if (ret) {
- pr_err("error packet receive\n");
- return ret;
- }
+ usb_gadget_handle_interrupts(0);
if (packet_received) {
if (ethdev->rx_req) {
@@ -2509,13 +2486,6 @@ static int usb_eth_free_pkt(struct udevice *dev, uchar
*packet,
return rx_submit(ethdev, ethdev->rx_req, 0);
}
-static void usb_eth_stop(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- _usb_eth_halt(priv);
-}
-
static int usb_eth_probe(struct udevice *dev)
{
struct ether_priv *priv = dev_get_priv(dev);
--
2.39.2
Re: [PATCH 00/14] rockchip: rk35xx: Update defconfigs and enable boot from SPI NOR flash
Hi Jonas, On 2023/5/10 14:48, Jonas Karlman wrote: Looks like the following two commits in your enablement efforts tree may be a source of some of these dependency conflicts. - rockchip: rk3588-rock-5b: Add spi nor flash node - ARM: dts: rockchip: rk3588-rock-5b-u-boot: enable SPI flash in SPL Those commits should come after all your pending series, same/similar commits are included in this defconfig/spinor series, series that I have tried to base on top of your series I will rebase my series on top of rockchip U-Boot Custodian Tree master and Eugen's series. I had some time over and prepared a rebase branch with the following series from Eugen: [2/2] reset: rockchip: implement rk3588 lookup table https://patchwork.ozlabs.org/project/uboot/patch/20230413113646.261415-2-eugen.hris...@collabora.com/ [v5,1/6] ARM: dts: rockchip: rk3588-rock-5b-u-boot: add USB 2.0 host https://patchwork.ozlabs.org/project/uboot/list/?series=351534 [v3,1/2] ARM: dts: rk3588-rock-5b-u-boot: add bootph-all to pinctrl for sdmmc https://patchwork.ozlabs.org/project/uboot/list/?series=351078 [v3,1/7] pci: pcie_dw_rockchip: Add rk3588 compatible https://patchwork.ozlabs.org/project/uboot/list/?series=352596 This patch set will need a rebase due to conflict since 0005. And on top of those my series: rockchip: rk35xx: Update defconfigs and enable boot from SPI NOR flash https://patchwork.ozlabs.org/project/uboot/list/?series=351973 Conflict since 0008 rockchip: rk3568-rock-3a: Enable boot from SPI NOR flash rockchip: Fix eMMC performance regression https://patchwork.ozlabs.org/project/uboot/list/?series=353826 Conflict for configs/rock-pi-4-rk3399_defconfig in 0004 rockchip: rock-pi-4: Use SDMA to boost eMMC performance Please send the update, maybe after new version "pci: pcie_dw_rockchip: Add rk3588 compatible" from Eugen. I have apply part of these patches for the driver is fine and conflict only happen in dts level. Will apply new version if available. Thanks, - Kever I think that should be the correct apply order. The rebase branch can be found at: https://github.com/Kwiboo/u-boot-rockchip/commits/rebase-20230510a I will hold off on sending out my v2 series until Eugen have had a chance to finalize and send out his series
[PATCH 4/4] usb: gadget: ether: Handle gadget driver registration in probe and remove
Move the ethernet gadget driver registration and removal from ethernet
bind and unbind callbacks into driver DM probe and remove callbacks.
This way, when the driver is bound, which is triggered deliberately
using 'bind' command, the USB ethernet gadget driver is instantiated
and bound to the matching UDC. In reverse, when the driver is unbound,
which is again triggered deliberately using 'unbind' command, the USB
ethernet gadget driver instance is removed.
Effectively, this now behaves like running either 'ums' or 'dfu' or
any other commands utilizing USB gadget functionality.
This also drops use of usb_gadget_initialize()/usb_gadget_release(),
which are helper functions implemented in the UDC uclass to bind and
unbind UDC drivers to controllers from U-Boot command line. Those have
no place in drivers.
Signed-off-by: Marek Vasut
---
NOTE: This must be thoroughly tested.
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
drivers/usb/gadget/ether.c | 95 --
1 file changed, 51 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 2040b5b5081..55853fa98fd 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2281,49 +2281,8 @@ static int usb_eth_start(struct udevice *udev)
struct eth_dev *dev = >ethdev;
struct usb_gadget *gadget;
unsigned long ts;
- int ret;
unsigned long timeout = USB_CONNECT_TIMEOUT;
- ret = usb_gadget_initialize(0);
- if (ret)
- return ret;
-
- /* Configure default mac-addresses for the USB ethernet device */
-#ifdef CONFIG_USBNET_DEV_ADDR
- strlcpy(dev_addr, CONFIG_USBNET_DEV_ADDR, sizeof(dev_addr));
-#endif
-#ifdef CONFIG_USBNET_HOST_ADDR
- strlcpy(host_addr, CONFIG_USBNET_HOST_ADDR, sizeof(host_addr));
-#endif
- /* Check if the user overruled the MAC addresses */
- if (env_get("usbnet_devaddr"))
- strlcpy(dev_addr, env_get("usbnet_devaddr"),
- sizeof(dev_addr));
-
- if (env_get("usbnet_hostaddr"))
- strlcpy(host_addr, env_get("usbnet_hostaddr"),
- sizeof(host_addr));
-
- if (!is_eth_addr_valid(dev_addr)) {
- pr_err("Need valid 'usbnet_devaddr' to be set");
- goto fail;
- }
- if (!is_eth_addr_valid(host_addr)) {
- pr_err("Need valid 'usbnet_hostaddr' to be set");
- goto fail;
- }
-
- priv->eth_driver.speed = DEVSPEED;
- priv->eth_driver.bind = eth_bind;
- priv->eth_driver.unbind = eth_unbind;
- priv->eth_driver.setup = eth_setup;
- priv->eth_driver.reset = eth_disconnect;
- priv->eth_driver.disconnect = eth_disconnect;
- priv->eth_driver.suspend= eth_suspend;
- priv->eth_driver.resume = eth_resume;
- if (usb_gadget_register_driver(>eth_driver) < 0)
- goto fail;
-
dev->network_started = 0;
packet_received = 0;
@@ -2450,9 +2409,6 @@ static void usb_eth_stop(struct udevice *udev)
usb_gadget_handle_interrupts(0);
dev->network_started = 0;
}
-
- usb_gadget_unregister_driver(>eth_driver);
- usb_gadget_release(0);
}
static int usb_eth_recv(struct udevice *dev, int flags, uchar **packetp)
@@ -2518,6 +2474,7 @@ static int usb_eth_probe(struct udevice *dev)
{
struct ether_priv *priv = dev_get_priv(dev);
struct eth_pdata *pdata = dev_get_plat(dev);
+ int ret;
priv->netdev = dev;
l_priv = priv;
@@ -2525,6 +2482,55 @@ static int usb_eth_probe(struct udevice *dev)
get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
+ /* Configure default mac-addresses for the USB ethernet device */
+#ifdef CONFIG_USBNET_DEV_ADDR
+ strlcpy(dev_addr, CONFIG_USBNET_DEV_ADDR, sizeof(dev_addr));
+#endif
+#ifdef CONFIG_USBNET_HOST_ADDR
+ strlcpy(host_addr, CONFIG_USBNET_HOST_ADDR, sizeof(host_addr));
+#endif
+ /* Check if the user overruled the MAC addresses */
+ if (env_get("usbnet_devaddr"))
+ strlcpy(dev_addr, env_get("usbnet_devaddr"),
+ sizeof(dev_addr));
+
+ if (env_get("usbnet_hostaddr"))
+ strlcpy(host_addr, env_get("usbnet_hostaddr"),
+ sizeof(host_addr));
+
+ if (!is_eth_addr_valid(dev_addr)) {
+ pr_err("Need valid 'usbnet_devaddr' to be set");
+ goto fail;
+ }
+ if (!is_eth_addr_valid(host_addr)) {
+ pr_err("Need valid 'usbnet_hostaddr' to be set");
+ goto fail;
+ }
+
+ priv->eth_driver.speed = DEVSPEED;
+ priv->eth_driver.bind = eth_bind;
+ priv->eth_driver.unbind =
Re: [PATCH v4 1/2] ARM: dts: rk3588-rock-5b-u-boot: add bootph-all to pinctrl for sdmmc
On 2023/5/15 21:44, Eugen Hristev wrote:
To be able to initialize the pinctrl correctly at SPL level and read
u-boot proper from SD-Card, the pinctrl must be initialized.
Signed-off-by: Eugen Hristev
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changes in v4:
- rebased on latest master: This is also on top of the USB 2.0 series !
Changes in v3:
- change to bootph-all props.
Changes in v2:
- add u-boot,dm-spl to pull up nodes, to also setup the pull control
correctly. Also, in the loop that initializes multiple pins, only the
first will be muxed as the loop will break when the pull up node is not
found.
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 26 +
1 file changed, 26 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 53d029c60e8f..e9fcb7b92eb3 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -31,6 +31,8 @@
};
{
+ bootph-all;
+
usb {
vcc5v0_host_en: vcc5v0-host-en {
rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO _pull_none>;
@@ -38,11 +40,35 @@
};
};
+_pull_up_drv_level_2 {
+ bootph-all;
+};
+
+_pull_up {
+ bootph-all;
+};
+
{
bus-width = <4>;
status = "okay";
};
+_bus4 {
+ bootph-all;
+};
+
+_clk {
+ bootph-all;
+};
+
+_cmd {
+ bootph-all;
+};
+
+_det {
+ bootph-all;
+};
+
{
cap-mmc-highspeed;
mmc-ddr-1_8v;
Re: [PATCH v4 2/2] configs: rockchip: rock5b-rk3588: add pinctrl to SPL
On 2023/5/15 21:44, Eugen Hristev wrote: Add pinctrl driver in SPL. Do not remove pinctrl properties for SPL dtb. Signed-off-by: Eugen Hristev Reviewed-by: Kever Yang Thanks, - Kever --- Changes in v4: - rebased on master: Warning ! This is rebased on top of the USB 2.0 series ! Changes in v2,v3: - no change configs/rock5b-rk3588_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index 8a3d356f729e..95271c312c51 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -47,7 +47,7 @@ CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIVE=y -CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y @@ -65,6 +65,7 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_SPL_PINCTRL=y CONFIG_REGULATOR_PWM=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_ROCKCHIP=y
Re: [RFC PATCH 08/17] sunxi: introduce NCAT2 generation model
On 5/16/23 15:08, Andre Przywara wrote:
This whole memory map is somewhat of a legacy. Apart from a few
addresses for the SPL needs we shouldn't have those defines at all.
Some symbols are needed because there are other macros using them,
although these then are eventually unused.
I have some patches to remove most of the symbols, and patch 14/17
demonstrates some idea how to pin this down to what's really needed.
For this particular case: this was copied from the H6 memory map, some
addresses are just plain wrong for the D1 family. I will try to remove
them as much as possible, leaving only the ones needed in.
I see - the only "tangible" concern I had was the access to
prcm->res_cal_ctrl done in
arch/arm/mach-sunxi/clock_sun50i_h6.c:clock_init_safe
This doesn't appear to upset the silicon but also doesn't seem necessary
either -- and with how tight of a memory footprint SPL has to fit into,
I wanted to check whether this was just something undocumented or dead
code that needed to be removed. It sounds like it's mostly the latter.
So where did you see problems? If you would (wrongly) reference
PortL somewhere in SPL GPIO code, it would use a wrong pointer, but at
least the code would still compile fine, wouldn't it?
The specific patch I had to apply (to arch/arm/mach-sunxi/board.c) was:
/* Update PIO power bias configuration by copy hardware
detected value */
val = readl(SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
writel(val, SUNXI_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
- val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
- writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
+ if (SUNXI_R_PIO_BASE) {
+ val = readl(SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_VAL);
+ writel(val, SUNXI_R_PIO_BASE + SUN50I_H6_GPIO_POW_MOD_SEL);
+ }
With SUNXI_R_PIO_BASE being 0, this was actually attempting to write to
BROM. This might also be something that doesn't really upset the
silicon, though: my debug environment is a concolic emulator I quickly
hacked up to trace MMIO accesses, and it flagged the write to BROM as an
error. It was easier to patch the SPL than to have the emulator ignore
the error (and verify that the T113 was cool with it).
Since this kind of extraneous/erroneous init code tends to remain
undetected when the symbols they need are dummied-out like this, I
figured I'd give a nudge in the direction of instead *removing* the
symbols where appropriate and fixing whatever breaks -- especially since
we really need to be thrifty about SPL size. But that might also be
something that happens in a later cleanup pass when the patchset is
being prepared for upstream inclusion. :)
P.S. Could you try the github post? Then compiled and booted fine for
me, and includes the DRAM code as well now:
https://github.com/apritzel/u-boot/commits/t113s-mq-r-WIP
Ooh, more up-to-date code, thanks for the link! I'll switch to using
this instead going forward. My pulls from that branch might be
relatively infrequent since I'm also working on some patches for better
Clang compatibility concurrent with the efforts here. Is this email
thread a good venue for feedback against that branch or would you prefer
that I use GitHub issues instead?
Warm regards,
Sam
P.S. My target is the BMC on the Turing Pi 2 board. They have the same
SoC and (apparently) UART console configuration, but the differences end
there: in particular, my target supports boot from either/both
microSD+SPI-NAND. I might have to start pushing for room for SPI drivers
in the SPL soon. :)
Re: [PATCH 1/1] config: CONFIG_SPL_SIZE_LIMIT for VisionFive 2
@Heinrich Some background information I discovered by experimenting with my vf2 board: The only reasonable place to load SPL is the L2 LIM, which is 2M in size mapped at 0x800. This region consists of 16 0x2 sized regions, each one can be used as either L2 cache way or SRAM (not both). From top to bottom, you have way 0-15. When ways are enabled, they can't be disabled without reset. Effectively, as you enabling more and more L2 cache, this SRAM region shrinks. The way 0 is always enabled, so SPL can only use at most 0x1e bytes of memory. On 5/16/23 12:56 PM, Heinrich Schuchardt wrote: https://github.com/starfive-tech/Tools/commit/8c5acc4e5eb7e4ad012463b05a5e3dbbfed1c38d seems to have changed the limit in the tooling. I don't know how they derive the number 180048, but my guess is they just pick some number that fits their u-boot build. For correctness, it really depends on how ROM is loading SPL, and where does ROM allocate its data/stack during loading, so it won't collide with the SPL being loaded. It might also be that ROM uses S7 DTIM to load SPL, and doesn't touch L2 LIM at all. The ROM is close-sourced, thus, not very easy to know without reverse-engineering it. The defconfig already defines https://github.com/u-boot/u-boot/blob/6e1852c/configs/starfive_visionfive2_defconfig#L37 CONFIG_SPL_MAX_SIZE=0x4 CONFIG_SPL_BSS_START_ADDR=0x804 256KiB of SPL sounds like a reasonable number to me. 128KiB might be a little bit small when you have max loglevels enabled, and -DDEBUG. I think we can probably just change CONFIG_SPL_MAX_SIZE to CONFIG_SPL_SIZE_LIMIT, and be done with it.
Re: [PATCH v3 7/7] configs: rock5b-rk3588: add PCI drivers and command
Hi Eugen, On 2023/5/16 17:20, Eugen Hristev wrote: On 5/6/23 12:44, Kever Yang wrote: On 2023/4/27 15:35, Eugen Hristev wrote: Add drivers for PCIe , phy, and command. Signed-off-by: Eugen Hristev Reviewed-by: Kever Yang Thanks, - Kever --- Hi Kever, Do you need me to resend this series as well ? If you need help in applying, or specifying the order of patches, let me know. I have rebased some of the series, order of applying at the moment is : https://patchwork.ozlabs.org/project/uboot/patch/20230515095950.23666-1-eugen.hris...@collabora.com/ and then https://patchwork.ozlabs.org/project/uboot/patch/20230515134403.38485-1-eugen.hris...@collabora.com/ I got conflict since patch 0005 after apply these two patch sets. So a rebase of this patch set will be better after previous two patch sets. Thanks, - Kever if you apply these to your tree I can then send patches on top of your branch, if that is better for you ? Thanks, Eugen
Re: [tiU23.04 PATCH 0/4] HS booting cleanup
Kindly ignore the series Regards, Manorit From: Chawdhry, Manorit Sent: Wednesday, May 17, 2023 10:31:42 AM To: Nagalla, Hari; Raghavendra, Vignesh; Brattlof, Bryan Cc: Chawdhry, Manorit; u-boot@lists.denx.de; Kumar, Udit; Bajjuri, Praneeth; Francis, Neha Subject: [tiU23.04 PATCH 0/4] HS booting cleanup Test results http://lcpdresults.itg.ti.com/launcher/results/14057 Cc: u-boot@lists.denx.de To: Hari Nagalla To: Vignesh Raghavendra To: Bryan Brattlof Cc: Udit Kumar Cc: Praneeth Bajjuri Cc: Neha Malcom Francis Signed-off-by: Manorit Chawdhry --- Manorit Chawdhry (4): configs: remove explicit not set of setexpr configs: keep the bootcmd consistent across jacinto configs: j7*: remove saved environments configs: enable signed fit booting across all k3 socs boot/Kconfig | 3 +-- configs/am62ax_evm_a53_defconfig | 2 ++ configs/am62x_evm_a53_defconfig | 2 ++ configs/am64x_evm_a53_defconfig | 2 ++ configs/j7200_evm_a72_defconfig | 8 configs/j721e_evm_a72_defconfig | 7 +++ configs/j721s2_evm_a72_defconfig | 9 - configs/j784s4_evm_a72_defconfig | 5 ++--- 8 files changed, 20 insertions(+), 18 deletions(-) --- base-commit: c22f1ee591f84ab28c025d7aed9ee10c7f0154c1 change-id: 20230515-b4-internal-setexpr-fix-1876f8cff5e4 Best regards, -- Manorit Chawdhry
[tiU23.04 PATCH 4/4] configs: enable signed fit booting across all k3 socs
We are moving towards the standard fit signature booting that requires
the following configs to be enabled, enable them in all k3 socs to allow
signed fit booting.
Signed-off-by: Manorit Chawdhry
---
boot/Kconfig | 3 +--
configs/am62ax_evm_a53_defconfig | 2 ++
configs/am62x_evm_a53_defconfig | 2 ++
configs/am64x_evm_a53_defconfig | 2 ++
configs/j7200_evm_a72_defconfig | 2 ++
configs/j721e_evm_a72_defconfig | 2 ++
configs/j721s2_evm_a72_defconfig | 2 ++
7 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/boot/Kconfig b/boot/Kconfig
index b23959900cc6..359cd516e951 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -125,8 +125,7 @@ config FIT_BEST_MATCH
config FIT_IMAGE_POST_PROCESS
bool "Enable post-processing of FIT artifacts after loading by U-Boot"
depends on FIT
- depends on TI_SECURE_DEVICE || SOCFPGA_SECURE_VAB_AUTH
- default y if TI_SECURE_DEVICE && !FIT_SIGNATURE
+ depends on SOCFPGA_SECURE_VAB_AUTH
help
Allows doing any sort of manipulation to blobs after they got
extracted
from FIT images like stripping off headers or modifying the size of
the
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 10c9d5268c84..b09acf436d57 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -41,6 +41,8 @@ CONFIG_SPL_OF_CONTROL=y
CONFIG_MULTI_DTB_FIT=y
CONFIG_SPL_MULTI_DTB_FIT=y
CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_RSA=y
CONFIG_SPL_DM=y
CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_REGMAP=y
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 604df4729217..f4769b72f8cd 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -29,6 +29,8 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
setenv fdtfile ti/${name_fdt}; run distro_bootcmd"
+CONFIG_FIT_SIGNATURE=y
+CONFIG_RSA=y
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80a0
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index e5812a2aa4a5..dd4212878997 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -35,6 +35,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_FIT_SIGNATURE=y
+CONFIG_RSA=y
CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x18
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 98dfbe6cac3a..699cdbe170b3 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -34,6 +34,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi; run distro_bootcmd"
+CONFIG_FIT_SIGNATURE=y
+CONFIG_RSA=y
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index b3a855c6ba22..d9c988381b5d 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -32,6 +32,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi; run distro_bootcmd"
+CONFIG_FIT_SIGNATURE=y
+CONFIG_RSA=y
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index 4928f42af630..10c4f7662e40 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -32,6 +32,8 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi; run distro_bootcmd"
+CONFIG_FIT_SIGNATURE=y
+CONFIG_RSA=y
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
[tiU23.04 PATCH 1/4] configs: remove explicit not set of setexpr
Keeping this line in defconfigs doesn't allow the Kconfig values to be reflected, remove these to enabled use of setexpr used for fit image booting. Signed-off-by: Manorit Chawdhry --- configs/j7200_evm_a72_defconfig | 1 - configs/j721e_evm_a72_defconfig | 1 - configs/j721s2_evm_a72_defconfig | 1 - 3 files changed, 3 deletions(-) diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig index b60eccf75a35..19670b0da3c1 100644 --- a/configs/j7200_evm_a72_defconfig +++ b/configs/j7200_evm_a72_defconfig @@ -78,7 +78,6 @@ CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_UFS=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0,nor0=47034000.hyperbus" diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 645c5b45e9c5..1b0358a642c2 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -76,7 +76,6 @@ CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_UFS=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0,nor0=47034000.hyperbus" diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig index 15ce93959de4..884e2f5fe38b 100644 --- a/configs/j721s2_evm_a72_defconfig +++ b/configs/j721s2_evm_a72_defconfig @@ -77,7 +77,6 @@ CONFIG_CMD_REMOTEPROC=y CONFIG_CMD_UFS=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y -# CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=4704.spi.0,nor0=47034000.hyperbus" -- 2.34.1
[tiU23.04 PATCH 2/4] configs: keep the bootcmd consistent across jacinto
Since moving towards distroboot, we need a way to boot using the legacy
methods too so keep the bootcmd consistent across devices to keep both
the flows running.
Signed-off-by: Manorit Chawdhry
---
configs/j7200_evm_a72_defconfig | 2 +-
configs/j721e_evm_a72_defconfig | 2 +-
configs/j721s2_evm_a72_defconfig | 2 +-
configs/j784s4_evm_a72_defconfig | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 19670b0da3c1..3982e6a8b53e 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi; run distro_bootcmd"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 1b0358a642c2..32dc4366fa84 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -31,7 +31,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi; run distro_bootcmd"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index 884e2f5fe38b..75b1ce761c94 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -31,7 +31,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
boot_rprocs; if test ${boot_fit} -eq 1; then run get_fit_${boot}; run
get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi; run distro_bootcmd"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j784s4_evm_a72_defconfig b/configs/j784s4_evm_a72_defconfig
index 9c4bda4fac43..fd61c9f43123 100644
--- a/configs/j784s4_evm_a72_defconfig
+++ b/configs/j784s4_evm_a72_defconfig
@@ -34,7 +34,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
# CONFIG_USE_SPL_FIT_GENERATOR is not set
CONFIG_OF_BOARD_SETUP=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; if test
${boot_fit} -eq 1; then run get_fit_${boot}; run get_overlaystring; run
run_fit; else; run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern; setenv fdtfile ti/${name_fdt}; fi; run
distro_bootcmd"
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; if test
${boot_fit} -eq 1; then run get_fit_${boot}; run get_overlaystring; run
run_fit; else; run get_kern_${boot}; run get_fdt_${boot}; run
get_overlay_${boot}; run run_kern; fi; run distro_bootcmd"
CONFIG_FIT_SIGNATURE=y
CONFIG_RSA=y
CONFIG_LOGLEVEL=7
--
2.34.1
[tiU23.04 PATCH 3/4] configs: j7*: remove saved environments
Having saved environments usually causes inconsistencies while development workflow. The saved environments conflict with the default ones that uboot should be updating while development but that doesn't happen and the saved environments need to be reset during bootups to test the changes causing extra debugs. Remove the saved environments as a default. ( Uenv.txt can be used optionally as a replacement for saved environments ) Signed-off-by: Manorit Chawdhry --- configs/j7200_evm_a72_defconfig | 3 +-- configs/j721e_evm_a72_defconfig | 2 -- configs/j721s2_evm_a72_defconfig | 4 +--- configs/j784s4_evm_a72_defconfig | 3 +-- 4 files changed, 3 insertions(+), 9 deletions(-) diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig index 3982e6a8b53e..98dfbe6cac3a 100644 --- a/configs/j7200_evm_a72_defconfig +++ b/configs/j7200_evm_a72_defconfig @@ -89,8 +89,7 @@ CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y -CONFIG_ENV_OVERWRITE=y -CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_NOWHERE=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig index 32dc4366fa84..b3a855c6ba22 100644 --- a/configs/j721e_evm_a72_defconfig +++ b/configs/j721e_evm_a72_defconfig @@ -90,9 +90,7 @@ CONFIG_OF_LIST="k3-j721e-common-proc-board k3-j721e-sk" CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y -CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_NOWHERE=y -CONFIG_ENV_IS_IN_FAT=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_ENV_FAT_DEVICE_AND_PART="1:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig index 75b1ce761c94..4928f42af630 100644 --- a/configs/j721s2_evm_a72_defconfig +++ b/configs/j721s2_evm_a72_defconfig @@ -89,10 +89,8 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="k3-j721s2-common-proc-board k3-am68-sk-base-board" CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y -CONFIG_ENV_OVERWRITE=y -CONFIG_ENV_IS_IN_FAT=y +CONFIG_ENV_IS_NOWHERE=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y -CONFIG_ENV_FAT_DEVICE_AND_PART="1:1" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y diff --git a/configs/j784s4_evm_a72_defconfig b/configs/j784s4_evm_a72_defconfig index fd61c9f43123..2f87d8c1be5b 100644 --- a/configs/j784s4_evm_a72_defconfig +++ b/configs/j784s4_evm_a72_defconfig @@ -94,8 +94,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_OF_LIST="k3-j784s4-evm" CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y -CONFIG_ENV_OVERWRITE=y -CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_IS_NOWHERE=y CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y -- 2.34.1
[tiU23.04 PATCH 0/4] HS booting cleanup
Test results http://lcpdresults.itg.ti.com/launcher/results/14057 Cc: u-boot@lists.denx.de To: Hari Nagalla To: Vignesh Raghavendra To: Bryan Brattlof Cc: Udit Kumar Cc: Praneeth Bajjuri Cc: Neha Malcom Francis Signed-off-by: Manorit Chawdhry --- Manorit Chawdhry (4): configs: remove explicit not set of setexpr configs: keep the bootcmd consistent across jacinto configs: j7*: remove saved environments configs: enable signed fit booting across all k3 socs boot/Kconfig | 3 +-- configs/am62ax_evm_a53_defconfig | 2 ++ configs/am62x_evm_a53_defconfig | 2 ++ configs/am64x_evm_a53_defconfig | 2 ++ configs/j7200_evm_a72_defconfig | 8 configs/j721e_evm_a72_defconfig | 7 +++ configs/j721s2_evm_a72_defconfig | 9 - configs/j784s4_evm_a72_defconfig | 5 ++--- 8 files changed, 20 insertions(+), 18 deletions(-) --- base-commit: c22f1ee591f84ab28c025d7aed9ee10c7f0154c1 change-id: 20230515-b4-internal-setexpr-fix-1876f8cff5e4 Best regards, -- Manorit Chawdhry
