Re: [PATCH v3 0/4] Fix fdtfile for j722s and am62p
On Tue, 02 Jul 2024 10:50:00 +0530, Manorit Chawdhry wrote: > fdtfile wasn't being populated in these boards in legacy boot using > bootcmd_ti_mmc, migrate these platforms to ti_set_fdt_env. > > Applied to u-boot/master, thanks! -- Tom
[PATCH v3 0/4] alist: Implement a pointer list / array of structs
This data structure provides a list of pointers / array of structures. I was planning to use it for the lmb restructure, to allow it to support any number of entries, but then I gave up on it. There are quite a few places in U-Boot where such a list would be useful, since it supports growing the array. The series includes a patch to convert an existing function to use this. It adds a little under 300 bytes of code with Thumb2. Example: struct my_struct obj; struct my_struct *ptr = alist_add(, , struct my_struct); // now ptr is in the list [1] https://patchwork.ozlabs.org/project/uboot/list/?series=371258=* Changes in v3: - Add prototype for alist_expand_by() - Update for alist_add() API change Changes in v2: - Fix 'typeee' typo - Make alist_get_ptr() take a const alist * - Make alist_add() take a struct rather than a pointer - Declare alist_expand_by() as static Simon Glass (4): malloc: Support testing with realloc() lib: Handle a special case with str_to_list() alist: Add support for an allocated pointer list lib: Convert str_to_list() to use alist common/dlmalloc.c | 4 + include/alist.h | 214 ++ lib/Makefile | 1 + lib/alist.c | 147 +++ lib/strto.c | 33 --- test/lib/Makefile | 1 + test/lib/alist.c | 197 ++ test/str_ut.c | 4 +- 8 files changed, 584 insertions(+), 17 deletions(-) create mode 100644 include/alist.h create mode 100644 lib/alist.c create mode 100644 test/lib/alist.c -- 2.34.1
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 17:31-20240703, Sebin Francis wrote: > > On 01/07/24 20:54, Nishanth Menon wrote: > > On 15:25-20240701, Sebin Francis wrote: > > > For HS-FS device we need to sign the fs-stub with customer key. DM > > > firmware > > > cannot have a component which is signed using customer key. > > Please explain please why DM cannot have a component signed using a > > customer key for the public record? > > > For HS device customer is owning the customer key and only customer > > has the access for the customer key. Because of this the signing has to > happen > > from the customer side. > > DM is release by TI, Since TI doesn't have access to the customer key it > cannot > > have a component that is signed by customer key. please resubmit the series with this documented in documentation and commit message. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 01/07/24 20:54, Nishanth Menon wrote: On 15:25-20240701, Sebin Francis wrote: For HS-FS device we need to sign the fs-stub with customer key. DM firmware cannot have a component which is signed using customer key. Please explain please why DM cannot have a component signed using a customer key for the public record? For HS device customer is owning the customer key and only customer has the access for the customer key. Because of this the signing has to happen from the customer side. DM is release by TI, Since TI doesn't have access to the customer key it cannot have a component that is signed by customer key.
[PATCH v3 0/4] Fix fdtfile for j722s and am62p
fdtfile wasn't being populated in these boards in legacy boot using bootcmd_ti_mmc, migrate these platforms to ti_set_fdt_env. Signed-off-by: Manorit Chawdhry --- Changes in v3: - Update the commit messages to make the change more clear. - Link to v2: https://lore.kernel.org/r/20240701-b4-upstream-streamline-platform-v2-0-7539ff066...@ti.com --- Dhruva Gole (1): include: env: ti_common: Remove findfdt from bootcmd_ti_mmc Manorit Chawdhry (3): board: ti: am62p|j722s: Add ti_set_fdt_env for fdtfile configs: am62p|j722s_a53: Add CONFIG_BOARD_LATE_INIT include: env: ti: mmc: Change name_fdt usage to fdtfile board/ti/am62px/evm.c| 9 + board/ti/j722s/evm.c | 9 + configs/am62px_evm_a53_defconfig | 1 + configs/j722s_evm_a53_defconfig | 1 + include/env/ti/mmc.env | 2 +- include/env/ti/ti_common.env | 2 +- 6 files changed, 22 insertions(+), 2 deletions(-) --- base-commit: 899b088674b6905710ce546f0a8848662904852a change-id: 20240628-b4-upstream-streamline-platform-f0d7453637b2 Best regards, -- Manorit Chawdhry
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 15:25-20240701, Sebin Francis wrote: > For HS-FS device we need to sign the fs-stub with customer key. DM firmware > cannot have a component which is signed using customer key. Please explain please why DM cannot have a component signed using a customer key for the public record? -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 28/06/24 23:10, Nishanth Menon wrote: On 19:39-20240628, Sebin Francis wrote: On 28/06/24 18:33, Nishanth Menon wrote: On 15:02-20240628, Dhruva Gole wrote: This series includes the binman related changes required to package tIFS Stub to support Low Power Modes on BeaglePlay. Also, based on comments from previous patch [0] documentation has been added to describe small addition in boot flow as well as tispl image format. I am aware that the new boot flow image will need to be updated in other places like am62a, am62p and even other boards that use am62x. However, I would like to keep this series beagleplay TIFSStub specific and so I will be sending a follow up series to update other places seperately if that's ok. [...] Maybe you can help clarify a bit. I understand from [1] that you are betting on timing to keep tifs stub safe. But then, why not plug in this firmware blob along with DM itself? that allows DM to manage itself the way it wants to and control it's own memory map? DM initialization itself takes a few ms, just because TFA is not touching any part of DDR does not mean that we can assume system is interference free, no? What if DM architecture changes such that PLL initialization or some other long pole item is performed prior to loading the tifs stub? In Linux DT the address space in which FS stub is copied is part of DM firmware carve-out in DDR, so if fs stub can get corrupted then DM also can get corrupted. OK - so the memory map we are copying to is already reserved in device tree? See this thread[1] - we are arguing here that the reserved region is meant for bootloader to fill up and keep protected. DT itself from kernel is shared between u-boot and kernel OF_UPSTREAM. Now, the consumer of the binary is DM, the load area is already part of carveout for DM, it sounds like it should have been packaged with DM itself instead of making the packaging problem the problem that everyone image creation system has to solve - not to mention signing etc.. Why not merge this with DM? [1] https://lore.kernel.org/all/59c391a7-c6fe-4b04-891a-c6905ef29...@ti.com/ For HS-FS device we need to sign the fs-stub with customer key. DM firmware cannot have a component which is signed using customer key. Thanks Sebin
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 19:39-20240628, Sebin Francis wrote: > > On 28/06/24 18:33, Nishanth Menon wrote: > > On 15:02-20240628, Dhruva Gole wrote: > > > This series includes the binman related changes required to package tIFS > > > Stub to support Low Power Modes on BeaglePlay. > > > Also, based on comments from previous patch [0] documentation has been > > > added to describe small addition in boot flow as well as tispl image > > > format. > > > > > > I am aware that the new boot flow image will need to be updated in > > > other places like am62a, am62p and even other boards that use am62x. > > > However, I would like to keep this series beagleplay TIFSStub specific > > > and so I will be sending a follow up series to update other places > > > seperately if that's ok. [...] > > > > Maybe you can help clarify a bit. I understand from [1] > > that you are betting on timing to keep tifs stub safe. But then, why > > not plug in this firmware blob along with DM itself? that allows DM > > to manage itself the way it wants to and control it's own memory map? > > DM initialization itself takes a few ms, just because TFA is not > > touching any part of DDR does not mean that we can assume system is > > interference free, no? What if DM architecture changes such that PLL > > initialization or some other long pole item is performed prior to > > loading the tifs stub? > > In Linux DT the address space in which FS stub is copied is part of DM > firmware carve-out in DDR, > so if fs stub can get corrupted then DM also can get corrupted. OK - so the memory map we are copying to is already reserved in device tree? See this thread[1] - we are arguing here that the reserved region is meant for bootloader to fill up and keep protected. DT itself from kernel is shared between u-boot and kernel OF_UPSTREAM. Now, the consumer of the binary is DM, the load area is already part of carveout for DM, it sounds like it should have been packaged with DM itself instead of making the packaging problem the problem that everyone image creation system has to solve - not to mention signing etc.. Why not merge this with DM? [1] https://lore.kernel.org/all/59c391a7-c6fe-4b04-891a-c6905ef29...@ti.com/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 28/06/24 18:33, Nishanth Menon wrote: On 15:02-20240628, Dhruva Gole wrote: This series includes the binman related changes required to package tIFS Stub to support Low Power Modes on BeaglePlay. Also, based on comments from previous patch [0] documentation has been added to describe small addition in boot flow as well as tispl image format. I am aware that the new boot flow image will need to be updated in other places like am62a, am62p and even other boards that use am62x. However, I would like to keep this series beagleplay TIFSStub specific and so I will be sending a follow up series to update other places seperately if that's ok. Changelog: * Add new image format for TISPL * Add new changes in boot flow for am62 family of devices. [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-g...@ti.com/ Dhruva Gole (4): arm: dts: k3-am625-beagleplay: Package TIFS Stub doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub doc: beagle: am62x_beagleplay: Add TIFS Stub in image format doc: ti: k3: Add TIFS Stub documentation arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++- doc/board/beagle/am62x_beagleplay.rst| 4 +-- doc/board/ti/img/boot_diagram_am62.svg | 4 +++ doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 +++ doc/board/ti/k3.rst | 5 +++ 5 files changed, 47 insertions(+), 3 deletions(-) create mode 100644 doc/board/ti/img/boot_diagram_am62.svg create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg Maybe you can help clarify a bit. I understand from [1] that you are betting on timing to keep tifs stub safe. But then, why not plug in this firmware blob along with DM itself? that allows DM to manage itself the way it wants to and control it's own memory map? DM initialization itself takes a few ms, just because TFA is not touching any part of DDR does not mean that we can assume system is interference free, no? What if DM architecture changes such that PLL initialization or some other long pole item is performed prior to loading the tifs stub? In Linux DT the address space in which FS stub is copied is part of DM firmware carve-out in DDR, so if fs stub can get corrupted then DM also can get corrupted. Regards Sebin [1] https://lore.kernel.org/u-boot/20240621054337.qqjftv72ofiinlhv@dhruva/
Re: [PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
On 15:02-20240628, Dhruva Gole wrote: > This series includes the binman related changes required to package tIFS > Stub to support Low Power Modes on BeaglePlay. > Also, based on comments from previous patch [0] documentation has been > added to describe small addition in boot flow as well as tispl image > format. > > I am aware that the new boot flow image will need to be updated in > other places like am62a, am62p and even other boards that use am62x. > However, I would like to keep this series beagleplay TIFSStub specific > and so I will be sending a follow up series to update other places > seperately if that's ok. > > Changelog: > * Add new image format for TISPL > * Add new changes in boot flow for am62 family of devices. > > [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-g...@ti.com/ > > Dhruva Gole (4): > arm: dts: k3-am625-beagleplay: Package TIFS Stub > doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub > doc: beagle: am62x_beagleplay: Add TIFS Stub in image format > doc: ti: k3: Add TIFS Stub documentation > > arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++- > doc/board/beagle/am62x_beagleplay.rst| 4 +-- > doc/board/ti/img/boot_diagram_am62.svg | 4 +++ > doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 +++ > doc/board/ti/k3.rst | 5 +++ > 5 files changed, 47 insertions(+), 3 deletions(-) > create mode 100644 doc/board/ti/img/boot_diagram_am62.svg > create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg Maybe you can help clarify a bit. I understand from [1] that you are betting on timing to keep tifs stub safe. But then, why not plug in this firmware blob along with DM itself? that allows DM to manage itself the way it wants to and control it's own memory map? DM initialization itself takes a few ms, just because TFA is not touching any part of DDR does not mean that we can assume system is interference free, no? What if DM architecture changes such that PLL initialization or some other long pole item is performed prior to loading the tifs stub? [1] https://lore.kernel.org/u-boot/20240621054337.qqjftv72ofiinlhv@dhruva/ -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH V3 0/4] Low Power Mode: Pakage TIFS Stub on BeaglePlay
This series includes the binman related changes required to package tIFS Stub to support Low Power Modes on BeaglePlay. Also, based on comments from previous patch [0] documentation has been added to describe small addition in boot flow as well as tispl image format. I am aware that the new boot flow image will need to be updated in other places like am62a, am62p and even other boards that use am62x. However, I would like to keep this series beagleplay TIFSStub specific and so I will be sending a follow up series to update other places seperately if that's ok. Changelog: * Add new image format for TISPL * Add new changes in boot flow for am62 family of devices. [0] https://lore.kernel.org/u-boot/20240618045610.271884-1-d-g...@ti.com/ Dhruva Gole (4): arm: dts: k3-am625-beagleplay: Package TIFS Stub doc: beagle: am62x_beagleplay: Update the boot flow to show TIFS Stub doc: beagle: am62x_beagleplay: Add TIFS Stub in image format doc: ti: k3: Add TIFS Stub documentation arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 33 +++- doc/board/beagle/am62x_beagleplay.rst| 4 +-- doc/board/ti/img/boot_diagram_am62.svg | 4 +++ doc/board/ti/img/tifsstub_dm_tispl.bin.svg | 4 +++ doc/board/ti/k3.rst | 5 +++ 5 files changed, 47 insertions(+), 3 deletions(-) create mode 100644 doc/board/ti/img/boot_diagram_am62.svg create mode 100644 doc/board/ti/img/tifsstub_dm_tispl.bin.svg base-commit: c53b344475734d0d29f522b7b1d80c5b8204442d -- 2.34.1
Re: [PATCH v3 0/4] Enable OSPI boot for j721s2
On Tue, 04 Jun 2024 11:39:09 +0530, Manorit Chawdhry wrote: > The series enables ospi boot for j721s2. > > Test logs: > https://gist.github.com/manorit2001/6bb91885c608e3a8cb0267ab2c614781 > > Applied to u-boot/next, thanks! -- Tom
[PATCH v3 0/4] Enable OSPI boot for j721s2
The series enables ospi boot for j721s2. Test logs: https://gist.github.com/manorit2001/6bb91885c608e3a8cb0267ab2c614781 Signed-off-by: Manorit Chawdhry --- Changes in v3: - Rebase on top of -next - Remove SF_DEFAULT_MODE as it's default 0 - Add new properties in correct location as per savedefconfig - Link to v2: https://lore.kernel.org/r/20240528-b4-upstream-j721s2-ospi-support-v2-0-b2e372ebc...@ti.com --- Manorit Chawdhry (3): arch: arm: dts: k3-j721s2-r5: Override ospi and fss for 32-bit mode arch: arm: dts: k3-j721s2-*-u-boot.dtsi: Enable the ospi0 node configs: j721s2_evm_*_defconfig: Enable OSPI configs Pratyush Yadav (1): mtd: spi-nor-core: Do not start or end writes at odd address in DTR mode .../dts/k3-j721s2-common-proc-board-u-boot.dtsi| 4 +- arch/arm/dts/k3-j721s2-r5.dtsi | 13 + configs/j721s2_evm_a72_defconfig | 1 + configs/j721s2_evm_r5_defconfig| 1 + drivers/mtd/spi/spi-nor-core.c | 59 -- 5 files changed, 73 insertions(+), 5 deletions(-) --- base-commit: 15d0dcc0ec1f424199dff2a3cbe037bc3a7d8749 change-id: 20240322-b4-upstream-j721s2-ospi-support-d45dfaa926dc Best regards, -- Manorit Chawdhry
Re: [PATCH v3 0/4] Clean-up patch set for MbedTLS integration
On Thu, 16 May 2024 14:11:48 -0700, Raymond Mao wrote: > This patch set is picked from the previously posted serie: > "[RFC] Integrate MbedTLS v3.6 LTS with U-Boot" > > They are not directly related to MbedTLS integration, but the > prerequisite for a few clean-up, refactoring and minor fixes. > > For V2, the linker script patch is dropped and added one patch > to move the snprintf to stdio.h > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH v3 0/4] Clean-up patch set for MbedTLS integration
This patch set is picked from the previously posted serie: "[RFC] Integrate MbedTLS v3.6 LTS with U-Boot" They are not directly related to MbedTLS integration, but the prerequisite for a few clean-up, refactoring and minor fixes. For V2, the linker script patch is dropped and added one patch to move the snprintf to stdio.h Raymond Mao (4): image: remove redundant hash includes efi_loader: remove redundant hash includes md5: Use typedef for MD5 context include: Move snprintf to stdio.h arch/arc/lib/cpu.c | 2 +- board/Synology/common/legacy.c | 1 + board/ti/common/fdt_ops.c | 2 +- boot/image-fit.c | 4 boot/image.c | 2 -- cmd/part.c | 1 + common/button_cmd.c| 2 +- drivers/cpu/mpc83xx_cpu.c | 2 +- drivers/crypto/hash/hash_sw.c | 8 include/stdio.h| 17 + include/u-boot/md5.h | 10 +- include/vsprintf.h | 17 - lib/display_options.c | 1 + lib/efi_loader/efi_signature.c | 1 - lib/efi_loader/efi_tcg2.c | 3 --- lib/fwu_updates/fwu_mtd.c | 2 +- lib/hexdump.c | 2 +- lib/md5.c | 10 +- lib/vsprintf.c | 1 + test/dm/scmi.c | 2 +- test/print_ut.c| 1 + 21 files changed, 43 insertions(+), 48 deletions(-) -- 2.25.1
Re: [PATCH v3 0/4]
On Sat, 20 Apr 2024 at 10:20, Heinrich Schuchardt wrote: > > On 4/18/24 14:54, Ilias Apalodimas wrote: > > Hi! > > This is v3 of SetVariable at runtime [0] > > > > Nothing changed drastically from v2. > > A few more test cases have been added, comments/suggestions have been > > addressed and a bug where deleting a variable by setting 'attributes' to > > 0 has been fixed. > > > > Changes since v2: > > - Add more selftests checking for variable deletion as well as the > >VarToFile header format > > - Use unaligned sized variables on tests > > - Add a new function to get the variable entry length instead of > >repurposing efi_var_mem_compare() > > - Converted VarToFile to RO > > - Added a few comments requested by Heinrich > > - Fixed a bug where SetVariable with attributes set to 0 did not delete > >the variable but returned EFI_INVALID_PARAMETER instead > > - Run FWTS 'uefitests' and attach the log in patch #1 > > - Added r-b tags from Heinrich > > > > Changes since v1: > > - Instead of Creating VarToFile at SetVariable, create it on GetVariable. > >This allows us to get rid of the preallocated RT buffer, since the > >address is user provided > > - convert Set/GetVariableRT -> Set/GetVariable at runtime > > - return EFI_INVALID_PARAM is NV is not set at runtime > > - Heinrich sent me the efi_var_collect_mem() variant > > > > Changes since the RFC: > > - Return EFI_INVALID_PARAM if attributes are not volatile > > - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables > > - Add 2 EFI variables and allow userspace to write the file > > - Add selftests > > > > I also have a patch enable QueryVariableInfo [1], but I don't want to > > introduce new patches now. This also needs a few more testcases of its > > own so I'll send it once we finalize this one. > > > > [0] > > https://lore.kernel.org/u-boot/20240417101928.119115-1-ilias.apalodi...@linaro.org/T/ > > [1] > > https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/ce35270aaeb93686d7e013f3b028808e8af88cc0 > > > > Regards > > /Ilias > > > > Ilias Apalodimas (4): > >efi_loader: conditionally enable SetvariableRT > >efi_loader: Add OS notifications for SetVariable at runtime > >efi_loader: add an EFI variable with the file contents > >efi_selftest: add tests for setvariableRT > > I am missing a defconfig change which is needed to run the unit test in > Gitlab CI. I would prefer testing this on the sandbox. > > Best regards Ok I'll send a followup since you already sent a PR with these Thanks! /Ilias > > Heinrich > > > > > include/efi_loader.h | 4 + > > include/efi_variable.h| 16 +- > > lib/charset.c | 2 +- > > lib/efi_loader/Kconfig| 16 ++ > > lib/efi_loader/efi_runtime.c | 42 > > lib/efi_loader/efi_var_common.c | 6 +- > > lib/efi_loader/efi_var_mem.c | 151 - > > lib/efi_loader/efi_variable.c | 122 -- > > lib/efi_loader/efi_variable_tee.c | 5 - > > .../efi_selftest_variables_runtime.c | 211 +- > > 10 files changed, 495 insertions(+), 80 deletions(-) > > > > -- > > 2.40.1 > > >
Re: [PATCH v3 0/4]
On 4/18/24 14:54, Ilias Apalodimas wrote: Hi! This is v3 of SetVariable at runtime [0] Nothing changed drastically from v2. A few more test cases have been added, comments/suggestions have been addressed and a bug where deleting a variable by setting 'attributes' to 0 has been fixed. Changes since v2: - Add more selftests checking for variable deletion as well as the VarToFile header format - Use unaligned sized variables on tests - Add a new function to get the variable entry length instead of repurposing efi_var_mem_compare() - Converted VarToFile to RO - Added a few comments requested by Heinrich - Fixed a bug where SetVariable with attributes set to 0 did not delete the variable but returned EFI_INVALID_PARAMETER instead - Run FWTS 'uefitests' and attach the log in patch #1 - Added r-b tags from Heinrich Changes since v1: - Instead of Creating VarToFile at SetVariable, create it on GetVariable. This allows us to get rid of the preallocated RT buffer, since the address is user provided - convert Set/GetVariableRT -> Set/GetVariable at runtime - return EFI_INVALID_PARAM is NV is not set at runtime - Heinrich sent me the efi_var_collect_mem() variant Changes since the RFC: - Return EFI_INVALID_PARAM if attributes are not volatile - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables - Add 2 EFI variables and allow userspace to write the file - Add selftests I also have a patch enable QueryVariableInfo [1], but I don't want to introduce new patches now. This also needs a few more testcases of its own so I'll send it once we finalize this one. [0] https://lore.kernel.org/u-boot/20240417101928.119115-1-ilias.apalodi...@linaro.org/T/ [1] https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/ce35270aaeb93686d7e013f3b028808e8af88cc0 Regards /Ilias Ilias Apalodimas (4): efi_loader: conditionally enable SetvariableRT efi_loader: Add OS notifications for SetVariable at runtime efi_loader: add an EFI variable with the file contents efi_selftest: add tests for setvariableRT I am missing a defconfig change which is needed to run the unit test in Gitlab CI. I would prefer testing this on the sandbox. Best regards Heinrich include/efi_loader.h | 4 + include/efi_variable.h| 16 +- lib/charset.c | 2 +- lib/efi_loader/Kconfig| 16 ++ lib/efi_loader/efi_runtime.c | 42 lib/efi_loader/efi_var_common.c | 6 +- lib/efi_loader/efi_var_mem.c | 151 - lib/efi_loader/efi_variable.c | 122 -- lib/efi_loader/efi_variable_tee.c | 5 - .../efi_selftest_variables_runtime.c | 211 +- 10 files changed, 495 insertions(+), 80 deletions(-) -- 2.40.1
[PATCH v3 0/4]
Hi! This is v3 of SetVariable at runtime [0] Nothing changed drastically from v2. A few more test cases have been added, comments/suggestions have been addressed and a bug where deleting a variable by setting 'attributes' to 0 has been fixed. Changes since v2: - Add more selftests checking for variable deletion as well as the VarToFile header format - Use unaligned sized variables on tests - Add a new function to get the variable entry length instead of repurposing efi_var_mem_compare() - Converted VarToFile to RO - Added a few comments requested by Heinrich - Fixed a bug where SetVariable with attributes set to 0 did not delete the variable but returned EFI_INVALID_PARAMETER instead - Run FWTS 'uefitests' and attach the log in patch #1 - Added r-b tags from Heinrich Changes since v1: - Instead of Creating VarToFile at SetVariable, create it on GetVariable. This allows us to get rid of the preallocated RT buffer, since the address is user provided - convert Set/GetVariableRT -> Set/GetVariable at runtime - return EFI_INVALID_PARAM is NV is not set at runtime - Heinrich sent me the efi_var_collect_mem() variant Changes since the RFC: - Return EFI_INVALID_PARAM if attributes are not volatile - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables - Add 2 EFI variables and allow userspace to write the file - Add selftests I also have a patch enable QueryVariableInfo [1], but I don't want to introduce new patches now. This also needs a few more testcases of its own so I'll send it once we finalize this one. [0] https://lore.kernel.org/u-boot/20240417101928.119115-1-ilias.apalodi...@linaro.org/T/ [1] https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commit/ce35270aaeb93686d7e013f3b028808e8af88cc0 Regards /Ilias Ilias Apalodimas (4): efi_loader: conditionally enable SetvariableRT efi_loader: Add OS notifications for SetVariable at runtime efi_loader: add an EFI variable with the file contents efi_selftest: add tests for setvariableRT include/efi_loader.h | 4 + include/efi_variable.h| 16 +- lib/charset.c | 2 +- lib/efi_loader/Kconfig| 16 ++ lib/efi_loader/efi_runtime.c | 42 lib/efi_loader/efi_var_common.c | 6 +- lib/efi_loader/efi_var_mem.c | 151 - lib/efi_loader/efi_variable.c | 122 -- lib/efi_loader/efi_variable_tee.c | 5 - .../efi_selftest_variables_runtime.c | 211 +- 10 files changed, 495 insertions(+), 80 deletions(-) -- 2.40.1
Re: [PATCH v3 0/4]
On Mon, 11 Mar 2024 21:33:44 +, Volodymyr Babchuk wrote: > Set of pre-req patches for Qualcomm SA8155P-ADP board support. > > This path series consist of generic qcom changes that may benefit > different boards. It is the part of the bigger series that adds > SA8155P-ADP support, but I am posting this limited set because there > are other developers who depend on those changes and I am not ready to > post other patches of the bigger series. > > [...] Applied, thanks! [1/4] qcom: board: validate fdt before trying to use it commit: a1ecfa2371efc68671c66d3e186743f82926a640 [2/4] clk: qcom: clear div mask before assigning a new divider commit: 10f402108a9063d5bc4d517e2a1197afcfabc3a4 [3/4] clk: qcom: add support for power domains uclass commit: 95d76bf4e9a912ee458726a59b1045ecb2eff0cc [4/4] pinctrl: qcom: pass pin number to get_function_mux callback commit: 018b8ab702ce38f79e7d276186565478513880a6 Best regards, -- // Caleb (they/them)
[PATCH v3 0/4]
Set of pre-req patches for Qualcomm SA8155P-ADP board support. This path series consist of generic qcom changes that may benefit different boards. It is the part of the bigger series that adds SA8155P-ADP support, but I am posting this limited set because there are other developers who depend on those changes and I am not ready to post other patches of the bigger series. Changes in v3: - Replaced fdt_valid() with fdt_check_header() - Added "depends POWER_DOMAIN" to Kconfig (see note) - Use readl_poll_timeout() instead of open coded wait loop - Print warning if power domain can't be enabled/disabled Changes in v2: - New patch in v2 - Reworked qcom_cc_bind() function - Added timeout to qcom_power_set() - Minor fixes in register names and formatting Volodymyr Babchuk (4): qcom: board: validate fdt before trying to use it clk: qcom: clear div mask before assigning a new divider clk: qcom: add support for power domains uclass pinctrl: qcom: pass pin number to get_function_mux callback arch/arm/mach-snapdragon/board.c | 5 +- drivers/clk/qcom/Kconfig | 2 +- drivers/clk/qcom/clock-qcom.c | 135 ++--- drivers/clk/qcom/clock-qcom.h | 6 ++ drivers/pinctrl/qcom/pinctrl-apq8016.c | 3 +- drivers/pinctrl/qcom/pinctrl-apq8096.c | 3 +- drivers/pinctrl/qcom/pinctrl-ipq4019.c | 3 +- drivers/pinctrl/qcom/pinctrl-qcom.c| 4 +- drivers/pinctrl/qcom/pinctrl-qcom.h| 3 +- drivers/pinctrl/qcom/pinctrl-qcs404.c | 3 +- drivers/pinctrl/qcom/pinctrl-sdm845.c | 3 +- 11 files changed, 146 insertions(+), 24 deletions(-) -- 2.43.0
[PATCH v3 0/4] phycore-imx8mp: Add USB support
add support for various USB features like USB storage, USB mass storage as well as booting and flashing emmc via UUU. Signed-off-by: Benjamin Hahn --- Changes in v3: - add patch description for the sync with kernel devicetree commit - Link to v2: https://lore.kernel.org/r/20240131-usb_support-v2-0-7521c554b...@phytec.de Changes in v2: - sync kernel devicetree before making changes - Link to v1: https://lore.kernel.org/r/20240129-usb_support-v1-0-8bd2fe840...@phytec.de --- Benjamin Hahn (4): imx8mp-phyboard-pollux-rdk: sync with kernel devicetree from v6.8-rc2 phycore-imx8mp: add USB host support phycore-imx8mp: add USB mass storage support phycore-imx8mp: add support for booting and flashing emmc via UUU .../arm/dts/imx8mp-phyboard-pollux-rdk-u-boot.dtsi | 4 + arch/arm/dts/imx8mp-phyboard-pollux-rdk.dts| 162 - board/phytec/phycore_imx8mp/phycore-imx8mp.c | 4 + configs/phycore-imx8mp_defconfig | 33 - include/configs/phycore_imx8mp.h | 5 + 5 files changed, 204 insertions(+), 4 deletions(-) --- base-commit: 0101a2ffe125911ebf89172b495f5ff14f2fd058 change-id: 20240126-usb_support-403f47d71ac1 Best regards, -- Benjamin Hahn
Re: [PATCH v3 0/4] cmd: bootefi: refactor the code for bootmgr
Hi AKASHI, On Sun, 17 Dec 2023 at 19:39, AKASHI Takahiro wrote: > > This patch set is motivated by the discussion[1] regarding > CONFIG_BOOTEFI_BOOTMGR option. > > # It has been partially merged in -next branch. So this version (v3) > # contains only the remaining commits. > > At the end, bootefi.c will be decomposed into two parts, one for > providing the command itself and one for implementing helper functions. > EFI_LOADER will now be available without CONFIG_CMDLINE or specifically > CONFIG_CMD_BOOTEFI if invoked via bootmeth/bootstd. Great!! > > Then, EFI_LOADER library side will be further split into two options > for fine-grain control: > CONFIG_EFI_BINARY_EXEC: execute UEFI binaries which are to be explicitly > loaded by U-Boot's load commands/functions or other methods > (like a jtag debugger?) > It supports bootmeth_efi as well as "bootefi |hello"(/"bootm"?). > > CONFIG_EFI_BOOTMGR: provide EFI boot manger functionality > It supports bootmeth_efi_mgr as well as "bootefi bootmgr". > > As such, We will no longer need CONFIG_EFI_BINARY_EXEC if we want to only > make use of the UEFI boot manger for booting a next stage OS. > > Prerequisite > > This patch set is based on top of Tom's latest "next" branch. > > Tests > = > * run UT efi_selftest on sandbox locally > * run test_efi_bootmgr on sandbox locally > > Unfortunately, I could not submit a pull request for CI test. > > Changes > === > v3 (Dec 18, 2023) > * rebased onto Tom's latest next branch > * remove already-merged commits > > v2 (Nov 21, 2023) > * rebased onto Tom's next branch > * remove already merged commits > * revise commit messages > * add patch #5 which was split from ex-patch#5 > RFC (Oct 26, 2023) > > [1] https://lists.denx.de/pipermail/u-boot/2023-October/534598.html > > AKASHI Takahiro (4): > efi_loader: split unrelated code from efi_bootmgr.c > efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR > net: tftp: remove explicit efi configuration dependency > fs: remove explicit efi configuration dependency > > boot/Kconfig | 4 +- > boot/Makefile| 2 +- > cmd/Kconfig | 10 +- > cmd/efidebug.c | 4 +- > fs/fs.c | 7 +- > include/efi_loader.h | 28 +- > lib/efi_loader/Kconfig | 11 +- > lib/efi_loader/Makefile | 2 +- > lib/efi_loader/efi_bootmgr.c | 493 -- > lib/efi_loader/efi_device_path.c | 3 +- > lib/efi_loader/efi_helper.c | 499 ++- > net/tftp.c | 10 +- > test/boot/bootflow.c | 2 +- > 13 files changed, 544 insertions(+), 531 deletions(-) > > -- > 2.34.1 > Thanks for doing this work. Regards, Simon
[PATCH v3 0/4] cmd: bootefi: refactor the code for bootmgr
This patch set is motivated by the discussion[1] regarding CONFIG_BOOTEFI_BOOTMGR option. # It has been partially merged in -next branch. So this version (v3) # contains only the remaining commits. At the end, bootefi.c will be decomposed into two parts, one for providing the command itself and one for implementing helper functions. EFI_LOADER will now be available without CONFIG_CMDLINE or specifically CONFIG_CMD_BOOTEFI if invoked via bootmeth/bootstd. Then, EFI_LOADER library side will be further split into two options for fine-grain control: CONFIG_EFI_BINARY_EXEC: execute UEFI binaries which are to be explicitly loaded by U-Boot's load commands/functions or other methods (like a jtag debugger?) It supports bootmeth_efi as well as "bootefi |hello"(/"bootm"?). CONFIG_EFI_BOOTMGR: provide EFI boot manger functionality It supports bootmeth_efi_mgr as well as "bootefi bootmgr". As such, We will no longer need CONFIG_EFI_BINARY_EXEC if we want to only make use of the UEFI boot manger for booting a next stage OS. Prerequisite This patch set is based on top of Tom's latest "next" branch. Tests = * run UT efi_selftest on sandbox locally * run test_efi_bootmgr on sandbox locally Unfortunately, I could not submit a pull request for CI test. Changes === v3 (Dec 18, 2023) * rebased onto Tom's latest next branch * remove already-merged commits v2 (Nov 21, 2023) * rebased onto Tom's next branch * remove already merged commits * revise commit messages * add patch #5 which was split from ex-patch#5 RFC (Oct 26, 2023) [1] https://lists.denx.de/pipermail/u-boot/2023-October/534598.html AKASHI Takahiro (4): efi_loader: split unrelated code from efi_bootmgr.c efi_loader: rename BOOTEFI_BOOTMGR to EFI_BOOTMGR net: tftp: remove explicit efi configuration dependency fs: remove explicit efi configuration dependency boot/Kconfig | 4 +- boot/Makefile| 2 +- cmd/Kconfig | 10 +- cmd/efidebug.c | 4 +- fs/fs.c | 7 +- include/efi_loader.h | 28 +- lib/efi_loader/Kconfig | 11 +- lib/efi_loader/Makefile | 2 +- lib/efi_loader/efi_bootmgr.c | 493 -- lib/efi_loader/efi_device_path.c | 3 +- lib/efi_loader/efi_helper.c | 499 ++- net/tftp.c | 10 +- test/boot/bootflow.c | 2 +- 13 files changed, 544 insertions(+), 531 deletions(-) -- 2.34.1
[PATCH v3 0/4] cmd: acpi: correct handling of DSDT and FACS
Fields X_FIRMWARE and X_DSDT in the FADT table must be 64bit. Fix the definition in our include. The 64bit fields X_FIRMWARE and X_DSDT take precedence over the respective 32bit fields. Consider this in the 'acpi list' and 'acpi dump' commands. The fields only exist for FADT table revision 3 and above. Don't fill unused fields FIRMWAE and DSDT. Write an error if the hardware reduce flag is not set for non-x86 systems. v3: fix subject lines of patches 1 and 4 use map_to_sysmem for pointer to address conversion v2: check FADT table revision correct dumping DSDT and FACS Heinrich Schuchardt (4): acpi: use 64-bit addresses in FADT table cmd: acpi: fix listing DSDT and FACS cmd: acpi: check HW reduced flag in acpi list acpi: support 64bit in acpi_find_table for DSDT and FACS arch/x86/cpu/baytrail/acpi.c | 9 +++-- arch/x86/cpu/quark/acpi.c| 9 +++-- arch/x86/cpu/tangier/acpi.c | 9 +++-- arch/x86/lib/acpi_table.c| 9 ++--- cmd/acpi.c | 12 ++-- include/acpi/acpi_table.h| 6 ++ lib/acpi/acpi.c | 29 - 7 files changed, 47 insertions(+), 36 deletions(-) -- 2.40.1
Re: [PATCH v3 0/4] bootm: Handle compressed arm64 images with bootm
On Sun, 19 Nov 2023 07:43:30 -0700, Simon Glass wrote: > This little series corrects a problem I noticed with arm64 images, > where the kernel is not recognised if compression is used: > >U-Boot> tftp image.fit >Using ethernet@7d58 device >TFTP from server 192.168.4.7; our IP address is 192.168.4.147 >Filename 'image.fit'. >Load address: 0x100 >Loading: ## 23 MiB >20.5 MiB/s >done >Bytes transferred = 24118272 (1700400 hex) >U-Boot> bootm >## Loading kernel from FIT Image at 0100 ... > Using 'conf-768' configuration > Trying 'kernel' kernel subimage > Description: Linux > Type: Kernel Image (no loading done) > Compression: gzip compressed > Data Start: 0x01000120 > Data Size:13662338 Bytes = 13 MiB > Verifying Hash Integrity ... OK >Bad Linux ARM64 Image magic! > > [...] Applied to u-boot/next, thanks! -- Tom
[PATCH v3 0/4] Add DFU and usb boot for TI am62x
Previous version of this patchset went out back in April and got delayed for various reasons. As some parts were merge this is a somewhat smaller set then before. Patches against u-boot/next to take advantage of the latest dts sync from linux v6.7-rc1 0: https://lists.denx.de/pipermail/u-boot/2023-April/514642.html Changes in v3: - Add dfu via environment rather then config headers - Enable usb nodes in all boot phases - Run savedefconfig to adjust to more recent u-boot Changes in v2: - Switch dwc3 glue to a seperate driver rather then in dwc-generic - Minimize config changes to just DFU configuration - Only enable usb port 0 DFU in SPL - Create a seperate defconfig for R5 Sjoerd Simons (4): usb: dwc3: Add dwc3 glue driver for am62 board: ti: am62x: am62x: include env for DFU arm: dts: k3-am625-sk: Enable usb ports in u-boot configs: am62x_evm_*: Enable USB and DFU support arch/arm/dts/k3-am625-sk-u-boot.dtsi | 9 ++ board/ti/am62x/am62x.env | 1 + configs/am62x_evm_a53_defconfig | 31 ++- configs/am62x_evm_r5_usbdfu_defconfig | 111 +++ drivers/usb/dwc3/Kconfig | 14 +++ drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-am62.c | 125 ++ 7 files changed, 291 insertions(+), 1 deletion(-) create mode 100644 configs/am62x_evm_r5_usbdfu_defconfig create mode 100644 drivers/usb/dwc3/dwc3-am62.c -- 2.43.0
[PATCH v3 0/4] bootm: Handle compressed arm64 images with bootm
This little series corrects a problem I noticed with arm64 images, where the kernel is not recognised if compression is used: U-Boot> tftp image.fit Using ethernet@7d58 device TFTP from server 192.168.4.7; our IP address is 192.168.4.147 Filename 'image.fit'. Load address: 0x100 Loading: ## 23 MiB 20.5 MiB/s done Bytes transferred = 24118272 (1700400 hex) U-Boot> bootm ## Loading kernel from FIT Image at 0100 ... Using 'conf-768' configuration Trying 'kernel' kernel subimage Description: Linux Type: Kernel Image (no loading done) Compression: gzip compressed Data Start: 0x01000120 Data Size:13662338 Bytes = 13 MiB Verifying Hash Integrity ... OK Bad Linux ARM64 Image magic! With this series: U-Boot> tftp 2000 image.fit Using ethernet@7d58 device TFTP from server 192.168.4.7; our IP address is 192.168.4.147 Filename 'image.fit'. Load address: 0x2000 Loading: ## 23.5 MiB 20.8 MiB/s done Bytes transferred = 24642560 (1780400 hex) U-Boot> bootm 0x2000 ## Loading kernel from FIT Image at 2000 ... Using 'conf-768' configuration Trying 'kernel' kernel subimage Description: Linux Type: Kernel Image (no loading done) Compression: zstd compressed Data Start: 0x2120 Data Size:14333475 Bytes = 13.7 MiB Verifying Hash Integrity ... OK Using kernel load address 8 ## Loading fdt from FIT Image at 2000 ... Using 'conf-768' configuration Trying 'fdt-768' fdt subimage Description: Raspberry Pi 4 Model B Type: Flat Device Tree Compression: zstd compressed Data Start: 0x215f820c Data Size:9137 Bytes = 8.9 KiB Architecture: AArch64 Verifying Hash Integrity ... OK Uncompressing Flat Device Tree to 3aff3010 Booting using the fdt blob at 0x3aff3010 Working FDT set to 3aff3010 Uncompressing Kernel Image (no loading done) to 8 Moving Image from 0x8 to 0x20, end=2b0 Using Device Tree in place at 3aff3010, end 3afff4c4 Working FDT set to 3aff3010 Starting kernel ... [0.00] Booting Linux on physical CPU 0x00 [0x410fd083] The problem is that the arm64 magic is checked before the image is decompressed. However this is only part of it. The kernel_noload image type doesn't work with compression, since the kernel is not loaded. So this series deals with that by using an lmb-allocated buffer for the uncompressed kernel. Another issue is that the arm64 handling is done too early, before the image is loaded. This series moves it to after loading, so that compression can be handled. A patch is included to show the kernel load-address, so it is easy to see what is going on. One annoying feature of arm64 is that the image is often copied to another address. It might be possible for U-Boot to figure that out earlier and decompress it to the right place, but perhaps not. With all of this it should be possible to boot a compressed kernel on any of the 990 arm64 boards supported by Linux, although I have only tested two. Changes in v3: - Rebase on to bootm-refactoring series - Support compression with an lmb-allocated region - Drop patch to disallow kernel_noload with compression - Drop patch 'bootm: Allow omitting the load address' Changes in v2: - Rework the patch based on a better understanding of events - Add a 'success' case to the cover letter - Redo how the arm64 support is implemented Simon Glass (4): image: Correct load_bug typo image: Show the load address when decompressing bootm: Move arm64-image processing later bootm: Support kernel_noload with compression boot/bootm.c| 63 +++-- boot/image.c| 13 ++ include/image.h | 2 +- 3 files changed, 55 insertions(+), 23 deletions(-) -- 2.43.0.rc0.421.g78406f8d94-goog
[PATCH v3 0/4] bootflow: bootmeth_efi: Fix network efi boot.
Currently bootmeth_efi crashes while doing a network (dhcp) boot. This patch series fixes issues and both network and disk boot works. Shantur Rathore (4): bootflow: bootmeth_efi: Set bootp_arch as hex bootflow: bootmeth_efi: set bflow->fname from bootfile name bootflow: bootmeth_efi: Handle fdt not available. bootflow: bootmeth_efi: don't free buffer boot/bootmeth_efi.c | 36 +++- include/bootflow.h | 2 ++ 2 files changed, 29 insertions(+), 9 deletions(-) -- 2.40.1
Re: [PATCH v3 0/4] arm: mach-snapdragon: Qualcomm pinctrl driver cleanup
On Tue, 14 Nov 2023 12:55:39 +, Caleb Connolly wrote: > This series moves the Qualcomm pinctrl drivers from mach-snapdragon and > mach-ipq40xx to drivers/pinctrl/qcom. It then makes the necessary changes > to enable compatibility with Linux DTs. > > The pinctrl hardware on most Qualcomm platforms is made up of "tiles", > these are just banks of pins at different register addresses. The > mapping between pin number and tile is totally arbitrary, this > unfortunately means that it is necessary to have a map of pin to tile in > order to support all pins. Up until now this driver has ignored tiles, > meaning that the pin numbers and DT nodes are entirely different to the > Linux DT and only a subset of pins are addressable. > > [...] Applied, thanks! [1/4] pinctrl: qcom: move out of mach-snapdragon commit: b009e7e619d35043e9dc347999227447c8de0134 [2/4] pinctrl: qcom: move ipq4019 driver from mach-ipq40xx commit: 75ac9c61b973b96b3b6a81a7e294c195c71a212f [3/4] pinctrl: qcom: make compatible with linux DTs commit: a5764aeb78679b475e97a12a9711bb07e517cfb3 [4/4] msm_gpio: use unsigned int commit: e319539a061e4cfc665907b4afcb57afd5c4e0a5 Best regards, -- // Caleb (they/them)
[PATCH v3 0/4] arm: mach-snapdragon: Qualcomm pinctrl driver cleanup
This series moves the Qualcomm pinctrl drivers from mach-snapdragon and mach-ipq40xx to drivers/pinctrl/qcom. It then makes the necessary changes to enable compatibility with Linux DTs. The pinctrl hardware on most Qualcomm platforms is made up of "tiles", these are just banks of pins at different register addresses. The mapping between pin number and tile is totally arbitrary, this unfortunately means that it is necessary to have a map of pin to tile in order to support all pins. Up until now this driver has ignored tiles, meaning that the pin numbers and DT nodes are entirely different to the Linux DT and only a subset of pins are addressable. Patch 2 solves this by introducing the pin_offset map, initially supporting SDM845. This map is used for all pin register lookups for both the pinctrl and GPIO drivers. Similarly to the clock/reset drivers these are both associated with a single DT node, where the pinctrl driver is responsible for binding the GPIO drivers. Patch 3 introduces support for gpio-reserved-ranges, this property is used on some boards to mark pin ranges that shouldn't be touched (else firmware will trigger a fault and reset the board). This series loosely depends on the associated clock driver cleanup which can be found here (Makefile and perhaps DTS conflicts): https://lore.kernel.org/u-boot/20231103-b4-qcom-clk-v3-0-8d2d460ec...@linaro.org --- Changes in v3: * Fix header in msm_gpio.c * Link to v2: https://lore.kernel.org/r/20231106-b4-qcom-pinctrl-v2-0-406e8d868...@linaro.org Changes in v2: * Drop msm -> qcom rename (will be handled in a future patch) * Drop "handle reserved ranges" patch to be introduced alongside a user * Re-order APQ4019 move to be the second patch * Change driver name to pinctrl_qcom instead of qcom_pinctrl * Add MAINTAINERS entry * Move shared GPIO header to mach-snapdragon * Link to v1: https://lore.kernel.org/r/20231025-b4-qcom-pinctrl-v1-0-9123d6a21...@linaro.org --- Caleb Connolly (4): pinctrl: qcom: move out of mach-snapdragon pinctrl: qcom: move ipq4019 driver from mach-ipq40xx pinctrl: qcom: make compatible with linux DTs msm_gpio: use unsigned int MAINTAINERS| 1 + arch/arm/Kconfig | 1 + arch/arm/dts/dragonboard845c-uboot.dtsi| 2 +- arch/arm/dts/sdm845.dtsi | 16 +- arch/arm/dts/starqltechn-uboot.dtsi| 5 +- arch/arm/dts/starqltechn.dts | 16 +- arch/arm/mach-ipq40xx/Makefile | 8 - arch/arm/mach-ipq40xx/pinctrl-snapdragon.c | 166 - arch/arm/mach-snapdragon/Kconfig | 4 + arch/arm/mach-snapdragon/Makefile | 5 - arch/arm/mach-snapdragon/include/mach/gpio.h | 28 +++- arch/arm/mach-snapdragon/pinctrl-sdm845.c | 44 -- arch/arm/mach-snapdragon/pinctrl-snapdragon.h | 33 drivers/gpio/msm_gpio.c| 42 +++--- drivers/pinctrl/Kconfig| 1 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/qcom/Kconfig | 46 ++ drivers/pinctrl/qcom/Makefile | 10 ++ .../pinctrl/qcom}/pinctrl-apq8016.c| 21 ++- .../pinctrl/qcom}/pinctrl-apq8096.c| 21 ++- .../pinctrl/qcom}/pinctrl-ipq4019.c| 25 +++- .../pinctrl/qcom/pinctrl-qcom.c| 70 + .../pinctrl/qcom/pinctrl-qcom.h| 15 +- .../pinctrl/qcom}/pinctrl-qcs404.c | 21 ++- drivers/pinctrl/qcom/pinctrl-sdm845.c | 100 + 25 files changed, 350 insertions(+), 352 deletions(-) --- base-commit: 8c5e4ddf52ea3c1e85c44cdd5d5b2e2f6c892b4f // Caleb (they/them)
Re: [PATCH v3 0/4] sunxi: SPL FIT support for 32-bit sunxi SoCs
On Tue, Oct 31, 2023 at 1:18 AM Samuel Holland wrote: > > This series makes the necessary changes so 32-bit sunxi SoCs can load > additional device trees or firmware from SPL along with U-Boot proper. > Crust (SCP firmware) has support for A33 and H3, and H3 also needs to > load an eGon blob to support CPU 0 hotplug (a silicon bug workaround). > > FIT unlocks more features (signatures, multiple DTBs, etc.), so enable > it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs > SPL_FIT_IMAGE_TINY. For consistency, enable that option everywhere. > > After this series is applied, we can increase SPL_MAX_SIZE for H6 and > newer SoCs, both 32-bit (e.g. A50, T113) and 64-bit. I did not do that > yet because there is some discussion to be had about the correct value: > it must be adjusted to guarantee return-to-FEL functionality, and the > exact adjustment depends on the sunxi-fel tool implementation. > > Changes in v3: > - Rebased and collected tags > > Changes in v2: > - Disable padding from SPL_PAD_TO > - Rely on binman min-size instead of using explicit offsets > - Use Kconfig for firmware addresses instead of an #ifdef staircase > > Samuel Holland (4): > sunxi: spl: Disable padding from SPL_PAD_TO > sunxi: binman: Move BL31 and SCP firmware addresses to Kconfig > sunxi: binman: Support FIT generation for 32-bit SoCs > sunxi: Enable SPL FIT loading for 32-bit SoCs > > arch/arm/Kconfig | 1 + > arch/arm/dts/sunxi-u-boot.dtsi | 39 ++ > arch/arm/mach-sunxi/Kconfig| 17 +++ > common/spl/Kconfig | 6 ++ > 4 files changed, 41 insertions(+), 22 deletions(-) > > -- > 2.41.0 > Acked-by: Jesse Taube Looks good!
[PATCH v3 0/4] sunxi: SPL FIT support for 32-bit sunxi SoCs
This series makes the necessary changes so 32-bit sunxi SoCs can load additional device trees or firmware from SPL along with U-Boot proper. Crust (SCP firmware) has support for A33 and H3, and H3 also needs to load an eGon blob to support CPU 0 hotplug (a silicon bug workaround). FIT unlocks more features (signatures, multiple DTBs, etc.), so enable it by default. A10 (sun4i) only has 24 KiB of SRAM A1, so it needs SPL_FIT_IMAGE_TINY. For consistency, enable that option everywhere. After this series is applied, we can increase SPL_MAX_SIZE for H6 and newer SoCs, both 32-bit (e.g. A50, T113) and 64-bit. I did not do that yet because there is some discussion to be had about the correct value: it must be adjusted to guarantee return-to-FEL functionality, and the exact adjustment depends on the sunxi-fel tool implementation. Changes in v3: - Rebased and collected tags Changes in v2: - Disable padding from SPL_PAD_TO - Rely on binman min-size instead of using explicit offsets - Use Kconfig for firmware addresses instead of an #ifdef staircase Samuel Holland (4): sunxi: spl: Disable padding from SPL_PAD_TO sunxi: binman: Move BL31 and SCP firmware addresses to Kconfig sunxi: binman: Support FIT generation for 32-bit SoCs sunxi: Enable SPL FIT loading for 32-bit SoCs arch/arm/Kconfig | 1 + arch/arm/dts/sunxi-u-boot.dtsi | 39 ++ arch/arm/mach-sunxi/Kconfig| 17 +++ common/spl/Kconfig | 6 ++ 4 files changed, 41 insertions(+), 22 deletions(-) -- 2.41.0
[PATCH v3 0/4] fix npcm bmc error
1. add name for gpio pinctrl function 2. add baud rate table 3. fix ecc ram size 4. modify configs Jim Liu (4): pinctrl: npcm8xx: add name for gpio function configs: npcm: support more uart baud rate board: nuvuton: arbel: fix incorrect ram size configs: nuvoton: npcm8xx: disable CONFIG_SPI_FLASH_USE_4K_SECTORS board/nuvoton/arbel_evb/arbel_evb.c | 17 + configs/arbel_evb_defconfig | 1 + drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c | 1 + include/configs/arbel.h | 5 - include/configs/poleg.h | 2 ++ 5 files changed, 17 insertions(+), 9 deletions(-) -- 2.34.1
[PATCH v3 0/4] Conclusive KSTR-SAMA5D27 support
Hi all, this is v3 of the Conclusive KSTR-SAMA5D27 support series. Patch [1/4] now takes a different approach at reading the EEPROM serial. An existing CONFIG_ID_EEPROM option provides a mechanism for reading EEPROM embedded MAC addresses at init. As this option is meant for reading various identifying features, not just MACs, I've decided to expand it by the ability of reading serial number, adding a generic serial_read_from_eeprom(). For tlv eeprom, this wraps around existing populate_serial_number(), which now becomes local to tlv_eeprom.c. Other boards which enable CONFIG_ID_EEPROM, but don't store EEPROM data as tlv, will need to provide their own implementations of serial_read_from_eeprom(). A dummy weak function has been provided to prevent compilation issues on such boards. Simon, you've already accepted the solution from v2, however changes required for [4/4] have forced me to go with this new approach. Patch [2/4] is new. CONFIG_ID_EEPROM requires that the do_mac() command exists, however implementation of this function has been missing from tlv_eeprom. This patch adds a bare minimum support for it - only handling the "mac read" flag. KSTR-SAMA5D27 is supposed to use EEPROM embedded MAC addresses, however this feature has been overlooked in previous versions of this series. Patch [3/4] remains unchanged. Patch [4/4] now uses CONFIG_DISPLAY_BOARDINFO_LATE in order to display the board model and S/N. As a side effect of that, serial access has been moved to CONFIG_ID_EEPROM (see patch [1/4]) and BOARD_LATE_INIT mechanism dropped as unnecessary. The kstr_sama5d27_defconfig has also been re-generated with savedefconfig, which got rid of some redundant flags. Artur Rojek (4): common: Add generic function for reading serial number cmd: tlv_eeprom: Add support for do_mac() command arm: dts: at91: sama5: Add flexcom4 node board: Add support for Conclusive KSTR-SAMA5D27 arch/arm/dts/Makefile | 3 + arch/arm/dts/at91-kstr-sama5d27.dts | 131 ++ arch/arm/dts/sama5d2.dtsi | 20 ++ arch/arm/mach-at91/Kconfig| 12 + board/conclusive/kstr-sama5d27/Kconfig| 15 ++ board/conclusive/kstr-sama5d27/MAINTAINERS| 8 + board/conclusive/kstr-sama5d27/Makefile | 5 + .../conclusive/kstr-sama5d27/kstr-sama5d27.c | 230 ++ cmd/tlv_eeprom.c | 76 -- common/board_r.c | 8 + configs/kstr_sama5d27_defconfig | 74 ++ include/configs/kstr-sama5d27.h | 15 ++ include/init.h| 14 ++ 13 files changed, 595 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts create mode 100644 board/conclusive/kstr-sama5d27/Kconfig create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS create mode 100644 board/conclusive/kstr-sama5d27/Makefile create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c create mode 100644 configs/kstr_sama5d27_defconfig create mode 100644 include/configs/kstr-sama5d27.h -- 2.42.0
Re: [PATCH v3 0/4] malloc: Reduce size by initializing data at runtime
On 10/1/23 21:16, Simon Glass wrote:
Hi Sean,
On Thu, 28 Sept 2023 at 08:45, Sean Anderson wrote:
In my efforts to get SPL to fit into flash after some changes I made, I
noticed that av_ is one of the largest variables in SPL. As it turns
out, we can generate it at runtime, and the code is already there. This
has the potential to save 1-2k across the board, for some (very) minor
boot time increase.
This series is based on [1], since this makes checking for SYS_MALLOC_F
easier. Passing CI at [2].
To measure the boot time difference, I applied the following patch:
---
common/board_r.c | 5 +
common/spl/spl.c | 4
2 files changed, 9 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 58a5986aa54..ca624b20d46 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -194,6 +194,7 @@ static int initr_barrier(void)
return 0;
}
+static ulong malloc_begin, malloc_end;
static int initr_malloc(void)
{
ulong malloc_start;
@@ -208,8 +209,10 @@ static int initr_malloc(void)
* reserve_noncached().
*/
malloc_start = gd->relocaddr - TOTAL_MALLOC_LEN;
+ malloc_begin = timer_get_boot_us();
Perhaps this would be better done with bootstage, since then the
timing can be enabled / disabled, and reported along with other
timings.
I'll try that out next time.
mem_malloc_init((ulong)map_sysmem(malloc_start, TOTAL_MALLOC_LEN),
TOTAL_MALLOC_LEN);
+ malloc_end = timer_get_boot_us();
gd->flags |= GD_FLG_FULL_MALLOC_INIT;
return 0;
}
@@ -570,6 +573,8 @@ static int dm_announce(void)
static int run_main_loop(void)
{
+ printf("malloc_init took %luus (%lu %lu)\n", malloc_end - malloc_begin,
+ malloc_begin, malloc_end);
#ifdef CONFIG_SANDBOX
sandbox_main_loop_init();
#endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index d74acec10b5..b34d1f4b4e6 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -755,7 +755,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_set_bd();
#if defined(CONFIG_SYS_SPL_MALLOC)
+ ulong malloc_begin = timer_get_boot_us();
mem_malloc_init(SYS_SPL_MALLOC_START, CONFIG_SYS_SPL_MALLOC_SIZE);
+ ulong malloc_end = timer_get_boot_us();
gd->flags |= GD_FLG_FULL_MALLOC_INIT;
#endif
if (!(gd->flags & GD_FLG_SPL_INIT)) {
@@ -817,6 +819,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_image.boot_device = BOOT_DEVICE_NONE;
board_boot_order(spl_boot_list);
+ printf("malloc_init took %luus (%lu %lu)\n", malloc_end - malloc_begin,
+ malloc_begin, malloc_end);
debug() ?
Well, this is not going to be applied, so I used the easiest thing :)
--Sean
ret = boot_from_devices(_image, spl_boot_list,
ARRAY_SIZE(spl_boot_list));
if (ret) {
--
2.25.1
I found that MALLOC_CLEAR_ON_INIT dominated the mem_malloc_init time
(taking around 150 ms in SPL on my board). After disabling it, I found
that MALLOC_RUNTIME_INIT took around 5 us on average.
[1] https://lore.kernel.org/u-boot/20230926141514.2101787-1-...@chromium.org/
[2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/17900
Changes in v3:
- Use CONFIG_IS_ENABLED in conditionals
- Don't enable SPL_SYS_MALLOC_RUNTIME_INIT if we are short on BSS
Changes in v2:
- Only mark malloc initialized after mem_malloc_init
- Fix cALLOc condition
Sean Anderson (4):
common: Only mark malloc initialized after mem_malloc_init
malloc: Don't use ifdefs for SYS_MALLOC_DEFAULT_TO_INIT
malloc: Don't statically initialize av_ if using malloc_init
malloc: Enable SYS_MALLOC_RUNTIME_INIT by default in SPL
Kconfig | 27 +--
common/board_r.c | 3 ++-
common/dlmalloc.c | 16
3 files changed, 27 insertions(+), 19 deletions(-)
--
2.35.1.1320.gc452695387.dirty
REgards,
SImon
Re: [PATCH v3 0/4] malloc: Reduce size by initializing data at runtime
Hi Sean,
On Thu, 28 Sept 2023 at 08:45, Sean Anderson wrote:
>
> In my efforts to get SPL to fit into flash after some changes I made, I
> noticed that av_ is one of the largest variables in SPL. As it turns
> out, we can generate it at runtime, and the code is already there. This
> has the potential to save 1-2k across the board, for some (very) minor
> boot time increase.
>
> This series is based on [1], since this makes checking for SYS_MALLOC_F
> easier. Passing CI at [2].
>
> To measure the boot time difference, I applied the following patch:
>
> ---
> common/board_r.c | 5 +
> common/spl/spl.c | 4
> 2 files changed, 9 insertions(+)
>
> diff --git a/common/board_r.c b/common/board_r.c
> index 58a5986aa54..ca624b20d46 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -194,6 +194,7 @@ static int initr_barrier(void)
> return 0;
> }
>
> +static ulong malloc_begin, malloc_end;
> static int initr_malloc(void)
> {
> ulong malloc_start;
> @@ -208,8 +209,10 @@ static int initr_malloc(void)
> * reserve_noncached().
> */
> malloc_start = gd->relocaddr - TOTAL_MALLOC_LEN;
> + malloc_begin = timer_get_boot_us();
Perhaps this would be better done with bootstage, since then the
timing can be enabled / disabled, and reported along with other
timings.
> mem_malloc_init((ulong)map_sysmem(malloc_start, TOTAL_MALLOC_LEN),
> TOTAL_MALLOC_LEN);
> + malloc_end = timer_get_boot_us();
> gd->flags |= GD_FLG_FULL_MALLOC_INIT;
> return 0;
> }
> @@ -570,6 +573,8 @@ static int dm_announce(void)
>
> static int run_main_loop(void)
> {
> + printf("malloc_init took %luus (%lu %lu)\n", malloc_end -
> malloc_begin,
> + malloc_begin, malloc_end);
> #ifdef CONFIG_SANDBOX
> sandbox_main_loop_init();
> #endif
> diff --git a/common/spl/spl.c b/common/spl/spl.c
> index d74acec10b5..b34d1f4b4e6 100644
> --- a/common/spl/spl.c
> +++ b/common/spl/spl.c
> @@ -755,7 +755,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> spl_set_bd();
>
> #if defined(CONFIG_SYS_SPL_MALLOC)
> + ulong malloc_begin = timer_get_boot_us();
> mem_malloc_init(SYS_SPL_MALLOC_START, CONFIG_SYS_SPL_MALLOC_SIZE);
> + ulong malloc_end = timer_get_boot_us();
> gd->flags |= GD_FLG_FULL_MALLOC_INIT;
> #endif
> if (!(gd->flags & GD_FLG_SPL_INIT)) {
> @@ -817,6 +819,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
> spl_image.boot_device = BOOT_DEVICE_NONE;
> board_boot_order(spl_boot_list);
>
> + printf("malloc_init took %luus (%lu %lu)\n", malloc_end -
> malloc_begin,
> + malloc_begin, malloc_end);
debug() ?
> ret = boot_from_devices(_image, spl_boot_list,
> ARRAY_SIZE(spl_boot_list));
> if (ret) {
> --
> 2.25.1
>
> I found that MALLOC_CLEAR_ON_INIT dominated the mem_malloc_init time
> (taking around 150 ms in SPL on my board). After disabling it, I found
> that MALLOC_RUNTIME_INIT took around 5 us on average.
>
> [1] https://lore.kernel.org/u-boot/20230926141514.2101787-1-...@chromium.org/
> [2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/17900
>
> Changes in v3:
> - Use CONFIG_IS_ENABLED in conditionals
> - Don't enable SPL_SYS_MALLOC_RUNTIME_INIT if we are short on BSS
>
> Changes in v2:
> - Only mark malloc initialized after mem_malloc_init
> - Fix cALLOc condition
>
> Sean Anderson (4):
> common: Only mark malloc initialized after mem_malloc_init
> malloc: Don't use ifdefs for SYS_MALLOC_DEFAULT_TO_INIT
> malloc: Don't statically initialize av_ if using malloc_init
> malloc: Enable SYS_MALLOC_RUNTIME_INIT by default in SPL
>
> Kconfig | 27 +--
> common/board_r.c | 3 ++-
> common/dlmalloc.c | 16
> 3 files changed, 27 insertions(+), 19 deletions(-)
>
> --
> 2.35.1.1320.gc452695387.dirty
>
REgards,
SImon
[PATCH v3 0/4] Allwinner R528/T113s PSCI
Hi list,
This is the third version of my patchset for supporting PSCI on
R528/T113-s3. It is meant to be applied atop Andre Przywara's T113s support
series (v2). For convenience, the latter exists in a Git branch at:
https://source.denx.de/u-boot/custodians/u-boot-sunxi.git t113s-v2
It's looking like we're very close to finished here. The only "controversy"
that I expect is that patch 4/4 defines CFG_ARM_GIC_BASE_ADDRESS in
sunxi-common.h. There has previously been discussion about moving this to
Kconfig. I agree that this is a good change in principle, but I don't have the
available cycles to look into adding another Kconfig symbol (and cleaning up
Arndale, the other target which uses this) and so have opted to defer that
cleanup for another day.
For testing: I can confirm that patch 2/4 results in no change to machine code
whatsoever on any supported target. Patch 1/4 results in a minor machine code
change on R40 only. Patch 3/4 will likely require testing on each of the 4
"special case" sunxi targets (sun6i, sun7i, R40, H3) to ensure that register
offsets are kept consistent. Patch 4/4 needs testing on R528 only.
Changes v2->v3:
- Fix missing `cpu=0;` for the sun7i power management case.
- Make sunxi_cpu_power_off() a static function, per feedback on v2.
- Kevin Amadiva of MEC electronics got in touch with me off-list, reported
success bringing up CPU1 of a T113 with this patchset, and kindly provided
me with a Tested-by tag for patch 4/4.
- Remove a comment about R40/R528 being special, per feedback on v2.
- Simplify an if statement, per feedback on v2.
- Add missing 'select' directives to the R528 Kconfig, per feedback on v2.
Changes v1->v2:
- Power clamp is now adjusted ONLY on sun{6,7}i, H3, R40. The previous version
was mistakenly doing this EXCEPT on those machines.
- Flattened sunxi_power_switch() into sunxi_cpu_set_power() for simplicity's
sake.
- Moved the "power clamp is not NULL" conditional into sunxi_cpu_set_power().
- Removed unnecessary H6 special-case, since H6 is actually ARM64.
- Renamed SUNXI_CPUX_BASE to SUNXI_CPUCFG_BASE, to mirror expected changes in
Andre's v2 of the R528 series (we decided against using a new name for this
block).
- Removed sunxi_cpucfg_reg struct, and stopped using the PRCM struct in psci.c.
Happy Saturday all,
Sam
Sam Edwards (4):
sunxi: psci: clean away preprocessor macros
sunxi: psci: refactor register access to separate functions
sunxi: psci: stop modeling register layout with C structs
sunxi: psci: implement PSCI on R528
arch/arm/cpu/armv7/sunxi/psci.c | 185 ++-
arch/arm/include/asm/arch-sunxi/cpucfg.h | 67
arch/arm/mach-sunxi/Kconfig | 4 +
include/configs/sunxi-common.h | 8 +
4 files changed, 127 insertions(+), 137 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg.h
--
2.41.0
[PATCH v3 0/4] malloc: Reduce size by initializing data at runtime
In my efforts to get SPL to fit into flash after some changes I made, I
noticed that av_ is one of the largest variables in SPL. As it turns
out, we can generate it at runtime, and the code is already there. This
has the potential to save 1-2k across the board, for some (very) minor
boot time increase.
This series is based on [1], since this makes checking for SYS_MALLOC_F
easier. Passing CI at [2].
To measure the boot time difference, I applied the following patch:
---
common/board_r.c | 5 +
common/spl/spl.c | 4
2 files changed, 9 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 58a5986aa54..ca624b20d46 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -194,6 +194,7 @@ static int initr_barrier(void)
return 0;
}
+static ulong malloc_begin, malloc_end;
static int initr_malloc(void)
{
ulong malloc_start;
@@ -208,8 +209,10 @@ static int initr_malloc(void)
* reserve_noncached().
*/
malloc_start = gd->relocaddr - TOTAL_MALLOC_LEN;
+ malloc_begin = timer_get_boot_us();
mem_malloc_init((ulong)map_sysmem(malloc_start, TOTAL_MALLOC_LEN),
TOTAL_MALLOC_LEN);
+ malloc_end = timer_get_boot_us();
gd->flags |= GD_FLG_FULL_MALLOC_INIT;
return 0;
}
@@ -570,6 +573,8 @@ static int dm_announce(void)
static int run_main_loop(void)
{
+ printf("malloc_init took %luus (%lu %lu)\n", malloc_end - malloc_begin,
+ malloc_begin, malloc_end);
#ifdef CONFIG_SANDBOX
sandbox_main_loop_init();
#endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index d74acec10b5..b34d1f4b4e6 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -755,7 +755,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_set_bd();
#if defined(CONFIG_SYS_SPL_MALLOC)
+ ulong malloc_begin = timer_get_boot_us();
mem_malloc_init(SYS_SPL_MALLOC_START, CONFIG_SYS_SPL_MALLOC_SIZE);
+ ulong malloc_end = timer_get_boot_us();
gd->flags |= GD_FLG_FULL_MALLOC_INIT;
#endif
if (!(gd->flags & GD_FLG_SPL_INIT)) {
@@ -817,6 +819,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_image.boot_device = BOOT_DEVICE_NONE;
board_boot_order(spl_boot_list);
+ printf("malloc_init took %luus (%lu %lu)\n", malloc_end - malloc_begin,
+ malloc_begin, malloc_end);
ret = boot_from_devices(_image, spl_boot_list,
ARRAY_SIZE(spl_boot_list));
if (ret) {
--
2.25.1
I found that MALLOC_CLEAR_ON_INIT dominated the mem_malloc_init time
(taking around 150 ms in SPL on my board). After disabling it, I found
that MALLOC_RUNTIME_INIT took around 5 us on average.
[1] https://lore.kernel.org/u-boot/20230926141514.2101787-1-...@chromium.org/
[2] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/17900
Changes in v3:
- Use CONFIG_IS_ENABLED in conditionals
- Don't enable SPL_SYS_MALLOC_RUNTIME_INIT if we are short on BSS
Changes in v2:
- Only mark malloc initialized after mem_malloc_init
- Fix cALLOc condition
Sean Anderson (4):
common: Only mark malloc initialized after mem_malloc_init
malloc: Don't use ifdefs for SYS_MALLOC_DEFAULT_TO_INIT
malloc: Don't statically initialize av_ if using malloc_init
malloc: Enable SYS_MALLOC_RUNTIME_INIT by default in SPL
Kconfig | 27 +--
common/board_r.c | 3 ++-
common/dlmalloc.c | 16
3 files changed, 27 insertions(+), 19 deletions(-)
--
2.35.1.1320.gc452695387.dirty
Re: [PATCH v3 0/4] support for booting the compressed U-boot binary on Rockchip based ARM64 SOC's
Hi, On 2023-09-10 20:24, Manoj Sai wrote: > This patchset adds the support on Rockchip based ARM64 SOC's that compress > the U-BOOT proper along with dtb > and ATF in FIT image format.Second stage bootloader(SPL) loads the compressed > binaries, uncompress > them and handover control to the next stage. > > Changes for V3 :- > > 1. Replaced spl_decompression_enabled() function instead of checking > IS_ENABLED(CONFIG_SPL_GZIP) >and IS_ENABLED(CONFIG_SPL_LZMA) in spl_fit.c > > 2. Removed extra wrapping parentheses in spl_decompression_enabled(). > > Size Comparision between compressed and uncompressed binaries :- > >size of uncompressed binary:- 9.0M (94,21,824 bytes) > manoj:u-boot$ ls -lb u-boot-rockchip.bin > -rw-rw-r-- 1 manoj manoj 9421824 Sep 10 22:22 u-boot-rockchip.bin > >size of GZIP compressed binary :- 8.6M (89,85,088 bytes) > manoj:u-boot$ ls -lb u-boot-rockchip.bin > -rw-rw-r-- 1 manoj manoj 8985088 Jul 25 07:42 u-boot-rockchip.bin > >size of LZMA compressed binary :- 8.6 M (90,06,592 bytes) > manoj:u-boot$ ls -lb u-boot-rockchip.bin > -rw-rw-r-- 1 manoj manoj 9006592 Jul 25 07:47 u-boot-rockchip.bin > > Test results of Booting time using bootstage command in Uboot command prompt > on roc-rk3399-pc board :- > > 1) Uncompressed U-BOOT : Total boot time ≈ 12.063971 seconds > => bootstage report > Timer summary in microseconds (10 records): >MarkElapsed Stage > 0 0 reset > 1,833,884 1,833,884 board_init_f > 2,959,528 1,125,644 board_init_r > 5,224,521 2,264,993 eth_common_init > 5,523,428298,907 eth_initialize > 5,523,606178 main_loop > 5,523,764158 usb_start > 12,063,971 6,540,207 cli_loop > > 2) GZIP Compressed U-BOOT : Total time ≈ 12.824968 seconds > > => bootstage report > Timer summary in microseconds (10 records): >MarkElapsed Stage > 0 0 reset > 2,594,709 2,594,709 board_init_f > 3,719,969 1,125,260 board_init_r > 5,985,450 2,265,481 eth_common_init > 6,284,371298,921 eth_initialize > 6,284,549178 main_loop > 6,284,708159 usb_start > 12,824,968 6,540,260 cli_loop > > 3) LZMA Compressed U-BOOT : Total time ≈ 17.025004 seconds > > => bootstage report > Timer summary in microseconds (10 records): >MarkElapsed Stage > 0 0 reset > 6,852,254 6,852,254 board_init_f > 7,940,143 1,087,889 board_init_r > 10,190,458 2,250,315 eth_common_init > 10,487,254296,796 eth_initialize > 10,487,432178 main_loop > 10,487,590158 usb_start > 17,025,004 6,537,414 cli_loop > > > As per suggestion from Mr.Jonas Karlman (jo...@kwiboo.se) through Patchset > V2,that check boot time > with enabling CONFIG_SPL_FIT_SIGNATURE that might impact boot time. > > Tried to check the boot time with CONFIG_FIT_SIGNATURE enabled, I didnt find > any significant > boot time improvement with enabling CONFIG_SPL_FIT_SIGNATURE. I may not have been that clear in my last mail, it is the following rfc/patch that may improve performance. That prfc/patch does improve performance for sha256 validation when CONFIG_SPL_FIT_SIGNATURE is enabled. [RFC] rockchip: spl: Enable caches to speed up checksum validation https://patchwork.ozlabs.org/project/uboot/patch/20230702110055.3686457-1-jo...@kwiboo.se/ Would be great to get confirmation if D-cache enabled in SPL also benefit this series, and not just checksum validation. (that rfc/patch unfortunately did not get much feedback) Regards, Jonas > > Comparision of GZIP and LZMA compressed U-boot Boot time with and without > Enable of CONFIG_FIT_SIGNATURE :- > > - GZIP Compressed U-BOOT and CONFIG_FIT_SIGNATURE enabled :- Total time ≈ > 13.283998 seconds > > => bootstage report > Timer summary in microseconds (10 records): >MarkElapsed Stage > 0 0 reset > 3,052,571 3,052,571 board_init_f > 4,179,787 1,127,216 board_init_r > 6,445,472 2,265,685 eth_common_init > 6,744,416298,944 eth_initialize > 6,744,593177 main_loop > 6,744,751158 usb_start > 13,283,998 6,539,247 cli_loop > > - GZIP Compressed U-BOOT and CONFIG_FIT_SIGNATURE disabled :- Total time ≈ > 12.824968 seconds > > > - LZMA Compressed U-BOOT and CONFIG_FIT_SIGNATURE enabled :- Total time ≈ > 17.005996 seconds > >=> bootstage report > Timer summary in microseconds (10 records): >MarkElapsed Stage > 0 0 reset > 6,775,071 6,775,071 board_init_f > 7,902,443 1,127,372 board_init_r > 10,167,546 2,265,103 eth_common_init > 10,466,418298,872 eth_initialize > 10,466,595177 main_loop > 10,466,753158 usb_start > 17,005,996 6,539,243 cli_loop > > - LZMA Compressed U-BOOT and CONFIG_FIT_SIGNATURE disabled :- Total time ≈ > 17.025004 seconds > >
[PATCH v3 0/4] support for booting the compressed U-boot binary on Rockchip based ARM64 SOC's
This patchset adds the support on Rockchip based ARM64 SOC's that compress the U-BOOT proper along with dtb and ATF in FIT image format.Second stage bootloader(SPL) loads the compressed binaries, uncompress them and handover control to the next stage. Changes for V3 :- 1. Replaced spl_decompression_enabled() function instead of checking IS_ENABLED(CONFIG_SPL_GZIP) and IS_ENABLED(CONFIG_SPL_LZMA) in spl_fit.c 2. Removed extra wrapping parentheses in spl_decompression_enabled(). Size Comparision between compressed and uncompressed binaries :- size of uncompressed binary:- 9.0M (94,21,824 bytes) manoj:u-boot$ ls -lb u-boot-rockchip.bin -rw-rw-r-- 1 manoj manoj 9421824 Sep 10 22:22 u-boot-rockchip.bin size of GZIP compressed binary :- 8.6M (89,85,088 bytes) manoj:u-boot$ ls -lb u-boot-rockchip.bin -rw-rw-r-- 1 manoj manoj 8985088 Jul 25 07:42 u-boot-rockchip.bin size of LZMA compressed binary :- 8.6 M (90,06,592 bytes) manoj:u-boot$ ls -lb u-boot-rockchip.bin -rw-rw-r-- 1 manoj manoj 9006592 Jul 25 07:47 u-boot-rockchip.bin Test results of Booting time using bootstage command in Uboot command prompt on roc-rk3399-pc board :- 1) Uncompressed U-BOOT : Total boot time ??? 12.063971 seconds => bootstage report Timer summary in microseconds (10 records): MarkElapsed Stage 0 0 reset 1,833,884 1,833,884 board_init_f 2,959,528 1,125,644 board_init_r 5,224,521 2,264,993 eth_common_init 5,523,428298,907 eth_initialize 5,523,606178 main_loop 5,523,764158 usb_start 12,063,971 6,540,207 cli_loop 2) GZIP Compressed U-BOOT : Total time ??? 12.824968 seconds => bootstage report Timer summary in microseconds (10 records): MarkElapsed Stage 0 0 reset 2,594,709 2,594,709 board_init_f 3,719,969 1,125,260 board_init_r 5,985,450 2,265,481 eth_common_init 6,284,371298,921 eth_initialize 6,284,549178 main_loop 6,284,708159 usb_start 12,824,968 6,540,260 cli_loop 3) LZMA Compressed U-BOOT : Total time ??? 17.025004 seconds => bootstage report Timer summary in microseconds (10 records): MarkElapsed Stage 0 0 reset 6,852,254 6,852,254 board_init_f 7,940,143 1,087,889 board_init_r 10,190,458 2,250,315 eth_common_init 10,487,254296,796 eth_initialize 10,487,432178 main_loop 10,487,590158 usb_start 17,025,004 6,537,414 cli_loop As per suggestion from Mr.Jonas Karlman (jo...@kwiboo.se) through Patchset V2,that check boot time with enabling CONFIG_SPL_FIT_SIGNATURE that might impact boot time. Tried to check the boot time with CONFIG_FIT_SIGNATURE enabled, I didnt find any significant boot time improvement with enabling CONFIG_SPL_FIT_SIGNATURE. Comparision of GZIP and LZMA compressed U-boot Boot time with and without Enable of CONFIG_FIT_SIGNATURE :- - GZIP Compressed U-BOOT and CONFIG_FIT_SIGNATURE enabled :- Total time ??? 13.283998 seconds => bootstage report Timer summary in microseconds (10 records): MarkElapsed Stage 0 0 reset 3,052,571 3,052,571 board_init_f 4,179,787 1,127,216 board_init_r 6,445,472 2,265,685 eth_common_init 6,744,416298,944 eth_initialize 6,744,593177 main_loop 6,744,751158 usb_start 13,283,998 6,539,247 cli_loop - GZIP Compressed U-BOOT and CONFIG_FIT_SIGNATURE disabled :- Total time ??? 12.824968 seconds - LZMA Compressed U-BOOT and CONFIG_FIT_SIGNATURE enabled :- Total time ??? 17.005996 seconds => bootstage report Timer summary in microseconds (10 records): MarkElapsed Stage 0 0 reset 6,775,071 6,775,071 board_init_f 7,902,443 1,127,372 board_init_r 10,167,546 2,265,103 eth_common_init 10,466,418298,872 eth_initialize 10,466,595177 main_loop 10,466,753158 usb_start 17,005,996 6,539,243 cli_loop - LZMA Compressed U-BOOT and CONFIG_FIT_SIGNATURE disabled :- Total time ??? 17.025004 seconds Manoj Sai (4): spl: fit: support for booting a GZIP-compressed U-boot binary spl: fit: support for booting a LZMA-compressed U-boot binary rockchip: Add support to generate GZIP compressed U-boot binary rockchip: Add support to generate LZMA compressed U-boot binary arch/arm/dts/rockchip-u-boot.dtsi | 11 +++ common/spl/spl_fit.c | 20 +--- include/spl.h | 10 ++ 3 files changed, 38 insertions(+), 3 deletions(-) -- 2.25.1
Re: [PATCH V3 0/4] board: ti: Add support for BeaglePlay
On mar., août 22, 2023 at 10:40, Nishanth Menon wrote:
> On 17:33-20230822, Mattijs Korpershoek wrote:
>> On mar., août 15, 2023 at 11:44, Nishanth Menon wrote:
>>
>> > Add support for BeaglePlay - rev 3
>> >
>> > Boot log: https://gist.github.com/nmenon/3e99b44380873263e39ba4d84788db89
>> >
>> > Full series(including dependencies) can be found at:
>> > https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3
>> >
>> > Caveats:
>> > * I have kept networking out of picture for now as it is still in debug
>> > (See
>> >
>> > https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3-enet-debug
>> > if anyone is interested)
>> >
>> > Changes since V2:
>> > * I have rebased to latest next branch
>> > bdc682437a67 (origin/next) Merge branch
>> > '2023-08-14-assorted-general-updates' into next
>> > * Uses config fragments by default.
>> > * Updated MAINTAINER file as well
>> >
>> > V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/
>> > V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/
>> >
>> > Nishanth Menon (3):
>> > arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
>> > board: ti: am62x: Add am62x_beagleplay_* defconfigs
>> > doc: board: ti: Add BeaglePlay documentation
>> >
>> > Robert Nelson (1):
>> > arm: dts: Add k3-am625-beagleplay
>>
>> I tried these series on top of next on my beagleplay with the intention of
>> booting U-Boot from eMMC.
>>
>> Base commit: 7e6e40c57233 ("Merge tag 'v2023.10-rc3' into next")
>>
>> I can't get this to boot. Seems to be stuck in the r5 spl.
>>
>> Boot log is:
>>
>> U-Boot SPL 2023.10-rc3-01591-ga4f9ddf99438 (Aug 22 2023 - 17:11:47 +0200)
>> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
>> SPL initial stack usage: 13400 bytes
>> Trying to boot from MMC1
>> mmc_load_image_raw_sector: mmc block read error
>> Partition 1 invalid on device 0
>> spl_register_fat_device: fat register err - -1
>> spl_load_image_fat: error reading image tispl.bin, err - -1
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> It seems that when we try to find tispl.bin, we read from the mmc0boot0
>> hw partition instead of from the user partition.
>>
>> Per my understanding, BeaglePlay has the following (simplified) boot
>> flow:
>
> Thanks Mattijs, we have been discussing this in our discord channel, and
Indeed I saw some things on discord around this but wanted to notice a
broader audience (via the U-Boot list) that booting from eMMC was not
working for some folks.
> I have a new version I am working on. will fix it up and send it later
> today - fixing some other pending documentation aspects atm.
Looking forward to give it a try !
If it's not too much to ask, please cc me on the v4 series.
Thank you.
>
> --
> Regards,
> Nishanth Menon
> Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
> 849D 1736 249D
Re: [PATCH V3 0/4] board: ti: Add support for BeaglePlay
On 17:33-20230822, Mattijs Korpershoek wrote:
> On mar., août 15, 2023 at 11:44, Nishanth Menon wrote:
>
> > Add support for BeaglePlay - rev 3
> >
> > Boot log: https://gist.github.com/nmenon/3e99b44380873263e39ba4d84788db89
> >
> > Full series(including dependencies) can be found at:
> > https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3
> >
> > Caveats:
> > * I have kept networking out of picture for now as it is still in debug
> > (See
> >
> > https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3-enet-debug
> > if anyone is interested)
> >
> > Changes since V2:
> > * I have rebased to latest next branch
> > bdc682437a67 (origin/next) Merge branch
> > '2023-08-14-assorted-general-updates' into next
> > * Uses config fragments by default.
> > * Updated MAINTAINER file as well
> >
> > V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/
> > V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/
> >
> > Nishanth Menon (3):
> > arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
> > board: ti: am62x: Add am62x_beagleplay_* defconfigs
> > doc: board: ti: Add BeaglePlay documentation
> >
> > Robert Nelson (1):
> > arm: dts: Add k3-am625-beagleplay
>
> I tried these series on top of next on my beagleplay with the intention of
> booting U-Boot from eMMC.
>
> Base commit: 7e6e40c57233 ("Merge tag 'v2023.10-rc3' into next")
>
> I can't get this to boot. Seems to be stuck in the r5 spl.
>
> Boot log is:
>
> U-Boot SPL 2023.10-rc3-01591-ga4f9ddf99438 (Aug 22 2023 - 17:11:47 +0200)
> SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
> SPL initial stack usage: 13400 bytes
> Trying to boot from MMC1
> mmc_load_image_raw_sector: mmc block read error
> Partition 1 invalid on device 0
> spl_register_fat_device: fat register err - -1
> spl_load_image_fat: error reading image tispl.bin, err - -1
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> It seems that when we try to find tispl.bin, we read from the mmc0boot0
> hw partition instead of from the user partition.
>
> Per my understanding, BeaglePlay has the following (simplified) boot
> flow:
Thanks Mattijs, we have been discussing this in our discord channel, and
I have a new version I am working on. will fix it up and send it later
today - fixing some other pending documentation aspects atm.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH V3 0/4] board: ti: Add support for BeaglePlay
On mar., août 15, 2023 at 11:44, Nishanth Menon wrote:
> Add support for BeaglePlay - rev 3
>
> Boot log: https://gist.github.com/nmenon/3e99b44380873263e39ba4d84788db89
>
> Full series(including dependencies) can be found at:
> https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3
>
> Caveats:
> * I have kept networking out of picture for now as it is still in debug
> (See
> https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3-enet-debug
> if anyone is interested)
>
> Changes since V2:
> * I have rebased to latest next branch
> bdc682437a67 (origin/next) Merge branch
> '2023-08-14-assorted-general-updates' into next
> * Uses config fragments by default.
> * Updated MAINTAINER file as well
>
> V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/
> V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/
>
> Nishanth Menon (3):
> arm: dts: k3-am625-sk-binman: Add labels for unsigned binary
> board: ti: am62x: Add am62x_beagleplay_* defconfigs
> doc: board: ti: Add BeaglePlay documentation
>
> Robert Nelson (1):
> arm: dts: Add k3-am625-beagleplay
I tried these series on top of next on my beagleplay with the intention of
booting U-Boot from eMMC.
Base commit: 7e6e40c57233 ("Merge tag 'v2023.10-rc3' into next")
I can't get this to boot. Seems to be stuck in the r5 spl.
Boot log is:
U-Boot SPL 2023.10-rc3-01591-ga4f9ddf99438 (Aug 22 2023 - 17:11:47 +0200)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
SPL initial stack usage: 13400 bytes
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
Partition 1 invalid on device 0
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image tispl.bin, err - -1
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
It seems that when we try to find tispl.bin, we read from the mmc0boot0
hw partition instead of from the user partition.
Per my understanding, BeaglePlay has the following (simplified) boot
flow:
1. boot rom loads tiboot3 from mmc0boot0
2. tiboot3 loads tispl.bin from mmc(user), first partition (on a FAT filesystem)
3. tispl loads u-boot.img from mmc(user), first partition (on a FAT filesystem)
With the folllowing diff, I can boot all the way to U-Boot proper:
diff --git a/board/ti/am62x/beagleplay_a53.config
b/board/ti/am62x/beagleplay_a53.config
index 4889e1bc6f2b..d59a3ca6926e 100644
--- a/board/ti/am62x/beagleplay_a53.config
+++ b/board/ti/am62x/beagleplay_a53.config
@@ -18,3 +18,8 @@ CONFIG_SPI=n
CONFIG_SPI_FLASH=n
CONFIG_SPL_DM_SPI_FLASH=n
CONFIG_SPL_SPI_FLASH_SUPPORT=n
+
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG=y
+CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION=0
diff --git a/board/ti/am62x/beagleplay_r5.config
b/board/ti/am62x/beagleplay_r5.config
index ce64561bee92..239d0d6a55bd 100644
--- a/board/ti/am62x/beagleplay_r5.config
+++ b/board/ti/am62x/beagleplay_r5.config
@@ -9,3 +9,8 @@ CONFIG_SPI=n
CONFIG_SPI_FLASH=n
CONFIG_SPL_DM_SPI_FLASH=n
CONFIG_SPL_SPI_FLASH_SUPPORT=n
+
+CONFIG_SUPPORT_EMMC_BOOT=y
+CONFIG_SUPPORT_EMMC_BOOT_OVERRIDE_PART_CONFIG=y
+CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION=0
The above is probably not the proper way of doing things, but it seems
to resolve my booting issue.
>
> arch/arm/dts/Makefile |2 +
> .../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 +
> arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 172 ++
> arch/arm/dts/k3-am625-beagleplay.dts | 758 ++
> arch/arm/dts/k3-am625-r5-beagleplay.dts | 87 +
> arch/arm/dts/k3-am625-sk-binman.dtsi |4 +-
> board/ti/am62x/MAINTAINERS|7 +
> board/ti/am62x/beagleplay_a53.config | 20 +
> board/ti/am62x/beagleplay_r5.config | 11 +
> doc/board/ti/am62x_beagleplay.rst | 121 +
> doc/board/ti/k3.rst |1 +
> 11 files changed, 3376 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi
> create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi
> create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts
> create mode 100644 arch/arm/dts/k3-am625-r5-beagleplay.dts
> create mode 100644 board/ti/am62x/beagleplay_a53.config
> create mode 100644 board/ti/am62x/beagleplay_r5.config
> create mode 100644 doc/board/ti/am62x_beagleplay.rst
>
> --
> 2.40.0
[PATCH V3 0/4] board: ti: Add support for BeaglePlay
Add support for BeaglePlay - rev 3 Boot log: https://gist.github.com/nmenon/3e99b44380873263e39ba4d84788db89 Full series(including dependencies) can be found at: https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3 Caveats: * I have kept networking out of picture for now as it is still in debug (See https://github.com/nmenon/fix-k3-dt-u-boot/commits/beagleplay-v3-enet-debug if anyone is interested) Changes since V2: * I have rebased to latest next branch bdc682437a67 (origin/next) Merge branch '2023-08-14-assorted-general-updates' into next * Uses config fragments by default. * Updated MAINTAINER file as well V2: https://lore.kernel.org/u-boot/20230727234446.3651836-1...@ti.com/ V1: https://lore.kernel.org/all/20230725185253.2123433-1...@ti.com/ Nishanth Menon (3): arm: dts: k3-am625-sk-binman: Add labels for unsigned binary board: ti: am62x: Add am62x_beagleplay_* defconfigs doc: board: ti: Add BeaglePlay documentation Robert Nelson (1): arm: dts: Add k3-am625-beagleplay arch/arm/dts/Makefile |2 + .../dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi | 2195 + arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 172 ++ arch/arm/dts/k3-am625-beagleplay.dts | 758 ++ arch/arm/dts/k3-am625-r5-beagleplay.dts | 87 + arch/arm/dts/k3-am625-sk-binman.dtsi |4 +- board/ti/am62x/MAINTAINERS|7 + board/ti/am62x/beagleplay_a53.config | 20 + board/ti/am62x/beagleplay_r5.config | 11 + doc/board/ti/am62x_beagleplay.rst | 121 + doc/board/ti/k3.rst |1 + 11 files changed, 3376 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/k3-am625-beagleplay-ddr4-1600MTs.dtsi create mode 100644 arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi create mode 100644 arch/arm/dts/k3-am625-beagleplay.dts create mode 100644 arch/arm/dts/k3-am625-r5-beagleplay.dts create mode 100644 board/ti/am62x/beagleplay_a53.config create mode 100644 board/ti/am62x/beagleplay_r5.config create mode 100644 doc/board/ti/am62x_beagleplay.rst -- 2.40.0
Re: [PATCH v3 0/4] General regulator and pmic uclass improvements
Mailing list reduction.
This issue is not directly related to pmic apart from the fact that pmics in my
case is an i2c device so writing on the top.
Sorry for this format but you are one of the most keen and in the
context of this
regulator rework. As you know I have an issue with probing the PMIC i2c device.
I have made some logs and tests and found next stuff.
If I use purely setup from this patchset v3 I get error in i2c xfer
(bootloader) tegra_i2c_probe
(bootloader) max77663_probe
(bootloader) max77663_sd_probe
(bootloader) Core: 99 devices, 25 uclasses, devicetree: separate
(bootloader) MMC: sdhci@78000600: 0
(bootloader) Loading Environment from MMC... max77663_sd_probe
(bootloader) Error enabling VMMC supply : -121
If I use probing regulators on pmic post_probe I get no error and
different calls
(bootloader) Core: 99 devices, 25 uclasses, devicetree: separate
(bootloader) MMC: sdhci@78000600: 0
(bootloader) Loading Environment from MMC... tegra_i2c_probe
(bootloader) max77663_probe
(bootloader) max77663_sd_probe
(bootloader) *** Warning - bad CRC, using default environment
Maybe you have any ideas what is causing this inconsistency?
нд, 6 серп. 2023 р. о 20:52 Svyatoslav Ryhel пише:
>
> This patchset derives from discussion of TPS65913 bringup and aims to
> cycle all regulator management inside uclass removing need of any board
> calls for regulators.
>
> My hw setup is Tegra 3 LG Optimus Vu P895 (PMIC is MAX77663) with native
> spl u-boot build.
>
> power: regulator: expand basic reference counter onto all uclass
> Commit is basically expansion of 4fcba5d ("regulator: implement basic
> reference counter") onto all regulators. My testing on hw has shown no
> issues so far with both pmic regulators and fixed regulators. Counting
> works as expected, dm test is set in test of regulator_set_enable_if_allowed.
>
> power: regulator-uclass: perform regulator setup inside uclass
> All regulators with always-on or boot-on are set to probe after bind
> which ensures that essential regulators are set. In the post probe
> regulator autoset is called so that correct regulator state according to
> device tree is reached. DM test is set by checking regulators data without
> pre-configuring them manually.
>
> ---
> Changes from v2:
> - dropped changes related to pmic (pmic regulator probing on pmic post bind)
> - regulator uclass changes are dropped to minimum to remain compatibility:
>- always-on and boot-on check is moved to post bind
>- regulator_autoset is called on post_probe
> - adjusted dm tests to pass with this changes
>
> Changes from v1:
> - adapted description of regulator_set_enable
> - remove uc_pdata->enable_count from post_probe
> - added tests from counter and regulators post_probe
> ---
>
> Svyatoslav Ryhel (4):
> power: regulator: expand basic reference counter onto all uclass
> test: dm: regulator: test counter in set_enable_if_allowed test
> power: regulator: Perform regulator setup inside uclass
> test: dm: regulator: provide test of auto setup
>
> drivers/power/regulator/regulator-uclass.c | 71 --
> drivers/power/regulator/regulator_common.c | 22 ---
> drivers/power/regulator/regulator_common.h | 21 ---
> include/power/regulator.h | 2 +
> test/dm/regulator.c| 27 +++-
> 5 files changed, 92 insertions(+), 51 deletions(-)
>
> --
> 2.39.2
>
[PATCH v3 0/4] General regulator and pmic uclass improvements
This patchset derives from discussion of TPS65913 bringup and aims to
cycle all regulator management inside uclass removing need of any board
calls for regulators.
My hw setup is Tegra 3 LG Optimus Vu P895 (PMIC is MAX77663) with native
spl u-boot build.
power: regulator: expand basic reference counter onto all uclass
Commit is basically expansion of 4fcba5d ("regulator: implement basic
reference counter") onto all regulators. My testing on hw has shown no
issues so far with both pmic regulators and fixed regulators. Counting
works as expected, dm test is set in test of regulator_set_enable_if_allowed.
power: regulator-uclass: perform regulator setup inside uclass
All regulators with always-on or boot-on are set to probe after bind
which ensures that essential regulators are set. In the post probe
regulator autoset is called so that correct regulator state according to
device tree is reached. DM test is set by checking regulators data without
pre-configuring them manually.
---
Changes from v2:
- dropped changes related to pmic (pmic regulator probing on pmic post bind)
- regulator uclass changes are dropped to minimum to remain compatibility:
- always-on and boot-on check is moved to post bind
- regulator_autoset is called on post_probe
- adjusted dm tests to pass with this changes
Changes from v1:
- adapted description of regulator_set_enable
- remove uc_pdata->enable_count from post_probe
- added tests from counter and regulators post_probe
---
Svyatoslav Ryhel (4):
power: regulator: expand basic reference counter onto all uclass
test: dm: regulator: test counter in set_enable_if_allowed test
power: regulator: Perform regulator setup inside uclass
test: dm: regulator: provide test of auto setup
drivers/power/regulator/regulator-uclass.c | 71 --
drivers/power/regulator/regulator_common.c | 22 ---
drivers/power/regulator/regulator_common.h | 21 ---
include/power/regulator.h | 2 +
test/dm/regulator.c| 27 +++-
5 files changed, 92 insertions(+), 51 deletions(-)
--
2.39.2
[PATCH v3 0/4] arm: dts: k3-am64: Sync DT with Linux
Hi, This series syncs AM64 DT files from Linux v6.5-rc1. Tested on AM642-EVM GP SR1.0 and AM642-SK-EVM HS-FS SR2.0. Couldn't verify Linux boot on AM642-SK-EVM so would appreciate if someone can give a Tested-by for that. Thanks! cheers, -roger Changelog: v3: - include board DT file in -r5 DT file. - move including -u-boot.dtsi file at the top of -r5 DT file. - drop duplicate nodes - document why we need to delete clock/power properties from main_timer0 v2: - Sync with v6.5-rc1 - Rebase on latest uboot/master - CPSW node cleanup - Timer node cleanup Roger Quadros (4): board: ti: am64x: Recognize AM64-HSEVM doc: board: ti: am64: Add boot flow diagram Revert "ARM: dts: k3-am642-sk-u-boot: add PMIC node" arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 arch/arm/dts/k3-am64-main.dtsi | 171 - arch/arm/dts/k3-am64-mcu.dtsi | 53 ++- arch/arm/dts/k3-am64-thermal.dtsi | 33 ++ arch/arm/dts/k3-am64.dtsi | 22 +- arch/arm/dts/k3-am642-evm-u-boot.dtsi | 67 ++-- arch/arm/dts/k3-am642-evm.dts | 173 +++-- arch/arm/dts/k3-am642-r5-evm.dts | 202 +- arch/arm/dts/k3-am642-r5-sk.dts| 209 +-- arch/arm/dts/k3-am642-sk-u-boot.dtsi | 120 ++ arch/arm/dts/k3-am642-sk.dts | 166 ++--- arch/arm/dts/k3-am642.dtsi | 1 + board/ti/am64x/evm.c | 3 +- doc/board/ti/img/boot_diagram_am64.svg | 496 + 13 files changed, insertions(+), 605 deletions(-) create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi create mode 100644 doc/board/ti/img/boot_diagram_am64.svg -- 2.34.1
[PATCH v3 0/4] Tegra: add ASUS/Google Nexus 7 (2012) support
This patchset adds support for native use of U-Boot on ASUS/Google Nexus 7 (2012), aka grouper/tilapia as a replacement of vendor bootloader. Alongside device bringup tegra requires few small patches: - add gpio keyboard as stdin device - make networking boot options optional - add a small tool to generate SoC UID Commits passed buildman with './tools/buildman/buildman -Pr tegra' without errors. --- Changes from v2: - fuse build is excluded for T186 (it is not supported in it anyway) Changes from v1: - fix fuse headers for newer Tegra generations - allow grouper_common_defconfig to pass without fragments --- Jonas Schwöbel (1): configs: tegra-common-post: make PXE and DHCP boot targets optional Svyatoslav Ryhel (3): configs: tegra-common-post: add GPIO keyboard as STDIN device ARM: tegra: add SoC UID calculation function board: asus: grouper: add Google Nexus 7 (2012) support arch/arm/dts/Makefile | 3 + arch/arm/dts/tegra30-asus-grouper-common.dtsi | 125 ++ .../dts/tegra30-asus-nexus7-grouper-E1565.dts | 40 ++ .../dts/tegra30-asus-nexus7-grouper-PM269.dts | 65 .../dts/tegra30-asus-nexus7-tilapia-E1565.dts | 40 ++ arch/arm/include/asm/arch-tegra/fuse.h| 7 + arch/arm/mach-tegra/Makefile | 4 + arch/arm/mach-tegra/fuse.c| 151 arch/arm/mach-tegra/tegra30/Kconfig | 5 + board/asus/grouper/Kconfig| 22 ++ board/asus/grouper/MAINTAINERS| 6 + board/asus/grouper/Makefile | 14 + board/asus/grouper/grouper-spl-max.c | 46 +++ board/asus/grouper/grouper-spl-ti.c | 42 ++ board/asus/grouper/grouper.c | 209 ++ board/asus/grouper/pinmux-config-grouper.h| 362 ++ configs/grouper_E1565.config | 2 + configs/grouper_PM269.config | 2 + configs/grouper_common_defconfig | 84 configs/tilapia.config| 3 + include/configs/grouper.h | 68 include/configs/tegra-common-post.h | 28 +- 22 files changed, 1323 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/tegra30-asus-grouper-common.dtsi create mode 100644 arch/arm/dts/tegra30-asus-nexus7-grouper-E1565.dts create mode 100644 arch/arm/dts/tegra30-asus-nexus7-grouper-PM269.dts create mode 100644 arch/arm/dts/tegra30-asus-nexus7-tilapia-E1565.dts create mode 100644 arch/arm/mach-tegra/fuse.c create mode 100644 board/asus/grouper/Kconfig create mode 100644 board/asus/grouper/MAINTAINERS create mode 100644 board/asus/grouper/Makefile create mode 100644 board/asus/grouper/grouper-spl-max.c create mode 100644 board/asus/grouper/grouper-spl-ti.c create mode 100644 board/asus/grouper/grouper.c create mode 100644 board/asus/grouper/pinmux-config-grouper.h create mode 100644 configs/grouper_E1565.config create mode 100644 configs/grouper_PM269.config create mode 100644 configs/grouper_common_defconfig create mode 100644 configs/tilapia.config create mode 100644 include/configs/grouper.h -- 2.37.2
[PATCH v3 0/4] FMP versioning support
Firmware version management is not implemented in the current FMP implementation. This series aims to add the versioning support in FMP. Python based test will follow later. EDK2 reference implementation utilizes the FMP Payload Header inserted right before the capsule payload. With this series, U-Boot also follows the EDK2 implementation. Currently, there is no way to know the current running firmware version through the EFI interface. FMP->GetImageInfo() returns always 0 for the version number. So a user can not know that expected firmware is running after the capsule update. With this series applied, version number can be specified in the capsule file generation with mkeficapsule tool, then user can know the running firmware version through FMP->GetImageInfo() and ESRT. Note that this series does not mandate the FMP Payload Header, compatible with boards that are already using the existing U-Boot FMP implementation. If no FMP Payload Header is found in the capsule file, fw_version, lowest supported version, last attempt version and last attempt status is set to 0 and this is the same behavior as existing FMP implementation. Changes in v3: - exclude CONFIG_FWU_MULTI_BANK_UPDATE case Masahisa Kojima (4): efi_loader: store firmware version into FmpState variable efi_loader: versioning support in GetImageInfo efi_loader: check lowest supported version in capsule update mkeficapsule: add FMP Payload Header doc/mkeficapsule.1| 16 ++ lib/efi_loader/efi_firmware.c | 302 +++--- tools/eficapsule.h| 32 tools/mkeficapsule.c | 51 +- 4 files changed, 369 insertions(+), 32 deletions(-) -- 2.17.1
[PATCH v3 0/4] patman: Speed up some operations
This little series updates patman to run the get_maintainer.py script in parallel for each commit. It also does the same with checkpatch. In some cases this can make a dramatic different to the speed. Changes in v3: - Mention the commit where the -a option was dropped - Reword comment for all_skips - Sort the set directly instead of converting it to a list first Changes in v2: - Fix 'uncorrect' typo in subject - Fix missing 'f' on format string Simon Glass (4): patman: Drop an incorrect comment about git am patman: Refactor MakeCcFile() into two functions patman: Run get_maintainer.pl in parallel patman: Check patches in parallel tools/patmanu/checkpatch.py | 46 --- tools/patmanu/control.py| 2 +- tools/patmanu/func_test.py | 2 + tools/patmanu/series.py | 108 4 files changed, 113 insertions(+), 45 deletions(-) -- 2.40.0.rc0.216.gc4246ad0f0-goog
[PATCH v3 0/4] J721E HS Fixes
This series fixes the support for J721E board along with some maintainance for it. v3: - drop fixes related to other boards ( make series j721e specific ) - memory map added in docs - applied reviewed-by v2: - Merge two series - Include some more commits that fix the gp builds when merging defconfigs - Update MAINTAINERS to remove hs related defconfigs - applied Acks Andrew Davis (1): arm: k3: config.mk: Add missing dependencies on tispl.bin HS Dave Gerlach (1): arm: mach-k3: Increase SYSFW max image size Manorit Chawdhry (2): configs: j721e: Merge the HS and non-HS defconfigs Kconfig: j721e: Change K3_MCU_SCRATCHPAD_BASE to non firewalled region MAINTAINERS| 2 - arch/arm/mach-k3/Kconfig | 6 +- arch/arm/mach-k3/config.mk | 2 + configs/j721e_evm_a72_defconfig| 3 +- configs/j721e_evm_r5_defconfig | 11 +- configs/j721e_hs_evm_a72_defconfig | 208 - configs/j721e_hs_evm_r5_defconfig | 176 doc/board/ti/j721e_evm.rst | 24 8 files changed, 40 insertions(+), 392 deletions(-) delete mode 100644 configs/j721e_hs_evm_a72_defconfig delete mode 100644 configs/j721e_hs_evm_r5_defconfig -- 2.34.1
[PATCH v3 0/4] cmd: part: Add partition-related type command
This series are a consequence on the discussion of the patch [1]. It introduces some new patches in order to address the feedback received, adds the documentation and fixes a small typo found during the work on these patches. Best regards, Enric [1] https://patchwork.ozlabs.org/project/uboot/patch/20220727133534.126824-1-eballe...@redhat.com/ Changes in v3: - Add the entry in doc/usage/cmd/index.rst. - Provide examples for the other sub-commands. - Fix return value chapter, 0 (true) on success and 1(false) on error. - Add reviewed by tags Changes in v2: - New patch (1) in the series to fix a trivial type - New patch (2) in the series to introduce the documentation of the part type command - Fix typo s/partittion/partition/ in commit message - Add gpt test for the part type command - Add the man-page for part command in doc/usage/cmd Enric Balletbo i Serra (4): doc: man-page for the part command doc/README.gpt: Fix typo 'a optionnal' cmd: part: Add partition-related type command test/py: gpt: add test for the gpt partition type GUID identifier cmd/part.c| 29 +++ doc/README.gpt| 2 +- doc/usage/cmd/part.rst| 154 ++ doc/usage/index.rst | 1 + test/py/tests/test_gpt.py | 23 ++ 5 files changed, 208 insertions(+), 1 deletion(-) create mode 100644 doc/usage/cmd/part.rst -- 2.39.0
Re: [PATCH V3 0/4] Enable gigadevice and add new part #s
On 1/10/23 00:49, Victor Lim wrote: Changes in V2: Adding the following parts to the list gd25b256: 3V QSPI, QE=1, 256Mbit gd25b512: 3V QSPI, QE=1, 512Mbit gd55b01g: 3V QSPI, QE=1, 1Gbit gd55b02g: 3V QSPI, QE=1, 2Gbit gd25f64: 3V QSPI, QE=1, 64Mbit, high performance gd25f128: 3V QSPI, QE=1, 128Mbit, high performance gd25f256: 3V QSPI, QE=1, 256Mbit, high performance gd55f512: 3V QSPI, QE=1, 512Mbit, high performance gd25t512: 3V QSPI, 512Mbit, ultra high performance gd55t01g: 3V QSPI, 1Gbit, ultra high performance gd55t02g: 3V QSPI, 2Gbit, ultra high performance gd25x512: 3V OSPI, 512Mbit, ultra high performance gd55x01g: 3V OSPI, 1Gbit, ultra high performance gd55x02g: 3V OSPI, 2Gbit, ultra high performance gd25lb256: 1.8V QSPI, QE=1, 256Mbit gd25lb512: 1.8V QSPI, QE=1, 512Mbit gd55lb01g: 1.8V QSPI, QE=1, 1Gbit gd55lb02g: 1.8V QSPI, QE=1, 2Gbit gd25lf64: 1.8V QSPI, QE=1, 64Mbit, high performance gd25lf128: 1.8V QSPI, QE=1, 128Mbit, high performance gd25lf256: 1.8V QSPI, QE=1, 256Mbit, high performance gd55lf512: 1.8V QSPI, QE=1, 512Mbit, high performance gd25lt512: 1.8V QSPI, 512Mbit, ultra high performance gd55lt01g: 1.8V QSPI, 1Gbit, ultra high performance gd55lt02g: 1.8V QSPI, 2Gbit, ultra high performance gd25lx512: 1.8V OSPI, 512Mbit, ultra high performance gd55lx01g: 1.8V OSPI, 1Gbit, ultra high performance gd55lx02g: 1.8V OSPI, 2Gbit, ultra high performance This is the link to the datasheet. https://www.gigadevice.com/products/memory/flash/spi-nor/ Victor Lim (4): mtd: spi-nor-ids: add gigadevice part # configs: zynq: enable gigadevice arm64: zynqmp: enable gigadevice xilinx: versal: enable gigadevice configs/xilinx_versal_mini_qspi_defconfig | 1 + configs/xilinx_zynq_virt_defconfig| 1 + configs/xilinx_zynqmp_mini_qspi_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + configs/zynq_cse_qspi_defconfig | 1 + drivers/mtd/spi/spi-nor-ids.c | 68 +++ 6 files changed, 73 insertions(+) Applied. M
[PATCH V3 0/4] Enable gigadevice and add new part #s
Changes in V2: Adding the following parts to the list gd25b256: 3V QSPI, QE=1, 256Mbit gd25b512: 3V QSPI, QE=1, 512Mbit gd55b01g: 3V QSPI, QE=1, 1Gbit gd55b02g: 3V QSPI, QE=1, 2Gbit gd25f64: 3V QSPI, QE=1, 64Mbit, high performance gd25f128: 3V QSPI, QE=1, 128Mbit, high performance gd25f256: 3V QSPI, QE=1, 256Mbit, high performance gd55f512: 3V QSPI, QE=1, 512Mbit, high performance gd25t512: 3V QSPI, 512Mbit, ultra high performance gd55t01g: 3V QSPI, 1Gbit, ultra high performance gd55t02g: 3V QSPI, 2Gbit, ultra high performance gd25x512: 3V OSPI, 512Mbit, ultra high performance gd55x01g: 3V OSPI, 1Gbit, ultra high performance gd55x02g: 3V OSPI, 2Gbit, ultra high performance gd25lb256: 1.8V QSPI, QE=1, 256Mbit gd25lb512: 1.8V QSPI, QE=1, 512Mbit gd55lb01g: 1.8V QSPI, QE=1, 1Gbit gd55lb02g: 1.8V QSPI, QE=1, 2Gbit gd25lf64: 1.8V QSPI, QE=1, 64Mbit, high performance gd25lf128: 1.8V QSPI, QE=1, 128Mbit, high performance gd25lf256: 1.8V QSPI, QE=1, 256Mbit, high performance gd55lf512: 1.8V QSPI, QE=1, 512Mbit, high performance gd25lt512: 1.8V QSPI, 512Mbit, ultra high performance gd55lt01g: 1.8V QSPI, 1Gbit, ultra high performance gd55lt02g: 1.8V QSPI, 2Gbit, ultra high performance gd25lx512: 1.8V OSPI, 512Mbit, ultra high performance gd55lx01g: 1.8V OSPI, 1Gbit, ultra high performance gd55lx02g: 1.8V OSPI, 2Gbit, ultra high performance This is the link to the datasheet. https://www.gigadevice.com/products/memory/flash/spi-nor/ Victor Lim (4): mtd: spi-nor-ids: add gigadevice part # configs: zynq: enable gigadevice arm64: zynqmp: enable gigadevice xilinx: versal: enable gigadevice configs/xilinx_versal_mini_qspi_defconfig | 1 + configs/xilinx_zynq_virt_defconfig| 1 + configs/xilinx_zynqmp_mini_qspi_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + configs/zynq_cse_qspi_defconfig | 1 + drivers/mtd/spi/spi-nor-ids.c | 68 +++ 6 files changed, 73 insertions(+) -- 2.34.1
[PATCH v3 0/4] cmd: source: Support specifying config name
This series adds support for using configs with the source command. See the third patch for details. Changes in v3: - Halve the quotes Changes in v2: - Add test for source command Sean Anderson (4): test: Add test for source command treewide: Use NULL for script image name cmd: source: Clean up a few lines cmd: source: Support specifying config name .../cmd_stm32prog/cmd_stm32prog.c | 2 +- boot/bootmeth_script.c| 2 +- cmd/source.c | 83 +-- doc/uImage.FIT/source_file_format.txt | 3 + drivers/usb/gadget/f_sdp.c| 2 +- include/image.h | 19 +++-- test/py/tests/source.its | 43 ++ test/py/tests/test_source.py | 37 + 8 files changed, 156 insertions(+), 35 deletions(-) create mode 100644 test/py/tests/source.its create mode 100644 test/py/tests/test_source.py -- 2.35.1.1320.gc452695387.dirty
[PATCH v3 0/4] Update Microchip PolarFire SoC
This patch set updates Microchip PolarFire SoC Icicle Kit support of RISC-V U-Boot. The patches are based upon latest U-Boot tree (https://source.denx.de/u-boot/u-boot) at commit id 8bc87a4c55a1723728374a5643f13bced37dad6b The memory device node is updated based on the latest FPGA reference design v2022.10 and a small 4MB reservation is made at the end of 32-bit DDR to provide some memory for the HSS to use, add Microchip QSPI driver. Changes in v3: - Add reference design campatible in the device tree - Change QSPI time out value to 500ms(as per Linux) - Fix some typos Changes in v2: - Add Co-developed-by with patch - Replace spi-nand with flash in device node - Add board details for QSPI NAND - Rename QSPI driver file with microchip-coreqspi - Add microchip,coreqspi-rtl-v2 to the compatible list - Use MICROCHIP_COREQSPI instead of MICROCHIP_QSPI in kconfig Padmarao Begari (4): riscv: dts: Update memory configuration riscv: dts: Add QSPI NAND device node spi: Add Microchip PolarFire SoC QSPI driver riscv: Update Microchip MPFS Icicle Kit support arch/riscv/dts/microchip-mpfs-icicle-kit.dts | 91 ++-- board/microchip/mpfs_icicle/Kconfig | 7 + configs/microchip_mpfs_icicle_defconfig | 1 + drivers/spi/Kconfig | 6 + drivers/spi/Makefile | 1 + drivers/spi/microchip_coreqspi.c | 505 +++ 6 files changed, 553 insertions(+), 58 deletions(-) create mode 100644 drivers/spi/microchip_coreqspi.c -- 2.25.1
[u-boot][PATCH v3 0/4] Introduce MEMORY uclass and TI GPMC driver
Hi, This series introduces the MEMORY controller uclass for the drivers that exist in drivers/memory directory. With that, we add the TI GPMC Memory controller driver as the first user of this uclass. The GPMC is a unified memory controller dedicated for interfacing with external memory devices like - Asynchronous SRAM-like memories and ASICs - Asynchronous, synchronous, and page mode burst NOR flash - NAND flash - Pseudo-SRAM devices The driver is pulled straight from the Linux kernel and adapted for u-boot. This driver will take care of setting up the GPMC based on the settings specified in the Device tree and then probe its children. cheers, -roger Changelog: v3: - Use CONFIG_MEMORY instead of CONFIG_DM_MEMORY - Introduce CONFIG_SPL_MEMORY and use it to gate inclusion of of drivers/memory for SPL build - Make TI_GPMC depend on OF_CONTROL and CLK as well v2: - Introduce MEMORY uclass Roger Quadros (4): dm: memory: Introduce new uclass scripts: Makefile.spl: Enable memory drivers to be built for SPL dt/bindings: memory: Add bindings for TI GPMC driver memory: Add TI GPMC driver arch/sandbox/dts/test.dts |4 + common/spl/Kconfig|7 + .../memory/ti,gpmc-child.yaml | 252 doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 +++ drivers/memory/Kconfig| 36 + drivers/memory/Makefile |3 + drivers/memory/memory-sandbox.c | 18 + drivers/memory/memory-uclass.c| 13 + drivers/memory/ti-gpmc.c | 1240 + drivers/memory/ti-gpmc.h | 298 include/dm/uclass-id.h|1 + include/linux/mtd/omap_gpmc.h |3 + scripts/Makefile.spl |1 + test/dm/Makefile |1 + test/dm/memory.c | 21 + 15 files changed, 2088 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml create mode 100644 drivers/memory/memory-sandbox.c create mode 100644 drivers/memory/memory-uclass.c create mode 100644 drivers/memory/ti-gpmc.c create mode 100644 drivers/memory/ti-gpmc.h create mode 100644 test/dm/memory.c -- 2.17.1
[PATCH v3 0/4] gpio: update gpio_get_status()
Currently, if pin's function is GPIOF_FUNC, only "func" if displayed without any other information. It would be interesting, if information is available, to indicate which pinmuxing's name is used. Changes in v3: - add lost Simon Glass's reviewed-by during v1 review in patch 1 and 2 Patrice Chotard (4): gpio: Allow to print pin's label even for pin with GPIOF_FUNC function gpio: Fix pin's status display for pin with GPIOF_UNUSED function pinctrl: pinctrl_stm32: Populate uc_priv->name[] with pinmux node's name gpio: sandbox: Add GPIOD_IS_AF for gpio configured in alternate function drivers/gpio/gpio-uclass.c | 18 ++- drivers/gpio/sandbox.c | 5 + drivers/pinctrl/pinctrl_stm32.c | 8 +-- include/asm-generic/gpio.h | 1 + include/dt-bindings/gpio/sandbox-gpio.h | 3 +++ test/dm/gpio.c | 30 + 6 files changed, 57 insertions(+), 8 deletions(-) -- 2.25.1
[PATCH v3 0/4] introduce Arm FF-A support
This new version of the patchset provides improvements to the FF-A driver
design.
The FF-A driver is a discoverable bus and brings these new features:
* support for the 64-bit x0-x17 registers in SMC arguments passing
* align with the FF-A kernel driver interfaces
* make the driver EFI independent
This patchset will be followed by further updates (work in progress):
* discover MM partitions at runtime
* align with the FF-A kernel driver error handling
* align Sandbox driver and tests with the new interfaces
Changelog:
===
v3:
* port x0-x17 registers support from linux kernel as defined by SMCCCv1.2
* align the interfaces of the u-boot FF-A driver with those in the linux FF-A
driver
* remove the FF-A helper layer
* make the u-boot FF-A driver independent from EFI
* provide an optional config that enables copying the driver data to EFI
runtime section at ExitBootServices service
* use 64-bit version of FFA_RXTX_MAP, FFA_MSG_SEND_DIRECT_{REQ, RESP}
* update armffa command with the new driver interfaces
v2 [2]:
* make FF-A bus discoverable using device_{bind, probe} APIs
* remove device tree support
v1 [1]:
* introduce FF-A bus driver with device tree support
* introduce armffa command
* introduce FF-A Sandbox driver
* add FF-A Sandbox test cases
* introduce FF-A MM communication
Cheers,
Abdellatif
[1]:
https://lore.kernel.org/all/20220329151659.16894-1-abdellatif.elkhl...@arm.com/
[2]:
https://lore.kernel.org/all/20220415122803.1-1-abdellatif.elkhl...@arm.com/
Cc: Tom Rini
Cc: Ilias Apalodimas
Cc: Jens Wiklander
Cc: Achin Gupta
Cc: Vishnu Banavath
Cc: Xueliang Zhong
Abdellatif El Khlifi (4):
arm64: smccc: add Xn registers support used by SMC calls
arm64: smccc: clear the Xn registers after SMC calls
arm_ffa: introduce Arm FF-A low-level driver
arm_ffa: introduce armffa command
MAINTAINERS|7 +
arch/arm/cpu/armv8/smccc-call.S| 73 ++
arch/arm/lib/asm-offsets.c | 13 +
cmd/Kconfig| 10 +
cmd/Makefile |2 +
cmd/armffa.c | 246
common/board_r.c |7 +
drivers/Kconfig|2 +
drivers/Makefile |1 +
drivers/arm-ffa/Kconfig| 34 +
drivers/arm-ffa/Makefile |7 +
drivers/arm-ffa/arm-ffa-uclass.c | 16 +
drivers/arm-ffa/arm_ffa_prv.h | 219
drivers/arm-ffa/core.c | 1338
drivers/arm-ffa/efi_ffa_runtime_data_mgr.c | 94 ++
include/arm_ffa.h | 132 ++
include/dm/uclass-id.h |1 +
include/linux/arm-smccc.h | 43 +
include/uuid.h |8 +
lib/efi_loader/efi_boottime.c | 17 +
lib/uuid.c | 65 +
21 files changed, 2335 insertions(+)
create mode 100644 cmd/armffa.c
create mode 100644 drivers/arm-ffa/Kconfig
create mode 100644 drivers/arm-ffa/Makefile
create mode 100644 drivers/arm-ffa/arm-ffa-uclass.c
create mode 100644 drivers/arm-ffa/arm_ffa_prv.h
create mode 100644 drivers/arm-ffa/core.c
create mode 100644 drivers/arm-ffa/efi_ffa_runtime_data_mgr.c
create mode 100644 include/arm_ffa.h
--
2.17.1
[PATCH v3 0/4] Deduplicate dhelectronics board files
This series unifies common MAC address code for imx6, imx8 and stm32 based boards by DH. It is thought of as a starting point for more deduplication in the future. Changes in v3: - Entire series reviewed by Marek Changes in v2: - Tested-by Marek - convert to livetree (rebase on commit 5a605b7c86152) - Fix spelling Philip Oberfichtner (4): board: dhelectronics: Implement common MAC address functions ARM: imx6: DH: Use common MAC address functions ARM: imx8: DH: Use common MAC address functions ARM: stm32: DH: Use common MAC address functions board/dhelectronics/common/Makefile | 10 ++ board/dhelectronics/common/dh_common.c| 65 ++ board/dhelectronics/common/dh_common.h| 28 board/dhelectronics/common/dh_imx.c | 24 board/dhelectronics/common/dh_imx.h | 12 ++ board/dhelectronics/dh_imx6/dh_imx6.c | 47 ++- .../dh_imx8mp/imx8mp_dhcom_pdk2.c | 121 +++--- board/dhelectronics/dh_stm32mp1/board.c | 102 +++ 8 files changed, 246 insertions(+), 163 deletions(-) create mode 100644 board/dhelectronics/common/Makefile create mode 100644 board/dhelectronics/common/dh_common.c create mode 100644 board/dhelectronics/common/dh_common.h create mode 100644 board/dhelectronics/common/dh_imx.c create mode 100644 board/dhelectronics/common/dh_imx.h -- 2.37.1
[PATCH v3 0/4] mtd: spi: spi-nor: rk3399: rock-pi-4: u-boot/next Support SPI NOR Flash in Rock Pi 4 (XTX xt25f32b)
The Radxa Rock Pi 4 board is sold from revision 1.4 with a soldered
4Mb SPI NOR Flash. This series allows to use it from U-Boot and boot
from it.
This series applies to u-boot/master.
Changes since v2:
- rebased on master
- droped 5th path, and enabled CONFIG_SPL_DM_SEQ_ALIAS instead
to have the flash on spi1 both on SPL and U-Boot proper.
Changes since v1:
- Changed bus number to 1 in SPL to match U-Boot proper (before it
was bus 0 in SPL and bus 1 in U-Boot).
- Generalization. v1 did a first soft_reset in 8_8_8_DTR but that
wouldn't work since Pratyush Yadav fixed supports_op() in commit
5752d6ae8daacbd ("spi: spi-mem: add spi_mem_dtr_supports_op()").
So now we try a few protocols until 1_1_1 is supported by
controller and device. Might work for more systems.
[PATCH v3 0/4] mtd: spi: spi-nor: rk3399: rock-pi-4: u-boot/next Support SPI NOR Flash in Rock Pi 4 (XTX xt25f32b)
The Radxa Rock Pi 4 board is sold from revision 1.4 with a soldered
4Mb SPI NOR Flash. This series allows to use it from U-Boot and boot
from it.
This series applies to u-boot/master.
Changes since v2:
- rebased on master
- droped 5th path, and enabled CONFIG_SPL_DM_SEQ_ALIAS instead
to have the flash on spi1 both on SPL and U-Boot proper.
Changes since v1:
- Changed bus number to 1 in SPL to match U-Boot proper (before it
was bus 0 in SPL and bus 1 in U-Boot).
- Generalization. v1 did a first soft_reset in 8_8_8_DTR but that
wouldn't work since Pratyush Yadav fixed supports_op() in commit
5752d6ae8daacbd ("spi: spi-mem: add spi_mem_dtr_supports_op()").
So now we try a few protocols until 1_1_1 is supported by
controller and device. Might work for more systems.
[PATCH v3 0/4] Add Nuvoton NPCM750 support
The patch series add basic supoorts for NPCM750, which is Nuvoton's 3th-generation BMC (Baseboard Management Controller). Add drivers to support Clock,Timer,Uart for NPCM7xx SoC. the NPCM750 computing subsystem comprises a dual-core ARM a9 at 800MHz speed with L1/L2 caches dts,dtsi and npcm7xx-reset.h have been submitted to kernel upstream. the patch is base on top of current master and pass the CI test. https://github.com/u-boot/u-boot/pull/169 Jim Liu (4): arm: nuvoton: Add support for Nuvoton NPCM750 BMC clk: nuvoton: Add support for NPCM750 serial: npcm: Add support for Nuvoton NPCM SoCs timer: npcm: Add NPCM timer support arch/arm/Kconfig |8 + arch/arm/Makefile |1 + arch/arm/dts/Makefile |1 + arch/arm/dts/nuvoton-common-npcm7xx.dtsi | 1120 + arch/arm/dts/nuvoton-npcm750-evb.dts | 405 ++ arch/arm/dts/nuvoton-npcm750-pincfg-evb.dtsi | 157 +++ arch/arm/dts/nuvoton-npcm750.dtsi | 62 + arch/arm/include/asm/arch-npcm7xx/gcr.h | 65 + arch/arm/mach-npcm/Kconfig| 26 + arch/arm/mach-npcm/Makefile |1 + arch/arm/mach-npcm/npcm7xx/Kconfig| 22 + arch/arm/mach-npcm/npcm7xx/Makefile |1 + arch/arm/mach-npcm/npcm7xx/cpu.c | 66 + arch/arm/mach-npcm/npcm7xx/l2_cache_pl310.c | 29 + .../mach-npcm/npcm7xx/l2_cache_pl310_init.S | 71 ++ board/nuvoton/poleg_evb/Kconfig | 25 + board/nuvoton/poleg_evb/MAINTAINERS |7 + board/nuvoton/poleg_evb/Makefile |1 + board/nuvoton/poleg_evb/poleg_evb.c | 48 + configs/poleg_evb_defconfig | 40 + drivers/clk/Makefile |1 + drivers/clk/nuvoton/Makefile |2 + drivers/clk/nuvoton/clk_npcm.c| 299 + drivers/clk/nuvoton/clk_npcm.h| 105 ++ drivers/clk/nuvoton/clk_npcm7xx.c | 95 ++ drivers/serial/Kconfig|9 + drivers/serial/Makefile |1 + drivers/serial/serial_npcm.c | 157 +++ drivers/timer/Kconfig |9 + drivers/timer/Makefile|1 + drivers/timer/npcm-timer.c| 115 ++ include/configs/poleg.h | 44 + .../dt-bindings/clock/nuvoton,npcm7xx-clock.h | 46 + .../dt-bindings/reset/nuvoton,npcm7xx-reset.h | 91 ++ 34 files changed, 3131 insertions(+) create mode 100644 arch/arm/dts/nuvoton-common-npcm7xx.dtsi create mode 100644 arch/arm/dts/nuvoton-npcm750-evb.dts create mode 100644 arch/arm/dts/nuvoton-npcm750-pincfg-evb.dtsi create mode 100644 arch/arm/dts/nuvoton-npcm750.dtsi create mode 100644 arch/arm/include/asm/arch-npcm7xx/gcr.h create mode 100644 arch/arm/mach-npcm/Kconfig create mode 100644 arch/arm/mach-npcm/Makefile create mode 100644 arch/arm/mach-npcm/npcm7xx/Kconfig create mode 100644 arch/arm/mach-npcm/npcm7xx/Makefile create mode 100644 arch/arm/mach-npcm/npcm7xx/cpu.c create mode 100644 arch/arm/mach-npcm/npcm7xx/l2_cache_pl310.c create mode 100644 arch/arm/mach-npcm/npcm7xx/l2_cache_pl310_init.S create mode 100644 board/nuvoton/poleg_evb/Kconfig create mode 100644 board/nuvoton/poleg_evb/MAINTAINERS create mode 100644 board/nuvoton/poleg_evb/Makefile create mode 100644 board/nuvoton/poleg_evb/poleg_evb.c create mode 100644 configs/poleg_evb_defconfig create mode 100644 drivers/clk/nuvoton/Makefile create mode 100644 drivers/clk/nuvoton/clk_npcm.c create mode 100644 drivers/clk/nuvoton/clk_npcm.h create mode 100644 drivers/clk/nuvoton/clk_npcm7xx.c create mode 100644 drivers/serial/serial_npcm.c create mode 100644 drivers/timer/npcm-timer.c create mode 100644 include/configs/poleg.h create mode 100644 include/dt-bindings/clock/nuvoton,npcm7xx-clock.h create mode 100644 include/dt-bindings/reset/nuvoton,npcm7xx-reset.h -- 2.17.1
[PATCH V3 0/4] imx: imx8m: enable DM SERIAL
From: Peng Fan V3: Add missed Signed-off-by Rebased to only add CONFIG_DM_SERIAL, not touch other config change in defconfig V2: Include imx8mq-evk in this patchset. For i.MX8MN/M/P, drop board level uart pinmux settings, move preloader_console_init after driver probe. Tested on all four boards. Note i.MX8MQ-EVK not have SPL_DM, so pinmux for uart still there for spl usage. Peng Fan (4): imx: imx8mp_evk: enable CONFIG_DM_SERIAL imx: imx8mm_evk: enable CONFIG_DM_SERIAL imx: imx8mn_evk: enable CONFIG_DM_SERIAL imx: imx8mq-evk: enable CONFIG_DM_SERIAL arch/arm/dts/imx8mq-evk-u-boot.dtsi | 32 + board/freescale/imx8mm_evk/spl.c| 12 ++ board/freescale/imx8mn_evk/spl.c| 12 ++ board/freescale/imx8mp_evk/imx8mp_evk.c | 8 --- configs/imx8mm_evk_defconfig| 1 + configs/imx8mn_ddr4_evk_defconfig | 1 + configs/imx8mn_evk_defconfig| 1 + configs/imx8mp_evk_defconfig| 1 + configs/imx8mq_evk_defconfig| 1 + 9 files changed, 41 insertions(+), 28 deletions(-) -- 2.35.1
[PATCH v3 0/4] Add a clock driver for the imx8mq
This is a DM clock driver for the imx8mq based on the linux kernel driver and the u-boot imx8mm clock driver. It also removes some code duplication in the imx8m[nmp] clock drivers. Changes since v2: Added kernel commit IDs Re-factored rate table code to remove duplication Remove duplicate code by creating a common clk-imx8m Changes since v1: More verbose clock driver description Added forgotten dt-bindings Synced PLL frequencies with mainline kernel Angus Ainslie (4): dt-bindings: imx8mq-clock: add mainline definitions clk: imx8mq: Add a clock driver for the imx8mq clk: imx8m: reduce rate table duplication clk: imx8m: remove code duplication drivers/clk/imx/Kconfig | 16 + drivers/clk/imx/Makefile | 8 +- drivers/clk/imx/clk-imx8m.c | 108 ++ drivers/clk/imx/clk-imx8m.h | 12 + drivers/clk/imx/clk-imx8mm.c | 149 +--- drivers/clk/imx/clk-imx8mn.c | 149 +--- drivers/clk/imx/clk-imx8mp.c | 156 +--- drivers/clk/imx/clk-imx8mq.c | 441 +++ drivers/clk/imx/clk-pll14xx.c| 44 +++ drivers/clk/imx/clk.h| 21 ++ include/dt-bindings/clock/imx8mq-clock.h | 16 +- 11 files changed, 688 insertions(+), 432 deletions(-) create mode 100644 drivers/clk/imx/clk-imx8m.c create mode 100644 drivers/clk/imx/clk-imx8m.h create mode 100644 drivers/clk/imx/clk-imx8mq.c -- 2.25.1
[PATCH v3 0/4] Add ESM driver support for AM64x R5 SPL/U-boot
AM64x devices have a main ESM and a MCU ESM. The ESM driver enables routing of the error events from various sources to different processors or to reset hardware logic. Only the MCU ESM's high output can trigger reset logic. The main RTI0 WWDT output can be routed to the MCU highoutput to trigger reset through the main ESM. For this reset to occur CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'. AM64x Technical Reference Manual - https://www.ti.com/lit/pdf/spruim2 Hari Nagalla (4): misc: k3_esm: Add functionality to set and route error events within K3SoC arm: dts: k3-am64: Add support for ESM device nodes arch: arm: mach-k3: am642_init: Probe ESM nodes configs: am64x_evm_r5_defconfig: Add support for ESM arch/arm/dts/k3-am64.dtsi| 1 + arch/arm/dts/k3-am642-r5-evm.dts | 19 arch/arm/dts/k3-am642-r5-sk.dts | 19 arch/arm/mach-k3/am642_init.c| 40 +--- configs/am64x_evm_r5_defconfig | 1 + drivers/misc/k3_esm.c| 53 ++-- 6 files changed, 126 insertions(+), 7 deletions(-) -- 2.17.1
Re: [PATCH v3 0/4] rockchip: sdhci: Fix reinit and add HS400 Enhanced Strobe support
On 21/01/2022 06:25, Simon Glass wrote: > On Sun, 16 Jan 2022 at 13:18, Alper Nebi Yasak > wrote: >> mmc: sdhci: Add HS400 Enhanced Strobe support >> rockchip: sdhci: Fix RK3399 eMMC PHY power cycling >> rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 >> rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 >> >> drivers/mmc/rockchip_sdhci.c | 136 --- >> drivers/mmc/sdhci.c | 18 + >> include/sdhci.h | 1 + >> 3 files changed, 145 insertions(+), 10 deletions(-) > > This looks great, but your 'kevin' patches do not seem to be applied > on master. What gives? I hope it's just Kever not finding the time to send a pull request for 2022.04. The latest u-boot-rockchip PR was about fixes for 2022.01 and didn't include those.
Re: [PATCH v3 0/4] rockchip: sdhci: Fix reinit and add HS400 Enhanced Strobe support
Hi Alper, On Sun, 16 Jan 2022 at 13:18, Alper Nebi Yasak wrote: > > My rk3399-gru-kevin has some problems with the eMMC. The board can boot > to U-Boot proper with the eMMC working at a low speed, but trying to > reinitialize it with "mmc dev 0" or "mmc rescan" makes it unusable. If > the HS400 mode is enabled, it times out while executing tuning and > doesn't even start at a working state. > > To work around these errors, I had implemented support for the HS400 > Enhanced Strobe mode as the first version of this series. I have also > managed the fix the issue above (related to power-cycling the eMMC PHY), > which exposed another one with this series: reinitialization at lower > speeds fail if the ES bit is set. Since fixing that needed changes to > this series I decided to send the previous fix as part of this instead > of as an independent patch. > > To test, I'm building with the following configs enabled: > > +CONFIG_MMC_SPEED_MODE_SET=y > [...] > CONFIG_MMC_PWRSEQ=y > +CONFIG_MMC_IO_VOLTAGE=y > +CONFIG_MMC_UHS_SUPPORT=y > +CONFIG_MMC_HS400_ES_SUPPORT=y > +CONFIG_MMC_HS400_SUPPORT=y > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_MMC_SDHCI=y > +CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_ROCKCHIP=y > > and running roughly: > > $ mmc rescan [0|1|3|10|11|12] > $ mmc info > $ mmc part > $ load mmc 0:1 0xd000 256MiB.bin > $ load mmc 0:1 0xd000 16MiB.bin > $ load mmc 0:1 0xd000 8MiB.bin > > I used to test by loading different sizes from a very big file (~7GiB), > but that's slower than reading fixed-size files for some reason I don't > know. I thought loading full files would be a better test so I switched > to those. Here's the differences in info and speeds I get with this: > > Mode | Bus Speed| Bus Width > ---+--+-- > MMC Legacy | 2500 | 8-bit > MMC High Speed (26MHz) | 2600 | 8-bit > MMC High Speed (52MHz) | 5200 | 8-bit > HS200 (200MHz) | 2| 8-bit > HS400 (200MHz) | 2| 8-bit DDR > HS400ES (200MHz) | 2| 8-bit DDR > > Mode | 256 MiB Load | 16 MiB Load | 8 MiB Load > ---+--+--+-- > MMC Legacy | ~22.1 MiB/s | ~21.9 MiB/s | ~21.6 MiB/s > MMC High Speed (26MHz) | ~22.1 MiB/s | ~21.9 MiB/s | ~21.6 MiB/s > MMC High Speed (52MHz) | ~43.7 MiB/s | ~42.8 MiB/s | ~41.7 MiB/s > HS200 (200MHz) | ~161.2 MiB/s | ~149.5 MiB/s | ~137.9 MiB/s > HS400 (200MHz) | ~254.5 MiB/s | ~235.3 MiB/s | ~216.2 MiB/s > HS400ES (200MHz) | ~254.7 MiB/s | ~238.8 MiB/s | ~216.2 MiB/s > > Hope I haven't missed anything. Enabling the configs above for each > board is left to board maintainers as I can't test on those boards. > > As an aside, I want to further clean up this driver when I have the time > (it's a weird combination of what could be three different drivers), but > wanted to send this as it at least gets the driver to a working state. > > Changes in v3: > - Set DWCMSHC_CARD_IS_EMMC bit in rk3568_emmc_phy_init() > > v2: https://patchwork.ozlabs.org/project/uboot/list/?series=280494 > > Changes in v2: > - Add patch to fix PHY power cycling at higher speeds > - Unset ES bit in rk3399 set_control_reg() to fix a reinit issue > - Don't use unnecessary & for function pointer in ops struct > - Rename rk3399_set_enhanced_strobe -> rk3399_sdhci_set_enhanced_strobe > - Rename rk3568_set_enhanced_strobe -> rk3568_sdhci_set_enhanced_strobe > - Let set_enhanced_strobe() unset the ES bit if mode is not HS400_ES > - Rewrote cover letter > > v1: https://patchwork.ozlabs.org/project/uboot/list/?series=269768 > > Alper Nebi Yasak (4): > mmc: sdhci: Add HS400 Enhanced Strobe support > rockchip: sdhci: Fix RK3399 eMMC PHY power cycling > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 > rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 > > drivers/mmc/rockchip_sdhci.c | 136 --- > drivers/mmc/sdhci.c | 18 + > include/sdhci.h | 1 + > 3 files changed, 145 insertions(+), 10 deletions(-) This looks great, but your 'kevin' patches do not seem to be applied on master. What gives? Regards, Simon
[RESEND PATCH v3 0/4] arm: kirkwood: Add support for Pogoplug V4
Pogoplug V4 specifications: Kirkwood 88F6192 SoC 800 MHz CPU 1Gbs Ethernet 128 MB RAM 128 MB NAND 1x USB 2.0 2x USB 3.0 (on PCIe bus) 1 SDHC slot 1x External SATA port (USM enclosure form factor slot) Changes in v3: - Migrate symbols from board include header to Kconfig - Squash board file small patches into one patch - Migrate config symbols from board include header to defconfig - Remove obsolete config symbols from header file - Don't use ifdefs for unselectable config symbols in header file Changes in v2: - Use mainline Linux DTS version - Move constants to .c file and remove header file - Use canonical format for defconfig file Tony Dinh (4): arm: kirkwood: Pogoplug-V4 : Add DTS files arm: kirkwood: Pogoplug-V4 : Add Kconfig files arm: kirkwood: Pogoplug-V4 : Add board implementation files arm: kirkwood: Pogoplug V4 : Add board include header and defconfig files arch/arm/dts/Makefile | 1 + arch/arm/dts/kirkwood-pogoplug-series-4.dts | 180 arch/arm/mach-kirkwood/Kconfig | 6 + board/cloudengines/pogo_v4/Kconfig | 16 ++ board/cloudengines/pogo_v4/MAINTAINERS | 6 + board/cloudengines/pogo_v4/Makefile | 10 + board/cloudengines/pogo_v4/kwbimage.cfg | 148 + board/cloudengines/pogo_v4/pogo_v4.c| 220 configs/pogo_v4_defconfig | 79 +++ include/configs/pogo_v4.h | 56 + 10 files changed, 722 insertions(+) create mode 100644 arch/arm/dts/kirkwood-pogoplug-series-4.dts create mode 100644 board/cloudengines/pogo_v4/Kconfig create mode 100644 board/cloudengines/pogo_v4/MAINTAINERS create mode 100644 board/cloudengines/pogo_v4/Makefile create mode 100644 board/cloudengines/pogo_v4/kwbimage.cfg create mode 100644 board/cloudengines/pogo_v4/pogo_v4.c create mode 100644 configs/pogo_v4_defconfig create mode 100644 include/configs/pogo_v4.h -- 2.30.2
[PATCH v3 0/4] arm: kirkwood: Add support for Pogoplug V4
Pogoplug V4 specifications: Kirkwood 88F6192 SoC 800 MHz CPU 1Gbs Ethernet 128 MB RAM 128 MB NAND 1x USB 2.0 2x USB 3.0 (on PCIe bus) 1 SDHC slot 1x External SATA port (USM enclosure form factor slot) Changes in v3: - Migrate config symbols from board include header to defconfig - Remove obsolete config symbols from header file - Don't use ifdefs for unselectable config symbols in header file - Migrate symbols from board include header to Kconfig - Squash board file small patches into one patch Changes in v2: - Use mainline Linux DTS version - Use canonical format for defconfig file - Move constants to .c file and remove header file Tony Dinh (4): arm: kirkwood: Pogoplug-V4 : Add DTS files arm: kirkwood: Pogoplug V4 : Add board include header and defconfig files arm: kirkwood: Pogoplug-V4 : Add Kconfig files arm: kirkwood: Pogoplug-V4 : Add board implementation files arch/arm/dts/Makefile | 1 + arch/arm/dts/kirkwood-pogoplug-series-4.dts | 180 arch/arm/mach-kirkwood/Kconfig | 6 + board/cloudengines/pogo_v4/Kconfig | 16 ++ board/cloudengines/pogo_v4/MAINTAINERS | 6 + board/cloudengines/pogo_v4/Makefile | 10 + board/cloudengines/pogo_v4/kwbimage.cfg | 148 + board/cloudengines/pogo_v4/pogo_v4.c| 220 configs/pogo_v4_defconfig | 79 +++ include/configs/pogo_v4.h | 56 + 10 files changed, 722 insertions(+) create mode 100644 arch/arm/dts/kirkwood-pogoplug-series-4.dts create mode 100644 board/cloudengines/pogo_v4/Kconfig create mode 100644 board/cloudengines/pogo_v4/MAINTAINERS create mode 100644 board/cloudengines/pogo_v4/Makefile create mode 100644 board/cloudengines/pogo_v4/kwbimage.cfg create mode 100644 board/cloudengines/pogo_v4/pogo_v4.c create mode 100644 configs/pogo_v4_defconfig create mode 100644 include/configs/pogo_v4.h -- 2.30.2
[PATCH v3 0/4] rockchip: sdhci: Fix reinit and add HS400 Enhanced Strobe support
My rk3399-gru-kevin has some problems with the eMMC. The board can boot to U-Boot proper with the eMMC working at a low speed, but trying to reinitialize it with "mmc dev 0" or "mmc rescan" makes it unusable. If the HS400 mode is enabled, it times out while executing tuning and doesn't even start at a working state. To work around these errors, I had implemented support for the HS400 Enhanced Strobe mode as the first version of this series. I have also managed the fix the issue above (related to power-cycling the eMMC PHY), which exposed another one with this series: reinitialization at lower speeds fail if the ES bit is set. Since fixing that needed changes to this series I decided to send the previous fix as part of this instead of as an independent patch. To test, I'm building with the following configs enabled: +CONFIG_MMC_SPEED_MODE_SET=y [...] CONFIG_MMC_PWRSEQ=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_ES_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_ROCKCHIP=y and running roughly: $ mmc rescan [0|1|3|10|11|12] $ mmc info $ mmc part $ load mmc 0:1 0xd000 256MiB.bin $ load mmc 0:1 0xd000 16MiB.bin $ load mmc 0:1 0xd000 8MiB.bin I used to test by loading different sizes from a very big file (~7GiB), but that's slower than reading fixed-size files for some reason I don't know. I thought loading full files would be a better test so I switched to those. Here's the differences in info and speeds I get with this: Mode | Bus Speed| Bus Width ---+--+-- MMC Legacy | 2500 | 8-bit MMC High Speed (26MHz) | 2600 | 8-bit MMC High Speed (52MHz) | 5200 | 8-bit HS200 (200MHz) | 2| 8-bit HS400 (200MHz) | 2| 8-bit DDR HS400ES (200MHz) | 2| 8-bit DDR Mode | 256 MiB Load | 16 MiB Load | 8 MiB Load ---+--+--+-- MMC Legacy | ~22.1 MiB/s | ~21.9 MiB/s | ~21.6 MiB/s MMC High Speed (26MHz) | ~22.1 MiB/s | ~21.9 MiB/s | ~21.6 MiB/s MMC High Speed (52MHz) | ~43.7 MiB/s | ~42.8 MiB/s | ~41.7 MiB/s HS200 (200MHz) | ~161.2 MiB/s | ~149.5 MiB/s | ~137.9 MiB/s HS400 (200MHz) | ~254.5 MiB/s | ~235.3 MiB/s | ~216.2 MiB/s HS400ES (200MHz) | ~254.7 MiB/s | ~238.8 MiB/s | ~216.2 MiB/s Hope I haven't missed anything. Enabling the configs above for each board is left to board maintainers as I can't test on those boards. As an aside, I want to further clean up this driver when I have the time (it's a weird combination of what could be three different drivers), but wanted to send this as it at least gets the driver to a working state. Changes in v3: - Set DWCMSHC_CARD_IS_EMMC bit in rk3568_emmc_phy_init() v2: https://patchwork.ozlabs.org/project/uboot/list/?series=280494 Changes in v2: - Add patch to fix PHY power cycling at higher speeds - Unset ES bit in rk3399 set_control_reg() to fix a reinit issue - Don't use unnecessary & for function pointer in ops struct - Rename rk3399_set_enhanced_strobe -> rk3399_sdhci_set_enhanced_strobe - Rename rk3568_set_enhanced_strobe -> rk3568_sdhci_set_enhanced_strobe - Let set_enhanced_strobe() unset the ES bit if mode is not HS400_ES - Rewrote cover letter v1: https://patchwork.ozlabs.org/project/uboot/list/?series=269768 Alper Nebi Yasak (4): mmc: sdhci: Add HS400 Enhanced Strobe support rockchip: sdhci: Fix RK3399 eMMC PHY power cycling rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3399 rockchip: sdhci: Add HS400 Enhanced Strobe support for RK3568 drivers/mmc/rockchip_sdhci.c | 136 --- drivers/mmc/sdhci.c | 18 + include/sdhci.h | 1 + 3 files changed, 145 insertions(+), 10 deletions(-) -- 2.34.1
[PATCH v3 0/4] rockchip: Improve support for Bob chromebook and add support for Kevin
I have recently started testing booting U-Boot from SPI on my gru-kevin (as opposed to chainloading it from vendor coreboot + depthcharge) and brought it to a better working state based on an initial support patch from Marty [1][2] and some follow-up work by Simon [3]. I tried to keep them as the git author when I took things from their work, but squashing other changes into those and rewriting commit messages makes things a bit weird in my opinion, especially for keeping their signoff. Do tell me if there is a better way to that. As the Kevin and Bob boards are very similar, I assumed the config and devicetree changes will be appropriate for Bob as well, and applied them to it first. I do not have a Bob, so could not test on one myself, but Simon did test an earlier version of this and it appears to work [4]. Other useful things for these boards: - Patch to fix a hang when usb controllers exit [5] (or [6]) - Series to support HS400ES mode as HS400 training fails [7] (but faster speeds are kept disabled in this series since v3) - Hack to skip eMMC reinitialization so it keeps working [8] [1] https://patchwork.ozlabs.org/patch/1053386/ [2] https://patchwork.ozlabs.org/comment/2488899/ [3] https://github.com/sjg20/u-boot/commits/kevin [4] https://patchwork.ozlabs.org/comment/2799106/ [5] https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icen...@aosc.io/ [6] https://patchwork.ozlabs.org/project/uboot/patch/20211224130549.20276-1-alpernebiya...@gmail.com/ [7] https://patchwork.ozlabs.org/project/uboot/list/?series=269768 [8] https://patchwork.ozlabs.org/comment/2779784/ Changes in v3: - Unset configs MMC_IO_VOLTAGE, MMC_UHS_SUPPORT, MMC_HS400_SUPPORT, MMC_HS400_ES_SUPPORT, MMC_SDHCI_SDMA. - Add tag: "Reviewed-by: Kever Yang " v2: https://patchwork.ozlabs.org/project/uboot/list/?series=276629 Changes in v2: - Drop unnecessary ifdef. - Clarify commit message regarding 'values set in coreboot'. - Rebase on u-boot/next, fixing conflict in board_debug_uart_init() v1: https://patchwork.ozlabs.org/project/uboot/list/?series=273848 Alper Nebi Yasak (2): rockchip: gru: Set up SoC IO domain registers rockchip: bob: Enable more configs Marty E. Plummer (1): rockchip: rk3399: Add support for chromebook_kevin Simon Glass (1): rockchip: gru: Add more devicetree settings arch/arm/dts/Makefile | 1 + arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi | 11 ++ arch/arm/dts/rk3399-gru-u-boot.dtsi | 55 + arch/arm/mach-rockchip/rk3399/Kconfig | 11 ++ arch/arm/mach-rockchip/rk3399/rk3399.c| 3 +- arch/arm/mach-rockchip/spl.c | 3 +- board/google/gru/Kconfig | 16 +++ board/google/gru/MAINTAINERS | 8 ++ board/google/gru/gru.c| 54 - configs/chromebook_bob_defconfig | 22 +++- configs/chromebook_kevin_defconfig| 111 ++ doc/board/rockchip/rockchip.rst | 1 + include/configs/gru.h | 3 + include/dt-bindings/input/linux-event-codes.h | 3 +- 14 files changed, 297 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/rk3399-gru-kevin-u-boot.dtsi create mode 100644 configs/chromebook_kevin_defconfig -- 2.34.1
[PATCH v3 0/4] sunxi: TOC0 image type support
This series adds support for the TOC0 image format used by the Allwinner secure boot ROM (SBROM). This series has been tested on the following SoCs/boards, with the eFuse burnt to enable secure mode: - A50: Ainol Q88 Tablet - A64: Pine A64 Plus - H5: Orange Pi Zero Plus - H6: Pine H64 Model B - H616: Orange Pi Zero 2 This time I also tested it on boards that are not switched to secure mode (with A64, H3, and H5). Due to both series changing Makefile.spl, the last patch depends on: https://patchwork.ozlabs.org/project/uboot/list/?series=267136 Changes in v3: - Selected TOOLS_LIBCRYPTO on all platforms that use kwbimage (as best as I can tell, using the suggestions from Pali Rohár) - Removed TOOLS_LIBCRYPTO selection for sunxi, since most boards do not need it - Added __packed to all new "ABI" structs - Added entry to MAINTAINERS for sunxi tools - Fixed offset of magic passed to memcmp - Refactored functions to not return pointers (fixes ambiguous NULL) Changes in v2: - Refactored the first patch on top of TOOLS_LIBCRYPTO - Moved certificate and key item structures out of sunxi_image.h - Renamed "main" and "item" variables for clarity - Improved error messages, and added a hint about key generation - Added a comment explaining the purpose of the various key files - Mentioned testing this code on A50 in the commit message - Moved SPL header signature checks out of sunxi_image.h - Refactored SPL header signature checks to use fewer casts - Rebase on top of Icenowy's RISC-V support series - Rename Kconfig symbols to include the full image type name Samuel Holland (4): tools: Separate image types which depend on OpenSSL tools: mkimage: Add Allwinner TOC0 support sunxi: Support SPL in both eGON and TOC0 images sunxi: Support building a SPL as a TOC0 image MAINTAINERS | 1 + arch/arm/Kconfig | 3 + arch/arm/include/asm/arch-sunxi/spl.h | 2 - arch/arm/mach-imx/mxs/Kconfig | 2 + arch/arm/mach-sunxi/Kconfig | 2 + arch/arm/mach-sunxi/board.c | 34 +- board/sunxi/Kconfig | 24 + common/image.c| 1 + include/image.h | 1 + include/sunxi_image.h | 37 ++ scripts/Makefile.spl | 5 +- scripts/config_whitelist.txt | 1 - tools/Makefile| 20 +- tools/mxsimage.c | 3 - tools/sunxi_toc0.c| 907 ++ 15 files changed, 1016 insertions(+), 27 deletions(-) create mode 100644 board/sunxi/Kconfig create mode 100644 tools/sunxi_toc0.c -- 2.32.0
[PATCH v3 0/4] mkimage: sunxi_egon: add riscv support
This patchset updates mkimage -T sunxi_egon to be able to generate an eGON.BT0 image for Allwinner RISC-V SoCs (e.g. D1). In addition, to keep the compatibility, it will still consider the architecture to be ARM when no architecture is specified. This v3 is a minor update to Icenowy's patch series, which I have also tested. Since the TOC0 patch series touches the same lines in Makefile.spl, it depends on this series. Changes in v3: - Factor out an egon_get_arch() function as suggested by Andre Icenowy Zheng (4): mkimage: add a flag to describe whether -A is specified mkimage: sunxi_egon: refactor for multi-architecture support mkimage: sunxi_egon: add support for riscv sunxi: specify architecture when generating SPL boot image scripts/Makefile.spl | 2 +- tools/imagetool.h| 1 + tools/mkimage.c | 1 + tools/sunxi_egon.c | 73 +++- 4 files changed, 69 insertions(+), 8 deletions(-) -- 2.32.0
[PATCH v3 0/4] efi_loader: centralize known vendor GUIDs
The UEFI specification defines which vendor GUIDs should be used for predefined variables like 'PK'. Currently we have multiple places where this relationship is stored. With this patch series a function for retrieving the GUID is provided and existing code is adjusted to used it. v3: Keep error handling in efi_sigstore_parse_sigdb() v2: Remove a superfluous value check. Adjust commit messages and comments in the code. Heinrich Schuchardt (4): efi_loader: treat UEFI variable name as const efi_loader: function to get GUID for variable name efi_loader: simplify efi_sigstore_parse_sigdb() efi_loader: simplify tcg2_measure_secure_boot_variable() include/efi_loader.h | 2 +- include/efi_variable.h| 27 +-- lib/efi_loader/efi_signature.c| 11 ++- lib/efi_loader/efi_tcg2.c | 31 ++- lib/efi_loader/efi_var_common.c | 14 -- lib/efi_loader/efi_var_mem.c | 7 --- lib/efi_loader/efi_variable.c | 9 + lib/efi_loader/efi_variable_tee.c | 16 ++-- 8 files changed, 69 insertions(+), 48 deletions(-) -- 2.32.0
[PATCH v3 0/4] Add octal DTR support for Macronix flash
This series add support for Macronix octal DTR flash, add second time Softreset with "INVERT" command extension type and follow linux kernel to enable 4byte opcode when possible. v3: Add flag SPI_NOR_CMD_EXT_INVERT to seperate command extension types. replace CONFIG_SPI_FLASH_MACRONIX with SPI_FLASH_MACRONIX_OCTAL for spi_nor_macronix_octal_dtr_enable function. v2: add ret checking for write enable in spi_nor_macronix_octal_dtr_enable function. JaimeLiao (4): mtd: spi-nor: macronix: add support for Macronix Octal mtd: spi-nor-core: Adding different type of command extension in Soft Reset mtd: spi-nor-core: set 4byte opcode when possible mtd: spi-nor-core: Add support for Macronix Octal flash drivers/mtd/spi/Kconfig| 13 + drivers/mtd/spi/spi-nor-core.c | 94 +- drivers/mtd/spi/spi-nor-ids.c | 22 +++- include/linux/mtd/spi-nor.h| 13 - 4 files changed, 138 insertions(+), 4 deletions(-) -- 2.17.1
Re: [PATCH v3 0/4] Support SiFive Composable cache driver
On Tue, Aug 17, 2021 at 5:08 PM Zong Li wrote: > > This patch set contains the SiFive composable cache support, and > indroduce an interface to do cache initialization, each platform can > overwrite it by their own implementation. > > Changed in v3: > - Combine some patches > - Drop the subdirectories of vendor in lib/ > - Rebase codebase > > Changed in v2: > - Refine the ccache driver by Sean's suggestions > - Introduce a common interface for cache initialization > > Zong Li (4): > cache: add sifive composable cache driver > riscv: lib: introduce a cache_init interface > board: sifive: use ccache driver instead of helper function > riscv: lib: modify the indent > > arch/riscv/Kconfig| 5 ++ > arch/riscv/cpu/fu540/Kconfig | 2 + > arch/riscv/cpu/fu540/Makefile | 1 - > arch/riscv/cpu/fu540/cache.c | 55 - > arch/riscv/cpu/fu740/Kconfig | 2 + > arch/riscv/cpu/fu740/Makefile | 1 - > arch/riscv/cpu/fu740/cache.c | 55 - > arch/riscv/include/asm/arch-fu540/cache.h | 14 - > arch/riscv/include/asm/arch-fu740/cache.h | 14 - > arch/riscv/include/asm/cache.h| 3 +- > arch/riscv/lib/Makefile | 1 + > arch/riscv/lib/cache.c| 5 ++ > arch/riscv/lib/sifive_cache.c | 27 > board/sifive/unleashed/unleashed.c| 12 +--- > board/sifive/unmatched/unmatched.c| 11 +--- > drivers/cache/Kconfig | 7 +++ > drivers/cache/Makefile| 1 + > drivers/cache/cache-sifive-ccache.c | 75 +++ > 18 files changed, 131 insertions(+), 160 deletions(-) > delete mode 100644 arch/riscv/cpu/fu540/cache.c > delete mode 100644 arch/riscv/cpu/fu740/cache.c > delete mode 100644 arch/riscv/include/asm/arch-fu540/cache.h > delete mode 100644 arch/riscv/include/asm/arch-fu740/cache.h > create mode 100644 arch/riscv/lib/sifive_cache.c > create mode 100644 drivers/cache/cache-sifive-ccache.c > > -- > 2.32.0 > ping
[PATCH v3 0/4] Support SiFive Composable cache driver
This patch set contains the SiFive composable cache support, and indroduce an interface to do cache initialization, each platform can overwrite it by their own implementation. Changed in v3: - Combine some patches - Drop the subdirectories of vendor in lib/ - Rebase codebase Changed in v2: - Refine the ccache driver by Sean's suggestions - Introduce a common interface for cache initialization Zong Li (4): cache: add sifive composable cache driver riscv: lib: introduce a cache_init interface board: sifive: use ccache driver instead of helper function riscv: lib: modify the indent arch/riscv/Kconfig| 5 ++ arch/riscv/cpu/fu540/Kconfig | 2 + arch/riscv/cpu/fu540/Makefile | 1 - arch/riscv/cpu/fu540/cache.c | 55 - arch/riscv/cpu/fu740/Kconfig | 2 + arch/riscv/cpu/fu740/Makefile | 1 - arch/riscv/cpu/fu740/cache.c | 55 - arch/riscv/include/asm/arch-fu540/cache.h | 14 - arch/riscv/include/asm/arch-fu740/cache.h | 14 - arch/riscv/include/asm/cache.h| 3 +- arch/riscv/lib/Makefile | 1 + arch/riscv/lib/cache.c| 5 ++ arch/riscv/lib/sifive_cache.c | 27 board/sifive/unleashed/unleashed.c| 12 +--- board/sifive/unmatched/unmatched.c| 11 +--- drivers/cache/Kconfig | 7 +++ drivers/cache/Makefile| 1 + drivers/cache/cache-sifive-ccache.c | 75 +++ 18 files changed, 131 insertions(+), 160 deletions(-) delete mode 100644 arch/riscv/cpu/fu540/cache.c delete mode 100644 arch/riscv/cpu/fu740/cache.c delete mode 100644 arch/riscv/include/asm/arch-fu540/cache.h delete mode 100644 arch/riscv/include/asm/arch-fu740/cache.h create mode 100644 arch/riscv/lib/sifive_cache.c create mode 100644 drivers/cache/cache-sifive-ccache.c -- 2.32.0
[PATCH v3 0/4] sf: Add documentation and an 'sf mmap' command
This little series adds documentation and a few other tidy-ups to the 'sf' command. It also provides a way to access memory-mapped SPI via the command line. Changes in v3: - Add configuration and return value also Changes in v2: - Explain why 'usage' cannot be const - Many fixes as suggested by Heinrich Simon Glass (4): command: Use a constant pointer for the help sf: Tidy up code to avoid #ifdef sf: doc: Add documentation for the 'sf' command sf: Provide a command to access memory-mapped SPI arch/Kconfig| 2 + cmd/Kconfig | 8 ++ cmd/sf.c| 67 +++--- doc/usage/index.rst | 1 + doc/usage/sf.rst| 304 include/command.h | 2 +- 6 files changed, 365 insertions(+), 19 deletions(-) create mode 100644 doc/usage/sf.rst -- 2.32.0.554.ge1b32706d8-goog
[PATCH v3 0/4] Allwinner H6 USB3 support
This series adds PHY and XHCI driver support for the USB3 controller found in the Allwinner H6 SoC. It has been tested and working on both boards enabled in patch 4, although some users experience issues[1]. [1]: https://lists.denx.de/pipermail/u-boot/2021-February/440767.html Changes from v2: - Fix xhci-pci.c compilation (RPi4 and other boards) Changes from v1: - Dropped patches 1-2 (already in u-boot-sunxi/master) and rebased - Added Andre's Reviewed-by on the PHY driver - Fixed error handling in xhci_pci_probe Samuel Holland (4): phy: sun50i-usb3: Add a driver for the H6 USB3 PHY usb: xhci-pci: Move reset logic out of XHCI core usb: xhci-dwc3: Add support for clocks/resets configs: Enable USB3 on Allwinner H6 boards configs/orangepi_3_defconfig| 5 + configs/pine_h64_defconfig | 5 + drivers/phy/allwinner/Kconfig | 8 ++ drivers/phy/allwinner/Makefile | 1 + drivers/phy/allwinner/phy-sun50i-usb3.c | 171 drivers/usb/host/xhci-dwc3.c| 56 drivers/usb/host/xhci-mem.c | 2 - drivers/usb/host/xhci-pci.c | 52 ++- drivers/usb/host/xhci.c | 35 - include/usb/xhci.h | 2 - 10 files changed, 294 insertions(+), 43 deletions(-) create mode 100644 drivers/phy/allwinner/phy-sun50i-usb3.c -- 2.17.5
[PATCH v3 0/4] board: imx8mm: Add Engicam i.Core MX8M Mini SoM
Patch series for Engicam i.Core MX8M Mini SOM and it's associated carrier board dts(i) support. patch 1: add imx8mm-u-boot.dtsi patch 2: Engicam i.Core MX8M Mini SoM dtsi patch 3-4: EDIMM2.2, C.TOUCH 2.0 Carrier boards Changes for v3: - rebase on master - drop header improvement patch Changes for v2: - add Linux commit sha1 in commit messages. Any inputs? Jagan. Jagan Teki (4): arm64: dts: imx8mm: Add common -u-boot.dtsi arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini SoM board: imx8mm: Add Engicam i.Core MX8M Mini EDIMM2.2 Starter Kit board: imx8mm: Add Engicam i.Core MX8M Mini C.TOUCH 2.0 arch/arm/dts/Makefile |2 + arch/arm/dts/imx8mm-beacon-kit-u-boot.dtsi| 37 +- arch/arm/dts/imx8mm-evk-u-boot.dtsi | 37 +- .../imx8mm-icore-mx8mm-ctouch2-u-boot.dtsi| 31 + arch/arm/dts/imx8mm-icore-mx8mm-ctouch2.dts | 97 + .../imx8mm-icore-mx8mm-edimm2.2-u-boot.dtsi | 31 + arch/arm/dts/imx8mm-icore-mx8mm-edimm2.2.dts | 97 + arch/arm/dts/imx8mm-icore-mx8mm-u-boot.dtsi | 27 + arch/arm/dts/imx8mm-icore-mx8mm.dtsi | 232 +++ arch/arm/dts/imx8mm-u-boot.dtsi | 39 + arch/arm/dts/imx8mm-venice-gw700x-u-boot.dtsi | 35 +- arch/arm/dts/imx8mm-venice-u-boot.dtsi| 37 +- arch/arm/dts/imx8mm-verdin-u-boot.dtsi| 38 +- arch/arm/dts/phycore-imx8mm-u-boot.dtsi | 37 +- arch/arm/mach-imx/imx8m/Kconfig | 19 + board/engicam/imx8mm/Kconfig | 14 + board/engicam/imx8mm/MAINTAINERS | 13 + board/engicam/imx8mm/Makefile | 12 + board/engicam/imx8mm/icore_mx8mm.c| 85 + board/engicam/imx8mm/lpddr4_timing.c | 1846 + board/engicam/imx8mm/spl.c| 101 + configs/imx8mm-icore-mx8mm-ctouch2_defconfig | 92 + configs/imx8mm-icore-mx8mm-edimm2.2_defconfig | 92 + include/configs/imx8mm_icore_mx8mm.h | 100 + 24 files changed, 2942 insertions(+), 209 deletions(-) create mode 100644 arch/arm/dts/imx8mm-icore-mx8mm-ctouch2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-icore-mx8mm-ctouch2.dts create mode 100644 arch/arm/dts/imx8mm-icore-mx8mm-edimm2.2-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-icore-mx8mm-edimm2.2.dts create mode 100644 arch/arm/dts/imx8mm-icore-mx8mm-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-icore-mx8mm.dtsi create mode 100644 arch/arm/dts/imx8mm-u-boot.dtsi create mode 100644 board/engicam/imx8mm/Kconfig create mode 100644 board/engicam/imx8mm/MAINTAINERS create mode 100644 board/engicam/imx8mm/Makefile create mode 100644 board/engicam/imx8mm/icore_mx8mm.c create mode 100644 board/engicam/imx8mm/lpddr4_timing.c create mode 100644 board/engicam/imx8mm/spl.c create mode 100644 configs/imx8mm-icore-mx8mm-ctouch2_defconfig create mode 100644 configs/imx8mm-icore-mx8mm-edimm2.2_defconfig create mode 100644 include/configs/imx8mm_icore_mx8mm.h -- 2.25.1
[PATCH v3 0/4] psci: add support for SYSTEM_RESET2 and PSCI_FEATURES
From: Igor Opaniuk 1. Adds support for: * PSCI_FEATURES, introduced in PSCI 1.0. This provides API that allows discovering whether a specific PSCI function is implemented and its features. * SYSTEM_RESET2, introduced in PSCI 1.1, which extends existing SYSTEM_RESET. It provides support for vendor-specific resets, providing reset_type as an additional param. 2. PSCI sysreset driver is refactored to use new API. 3. do_reset cmd is extended, optional param added for providing type of reset CI: https://dev.azure.com/igoropaniuk/u-boot/_build/results?buildId=20=results Changes in v3: - Drop RFC tag - Add usage doc for reset cmd - Reimplement param handling for reset cmd - Droped updates in reset usage string Changes in v2: - do_reset cmd updates Igor Opaniuk (4): psci: add features/reset2 support sysreset: psci: use psci driver exported functions sysreset: provide type of reset in do_reset cmd doc: usage: add usage details for reset cmd cmd/boot.c | 2 +- doc/usage/index.rst| 1 + doc/usage/reset.rst| 26 drivers/firmware/psci.c| 68 ++ drivers/sysreset/sysreset-uclass.c | 11 - drivers/sysreset/sysreset_psci.c | 8 +--- include/linux/psci.h | 3 ++ 7 files changed, 111 insertions(+), 8 deletions(-) create mode 100644 doc/usage/reset.rst -- 2.25.1
[PATCH v3 0/4] Move qfw to DM, add Arm support
Version 3 of this series moves the QFW driver into a uclass, UCLASS_QFW, and splits the driver into qfw_pio and qfw_mmio. The ugly arch-specific ifdefs are now gone, since regular Makefile conditional compilation of each driver takes care of it for us. As before, on x86 a U_BOOT_DRVINFO is used to configure the qfw_pio driver, otherwise we configure qfw_mmio from device tree if present. I continue to test this on arm64 and x86_64 qemu. A sandbox driver is also included, and a DM unit test for it. A test that runs in the qemu platform is still yet to come -- I wanted to submit this ahead of that for more feedback. One question: how much should I roll these patches together? The first introduces a few changes that are immediately superceded by the second, but maybe it's helpful for review? To view the changes online, see: https://git.src.kameliya.ee/~kameliya/u-boot/log/qfw-priv Changes in v3: - ARCH_QEMU now implies CMD_QFW, not QFW - rename qemu_fwcfg_read_entry_pio to ..._io Asherah Connor (4): arm: x86: qemu: move qfw to DM, include Arm support arm: x86: qemu: add UCLASS_QFW, split driver into _pio and _mmio arm: x86: qemu: unify qfw driver functions as qfw_ qemu: add sandbox driver and tests arch/arm/Kconfig | 1 + arch/sandbox/dts/sandbox.dtsi | 4 + arch/sandbox/dts/test.dts | 4 + arch/x86/cpu/qemu/cpu.c | 7 +- arch/x86/cpu/qemu/qemu.c | 52 ++-- arch/x86/cpu/qfw_cpu.c| 11 +- cmd/qfw.c | 56 common/Makefile | 2 + common/qfw.c | 111 drivers/misc/Makefile | 7 +- drivers/misc/qfw.c| 239 -- drivers/misc/qfw_mmio.c | 101 ++ drivers/misc/qfw_pio.c| 66 ++ drivers/misc/qfw_sandbox.c| 129 ++ include/dm/uclass-id.h| 1 + include/qfw.h | 90 + test/dm/Makefile | 1 + test/dm/qfw.c | 42 ++ 18 files changed, 665 insertions(+), 259 deletions(-) create mode 100644 common/qfw.c create mode 100644 drivers/misc/qfw_mmio.c create mode 100644 drivers/misc/qfw_pio.c create mode 100644 drivers/misc/qfw_sandbox.c create mode 100644 test/dm/qfw.c -- 2.20.1
[PATCH v3 0/4] console: remove #ifdef CONFIG when it is possible
Hi, It is the V3 of serie [1] after Simon Glass comments. Use 'if (IS_ENABLED(CONFIG...))' instead of '#if or #ifdef' where possible This patchset can applied on master branch after the serie [2] (for the new order of test in function putc() and puts() done in "console: allow to record console output before ready" ) For information: I try to remove the sandox code in [3] (with the associated tests #ifdef CONFIG_SANDBOX) but it wasn't a correct idea. I will pushed a separate serie to remove the remaining #ifdef CONFIG_VIDCONSOLE_AS_LCD [4] [1] http://patchwork.ozlabs.org/project/uboot/list/?series=218309 [2] http://patchwork.ozlabs.org/project/uboot/list/?series=217079 "log: don't build the trace buffer when log is not ready" [3] http://patchwork.ozlabs.org/project/uboot/patch/20201127114927.2.Ida70f4fb1524187703e9240d63e436f8ae5adaab@changeid/ "[2/2] console: sandbox: remove unnecessary sandbox code" [4] http://patchwork.ozlabs.org/project/uboot/list/?series=218307 "video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME" Changes in v3: - update commit message with new function name console_has_tstc Changes in v2: - update also #ifdef CONFIG_SANDBOX after Simon Glass remark (code can't be removed to avoid to rely sandbox on debug uart) - move the tests on gd->flags & GD_FLG_RECORD in helper functions - remove test on IS_ENABLED(CONFIG_CONSOLE_RECORD) before to call helper functions - add comment for tstcdev variable - rename console_tstc_check to console_has_tstc Patrick Delaunay (4): console: remove #ifdef CONFIG when it is possible console: add function console_devices_set console: remove #ifdef CONFIG_CONSOLE_RECORD console: add console_has_tstc helper function for CONSOLE_MUX common/console.c | 310 ++- 1 file changed, 175 insertions(+), 135 deletions(-) -- 2.17.1
[PATCH v3 0/4] Add Renesas SoC identification driver support
This patch series aims to support Renesas SoC identification driver. Added a helper function of_match_node to find the matching of_match structure. This helper function can be used to replace the following code in u-boot [1] and [2] [1] https://elixir.bootlin.com/u-boot/latest/source/drivers/serial/serial_uniphier.c#L129 [2] https://elixir.bootlin.com/u-boot/latest/source/drivers/usb/phy/rockchip_usb2_phy.c#L77 Also added soc_id attribute support in UCLASS_SOC which is required for Renesas SoC identification driver similar to mainline linux. Biju Das (4): dm: core: Add of_match_node helper function soc: Fix comments from SOC to SoC dm: soc: Add SoC id for attribute matching dm: soc: SoC identification driver for Renesas SoC's drivers/core/device.c | 21 drivers/soc/Kconfig | 7 ++ drivers/soc/Makefile | 1 + drivers/soc/soc-uclass.c | 19 ++- drivers/soc/soc_renesas.c | 239 ++ drivers/soc/soc_sandbox.c | 8 ++ include/dm/device.h | 13 +++ include/soc.h | 39 ++- test/dm/core.c| 31 + test/dm/soc.c | 8 ++ 10 files changed, 379 insertions(+), 7 deletions(-) create mode 100644 drivers/soc/soc_renesas.c -- 2.17.1
Re: [PATCH v3 0/4] arm64: Large PIE fixes
Hi, On 09. 09. 20 19:07, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > This fixes some build issues with large (> 1MB) PIE U-Boot setups. > We also document the 4K aligned load address requirement and > add an early run-time check for it. > > As requested by reviewers, I've also added a runtime check for > non-PIE builds to trap the startup sequence early if the start > address doesn't match between run-time and link-time. > > Cheers, > Edgar > > ChangeLog: > v2 -> v3: > * Add non-PIE start address (run vs link-time) check > * Move 4K aligment Kconfig help description > * Fix load of __bss_start > * Use x0 rather than x1 in PIE load-address check > * Add missing tabs > * Add load-address check for non-PIE > * U-boot -> U-Boot in a few places > * Tweak commit messages > > v1 -> v2: > * Fix adr of _start in arch/arm/lib/crt0_64.S > * Add early check and bail out into a WFI loop when not 4K aligned > * Document the 4K alignement requirement in Kconfig > > Edgar E. Iglesias (4): > arm64: Mention 4K aligned load addresses in the PIE Kconfig help > arm64: Trap PIE builds early if load address is not 4K aligned > arm64: Add support for larger PIE U-Boot > arm64: Trap non-PIE builds early if starting from wrong address > > arch/arm/Kconfig | 4 ++-- > arch/arm/cpu/armv8/start.S | 36 ++-- > arch/arm/lib/crt0_64.S | 8 +++- > 3 files changed, 43 insertions(+), 5 deletions(-) > Because these changes are made for supporting Xilinx SOCs 1-3 applied to my tree. Patch 4 is dropped as was agreed. 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 v3 0/4] arm64: Large PIE fixes
On 9/9/20 11:07 AM, Edgar E. Iglesias wrote: > From: "Edgar E. Iglesias" > > This fixes some build issues with large (> 1MB) PIE U-Boot setups. > We also document the 4K aligned load address requirement and > add an early run-time check for it. > > As requested by reviewers, I've also added a runtime check for > non-PIE builds to trap the startup sequence early if the start > address doesn't match between run-time and link-time. The series, Reviewed-by: Stephen Warren
[PATCH v3 0/4] arm64: Large PIE fixes
From: "Edgar E. Iglesias" This fixes some build issues with large (> 1MB) PIE U-Boot setups. We also document the 4K aligned load address requirement and add an early run-time check for it. As requested by reviewers, I've also added a runtime check for non-PIE builds to trap the startup sequence early if the start address doesn't match between run-time and link-time. Cheers, Edgar ChangeLog: v2 -> v3: * Add non-PIE start address (run vs link-time) check * Move 4K aligment Kconfig help description * Fix load of __bss_start * Use x0 rather than x1 in PIE load-address check * Add missing tabs * Add load-address check for non-PIE * U-boot -> U-Boot in a few places * Tweak commit messages v1 -> v2: * Fix adr of _start in arch/arm/lib/crt0_64.S * Add early check and bail out into a WFI loop when not 4K aligned * Document the 4K alignement requirement in Kconfig Edgar E. Iglesias (4): arm64: Mention 4K aligned load addresses in the PIE Kconfig help arm64: Trap PIE builds early if load address is not 4K aligned arm64: Add support for larger PIE U-Boot arm64: Trap non-PIE builds early if starting from wrong address arch/arm/Kconfig | 4 ++-- arch/arm/cpu/armv8/start.S | 36 ++-- arch/arm/lib/crt0_64.S | 8 +++- 3 files changed, 43 insertions(+), 5 deletions(-) -- 2.25.1
[PATCH v3 0/4] fs/squashfs: Add new decompression algorithms
Hello, Following the SquashFS support, this series adds support for LZO and ZSTD algorithms. Changes in v3: - Reorganize patches order. - Remove memory leak from sqfs_zstd_decompress(). Changes in v2: - Change tests architecture. - Add tests for LZO and ZSTD. - Skip compression algorithms unsupported by the host's squashfs-tools version. - Add sqfs_decompress_init() and sqfs_decompress_cleanup() to SquashFS support. Joao Marcos Costa (4): fs/squashfs: Add init. and clean-up functions to decompression fs/squashfs: add support for ZSTD decompression fs/squashfs: add support for LZO decompression test/py: Add tests for LZO and ZSTD fs/squashfs/sqfs.c| 87 --- fs/squashfs/sqfs_decompressor.c | 103 +- fs/squashfs/sqfs_decompressor.h | 3 + fs/squashfs/sqfs_filesystem.h | 12 +- .../test_fs/test_squashfs/sqfs_common.py | 76 + .../test_fs/test_squashfs/test_sqfs_load.py | 40 --- .../test_fs/test_squashfs/test_sqfs_ls.py | 33 -- 7 files changed, 261 insertions(+), 93 deletions(-) -- 2.17.1
[PATCH v3 0/4] Support for specifying extra IOMMU mappings for PCI
From: Laurentiu Tudor In the current implementation, u-boot creates iommu mappings only for PCI devices enumarated at boot time thus does not take into account more dynamic scenarios such as SR-IOV or PCI hot-plug. Add support for specifying extra IOMMU mappings for PCI controllers through a special env var called "pci_iommu_extra" or through a device tree property named "pci-iommu-extra" placed in the node describing the PCI controller. More detailed information can be found in the final patch. Changes in v3: - rebased - trimmed commit message of the last patch - minor adjustments to the readme file Changes in v2: - add ARI support and use it by default - option to disable ARI - fixes in BDF calculation - reorganized code a bit - added more comments Laurentiu Tudor (4): pci: layerscape: move per-pci device fdt fixup in a function pci: layerscape: move pci node search in a common function pci: add a few ARI and SRIOV related defines pci: layerscape: add a way of specifying additional iommu mappings .../fsl-layerscape/doc/README.pci_iommu_extra | 67 +++ drivers/pci/Kconfig | 12 + drivers/pci/pcie_layerscape_fixup.c | 450 +++--- include/pci.h | 14 + 4 files changed, 482 insertions(+), 61 deletions(-) create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra -- 2.17.1
Re: [PATCH v3 0/4] spi: kirkwood: dm-conversion (part4)
On Fri, Jun 19, 2020 at 8:31 PM Chris Packham wrote: > > Hi Jagan, > > On Fri, 19 Jun 2020, 5:45 AM Jagan Teki, wrote: >> >> Series of kirkwood boards to switch DM_SPI and drop >> which are not DM enabled still. >> >> Any inputs? >> Jagan. > > > I had a quick glance over the series and it looks good to me. > > I'm fortunate enough to be able to get into the office so I'll try and give > this a spin on the kirkwood board I have on Monday. > Tooks a bit longer to dust off the kirkwood board than I expected. For this series Tested-by: Chris Packham
[PATCH v3 0/4] mips: Add initial Octeon MIPS64 base support
This patch adds very basic support for the Octeon III SoCs. Only CFI parallel UART, reset and NOR flash are supported for now. Please note that the basic Octeon port does not include the DDR3/4 initialization yet. This will be added in some follow-up patches later. To still use U-Boot on with this port, the L2 cache (4MiB on Octeon III CN73xx) is used as RAM. This way, U-Boot can boot to the prompt on such boards. v3: This version is based on the MIPS start.S rework and Linux header sync from Daniel using this branch: u-boot-mips/header_sync_v2 I removed the very early copy to to L2 cache for now to make the integration into mainline easier. With all the patches already applied and the Linux header sync, the resulting patchset is much smaller. Thanks, Stefan Changes in v3: - Don't "relocate" to L2 cache for now - Remove inclusion of "common.h" - Remove inclusion of "common.h" - Slightly change some copyright messages (adjust year) Changes in v2: - Remove custom start.S and use common start.S. Minimal custom lowlevel init code is currently added in the custom lowlevel_init.S. This needs to be extended with necessary code, like errata handling etc. But for a very first basic port, this seems to be all thats needed to boot on the EBB7304 to the prompt. - Removed select CREATE_ARCH_SYMLINK - Removed Octeon II support, as its currently no added in this patchset - Added cache.c to add the platform specific cache functions as no-ops for Octeon as the platform is cache coherent - Removed CONFIG_MIPS_CACHE_COHERENT - Added CONFIG_CPU_CAVIUM_OCTEON to Kconfig and selected it for Octeon to enable better sync with the Linux files in the future - Add get_tbclk() -> no need to define CONFIG_SYS_MIPS_TIMER_FREQ any more - Removed CONFIG_SYS_MIPS_TIMER_FREQ Aaron Williams (1): mips: octeon: Initial minimal support for the Marvell Octeon SoC Stefan Roese (3): sysreset: Add Octeon sysreset driver mips: octeon: dts: Add Octeon 3 cn73xx base dtsi file mips: octeon: Add minimal Octeon 3 EBB7304 EVK support MAINTAINERS | 7 ++ arch/mips/Kconfig | 41 arch/mips/Makefile| 3 + arch/mips/dts/Makefile| 1 + arch/mips/dts/mrvl,cn73xx.dtsi| 64 + arch/mips/dts/mrvl,octeon-ebb7304.dts | 96 +++ arch/mips/mach-octeon/Kconfig | 60 arch/mips/mach-octeon/Makefile| 10 ++ arch/mips/mach-octeon/cache.c | 20 arch/mips/mach-octeon/clock.c | 27 ++ arch/mips/mach-octeon/cpu.c | 57 +++ arch/mips/mach-octeon/dram.c | 28 ++ arch/mips/mach-octeon/include/ioremap.h | 30 ++ arch/mips/mach-octeon/include/mach/cavm-reg.h | 42 arch/mips/mach-octeon/include/mach/clock.h| 22 + arch/mips/mach-octeon/lowlevel_init.S | 19 board/Marvell/octeon_ebb7304/Kconfig | 19 board/Marvell/octeon_ebb7304/MAINTAINERS | 7 ++ board/Marvell/octeon_ebb7304/Makefile | 8 ++ board/Marvell/octeon_ebb7304/board.c | 9 ++ configs/octeon_ebb7304_defconfig | 37 +++ drivers/sysreset/Kconfig | 7 ++ drivers/sysreset/Makefile | 1 + drivers/sysreset/sysreset_octeon.c| 52 ++ include/configs/octeon_common.h | 25 + include/configs/octeon_ebb7304.h | 20 scripts/config_whitelist.txt | 1 - 27 files changed, 712 insertions(+), 1 deletion(-) create mode 100644 arch/mips/dts/mrvl,cn73xx.dtsi create mode 100644 arch/mips/dts/mrvl,octeon-ebb7304.dts create mode 100644 arch/mips/mach-octeon/Kconfig create mode 100644 arch/mips/mach-octeon/Makefile create mode 100644 arch/mips/mach-octeon/cache.c create mode 100644 arch/mips/mach-octeon/clock.c create mode 100644 arch/mips/mach-octeon/cpu.c create mode 100644 arch/mips/mach-octeon/dram.c create mode 100644 arch/mips/mach-octeon/include/ioremap.h create mode 100644 arch/mips/mach-octeon/include/mach/cavm-reg.h create mode 100644 arch/mips/mach-octeon/include/mach/clock.h create mode 100644 arch/mips/mach-octeon/lowlevel_init.S create mode 100644 board/Marvell/octeon_ebb7304/Kconfig create mode 100644 board/Marvell/octeon_ebb7304/MAINTAINERS create mode 100644 board/Marvell/octeon_ebb7304/Makefile create mode 100644 board/Marvell/octeon_ebb7304/board.c create mode 100644 configs/octeon_ebb7304_defconfig create mode 100644 drivers/sysreset/sysreset_octeon.c create mode 100644 include/configs/octeon_common.h create mode 100644 include/configs/octeon_ebb7304.h -- 2.27.0
RE: [PATCH v3 0/4] update clock handler and proper cpu features
Hello Rick,
> -Original Message-
> From: Rick Chen
> Sent: Friday, June 19, 2020 1:26 PM
> To: Sagar Kadam
> Cc: U-Boot Mailing List ; Lukasz Majewski
> ; Bin Meng ; Jagan Teki
> ; Pragnesh Patel
> ; Anup Patel ; Simon
> Glass ; Sean Anderson ; rick
> ; ycli...@andestech.com; Alan Kao
>
> Subject: Re: [PATCH v3 0/4] update clock handler and proper cpu features
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> Hi Sagar
>
> > From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> > Sent: Thursday, June 04, 2020 6:45 PM
> > To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志); lu...@denx.de
> > Cc: bmeng...@gmail.com; ja...@amarulasolutions.com;
> pragnesh.pa...@sifive.com; anup.pa...@wdc.com; s...@chromium.org;
> sean...@gmail.com; Sagar Shrikant Kadam
> > Subject: [PATCH v3 0/4] update clock handler and proper cpu features
> >
> > U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing
> clk_request and free handlers.
> > The current "cpu detail" sometimes shows "Microcode" as a feature,
> which is not the case with FU540-C000 on HiFive Unleashed board.
> >
> > Patch 1: add clk request handler to check if valid clock id is requested.
> > Patch 2: add cpu node aliases.
> > Patch 3: Correctly parse and update mmu-type.
> >
> > RISC-V core's on FU540-C000 SoC have separate instruction and data
> (split)
> > L1 cache.
> > Patch 4:Use i-cache-size dt property as one of identifier to indicate a
> > split cache is available.
> >
> > I have picked few dependent patches from Sean's and Pragnesh's latest
> series from here [1]...[5].
> >
> > These have applied on mainline U-Boot commit 0d8f35b58cc8 ("Merge
> https://gitlab.denx.de/u-boot/custodians/u-boot-spi;)
> >
> > Patch history:
> > =
> > V3:
> > 1. Included the cosmetic change as suggested
> >s/L1 feature/L1 cache feature/
> > 2. Added Reviewed-By tags
> >
> > V2:
> > 1. Incorporate review comments from Bin and Sean Anderson.
> >and dropped 2nd patch as similar work was already done in [1] and [2]
> > 2 Add cpu node aliases to display cpu node's in sequence.
> > 3. Add fix to show mmu as available cpu feature.
> > 4. Check and append L1 cache feature.
> >
> > V1: Base version
> > Thanks to Vincent Chen for testing the V1
> > version of this series.
> >
> > [1] https://patchwork.ozlabs.org/patch/1295345
> > [2] https://patchwork.ozlabs.org/patch/1295346
> > [3] https://patchwork.ozlabs.org/patch/1300369
> > [4] https://patchwork.ozlabs.org/patch/1300370
> > [5] https://patchwork.ozlabs.org/patch/1300373
> >
> > All these together is available here:
> > https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v3
> >
> > Sagar Shrikant Kadam (4):
> > fu540: prci: add request and free clock handlers
> > riscv: dts: hifive-unleashed-a00: add cpu aliases
> > riscv: cpu: fixes to display proper CPU features
> > riscv: cpu: check and append L1 cache to cpu features
> >
> > arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 5 +
> > drivers/clk/sifive/fu540-prci.c | 21 +
> > drivers/cpu/riscv_cpu.c | 10 +-
> > 3 files changed, 35 insertions(+), 1 deletion(-)
>
>
> I am trying to apply to u-boot/master, but it fail as below:
> Applying: fu540: prci: add request and free clock handlers
> error: patch failed: drivers/clk/sifive/fu540-prci.c:581
> error: drivers/clk/sifive/fu540-prci.c: patch does not apply
> Patch failed at 0001 fu540: prci: add request and free clock handlers
>
> Please rebase master, I will sync to master later.
>
Sure, I will rebase and resend this series on master
Thanks & BR,
Sagar
> Thanks,
> Rick
>
> >
> > --
> > 2.7.4
> >
Re: [PATCH v3 0/4] spi: kirkwood: dm-conversion (part4)
Hi Jagan, On Fri, 19 Jun 2020, 5:45 AM Jagan Teki, wrote: > Series of kirkwood boards to switch DM_SPI and drop > which are not DM enabled still. > > Any inputs? > Jagan. > I had a quick glance over the series and it looks good to me. I'm fortunate enough to be able to get into the office so I'll try and give this a spin on the kirkwood board I have on Monday. Bhargav Shah (1): > spi: kirkwood: Drop nondm code > > Jagan Teki (3): > arm: Remove d2net_v2 board > db-88f6281-bp-nand: Enable DM_SPI/SPI_FLASH > arm: Remove netspace_v2 board > > arch/arm/mach-kirkwood/Kconfig| 8 - > board/LaCie/net2big_v2/Kconfig| 12 - > board/LaCie/net2big_v2/MAINTAINERS| 7 - > board/LaCie/net2big_v2/Makefile | 13 -- > board/LaCie/net2big_v2/kwbimage.cfg | 149 - > board/LaCie/net2big_v2/net2big_v2.c | 257 -- > board/LaCie/net2big_v2/net2big_v2.h | 28 --- > board/LaCie/netspace_v2/Kconfig | 12 - > board/LaCie/netspace_v2/MAINTAINERS | 14 -- > board/LaCie/netspace_v2/Makefile | 10 - > board/LaCie/netspace_v2/kwbimage-is2.cfg | 149 - > board/LaCie/netspace_v2/kwbimage-ns2l.cfg | 149 - > board/LaCie/netspace_v2/kwbimage.cfg | 149 - > board/LaCie/netspace_v2/netspace_v2.c | 120 -- > board/LaCie/netspace_v2/netspace_v2.h | 22 -- > configs/d2net_v2_defconfig| 53 - > configs/db-88f6281-bp-nand_defconfig | 4 +- > configs/inetspace_v2_defconfig| 53 - > configs/net2big_v2_defconfig | 53 - > configs/netspace_lite_v2_defconfig| 53 - > configs/netspace_max_v2_defconfig | 53 - > configs/netspace_mini_v2_defconfig| 48 > configs/netspace_v2_defconfig | 53 - > drivers/spi/Kconfig | 12 +- > drivers/spi/kirkwood_spi.c| 136 ++-- > include/configs/lacie_kw.h| 152 - > scripts/config_whitelist.txt | 1 - > 27 files changed, 21 insertions(+), 1749 deletions(-) > delete mode 100644 board/LaCie/net2big_v2/Kconfig > delete mode 100644 board/LaCie/net2big_v2/MAINTAINERS > delete mode 100644 board/LaCie/net2big_v2/Makefile > delete mode 100644 board/LaCie/net2big_v2/kwbimage.cfg > delete mode 100644 board/LaCie/net2big_v2/net2big_v2.c > delete mode 100644 board/LaCie/net2big_v2/net2big_v2.h > delete mode 100644 board/LaCie/netspace_v2/Kconfig > delete mode 100644 board/LaCie/netspace_v2/MAINTAINERS > delete mode 100644 board/LaCie/netspace_v2/Makefile > delete mode 100644 board/LaCie/netspace_v2/kwbimage-is2.cfg > delete mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg > delete mode 100644 board/LaCie/netspace_v2/kwbimage.cfg > delete mode 100644 board/LaCie/netspace_v2/netspace_v2.c > delete mode 100644 board/LaCie/netspace_v2/netspace_v2.h > delete mode 100644 configs/d2net_v2_defconfig > delete mode 100644 configs/inetspace_v2_defconfig > delete mode 100644 configs/net2big_v2_defconfig > delete mode 100644 configs/netspace_lite_v2_defconfig > delete mode 100644 configs/netspace_max_v2_defconfig > delete mode 100644 configs/netspace_mini_v2_defconfig > delete mode 100644 configs/netspace_v2_defconfig > delete mode 100644 include/configs/lacie_kw.h > > -- > 2.25.1 > >
Re: [PATCH v3 0/4] update clock handler and proper cpu features
Hi Sagar
> From: Sagar Shrikant Kadam [mailto:sagar.ka...@sifive.com]
> Sent: Thursday, June 04, 2020 6:45 PM
> To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志); lu...@denx.de
> Cc: bmeng...@gmail.com; ja...@amarulasolutions.com;
> pragnesh.pa...@sifive.com; anup.pa...@wdc.com; s...@chromium.org;
> sean...@gmail.com; Sagar Shrikant Kadam
> Subject: [PATCH v3 0/4] update clock handler and proper cpu features
>
> U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing
> clk_request and free handlers.
> The current "cpu detail" sometimes shows "Microcode" as a feature, which is
> not the case with FU540-C000 on HiFive Unleashed board.
>
> Patch 1: add clk request handler to check if valid clock id is requested.
> Patch 2: add cpu node aliases.
> Patch 3: Correctly parse and update mmu-type.
>
> RISC-V core's on FU540-C000 SoC have separate instruction and data (split)
> L1 cache.
> Patch 4:Use i-cache-size dt property as one of identifier to indicate a
> split cache is available.
>
> I have picked few dependent patches from Sean's and Pragnesh's latest series
> from here [1]...[5].
>
> These have applied on mainline U-Boot commit 0d8f35b58cc8 ("Merge
> https://gitlab.denx.de/u-boot/custodians/u-boot-spi;)
>
> Patch history:
> =
> V3:
> 1. Included the cosmetic change as suggested
>s/L1 feature/L1 cache feature/
> 2. Added Reviewed-By tags
>
> V2:
> 1. Incorporate review comments from Bin and Sean Anderson.
>and dropped 2nd patch as similar work was already done in [1] and [2]
> 2 Add cpu node aliases to display cpu node's in sequence.
> 3. Add fix to show mmu as available cpu feature.
> 4. Check and append L1 cache feature.
>
> V1: Base version
> Thanks to Vincent Chen for testing the V1
> version of this series.
>
> [1] https://patchwork.ozlabs.org/patch/1295345
> [2] https://patchwork.ozlabs.org/patch/1295346
> [3] https://patchwork.ozlabs.org/patch/1300369
> [4] https://patchwork.ozlabs.org/patch/1300370
> [5] https://patchwork.ozlabs.org/patch/1300373
>
> All these together is available here:
> https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v3
>
> Sagar Shrikant Kadam (4):
> fu540: prci: add request and free clock handlers
> riscv: dts: hifive-unleashed-a00: add cpu aliases
> riscv: cpu: fixes to display proper CPU features
> riscv: cpu: check and append L1 cache to cpu features
>
> arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 5 +
> drivers/clk/sifive/fu540-prci.c | 21 +
> drivers/cpu/riscv_cpu.c | 10 +-
> 3 files changed, 35 insertions(+), 1 deletion(-)
I am trying to apply to u-boot/master, but it fail as below:
Applying: fu540: prci: add request and free clock handlers
error: patch failed: drivers/clk/sifive/fu540-prci.c:581
error: drivers/clk/sifive/fu540-prci.c: patch does not apply
Patch failed at 0001 fu540: prci: add request and free clock handlers
Please rebase master, I will sync to master later.
Thanks,
Rick
>
> --
> 2.7.4
>
[PATCH v3 0/4] spi: kirkwood: dm-conversion (part4)
Series of kirkwood boards to switch DM_SPI and drop which are not DM enabled still. Any inputs? Jagan. Bhargav Shah (1): spi: kirkwood: Drop nondm code Jagan Teki (3): arm: Remove d2net_v2 board db-88f6281-bp-nand: Enable DM_SPI/SPI_FLASH arm: Remove netspace_v2 board arch/arm/mach-kirkwood/Kconfig| 8 - board/LaCie/net2big_v2/Kconfig| 12 - board/LaCie/net2big_v2/MAINTAINERS| 7 - board/LaCie/net2big_v2/Makefile | 13 -- board/LaCie/net2big_v2/kwbimage.cfg | 149 - board/LaCie/net2big_v2/net2big_v2.c | 257 -- board/LaCie/net2big_v2/net2big_v2.h | 28 --- board/LaCie/netspace_v2/Kconfig | 12 - board/LaCie/netspace_v2/MAINTAINERS | 14 -- board/LaCie/netspace_v2/Makefile | 10 - board/LaCie/netspace_v2/kwbimage-is2.cfg | 149 - board/LaCie/netspace_v2/kwbimage-ns2l.cfg | 149 - board/LaCie/netspace_v2/kwbimage.cfg | 149 - board/LaCie/netspace_v2/netspace_v2.c | 120 -- board/LaCie/netspace_v2/netspace_v2.h | 22 -- configs/d2net_v2_defconfig| 53 - configs/db-88f6281-bp-nand_defconfig | 4 +- configs/inetspace_v2_defconfig| 53 - configs/net2big_v2_defconfig | 53 - configs/netspace_lite_v2_defconfig| 53 - configs/netspace_max_v2_defconfig | 53 - configs/netspace_mini_v2_defconfig| 48 configs/netspace_v2_defconfig | 53 - drivers/spi/Kconfig | 12 +- drivers/spi/kirkwood_spi.c| 136 ++-- include/configs/lacie_kw.h| 152 - scripts/config_whitelist.txt | 1 - 27 files changed, 21 insertions(+), 1749 deletions(-) delete mode 100644 board/LaCie/net2big_v2/Kconfig delete mode 100644 board/LaCie/net2big_v2/MAINTAINERS delete mode 100644 board/LaCie/net2big_v2/Makefile delete mode 100644 board/LaCie/net2big_v2/kwbimage.cfg delete mode 100644 board/LaCie/net2big_v2/net2big_v2.c delete mode 100644 board/LaCie/net2big_v2/net2big_v2.h delete mode 100644 board/LaCie/netspace_v2/Kconfig delete mode 100644 board/LaCie/netspace_v2/MAINTAINERS delete mode 100644 board/LaCie/netspace_v2/Makefile delete mode 100644 board/LaCie/netspace_v2/kwbimage-is2.cfg delete mode 100644 board/LaCie/netspace_v2/kwbimage-ns2l.cfg delete mode 100644 board/LaCie/netspace_v2/kwbimage.cfg delete mode 100644 board/LaCie/netspace_v2/netspace_v2.c delete mode 100644 board/LaCie/netspace_v2/netspace_v2.h delete mode 100644 configs/d2net_v2_defconfig delete mode 100644 configs/inetspace_v2_defconfig delete mode 100644 configs/net2big_v2_defconfig delete mode 100644 configs/netspace_lite_v2_defconfig delete mode 100644 configs/netspace_max_v2_defconfig delete mode 100644 configs/netspace_mini_v2_defconfig delete mode 100644 configs/netspace_v2_defconfig delete mode 100644 include/configs/lacie_kw.h -- 2.25.1
[PATCH v3 0/4] rockchip: rk3399: Add SPI boot
Thanks to Hugh Cole-Baker for inputs about SPI boot image creation. V2 changes can be available at [1] Changes for v3: - SPI env offset, size changes based on roc-rk3399-pc Changes for v2: - same defconfig to support both MMC, SPI boot - add spi flash program document Any inputs? Jagan. [1] https://patchwork.ozlabs.org/project/uboot/cover/20200601204213.466120-1-ja...@amarulasolutions.com/ Jagan Teki (4): Makefile: Drop to handle rkspi image type roc-rk3399-pc: Mark default env from SPI roc-rk3399-pc: Add SPI boot doc: rockchip: Document SPI flash program steps Makefile | 11 ++ arch/arm/dts/rk3399-roc-pc-u-boot.dtsi| 12 ++- configs/roc-pc-mezzanine-rk3399_defconfig | 9 ++-- configs/roc-pc-rk3399_defconfig | 9 ++-- doc/board/rockchip/rockchip.rst | 26 ++- include/configs/roc-pc-rk3399.h | 4 6 files changed, 52 insertions(+), 19 deletions(-) -- 2.25.1
[PATCH v3 0/4] update clock handler and proper cpu features
U-Boot cmd "cpu detail" shows inconsistent CPU features and is missing
clk_request and free handlers.
The current "cpu detail" sometimes shows "Microcode" as a feature, which
is not the case with FU540-C000 on HiFive Unleashed board.
Patch 1: add clk request handler to check if valid clock id is requested.
Patch 2: add cpu node aliases.
Patch 3: Correctly parse and update mmu-type.
RISC-V core's on FU540-C000 SoC have separate instruction and data (split)
L1 cache.
Patch 4:Use i-cache-size dt property as one of identifier to indicate a
split cache is available.
I have picked few dependent patches from Sean's and Pragnesh's latest
series from here [1]...[5].
These have applied on mainline U-Boot commit 0d8f35b58cc8
("Merge https://gitlab.denx.de/u-boot/custodians/u-boot-spi;)
Patch history:
=
V3:
1. Included the cosmetic change as suggested
s/L1 feature/L1 cache feature/
2. Added Reviewed-By tags
V2:
1. Incorporate review comments from Bin and Sean Anderson.
and dropped 2nd patch as similar work was already done in [1] and [2]
2 Add cpu node aliases to display cpu node's in sequence.
3. Add fix to show mmu as available cpu feature.
4. Check and append L1 cache feature.
V1: Base version
Thanks to Vincent Chen for testing the V1
version of this series.
[1] https://patchwork.ozlabs.org/patch/1295345
[2] https://patchwork.ozlabs.org/patch/1295346
[3] https://patchwork.ozlabs.org/patch/1300369
[4] https://patchwork.ozlabs.org/patch/1300370
[5] https://patchwork.ozlabs.org/patch/1300373
All these together is available here:
https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v3
Sagar Shrikant Kadam (4):
fu540: prci: add request and free clock handlers
riscv: dts: hifive-unleashed-a00: add cpu aliases
riscv: cpu: fixes to display proper CPU features
riscv: cpu: check and append L1 cache to cpu features
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 5 +
drivers/clk/sifive/fu540-prci.c | 21 +
drivers/cpu/riscv_cpu.c | 10 +-
3 files changed, 35 insertions(+), 1 deletion(-)
--
2.7.4
[PATCH v3 0/4] Fix the SPL loading of a FIT image from NAND
Loading u-boot and its fdt from a NAND memory area with bad blocks led to the creation of these patches. Next, the output generated by the script used to flash the NAND of the SOC that caused the issue. ** Rewriting /dev/mtd0 with /mnt/MLO Erasing 128 Kibyte @ 0 -- 100 % complete Writing data to block 0 at offset 0x0 ** Rewriting /dev/mtd1 with /mnt/MLO Erasing 128 Kibyte @ 0 -- 100 % complete Writing data to block 0 at offset 0x0 ** Rewriting /dev/mtd2 with /mnt/MLO Erasing 128 Kibyte @ 0 -- 100 % complete Writing data to block 0 at offset 0x0 ** Rewriting /dev/mtd3 with /mnt/MLO Erasing 128 Kibyte @ 0 -- 100 % complete Writing data to block 0 at offset 0x0 ** Rewriting /dev/mtd4 with /mnt/u-boot.itb Skipping bad block at 0002 Erasing 128 Kibyte @ e -- 100 % complete Bad block at 2, 1 block(s) will be skipped Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x2 Writing data to block 2 at offset 0x4 Writing data to block 3 at offset 0x6 Writing data to block 4 at offset 0x8 Writing data to block 5 at offset 0xa ** Rewriting /dev/mtd5 with /mnt/u-boot.itb Erasing 128 Kibyte @ e -- 100 % complete Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x2 Writing data to block 2 at offset 0x4 Writing data to block 3 at offset 0x6 Writing data to block 4 at offset 0x8 ... - The bad block of the mtd4 partition at address 0x2 is skipped during the writing of u-boot.itb. - A redundant copy of u-boot.itb is written on mtd5 partition. In this partition there are no bad blocks. - Every data written on mtd5 partition at address greater than or equal to 0x2, has been written on partition mtd4 at address 0x4 + - 0x2. The current version of u-boot correctly manages bad blocks only if they are at addresses that follow the address from which to start reading data. If the starting address of the device tree, which can be taken from the itb header, is higher than the address of any bad block of the same partition, the address is no longer valid and it must be changed. Changes in v3: The previous versions were buggy for devices others than NAND. This because the 'adjust_offset' helper was properly set only for the NAND case but called even for devices like MMC, RAM, and so on, crashing the boot up by that devices. Continuing to use the adjust_offset helper would mean checking the helper before calling it and patching too many files to set it properly before calling the spl_load_simple_fit routine. For this reason, the adjust_offset helper has been removed from the spl_image_info structure and the offset fixed inside the read helper for the NAND device only. This solution fixes the problem for the NAND device without side effects for other types of devices. Changes in v2: - Replace CONFIG_IS_ENABLED(OF_EMBED) with IS_ENABLED(CONFIG_OF_EMBED)) Dario Binacchi (4): spl: fix format of function documentation spl: fit: fail fit loading in case of FDT appending error spl: fit: nand: fix fit loading in case of bad blocks spl: fit: improve spl_nand_fit_read(...) readability common/spl/spl_fit.c| 9 +--- common/spl/spl_nand.c | 15 +++-- drivers/mtd/nand/raw/nand_spl_loaders.c | 28 + include/nand.h | 1 + include/spl.h | 2 +- 5 files changed, 45 insertions(+), 10 deletions(-) -- 2.17.1
[PATCH v3 0/4] mx6cuboxi: enable support for OF_CONTROL and DM in SPL
Make an additional step to add full DM support to mx6cuboxi, including its support for SPL With this new configuration SPL image is 50 KB, higher than the 38 KB from the previous version, but it still under the 68 KB limit. Changes in v3: - Cleanup Changes in v2: - Fix board_boot_order to avoid pointing to a NAND device - Fix board_boot_order to include MMC iomux - Remove unused code Walter Lozano (4): mx6cuboxi: enable MMC and eMMC in DT for SPL mx6cuboxi: customize board_boot_order to access eMMC mx6cuboxi: enable OF_CONTROL and DM in SPL mx6cuboxi: remove unused code ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 8 ++ board/solidrun/mx6cuboxi/mx6cuboxi.c | 113 -- configs/mx6cuboxi_defconfig | 3 + 3 files changed, 59 insertions(+), 65 deletions(-) -- 2.20.1
