Re: [PATCH v1 2/5] tee: sandbox: fix spelling errors
On 2/14/24 7:34 PM, Igor Opaniuk wrote: Fix spelling errors in comments. Signed-off-by: Igor Opaniuk Reviewed-by: Heinrich Schuchardt --- drivers/tee/sandbox.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c index 86219a9bb1a..ec66401878c 100644 --- a/drivers/tee/sandbox.c +++ b/drivers/tee/sandbox.c @@ -14,7 +14,7 @@ #include "optee/optee_private.h" /* - * The sandbox tee driver tries to emulate a generic Trusted Exectution + * The sandbox tee driver tries to emulate a generic Trusted Execution * Environment (TEE) with the Trusted Applications (TA) OPTEE_TA_AVB and * OPTEE_TA_RPC_TEST available. */ @@ -23,7 +23,7 @@ static const u32 pstorage_max = 16; /** * struct ta_entry - TA entries * @uuid: UUID of an emulated TA - * @open_session Called when a session is openened to the TA + * @open_session Called when a session is opened to the TA * @invoke_func Called when a function in the TA is to be invoked * * This struct is used to register TAs in this sandbox emulation of a TEE. @@ -140,8 +140,8 @@ static u32 pta_scp03_invoke_func(struct udevice *dev, u32 func, uint num_params, provisioned = true; /* -* Either way, we asume both operations succeeded and that -* the communication channel has now been stablished +* Either way, we assume both operations succeeded and that +* the communication channel has now been established */ return TEE_SUCCESS;
Re: [PATCH v1 1/5] tee: optee: fix description in Kconfig
On 2/14/24 7:34 PM, Igor Opaniuk wrote: Fix OPTEE_TA_AVB symbol description in Kconfig: s/"write"rb"/"write_rb"/g Signed-off-by: Igor Opaniuk The change is consistent with cmd/avb.c:424: U_BOOT_CMD_MKENT(write_rb, 3, 0, do_avb_write_rb, "", ""), Reviewed-by: Heinrich Schuchardt --- drivers/tee/optee/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index 9dc65b0501e..db0bcfa6f15 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -19,7 +19,7 @@ config OPTEE_TA_AVB default y help Enables support for the AVB Trusted Application (TA) in OP-TEE. - The TA can support the "avb" subcommands "read_rb", "write"rb" + The TA can support the "avb" subcommands "read_rb", "write_rb" and "is_unlocked". config OPTEE_TA_RPC_TEST
[PATCH 1/1] efi_loader: set IMAGE_DLLCHARACTERISTICS_NX_COMPAT
The IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag marks an EFI binary where the following conditions are met [1]: * Executable and writable sections are separated. * The application does not run self-modifying code. * The application uses the EFI_MEMORY_ATTRIBUTE_PROTOCOL when loading executable code. * The application does not assume that all memory ranges are usable. * The stack is not expected to be executable. The only EFI binaries U-Boot provides that do not fulfill these requirements are the EFI app and the EFI payload. Once we have implemented separation of writable and executable memory in U-Boot we can use the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag to decide if we will load an EFI binary. [1] New UEFI CA memory mitigation requirements for signing https://techcommunity.microsoft.com/t5/hardware-dev-center/new-uefi-ca-memory-mitigation-requirements-for-signing/ba-p/3608714 Signed-off-by: Heinrich Schuchardt --- The separation of executable and writable sections for armv7 EFI binaries is provided by [PATCH 1/1] arm: separate .data and .text sections of EFI binaries https://lore.kernel.org/u-boot/20240214190625.13764-1-heinrich.schucha...@canonical.com/T/#u --- arch/arm/lib/crt0_aarch64_efi.S | 4 arch/arm/lib/crt0_arm_efi.S | 4 arch/riscv/lib/crt0_riscv_efi.S | 4 include/asm-generic/pe.h| 3 +++ 4 files changed, 15 insertions(+) diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S index 3c2cef6ec7..fe6eca576e 100644 --- a/arch/arm/lib/crt0_aarch64_efi.S +++ b/arch/arm/lib/crt0_aarch64_efi.S @@ -66,7 +66,11 @@ extra_header_fields: .long _start - ImageBase /* SizeOfHeaders */ .long 0 /* CheckSum */ .short IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */ +#if CONFIG_VENDOR_EFI .short 0 /* DllCharacteristics */ +#else + .short IMAGE_DLLCHARACTERISTICS_NX_COMPAT +#endif .quad 0 /* SizeOfStackReserve */ .quad 0 /* SizeOfStackCommit */ .quad 0 /* SizeOfHeapReserve */ diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S index ba9fada500..afeff3f3fb 100644 --- a/arch/arm/lib/crt0_arm_efi.S +++ b/arch/arm/lib/crt0_arm_efi.S @@ -65,7 +65,11 @@ extra_header_fields: .long _start - image_base /* SizeOfHeaders */ .long 0 /* CheckSum */ .short IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */ +#if CONFIG_VENDOR_EFI .short 0 /* DllCharacteristics */ +#else + .short IMAGE_DLLCHARACTERISTICS_NX_COMPAT +#endif .long 0 /* SizeOfStackReserve */ .long 0 /* SizeOfStackCommit */ .long 0 /* SizeOfHeapReserve */ diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S index 46b0855237..c7a4559eac 100644 --- a/arch/riscv/lib/crt0_riscv_efi.S +++ b/arch/riscv/lib/crt0_riscv_efi.S @@ -96,7 +96,11 @@ extra_header_fields: .long _start - ImageBase /* SizeOfHeaders */ .long 0 /* CheckSum */ .short IMAGE_SUBSYSTEM_EFI_APPLICATION /* Subsystem */ +#if CONFIG_VENDOR_EFI .short 0 /* DllCharacteristics */ +#else + .short IMAGE_DLLCHARACTERISTICS_NX_COMPAT +#endif #if __riscv_xlen == 32 .long 0 /* SizeOfStackReserve */ .long 0 /* SizeOfStackCommit */ diff --git a/include/asm-generic/pe.h b/include/asm-generic/pe.h index b9d674b6da..cd5b6ad62b 100644 --- a/include/asm-generic/pe.h +++ b/include/asm-generic/pe.h @@ -51,6 +51,9 @@ #define IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER 12 #define IMAGE_SUBSYSTEM_EFI_ROM13 +/* DLL characteristics */ +#define IMAGE_DLLCHARACTERISTICS_NX_COMPAT 0x100 + /* Section flags */ #define IMAGE_SCN_CNT_CODE 0x0020 #define IMAGE_SCN_CNT_INITIALIZED_DATA 0x0040 -- 2.43.0
[PATCH v1] pci-host-ecam-generic: Convert to ofnode functions
FDT functions is not working when OF_LIVE is enabled.
Convert fdt parsing functions to ofnode parsing functions
Signed-off-by: Maksim Kiselev
---
drivers/pci/pcie_ecam_generic.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pcie_ecam_generic.c b/drivers/pci/pcie_ecam_generic.c
index 2e089b0e03..f5bc6e3d92 100644
--- a/drivers/pci/pcie_ecam_generic.c
+++ b/drivers/pci/pcie_ecam_generic.c
@@ -10,7 +10,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -133,18 +133,17 @@ static int pci_generic_ecam_write_config(struct udevice
*bus, pci_dev_t bdf,
static int pci_generic_ecam_of_to_plat(struct udevice *dev)
{
struct generic_ecam_pcie *pcie = dev_get_priv(dev);
- struct fdt_resource reg_res;
- DECLARE_GLOBAL_DATA_PTR;
+ ofnode node = dev_ofnode(dev);
+ struct resource reg_res;
int err;
- err = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev), "reg",
- 0, _res);
+ err = ofnode_read_resource(node, 0, _res);
if (err < 0) {
pr_err("\"reg\" resource not found\n");
return err;
}
- pcie->size = fdt_resource_size(_res);
+ pcie->size = resource_size(_res);
pcie->cfg_base = map_physmem(reg_res.start, pcie->size, MAP_NOCACHE);
return 0;
--
2.40.1
Re: [PATCH v5 08/11] doc: devicetree: Updates for devicetree-rebasing subtree
On Wed, 2024-02-14 at 19:02 +0530, Sumit Garg wrote: > > > > > Also, is devicetree-rebasing a "forked copy"? A fork would imply some > > difference from upstream. I would guess this is more like a mirror. > > AFAIK, it's a mirror from upstream with a different directory > (Makefile) structure. Ian may clarify further as to how this mirror is > kept updated. It's not really a mirror nor a fork, I guess it is something in between. It's a rewritten tree which extracts the DTS bits only from the kernel source into a standalone source repo. It's produced using "git filter- branch", all the scripting to do so is at: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/scripts The conversion state is part of https://github.com/ijc/devicetree-conversion-state-v3/, that repo contains all of upstream Linux commits too, since the branches there track the most recently converted inputs to support incremental updates. There's also the filter-map branch which maintains the state needed to not have to redo the conversion every time (which from scratch took days last time...) Ian
Re: [PATCH v5 08/11] doc: devicetree: Updates for devicetree-rebasing subtree
+ Ian Campbell (Maintainer for devicetree-rebasing tree) Hi Paul, Thanks for your nice documentation review. On Wed, 14 Feb 2024 at 03:01, Paul Barker wrote: > > On 02/02/2024 13:05, Sumit Garg wrote: > > Encourage SoC/board maintainers to migrate to using devicetree-rebasing > > subtree and maintain a regular sync with Linux kernel devicetree files > > and bindings. > > > > Along with that add documentation regarding how to run DT bindings > > schema checks. > > > > Signed-off-by: Sumit Garg > > --- > > > > Changes in v5: > > - Document how to cherry-pick fixes from devicetree-rebasing tree. > > > > Changes in v4: > > - Switched subtree to be imported as dts/upstream sub-directory rather > > than devicetree-rebasing sub-directory to better suite U-Boot > > directory structure. > > - Since we now have v6.7-dts tag available now, so switch subtree to > > that from its beginning. > > - Clarify subtree uprev schedule as a separate documentation section. > > Also, fixed documentation typos. > > > > Changes in v3: > > - Replace CONFIG_* with Kconfig options > > > > Changes in v2: > > - s/U-boot/U-Boot/ > > > > doc/develop/devicetree/control.rst | 117 - > > 1 file changed, 97 insertions(+), 20 deletions(-) > > > > diff --git a/doc/develop/devicetree/control.rst > > b/doc/develop/devicetree/control.rst > > index 9a0cb90336df..4440d4b82c6a 100644 > > --- a/doc/develop/devicetree/control.rst > > +++ b/doc/develop/devicetree/control.rst > > @@ -1,5 +1,6 @@ > > .. SPDX-License-Identifier: GPL-2.0+ > > .. sectionauthor:: Copyright 2011 The Chromium OS Authors > > +.. Copyright 2023-2024 Linaro Ltd. > > > > Devicetree Control in U-Boot > > > > @@ -22,12 +23,11 @@ for three reasons: > >hierarchical format > > - It is fairly efficient to read incrementally > > > > -The arch//dts directories contains a Makefile for building the > > devicetree > > -blob and embedding it in the U-Boot image. This is useful since it allows > > -U-Boot to configure itself according to what it finds there. If you have > > -a number of similar boards with different peripherals, you can describe > > -the features of each board in the devicetree file, and have a single > > -generic source base. > > +The U-Boot Makefile infrastructure allows for building the devicetree blob > > +and embedding it in the U-Boot image. This is useful since it allows U-Boot > > +to configure itself according to what it finds there. If you have a number > > +of similar boards with different peripherals, you can describe the features > > +of each board in the devicetree file, and have a single generic source > > base. > > > > To enable this feature, select `OF_CONTROL` via Kconfig. > > > > @@ -68,8 +68,14 @@ a binary file. U-Boot adds its own `fdtgrep` for > > creating subsets of the file. > > Where do I get a devicetree file for my board? > > -- > > > > -You may find that the Linux kernel has a suitable file. Look in the > > -kernel source in arch//boot/dts. > > +Linux kernel Git repository has been the place where devicetree files along > > +with devicetree bindings are stored and maintained. There is > > devicetee-rebasing > > +(dtrepo_) which maintains a forked copy of devicetree files along with > > bindings > > +at every Linux kernel major release or intermediate release candidates. > > This can be written more clearly, we can steal what you wrote later and > expand it to say what was wrong with the previous situation: > > "The devicetree files and devicetree bindings are maintained as part of > the Linux kernel git repository. Traditionally, U-Boot placed copies of > devicetree source files from the Linux kernel into > `arch//dts/.dts`. However, this required each board > maintainer to manually keep their device tree in sync with Linux and > often led to divergence between these copies." > > We can then introduce the `dts/upstream` directory and tell developers > why it is a better solution. Ack, I will try to reorganize the contents as per your suggestion. > > I think the docs should talk about the `dts/upstream` directory first, > then the devicetree-rebasing repository afterwards. The directory in the > u-boot source tree is what most developers will see and interact with, > use of the devicetree-rebasing repository is an implementation detail of > how that subtree is sync'd with Linux. I don't think we need to mention > the devicetree-rebasing repository until the "Resyncing with > devicetree-rebasing" section below. Ack. > > Also, is devicetree-rebasing a "forked copy"? A fork would imply some > difference from upstream. I would guess this is more like a mirror. AFAIK, it's a mirror from upstream with a different directory (Makefile) structure. Ian may clarify further as to how this mirror is kept updated. > > > + > > +U-Boot maintains a Git subtree for devicetee-rebasing repo as > > `dts/upstream/` > > +sub-directory.
[PATCH 1/1] arm: separate .data and .text sections of EFI binaries
EFI binaries should not contain sections that are both writable and
executable. Separate the RX .text section from the RW .data section.
Signed-off-by: Heinrich Schuchardt
---
arch/arm/lib/crt0_arm_efi.S | 35 +++
arch/arm/lib/elf_arm_efi.lds | 33 ++---
2 files changed, 49 insertions(+), 19 deletions(-)
diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S
index f6deca9a14..ba9fada500 100644
--- a/arch/arm/lib/crt0_arm_efi.S
+++ b/arch/arm/lib/crt0_arm_efi.S
@@ -23,7 +23,7 @@ pe_header:
.long IMAGE_NT_SIGNATURE /* 'PE' */
coff_header:
.short IMAGE_FILE_MACHINE_THUMB/* Mixed ARM/Thumb */
- .short 2 /* nr_sections */
+ .short 3 /* nr_sections */
.long 0 /* TimeDateStamp */
.long 0 /* PointerToSymbolTable */
.long 0 /* NumberOfSymbols */
@@ -107,16 +107,35 @@ section_table:
.byte 0
.byte 0
.byte 0 /* end of 0 padding of section name */
- .long _edata - _start /* VirtualSize */
+ .long _etext - _start /* VirtualSize */
.long _start - image_base /* VirtualAddress */
- .long _edata - _start /* SizeOfRawData */
+ .long _etext - _start /* SizeOfRawData */
.long _start - image_base /* PointerToRawData */
+ .long 0 /* PointerToRelocations */
+ .long 0 /* PointerToLineNumbers */
+ .short 0 /* NumberOfRelocations */
+ .short 0 /* NumberOfLineNumbers */
+ /* Characteristics (section flags) */
+ .long (IMAGE_SCN_MEM_READ | \
+IMAGE_SCN_MEM_EXECUTE | \
+IMAGE_SCN_CNT_CODE)
- .long 0 /* PointerToRelocations (0 for executables) */
- .long 0 /* PointerToLineNumbers (0 for executables) */
- .short 0 /* NumberOfRelocations (0 for executables) */
- .short 0 /* NumberOfLineNumbers (0 for executables) */
- .long 0xe0500020 /* Characteristics (section flags) */
+ .ascii ".data"
+ .byte 0
+ .byte 0
+ .byte 0 /* end of 0 padding of section name */
+ .long _data_size /* VirtualSize */
+ .long _data - image_base /* VirtualAddress */
+ .long _data_size /* SizeOfRawData */
+ .long _data - image_base /* PointerToRawData */
+ .long 0 /* PointerToRelocations */
+ .long 0 /* PointerToLineNumbers */
+ .short 0 /* NumberOfRelocations */
+ .short 0 /* NumberOfLineNumbers */
+ /* Characteristics (section flags) */
+ .long (IMAGE_SCN_MEM_WRITE | \
+IMAGE_SCN_MEM_READ | \
+IMAGE_SCN_CNT_INITIALIZED_DATA)
.align 12
_start:
diff --git a/arch/arm/lib/elf_arm_efi.lds b/arch/arm/lib/elf_arm_efi.lds
index 767ebda635..75341df5dd 100644
--- a/arch/arm/lib/elf_arm_efi.lds
+++ b/arch/arm/lib/elf_arm_efi.lds
@@ -7,6 +7,12 @@
OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
+
+PHDRS
+{
+ data PT_LOAD FLAGS(3); /* SHF_WRITE | SHF_ALLOC */
+}
+
ENTRY(_start)
SECTIONS
{
@@ -18,11 +24,17 @@ SECTIONS
*(.gnu.linkonce.t.*)
*(.srodata)
*(.rodata*)
+ . = ALIGN(16);
+ *(.dynamic);
. = ALIGN(512);
}
+ .rela.dyn : { *(.rela.dyn) }
+ .rela.plt : { *(.rela.plt) }
+ .rela.got : { *(.rela.got) }
+ .rela.data : { *(.rela.data) *(.rela.data*) }
_etext = .;
_text_size = . - _text;
- .dynamic : { *(.dynamic) }
+ . = ALIGN(4096);
.data : {
_data = .;
*(.sdata)
@@ -47,20 +59,19 @@ SECTIONS
. = ALIGN(512);
_bss_end = .;
_edata = .;
- }
- .rel.dyn : { *(.rel.dyn) }
- .rel.plt : { *(.rel.plt) }
- .rel.got : { *(.rel.got) }
- .rel.data : { *(.rel.data) *(.rel.data*) }
- _data_size = . - _etext;
+ } :data
+ _data_size = _edata - _data;
+ . = ALIGN(4096);
+ .dynsym : { *(.dynsym) }
+ . = ALIGN(4096);
+ .dynstr : { *(.dynstr) }
+ . = ALIGN(4096);
+ .note.gnu.build-id : { *(.note.gnu.build-id) }
/DISCARD/ : {
*(.rel.reloc)
*(.eh_frame)
*(.note.GNU-stack)
- *(.dynsym)
- *(.dynstr)
-
[PATCH v1 5/5] tee: remove common.h inclusion
The usage of the common.h include file is deprecated [1], and has already been removed from several files. Get rid of all inclusions in the "drivers/tee" directory, and replace it with required include files directly where needed. [1] doc/develop/codingstyle.rst Signed-off-by: Igor Opaniuk --- drivers/tee/broadcom/chimp_optee.c | 2 +- drivers/tee/optee/core.c | 1 - drivers/tee/optee/i2c.c| 1 - drivers/tee/optee/rpmb.c | 1 - drivers/tee/optee/supplicant.c | 2 +- drivers/tee/sandbox.c | 2 +- drivers/tee/tee-uclass.c | 1 - 7 files changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/tee/broadcom/chimp_optee.c b/drivers/tee/broadcom/chimp_optee.c index 37f9b094f76..c142ebd542f 100644 --- a/drivers/tee/broadcom/chimp_optee.c +++ b/drivers/tee/broadcom/chimp_optee.c @@ -3,9 +3,9 @@ * Copyright 2020 Broadcom. */ -#include #include #include +#include #ifdef CONFIG_CHIMP_OPTEE diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c index 47f845cffe3..5fc0505c788 100644 --- a/drivers/tee/optee/core.c +++ b/drivers/tee/optee/core.c @@ -3,7 +3,6 @@ * Copyright (c) 2018-2020 Linaro Limited */ -#include #include #include #include diff --git a/drivers/tee/optee/i2c.c b/drivers/tee/optee/i2c.c index ef4e10f9912..e3fb99897c5 100644 --- a/drivers/tee/optee/i2c.c +++ b/drivers/tee/optee/i2c.c @@ -3,7 +3,6 @@ * Copyright (c) 2020 Foundries.io Ltd */ -#include #include #include #include diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c index 5bc13757ea8..bacced6af6c 100644 --- a/drivers/tee/optee/rpmb.c +++ b/drivers/tee/optee/rpmb.c @@ -3,7 +3,6 @@ * Copyright (c) 2018 Linaro Limited */ -#include #include #include #include diff --git a/drivers/tee/optee/supplicant.c b/drivers/tee/optee/supplicant.c index f9dd874b594..8a426f53ba8 100644 --- a/drivers/tee/optee/supplicant.c +++ b/drivers/tee/optee/supplicant.c @@ -3,10 +3,10 @@ * Copyright (c) 2018, Linaro Limited */ -#include #include #include #include +#include #include #include "optee_msg.h" diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c index ec66401878c..8ad7c09efdd 100644 --- a/drivers/tee/sandbox.c +++ b/drivers/tee/sandbox.c @@ -2,7 +2,7 @@ /* * Copyright (C) 2018 Linaro Limited */ -#include + #include #include #include diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c index 52412a4098e..0194d732193 100644 --- a/drivers/tee/tee-uclass.c +++ b/drivers/tee/tee-uclass.c @@ -5,7 +5,6 @@ #define LOG_CATEGORY UCLASS_TEE -#include #include #include #include -- 2.34.1
[PATCH v1 4/5] test: py: add optee_rpmb tests
Add read/write tests for optee_rpmb cmd.
Signed-off-by: Igor Opaniuk
---
test/py/tests/test_optee_rpmb.py | 20
1 file changed, 20 insertions(+)
create mode 100644 test/py/tests/test_optee_rpmb.py
diff --git a/test/py/tests/test_optee_rpmb.py b/test/py/tests/test_optee_rpmb.py
new file mode 100644
index 000..8a081b5c494
--- /dev/null
+++ b/test/py/tests/test_optee_rpmb.py
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Tests for OP-TEE RPMB read/write support
+
+"""
+This tests optee_rpmb cmd in U-Boot
+"""
+
+import pytest
+import u_boot_utils as util
+
+@pytest.mark.buildconfigspec('cmd_optee_rpmb')
+def test_optee_rpmb_read_write(u_boot_console):
+"""Test OP-TEE RPMB cmd read/write
+"""
+response = u_boot_console.run_command('optee_rpmb write_pvalue
test_variable test_value')
+assert response == 'Wrote 11 bytes'
+
+response = u_boot_console.run_command('optee_rpmb read_pvalue
test_variable 11')
+assert response == 'Read 11 bytes, value = test_value'
\ No newline at end of file
--
2.34.1
[PATCH v1 2/5] tee: sandbox: fix spelling errors
Fix spelling errors in comments. Signed-off-by: Igor Opaniuk --- drivers/tee/sandbox.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c index 86219a9bb1a..ec66401878c 100644 --- a/drivers/tee/sandbox.c +++ b/drivers/tee/sandbox.c @@ -14,7 +14,7 @@ #include "optee/optee_private.h" /* - * The sandbox tee driver tries to emulate a generic Trusted Exectution + * The sandbox tee driver tries to emulate a generic Trusted Execution * Environment (TEE) with the Trusted Applications (TA) OPTEE_TA_AVB and * OPTEE_TA_RPC_TEST available. */ @@ -23,7 +23,7 @@ static const u32 pstorage_max = 16; /** * struct ta_entry - TA entries * @uuid: UUID of an emulated TA - * @open_session Called when a session is openened to the TA + * @open_session Called when a session is opened to the TA * @invoke_funcCalled when a function in the TA is to be invoked * * This struct is used to register TAs in this sandbox emulation of a TEE. @@ -140,8 +140,8 @@ static u32 pta_scp03_invoke_func(struct udevice *dev, u32 func, uint num_params, provisioned = true; /* -* Either way, we asume both operations succeeded and that -* the communication channel has now been stablished +* Either way, we assume both operations succeeded and that +* the communication channel has now been established */ return TEE_SUCCESS; -- 2.34.1
[PATCH v1 1/5] tee: optee: fix description in Kconfig
Fix OPTEE_TA_AVB symbol description in Kconfig: s/"write"rb"/"write_rb"/g Signed-off-by: Igor Opaniuk --- drivers/tee/optee/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig index 9dc65b0501e..db0bcfa6f15 100644 --- a/drivers/tee/optee/Kconfig +++ b/drivers/tee/optee/Kconfig @@ -19,7 +19,7 @@ config OPTEE_TA_AVB default y help Enables support for the AVB Trusted Application (TA) in OP-TEE. - The TA can support the "avb" subcommands "read_rb", "write"rb" + The TA can support the "avb" subcommands "read_rb", "write_rb" and "is_unlocked". config OPTEE_TA_RPC_TEST -- 2.34.1
[PATCH v1 3/5] cmd: optee_rpmb: build cmd for sandbox
Support CMD_OPTEE_RPMB for SANDBOX configurations. Test: $ ./u-boot -d arch/sandbox/dts/test.dtb ... => optee_rpmb write_pvalue test_variable test_value Wrote 11 bytes => optee_rpmb read_pvalue test_variable 11 Read 11 bytes, value = test_value Signed-off-by: Igor Opaniuk --- cmd/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/cmd/Kconfig b/cmd/Kconfig index a86b5705174..8ad8c0c542c 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -1370,7 +1370,9 @@ config CMD_CLONE config CMD_OPTEE_RPMB bool "Enable read/write support on RPMB via OPTEE" - depends on SUPPORT_EMMC_RPMB && OPTEE + depends on (SUPPORT_EMMC_RPMB && OPTEE) || SANDBOX_TEE + default y if SANDBOX_TEE + select OPTEE_TA_AVB if SANDBOX_TEE help Enable the commands for reading, writing persistent named values in the Replay Protection Memory Block partition in eMMC by -- 2.34.1
[PATCH v1 0/5] TEE: minor cleanup
- Address some spelling errors and typos - Support CMD_OPTEE_RPMB for SANDBOX configurations and add python tests - Remove common.h inclusion for drivers/tee Igor Opaniuk (5): tee: optee: fix description in Kconfig tee: sandbox: fix spelling errors cmd: optee_rpmb: build cmd for sandbox test: py: add optee_rpmb tests tee: remove common.h inclusion cmd/Kconfig| 4 +++- drivers/tee/broadcom/chimp_optee.c | 2 +- drivers/tee/optee/Kconfig | 2 +- drivers/tee/optee/core.c | 1 - drivers/tee/optee/i2c.c| 1 - drivers/tee/optee/rpmb.c | 1 - drivers/tee/optee/supplicant.c | 2 +- drivers/tee/sandbox.c | 10 +- drivers/tee/tee-uclass.c | 1 - test/py/tests/test_optee_rpmb.py | 20 10 files changed, 31 insertions(+), 13 deletions(-) create mode 100644 test/py/tests/test_optee_rpmb.py -- 2.34.1
Re: [PATCH] button: qcom-pmic: fix some error checking
On Wed, 31 Jan 2024 10:09:15 +0300, Dan Carpenter wrote: > The pmic_reg_read() function can return errors. Add a check for that. > > Applied, thanks! [1/1] button: qcom-pmic: fix some error checking commit: 6b929e9f3c16bbddeffb85351e93db13eaa9b57d Best regards, -- // Caleb (they/them)
[PATCH] test: dm: add button_cmd test
Add a test for the button_cmd feature. This validates that commands can
be mapped to two buttons, that the correct command runs based on which
button is pressed, that only 1 command is run, and that no command runs
if button_cmd_0_name is wrong or unset.
CONFIG_BUTTON is now enabled automatically and was removed when running
save_defconfig.
Signed-off-by: Caleb Connolly
---
configs/sandbox_defconfig | 2 +-
test/dm/button.c | 96 +++
2 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index a8df5e635b26..93b52f2de5cf 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -10,6 +10,7 @@ CONFIG_PCI=y
CONFIG_DEBUG_UART=y
CONFIG_SYS_MEMTEST_START=0x0010
CONFIG_SYS_MEMTEST_END=0x00101000
+CONFIG_BUTTON_CMD=y
CONFIG_FIT=y
CONFIG_FIT_RSASSA_PSS=y
CONFIG_FIT_CIPHER=y
@@ -166,7 +167,6 @@ CONFIG_DM_BOOTCOUNT=y
CONFIG_DM_BOOTCOUNT_RTC=y
CONFIG_DM_BOOTCOUNT_I2C_EEPROM=y
CONFIG_DM_BOOTCOUNT_SYSCON=y
-CONFIG_BUTTON=y
CONFIG_BUTTON_ADC=y
CONFIG_BUTTON_GPIO=y
CONFIG_CLK=y
diff --git a/test/dm/button.c b/test/dm/button.c
index 3318668df25a..830d96fbef34 100644
--- a/test/dm/button.c
+++ b/test/dm/button.c
@@ -131,3 +131,99 @@ static int dm_test_button_keys_adc(struct unit_test_state
*uts)
return 0;
}
DM_TEST(dm_test_button_keys_adc, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+/* Test of the button uclass using the button_gpio driver */
+static int dm_test_button_cmd(struct unit_test_state *uts)
+{
+ struct udevice *btn1_dev, *btn2_dev, *gpio;
+ const char *envstr;
+
+#define BTN1_GPIO 3
+#define BTN2_GPIO 4
+#define BTN1_PASS_VAR "test_button_cmds_0"
+#define BTN2_PASS_VAR "test_button_cmds_1"
+
+ /*
+* Buttons 1 and 2 are connected to gpio_a gpios 3 and 4 respectively.
+* set the GPIOs to known values and then check that the appropriate
+* commands are run when invoking process_button_cmds().
+*/
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 1, _dev));
+ ut_assertok(uclass_get_device(UCLASS_BUTTON, 2, _dev));
+ ut_assertok(uclass_get_device(UCLASS_GPIO, 1, ));
+
+ /*
+* Map a command to button 1 and check that it process_button_cmds()
+* runs it if called with button 1 pressed.
+*/
+ ut_assertok(env_set("button_cmd_0_name", "button1"));
+ ut_assertok(env_set("button_cmd_0", "env set " BTN1_PASS_VAR " PASS"));
+ ut_assertok(sandbox_gpio_set_value(gpio, BTN1_GPIO, 1));
+ /* Sanity check that the button is actually pressed */
+ ut_asserteq(BUTTON_ON, button_get_state(btn1_dev));
+ process_button_cmds();
+ ut_assertnonnull((envstr = env_get(BTN1_PASS_VAR)));
+ ut_asserteq_str(envstr, "PASS");
+
+ /* Clear result */
+ ut_assertok(env_set(BTN1_PASS_VAR, NULL));
+
+ /*
+* Map a command for button 2, press it, check that only the command
+* for button 1 runs because it comes first and is also pressed.
+*/
+ ut_assertok(env_set("button_cmd_1_name", "button2"));
+ ut_assertok(env_set("button_cmd_1", "env set " BTN2_PASS_VAR " PASS"));
+ ut_assertok(sandbox_gpio_set_value(gpio, BTN2_GPIO, 1));
+ ut_asserteq(BUTTON_ON, button_get_state(btn2_dev));
+ process_button_cmds();
+ /* Check that button 1 triggered again */
+ ut_assertnonnull((envstr = env_get(BTN1_PASS_VAR)));
+ ut_asserteq_str(envstr, "PASS");
+ /* And button 2 didn't */
+ ut_assertnull(env_get(BTN2_PASS_VAR));
+
+ /* Clear result */
+ ut_assertok(env_set(BTN1_PASS_VAR, NULL));
+
+ /*
+* Release button 1 and check that the command for button 2 is run
+*/
+ ut_assertok(sandbox_gpio_set_value(gpio, BTN1_GPIO, 0));
+ process_button_cmds();
+ ut_assertnull(env_get(BTN1_PASS_VAR));
+ /* Check that the command for button 2 ran */
+ ut_assertnonnull((envstr = env_get(BTN2_PASS_VAR)));
+ ut_asserteq_str(envstr, "PASS");
+
+ /* Clear result */
+ ut_assertok(env_set(BTN2_PASS_VAR, NULL));
+
+ /*
+* Unset "button_cmd_0_name" and check that no commands run even
+* with both buttons pressed.
+*/
+ ut_assertok(env_set("button_cmd_0_name", NULL));
+ /* Press button 1 (button 2 is already pressed )*/
+ ut_assertok(sandbox_gpio_set_value(gpio, BTN1_GPIO, 1));
+ ut_asserteq(BUTTON_ON, button_get_state(btn1_dev));
+ process_button_cmds();
+ ut_assertnull(env_get(BTN1_PASS_VAR));
+ ut_assertnull(env_get(BTN2_PASS_VAR));
+
+ /*
+* Check that no command is run if the button name is wrong.
+*/
+ ut_assertok(env_set("button_cmd_0_name", "invalid_button"));
+ process_button_cmds();
+ ut_assertnull(env_get(BTN1_PASS_VAR));
+ ut_assertnull(env_get(BTN2_PASS_VAR));
+
+#undef BTN1_PASS_VAR
+#undef
[PATCH 5/6] arm: mach-k3: am62a: Fixup TF-A/OP-TEE reserved-memory node in FDT
The address we load TFA and OP-TEE to is configurable by
CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory
are static. Fix that by updating this node when the loaded address
does not match the address in DT.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/Makefile | 1 +
arch/arm/mach-k3/am62a7_fdt.c | 16
arch/arm/mach-k3/am62ax/Kconfig | 1 +
3 files changed, 18 insertions(+)
create mode 100644 arch/arm/mach-k3/am62a7_fdt.c
diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 42161376469..fdb442773e3 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SOC_K3_AM654) += am654_fdt.o
obj-$(CONFIG_SOC_K3_J721E) += j721e_fdt.o
obj-$(CONFIG_SOC_K3_J721S2) += j721s2_fdt.o
obj-$(CONFIG_SOC_K3_AM625) += am625_fdt.o
+obj-$(CONFIG_SOC_K3_AM62A7) += am62a7_fdt.o
endif
ifeq ($(CONFIG_SPL_BUILD),y)
obj-$(CONFIG_SOC_K3_AM654) += am654_init.o
diff --git a/arch/arm/mach-k3/am62a7_fdt.c b/arch/arm/mach-k3/am62a7_fdt.c
new file mode 100644
index 000..d67f012a5dc
--- /dev/null
+++ b/arch/arm/mach-k3/am62a7_fdt.c
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include "common_fdt.h"
+#include
+
+int ft_system_setup(void *blob, struct bd_info *bd)
+{
+ fdt_fixup_reserved(blob, "tfa", CONFIG_K3_ATF_LOAD_ADDR, 0x8);
+ fdt_fixup_reserved(blob, "optee", CONFIG_K3_OPTEE_LOAD_ADDR, 0x180);
+
+ return 0;
+}
diff --git a/arch/arm/mach-k3/am62ax/Kconfig b/arch/arm/mach-k3/am62ax/Kconfig
index c5f1ef87126..bbd5497f2ae 100644
--- a/arch/arm/mach-k3/am62ax/Kconfig
+++ b/arch/arm/mach-k3/am62ax/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM62A7_A53_EVM
bool "TI K3 based AM62A7 EVM running on A53"
select ARM64
select BINMAN
+ select OF_SYSTEM_SETUP
imply BOARD
imply SPL_BOARD
imply TI_I2C_BOARD_DETECT
--
2.39.2
[PATCH 3/6] arm: mach-k3: am62: Enable OF_SYSTEM_SETUP for all boards
The fixups provided by ft_system_setup() are applicable for all AM62 based
boards. Select this at the target selection level for all AM62 boards and
remove it from any specific defconfig.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am62x/Kconfig| 3 +++
configs/verdin-am62_a53_defconfig | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-k3/am62x/Kconfig b/arch/arm/mach-k3/am62x/Kconfig
index 935d596c879..7c9bac2ece8 100644
--- a/arch/arm/mach-k3/am62x/Kconfig
+++ b/arch/arm/mach-k3/am62x/Kconfig
@@ -13,6 +13,7 @@ config TARGET_AM625_A53_EVM
bool "TI K3 based AM625 EVM running on A53"
select ARM64
select BINMAN
+ select OF_SYSTEM_SETUP
config TARGET_AM625_R5_EVM
bool "TI K3 based AM625 EVM running on R5"
@@ -29,6 +30,7 @@ config TARGET_PHYCORE_AM62X_A53
bool "PHYTEC phyCORE-AM62x running on A53"
select ARM64
select BINMAN
+ select OF_SYSTEM_SETUP
config TARGET_PHYCORE_AM62X_R5
bool "PHYTEC phyCORE-AM62x running on R5"
@@ -45,6 +47,7 @@ config TARGET_VERDIN_AM62_A53
bool "Toradex Verdin AM62 running on A53"
select ARM64
select BINMAN
+ select OF_SYSTEM_SETUP
config TARGET_VERDIN_AM62_R5
bool "Toradex Verdin AM62 running on R5"
diff --git a/configs/verdin-am62_a53_defconfig
b/configs/verdin-am62_a53_defconfig
index 2003a530c7d..902c437d734 100644
--- a/configs/verdin-am62_a53_defconfig
+++ b/configs/verdin-am62_a53_defconfig
@@ -37,7 +37,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
CONFIG_SYS_BOOTM_LEN=0x4000
CONFIG_DISTRO_DEFAULTS=y
CONFIG_BOOTDELAY=1
-CONFIG_OF_SYSTEM_SETUP=y
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="test -n ${fdtfile} || setenv fdtfile
k3-am625-verdin-${variant}-${fdt_board}.dtb"
CONFIG_LOG=y
--
2.39.2
[PATCH 6/6] arm: mach-k3: Move DRAM address of ATF for AM62/AM62a
The current address of TF-A in DRAM is just below the 512MB address line. This means if the DRAM in a system is 512MB then TF-A is right at the end of memory which is often reused, for instance U-Boot relocates itself here. If a system has less than 512MB then that system wouldn't work at all as TF-A would fail to load. To avoid the issues above, move TF-A to the start of DRAM, which doesn't change from system to system. As TF-A is position independent, this has no dependency on TF-A. We also fixup DT as needed when TF-A address is moved, so this change also has no dependency on Linux and is fully forward/backward compatible. Signed-off-by: Andrew Davis --- arch/arm/mach-k3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 55bb874d9aa..33f20f61f83 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -123,7 +123,7 @@ config SYS_K3_SPL_ATF config K3_ATF_LOAD_ADDR hex "Load address of ATF image" - default 0x9e78 if (SOC_K3_AM625 || SOC_K3_AM62A7) + default 0x8000 if (SOC_K3_AM625 || SOC_K3_AM62A7) default 0x7000 help The load address for the ATF image. This value is used to build the -- 2.39.2
[PATCH 1/6] arm: mach-k3: Add default ATF location for AM62/AM62a
There is a default ATF load address that is used for devices that have ATF running in SRAM. For AM62 and AM62a, ATF runs from DRAM. Instead of having to override the address in every defconfig, make add a default for these ATF in DRAM devices. Signed-off-by: Andrew Davis --- arch/arm/mach-k3/Kconfig | 5 +++-- configs/am62ax_evm_a53_defconfig | 1 - configs/am62x_beagleplay_a53_defconfig | 1 - configs/am62x_evm_a53_defconfig| 1 - configs/phycore_am62x_a53_defconfig| 1 - configs/verdin-am62_a53_defconfig | 1 - 6 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index 03898424c95..0bd3f9fa12d 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -123,10 +123,11 @@ config SYS_K3_SPL_ATF config K3_ATF_LOAD_ADDR hex "Load address of ATF image" + default 0x9e78 if (SOC_K3_AM625 || SOC_K3_AM62A7) default 0x7000 help - The load address for the ATF image. This value defaults to 0x7000 - if not provided in the board defconfig file. + The load address for the ATF image. This value is used to build the + FIT image header that places ATF in memory where it will run. config K3_DM_FW bool "Separate DM firmware image" diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig index 38083586a3e..03b2dea7d51 100644 --- a/configs/am62ax_evm_a53_defconfig +++ b/configs/am62ax_evm_a53_defconfig @@ -5,7 +5,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM62A7=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_AM62A7_A53_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048 diff --git a/configs/am62x_beagleplay_a53_defconfig b/configs/am62x_beagleplay_a53_defconfig index 0be20045a97..122c1ba9299 100644 --- a/configs/am62x_beagleplay_a53_defconfig +++ b/configs/am62x_beagleplay_a53_defconfig @@ -6,7 +6,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_AM625_A53_BEAGLEPLAY=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index 457931faf21..e29df6ec523 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -5,7 +5,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_AM625_A53_EVM=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index 2d5d906a9d7..5ba08440268 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -5,7 +5,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_PHYCORE_AM62X_A53=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 diff --git a/configs/verdin-am62_a53_defconfig b/configs/verdin-am62_a53_defconfig index 956e3a1ad75..2003a530c7d 100644 --- a/configs/verdin-am62_a53_defconfig +++ b/configs/verdin-am62_a53_defconfig @@ -8,7 +8,6 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 CONFIG_SOC_K3_AM625=y -CONFIG_K3_ATF_LOAD_ADDR=0x9e78 CONFIG_TARGET_VERDIN_AM62_A53=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80b8 -- 2.39.2
[PATCH 0/6] Move DRAM address of ATF
Hello all, Explanation for this series is mostly in [4/6]. First 3 patches should be safe to take independent of the last 3. Thanks, Andrew Andrew Davis (6): arm: mach-k3: Add default ATF location for AM62/AM62a arm: mach-k3: Add config option for setting OP-TEE address arm: mach-k3: am62: Enable OF_SYSTEM_SETUP for all boards arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT arm: mach-k3: am62a: Fixup TF-A/OP-TEE reserved-memory node in FDT arm: mach-k3: Move DRAM address of ATF for AM62/AM62a arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 4 +- arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 4 +- arch/arm/dts/k3-binman.dtsi | 8 +-- .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 4 +- arch/arm/mach-k3/Kconfig | 10 +++- arch/arm/mach-k3/Makefile | 1 + arch/arm/mach-k3/am625_fdt.c | 2 + arch/arm/mach-k3/am62a7_fdt.c | 16 ++ arch/arm/mach-k3/am62ax/Kconfig | 1 + arch/arm/mach-k3/am62x/Kconfig| 3 ++ arch/arm/mach-k3/common_fdt.c | 52 +++ arch/arm/mach-k3/common_fdt.h | 2 + configs/am62ax_evm_a53_defconfig | 1 - configs/am62x_beagleplay_a53_defconfig| 1 - configs/am62x_evm_a53_defconfig | 1 - configs/phycore_am62x_a53_defconfig | 1 - configs/verdin-am62_a53_defconfig | 2 - 17 files changed, 96 insertions(+), 17 deletions(-) create mode 100644 arch/arm/mach-k3/am62a7_fdt.c -- 2.39.2
[PATCH 4/6] arm: mach-k3: am62: Fixup TF-A/OP-TEE reserved-memory node in FDT
The address we load TF-A and OP-TEE to is configurable by Kconfig
CONFIG_K3_{ATF,OPTEE}_LOAD_ADDR, but the DT nodes reserving this memory
are often statically defined. As these binaries are dynamically loadable,
and in the case of OP-TEE may not even be loaded at all, hard-coding these
addresses is not a hardware description, but rather a configuration.
If the address that U-Boot loaded TF-A or OP-TEE does not match the
address in hard-coded in DT, then fix that node address. This also handles
the case when no reserved memory for these is provided by DT, which is
more correct as explained above.
Add this fixup function, and enable it for AM62.
Signed-off-by: Andrew Davis
---
arch/arm/mach-k3/am625_fdt.c | 2 ++
arch/arm/mach-k3/common_fdt.c | 52 +++
arch/arm/mach-k3/common_fdt.h | 2 ++
3 files changed, 56 insertions(+)
diff --git a/arch/arm/mach-k3/am625_fdt.c b/arch/arm/mach-k3/am625_fdt.c
index 970dd3447de..b26186456f3 100644
--- a/arch/arm/mach-k3/am625_fdt.c
+++ b/arch/arm/mach-k3/am625_fdt.c
@@ -43,6 +43,8 @@ int ft_system_setup(void *blob, struct bd_info *bd)
fdt_fixup_cores_nodes_am625(blob, k3_get_core_nr());
fdt_fixup_gpu_nodes_am625(blob, k3_has_gpu());
fdt_fixup_pru_node_am625(blob, k3_has_pru());
+ fdt_fixup_reserved(blob, "tfa", CONFIG_K3_ATF_LOAD_ADDR, 0x8);
+ fdt_fixup_reserved(blob, "optee", CONFIG_K3_OPTEE_LOAD_ADDR, 0x180);
return 0;
}
diff --git a/arch/arm/mach-k3/common_fdt.c b/arch/arm/mach-k3/common_fdt.c
index 645c4de42f7..3bdedd7b509 100644
--- a/arch/arm/mach-k3/common_fdt.c
+++ b/arch/arm/mach-k3/common_fdt.c
@@ -112,3 +112,55 @@ int fdt_del_node_path(void *blob, const char *path)
return ret;
}
+
+int fdt_fixup_reserved(void *blob, const char *name,
+ unsigned int new_address, unsigned int new_size)
+{
+ int nodeoffset, subnode;
+ int ret;
+
+ /* Find reserved-memory */
+ nodeoffset = fdt_subnode_offset(blob, 0, "reserved-memory");
+ if (nodeoffset < 0) {
+ debug("Could not find reserved-memory node\n");
+ return 0;
+ }
+
+ /* Find existing matching subnode and remove it */
+ fdt_for_each_subnode(subnode, blob, nodeoffset) {
+ const char *node_name;
+ fdt_addr_t addr;
+ fdt_size_t size;
+
+ /* Name matching */
+ node_name = fdt_get_name(blob, subnode, NULL);
+ if (!name)
+ return -EINVAL;
+ if (!strncmp(node_name, name, strlen(name))) {
+ /* Read out old size first */
+ addr = fdtdec_get_addr_size(blob, subnode, "reg",
);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+ new_size = size;
+
+ /* Delete node */
+ ret = fdt_del_node(blob, subnode);
+ if (ret < 0)
+ return ret;
+
+ /* Only one matching node */
+ break;
+ }
+ }
+
+ struct fdt_memory carveout = {
+ .start = new_address,
+ .end = new_address + new_size - 1,
+ };
+ ret = fdtdec_add_reserved_memory(blob, name, , NULL, 0, NULL,
+FDTDEC_RESERVED_MEMORY_NO_MAP);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
diff --git a/arch/arm/mach-k3/common_fdt.h b/arch/arm/mach-k3/common_fdt.h
index 4d23ae638ca..52c07957483 100644
--- a/arch/arm/mach-k3/common_fdt.h
+++ b/arch/arm/mach-k3/common_fdt.h
@@ -8,5 +8,7 @@
int fdt_fixup_msmc_ram_k3(void *blob);
int fdt_del_node_path(void *blob, const char *path);
+int fdt_fixup_reserved(void *blob, const char *name,
+ unsigned int new_address, unsigned int new_size);
#endif /* _COMMON_FDT_H */
--
2.39.2
[PATCH 2/6] arm: mach-k3: Add config option for setting OP-TEE address
Much like we have for ATF, OP-TEE has a standard address that we load
it too and run it from. Add a Kconfig item for this to remove some
hard-coding and allow this address to be more easily changed.
Signed-off-by: Andrew Davis
---
arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 4 ++--
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 4 ++--
arch/arm/dts/k3-binman.dtsi | 8
arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi | 4 ++--
arch/arm/mach-k3/Kconfig | 7 +++
5 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
index a723caa5805..cca0f44b7d8 100644
--- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
+++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
@@ -105,8 +105,8 @@
arch = "arm64";
compression = "none";
os = "tee";
- load = <0x9e80>;
- entry = <0x9e80>;
+ load = ;
+ entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 64318d09cf0..3a6db91e132 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -51,8 +51,8 @@
arch = "arm64";
compression = "none";
os = "tee";
- load = <0x9e80>;
- entry = <0x9e80>;
+ load = ;
+ entry = ;
tee-os {
};
};
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
index 758c8bf6ea1..621653e9471 100644
--- a/arch/arm/dts/k3-binman.dtsi
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -286,8 +286,8 @@
arch = "arm64";
compression = "none";
os = "tee";
- load = <0x9e80>;
- entry = <0x9e80>;
+ load = ;
+ entry = ;
ti-secure {
content = <>;
keyfile = "custMpk.pem";
@@ -356,8 +356,8 @@
arch = "arm64";
compression = "none";
os = "tee";
- load = <0x9e80>;
- entry = <0x9e80>;
+ load = ;
+ entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
index 017a5a722e0..ca99fa0e690 100644
--- a/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
+++ b/arch/arm/dts/k3-j721e-beagleboneai64-u-boot.dtsi
@@ -250,8 +250,8 @@
arch = "arm64";
compression = "none";
os = "tee";
- load = <0x9e80>;
- entry = <0x9e80>;
+ load = ;
+ entry = ;
tee-os {
filename = "tee-raw.bin";
};
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 0bd3f9fa12d..55bb874d9aa 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -129,6 +129,13 @@ config K3_ATF_LOAD_ADDR
The load address for the ATF image. This value is used to build the
FIT image header that places ATF in memory where it will run.
+config K3_OPTEE_LOAD_ADDR
+ hex "Load address of OPTEE image"
+ default 0x9e80
+ help
+ The load address for the OPTEE image. This value defaults to
0x9e80
+ if not provided in the board defconfig file.
[GIT PULL] xilinx patches for v2024.04-rc3
Hi Tom, please pull these patches to your branch. Most of them are related to device tree and aligning with the latest dt schema for SR certification. CI is not reporting any issue too. Thanks, Michal The following changes since commit e8f2404e093daf6cc3ac2b3233e3c6770d13e371: Merge branch 'master-779h0-r2' of https://source.denx.de/u-boot/custodians/u-boot-sh (2024-02-11 12:42:25 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2024.04-rc3 for you to fetch changes up to c2ad5fb616d4e8aa2ac00e224030589847731fbe: arm64: versal-net: Setup correct addresses of GICR/GICD (2024-02-14 11:23:43 +0100) Xilinx changes for v2024.04-rc3 zynqmp: - Cover missing _SE chip variants to fix fpga programming versal: - Enable LTO for mini configurations versal-net: - Enable LTO for mini configurations - Fix GIC address to aligned with real silicon xilinx: - DTs cleanup and fixups - Enable HTTP boot - Add missing spl header to zynqmp.c Michal Simek (10): arm64: xilinx: Enable EFI_HTTP_BOOT by default arm64: zynqmp: Sync clock labels with kr260 revB arm64: zynqmp: Describe 25MHz fixed clock for PL GEMs arm64: zynqmp: Fix kr260 clock wiring xilinx: Fix fpga region DT nodes name arm64: zynqmp: Remove arm,cortex-a53-edac node arm64: zynqmp: Align nvmem-fw node with dt-schema arm64: zynqmp: Do not expose usbhub nodes on kr260 usb1 arm64: zynqmp: Disable DP on kd240 arm64: versal-net: Setup correct addresses of GICR/GICD Saeed Nowshadi (1): arm64: zynqmp: Add 'silabs, skip-recall' to all si570 clk nodes Venkatesh Yadav Abbarapu (4): soc: zynqmp: Add the IDcode for dr_SE and eg_SE variants configs: versal: Enable CONFIG_LTO for mini qspi/ospi configs: versal_net: Enable CONFIG_LTO for mini qspi/ospi xilinx: zynqmp: Add the missing function prototype arch/arm/dts/zynq-7000.dtsi | 2 +- arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 5 + arch/arm/dts/zynqmp-sck-kd-g-revA.dtso| 16 +++ arch/arm/dts/zynqmp-sck-kr-g-revA.dtso| 25 ++-- arch/arm/dts/zynqmp-sck-kr-g-revB.dtso| 8 ++ arch/arm/dts/zynqmp.dtsi | 131 ++-- board/xilinx/zynqmp/zynqmp.c | 1 + configs/xilinx_versal_mini_ospi_defconfig | 1 + configs/xilinx_versal_mini_qspi_defconfig | 1 + configs/xilinx_versal_net_mini_ospi_defconfig | 1 + configs/xilinx_versal_net_mini_qspi_defconfig | 1 + configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynqmp_kria_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + drivers/soc/soc_xilinx_zynqmp.c | 28 - include/configs/xilinx_versal_net.h | 4 +- 17 files changed, 149 insertions(+), 79 deletions(-) -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH v2 1/2] board: rockchip: Add support for rk3588s based Cool Pi 4B
Hi Andy,
On 2/14/24 10:31, Andy Yan wrote:
[You don't often get email from andys...@163.com. Learn why this is important
at https://aka.ms/LearnAboutSenderIdentification ]
CoolPi 4B is a rk3588s based SBC.
Specification:
- Rockchip RK3588S
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- SPI Nor 8MB
- Gigabit ethernet drived by PCIE with RTL8111HS
- HDMI Type D out
- Mini DP out
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- WIFI/BT module AIC8800
- 40 pin header
The dts is from linux-6.8 rc1.
Signed-off-by: Andy Yan
Reviewed-by: Kever Yang
---
Changes in v2:
- sync dts from linux-rockchip which will be in linux-6.8 rc6[0]
[0]https://patchwork.kernel.org/project/linux-rockchip/patch/2450634.jE0xQCEvom@phil/
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi | 30 +
arch/arm/dts/rk3588s-coolpi-4b.dts | 812 +
board/rockchip/evb_rk3588/MAINTAINERS | 7 +
configs/coolpi-4b-rk3588s_defconfig| 105 +++
5 files changed, 955 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588s-coolpi-4b.dts
create mode 100644 configs/coolpi-4b-rk3588s_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ce10d3dbb0..ae7c088ceb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -190,6 +190,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-rock-3a.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
+ rk3588s-coolpi-4b.dts \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
diff --git a/arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
b/arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
new file mode 100644
index 00..6b69ff424f
--- /dev/null
+++ b/arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
This is already in rk3588s-u-boot.dtsi
+};
+
+_pins {
+ bootph-all;
+};
+
+ {
+ bootph-pre-ram;
+ u-boot,spl-sfc-no-dma;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ 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>;
+ };
+};
diff --git a/arch/arm/dts/rk3588s-coolpi-4b.dts
b/arch/arm/dts/rk3588s-coolpi-4b.dts
new file mode 100644
index 00..e037bf9db7
--- /dev/null
+++ b/arch/arm/dts/rk3588s-coolpi-4b.dts
@@ -0,0 +1,812 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ * https://cool-pi.com/topic/130/coolpi-4b-product-spec-introduction
+ *
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3588s.dtsi"
+
+/ {
+ model = "RK3588S CoolPi 4 Model B";
+ compatible = "coolpi,pi-4b", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
+ analog-sound {
+ compatible = "audio-graph-card";
+ dais = <_8ch_p0>;
+ label = "rk3588-es8316";
+ routing = "MIC2", "Mic Jack",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR";
+ widgets = "Microphone", "Mic Jack",
+ "Headphone", "Headphones";
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led0: led-green {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PD0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1: led-red {
+ color = ;
+ default-state = "off";
+ function = LED_FUNCTION_WLAN;
+ gpios = < RK_PC4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ /*
+* On the module itself this is one of these (depending
+* on the actual card populated):
+* - SDIO_RESET_L_WL_REG_ON
+* - PDN (power down when low)
+*/
+
How To Move Root Partition From eMMC to SSD
I am running the NanoPi R6C. The device is not capable of booting from the SSD, the next best thing is to load the root filesystem from the SSD. Using rockchip's repos, I compile from source the images to boot 1) from the microSD card and 2) from eMMC. I install to the eMMC. Then, so as not to mount any partitions from eMMC, I boot from the microSD card, and I clone the root partition from the eMMC (/dev/mmcblk2p8) to the SSD (/dev/nvme0n1p1). I boot from the eMMC, the output of "cat /proc/cmdline" is: storagemedia=emmc androidboot.storagemedia=emmc androidboot.mode=normal androidboot.dtbo_idx=0 androidboot.verifiedbootstate=orange earlycon=uart8250,mmio32,0xfeb5 console=ttyFIQ0 coherent_pool=1m irqchip.gicv3_pseudo_nmi=0 rw root=/dev/mmcblk2p8 rootfstype=ext4 rootflags=discard data=/dev/mmcblk2p9 consoleblank=0 cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 androidboot.fwver=uboot-a83a7263ef-01/09/2024 How do I change "root=/dev/mmcblk2p8" to "root=/dev/nvme0n1p1"? I connect to the serial port and get to the U-Boot monitor. I examine the variables. "bootcmd" runs "bootrkp" which boots the system. "bootrkp" ignores "bootargs", I confirm this by deleting "bootargs" before running "bootrkp", the system boots up as before with no change in behavior. "bootrkp" is implemented in file "cmd/bootrkp.c". That code emits the equivalent of: setenv bootm-no-reloc y booti 0x40 0xa20:0x7b2bc0 0x830 Can I tell U-Boot to load the root partition from /dev/nvme0n1p1, either by entering commands at the monitor, or by modifying the source code of U-Boot, or through any other means? Regards, Eric
Re: [PATCH] Added FDT PAD memory size while reserving memory for FDT to avoid some memory corruption issue
Hi, The issue is happening in the following scenario. 1) Launch the QEMU for RISCV virt platform with uboot and ubuntu OS (Host system). Now the OS is booted without any issue. 2) Enable the KVM in the ubuntu OS. 3) Create a VM by launching the same RISC V QEMU from the Ubuntu OS (Host system) after enabling KVM. 4) So now the qemu is running from the HOST OS and launching the uboot and then OS. The system crash is happening in the VM OS booting. If the FDT is reserved with stub bytes then the VM is launched properly. The issue is not happening while launching Host OS even if it use the same uboot code. As per the image_fdt code in uboot, the FDT size is blindly increased even if the relocation is disabled and updated in the FDT header. So i reserve the Padding bytes while reserving FDT in uboot board_f phase itself for adding bootargs in uboot after image_fdt. Regards, Selva On Sat, Feb 10, 2024 at 1:55 AM Tom Rini wrote: > On Fri, Feb 09, 2024 at 07:45:10PM +0530, Selvakumar Velandi wrote: > > > The FDT relocation is not disabled. I am adding the FDT PADDING bytes > while > > doing FDT reservation in the board_f file. > > Also update the FDT length based on the new allocation, instead of > blindly > > increasing the size. > > Currently the size is getting increased even for the relocation disabled > > scenario also. > > So without increasing the physical memory for the disable relocation use > > case, the fdt total size is updated. thus causing memory corruption > > Please explain on what system you're seeing this with, and how things > are configured and what else is required to trigger this problem. Your > changes to boot/image-fdt.c change things so that we don't pad the > non-relocated device tree (but we need to, we still change the bootargs > and so forth). And the changes to common/board_f.c look like we're > trying to do that instead, earlier? But we should not have a kernel > corruption problem unless: > - We aren't relocating the device tree > - We aren't relocating the device tree far enough away from the kernel, > but this shouldn't be a problem on arm64 and riscv where the Image > header structure tells us how big the BSS is to be and we obey that. > > -- > Tom > -- *** This communication is confidential, may be privileged and is meant only for the intended recipient and purpose. No part of this email or any files transmitted with it can be shared, copied, forwarded or published online or offline, without prior written consent of the sender. If you are not the intended recipient, please preserve the confidentiality, delete the e-mail and attachments, if any from your system and inform the sender immediately. ***
Re: [RFC PATCH v2 0/2] Introduce fastboot oem board command
Hello! Ping. On Thu, Feb 01, 2024 at 12:20:25PM +0300, Alexey Romanov wrote: > Changes v2 since v1 at [1]: > - Added an example of using the command as requsted > by Sean Anderson [2]. > > Links: > [1] > https://lore.kernel.org/all/20231228152522.83291-1-avroma...@salutedevices.com/ > [2] > https://lore.kernel.org/all/72ac233d-c18d-4f57-bc66-451fe0bd2...@seco.com/ > > Alexey Romanov (2): > fastboot: introduce 'oem board' subcommand > board: ad401: example of fastboot oem board realization > > board/amlogic/ad401/fastboot.c | 222 + > drivers/fastboot/Kconfig | 7 ++ > drivers/fastboot/fb_command.c | 15 +++ > include/fastboot.h | 1 + > 4 files changed, 245 insertions(+) > create mode 100644 board/amlogic/ad401/fastboot.c > > -- > 2.30.1 > -- Thank you, Alexey
Re: [PATCH v5 06/11] dts: Add script to uprev dts/upstream subtree
Hi Marek, On Tue, 6 Feb 2024 at 11:50, Sumit Garg wrote: > > Hi Marek, > > On Tue, 6 Feb 2024 at 05:51, Marek Vasut wrote: > > > > On 2/2/24 14:05, Sumit Garg wrote: > > > dts/update-dts-subtree.sh is just a wrapper around git subtree commands. > > > Usage from the top level U-Boot source tree, run: > > > > > > $ ./dts/update-dts-subtree.sh pull > > > $ ./dts/update-dts-subtree.sh pick > > > > > > Signed-off-by: Sumit Garg > > > > How are the fixes which land in linux-stable handled now ? > > Firstly, all the fixes land in the Linux mainline tree, then at every > rc* release those would be mirrored into devicetree-rebasing repo. And > then if there is a critical fix to address DT ABI breakage for U-Boot > (for at least a single board) then they just need to notify us with > the fix commit ID to be picked up. Or if people are willing to use the > dts/update-dts-subtree.sh script themselves then we are happy to > accept patches too. > > BTW, we will also work with Linux DT maintainers to improve DT ABI > maintenance towards U-Boot. > > > > > Do I have to duplicate the work which is already being done by the > > linux-stable maintainers ? > > No, we don't have to backport all the fixes as they will make their > way automatically via the next subtree pull. As above we are only > concerned about fixes which are required to maintain DT ABI towards > U-Boot. > Gentle ping. I hope my comments above address your concerns. -Sumit
Re: [PATCH v2 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board
On Tue, Feb 13, 2024 at 2:33 PM Frieder Schrempf wrote: > > From: Frieder Schrempf > > Describe how to build and boot for the Sielaff i.MX6 Solo board. > > Signed-off-by: Frieder Schrempf Reviewed-by: Fabio Estevam
Re: [PATCH v2 2/3] board: Add support for Sielaff i.MX6 Solo board
On Tue, Feb 13, 2024 at 2:22 PM Frieder Schrempf wrote: > > From: Frieder Schrempf > > The Sielaff i.MX6 Solo board is a control and HMI board for vending > machines. Add support for this board. > > The devicetree files are taken from pending changes in the Linux > kernel that are available from linux-next and will likely be > part of Linux v6.9. > > Signed-off-by: Frieder Schrempf Reviewed-by: Fabio Estevam
[PATCH 5/5] riscv: mbv: Enable SPL and binman
Enable SPL and binman to generate u-boot.img (machine mode) and u-boot.itb
(supervisor mode). DTB is placed at fixed address to ensure that it is 8
byte aligned which is not ensured when dtb is attached behind SPL binary
that's why SPL and U-Boot are taking DTB from the same address.
Also align addresses for both defconfigs.
Signed-off-by: Michal Simek
---
arch/riscv/dts/xilinx-mbv32.dts | 3 +++
board/xilinx/common/board.c | 8
board/xilinx/mbv/Kconfig | 11 +++
board/xilinx/mbv/board.c | 10 ++
configs/xilinx_mbv32_defconfig | 18 --
configs/xilinx_mbv32_smode_defconfig | 20 ++--
6 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/dts/xilinx-mbv32.dts b/arch/riscv/dts/xilinx-mbv32.dts
index 94e42c268115..48ee11549566 100644
--- a/arch/riscv/dts/xilinx-mbv32.dts
+++ b/arch/riscv/dts/xilinx-mbv32.dts
@@ -8,6 +8,9 @@
*/
/dts-v1/;
+
+#include "binman.dtsi"
+
/ {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 9641ed307b75..e5ab32f901b9 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -358,6 +358,14 @@ void *board_fdt_blob_setup(int *err)
void *fdt_blob;
*err = 0;
+
+ if (IS_ENABLED(CONFIG_TARGET_XILINX_MBV)) {
+ fdt_blob = (void *)CONFIG_XILINX_OF_BOARD_DTB_ADDR;
+
+ if (fdt_magic(fdt_blob) == FDT_MAGIC)
+ return fdt_blob;
+ }
+
if (!IS_ENABLED(CONFIG_SPL_BUILD) &&
!IS_ENABLED(CONFIG_VERSAL_NO_DDR) &&
!IS_ENABLED(CONFIG_ZYNQMP_NO_DDR)) {
diff --git a/board/xilinx/mbv/Kconfig b/board/xilinx/mbv/Kconfig
index 553c2320697d..9d5ee65cea6f 100644
--- a/board/xilinx/mbv/Kconfig
+++ b/board/xilinx/mbv/Kconfig
@@ -15,12 +15,23 @@ config SYS_CONFIG_NAME
config TEXT_BASE
default 0x2120
+config SPL_TEXT_BASE
+ default 0x2000
+
+config SPL_OPENSBI_LOAD_ADDR
+ hex
+ default 0x2020
+
config BOARD_SPECIFIC_OPTIONS
def_bool y
select GENERIC_RISCV
+ select SUPPORT_SPL
imply BOARD_LATE_INIT
+ imply SPL_RAM_SUPPORT
+ imply SPL_RAM_DEVICE
imply CMD_SBI
imply CMD_PING
+ imply OF_HAS_PRIOR_STAGE
source "board/xilinx/Kconfig"
diff --git a/board/xilinx/mbv/board.c b/board/xilinx/mbv/board.c
index ccf4395d6ace..c478f7e04a0c 100644
--- a/board/xilinx/mbv/board.c
+++ b/board/xilinx/mbv/board.c
@@ -5,7 +5,17 @@
* Michal Simek
*/
+#include
+
int board_init(void)
{
return 0;
}
+
+#ifdef CONFIG_SPL
+u32 spl_boot_device(void)
+{
+ /* RISC-V QEMU only supports RAM as SPL boot device */
+ return BOOT_DEVICE_RAM;
+}
+#endif
diff --git a/configs/xilinx_mbv32_defconfig b/configs/xilinx_mbv32_defconfig
index a08a12570d34..4113409efbb2 100644
--- a/configs/xilinx_mbv32_defconfig
+++ b/configs/xilinx_mbv32_defconfig
@@ -1,10 +1,13 @@
CONFIG_RISCV=y
-CONFIG_SYS_MALLOC_LEN=0x80
+CONFIG_SYS_MALLOC_LEN=0xe0
CONFIG_NR_DRAM_BANKS=1
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2020
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2120
CONFIG_ENV_SIZE=0x2
CONFIG_DEFAULT_DEVICE_TREE="xilinx-mbv32"
+CONFIG_SPL_STACK=0x2020
+CONFIG_SPL_SIZE_LIMIT=0x4
+CONFIG_SPL=y
CONFIG_DEBUG_UART_BASE=0x4060
CONFIG_DEBUG_UART_CLOCK=100
CONFIG_SYS_CLK_FREQ=1
@@ -12,18 +15,29 @@ CONFIG_BOOT_SCRIPT_OFFSET=0x0
CONFIG_SYS_LOAD_ADDR=0x2020
CONFIG_DEBUG_UART=y
CONFIG_TARGET_XILINX_MBV=y
+# CONFIG_SPL_SMP is not set
CONFIG_REMAKE_ELF=y
CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x2020
CONFIG_DISTRO_DEFAULTS=y
CONFIG_DISPLAY_CPUINFO=y
CONFIG_DISPLAY_BOARDINFO=y
# CONFIG_BOARD_LATE_INIT is not set
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_BSS_START_ADDR=0x2400
+CONFIG_SPL_BSS_MAX_SIZE=0x8
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_SYS_MALLOC=y
+CONFIG_SPL_SYS_MALLOC_SIZE=0x80
# CONFIG_CMD_MII is not set
CONFIG_CMD_TIMER=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
CONFIG_DM_MTD=y
CONFIG_DEBUG_UART_ANNOUNCE=y
CONFIG_DEBUG_UART_SKIP_INIT=y
CONFIG_XILINX_UARTLITE=y
CONFIG_XILINX_TIMER=y
+# CONFIG_BINMAN_FDT is not set
CONFIG_PANIC_HANG=y
+CONFIG_SPL_GZIP=y
diff --git a/configs/xilinx_mbv32_smode_defconfig
b/configs/xilinx_mbv32_smode_defconfig
index fd3ef931f6ca..99381478ac5c 100644
--- a/configs/xilinx_mbv32_smode_defconfig
+++ b/configs/xilinx_mbv32_smode_defconfig
@@ -1,26 +1,40 @@
CONFIG_RISCV=y
-CONFIG_SYS_MALLOC_LEN=0x80
+CONFIG_SYS_MALLOC_LEN=0xe0
CONFIG_NR_DRAM_BANKS=1
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2020
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2120
CONFIG_ENV_SIZE=0x2
CONFIG_DEFAULT_DEVICE_TREE="xilinx-mbv32"
+CONFIG_SPL_STACK=0x2020
+CONFIG_SPL_SIZE_LIMIT=0x4
+CONFIG_SPL=y
[PATCH 4/5] riscv: mbv: Moving little_endian variable to data section
SPL is cleaning bss after calling board_init_f. Setting up console is done
and little_endian global variable is cleared which caused that console
stops to work. That's why move it to data seciton now. The patch should be
reverted when bss is cleared before board_init_f is called.
Signed-off-by: Michal Simek
---
drivers/serial/serial_xuartlite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/serial/serial_xuartlite.c
b/drivers/serial/serial_xuartlite.c
index b6197da97cc1..35df413321fe 100644
--- a/drivers/serial/serial_xuartlite.c
+++ b/drivers/serial/serial_xuartlite.c
@@ -23,7 +23,7 @@
#define ULITE_CONTROL_RST_TX 0x01
#define ULITE_CONTROL_RST_RX 0x02
-static bool little_endian;
+static bool little_endian __section(".data");
struct uartlite {
unsigned int rx_fifo;
--
2.36.1
[PATCH 3/5] riscv: mbv: Switch to OF_SEPARATE with fixed address
Hardcode DTB address to specific address. Signed-off-by: Michal Simek --- board/xilinx/Kconfig | 1 + configs/xilinx_mbv32_defconfig | 1 - configs/xilinx_mbv32_smode_defconfig | 1 - 3 files changed, 1 insertion(+), 2 deletions(-) diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig index 843198fa0da8..5c4ad8f1df9a 100644 --- a/board/xilinx/Kconfig +++ b/board/xilinx/Kconfig @@ -45,6 +45,7 @@ config XILINX_OF_BOARD_DTB_ADDR default 0x1000 if ARCH_VERSAL || ARCH_VERSAL_NET default 0x8000 if MICROBLAZE default 0x10 if ARCH_ZYNQ || ARCH_ZYNQMP + default 0x2300 if TARGET_XILINX_MBV depends on OF_BOARD || OF_SEPARATE help Offset in the memory where the board configuration DTB is placed. diff --git a/configs/xilinx_mbv32_defconfig b/configs/xilinx_mbv32_defconfig index 89fb3fbd2fbd..a08a12570d34 100644 --- a/configs/xilinx_mbv32_defconfig +++ b/configs/xilinx_mbv32_defconfig @@ -20,7 +20,6 @@ CONFIG_DISPLAY_BOARDINFO=y # CONFIG_BOARD_LATE_INIT is not set # CONFIG_CMD_MII is not set CONFIG_CMD_TIMER=y -CONFIG_OF_EMBED=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_DEBUG_UART_ANNOUNCE=y diff --git a/configs/xilinx_mbv32_smode_defconfig b/configs/xilinx_mbv32_smode_defconfig index 844afdecebf5..fd3ef931f6ca 100644 --- a/configs/xilinx_mbv32_smode_defconfig +++ b/configs/xilinx_mbv32_smode_defconfig @@ -20,7 +20,6 @@ CONFIG_DISPLAY_BOARDINFO=y # CONFIG_BOARD_LATE_INIT is not set # CONFIG_CMD_MII is not set CONFIG_CMD_TIMER=y -CONFIG_OF_EMBED=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_DEBUG_UART_UARTLITE=y -- 2.36.1
[PATCH 2/5] riscv: mbv: Enable REMAKE_ELF by default
Create also u-boot.elf out of u-boot ELF. It is better to align it with other Xilinx SOC where u-boot.elf also exists and tools like bootgen works only with files with .elf extension. Signed-off-by: Michal Simek --- configs/xilinx_mbv32_defconfig | 1 + configs/xilinx_mbv32_smode_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/xilinx_mbv32_defconfig b/configs/xilinx_mbv32_defconfig index 912355f42911..89fb3fbd2fbd 100644 --- a/configs/xilinx_mbv32_defconfig +++ b/configs/xilinx_mbv32_defconfig @@ -12,6 +12,7 @@ CONFIG_BOOT_SCRIPT_OFFSET=0x0 CONFIG_SYS_LOAD_ADDR=0x2020 CONFIG_DEBUG_UART=y CONFIG_TARGET_XILINX_MBV=y +CONFIG_REMAKE_ELF=y CONFIG_FIT=y CONFIG_DISTRO_DEFAULTS=y CONFIG_DISPLAY_CPUINFO=y diff --git a/configs/xilinx_mbv32_smode_defconfig b/configs/xilinx_mbv32_smode_defconfig index 3c911607a8d9..844afdecebf5 100644 --- a/configs/xilinx_mbv32_smode_defconfig +++ b/configs/xilinx_mbv32_smode_defconfig @@ -12,6 +12,7 @@ CONFIG_BOOT_SCRIPT_OFFSET=0x0 CONFIG_SYS_LOAD_ADDR=0x2020 CONFIG_TARGET_XILINX_MBV=y CONFIG_RISCV_SMODE=y +CONFIG_REMAKE_ELF=y CONFIG_FIT=y CONFIG_DISTRO_DEFAULTS=y CONFIG_DISPLAY_CPUINFO=y -- 2.36.1
[PATCH 1/5] riscv: mbv: Align addresses with default DT
Better to align everything with memory map described in DT to avoid mistakes. Execute both modes form the same address to make address map more understandable. Signed-off-by: Michal Simek --- board/xilinx/mbv/Kconfig | 3 +-- configs/xilinx_mbv32_defconfig | 3 +-- configs/xilinx_mbv32_smode_defconfig | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/board/xilinx/mbv/Kconfig b/board/xilinx/mbv/Kconfig index 4bc9f72c541b..553c2320697d 100644 --- a/board/xilinx/mbv/Kconfig +++ b/board/xilinx/mbv/Kconfig @@ -13,8 +13,7 @@ config SYS_CONFIG_NAME default "xilinx_mbv" config TEXT_BASE - default 0x8000 if !RISCV_SMODE - default 0x8040 if RISCV_SMODE && ARCH_RV32I + default 0x2120 config BOARD_SPECIFIC_OPTIONS def_bool y diff --git a/configs/xilinx_mbv32_defconfig b/configs/xilinx_mbv32_defconfig index 2689495057b0..912355f42911 100644 --- a/configs/xilinx_mbv32_defconfig +++ b/configs/xilinx_mbv32_defconfig @@ -1,5 +1,4 @@ CONFIG_RISCV=y -CONFIG_TEXT_BASE=0x2120 CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y @@ -10,7 +9,7 @@ CONFIG_DEBUG_UART_BASE=0x4060 CONFIG_DEBUG_UART_CLOCK=100 CONFIG_SYS_CLK_FREQ=1 CONFIG_BOOT_SCRIPT_OFFSET=0x0 -CONFIG_SYS_LOAD_ADDR=0x8020 +CONFIG_SYS_LOAD_ADDR=0x2020 CONFIG_DEBUG_UART=y CONFIG_TARGET_XILINX_MBV=y CONFIG_FIT=y diff --git a/configs/xilinx_mbv32_smode_defconfig b/configs/xilinx_mbv32_smode_defconfig index c724d1bad742..3c911607a8d9 100644 --- a/configs/xilinx_mbv32_smode_defconfig +++ b/configs/xilinx_mbv32_smode_defconfig @@ -1,5 +1,4 @@ CONFIG_RISCV=y -CONFIG_TEXT_BASE=0x2120 CONFIG_SYS_MALLOC_LEN=0x80 CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y @@ -10,7 +9,7 @@ CONFIG_DEBUG_UART_BASE=0x4060 CONFIG_DEBUG_UART_CLOCK=100 CONFIG_SYS_CLK_FREQ=1 CONFIG_BOOT_SCRIPT_OFFSET=0x0 -CONFIG_SYS_LOAD_ADDR=0x8020 +CONFIG_SYS_LOAD_ADDR=0x2020 CONFIG_TARGET_XILINX_MBV=y CONFIG_RISCV_SMODE=y CONFIG_FIT=y -- 2.36.1
[PATCH 0/5] riscv: mbv: Enhance MB-V support with also enabling SPL
Hi, enhance MB-V support with SPL configuration to support OpenSBI. All of that changes are out of generic Risc-V support that's why happy to take it via my tree. Please let me know if you want this to take via riscv subtree. Thanks, Michal Michal Simek (5): riscv: mbv: Align addresses with default DT riscv: mbv: Enable REMAKE_ELF by default riscv: mbv: Switch to OF_SEPARATE with fixed address riscv: mbv: Moving little_endian variable to data section riscv: mbv: Enable SPL and binman arch/riscv/dts/xilinx-mbv32.dts | 3 +++ board/xilinx/Kconfig | 1 + board/xilinx/common/board.c | 8 board/xilinx/mbv/Kconfig | 14 -- board/xilinx/mbv/board.c | 10 ++ configs/xilinx_mbv32_defconfig | 23 ++- configs/xilinx_mbv32_smode_defconfig | 25 - drivers/serial/serial_xuartlite.c| 2 +- 8 files changed, 73 insertions(+), 13 deletions(-) -- 2.36.1
Re: [PATCH v2 9/9] riscv: Update alignment for some sections in linker scripts
Hi Bin,
čt 13. 4. 2023 v 8:21 odesílatel Bin Meng napsal:
> Some sections in the linker scripts are aligned to 4 bytes, which
> may cause misaligned exception on some platforms, e.g.: clearing
> the bss section on 64-bit hardware if __bss_start does not start
> from a naturally 8 bytes aligned address.
>
> Signed-off-by: Bin Meng
>
> ---
>
> (no changes since v1)
>
> arch/riscv/cpu/u-boot-spl.lds | 2 +-
> arch/riscv/cpu/u-boot.lds | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/riscv/cpu/u-boot-spl.lds b/arch/riscv/cpu/u-boot-spl.lds
> index c3b4907905..d1113a59aa 100644
> --- a/arch/riscv/cpu/u-boot-spl.lds
> +++ b/arch/riscv/cpu/u-boot-spl.lds
> @@ -44,7 +44,7 @@ SECTIONS
> __binman_sym_end = .;
> } > .spl_mem
>
> - . = ALIGN(4);
> + . = ALIGN(8);
>
> _end = .;
> _image_binary_end = .;
> diff --git a/arch/riscv/cpu/u-boot.lds b/arch/riscv/cpu/u-boot.lds
> index 1c937aebee..15b5cbc585 100644
> --- a/arch/riscv/cpu/u-boot.lds
> +++ b/arch/riscv/cpu/u-boot.lds
> @@ -57,7 +57,7 @@ SECTIONS
> __efi_runtime_rel_stop = .;
> }
>
> - . = ALIGN(4);
> + . = ALIGN(8);
>
> /DISCARD/ : { *(.rela.plt*) }
> .rela.dyn : {
> @@ -66,7 +66,7 @@ SECTIONS
> __rel_dyn_end = .;
> }
>
> - . = ALIGN(4);
> + . = ALIGN(8);
>
> .dynsym : {
> __dyn_sym_start = .;
> @@ -74,7 +74,7 @@ SECTIONS
> __dyn_sym_end = .;
> }
>
> - . = ALIGN(4);
> + . = ALIGN(8);
>
> _end = .;
>
This change has actually a side effect on SPL and its behavior. You are
enforcing here that symbols _end
or _image_binary_end are 8byte aligned but if previous section are only 4
bytes aligned you are forcing 4byte gap
between the end of u-boot-nodtb.bin binary and symbol reference.
It means when you want to attach dtb behind SPL you have a problem.
DTBs should be 64bit aligned. It means alignment of 8bytes is fine but you
need to also make sure that
spl/u-boot-nodtb.bin is 8byte aligned.
Pretty much talking about change like below but it would require to change
all u-boot-spl.lds to make sure that end symbols are
8byte aligned that appended DTB is 8byte aligned all the time.
Thanks,
Michal
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 407fc52376a5..486360f10176 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -320,7 +320,7 @@ endif
endif
ifneq ($(build_dtb),)
-$(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
+$(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb-align.bin \
$(if
$(CONFIG_$(SPL_TPL_)SEPARATE_BSS),,$(obj)/$(SPL_BIN)-pad.bin) \
$(FINAL_DTB_CONTAINER) FORCE
$(call if_changed,cat)
@@ -328,7 +328,7 @@ $(obj)/$(SPL_BIN)-dtb.bin: $(obj)/$(SPL_BIN)-nodtb.bin \
$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-dtb.bin FORCE
$(call if_changed,copy)
else
-$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-nodtb.bin FORCE
+$(obj)/$(SPL_BIN).bin: $(obj)/$(SPL_BIN)-nodtb-align.bin FORCE
$(call if_changed,copy)
endif
@@ -390,6 +390,9 @@ OBJCOPYFLAGS_$(SPL_BIN)-nodtb.bin = $(SPL_OBJCFLAGS) -O
binary \
$(obj)/$(SPL_BIN)-nodtb.bin: $(obj)/$(SPL_BIN) FORCE
$(call if_changed,objcopy)
+$(obj)/$(SPL_BIN)-nodtb-align.bin: $(obj)/$(SPL_BIN)-nodtb.bin
+ @dd if=$< of=$@ conv=block,sync bs=8 2>/dev/null;
+
OBJCOPYFLAGS_u-boot-x86-start16-spl.bin := -O binary -j .start16
$(obj)/u-boot-x86-start16-spl.bin: $(obj)/u-boot-spl FORCE
$(call if_changed,objcopy)
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] arm64: versal-net: Setup correct addresses of GICR/GICD
On 2/6/24 12:51, Michal Simek wrote: Previous addresses where used in past in emulation environment but never gets to silicon that's why use correct addresses. Signed-off-by: Michal Simek --- include/configs/xilinx_versal_net.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/xilinx_versal_net.h b/include/configs/xilinx_versal_net.h index 2b441da91a10..9cb6b2bfea3e 100644 --- a/include/configs/xilinx_versal_net.h +++ b/include/configs/xilinx_versal_net.h @@ -16,8 +16,8 @@ /* #define CONFIG_ARMV8_SWITCH_TO_EL1 */ /* Generic Interrupt Controller Definitions */ -#define GICD_BASE 0xF900 -#define GICR_BASE 0xF906 +#define GICD_BASE 0xe200 +#define GICR_BASE 0xe206 /* Serial setup */ #define CFG_SYS_BAUDRATE_TABLE \ Applied. M
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On 2024-02-14 11:01, Shantur Rathore wrote:
On Wed, Feb 14, 2024 at 9:56 AM Shantur Rathore wrote:
On Wed, Feb 14, 2024 at 3:48 AM Dragan Simic
wrote:
> On 2024-02-14 04:18, Dragan Simic wrote:
> > On 2024-02-14 03:04, Andre Przywara wrote:
> >> On Mon, 12 Feb 2024 21:19:13 +0100 Marek Vasut wrote:
> >>> On 2/12/24 14:41, Shantur Rathore wrote:
> >>> > On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore
wrote:
> >>> >> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic
wrote:
> >>> >>> On 2024-02-08 15:17, Dragan Simic wrote:
> >>> On 2024-02-08 15:10, Shantur Rathore wrote:
> >>> > On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
> >>> > wrote:
> >>> >> On 2024-02-08 14:33, Marek Vasut wrote:
> >>> >>> On 2/8/24 12:30, Shantur Rathore wrote:
> >>> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut wrote:
> >>> > On 2/7/24 11:23, Shantur Rathore wrote:
> >>> >> USB 3.0 spec requires hub to reset device while
> >>> >> enumeration. Some USB 2.0 hubs / devices don't
> >>> >> handle this well and after implementation of
> >>> >> reset some USB 2.0 disks weren't detected on
> >>> >> Allwinner based boards.
> >>> >>
> >>> >> Resetting only when hub is USB 3.0 fixes it.
> >>> >
> >>> > It would be good to include as many details about the faulty
hardware
> >>> > in
> >>> > the commit message as possible, so that when someone else runs
into
> >>> > this, they would have all that information available.
> >>> >
> >>> >> Tested-by: Andre Przywara
> >>> >>
> >>> >> Signed-off-by: Shantur Rathore
> >>> >> ---
> >>> >>
> >>> >> common/usb_hub.c | 6 --
> >>> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>> >>
> >>> >> diff --git a/common/usb_hub.c b/common/usb_hub.c
> >>> >> index 3fb7e14d10..2e054eb935 100644
> >>> >> --- a/common/usb_hub.c
> >>> >> +++ b/common/usb_hub.c
> >>> >> @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
> >>> >> usb_hub_device *hub)
> >>> >>
> >>> >> debug("enabling power on all ports\n");
> >>> >> for (i = 0; i < dev->maxchild; i++) {
> >>> >> - usb_set_port_feature(dev, i + 1,
USB_PORT_FEAT_RESET);
> >>> >> - debug("Reset : port %d returns %lX\n", i + 1,
> >>> >> dev->status);
> >>> >> + if (usb_hub_is_superspeed(dev)) {
> >>> >
> >>> > Should this condition be "all which are lower than superspeed"
> >>> > instead ,
> >>> > so when the next generation of USB comes, this problem won't
trigger
> >>> > ?
> >>> >
> >>> > What does Linux do btw ?
> >>>
> >>> As of now Linux checks if the hub is superspeed
> >>>
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
> >>>
> >>> which is
> >>> return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
> >>> USB_HUB_PR_SS = 3
> >>>
> >>> This holds true for newer SuperSpeedPlus hubs as well.
> >>>
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
> >>>
> >>> We can change the check to be bDeviceProtocol > 2 but who knows
if
> >>> things change in the newer version of spec.
> >>> I am open to suggestions.
> >>> >>>
> >>> >>> Please just include the ^ in the commit description. Use link to
> >>> >>> git.kernel.org , not some mirror . This is extremely useful
> >>> >>> information and, well, you already wrote the V2 commit message
> >>> >>> addition in this answer.
> >>> >>
> >>> >> Shantur, if that would be easier or quicker for you, I can write
> >>> >> a quite detailed patch description for you, in exchange for a
> >>> >> "Helped-by" tag in the v2 patch submission. :)
> >>> >
> >>> > That would be really kind of you Dragan.
> >>>
> >>> Sure, I'll write the summary and send it over.
> >>>
> >>> > I am down with the flu so that would really help me as my brain is
> >>> > working at 15% capacity.
> >>>
> >>> Oh, I'm really sorry to hear that. :( I hope you'll get better
> >>> soon, and I know very well what's it like; I've also been sick
> >>> recently, as a result of some kind of flu that unfortunately found
> >>> its way into my lungs, and it took me about a month to get back
> >>> to about 90% of my usual mental capacity. I'm still not back to
> >>> exactly 100%. :/
> >>>
> >>> I really hope you'll recover much faster.
> >>> >>>
> >>> >>> I hope you're feeling better.
> >>> >>>
> >>> >>> Below are the patch subject and description that I prepared for you,
> >>> >>> please have a look.
> >>> >>>
> >>> >>> --- >8
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On Wed, Feb 14, 2024 at 9:56 AM Shantur Rathore wrote:
>
> On Wed, Feb 14, 2024 at 3:48 AM Dragan Simic wrote:
> >
> > Hello Shantur and Marek,
> >
> > On 2024-02-14 04:18, Dragan Simic wrote:
> > > On 2024-02-14 03:04, Andre Przywara wrote:
> > >> On Mon, 12 Feb 2024 21:19:13 +0100 Marek Vasut wrote:
> > >>> On 2/12/24 14:41, Shantur Rathore wrote:
> > >>> > On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore
> > >>> > wrote:
> > >>> >> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic
> > >>> >> wrote:
> > >>> >>> On 2024-02-08 15:17, Dragan Simic wrote:
> > >>> On 2024-02-08 15:10, Shantur Rathore wrote:
> > >>> > On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
> > >>> > wrote:
> > >>> >> On 2024-02-08 14:33, Marek Vasut wrote:
> > >>> >>> On 2/8/24 12:30, Shantur Rathore wrote:
> > >>> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut
> > >>> wrote:
> > >>> > On 2/7/24 11:23, Shantur Rathore wrote:
> > >>> >> USB 3.0 spec requires hub to reset device while
> > >>> >> enumeration. Some USB 2.0 hubs / devices don't
> > >>> >> handle this well and after implementation of
> > >>> >> reset some USB 2.0 disks weren't detected on
> > >>> >> Allwinner based boards.
> > >>> >>
> > >>> >> Resetting only when hub is USB 3.0 fixes it.
> > >>> >
> > >>> > It would be good to include as many details about the faulty
> > >>> > hardware
> > >>> > in
> > >>> > the commit message as possible, so that when someone else
> > >>> > runs into
> > >>> > this, they would have all that information available.
> > >>> >
> > >>> >> Tested-by: Andre Przywara
> > >>> >>
> > >>> >> Signed-off-by: Shantur Rathore
> > >>> >> ---
> > >>> >>
> > >>> >> common/usb_hub.c | 6 --
> > >>> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> > >>> >>
> > >>> >> diff --git a/common/usb_hub.c b/common/usb_hub.c
> > >>> >> index 3fb7e14d10..2e054eb935 100644
> > >>> >> --- a/common/usb_hub.c
> > >>> >> +++ b/common/usb_hub.c
> > >>> >> @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
> > >>> >> usb_hub_device *hub)
> > >>> >>
> > >>> >> debug("enabling power on all ports\n");
> > >>> >> for (i = 0; i < dev->maxchild; i++) {
> > >>> >> - usb_set_port_feature(dev, i + 1,
> > >>> >> USB_PORT_FEAT_RESET);
> > >>> >> - debug("Reset : port %d returns %lX\n", i + 1,
> > >>> >> dev->status);
> > >>> >> + if (usb_hub_is_superspeed(dev)) {
> > >>> >
> > >>> > Should this condition be "all which are lower than superspeed"
> > >>> > instead ,
> > >>> > so when the next generation of USB comes, this problem won't
> > >>> > trigger
> > >>> > ?
> > >>> >
> > >>> > What does Linux do btw ?
> > >>>
> > >>> As of now Linux checks if the hub is superspeed
> > >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
> > >>>
> > >>> which is
> > >>> return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
> > >>> USB_HUB_PR_SS = 3
> > >>>
> > >>> This holds true for newer SuperSpeedPlus hubs as well.
> > >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
> > >>>
> > >>> We can change the check to be bDeviceProtocol > 2 but who
> > >>> knows if
> > >>> things change in the newer version of spec.
> > >>> I am open to suggestions.
> > >>> >>>
> > >>> >>> Please just include the ^ in the commit description. Use link to
> > >>> >>> git.kernel.org , not some mirror . This is extremely useful
> > >>> >>> information and, well, you already wrote the V2 commit message
> > >>> >>> addition in this answer.
> > >>> >>
> > >>> >> Shantur, if that would be easier or quicker for you, I can write
> > >>> >> a quite detailed patch description for you, in exchange for a
> > >>> >> "Helped-by" tag in the v2 patch submission. :)
> > >>> >
> > >>> > That would be really kind of you Dragan.
> > >>>
> > >>> Sure, I'll write the summary and send it over.
> > >>>
> > >>> > I am down with the flu so that would really help me as my brain is
> > >>> > working at 15% capacity.
> > >>>
> > >>> Oh, I'm really sorry to hear that. :( I hope you'll get better
> > >>> soon, and I know very well what's it like; I've also been sick
> > >>> recently, as a result of some kind of flu that unfortunately found
> > >>> its way into my lungs, and it took me about a month to get back
> > >>> to about 90% of my usual mental capacity. I'm still not back to
>
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On Wed, Feb 14, 2024 at 3:48 AM Dragan Simic wrote:
>
> Hello Shantur and Marek,
>
> On 2024-02-14 04:18, Dragan Simic wrote:
> > On 2024-02-14 03:04, Andre Przywara wrote:
> >> On Mon, 12 Feb 2024 21:19:13 +0100 Marek Vasut wrote:
> >>> On 2/12/24 14:41, Shantur Rathore wrote:
> >>> > On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore
> >>> > wrote:
> >>> >> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic
> >>> >> wrote:
> >>> >>> On 2024-02-08 15:17, Dragan Simic wrote:
> >>> On 2024-02-08 15:10, Shantur Rathore wrote:
> >>> > On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
> >>> > wrote:
> >>> >> On 2024-02-08 14:33, Marek Vasut wrote:
> >>> >>> On 2/8/24 12:30, Shantur Rathore wrote:
> >>> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut wrote:
> >>> > On 2/7/24 11:23, Shantur Rathore wrote:
> >>> >> USB 3.0 spec requires hub to reset device while
> >>> >> enumeration. Some USB 2.0 hubs / devices don't
> >>> >> handle this well and after implementation of
> >>> >> reset some USB 2.0 disks weren't detected on
> >>> >> Allwinner based boards.
> >>> >>
> >>> >> Resetting only when hub is USB 3.0 fixes it.
> >>> >
> >>> > It would be good to include as many details about the faulty
> >>> > hardware
> >>> > in
> >>> > the commit message as possible, so that when someone else runs
> >>> > into
> >>> > this, they would have all that information available.
> >>> >
> >>> >> Tested-by: Andre Przywara
> >>> >>
> >>> >> Signed-off-by: Shantur Rathore
> >>> >> ---
> >>> >>
> >>> >> common/usb_hub.c | 6 --
> >>> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>> >>
> >>> >> diff --git a/common/usb_hub.c b/common/usb_hub.c
> >>> >> index 3fb7e14d10..2e054eb935 100644
> >>> >> --- a/common/usb_hub.c
> >>> >> +++ b/common/usb_hub.c
> >>> >> @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
> >>> >> usb_hub_device *hub)
> >>> >>
> >>> >> debug("enabling power on all ports\n");
> >>> >> for (i = 0; i < dev->maxchild; i++) {
> >>> >> - usb_set_port_feature(dev, i + 1,
> >>> >> USB_PORT_FEAT_RESET);
> >>> >> - debug("Reset : port %d returns %lX\n", i + 1,
> >>> >> dev->status);
> >>> >> + if (usb_hub_is_superspeed(dev)) {
> >>> >
> >>> > Should this condition be "all which are lower than superspeed"
> >>> > instead ,
> >>> > so when the next generation of USB comes, this problem won't
> >>> > trigger
> >>> > ?
> >>> >
> >>> > What does Linux do btw ?
> >>>
> >>> As of now Linux checks if the hub is superspeed
> >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
> >>>
> >>> which is
> >>> return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
> >>> USB_HUB_PR_SS = 3
> >>>
> >>> This holds true for newer SuperSpeedPlus hubs as well.
> >>> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
> >>>
> >>> We can change the check to be bDeviceProtocol > 2 but who knows
> >>> if
> >>> things change in the newer version of spec.
> >>> I am open to suggestions.
> >>> >>>
> >>> >>> Please just include the ^ in the commit description. Use link to
> >>> >>> git.kernel.org , not some mirror . This is extremely useful
> >>> >>> information and, well, you already wrote the V2 commit message
> >>> >>> addition in this answer.
> >>> >>
> >>> >> Shantur, if that would be easier or quicker for you, I can write
> >>> >> a quite detailed patch description for you, in exchange for a
> >>> >> "Helped-by" tag in the v2 patch submission. :)
> >>> >
> >>> > That would be really kind of you Dragan.
> >>>
> >>> Sure, I'll write the summary and send it over.
> >>>
> >>> > I am down with the flu so that would really help me as my brain is
> >>> > working at 15% capacity.
> >>>
> >>> Oh, I'm really sorry to hear that. :( I hope you'll get better
> >>> soon, and I know very well what's it like; I've also been sick
> >>> recently, as a result of some kind of flu that unfortunately found
> >>> its way into my lungs, and it took me about a month to get back
> >>> to about 90% of my usual mental capacity. I'm still not back to
> >>> exactly 100%. :/
> >>>
> >>> I really hope you'll recover much faster.
> >>> >>>
> >>> >>> I hope you're feeling better.
> >>> >>>
> >>> >>> Below are the patch subject and description that I prepared for you,
> >>> >>> please have a look.
> >>> >>>
> >>> >>>
[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
Additional testing of the changes introduced in commit 33e06dcbe57a "common:
usb-hub: Reset hub port before scanning") revealed that some USB 2.0 and 3.0
flash drives didn't work in U-Boot on some Allwinner SoCs that support USB
2.0 interfaces only. More precisely, some of the tested USB 2.0 and 3.0
flash drives failed to be detected and work on an OrangePi Zero 3, based on
the Allwinner H616 SoC that supports USB 2.0 only, while the same USB flash
drives worked just fine on a Pine64 H64, based on the Allwinner H6 SoC that
supports both USB 2.0 and USB 3.0 interfaces.
The USB ID of the above-mentioned USB 3.0 flash drive that failed to work is
1f75:0917 (Innostor Technology Corporation IS917 Mass storage), it is 32 GB
in size and sold under the PNY brand. The mentioned USB 2.0 drive is some
inexpensive no-name drive with an invalid USB ID.
Resetting USB 3.0 hubs only, which this patch introduces to the USB hub
resets, has been tested to work as expected, resolving the identified issues
on the Allwinner H616, while not introducing any new issues on other tested
Allwinner SoCs. Thus, let's fix it that way.
According to the USB 3.0 specification, resetting a USB 3.0 port is required
when an attached USB device transitions between different states, such as
when it resumes from suspend. Though, the Linux kernel performs additional
USB 3.0 port resets upon initial USB device attachment, as visible in commit
07194ab7be63 ("USB: Reset USB 3.0 devices on (re)discovery") in the kernel
source, to ensure proper state of the USB 3.0 hub port and proper USB mode
negotiation during the initial USB device attachment and enumeration.
These additional types of USB port resets don't exist for USB 2.0 hubs,
according the USB 2.0 specification. The resets seem to be added to the USB
3.0 specification as part of the port and device mode negotiation.
The Linux kernel resets USB 3.0 (i.e. SuperSpeed) hubs only, as visible in
commit 10d674a82e55 ("USB: When hot reset for USB3 fails, try warm reset.")
in the kernel source. The check for SuperSpeed hubs is performed in a way
that also applies to newer SuperSpeed Plus (USB 3.1 or 3.2) hubs as well,
which hopefully makes it future proof.
Fixes: commit 33e06dcbe57a ("common: usb-hub: Reset hub port before scanning")
Link:
https://lore.kernel.org/u-boot/20240207102327.35125-...@shantur.com/T/#u
Link:
https://lore.kernel.org/u-boot/20240201164604.13315...@donnerap.manchester.arm.com/T/#u
Signed-off-by: Shantur Rathore
Helped-by: Dragan Simic
Tested-by: Andre Przywara
Reviewed-by: Dragan Simic
---
(no changes since v1)
common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct usb_hub_device *hub)
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1, dev->status);
+ if (usb_hub_is_superspeed(dev)) {
+ usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
+ debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ }
usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_POWER);
debug("PowerOn : port %d returns %lX\n", i + 1, dev->status);
}
--
2.40.1
[PATCH v2 1/2] board: rockchip: Add support for rk3588s based Cool Pi 4B
CoolPi 4B is a rk3588s based SBC.
Specification:
- Rockchip RK3588S
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- SPI Nor 8MB
- Gigabit ethernet drived by PCIE with RTL8111HS
- HDMI Type D out
- Mini DP out
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- WIFI/BT module AIC8800
- 40 pin header
The dts is from linux-6.8 rc1.
Signed-off-by: Andy Yan
Reviewed-by: Kever Yang
---
Changes in v2:
- sync dts from linux-rockchip which will be in linux-6.8 rc6[0]
[0]https://patchwork.kernel.org/project/linux-rockchip/patch/2450634.jE0xQCEvom@phil/
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi | 30 +
arch/arm/dts/rk3588s-coolpi-4b.dts | 812 +
board/rockchip/evb_rk3588/MAINTAINERS | 7 +
configs/coolpi-4b-rk3588s_defconfig| 105 +++
5 files changed, 955 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588s-coolpi-4b.dts
create mode 100644 configs/coolpi-4b-rk3588s_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ce10d3dbb0..ae7c088ceb 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -190,6 +190,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3568) += \
rk3568-rock-3a.dtb
dtb-$(CONFIG_ROCKCHIP_RK3588) += \
+ rk3588s-coolpi-4b.dts \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
diff --git a/arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
b/arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
new file mode 100644
index 00..6b69ff424f
--- /dev/null
+++ b/arch/arm/dts/rk3588s-coolpi-4b-u-boot.dtsi
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+_pins {
+ bootph-all;
+};
+
+ {
+ bootph-pre-ram;
+ u-boot,spl-sfc-no-dma;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ 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>;
+ };
+};
diff --git a/arch/arm/dts/rk3588s-coolpi-4b.dts
b/arch/arm/dts/rk3588s-coolpi-4b.dts
new file mode 100644
index 00..e037bf9db7
--- /dev/null
+++ b/arch/arm/dts/rk3588s-coolpi-4b.dts
@@ -0,0 +1,812 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ * https://cool-pi.com/topic/130/coolpi-4b-product-spec-introduction
+ *
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include "rk3588s.dtsi"
+
+/ {
+ model = "RK3588S CoolPi 4 Model B";
+ compatible = "coolpi,pi-4b", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
+ analog-sound {
+ compatible = "audio-graph-card";
+ dais = <_8ch_p0>;
+ label = "rk3588-es8316";
+ routing = "MIC2", "Mic Jack",
+ "Headphones", "HPOL",
+ "Headphones", "HPOR";
+ widgets = "Microphone", "Mic Jack",
+ "Headphone", "Headphones";
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <_leds>;
+
+ led0: led-green {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PD0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1: led-red {
+ color = ;
+ default-state = "off";
+ function = LED_FUNCTION_WLAN;
+ gpios = < RK_PC4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "phy0tx";
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <_enable_h>;
+ /*
+* On the module itself this is one of these (depending
+* on the actual card populated):
+* - SDIO_RESET_L_WL_REG_ON
+* - PDN (power down when low)
+*/
+ post-power-on-delay-ms = <200>;
+ reset-gpios = < RK_PC7 GPIO_ACTIVE_LOW>;
+ };
+
+ vcc12v_dcin: vcc12v-dcin-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc12v_dcin";
[PATCH v2 2/2] board: rockchip: Add support for rk3588 based Cool Pi CM5 EVB
Cool Pi CM5 EVB works as a mother board connect with CM5.
CM5 Specification:
- Rockchip RK3588
- LPDDR4 2/4/8/16 GB
- TF scard slot
- eMMC 8/32/64/128 GB module
- SPI Nor 8MB
- Gigabit ethernet x 1 with PHY YT8531
- Gigabit ethernet x 1 drived by PCIE with YT6801S
CM5 EVB Specification:
- HDMI Type A out x 2
- HDMI Type D in x 1
- USB 2.0 Host x 2
- USB 3.0 OTG x 1
- USB 3.0 Host x 1
- PCIE M.2 E Key for Wireless connection
- PCIE M.2 M Key for NVME connection
- 40 pin header
The dts is from linux-6.8 rc1.
Signed-off-by: Andy Yan
Reviewed-by: Kever Yang
---
Changes in v2:
- sync dts from linux-rockchip which will be in linux-6.8 rc6[0]
[0]https://patchwork.kernel.org/project/linux-rockchip/patch/2450634.jE0xQCEvom@phil/
.../arm/dts/rk3588-coolpi-cm5-evb-u-boot.dtsi | 30 +
arch/arm/dts/rk3588-coolpi-cm5-evb.dts| 216 ++
arch/arm/dts/rk3588-coolpi-cm5.dtsi | 649 ++
board/rockchip/evb_rk3588/MAINTAINERS | 8 +
configs/coolpi-cm5-evb-rk3588_defconfig | 105 +++
5 files changed, 1008 insertions(+)
create mode 100644 arch/arm/dts/rk3588-coolpi-cm5-evb-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-coolpi-cm5-evb.dts
create mode 100644 arch/arm/dts/rk3588-coolpi-cm5.dtsi
create mode 100644 configs/coolpi-cm5-evb-rk3588_defconfig
diff --git a/arch/arm/dts/rk3588-coolpi-cm5-evb-u-boot.dtsi
b/arch/arm/dts/rk3588-coolpi-cm5-evb-u-boot.dtsi
new file mode 100644
index 00..6b69ff424f
--- /dev/null
+++ b/arch/arm/dts/rk3588-coolpi-cm5-evb-u-boot.dtsi
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
+
+_pins {
+ bootph-all;
+};
+
+ {
+ bootph-pre-ram;
+ u-boot,spl-sfc-no-dma;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ 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>;
+ };
+};
diff --git a/arch/arm/dts/rk3588-coolpi-cm5-evb.dts
b/arch/arm/dts/rk3588-coolpi-cm5-evb.dts
new file mode 100644
index 00..a4946cdc3b
--- /dev/null
+++ b/arch/arm/dts/rk3588-coolpi-cm5-evb.dts
@@ -0,0 +1,216 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include
+#include "rk3588-coolpi-cm5.dtsi"
+
+/ {
+ model = "RK3588 CoolPi CM5 EVB";
+ compatible = "coolpi,pi-cm5-evb", "coolpi,pi-cm5", "rockchip,rk3588";
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ enable-gpios = < RK_PA3 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_en>;
+ power-supply = <_dcin>;
+ pwms = < 0 25000 0>;
+ };
+
+ leds: leds {
+ compatible = "gpio-leds";
+
+ green_led: led-0 {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = < RK_PB7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vcc12v_dcin: vcc12v-dcin-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc12v_dcin";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1200>;
+ regulator-max-microvolt = <1200>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_dcin>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <_dcin>;
+ };
+
+ vcc3v3_lcd: vcc3v3-lcd-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_lcd";
+ enable-active-high;
+ gpio = < RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_en>;
+ vin-supply = <_sys>;
+ };
+
+ vcc5v0_usb_host1: vcc5v0_usb_host2: vcc5v0-usb-host-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_host";
+ regulator-boot-on;
+
Re: [AVB/AB] Overhaul plans
Hi Igor, On Fri, Feb 09, 2024 at 17:17, Igor Opaniuk wrote: > Hello Mattijs, > > On Fri, Feb 9, 2024 at 11:30 AM Mattijs Korpershoek > wrote: >> >> Hi Igor, >> >> On ven., févr. 09, 2024 at 11:14, Igor Opaniuk >> wrote: >> >> > Hi everyone, >> > >> > I'm currently planning a big overhaul of the current implementation of >> > AVB/AB in U-Boot during the 2024 year, which I have barely touched since >> > 2019. I used to believe that it was stillborn, but looks like it's >> > being actively used >> > now by some SoC vendors and Google folks [1][2]. >> >> This is great news! I am not aware of any development related to the >> above but I'm looking forward to this. >> >> I can't speak for all vendors but I know that TI uses both the AVB and >> AB implementation on their AM62x Android solution. > Amlogic also uses it. I know for VIM3 and VIM3L (since quite some folks at BayLibre were involved in this, including myself) :) I did not know that they use the commands in their vendor implementation. > >> >> > >> > This is what I have in my todo list: >> > * Backport latest libavb from AOSP upstream and add support for >> >Verified Boot 1.3.0 version >> > * Sync include/android_bootloader_message.h with AOSP upstream >> > * Check and backport fixes for AVB in AOSP U-Boot fork if needed [1] >> > * Get acquainted with a current state of A/B support in AOSP and >> >backport all needed changes >> > * Re-factor libavb, switch to U-Boot existing implementation of >> >rsa/sha256/sha512 >> > * Add SHA512 implementation that leverage ARMv8 CE >> >(pull it from Linux) >> > * Enable hw acceleration of SHA256/SHA512 that supports ARMv8 >> >Crypto Extensions to speed up verification process on ARMv8-based >> > boards. >> > * AVB support for NAND storage >> >> I know that this has been send but I don't think Alistair has send any >> follow-up on this: >> https://patchwork.ozlabs.org/project/uboot/patch/20220926220211.868968-1-ade...@google.com/ >> >> > >> > If someone is already working on anything from the above list - >> > please feel free to reach out to me, so we can avoid duplication of effort. >> > >> > Any comments/suggestions are welcome! Thanks! >> >> From my understanding, the AOSP version of U-Boot has quite a different >> bootflow since it relies on the (out-of-tree) boot_android command [3] > > Correct, but it turned out that they are using some parts of the existing avb > implementation in that out-of-tree "boot_android" cmd + > the made some adjustments on top of it, that we might be interested in : > > $ git log --grep=ANDROID --oneline | grep avb > ea8f0bb45e ANDROID: Add avb_verify unit tests > c9f88bf213 ANDROID: Adding function comments to avb_verify > c5599e4a9f Merge "ANDROID: avb_verify: Handle failed malloc in > get_partition()" > 3aeeae4426 ANDROID: avb_verify: Handle failed malloc in get_partition() > 2910c1042c Merge "ANDROID: avb_pubkey: Use bin2c instead of ld" > 30fbf100b6 Merge "ANDROID: avb: Extract avb_pubkey_is_trusted()" > 296361e80c ANDROID: avb_pubkey: Use bin2c instead of ld > 5af2c6d968 ANDROID: avb: Extract avb_pubkey_is_trusted() > f74b3f5815 ANDROID: avb_verify: Don't Return ERROR_IO for mismatch in > pubkey sizes > d6615cd233 Merge "ANDROID: Qualify avb_find_main_pubkey() parameters as const" > 9c8470ed6b ANDROID: Qualify avb_find_main_pubkey() parameters as const > af808f4b04 ANDROID: avb_find_main_pubkey returns CMD_RET_* > 2070f02c75 ANDROID: remove erraneous avb logs Indeed, these seem interesting. > > Btw, my initial intention (back in 2018) was to make avb > implementation boot-command > agnostic, as at the time of implementing it different board/SoC > vendors used different > approaches for booting AOSP; moreover, iirc AOSP-specific cmd > (boota/boot_android > or whatever it's called now) didn't manage to land to the U-Boot > mainline despite > multiple attempts by different contributors. Understood. Maybe with bootflow/bootmeth we could do something named bootmeth_android ! > >> >> [3] >> https://android.googlesource.com/platform/external/u-boot/+/refs/heads/main/cmd/boot_android.c >> >> Please keep me in the loop with your progress. If you want, you can >> reach me on IRC as well (libera: #u-boot, nick: mkorpershoek) > Sure, will keep you posted! > >> >> > >> > [1] https://android.googlesource.com/platform/external/u-boot >> > [2] https://source.android.com/docs/devices/cuttlefish/bootloader-dev >> > [3] >> > https://android.googlesource.com/platform/bootable/recovery/+/main/bootloader_message/include/bootloader_message/bootloader_message.h >> > >> > -- >> > Best regards - Atentamente - Meilleures salutations >> > >> > Igor Opaniuk >> > >> > mailto: igor.opan...@gmail.com >> > skype: igor.opanyuk >> > http://ua.linkedin.com/in/iopaniuk > > Regards, > Igor > > -- > Best regards - Atentamente - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opan...@gmail.com > skype: igor.opanyuk > http://ua.linkedin.com/in/iopaniuk
