Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hi Pali,
On 11.08.20 18:37, Pali Rohár wrote:
On Tuesday 11 August 2020 10:22:44 Simon Glass wrote:
Hi Daniel,
On Tue, 11 Aug 2020 at 10:10, Daniel Schwierzeck
wrote:
Am Dienstag, den 11.08.2020, 10:58 -0400 schrieb Tom Rini:
On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
Hi Pali,
On 11.08.20 10:00, Pali Rohár wrote:
Hello!
On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
Hi Tom,
Hi Pali,
(added Pali because of the Nokia RX51 issue)
Could you please send me a link to "problematic" patch? As you have not
inlined it in this email.
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
Its a rebase of the original patch.
On 07.08.20 21:21, Tom Rini wrote:
On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Also complete remove bi_memstart & bi_memsize from the board-info
struct. As now bi_dram[] is always enabled and should be used instead.
This removes the redundant varriables.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Tom Rini
Cc: Ramon Fried
Cc: Simon Glass
Cc: Michal Simek
Reviewed-by: Daniel Schwierzeck
I don't see quite how, but this is breaking running
test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
was wrong, and is what's breaking the test). Please rebase and confirm
that test passes as well, thanks!
I've checked the issue with nokia_rx51_test.sh and could not find any
issues in the patch. My assumption now is, that the very old Linux
kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
struct in Linux to pass the memory information (via bd_memstart &
bi_memsize), as was also done in the very old PowerPC days. With this
patch now and the removal of these fields from bd_info, this might
explain why this kernel does not boot any more (no output on the serial
console at all).
Pali, could you please check if my assumption is correct here? And if
yes, could please switch the test to using a newer kernel version? Or
remove the Linux kernel booting from the test?
Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
version does not contain Maemo patches which are required for Maemo
system which is still widely used. And yes, people are using it with
U-Boot.
Second reason why we cannot remove support for ATAGs is that Nokia's
signed first stage bootloader pass other setup data via ATAGs for kernel
and U-Boot N900 board code parses it, reuse it and pass to kernel.
And replacing first stage bootloader is not possible because it is
signed and signing keys are secret (now probably lost).
Okay. But this patch is not removing ATAG support, but removes 2
member from the bd_info struct (bi_memstart & bi_memsize), which are
replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
the generation of the memory ATAG is already done based on these
values:
setup_memory_tags() in arch/arm/lib/bootm.c
So I still fail to understand, why booting of this old kernel using
ATAGs does not work with this patch applied. Perhaps you could give
it a quick test? That would be really helpful. Here again the gitlab
branch that you can use for some tests:
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
I can do some tests on real N900 device at the end of week. But I doubt
that I could debug something on device if kernel does not print any
message.
Running u-boot and kernel in N900 emulator with debug serial console is
easier and you can do it too locally. If you look at that test script
test/nokia_rx51_test.sh you could see that it downloads & compile qemu
and prepare OneNAND MTD image with compiled u-boot + kernel binary.
You can also run that test script locally, it does not require root and
all data it stores into temporary "nokia_rx51_tmp" directory. This could
help you to test your changes without need to push them to travis/gitlab
ci testing.
So, I also thought maybe changing bd_t was it, and reverted just that
part locally, and it was still breaking. It's also only breaking in one
of the three boot tests, if I follow things correctly.
What about trying to *not* remove first two members of struct bd_info?
Maybe it is part of ABI structure?
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6#688c66555c917f123c1d054aabd1c7023c6c4522_31_30
Not changing the structure is what I tried and it still failed, unless I
made a thinko when
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hi Pali,
On 11.08.20 18:19, Pali Rohár wrote:
On Tuesday 11 August 2020 10:58:47 Tom Rini wrote:
On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
Hi Pali,
On 11.08.20 10:00, Pali Rohár wrote:
Hello!
On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
Hi Tom,
Hi Pali,
(added Pali because of the Nokia RX51 issue)
Could you please send me a link to "problematic" patch? As you have not
inlined it in this email.
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
Its a rebase of the original patch.
On 07.08.20 21:21, Tom Rini wrote:
On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Also complete remove bi_memstart & bi_memsize from the board-info
struct. As now bi_dram[] is always enabled and should be used instead.
This removes the redundant varriables.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Tom Rini
Cc: Ramon Fried
Cc: Simon Glass
Cc: Michal Simek
Reviewed-by: Daniel Schwierzeck
I don't see quite how, but this is breaking running
test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
was wrong, and is what's breaking the test). Please rebase and confirm
that test passes as well, thanks!
I've checked the issue with nokia_rx51_test.sh and could not find any
issues in the patch. My assumption now is, that the very old Linux
kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
struct in Linux to pass the memory information (via bd_memstart &
bi_memsize), as was also done in the very old PowerPC days. With this
patch now and the removal of these fields from bd_info, this might
explain why this kernel does not boot any more (no output on the serial
console at all).
Pali, could you please check if my assumption is correct here? And if
yes, could please switch the test to using a newer kernel version? Or
remove the Linux kernel booting from the test?
Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
version does not contain Maemo patches which are required for Maemo
system which is still widely used. And yes, people are using it with
U-Boot.
Second reason why we cannot remove support for ATAGs is that Nokia's
signed first stage bootloader pass other setup data via ATAGs for kernel
and U-Boot N900 board code parses it, reuse it and pass to kernel.
And replacing first stage bootloader is not possible because it is
signed and signing keys are secret (now probably lost).
Okay. But this patch is not removing ATAG support, but removes 2
member from the bd_info struct (bi_memstart & bi_memsize), which are
replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
the generation of the memory ATAG is already done based on these
values:
setup_memory_tags() in arch/arm/lib/bootm.c
So I still fail to understand, why booting of this old kernel using
ATAGs does not work with this patch applied. Perhaps you could give
it a quick test? That would be really helpful. Here again the gitlab
branch that you can use for some tests:
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
I can do some tests on real N900 device at the end of week. But I doubt
that I could debug something on device if kernel does not print any
message.
Running u-boot and kernel in N900 emulator with debug serial console is
easier and you can do it too locally. If you look at that test script
test/nokia_rx51_test.sh you could see that it downloads & compile qemu
and prepare OneNAND MTD image with compiled u-boot + kernel binary.
You can also run that test script locally, it does not require root and
all data it stores into temporary "nokia_rx51_tmp" directory. This could
help you to test your changes without need to push them to travis/gitlab
ci testing.
So, I also thought maybe changing bd_t was it, and reverted just that
part locally, and it was still breaking. It's also only breaking in one
of the three boot tests, if I follow things correctly.
What about trying to *not* remove first two members of struct bd_info?
Maybe it is part of ABI structure?
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6#688c66555c917f123c1d054aabd1c7023c6c4522_31_30
Not changing the structure is what I tried and it still failed, unless I
made a thinko when I was checking it out. Can you please look in to
this a bit?
Yes, I looked at that patch and seems it is really breaking something
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hi Daniel,
On 11.08.20 18:10, Daniel Schwierzeck wrote:
Am Dienstag, den 11.08.2020, 10:58 -0400 schrieb Tom Rini:
On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
Hi Pali,
On 11.08.20 10:00, Pali Rohár wrote:
Hello!
On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
Hi Tom,
Hi Pali,
(added Pali because of the Nokia RX51 issue)
Could you please send me a link to "problematic" patch? As you have not
inlined it in this email.
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
Its a rebase of the original patch.
On 07.08.20 21:21, Tom Rini wrote:
On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Also complete remove bi_memstart & bi_memsize from the board-info
struct. As now bi_dram[] is always enabled and should be used instead.
This removes the redundant varriables.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Tom Rini
Cc: Ramon Fried
Cc: Simon Glass
Cc: Michal Simek
Reviewed-by: Daniel Schwierzeck
I don't see quite how, but this is breaking running
test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
was wrong, and is what's breaking the test). Please rebase and confirm
that test passes as well, thanks!
I've checked the issue with nokia_rx51_test.sh and could not find any
issues in the patch. My assumption now is, that the very old Linux
kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
struct in Linux to pass the memory information (via bd_memstart &
bi_memsize), as was also done in the very old PowerPC days. With this
patch now and the removal of these fields from bd_info, this might
explain why this kernel does not boot any more (no output on the serial
console at all).
Pali, could you please check if my assumption is correct here? And if
yes, could please switch the test to using a newer kernel version? Or
remove the Linux kernel booting from the test?
Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
version does not contain Maemo patches which are required for Maemo
system which is still widely used. And yes, people are using it with
U-Boot.
Second reason why we cannot remove support for ATAGs is that Nokia's
signed first stage bootloader pass other setup data via ATAGs for kernel
and U-Boot N900 board code parses it, reuse it and pass to kernel.
And replacing first stage bootloader is not possible because it is
signed and signing keys are secret (now probably lost).
Okay. But this patch is not removing ATAG support, but removes 2
member from the bd_info struct (bi_memstart & bi_memsize), which are
replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
the generation of the memory ATAG is already done based on these
values:
setup_memory_tags() in arch/arm/lib/bootm.c
So I still fail to understand, why booting of this old kernel using
ATAGs does not work with this patch applied. Perhaps you could give
it a quick test? That would be really helpful. Here again the gitlab
branch that you can use for some tests:
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
I can do some tests on real N900 device at the end of week. But I doubt
that I could debug something on device if kernel does not print any
message.
Running u-boot and kernel in N900 emulator with debug serial console is
easier and you can do it too locally. If you look at that test script
test/nokia_rx51_test.sh you could see that it downloads & compile qemu
and prepare OneNAND MTD image with compiled u-boot + kernel binary.
You can also run that test script locally, it does not require root and
all data it stores into temporary "nokia_rx51_tmp" directory. This could
help you to test your changes without need to push them to travis/gitlab
ci testing.
So, I also thought maybe changing bd_t was it, and reverted just that
part locally, and it was still breaking. It's also only breaking in one
of the three boot tests, if I follow things correctly.
What about trying to *not* remove first two members of struct bd_info?
Maybe it is part of ABI structure?
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6#688c66555c917f123c1d054aabd1c7023c6c4522_31_30
Not changing the structure is what I tried and it still failed, unless I
made a thinko when I was checking it out. Can you please look in to
this a bit?
if I understand this correctly, the Maemo support
Re: [PATCH v2 6/7] riscv: Add watchdog bindings for the k210
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Sean Anderson > Sent: Friday, August 07, 2020 11:04 PM > To: u-boot@lists.denx.de > Cc: Heinrich Schuchardt; Marek Vasut; Simon Glass; Jagan Teki; Bin Meng; Sean > Anderson > Subject: [PATCH v2 6/7] riscv: Add watchdog bindings for the k210 > > This adds the necessary bindings. Most of them are already there. > > Signed-off-by: Sean Anderson > --- > > Changes in v2: > - Move watchdog enable to k210.dtsi as it does not depend on anything > board-specific. > > arch/riscv/dts/k210.dtsi | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rick Chen
Re: [U-Boot] requesting a custodian tree for Aspeed SoCs maintenance
On Wed, Aug 12, 2020 at 03:07:13AM +, ChiaWei Wang wrote: > Hi Tom, > > Thank you for the feedback. > > > -Original Message- > > From: Tom Rini [mailto:tr...@konsulko.com] > > Sent: Tuesday, August 11, 2020 11:26 PM > > To: ChiaWei Wang > > Cc: u-boot@lists.denx.de > > Subject: Re: [U-Boot] requesting a custodian tree for Aspeed SoCs > > maintenance > > > > On Mon, Aug 10, 2020 at 03:19:43AM +, ChiaWei Wang wrote: > > o > > > Hi, > > > > > > We are Aspeed SW team and would like to request the creation of a > > > u-boot-aspeed.git custodian tree for the u-boot support related to > > > Aspeed SoCs. Attached is the SSH key generated for this purpose. > > > > > > By the way, the Aspeed SoCs are based on ARM architecture. However, we > > > are not sure if the Aspeed custodian tree should be a downstream of > > > u-boot-arm.git tree or not. As there is no update to u-boot-arm since 4 > > > years > > ago. > > > > > > If anything is further needed, please let us know. > > > > To start with, I would like to handle Aspeed development by pulling > > respective > > patches in to one of my testing branches and merge them after appropriate > > review time. If the volume of changes makes it worthwhile we can add a > > new custodian tree later. Thanks! > > So currently, should we simply submit individual Aspeed patches to the > mailing list for the review process? > In fact, we have sent certain patches couple days ago. > (http://patchwork.ozlabs.org/project/uboot/cover/20200803093610.3222-1-chiawei_w...@aspeedtech.com/) > If it is the case, we will proceed the patch submission for Aspeed SoCs after > the review is done. Correct, thanks. I'll likely be picking up those patches soon. -- Tom signature.asc Description: PGP signature
RE: [U-Boot] requesting a custodian tree for Aspeed SoCs maintenance
Hi Tom, Thank you for the feedback. > -Original Message- > From: Tom Rini [mailto:tr...@konsulko.com] > Sent: Tuesday, August 11, 2020 11:26 PM > To: ChiaWei Wang > Cc: u-boot@lists.denx.de > Subject: Re: [U-Boot] requesting a custodian tree for Aspeed SoCs > maintenance > > On Mon, Aug 10, 2020 at 03:19:43AM +, ChiaWei Wang wrote: > o > > Hi, > > > > We are Aspeed SW team and would like to request the creation of a > > u-boot-aspeed.git custodian tree for the u-boot support related to > > Aspeed SoCs. Attached is the SSH key generated for this purpose. > > > > By the way, the Aspeed SoCs are based on ARM architecture. However, we > > are not sure if the Aspeed custodian tree should be a downstream of > > u-boot-arm.git tree or not. As there is no update to u-boot-arm since 4 > > years > ago. > > > > If anything is further needed, please let us know. > > To start with, I would like to handle Aspeed development by pulling respective > patches in to one of my testing branches and merge them after appropriate > review time. If the volume of changes makes it worthwhile we can add a > new custodian tree later. Thanks! So currently, should we simply submit individual Aspeed patches to the mailing list for the review process? In fact, we have sent certain patches couple days ago. (http://patchwork.ozlabs.org/project/uboot/cover/20200803093610.3222-1-chiawei_w...@aspeedtech.com/) If it is the case, we will proceed the patch submission for Aspeed SoCs after the review is done. Regards, Chiawei
[GIT PULL v2] TI changes for v2020.10-rc3
Hi Tom, Please find the pull request for v2020.10-rc3 containing TI specific changes. This should have been sent for rc2 but delayed due to some comments in the last minute. Please look at the PR description for the details on the PR. Also tag message is updated with details. Changes since v1: - Dropped an invalid commit - Updated Tag message Travis-CI build: https://travis-ci.org/github/lokeshvutla/u-boot/builds/716955604 The following changes since commit c045207f96f7f7ae8c7f134a6010e636176b: Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.10-rc3 for you to fetch changes up to db6451ec0e8483f76f3364293d48e86249c52322: arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11 20:34:46 +0530) - Added support for J7200 evm - DM_ETH and DM_USB migrations for omap3 - USB DFU and mass storage support for AM65x evm - RTI watchdog support for K3 devices - Fix an issue with L3 cache on K3 devices Andrew F. Davis (1): arm: mach-k3: Clean non-coherent lines out of L3 cache Dave Gerlach (1): arm: dts: k3-j7200: Add R5 specific dts support Derald D. Woods (1): ARM: omap3: evm: Complete DM_ETH and DM_USB migrations Faiz Abbas (14): mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value spl: usb: Create an API spl_usb_load() spl: usb: Only init usb once armv7R: K3: am654: Use full malloc in SPL both pre and post reloc arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB arm: mach-k3: am6_init: Gate mmc related configurations with the appropriate config arm: mach-k3: am6_init: Do USB fixups to facilitate host and device boot modes arm: mach-k3: am6_init: Add support for USB boot mode arm: dts: k3-am654-r5-base-board: Add USB0 nodes arm: dts: k3-am654-base-board: Add support for USB0 in SPL configs: am65x_evm: Add support for DFU related configs configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes configs: Add defconfig for USB DFU bootmode configs: Add new config for supporting USB mass storage boot Jan Kiszka (2): watchdog: Add support for K3 RTI watchdog arm: dts: k3: Add RTI watchdogs Jean-Jacques Hiblot (1): arm: mach-k3: Fix platform hang when SPL_MULTI_DTB_FIT is not enabled Kishon Vijay Abraham I (1): soc: soc_ti_k3: Add device identification for J7200 SoC Lokesh Vutla (15): board: ti: board_detect: Add stub functions for EEPROM detection apis board: ti: j721e: Probe eeprom only when CONFIG_TI_I2C_BOARD_DETECT is defined arm: mach-k3: Move mmr_unlock to a common location arm: mach-k3: sysfw-loader: Add support for rom loading sysfw image arm: mach-k3: j721e: Add detection for j721e arm: mach-k3: j721e: Fix unlocking control module registers arm: mach-k3: j7200: Add support for SOC detection arm: mach-k3: j7200: Add support for storing extended boot info from ROM arm: mach-k3: j7200: Detect if ROM has already loaded sysfw board: ti: j7200: Introduce support for j7200 build targets board: ti: j7200: Add board detection support for j7200 ram: k3-j721e: Relax version checks for memory controller arm: dts: k3-j7200: Add dts support configs: j7200_evm_r5: Add initial support configs: j7200_evm_a72: Add Initial support Suman Anna (4): arm: dts: k3-am65: Fix interconnect node names arm: dts: k3-j721e: Fix interconnect node names board: ti: am65x: Update fdt fixup logic for interconnect nodes board: ti: j721e: Update fdt fixup logic for interconnect nodes Vignesh Raghavendra (6): arm: dts: k3-j7200: Add USB related DT entries board: ti: j721e: Add support for HyperFlash detection ARM: dts: k3-j7200: Add wkup gpio node ARM: dts: k3-j7200: Add HyperBus and HyperFlash nodes ARM: dts: k3-j7200-mcu-wakeup: Add CPSW2G support arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-am65-mcu.dtsi |9 + arch/arm/dts/k3-am65.dtsi |6 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 27 + arch/arm/dts/k3-am654-r5-base-board.dts| 35 + .../arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 133 ++ arch/arm/dts/k3-j7200-common-proc-board.dts| 195 ++ arch/arm/dts/k3-j7200-ddr-evm-lp4-1600.dtsi| 2195 arch/arm/dts/k3-j7200-main.dtsi| 343 +++ arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 272 +++ arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 217 ++ arch/arm/dts/k3-j7200-som-p0.dtsi | 62 +
[PATCH v1 5/5] arm: socfpga: mailbox: Add mailbox retry support
From: Ley Foon Tan
Resend mailbox command for 3 times with 2ms interval in between if
it receives MBOX_RESP_TIMEOUT and MBOX_RESP_DEVICE_BUSY response code.
Add a wrapper function mbox_send_cmd_common_retry() for retry, change
all the callers to use this wrapper function.
Signed-off-by: Ley Foon Tan
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/mailbox_s10.c | 40 ++---
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
b/arch/arm/mach-socfpga/mailbox_s10.c
index a9ec818492..18d44924e6 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -296,11 +296,33 @@ static __always_inline int mbox_send_cmd_common(u8 id,
u32 cmd, u8 is_indirect,
return resp_err;
}
}
- };
+ }
return -EIO;
}
+static __always_inline int mbox_send_cmd_common_retry(u8 id, u32 cmd,
+ u8 is_indirect,
+ u32 len, u32 *arg,
+ u8 urgent,
+ u32 *resp_buf_len,
+ u32 *resp_buf)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < 3; i++) {
+ ret = mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
+ urgent, resp_buf_len, resp_buf);
+ if (ret == MBOX_RESP_TIMEOUT || ret == MBOX_RESP_DEVICE_BUSY)
+ udelay(2000); /* wait for 2ms before resend */
+ else
+ break;
+ }
+
+ return ret;
+}
+
int mbox_init(void)
{
int ret;
@@ -395,10 +417,10 @@ static __always_inline int
mbox_get_fpga_config_status_common(u32 cmd)
int ret;
reconfig_status_resp_len = RECONFIG_STATUS_RESPONSE_LEN;
- ret = mbox_send_cmd_common(MBOX_ID_UBOOT, cmd,
- MBOX_CMD_DIRECT, 0, NULL, 0,
- _status_resp_len,
- reconfig_status_resp);
+ ret = mbox_send_cmd_common_retry(MBOX_ID_UBOOT, cmd,
+MBOX_CMD_DIRECT, 0, NULL, 0,
+_status_resp_len,
+reconfig_status_resp);
if (ret)
return ret;
@@ -438,16 +460,16 @@ int __secure mbox_get_fpga_config_status_psci(u32 cmd)
int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
{
- return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
- resp_buf_len, resp_buf);
+ return mbox_send_cmd_common_retry(id, cmd, is_indirect, len, arg,
+ urgent, resp_buf_len, resp_buf);
}
int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
u32 *arg, u8 urgent, u32 *resp_buf_len,
u32 *resp_buf)
{
- return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
- resp_buf_len, resp_buf);
+ return mbox_send_cmd_common_retry(id, cmd, is_indirect, len, arg,
+ urgent, resp_buf_len, resp_buf);
}
int mbox_send_cmd_only(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg)
--
2.19.0
[PATCH v1 1/5] arm: socfpga: mailbox: Refactor mailbox timeout event handling
Add miliseconds delay when waiting for mailbox event to happen
before timeout. This will ensure the timeout duration is predictive.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/mailbox_s10.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
b/arch/arm/mach-socfpga/mailbox_s10.c
index f30e7f80a2..729d9b04fa 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -29,13 +29,14 @@ DECLARE_GLOBAL_DATA_PTR;
static __always_inline int mbox_polling_resp(u32 rout)
{
u32 rin;
- unsigned long i = ~0;
+ unsigned long i = 2000;
while (i) {
rin = MBOX_READL(MBOX_RIN);
if (rout != rin)
return 0;
+ udelay(1000);
i--;
}
@@ -176,11 +177,15 @@ static __always_inline int mbox_send_cmd_common(u8 id,
u32 cmd, u8 is_indirect,
MBOX_WRITEL(1, MBOX_DOORBELL_TO_SDM);
while (1) {
- ret = ~0;
+ ret = 1000;
/* Wait for doorbell from SDM */
- while (!MBOX_READL(MBOX_DOORBELL_FROM_SDM) && ret--)
- ;
+ do {
+ if (MBOX_READL(MBOX_DOORBELL_FROM_SDM))
+ break;
+ udelay(1000);
+ } while (--ret);
+
if (!ret)
return -ETIMEDOUT;
--
2.19.0
[PATCH v1 4/5] arm: socfpga: mailbox: Update mailbox response codes
From: Ley Foon Tan
Sync latest mailbox response codes from SDM firmware.
Signed-off-by: Ley Foon Tan
Signed-off-by: Chee Hong Ang
---
.../mach-socfpga/include/mach/mailbox_s10.h | 38 ++-
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
index 55707ab9c5..4d783119ea 100644
--- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
@@ -67,8 +67,42 @@ enum ALT_SDM_MBOX_RESP_CODE {
MBOX_RESP_UNKNOWN_BR = 2,
/* CMD code not recognized by firmware */
MBOX_RESP_UNKNOWN = 3,
- /* Indicates that the device is not configured */
- MBOX_RESP_NOT_CONFIGURED = 256,
+ /* Length setting is not a valid length for this CMD type */
+ MBOX_RESP_INVALID_LEN = 4,
+ /* Indirect setting is not valid for this CMD type */
+ MBOX_RESP_INVALID_INDIRECT_SETTING = 5,
+ /* HW source which is not allowed to send CMD type */
+ MBOX_RESP_CMD_INVALID_ON_SRC = 6,
+ /* Client with ID not associated with any running PR CMD tries to run
+* RECONFIG_DATA RECONFIG_STATUS and accessing QSPI / SDMMC using ID
+* without exclusive access
+*/
+ MBOX_RESP_CLIENT_ID_NO_MATCH = 8,
+ /* Address provided to the system is invalid (alignment, range
+* permission)
+*/
+ MBOX_RESP_INVALID_ADDR = 0x9,
+ /* Signature authentication failed */
+ MBOX_RESP_AUTH_FAIL = 0xA,
+ /* CMD timed out */
+ MBOX_RESP_TIMEOUT = 0xB,
+ /* HW (i.e. QSPI) is not ready (initialized or configured) */
+ MBOX_RESP_HW_NOT_RDY = 0xC,
+ /* Invalid license for IID registration */
+ MBOX_RESP_PUF_ACCCES_FAILED = 0x80,
+ MBOX_PUF_ENROLL_DISABLE = 0x81,
+ MBOX_RESP_PUF_ENROLL_FAIL = 0x82,
+ MBOX_RESP_PUF_RAM_TEST_FAIL = 0x83,
+ MBOX_RESP_ATTEST_CERT_GEN_FAIL = 0x84,
+ /* Operation not allowed under current security settings */
+ MBOX_RESP_NOT_ALLOWED_UNDER_SECURITY_SETTINGS = 0x85,
+ MBOX_RESP_PUF_TRNG_FAIL = 0x86,
+ MBOX_RESP_FUSE_ALREADY_BLOWN = 0x87,
+ MBOX_RESP_INVALID_SIGNATURE = 0x88,
+ MBOX_RESP_INVALID_HASH = 0x8b,
+ MBOX_RESP_INVALID_CERTIFICATE = 0x91,
+ /* Indicates that the device (FPGA or HPS) is not configured */
+ MBOX_RESP_NOT_CONFIGURED = 0x100,
/* Indicates that the device is busy */
MBOX_RESP_DEVICE_BUSY = 0x1FF,
/* Indicates that there is no valid response available */
--
2.19.0
[PATCH v1 0/5] SoCFPGA mailbox driver fixes and enhancements
Fixes: - Proper timeout implementation - Always read mailbox response data before returning mailbox status to caller Enhancement: - Auto retry on mailbox sending - Send large mailbox message Chee Hong Ang (3): arm: socfpga: mailbox: Refactor mailbox timeout event handling arm: socfpga: mailbox: Always read mailbox responses before returning status arm: socfpga: mailbox: Support sending large mailbox command Ley Foon Tan (2): arm: socfpga: mailbox: Update mailbox response codes arm: socfpga: mailbox: Add mailbox retry support .../mach-socfpga/include/mach/mailbox_s10.h | 38 +++- arch/arm/mach-socfpga/mailbox_s10.c | 172 -- 2 files changed, 156 insertions(+), 54 deletions(-) -- 2.19.0
[PATCH v1 3/5] arm: socfpga: mailbox: Support sending large mailbox command
Mailbox command which is too large to fit into the mailbox
FIFO command buffer can be sent to SDM in multiple parts.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/mailbox_s10.c | 113 +++-
1 file changed, 78 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
b/arch/arm/mach-socfpga/mailbox_s10.c
index e8a587f007..a9ec818492 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -43,41 +43,93 @@ static __always_inline int mbox_polling_resp(u32 rout)
return -ETIMEDOUT;
}
+static __always_inline int mbox_is_cmdbuf_full(u32 cin)
+{
+ return (((cin + 1) % MBOX_CMD_BUFFER_SIZE) == MBOX_READL(MBOX_COUT));
+}
+
+static __always_inline int mbox_is_cmdbuf_empty(u32 cin)
+{
+ return (((MBOX_READL(MBOX_COUT) + 1) % MBOX_CMD_BUFFER_SIZE) == cin);
+}
+
+static __always_inline int mbox_wait_for_cmdbuf_empty(u32 cin)
+{
+ int timeout = 2000;
+
+ while (timeout) {
+ if (mbox_is_cmdbuf_empty(cin))
+ return 0;
+ udelay(1000);
+ timeout--;
+ }
+
+ return -ETIMEDOUT;
+}
+
+static __always_inline int mbox_write_cmd_buffer(u32 *cin, u32 data,
+int *is_cmdbuf_overflow)
+{
+ int timeout = 1000;
+
+ while (timeout) {
+ if (mbox_is_cmdbuf_full(*cin)) {
+ if (is_cmdbuf_overflow &&
+ *is_cmdbuf_overflow == 0) {
+ /* Trigger SDM doorbell */
+ MBOX_WRITEL(1, MBOX_DOORBELL_TO_SDM);
+ *is_cmdbuf_overflow = 1;
+ }
+ udelay(1000);
+ } else {
+ /* write header to circular buffer */
+ MBOX_WRITE_CMD_BUF(data, (*cin)++);
+ *cin %= MBOX_CMD_BUFFER_SIZE;
+ MBOX_WRITEL(*cin, MBOX_CIN);
+ break;
+ }
+ timeout--;
+ }
+
+ if (!timeout)
+ return -ETIMEDOUT;
+
+ /* Wait for the SDM to drain the FIFO command buffer */
+ if (is_cmdbuf_overflow && *is_cmdbuf_overflow)
+ return mbox_wait_for_cmdbuf_empty(*cin);
+
+ return 0;
+}
+
/* Check for available slot and write to circular buffer.
* It also update command valid offset (cin) register.
*/
static __always_inline int mbox_fill_cmd_circular_buff(u32 header, u32 len,
u32 *arg)
{
- u32 cin;
- u32 cout;
- u32 i;
-
- cin = MBOX_READL(MBOX_CIN) % MBOX_CMD_BUFFER_SIZE;
- cout = MBOX_READL(MBOX_COUT) % MBOX_CMD_BUFFER_SIZE;
+ int i, ret;
+ int is_cmdbuf_overflow = 0;
+ u32 cin = MBOX_READL(MBOX_CIN) % MBOX_CMD_BUFFER_SIZE;
- /* if command buffer is full or not enough free space
-* to fit the data. Note, len is in u32 unit.
-*/
- if (((cin + 1) % MBOX_CMD_BUFFER_SIZE) == cout ||
- ((MBOX_CMD_BUFFER_SIZE - cin + cout - 1) %
-MBOX_CMD_BUFFER_SIZE) < (len + 1))
- return -ENOMEM;
-
- /* write header to circular buffer */
- MBOX_WRITE_CMD_BUF(header, cin++);
- /* wrapping around when it reach the buffer size */
- cin %= MBOX_CMD_BUFFER_SIZE;
+ ret = mbox_write_cmd_buffer(, header, _cmdbuf_overflow);
+ if (ret)
+ return ret;
/* write arguments */
for (i = 0; i < len; i++) {
- MBOX_WRITE_CMD_BUF(arg[i], cin++);
- /* wrapping around when it reach the buffer size */
- cin %= MBOX_CMD_BUFFER_SIZE;
+ is_cmdbuf_overflow = 0;
+ ret = mbox_write_cmd_buffer(, arg[i], _cmdbuf_overflow);
+ if (ret)
+ return ret;
}
- /* write command valid offset */
- MBOX_WRITEL(cin, MBOX_CIN);
+ /* If SDM doorbell is not triggered after the last data is
+* written into mailbox FIFO command buffer, trigger the
+* SDM doorbell again to ensure SDM able to read the remaining
+* data.
+*/
+ if (!is_cmdbuf_overflow)
+ MBOX_WRITEL(1, MBOX_DOORBELL_TO_SDM);
return 0;
}
@@ -90,10 +142,6 @@ static __always_inline int mbox_prepare_cmd_only(u8 id, u32
cmd,
u32 header;
int ret;
- /* Total length is command + argument length */
- if ((len + 1) > MBOX_CMD_BUFFER_SIZE)
- return -EINVAL;
-
if (cmd > MBOX_MAX_CMD_INDEX)
return -EINVAL;
@@ -110,11 +158,7 @@ static __always_inline int mbox_send_cmd_only_common(u8
id, u32 cmd,
u8 is_indirect, u32 len,
u32 *arg)
{
- int ret =
[PATCH v1 2/5] arm: socfpga: mailbox: Always read mailbox responses before returning status
Mailbox driver should always check for the length of the response
and read the response data before returning the response status to
caller.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/mailbox_s10.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
b/arch/arm/mach-socfpga/mailbox_s10.c
index 729d9b04fa..e8a587f007 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -221,9 +221,7 @@ static __always_inline int mbox_send_cmd_common(u8 id, u32
cmd, u8 is_indirect,
if ((MBOX_RESP_CLIENT_GET(resp) ==
MBOX_CLIENT_ID_UBOOT) &&
(MBOX_RESP_ID_GET(resp) == id)) {
- ret = MBOX_RESP_ERR_GET(resp);
- if (ret)
- return ret;
+ int resp_err = MBOX_RESP_ERR_GET(resp);
if (resp_buf_len) {
buf_len = *resp_buf_len;
@@ -252,7 +250,7 @@ static __always_inline int mbox_send_cmd_common(u8 id, u32
cmd, u8 is_indirect,
buf_len--;
}
}
- return ret;
+ return resp_err;
}
}
};
--
2.19.0
Re: [PATCH v2 09/10] riscv: Add device tree bindings for SPI
> This patch adds bindings for the MMC slot and SPI flash on the Sipeed Maix
> Bit.
>
> Signed-off-by: Sean Anderson
> ---
> This patch was previously part of
> https://patchwork.ozlabs.org/project/uboot/list/?series=161576
>
> Changes in v2:
> - Remove broken-wp property (implicit due to no wp gpio)
> - Remove ctrl0 field offsets from device tree
> - Switch to new compatible strings
> - Switch to new pinmux binding style
>
> arch/riscv/dts/k210-maix-bit.dts | 46 +++-
> arch/riscv/dts/k210.dtsi | 2 ++
> 2 files changed, 47 insertions(+), 1 deletion(-)
Acked-by: Rick Chen
I am OK that this patch can be pulled via SPI tree.
Thanks,
Rick
>
> diff --git a/arch/riscv/dts/k210-maix-bit.dts
> b/arch/riscv/dts/k210-maix-bit.dts
> index e840e04ada..73892c6450 100644
> --- a/arch/riscv/dts/k210-maix-bit.dts
> +++ b/arch/riscv/dts/k210-maix-bit.dts
> @@ -141,7 +141,7 @@
> pinmux = ,
> ,
> ,
> -;
> +; /* cs */
> };
> };
>
> @@ -149,3 +149,47 @@
> pinctrl-0 = <_dvp>;
> pinctrl-names = "default";
> };
> +
> + {
> + pinctrl-0 = <_spi0>;
> + pinctrl-names = "default";
> + num-cs = <1>;
> + cs-gpios = < 20 0>;
> +
> + panel@0 {
> + compatible = "sitronix,st7789v";
> + reg = <0>;
> + reset-gpios = < 21 GPIO_ACTIVE_LOW>;
> + dc-gpios = < 22 0>;
> + spi-max-frequency = <1500>;
> + status = "disabled";
> + };
> +};
> +
> + {
> + pinctrl-0 = <_spi1>;
> + pinctrl-names = "default";
> + num-cs = <1>;
> + cs-gpios = < 13 0>;
> + status = "okay";
> +
> + slot@0 {
> + compatible = "mmc-spi-slot";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> + voltage-ranges = <3300 3300>;
> + broken-cd;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + spi-flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <5000>;
> + m25p,fast-read;
> + broken-flash-reset;
> + };
> +};
> diff --git a/arch/riscv/dts/k210.dtsi b/arch/riscv/dts/k210.dtsi
> index 429891d651..fe47ee7aaf 100644
> --- a/arch/riscv/dts/k210.dtsi
> +++ b/arch/riscv/dts/k210.dtsi
> @@ -495,6 +495,8 @@
> interrupts = <24>;
> clocks = < K210_CLK_DVP>;
> resets = < K210_RST_DVP>;
> + kendryte,sysctl = <>;
> + kendryte,misc-offset = ;
> status = "disabled";
> };
>
> --
> 2.28.0
>
Re: OpenBSI and U-Boot
Hi Atish > On Mon, Aug 10, 2020 at 10:30 PM Heinrich Schuchardt > wrote: > > > > On 8/11/20 3:55 AM, Rick Chen wrote: > > > Hi Heinrich > > > > > >> Am 9. August 2020 22:08:23 MESZ schrieb Atish Patra > > >> : > > >>> On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt > > >>> wrote: > > > > On 8/8/20 5:32 PM, Sean Anderson wrote: > > > On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: > > >> Hello Anup, > > >> > > >> I have looking at you OpenSBI code firmware/payloads/test_head.S. > > >>> Here > > > > > > I think the real start is in firmware/fw_base.S. From there, > > >>> secondary > > > harts loop first in _wait_relocate_copy_done, and then in > > > _wait_for_boot_hart, and then they execute the next stage via > > > _start_warm and sbi_init. > > > > > >> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart > > >>> in to > > >> an enless loop (hang). > > > > > > As far as I can tell, U-Boot has all harts execute the next stage > > >>> when > > > SMP is enabled. smp_call_function has all harts execute that > > >>> function. > > > > U-Boot can only run on one hart. Are the other harts trapped in > > secondary_hart_loop()? How do we ensure that an UEFI payload does not > > overwrite this memory location? > > > > >>> > > >>> If you are booting Linux, U-Boot runs in S-mode and SMP is disabled. > > >> > > >> Would that also hold true on the Kendryte K210? For all what can see the > > >> secondary hart enters U-Boot and is only restrained by WFI and otherwise > > >> kept in an endless loop. > > >> > > >> I am wondering if that endless loop needs to be marked as reserved > > >> memory for Linux. > > > > > > Currently if U-Boot run in S-Mode, SMP is disable, there will exist > > > OpenSBI version compatible issue. > > > You shall use OpenSBI v0.7 with HSM, thus it will trap the other harts > > > in OpenSBI and only main hart will jump to kernel from U-Boot proper. > > > > > > Thanks, > > > Rick > > > > > > > HSM is described here: > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#hart-state-management-extension-extension-id-0x48534d-hsm > > > > Currently the Kendryte K210 has no SPL. So OpenSBI would be running > > before U-Boot. > > > > Will OpenSBI v0.7 by itself stop the other harts or do we need to call > > sbi_hart_stop() in U-Boot? Unfortunately opensbi/README.md and > > riscv-sbi.adoc both leave this open. > > > > OpenSBI will put all non-booting harts into wfi in sbi_hsm_wait > https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_hsm.c#L119 > > The S-mode OS is required to call sbi_hsm_start for all non-booting harts > so that they enter S-mode. > > Are you planning to add HSM extension just for Kendryte ? I have finished this part of jobs internally but still need some time to do code cleanup and prepare patchs. Thanks, Rick > > > Best regards > > > > Heinrich > > > > >> > > >>> All memory regions containing OpenSBI code are reserved. Thus, U-Boot > > >>> won't touch that. > > >>> U-Boot also marks the run time services memory region as reserved as > > >>> well. > > >>> Thus, Linux kernel won't touch any of those memory regions either. > > >>> > > spl_secondary_hart_stack_gd_setup() can jump to hang() if the call to > > secondary_hart_relocate() fails. > > > > > > > >> > > >> When Linux boots via UEFI it will wake up the extra harts after > > >> ExitBootServices(). So I assume we should define function hang() > > >>> in > > >> lib/hang.c as __efi_runtime to avoid seeing it overwritten by the > > >>> EFI > > >> payload. > > >> > > >> @Ard: > > >> Does Linux take care of the hanging harts and redirect them to its > > >>> own > > >> routine before SetVirtualAddressMap()? Otherwise anything could > > >>> happen. > > >> > > >> On the Kendryte K210 we don't have SPL. So we will not boot in the > > >> sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply > > >>> that > > >> we have to implement the hart lottery at the entry point of main > > >>> U-Boot > > >> in this case? > > > > > > Isn't the hart lottery already implemented for U-Boot? E.g. around > > >>> line > > > 100 of arch/riscv/cpu/start.S. > > > > Thanks for the hint. > > > > > > > > On another note, does Linux support S-Mode NOMMU? I was under the > > > impression that NOMMU implied M-Mode (or the other way around). > > > > Have a look at > > > > > > >>> https://linuxplumbersconf.org/event/4/contributions/386/attachments/298/502/RISC-V-NOMMU-Linux-Plumbers-2019.pdf > > > > Best regards > > > > Heinrich > > >> > > > > > -- > Regards, > Atish
[PATCH] efi_loader: variable: keep temporary buffer during the authentication
This is a bug fix; Setting an authenticated variable may fail due to
a memory corruption in the authentication.
A temporary buffer will, if needed, be allocated to parse a variable's
authentication data, and some portion of buffer, specifically signer's
certificates, will be referenced by efi_signature_verify().
So the buffer should be kept valid until the authentication process
is finished.
Signed-off-by: AKASHI Takahiro
Tested-by: Heinrich Schuchardt
---
lib/efi_loader/efi_variable.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index e509d6dbf0cf..0c06931135e3 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -37,16 +37,21 @@ static u8 pkcs7_hdr[] = {
* efi_variable_parse_signature - parse a signature in variable
* @buf: Pointer to variable's value
* @buflen:Length of @buf
+ * @tmpbuf:Pointer to temporary buffer
*
* Parse a signature embedded in variable's value and instantiate
* a pkcs7_message structure. Since pkcs7_parse_message() accepts only
* pkcs7's signedData, some header needed be prepended for correctly
* parsing authentication data, particularly for variable's.
+ * A temporary buffer will be allocated if needed, and it should be
+ * kept valid during the authentication because some data in the buffer
+ * will be referenced by efi_signature_verify().
*
* Return: Pointer to pkcs7_message structure on success, NULL on error
*/
static struct pkcs7_message *efi_variable_parse_signature(const void *buf,
- size_t buflen)
+ size_t buflen,
+ u8 **tmpbuf)
{
u8 *ebuf;
size_t ebuflen, len;
@@ -59,7 +64,9 @@ static struct pkcs7_message
*efi_variable_parse_signature(const void *buf,
if (buflen > sizeof(pkcs7_hdr) &&
!memcmp(&((u8 *)buf)[4], _hdr[4], 11)) {
msg = pkcs7_parse_message(buf, buflen);
- goto out;
+ if (IS_ERR(msg))
+ return NULL;
+ return msg;
}
/*
@@ -94,12 +101,12 @@ static struct pkcs7_message
*efi_variable_parse_signature(const void *buf,
msg = pkcs7_parse_message(ebuf, ebuflen);
- free(ebuf);
-
-out:
- if (IS_ERR(msg))
+ if (IS_ERR(msg)) {
+ free(ebuf);
return NULL;
+ }
+ *tmpbuf = ebuf;
return msg;
}
@@ -136,6 +143,7 @@ static efi_status_t efi_variable_authenticate(u16 *variable,
struct efi_time timestamp;
struct rtc_time tm;
u64 new_time;
+ u8 *ebuf;
enum efi_auth_var_type var_type;
efi_status_t ret;
@@ -143,6 +151,7 @@ static efi_status_t efi_variable_authenticate(u16 *variable,
truststore = NULL;
truststore2 = NULL;
regs = NULL;
+ ebuf = NULL;
ret = EFI_SECURITY_VIOLATION;
if (*data_size < sizeof(struct efi_variable_authentication_2))
@@ -204,9 +213,12 @@ static efi_status_t efi_variable_authenticate(u16
*variable,
/* variable's signature list */
if (auth->auth_info.hdr.dwLength < sizeof(auth->auth_info))
goto err;
+
+ /* ebuf should be kept valid during the authentication */
var_sig = efi_variable_parse_signature(auth->auth_info.cert_data,
auth->auth_info.hdr.dwLength
- - sizeof(auth->auth_info));
+ - sizeof(auth->auth_info),
+ );
if (!var_sig) {
EFI_PRINT("Parsing variable's signature failed\n");
goto err;
@@ -262,6 +274,7 @@ err:
efi_sigstore_free(truststore);
efi_sigstore_free(truststore2);
pkcs7_free_message(var_sig);
+ free(ebuf);
free(regs);
return ret;
--
2.27.0
Re: [PATCH 0/2] fs/squashfs: Add new decompression algorithms
On Tue, 11 Aug 2020 11:13:41 -0400 Tom Rini wrote: > On Tue, Aug 11, 2020 at 03:17:53PM +0200, Joao Marcos Costa wrote: > > > Hello, > > > > Following the SquashFS support, this series adds support for LZO > > and ZSTD algorithms. The only compression type enabled by default > > is ZLIB, so LZO and ZSTD need to be manually selected. > > > > Joao Marcos Costa (2): > > fs/squashfs: add support for LZO decompression > > fs/squashfs: add support for ZSTD decompression > > > > fs/squashfs/sqfs_decompressor.c | 60 > > +++-- 1 file changed, 58 insertions(+), > > 2 deletions(-) > > Can we add tests for this to sandbox? Thanks! Sure, I will enable the lzo and zstd configs for, and I will make some actual changes to the test scripts I added, because right now they are not really "scalable" (thinking of new compression algorithms). Best regards, Joao
Re: [PATCH] test/py: fix SquashFS tests
On Mon, Aug 10, 2020 at 02:37:27PM +0200, Joao Marcos Costa wrote: > Use "cons.config.build_dir" instead of writing to the source directory > (read-only). This will fix the test failures in Azure. > > Signed-off-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request for UEFI sub-system for efi-2020-10-rc3
On Tue, Aug 11, 2020 at 06:04:00AM +0200, Heinrich Schuchardt wrote: > The following changes since commit b904d79e4809bf35cf53c2e5fee0f73647bab07a: > > Makefile: sunxi: Don't use binman to build ATF image (2020-08-08 > 08:31:52 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2020-10-rc3 > > for you to fetch changes up to 0ad64007feb93dced461647c75f782160b1c8ede: > > efi_loader: set load options in boot manager (2020-08-08 19:03:24 +0200) > > Gitlab CI reported no problems: > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/4371 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
On 11/08/20 8:28 pm, Jan Kiszka wrote: > On 11.08.20 16:36, Lokesh Vutla wrote: >> Hi Jan, >> >> On 11/08/20 6:07 pm, Jan Kiszka wrote: >>> On 11.08.20 12:46, Lokesh Vutla wrote: On 11/08/20 4:12 pm, Jan Kiszka wrote: > On 11.08.20 12:33, Lokesh Vutla wrote: >> >> >> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>> kernel, augmented with firmware loading as needed on the AM65x. >>> >>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>> support will be posted soon). >>> >>> Changes in v2: >>> - keep watchdog powered when handing over to Linux >>> - drop unneeded explicit power-on >>> - account for RTI firmware locking the power domain >> >> Patch 1 and 3 merged applied. >> > > Thanks. Still taking workable suggestions for loading the firmware. FIT image is the one that I can think off. Since SPL is loading the FIT image, SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot can start the remote cores using this info. >>> >>> OK, just the ensure I got the idea correctly: >>> >>> - extend struct spl_handoff or arch_spl_handoff with the fit image >>> loadaddr that spl is processing >> >> Yes >> >>> >>> - stick the watchdog firmware into the u-boot proper fit image >>> (generated by tools/k3_fit_atf.sh or shipped via the board folder, as >>> in our case) >> >> IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. >> May > > Yeah, right. We also have a fit image for u-boot proper, that confused me. > >> be create a new one that packs fit image with u-boot and firmware. Or can you >> check if binman in u-boot works for you? > > You mean, pack the u-boot proper with the firmware? Then we could stick the > result in an signed fit image when needed. And I could read the offset of the > firmware from the generated dtb - provided binman can deal with multiple > configurations like we have. If that is possible I am okay with it. Thanks and regards, Lokesh > > Jan >
[PATCH v2 6/8] stdio: Update to use compiler for Kconfig checks
Drop use of the preprocessor where possible.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/stdio.c | 172 -
1 file changed, 83 insertions(+), 89 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index 33a795e7bb4..1921dc67194 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -18,10 +18,7 @@
#include
#include
#include
-
-#if defined(CONFIG_SYS_I2C)
#include
-#endif
#include
@@ -109,7 +106,6 @@ struct list_head* stdio_get_list(void)
return &(devs.list);
}
-#ifdef CONFIG_DM_VIDEO
/**
* stdio_probe_device() - Find a device which provides the given stdio device
*
@@ -160,7 +156,6 @@ static int stdio_probe_device(const char *name, enum
uclass_id id,
return 0;
}
-#endif
struct stdio_dev *stdio_get_by_name(const char *name)
{
@@ -175,22 +170,23 @@ struct stdio_dev *stdio_get_by_name(const char *name)
if (strcmp(sdev->name, name) == 0)
return sdev;
}
-#ifdef CONFIG_DM_VIDEO
- /*
-* We did not find a suitable stdio device. If there is a video
-* driver with a name starting with 'vidconsole', we can try probing
-* that in the hope that it will produce the required stdio device.
-*
-* This function is sometimes called with the entire value of
-* 'stdout', which may include a list of devices separate by commas.
-* Obviously this is not going to work, so we ignore that case. The
-* call path in that case is console_init_r() -> search_device() ->
-* stdio_get_by_name().
-*/
- if (!strncmp(name, "vidconsole", 10) && !strchr(name, ',') &&
- !stdio_probe_device(name, UCLASS_VIDEO, ))
- return sdev;
-#endif
+ if (IS_ENABLED(CONFIG_DM_VIDEO)) {
+ /*
+* We did not find a suitable stdio device. If there is a video
+* driver with a name starting with 'vidconsole', we can try
+* probing that in the hope that it will produce the required
+* stdio device.
+*
+* This function is sometimes called with the entire value of
+* 'stdout', which may include a list of devices separate by
+* commas. Obviously this is not going to work, so we ignore
+* that case. The call path in that case is
+* console_init_r() -> search_device() -> stdio_get_by_name()
+*/
+ if (!strncmp(name, "vidconsole", 10) && !strchr(name, ',') &&
+ !stdio_probe_device(name, UCLASS_VIDEO, ))
+ return sdev;
+ }
return NULL;
}
@@ -234,7 +230,6 @@ int stdio_register(struct stdio_dev *dev)
/* deregister the device "devname".
* returns 0 if success, -1 if device is assigned and 1 if devname not found
*/
-#if CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)
int stdio_deregister_dev(struct stdio_dev *dev, int force)
{
int l;
@@ -281,7 +276,6 @@ int stdio_deregister(const char *devname, int force)
return stdio_deregister_dev(dev, force);
}
-#endif /* CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER) */
int stdio_init_tables(void)
{
@@ -305,87 +299,87 @@ int stdio_init_tables(void)
int stdio_add_devices(void)
{
-#ifdef CONFIG_DM_KEYBOARD
struct udevice *dev;
struct uclass *uc;
int ret;
- /*
-* For now we probe all the devices here. At some point this should be
-* done only when the devices are required - e.g. we have a list of
-* input devices to start up in the stdin environment variable. That
-* work probably makes more sense when stdio itself is converted to
-* driver model.
-*
-* TODO(s...@chromium.org): Convert changing uclass_first_device() etc.
-* to return the device even on error. Then we could use that here.
-*/
- ret = uclass_get(UCLASS_KEYBOARD, );
- if (ret)
- return ret;
-
- /* Don't report errors to the caller - assume that they are non-fatal */
- uclass_foreach_dev(dev, uc) {
- ret = device_probe(dev);
+ if (IS_ENABLED(CONFIG_DM_KEYBOARD)) {
+ /*
+* For now we probe all the devices here. At some point this
+* should be done only when the devices are required - e.g. we
+* have a list of input devices to start up in the stdin
+* environment variable. That work probably makes more sense
+* when stdio itself is converted to driver model.
+*
+* TODO(s...@chromium.org): Convert changing
+* uclass_first_device() etc. to return the device even on
+* error. Then we could use that here.
+*/
+ ret = uclass_get(UCLASS_KEYBOARD, );
if (ret)
-
[PATCH v2 8/8] stdio: Tidy up the coding style
Bring the coding style in this file up to the current level.
Signed-off-by: Simon Glass
---
Changes in v2:
- Rebase to master
common/stdio.c | 37 -
include/stdio_dev.h | 9 +
2 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index d67ea60d6c6..84c36a735c0 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -191,16 +191,15 @@ struct stdio_dev *stdio_get_by_name(const char *name)
return NULL;
}
-struct stdio_dev* stdio_clone(struct stdio_dev *dev)
+struct stdio_dev *stdio_clone(struct stdio_dev *dev)
{
struct stdio_dev *_dev;
- if(!dev)
+ if (!dev)
return NULL;
_dev = calloc(1, sizeof(struct stdio_dev));
-
- if(!_dev)
+ if (!_dev)
return NULL;
memcpy(_dev, dev, sizeof(struct stdio_dev));
@@ -213,7 +212,7 @@ int stdio_register_dev(struct stdio_dev *dev, struct
stdio_dev **devp)
struct stdio_dev *_dev;
_dev = stdio_clone(dev);
- if(!_dev)
+ if (!_dev)
return -ENODEV;
list_add_tail(&_dev->list, );
if (devp)
@@ -227,41 +226,38 @@ int stdio_register(struct stdio_dev *dev)
return stdio_register_dev(dev, NULL);
}
-/* deregister the device "devname".
- * returns 0 if success, -1 if device is assigned and 1 if devname not found
- */
int stdio_deregister_dev(struct stdio_dev *dev, int force)
{
- int l;
struct list_head *pos;
char temp_names[3][16];
+ int i;
/* get stdio devices (ListRemoveItem changes the dev list) */
- for (l=0 ; l< MAX_FILES; l++) {
- if (stdio_devices[l] == dev) {
+ for (i = 0 ; i < MAX_FILES; i++) {
+ if (stdio_devices[i] == dev) {
if (force) {
- strcpy(temp_names[l], "nulldev");
+ strcpy(temp_names[i], "nulldev");
continue;
}
/* Device is assigned -> report error */
- return -1;
+ return -EBUSY;
}
- memcpy (_names[l][0],
- stdio_devices[l]->name,
- sizeof(temp_names[l]));
+ memcpy(_names[i][0], stdio_devices[i]->name,
+ sizeof(temp_names[i]));
}
list_del(>list);
free(dev);
- /* reassign Device list */
+ /* reassign device list */
list_for_each(pos, ) {
dev = list_entry(pos, struct stdio_dev, list);
- for (l=0 ; l< MAX_FILES; l++) {
- if(strcmp(dev->name, temp_names[l]) == 0)
- stdio_devices[l] = dev;
+ for (i = 0 ; i < MAX_FILES; i++) {
+ if (strcmp(dev->name, temp_names[i]) == 0)
+ stdio_devices[i] = dev;
}
}
+
return 0;
}
@@ -270,7 +266,6 @@ int stdio_deregister(const char *devname, int force)
struct stdio_dev *dev;
dev = stdio_get_by_name(devname);
-
if (!dev) /* device not found */
return -ENODEV;
diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index b61c0c6ceff..48871a6a22b 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -84,6 +84,15 @@ int stdio_init(void);
void stdio_print_current_devices(void);
int stdio_deregister(const char *devname, int force);
+
+/**
+ * stdio_deregister_dev() - deregister the device "devname".
+ *
+ * @dev: Stdio device to deregister
+ * @force: true to force deregistration even if in use
+ *
+ * returns 0 on success, -EBUSY if device is assigned
+ */
int stdio_deregister_dev(struct stdio_dev *dev, int force);
struct list_head *stdio_get_list(void);
struct stdio_dev *stdio_get_by_name(const char *name);
--
2.28.0.236.gb10cc79966-goog
[PATCH v2 7/8] stdio: Drop brackets around .list
These brackets are not needed. Drop them.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/stdio.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/common/stdio.c b/common/stdio.c
index 1921dc67194..d67ea60d6c6 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -103,7 +103,7 @@ static void drv_system_init (void)
*/
struct list_head* stdio_get_list(void)
{
- return &(devs.list);
+ return
}
/**
@@ -165,7 +165,7 @@ struct stdio_dev *stdio_get_by_name(const char *name)
if (!name)
return NULL;
- list_for_each(pos, &(devs.list)) {
+ list_for_each(pos, ) {
sdev = list_entry(pos, struct stdio_dev, list);
if (strcmp(sdev->name, name) == 0)
return sdev;
@@ -215,7 +215,7 @@ int stdio_register_dev(struct stdio_dev *dev, struct
stdio_dev **devp)
_dev = stdio_clone(dev);
if(!_dev)
return -ENODEV;
- list_add_tail(&(_dev->list), &(devs.list));
+ list_add_tail(&_dev->list, );
if (devp)
*devp = _dev;
@@ -251,11 +251,11 @@ int stdio_deregister_dev(struct stdio_dev *dev, int force)
sizeof(temp_names[l]));
}
- list_del(&(dev->list));
+ list_del(>list);
free(dev);
/* reassign Device list */
- list_for_each(pos, &(devs.list)) {
+ list_for_each(pos, ) {
dev = list_entry(pos, struct stdio_dev, list);
for (l=0 ; l< MAX_FILES; l++) {
if(strcmp(dev->name, temp_names[l]) == 0)
@@ -292,7 +292,7 @@ int stdio_init_tables(void)
#endif /* CONFIG_NEEDS_MANUAL_RELOC */
/* Initialize the list */
- INIT_LIST_HEAD(&(devs.list));
+ INIT_LIST_HEAD();
return 0;
}
--
2.28.0.236.gb10cc79966-goog
[PATCH v2 2/8] Convert CONFIG_SPLASH_SCREEN et al to Kconfig
This converts the following to Kconfig: CONFIG_SPLASH_SCREEN CONFIG_SPLASH_SCREEN_ALIGN CONFIG_SPLASHIMAGE_GUARD CONFIG_SPLASH_SOURCE Signed-off-by: Simon Glass --- (no changes since v1) README | 42 configs/apalis_imx6_defconfig | 2 + configs/aristainetos2_defconfig | 2 + configs/aristainetos2b_defconfig| 2 + configs/aristainetos2bcsl_defconfig | 2 + configs/aristainetos2c_defconfig| 2 + configs/cgtqmx6eval_defconfig | 2 + configs/cm_fx6_defconfig| 2 + configs/colibri-imx6ull_defconfig | 2 + configs/colibri_imx6_defconfig | 2 + configs/colibri_imx7_defconfig | 2 + configs/colibri_imx7_emmc_defconfig | 2 + configs/colibri_vf_defconfig| 1 + configs/dms-ba16-1g_defconfig | 2 + configs/dms-ba16_defconfig | 2 + configs/eb_cpu5282_defconfig| 1 + configs/eb_cpu5282_internal_defconfig | 1 + configs/gwventana_emmc_defconfig| 1 + configs/gwventana_gw5904_defconfig | 1 + configs/gwventana_nand_defconfig| 1 + configs/imx6dl_icore_nand_defconfig | 2 + configs/imx6q_icore_nand_defconfig | 2 + configs/imx6qdl_icore_mmc_defconfig | 2 + configs/imx6qdl_icore_nand_defconfig| 2 + configs/imxrt1050-evk_defconfig | 2 + configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + configs/libretech-ac_defconfig | 2 + configs/libretech-cc_defconfig | 2 + configs/libretech-s905d-pc_defconfig| 2 + configs/libretech-s912-pc_defconfig | 2 + configs/m53menlo_defconfig | 4 ++ configs/marsboard_defconfig | 2 + configs/mx23evk_defconfig | 1 + configs/mx28evk_auart_console_defconfig | 1 + configs/mx28evk_defconfig | 1 + configs/mx28evk_nand_defconfig | 1 + configs/mx28evk_spi_defconfig | 1 + configs/mx51evk_defconfig | 1 + configs/mx53loco_defconfig | 1 + configs/mx6cuboxi_defconfig | 2 + configs/mx6qsabrelite_defconfig | 2 + configs/mx6sabreauto_defconfig | 2 + configs/mx6sabresd_defconfig| 2 + configs/mx6sxsabresd_defconfig | 2 + configs/mx6ul_14x14_evk_defconfig | 2 + configs/mx6ul_9x9_evk_defconfig | 2 + configs/mx7dsabresd_defconfig | 2 + configs/mx7dsabresd_qspi_defconfig | 2 + configs/nitrogen6dl2g_defconfig | 2 + configs/nitrogen6dl_defconfig | 2 + configs/nitrogen6q2g_defconfig | 2 + configs/nitrogen6q_defconfig| 2 + configs/nitrogen6s1g_defconfig | 2 + configs/nitrogen6s_defconfig| 2 + configs/nokia_rx51_defconfig| 1 + configs/novena_defconfig| 1 + configs/odroid-c2_defconfig | 2 + configs/odroid-c4_defconfig | 2 + configs/opos6uldev_defconfig| 3 + configs/pico-dwarf-imx6ul_defconfig | 2 + configs/pico-dwarf-imx7d_defconfig | 2 + configs/pico-hobbit-imx6ul_defconfig| 2 + configs/pico-hobbit-imx7d_defconfig | 2 + configs/pico-imx6_defconfig | 2 + configs/pico-imx6ul_defconfig | 2 + configs/pico-imx7d_bl33_defconfig | 2 + configs/pico-imx7d_defconfig| 2 + configs/pico-nymph-imx7d_defconfig | 2 + configs/pico-pi-imx6ul_defconfig| 2 + configs/pico-pi-imx7d_defconfig | 2 + configs/pxm2_defconfig | 2 + configs/riotboard_defconfig | 2 + configs/riotboard_spl_defconfig | 2 + configs/rut_defconfig | 2 + configs/s5p4418_nanopi2_defconfig | 3 + configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + configs/sei510_defconfig| 2 + configs/sei610_defconfig| 2 + configs/stm32f746-disco_defconfig | 2 + configs/stm32f769-disco_defconfig | 2 + configs/tools-only_defconfig| 1 + configs/wandboard_defconfig | 2 + drivers/video/Kconfig | 85 + include/configs/M52277EVB.h | 1 - include/configs/advantech_dms-ba16.h| 2 - include/configs/apalis_imx6.h | 2 - include/configs/aristainetos2.h | 2 - include/configs/cgtqmx6eval.h | 2 - include/configs/cm_fx6.h| 2 - include/configs/colibri-imx6ull.h | 2 - include/configs/colibri_imx6.h | 2 - include/configs/colibri_imx7.h | 2 - include/configs/colibri_vf.h| 1 - include/configs/eb_cpu5282.h| 1 - include/configs/embestmx6boards.h | 2 -
[PATCH v2 1/8] moveconfig: Skip binary and ELF files
Add a few more file extensions to the list of files that should not be
processed. This avoids unicode errors, for example.
Signed-off-by: Simon Glass
---
(no changes since v1)
tools/moveconfig.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/moveconfig.py b/tools/moveconfig.py
index 36361f9ed1b..9514d9a00cb 100755
--- a/tools/moveconfig.py
+++ b/tools/moveconfig.py
@@ -666,7 +666,8 @@ def cleanup_headers(configs, options):
if dirpath == os.path.join('include', 'generated'):
continue
for filename in filenames:
-if not filename.endswith(('~', '.dts', '.dtsi')):
+if not filename.endswith(('~', '.dts', '.dtsi', '.bin',
+ '.elf')):
header_path = os.path.join(dirpath, filename)
# This file contains UTF-16 data and no CONFIG symbols
if header_path == 'include/video_font_data.h':
--
2.28.0.236.gb10cc79966-goog
[PATCH v2 3/8] Convert CONFIG_SYS_DEVICE_NULLDEV to Kconfig
This converts the following to Kconfig: CONFIG_SYS_DEVICE_NULLDEV Signed-off-by: Simon Glass --- (no changes since v1) common/Kconfig | 16 configs/M5249EVB_defconfig | 1 + configs/colibri_pxa270_defconfig | 1 + doc/README.silent| 2 +- include/configs/M5249EVB.h | 2 -- include/configs/colibri_pxa270.h | 2 -- scripts/config_whitelist.txt | 1 - 7 files changed, 19 insertions(+), 6 deletions(-) diff --git a/common/Kconfig b/common/Kconfig index 62d78c5bd73..5a6d0e0e79b 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -635,6 +635,22 @@ config SYS_STDIO_DEREGISTER removed (for example a USB keyboard) then this option can be enabled to ensure this is handled correctly. +config SPL_SYS_STDIO_DEREGISTER + bool "Allow deregistering stdio devices in SPL" + help + Generally there is no need to deregister stdio devices since they + are never deactivated. But if a stdio device is used which can be + removed (for example a USB keyboard) then this option can be + enabled to ensure this is handled correctly. This is very rarely + needed in SPL. + +config SYS_DEVICE_NULLDEV + bool "Enable a null device for stdio" + help + Enable creation of a "nulldev" stdio device. This allows silent + operation of the console by setting stdout to "nulldev". Enable + this to use a serial console under board control. + endmenu menu "Logging" diff --git a/configs/M5249EVB_defconfig b/configs/M5249EVB_defconfig index d4871c60c70..8f8a4a6bad5 100644 --- a/configs/M5249EVB_defconfig +++ b/configs/M5249EVB_defconfig @@ -5,6 +5,7 @@ CONFIG_ENV_SECT_SIZE=0x2000 CONFIG_TARGET_M5249EVB=y CONFIG_DEFAULT_DEVICE_TREE="M5249EVB" CONFIG_SYS_CONSOLE_INFO_QUIET=y +CONFIG_SYS_DEVICE_NULLDEV=y # CONFIG_DISPLAY_BOARDINFO is not set # CONFIG_CMDLINE_EDITING is not set # CONFIG_AUTOBOOT is not set diff --git a/configs/colibri_pxa270_defconfig b/configs/colibri_pxa270_defconfig index 89e05608423..2865730b8ff 100644 --- a/configs/colibri_pxa270_defconfig +++ b/configs/colibri_pxa270_defconfig @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x4 CONFIG_ENV_VARS_UBOOT_CONFIG=y CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=tty0 console=ttyS0,115200" +CONFIG_SYS_DEVICE_NULLDEV=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y # CONFIG_CMDLINE_EDITING is not set diff --git a/doc/README.silent b/doc/README.silent index 6d90a0ec403..00288e03b01 100644 --- a/doc/README.silent +++ b/doc/README.silent @@ -19,7 +19,7 @@ The following actions are taken if "silent" is set at boot time: - When the console devices have been initialized, "stdout" and "stderr" are set to "nulldev", so subsequent messages are suppressed automatically. Make sure to enable "nulldev" by - #defining CONFIG_SYS_DEVICE_NULLDEV in your board config file. + enabling CONFIG_SYS_DEVICE_NULLDEV in your board defconfig file. - When booting a linux kernel, the "bootargs" are fixed up so that the argument "console=" will be in the command line, no matter how diff --git a/include/configs/M5249EVB.h b/include/configs/M5249EVB.h index de7132940c1..1a1a1107654 100644 --- a/include/configs/M5249EVB.h +++ b/include/configs/M5249EVB.h @@ -31,8 +31,6 @@ */ #undef CONFIG_BOOTP_BOOTFILESIZE -#define CONFIG_SYS_DEVICE_NULLDEV 1 /* include nulldev device */ - #define CONFIG_SYS_LOAD_ADDR 0x20/* default load address */ /* diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h index 4686b8946e3..3dedcdaad28 100644 --- a/include/configs/colibri_pxa270.h +++ b/include/configs/colibri_pxa270.h @@ -69,8 +69,6 @@ #defineCONFIG_BOOTP_BOOTFILESIZE #endif -#defineCONFIG_SYS_DEVICE_NULLDEV 1 - /* * Clock Configuration */ diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 5c6790bd8df..14d5e4c1757 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -2117,7 +2117,6 @@ CONFIG_SYS_DEBUG_SERVER_FW_IN_NOR CONFIG_SYS_DEFAULT_LPDDR2_TIMINGS CONFIG_SYS_DEFAULT_VIDEO_MODE CONFIG_SYS_DEF_EEPROM_ADDR -CONFIG_SYS_DEVICE_NULLDEV CONFIG_SYS_DFU_DATA_BUF_SIZE CONFIG_SYS_DFU_MAX_FILE_SIZE CONFIG_SYS_DIAG_ADDR -- 2.28.0.236.gb10cc79966-goog
[PATCH v2 4/8] stdio: Tidy up use of CONFIG_SYS_DEVICE_NULLDEV
Now that this is in Kconfig we can move the logic at the top of the file
to Kconfig, and use if() instead of #if. Update the file with these
changes.
Signed-off-by: Simon Glass
---
(no changes since v1)
common/Kconfig | 1 +
common/stdio.c | 30 ++
2 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 5a6d0e0e79b..8f61aa76024 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -646,6 +646,7 @@ config SPL_SYS_STDIO_DEREGISTER
config SYS_DEVICE_NULLDEV
bool "Enable a null device for stdio"
+ default y if SPLASH_SCREEN || SYS_STDIO_DEREGISTER
help
Enable creation of a "nulldev" stdio device. This allows silent
operation of the console by setting stdout to "nulldev". Enable
diff --git a/common/stdio.c b/common/stdio.c
index 2119204b982..33a795e7bb4 100644
--- a/common/stdio.c
+++ b/common/stdio.c
@@ -31,15 +31,6 @@ static struct stdio_dev devs;
struct stdio_dev *stdio_devices[] = { NULL, NULL, NULL };
char *stdio_names[MAX_FILES] = { "stdin", "stdout", "stderr" };
-#if defined(CONFIG_SPLASH_SCREEN) && !defined(CONFIG_SYS_DEVICE_NULLDEV)
-#defineCONFIG_SYS_DEVICE_NULLDEV 1
-#endif
-
-#if CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER)
-#defineCONFIG_SYS_DEVICE_NULLDEV 1
-#endif
-
-#ifdef CONFIG_SYS_DEVICE_NULLDEV
static void nulldev_putc(struct stdio_dev *dev, const char c)
{
/* nulldev is empty! */
@@ -55,7 +46,6 @@ static int nulldev_input(struct stdio_dev *dev)
/* nulldev is empty! */
return 0;
}
-#endif
static void stdio_serial_putc(struct stdio_dev *dev, const char c)
{
@@ -96,18 +86,18 @@ static void drv_system_init (void)
dev.tstc = stdio_serial_tstc;
stdio_register ();
-#ifdef CONFIG_SYS_DEVICE_NULLDEV
- memset (, 0, sizeof (dev));
+ if (CONFIG_IS_ENABLED(SYS_DEVICE_NULLDEV)) {
+ memset(, '\0', sizeof(dev));
- strcpy (dev.name, "nulldev");
- dev.flags = DEV_FLAGS_OUTPUT | DEV_FLAGS_INPUT;
- dev.putc = nulldev_putc;
- dev.puts = nulldev_puts;
- dev.getc = nulldev_input;
- dev.tstc = nulldev_input;
+ strcpy(dev.name, "nulldev");
+ dev.flags = DEV_FLAGS_OUTPUT | DEV_FLAGS_INPUT;
+ dev.putc = nulldev_putc;
+ dev.puts = nulldev_puts;
+ dev.getc = nulldev_input;
+ dev.tstc = nulldev_input;
- stdio_register ();
-#endif
+ stdio_register();
+ }
}
/**
--
2.28.0.236.gb10cc79966-goog
[PATCH v2 5/8] stdio: Drop #ifdefs in the header file
These prevent the use of IS_ENABLED() and are unnecessary. Drop them and fix a few code-style nits nearby. Signed-off-by: Simon Glass --- (no changes since v1) include/stdio_dev.h | 40 1 file changed, 12 insertions(+), 28 deletions(-) diff --git a/include/stdio_dev.h b/include/stdio_dev.h index cd0cd601bff..b61c0c6ceff 100644 --- a/include/stdio_dev.h +++ b/include/stdio_dev.h @@ -57,7 +57,7 @@ extern char *stdio_names[MAX_FILES]; /* * PROTOTYPES */ -intstdio_register (struct stdio_dev * dev); +int stdio_register(struct stdio_dev *dev); int stdio_register_dev(struct stdio_dev *dev, struct stdio_dev **devp); /** @@ -82,35 +82,19 @@ int stdio_add_devices(void); */ int stdio_init(void); -void stdio_print_current_devices(void); -#if CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER) +void stdio_print_current_devices(void); int stdio_deregister(const char *devname, int force); int stdio_deregister_dev(struct stdio_dev *dev, int force); -#endif -struct list_head* stdio_get_list(void); -struct stdio_dev* stdio_get_by_name(const char* name); -struct stdio_dev* stdio_clone(struct stdio_dev *dev); - -#ifdef CONFIG_LCD -intdrv_lcd_init (void); -#endif -#if defined(CONFIG_VIDEO) || defined(CONFIG_CFB_CONSOLE) -intdrv_video_init (void); -#endif -#ifdef CONFIG_KEYBOARD -intdrv_keyboard_init (void); -#endif -#ifdef CONFIG_USB_TTY -intdrv_usbtty_init (void); -#endif -#ifdef CONFIG_NETCONSOLE -intdrv_nc_init (void); -#endif -#ifdef CONFIG_JTAG_CONSOLE -int drv_jtag_console_init (void); -#endif -#ifdef CONFIG_CBMEM_CONSOLE +struct list_head *stdio_get_list(void); +struct stdio_dev *stdio_get_by_name(const char *name); +struct stdio_dev *stdio_clone(struct stdio_dev *dev); + +int drv_lcd_init(void); +int drv_video_init(void); +int drv_keyboard_init(void); +int drv_usbtty_init(void); +int drv_nc_init(void); +int drv_jtag_console_init(void); int cbmemc_init(void); -#endif #endif -- 2.28.0.236.gb10cc79966-goog
Re: [PATCH v2 0/8] stdio: Clean up stdio.c
+Tom Rini too On Tue, 11 Aug 2020 at 11:22, Simon Glass wrote: > > This file is quite old and has some crufty code. This series converts a > few things to Kconfig and updates the file. > > Changes in v2: > - Rebase to master > > Simon Glass (8): > moveconfig: Skip binary and ELF files > Convert CONFIG_SPLASH_SCREEN et al to Kconfig > Convert CONFIG_SYS_DEVICE_NULLDEV to Kconfig > stdio: Tidy up use of CONFIG_SYS_DEVICE_NULLDEV > stdio: Drop #ifdefs in the header file > stdio: Update to use compiler for Kconfig checks > stdio: Drop brackets around > stdio: Tidy up the coding style > > README | 42 > common/Kconfig | 17 ++ > common/stdio.c | 251 +++- > configs/M5249EVB_defconfig | 1 + > configs/apalis_imx6_defconfig | 2 + > configs/aristainetos2_defconfig | 2 + > configs/aristainetos2b_defconfig| 2 + > configs/aristainetos2bcsl_defconfig | 2 + > configs/aristainetos2c_defconfig| 2 + > configs/cgtqmx6eval_defconfig | 2 + > configs/cm_fx6_defconfig| 2 + > configs/colibri-imx6ull_defconfig | 2 + > configs/colibri_imx6_defconfig | 2 + > configs/colibri_imx7_defconfig | 2 + > configs/colibri_imx7_emmc_defconfig | 2 + > configs/colibri_pxa270_defconfig| 1 + > configs/colibri_vf_defconfig| 1 + > configs/dms-ba16-1g_defconfig | 2 + > configs/dms-ba16_defconfig | 2 + > configs/eb_cpu5282_defconfig| 1 + > configs/eb_cpu5282_internal_defconfig | 1 + > configs/gwventana_emmc_defconfig| 1 + > configs/gwventana_gw5904_defconfig | 1 + > configs/gwventana_nand_defconfig| 1 + > configs/imx6dl_icore_nand_defconfig | 2 + > configs/imx6q_icore_nand_defconfig | 2 + > configs/imx6qdl_icore_mmc_defconfig | 2 + > configs/imx6qdl_icore_nand_defconfig| 2 + > configs/imxrt1050-evk_defconfig | 2 + > configs/khadas-vim3_defconfig | 2 + > configs/khadas-vim3l_defconfig | 2 + > configs/libretech-ac_defconfig | 2 + > configs/libretech-cc_defconfig | 2 + > configs/libretech-s905d-pc_defconfig| 2 + > configs/libretech-s912-pc_defconfig | 2 + > configs/m53menlo_defconfig | 4 + > configs/marsboard_defconfig | 2 + > configs/mx23evk_defconfig | 1 + > configs/mx28evk_auart_console_defconfig | 1 + > configs/mx28evk_defconfig | 1 + > configs/mx28evk_nand_defconfig | 1 + > configs/mx28evk_spi_defconfig | 1 + > configs/mx51evk_defconfig | 1 + > configs/mx53loco_defconfig | 1 + > configs/mx6cuboxi_defconfig | 2 + > configs/mx6qsabrelite_defconfig | 2 + > configs/mx6sabreauto_defconfig | 2 + > configs/mx6sabresd_defconfig| 2 + > configs/mx6sxsabresd_defconfig | 2 + > configs/mx6ul_14x14_evk_defconfig | 2 + > configs/mx6ul_9x9_evk_defconfig | 2 + > configs/mx7dsabresd_defconfig | 2 + > configs/mx7dsabresd_qspi_defconfig | 2 + > configs/nitrogen6dl2g_defconfig | 2 + > configs/nitrogen6dl_defconfig | 2 + > configs/nitrogen6q2g_defconfig | 2 + > configs/nitrogen6q_defconfig| 2 + > configs/nitrogen6s1g_defconfig | 2 + > configs/nitrogen6s_defconfig| 2 + > configs/nokia_rx51_defconfig| 1 + > configs/novena_defconfig| 1 + > configs/odroid-c2_defconfig | 2 + > configs/odroid-c4_defconfig | 2 + > configs/opos6uldev_defconfig| 3 + > configs/pico-dwarf-imx6ul_defconfig | 2 + > configs/pico-dwarf-imx7d_defconfig | 2 + > configs/pico-hobbit-imx6ul_defconfig| 2 + > configs/pico-hobbit-imx7d_defconfig | 2 + > configs/pico-imx6_defconfig | 2 + > configs/pico-imx6ul_defconfig | 2 + > configs/pico-imx7d_bl33_defconfig | 2 + > configs/pico-imx7d_defconfig| 2 + > configs/pico-nymph-imx7d_defconfig | 2 + > configs/pico-pi-imx6ul_defconfig| 2 + > configs/pico-pi-imx7d_defconfig | 2 + > configs/pxm2_defconfig | 2 + > configs/riotboard_defconfig | 2 + > configs/riotboard_spl_defconfig | 2 + > configs/rut_defconfig | 2 + > configs/s5p4418_nanopi2_defconfig | 3 + > configs/sandbox64_defconfig | 1 + > configs/sandbox_defconfig | 1 + > configs/sandbox_flattree_defconfig | 1 + > configs/sandbox_spl_defconfig | 1 + > configs/sei510_defconfig| 2 + > configs/sei610_defconfig
[PATCH v2 0/8] stdio: Clean up stdio.c
This file is quite old and has some crufty code. This series converts a few things to Kconfig and updates the file. Changes in v2: - Rebase to master Simon Glass (8): moveconfig: Skip binary and ELF files Convert CONFIG_SPLASH_SCREEN et al to Kconfig Convert CONFIG_SYS_DEVICE_NULLDEV to Kconfig stdio: Tidy up use of CONFIG_SYS_DEVICE_NULLDEV stdio: Drop #ifdefs in the header file stdio: Update to use compiler for Kconfig checks stdio: Drop brackets around stdio: Tidy up the coding style README | 42 common/Kconfig | 17 ++ common/stdio.c | 251 +++- configs/M5249EVB_defconfig | 1 + configs/apalis_imx6_defconfig | 2 + configs/aristainetos2_defconfig | 2 + configs/aristainetos2b_defconfig| 2 + configs/aristainetos2bcsl_defconfig | 2 + configs/aristainetos2c_defconfig| 2 + configs/cgtqmx6eval_defconfig | 2 + configs/cm_fx6_defconfig| 2 + configs/colibri-imx6ull_defconfig | 2 + configs/colibri_imx6_defconfig | 2 + configs/colibri_imx7_defconfig | 2 + configs/colibri_imx7_emmc_defconfig | 2 + configs/colibri_pxa270_defconfig| 1 + configs/colibri_vf_defconfig| 1 + configs/dms-ba16-1g_defconfig | 2 + configs/dms-ba16_defconfig | 2 + configs/eb_cpu5282_defconfig| 1 + configs/eb_cpu5282_internal_defconfig | 1 + configs/gwventana_emmc_defconfig| 1 + configs/gwventana_gw5904_defconfig | 1 + configs/gwventana_nand_defconfig| 1 + configs/imx6dl_icore_nand_defconfig | 2 + configs/imx6q_icore_nand_defconfig | 2 + configs/imx6qdl_icore_mmc_defconfig | 2 + configs/imx6qdl_icore_nand_defconfig| 2 + configs/imxrt1050-evk_defconfig | 2 + configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + configs/libretech-ac_defconfig | 2 + configs/libretech-cc_defconfig | 2 + configs/libretech-s905d-pc_defconfig| 2 + configs/libretech-s912-pc_defconfig | 2 + configs/m53menlo_defconfig | 4 + configs/marsboard_defconfig | 2 + configs/mx23evk_defconfig | 1 + configs/mx28evk_auart_console_defconfig | 1 + configs/mx28evk_defconfig | 1 + configs/mx28evk_nand_defconfig | 1 + configs/mx28evk_spi_defconfig | 1 + configs/mx51evk_defconfig | 1 + configs/mx53loco_defconfig | 1 + configs/mx6cuboxi_defconfig | 2 + configs/mx6qsabrelite_defconfig | 2 + configs/mx6sabreauto_defconfig | 2 + configs/mx6sabresd_defconfig| 2 + configs/mx6sxsabresd_defconfig | 2 + configs/mx6ul_14x14_evk_defconfig | 2 + configs/mx6ul_9x9_evk_defconfig | 2 + configs/mx7dsabresd_defconfig | 2 + configs/mx7dsabresd_qspi_defconfig | 2 + configs/nitrogen6dl2g_defconfig | 2 + configs/nitrogen6dl_defconfig | 2 + configs/nitrogen6q2g_defconfig | 2 + configs/nitrogen6q_defconfig| 2 + configs/nitrogen6s1g_defconfig | 2 + configs/nitrogen6s_defconfig| 2 + configs/nokia_rx51_defconfig| 1 + configs/novena_defconfig| 1 + configs/odroid-c2_defconfig | 2 + configs/odroid-c4_defconfig | 2 + configs/opos6uldev_defconfig| 3 + configs/pico-dwarf-imx6ul_defconfig | 2 + configs/pico-dwarf-imx7d_defconfig | 2 + configs/pico-hobbit-imx6ul_defconfig| 2 + configs/pico-hobbit-imx7d_defconfig | 2 + configs/pico-imx6_defconfig | 2 + configs/pico-imx6ul_defconfig | 2 + configs/pico-imx7d_bl33_defconfig | 2 + configs/pico-imx7d_defconfig| 2 + configs/pico-nymph-imx7d_defconfig | 2 + configs/pico-pi-imx6ul_defconfig| 2 + configs/pico-pi-imx7d_defconfig | 2 + configs/pxm2_defconfig | 2 + configs/riotboard_defconfig | 2 + configs/riotboard_spl_defconfig | 2 + configs/rut_defconfig | 2 + configs/s5p4418_nanopi2_defconfig | 3 + configs/sandbox64_defconfig | 1 + configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig | 1 + configs/sandbox_spl_defconfig | 1 + configs/sei510_defconfig| 2 + configs/sei610_defconfig| 2 + configs/stm32f746-disco_defconfig | 2 + configs/stm32f769-disco_defconfig | 2 + configs/tools-only_defconfig| 1 + configs/wandboard_defconfig | 2 + doc/README.silent | 2 +-
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
On Tuesday 11 August 2020 10:22:44 Simon Glass wrote:
> Hi Daniel,
>
> On Tue, 11 Aug 2020 at 10:10, Daniel Schwierzeck
> wrote:
> >
> > Am Dienstag, den 11.08.2020, 10:58 -0400 schrieb Tom Rini:
> > > On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
> > > > On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
> > > > > On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On 11.08.20 10:00, Pali Rohár wrote:
> > > > > > > Hello!
> > > > > > >
> > > > > > > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > > > > > > Hi Tom,
> > > > > > > > Hi Pali,
> > > > > > > >
> > > > > > > > (added Pali because of the Nokia RX51 issue)
> > > > > > >
> > > > > > > Could you please send me a link to "problematic" patch? As you
> > > > > > > have not
> > > > > > > inlined it in this email.
> > > > > >
> > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
> > > > > >
> > > > > > Its a rebase of the original patch.
> > > > > >
> > > > > > > > On 07.08.20 21:21, Tom Rini wrote:
> > > > > > > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > > > > > > >
> > > > > > > > > > Since commit 86cf1c82850f ("configs: Migrate
> > > > > > > > > > CONFIG_NR_DRAM_BANKS") &
> > > > > > > > > > commit 999a772d9f24 ("Kconfig: Migrate
> > > > > > > > > > CONFIG_NR_DRAM_BANKS"),
> > > > > > > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is
> > > > > > > > > > default).
> > > > > > > > > > It makes no sense to still carry code that is guarded with
> > > > > > > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch
> > > > > > > > > > removes
> > > > > > > > > > all these unreferenced code paths.
> > > > > > > > > >
> > > > > > > > > > Also complete remove bi_memstart & bi_memsize from the
> > > > > > > > > > board-info
> > > > > > > > > > struct. As now bi_dram[] is always enabled and should be
> > > > > > > > > > used instead.
> > > > > > > > > > This removes the redundant varriables.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Stefan Roese
> > > > > > > > > > Cc: Daniel Schwierzeck
> > > > > > > > > > Cc: Tom Rini
> > > > > > > > > > Cc: Ramon Fried
> > > > > > > > > > Cc: Simon Glass
> > > > > > > > > > Cc: Michal Simek
> > > > > > > > > > Reviewed-by: Daniel Schwierzeck
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't see quite how, but this is breaking running
> > > > > > > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to
> > > > > > > > > current master
> > > > > > > > > was wrong, and is what's breaking the test). Please rebase
> > > > > > > > > and confirm
> > > > > > > > > that test passes as well, thanks!
> > > > > > > >
> > > > > > > > I've checked the issue with nokia_rx51_test.sh and could not
> > > > > > > > find any
> > > > > > > > issues in the patch. My assumption now is, that the very old
> > > > > > > > Linux
> > > > > > > > kernel (2.6.28) that is used in this Nokia test, still uses the
> > > > > > > > bd_info
> > > > > > > > struct in Linux to pass the memory information (via bd_memstart
> > > > > > > > &
> > > > > > > > bi_memsize), as was also done in the very old PowerPC days.
> > > > > > > > With this
> > > > > > > > patch now and the removal of these fields from bd_info, this
> > > > > > > > might
> > > > > > > > explain why this kernel does not boot any more (no output on
> > > > > > > > the serial
> > > > > > > > console at all).
> > > > > > > >
> > > > > > > > Pali, could you please check if my assumption is correct here?
> > > > > > > > And if
> > > > > > > > yes, could please switch the test to using a newer kernel
> > > > > > > > version? Or
> > > > > > > > remove the Linux kernel booting from the test?
> > > > > > >
> > > > > > > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New
> > > > > > > kernel
> > > > > > > version does not contain Maemo patches which are required for
> > > > > > > Maemo
> > > > > > > system which is still widely used. And yes, people are using it
> > > > > > > with
> > > > > > > U-Boot.
> > > > > > >
> > > > > > > Second reason why we cannot remove support for ATAGs is that
> > > > > > > Nokia's
> > > > > > > signed first stage bootloader pass other setup data via ATAGs for
> > > > > > > kernel
> > > > > > > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> > > > > > >
> > > > > > > And replacing first stage bootloader is not possible because it is
> > > > > > > signed and signing keys are secret (now probably lost).
> > > > > >
> > > > > > Okay. But this patch is not removing ATAG support, but removes 2
> > > > > > member from the bd_info struct (bi_memstart & bi_memsize), which are
> > > > > > replaced (superseeded) by the bi_dram[].start/.size values. And
> > > > > > AFAICT,
> > > > > > the generation of the memory ATAG is already done based on these
> > > > > > values:
> > > > > >
> > > > > >
Re: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off"
On Tuesday 11 August 2020 21:33:19 Faiz Abbas wrote: > Pali, > > On 11/08/20 1:19 pm, Pali Rohár wrote: > > On Tuesday 11 August 2020 08:39:24 Faiz Abbas wrote: > >> Pali, Peng, > >> > >> On 10/08/20 6:25 am, Peng Fan wrote: > >>> Faiz, Jean > >>> > Subject: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched > on and off" > >>> > >>> Got time to take a look? > >>> > >> > >> When this issue was reported in the last thread, Pali said that he was > >> unable to get > >> prints because of the constant reboot loops? Shouldn't it be easy to put > >> while(1) > >> at different points in this execution and see which step causes the reboot > >> loop? > > > > In May in that last thread I wrote details which I was able to gather: > > > > Month ago I was able to detect that problem is somewhere in function > > mmc_set_ios() from mmc.c file. I put long debug line prior and also > > after mmc_set_ios() call. And it was printed only prior. Not after. > > So I think NULL pointer dereference is in mmc_set_ios() function. > > > > I could try with that while(1) loop to print detailed log message and > > read/capture it. But what information for debugging you need? Or what do > > you want to print which could help you? > > > > You can continue to bisect into omap_hsmmc_set_ios() to see at what point the > NULL pointer > gets triggered and what the NULL pointer is. I could try it, but I do not think I would be able to gather more data. I will try to find free time for this debugging on device either at the end of this week or end of next week. As I wrote in previous thread, main issue which makes it hard to debug is that this error is not triggered in emulator. > Also can you point to your config file? I'm using standard config file without any modifications. It is: configs/nokia_rx51_defconfig In case you are interested, I'm compiling u-boot by commands: export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make nokia_rx51_config make -j12 u-boot.bin
[PATCH 1/1] cmd/efidebug: missing initialization of load_options
Variable load_options must be initialized to NULL to avoid a segmentation
fault when freeing the memory this variable points to.
Signed-off-by: Heinrich Schuchardt
---
cmd/efidebug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index d00d4247dc..9874838b00 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -1126,7 +1126,7 @@ static int do_efi_test_bootmgr(struct cmd_tbl *cmdtp, int
flag,
efi_uintn_t exit_data_size = 0;
u16 *exit_data = NULL;
efi_status_t ret;
- void *load_options;
+ void *load_options = NULL;
ret = efi_bootmgr_load(, _options);
printf("efi_bootmgr_load() returned: %ld\n", ret & ~EFI_ERROR_MASK);
--
2.28.0
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hi Daniel,
On Tue, 11 Aug 2020 at 10:10, Daniel Schwierzeck
wrote:
>
> Am Dienstag, den 11.08.2020, 10:58 -0400 schrieb Tom Rini:
> > On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
> > > On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
> > > > On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On 11.08.20 10:00, Pali Rohár wrote:
> > > > > > Hello!
> > > > > >
> > > > > > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > > > > > Hi Tom,
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > (added Pali because of the Nokia RX51 issue)
> > > > > >
> > > > > > Could you please send me a link to "problematic" patch? As you have
> > > > > > not
> > > > > > inlined it in this email.
> > > > >
> > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
> > > > >
> > > > > Its a rebase of the original patch.
> > > > >
> > > > > > > On 07.08.20 21:21, Tom Rini wrote:
> > > > > > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > > > > > >
> > > > > > > > > Since commit 86cf1c82850f ("configs: Migrate
> > > > > > > > > CONFIG_NR_DRAM_BANKS") &
> > > > > > > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > > > > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is
> > > > > > > > > default).
> > > > > > > > > It makes no sense to still carry code that is guarded with
> > > > > > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch
> > > > > > > > > removes
> > > > > > > > > all these unreferenced code paths.
> > > > > > > > >
> > > > > > > > > Also complete remove bi_memstart & bi_memsize from the
> > > > > > > > > board-info
> > > > > > > > > struct. As now bi_dram[] is always enabled and should be used
> > > > > > > > > instead.
> > > > > > > > > This removes the redundant varriables.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Stefan Roese
> > > > > > > > > Cc: Daniel Schwierzeck
> > > > > > > > > Cc: Tom Rini
> > > > > > > > > Cc: Ramon Fried
> > > > > > > > > Cc: Simon Glass
> > > > > > > > > Cc: Michal Simek
> > > > > > > > > Reviewed-by: Daniel Schwierzeck
> > > > > > > >
> > > > > > > > I don't see quite how, but this is breaking running
> > > > > > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to
> > > > > > > > current master
> > > > > > > > was wrong, and is what's breaking the test). Please rebase and
> > > > > > > > confirm
> > > > > > > > that test passes as well, thanks!
> > > > > > >
> > > > > > > I've checked the issue with nokia_rx51_test.sh and could not find
> > > > > > > any
> > > > > > > issues in the patch. My assumption now is, that the very old Linux
> > > > > > > kernel (2.6.28) that is used in this Nokia test, still uses the
> > > > > > > bd_info
> > > > > > > struct in Linux to pass the memory information (via bd_memstart &
> > > > > > > bi_memsize), as was also done in the very old PowerPC days. With
> > > > > > > this
> > > > > > > patch now and the removal of these fields from bd_info, this might
> > > > > > > explain why this kernel does not boot any more (no output on the
> > > > > > > serial
> > > > > > > console at all).
> > > > > > >
> > > > > > > Pali, could you please check if my assumption is correct here?
> > > > > > > And if
> > > > > > > yes, could please switch the test to using a newer kernel
> > > > > > > version? Or
> > > > > > > remove the Linux kernel booting from the test?
> > > > > >
> > > > > > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New
> > > > > > kernel
> > > > > > version does not contain Maemo patches which are required for Maemo
> > > > > > system which is still widely used. And yes, people are using it with
> > > > > > U-Boot.
> > > > > >
> > > > > > Second reason why we cannot remove support for ATAGs is that Nokia's
> > > > > > signed first stage bootloader pass other setup data via ATAGs for
> > > > > > kernel
> > > > > > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> > > > > >
> > > > > > And replacing first stage bootloader is not possible because it is
> > > > > > signed and signing keys are secret (now probably lost).
> > > > >
> > > > > Okay. But this patch is not removing ATAG support, but removes 2
> > > > > member from the bd_info struct (bi_memstart & bi_memsize), which are
> > > > > replaced (superseeded) by the bi_dram[].start/.size values. And
> > > > > AFAICT,
> > > > > the generation of the memory ATAG is already done based on these
> > > > > values:
> > > > >
> > > > > setup_memory_tags() in arch/arm/lib/bootm.c
> > > > >
> > > > > So I still fail to understand, why booting of this old kernel using
> > > > > ATAGs does not work with this patch applied. Perhaps you could give
> > > > > it a quick test? That would be really helpful. Here again the gitlab
> > > > > branch that you can use for some tests:
> > > > >
> > > > >
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
On Tuesday 11 August 2020 10:58:47 Tom Rini wrote:
> On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
> > On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
> > > On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> > > > Hi Pali,
> > > >
> > > > On 11.08.20 10:00, Pali Rohár wrote:
> > > > > Hello!
> > > > >
> > > > > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > > > > Hi Tom,
> > > > > > Hi Pali,
> > > > > >
> > > > > > (added Pali because of the Nokia RX51 issue)
> > > > >
> > > > > Could you please send me a link to "problematic" patch? As you have
> > > > > not
> > > > > inlined it in this email.
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
> > > >
> > > > Its a rebase of the original patch.
> > > >
> > > > > > On 07.08.20 21:21, Tom Rini wrote:
> > > > > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > > > > >
> > > > > > > > Since commit 86cf1c82850f ("configs: Migrate
> > > > > > > > CONFIG_NR_DRAM_BANKS") &
> > > > > > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > > > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is
> > > > > > > > default).
> > > > > > > > It makes no sense to still carry code that is guarded with
> > > > > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
> > > > > > > > all these unreferenced code paths.
> > > > > > > >
> > > > > > > > Also complete remove bi_memstart & bi_memsize from the
> > > > > > > > board-info
> > > > > > > > struct. As now bi_dram[] is always enabled and should be used
> > > > > > > > instead.
> > > > > > > > This removes the redundant varriables.
> > > > > > > >
> > > > > > > > Signed-off-by: Stefan Roese
> > > > > > > > Cc: Daniel Schwierzeck
> > > > > > > > Cc: Tom Rini
> > > > > > > > Cc: Ramon Fried
> > > > > > > > Cc: Simon Glass
> > > > > > > > Cc: Michal Simek
> > > > > > > > Reviewed-by: Daniel Schwierzeck
> > > > > > >
> > > > > > > I don't see quite how, but this is breaking running
> > > > > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to current
> > > > > > > master
> > > > > > > was wrong, and is what's breaking the test). Please rebase and
> > > > > > > confirm
> > > > > > > that test passes as well, thanks!
> > > > > >
> > > > > > I've checked the issue with nokia_rx51_test.sh and could not find
> > > > > > any
> > > > > > issues in the patch. My assumption now is, that the very old Linux
> > > > > > kernel (2.6.28) that is used in this Nokia test, still uses the
> > > > > > bd_info
> > > > > > struct in Linux to pass the memory information (via bd_memstart &
> > > > > > bi_memsize), as was also done in the very old PowerPC days. With
> > > > > > this
> > > > > > patch now and the removal of these fields from bd_info, this might
> > > > > > explain why this kernel does not boot any more (no output on the
> > > > > > serial
> > > > > > console at all).
> > > > > >
> > > > > > Pali, could you please check if my assumption is correct here? And
> > > > > > if
> > > > > > yes, could please switch the test to using a newer kernel version?
> > > > > > Or
> > > > > > remove the Linux kernel booting from the test?
> > > > >
> > > > > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
> > > > > version does not contain Maemo patches which are required for Maemo
> > > > > system which is still widely used. And yes, people are using it with
> > > > > U-Boot.
> > > > >
> > > > > Second reason why we cannot remove support for ATAGs is that Nokia's
> > > > > signed first stage bootloader pass other setup data via ATAGs for
> > > > > kernel
> > > > > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> > > > >
> > > > > And replacing first stage bootloader is not possible because it is
> > > > > signed and signing keys are secret (now probably lost).
> > > >
> > > > Okay. But this patch is not removing ATAG support, but removes 2
> > > > member from the bd_info struct (bi_memstart & bi_memsize), which are
> > > > replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
> > > > the generation of the memory ATAG is already done based on these
> > > > values:
> > > >
> > > > setup_memory_tags() in arch/arm/lib/bootm.c
> > > >
> > > > So I still fail to understand, why booting of this old kernel using
> > > > ATAGs does not work with this patch applied. Perhaps you could give
> > > > it a quick test? That would be really helpful. Here again the gitlab
> > > > branch that you can use for some tests:
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
> >
> > I can do some tests on real N900 device at the end of week. But I doubt
> > that I could debug something on device if kernel does not print any
> > message.
> >
> > Running u-boot and kernel in N900 emulator with debug serial
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Am Dienstag, den 11.08.2020, 10:58 -0400 schrieb Tom Rini:
> On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
> > On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
> > > On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> > > > Hi Pali,
> > > >
> > > > On 11.08.20 10:00, Pali Rohár wrote:
> > > > > Hello!
> > > > >
> > > > > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > > > > Hi Tom,
> > > > > > Hi Pali,
> > > > > >
> > > > > > (added Pali because of the Nokia RX51 issue)
> > > > >
> > > > > Could you please send me a link to "problematic" patch? As you have
> > > > > not
> > > > > inlined it in this email.
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
> > > >
> > > > Its a rebase of the original patch.
> > > >
> > > > > > On 07.08.20 21:21, Tom Rini wrote:
> > > > > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > > > > >
> > > > > > > > Since commit 86cf1c82850f ("configs: Migrate
> > > > > > > > CONFIG_NR_DRAM_BANKS") &
> > > > > > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > > > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is
> > > > > > > > default).
> > > > > > > > It makes no sense to still carry code that is guarded with
> > > > > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
> > > > > > > > all these unreferenced code paths.
> > > > > > > >
> > > > > > > > Also complete remove bi_memstart & bi_memsize from the
> > > > > > > > board-info
> > > > > > > > struct. As now bi_dram[] is always enabled and should be used
> > > > > > > > instead.
> > > > > > > > This removes the redundant varriables.
> > > > > > > >
> > > > > > > > Signed-off-by: Stefan Roese
> > > > > > > > Cc: Daniel Schwierzeck
> > > > > > > > Cc: Tom Rini
> > > > > > > > Cc: Ramon Fried
> > > > > > > > Cc: Simon Glass
> > > > > > > > Cc: Michal Simek
> > > > > > > > Reviewed-by: Daniel Schwierzeck
> > > > > > >
> > > > > > > I don't see quite how, but this is breaking running
> > > > > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to current
> > > > > > > master
> > > > > > > was wrong, and is what's breaking the test). Please rebase and
> > > > > > > confirm
> > > > > > > that test passes as well, thanks!
> > > > > >
> > > > > > I've checked the issue with nokia_rx51_test.sh and could not find
> > > > > > any
> > > > > > issues in the patch. My assumption now is, that the very old Linux
> > > > > > kernel (2.6.28) that is used in this Nokia test, still uses the
> > > > > > bd_info
> > > > > > struct in Linux to pass the memory information (via bd_memstart &
> > > > > > bi_memsize), as was also done in the very old PowerPC days. With
> > > > > > this
> > > > > > patch now and the removal of these fields from bd_info, this might
> > > > > > explain why this kernel does not boot any more (no output on the
> > > > > > serial
> > > > > > console at all).
> > > > > >
> > > > > > Pali, could you please check if my assumption is correct here? And
> > > > > > if
> > > > > > yes, could please switch the test to using a newer kernel version?
> > > > > > Or
> > > > > > remove the Linux kernel booting from the test?
> > > > >
> > > > > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
> > > > > version does not contain Maemo patches which are required for Maemo
> > > > > system which is still widely used. And yes, people are using it with
> > > > > U-Boot.
> > > > >
> > > > > Second reason why we cannot remove support for ATAGs is that Nokia's
> > > > > signed first stage bootloader pass other setup data via ATAGs for
> > > > > kernel
> > > > > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> > > > >
> > > > > And replacing first stage bootloader is not possible because it is
> > > > > signed and signing keys are secret (now probably lost).
> > > >
> > > > Okay. But this patch is not removing ATAG support, but removes 2
> > > > member from the bd_info struct (bi_memstart & bi_memsize), which are
> > > > replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
> > > > the generation of the memory ATAG is already done based on these
> > > > values:
> > > >
> > > > setup_memory_tags() in arch/arm/lib/bootm.c
> > > >
> > > > So I still fail to understand, why booting of this old kernel using
> > > > ATAGs does not work with this patch applied. Perhaps you could give
> > > > it a quick test? That would be really helpful. Here again the gitlab
> > > > branch that you can use for some tests:
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
> >
> > I can do some tests on real N900 device at the end of week. But I doubt
> > that I could debug something on device if kernel does not print any
> > message.
> >
> > Running u-boot and kernel in N900 emulator with debug
Aw: Re: [PATCH] Makefile: fix annoying sunxi hack message
Hi > Gesendet: Dienstag, 11. August 2020 um 17:32 Uhr > Von: "Tom Rini" > Um, what environment is this failing on? Thanks! i get this when compiling for bananapi-r2 (mt7623, armhf). i guessed it is designed as comment, or should these printed for the sunxi? build does not fail, but the "message" is printed and imho this was not intended ;) regards Frank
Re: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off"
Pali, On 11/08/20 1:19 pm, Pali Rohár wrote: > On Tuesday 11 August 2020 08:39:24 Faiz Abbas wrote: >> Pali, Peng, >> >> On 10/08/20 6:25 am, Peng Fan wrote: >>> Faiz, Jean >>> Subject: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off" >>> >>> Got time to take a look? >>> >> >> When this issue was reported in the last thread, Pali said that he was >> unable to get >> prints because of the constant reboot loops? Shouldn't it be easy to put >> while(1) >> at different points in this execution and see which step causes the reboot >> loop? > > In May in that last thread I wrote details which I was able to gather: > > Month ago I was able to detect that problem is somewhere in function > mmc_set_ios() from mmc.c file. I put long debug line prior and also > after mmc_set_ios() call. And it was printed only prior. Not after. > So I think NULL pointer dereference is in mmc_set_ios() function. > > I could try with that while(1) loop to print detailed log message and > read/capture it. But what information for debugging you need? Or what do > you want to print which could help you? > You can continue to bisect into omap_hsmmc_set_ios() to see at what point the NULL pointer gets triggered and what the NULL pointer is. Also can you point to your config file? Thanks, Faiz
Re: [GIT PULL] TI changes for v2020.10-rc3
On Tue, Aug 11, 2020 at 08:42:40PM +0530, Lokesh Vutla wrote:
> Hi Tom, Jan
>
> On 11/08/20 8:32 pm, Jan Kiszka wrote:
> > On 11.08.20 16:56, Tom Rini wrote:
> >> On Tue, Aug 11, 2020 at 04:02:37PM +0530, Lokesh Vutla wrote:
> >>
> >>> Hi Tom,
> >>> Please find the pull request for v2020.10-rc3 containing TI specific
> >>> changes. This should have been sent for rc2 but delayed due to some
> >>> comments in the last minute. Please look at the PR description for the
> >>> details on the PR.
> >>>
> >>> Travis-CI build:
> >>> https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052
> >>>
> >>> The following changes since commit
> >>> c045207f96f7f7ae8c7f134a6010e636176b:
> >>>
> >>> Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400)
> >>>
> >>> are available in the Git repository at:
> >>>
> >>> https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git
> >>> tags/ti-v2020.10-rc3
> >>>
> >>> for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df:
> >>>
> >>> arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11
> >>> 10:22:11 +0530)
> >>>
> >>>
> >>> Below are the major changes in this PR:
> >>> - Added support for J7200 evm
> >>> - DM_ETH and DM_USB migrations for omap3
> >>> - USB DFU and mass storage support for AM65x evm
> >>> - RTI watchdog support for K3 devices
> >>> - Fix an issue with L3 cache on K3 devices
> >>>
> >>> Andrew F. Davis (1):
> >>> arm: mach-k3: Clean non-coherent lines out of L3 cache
> >>>
> >>> Dave Gerlach (1):
> >>> arm: dts: k3-j7200: Add R5 specific dts support
> >>>
> >>> Derald D. Woods (1):
> >>> ARM: omap3: evm: Complete DM_ETH and DM_USB migrations
> >>>
> >>> Faiz Abbas (14):
> >>> mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded
> >>> value
> >>> spl: usb: Create an API spl_usb_load()
> >>> spl: usb: Only init usb once
> >>> armv7R: K3: am654: Use full malloc in SPL both pre and post reloc
> >>> arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB
> >>> arm: mach-k3: am6_init: Gate mmc related configurations with the
> >>> appropriate config
> >>> arm: mach-k3: am6_init: Do USB fixups to facilitate host and device
> >>> boot modes
> >>> arm: mach-k3: am6_init: Add support for USB boot mode
> >>> arm: dts: k3-am654-r5-base-board: Add USB0 nodes
> >>> arm: dts: k3-am654-base-board: Add support for USB0 in SPL
> >>> configs: am65x_evm: Add support for DFU related configs
> >>> configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes
> >>> configs: Add defconfig for USB DFU bootmode
> >>> configs: Add new config for supporting USB mass storage boot
> >>>
> >>> Jan Kiszka (3):
> >>> watchdog: Add support for K3 RTI watchdog
> >>> arm: dts: k3: Add RTI watchdogs
> >>> am654_sdhci: mmc fail to send stop cmd
> >>
> >> OK, so the last change from Jan here is:
> >>
> >> commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
> >> Author: Jan Kiszka
> >> Date: Sat Jul 18 16:47:04 2020 +0200
> >>
> >> am654_sdhci: mmc fail to send stop cmd
> >>
> >> Hi all,
> >>
> >> on one device with one specific SD-card (possibly an aging one), I'm
> >> seeing frequent "mmc fail to send stop cmd" messages, followed by read
> >> errors when loading kernel and dtb. -ETIMEDOUT is returned by
> >> mmd_send_cmd. However, I can always resolve this by simply retrying
> >> the
> >> stop command like this:
> >>
> >> Hardware is our IOT2050, baseline is today's master (1c4b5038afcc)
> >> with
> >> board-enabling and a bunch of patches from your tree [1]. However,
> >> already 4d6da10ce611 exposes the problem.
> >>
> >> What could cause this?
> >>
> >> Jan
> >>
> >> [1] https://github.com/siemens/u-boot/commits/jan/iot2050
> >>
> >> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> >> index d79cdef62ed2..2aca8d3a4d32 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -407,7 +407,11 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
> >> lbaint_t start,
> >> #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> >> pr_err("mmc fail to send stop cmd\n");
> >> #endif
> >> - return 0;
> >> + pr_err("retrying...\n");
> >> + if (mmc_send_cmd(mmc, , NULL)) {
> >> + pr_err("failed again\n");
> >> + return 0;
> >> + }
> >> }
> >> }
> >>
> >> Which is a generic MMC change, grows everyone by a little bit and lacks
> >> both an S-o-B from the author and Reviewed-by of the MMC maintainer.
> >> Please drop this patch. Thanks!
> >>
> >
> > That was an instrumentation hunk for the issue described above. Never
> > intended to be a patch.
>
> Sorry my
Re: [PATCH] Makefile: fix annoying sunxi hack message
On Tue, Aug 11, 2020 at 05:19:54PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich
>
> every compilation shows this error
>
> Hack for sunxi which doesn't have a proper binman definition for
> 64-bit boards
>
> not only for sunxi-boards/arm64
>
> fix this by changing to real comments
>
> Fixes: 9f55ee259d0c ("Makefile: sunxi: Don't use binman to build ATF image")
> Signed-off-by: Frank Wunderlich
> ---
> Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4483a9bc8a..75c2987405 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1024,8 +1024,8 @@ PHONY += inputs
> inputs: $(INPUTS-y)
>
> all: .binman_stamp inputs
> - # Hack for sunxi which doesn't have a proper binman definition for
> - # 64-bit boards
> +# Hack for sunxi which doesn't have a proper binman definition for
> +# 64-bit boards
> ifneq ($(CONFIG_ARCH_SUNXI)$(CONFIG_ARM64),yy)
> ifeq ($(CONFIG_BINMAN),y)
> $(call if_changed,binman)
Um, what environment is this failing on? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [U-Boot] requesting a custodian tree for Aspeed SoCs maintenance
On Mon, Aug 10, 2020 at 03:19:43AM +, ChiaWei Wang wrote: o > Hi, > > We are Aspeed SW team and would like to request the creation of a > u-boot-aspeed.git > custodian tree for the u-boot support related to Aspeed SoCs. Attached is the > SSH key > generated for this purpose. > > By the way, the Aspeed SoCs are based on ARM architecture. However, we are > not sure > if the Aspeed custodian tree should be a downstream of u-boot-arm.git tree or > not. As > there is no update to u-boot-arm since 4 years ago. > > If anything is further needed, please let us know. To start with, I would like to handle Aspeed development by pulling respective patches in to one of my testing branches and merge them after appropriate review time. If the volume of changes makes it worthwhile we can add a new custodian tree later. Thanks! -- Tom signature.asc Description: PGP signature
[PATCH] Makefile: fix annoying sunxi hack message
From: Frank Wunderlich
every compilation shows this error
Hack for sunxi which doesn't have a proper binman definition for
64-bit boards
not only for sunxi-boards/arm64
fix this by changing to real comments
Fixes: 9f55ee259d0c ("Makefile: sunxi: Don't use binman to build ATF image")
Signed-off-by: Frank Wunderlich
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 4483a9bc8a..75c2987405 100644
--- a/Makefile
+++ b/Makefile
@@ -1024,8 +1024,8 @@ PHONY += inputs
inputs: $(INPUTS-y)
all: .binman_stamp inputs
- # Hack for sunxi which doesn't have a proper binman definition for
- # 64-bit boards
+# Hack for sunxi which doesn't have a proper binman definition for
+# 64-bit boards
ifneq ($(CONFIG_ARCH_SUNXI)$(CONFIG_ARM64),yy)
ifeq ($(CONFIG_BINMAN),y)
$(call if_changed,binman)
--
2.25.1
Re: [PATCH 0/2] fs/squashfs: Add new decompression algorithms
On Tue, Aug 11, 2020 at 03:17:53PM +0200, Joao Marcos Costa wrote: > Hello, > > Following the SquashFS support, this series adds support for LZO and ZSTD > algorithms. The only compression type enabled by default is ZLIB, so LZO > and ZSTD need to be manually selected. > > Joao Marcos Costa (2): > fs/squashfs: add support for LZO decompression > fs/squashfs: add support for ZSTD decompression > > fs/squashfs/sqfs_decompressor.c | 60 +++-- > 1 file changed, 58 insertions(+), 2 deletions(-) Can we add tests for this to sandbox? Thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] TI changes for v2020.10-rc3
Hi Tom, Jan
On 11/08/20 8:32 pm, Jan Kiszka wrote:
> On 11.08.20 16:56, Tom Rini wrote:
>> On Tue, Aug 11, 2020 at 04:02:37PM +0530, Lokesh Vutla wrote:
>>
>>> Hi Tom,
>>> Please find the pull request for v2020.10-rc3 containing TI specific
>>> changes. This should have been sent for rc2 but delayed due to some
>>> comments in the last minute. Please look at the PR description for the
>>> details on the PR.
>>>
>>> Travis-CI build:
>>> https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052
>>>
>>> The following changes since commit c045207f96f7f7ae8c7f134a6010e636176b:
>>>
>>> Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400)
>>>
>>> are available in the Git repository at:
>>>
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git
>>> tags/ti-v2020.10-rc3
>>>
>>> for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df:
>>>
>>> arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11
>>> 10:22:11 +0530)
>>>
>>>
>>> Below are the major changes in this PR:
>>> - Added support for J7200 evm
>>> - DM_ETH and DM_USB migrations for omap3
>>> - USB DFU and mass storage support for AM65x evm
>>> - RTI watchdog support for K3 devices
>>> - Fix an issue with L3 cache on K3 devices
>>>
>>> Andrew F. Davis (1):
>>> arm: mach-k3: Clean non-coherent lines out of L3 cache
>>>
>>> Dave Gerlach (1):
>>> arm: dts: k3-j7200: Add R5 specific dts support
>>>
>>> Derald D. Woods (1):
>>> ARM: omap3: evm: Complete DM_ETH and DM_USB migrations
>>>
>>> Faiz Abbas (14):
>>> mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
>>> spl: usb: Create an API spl_usb_load()
>>> spl: usb: Only init usb once
>>> armv7R: K3: am654: Use full malloc in SPL both pre and post reloc
>>> arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB
>>> arm: mach-k3: am6_init: Gate mmc related configurations with the
>>> appropriate config
>>> arm: mach-k3: am6_init: Do USB fixups to facilitate host and device
>>> boot modes
>>> arm: mach-k3: am6_init: Add support for USB boot mode
>>> arm: dts: k3-am654-r5-base-board: Add USB0 nodes
>>> arm: dts: k3-am654-base-board: Add support for USB0 in SPL
>>> configs: am65x_evm: Add support for DFU related configs
>>> configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes
>>> configs: Add defconfig for USB DFU bootmode
>>> configs: Add new config for supporting USB mass storage boot
>>>
>>> Jan Kiszka (3):
>>> watchdog: Add support for K3 RTI watchdog
>>> arm: dts: k3: Add RTI watchdogs
>>> am654_sdhci: mmc fail to send stop cmd
>>
>> OK, so the last change from Jan here is:
>>
>> commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
>> Author: Jan Kiszka
>> Date: Sat Jul 18 16:47:04 2020 +0200
>>
>> am654_sdhci: mmc fail to send stop cmd
>>
>> Hi all,
>>
>> on one device with one specific SD-card (possibly an aging one), I'm
>> seeing frequent "mmc fail to send stop cmd" messages, followed by read
>> errors when loading kernel and dtb. -ETIMEDOUT is returned by
>> mmd_send_cmd. However, I can always resolve this by simply retrying the
>> stop command like this:
>>
>> Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
>> board-enabling and a bunch of patches from your tree [1]. However,
>> already 4d6da10ce611 exposes the problem.
>>
>> What could cause this?
>>
>> Jan
>>
>> [1] https://github.com/siemens/u-boot/commits/jan/iot2050
>>
>> diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
>> index d79cdef62ed2..2aca8d3a4d32 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -407,7 +407,11 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
>> lbaint_t start,
>> #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
>> pr_err("mmc fail to send stop cmd\n");
>> #endif
>> - return 0;
>> + pr_err("retrying...\n");
>> + if (mmc_send_cmd(mmc, , NULL)) {
>> + pr_err("failed again\n");
>> + return 0;
>> + }
>> }
>> }
>>
>> Which is a generic MMC change, grows everyone by a little bit and lacks
>> both an S-o-B from the author and Reviewed-by of the MMC maintainer.
>> Please drop this patch. Thanks!
>>
>
> That was an instrumentation hunk for the issue described above. Never
> intended to be a patch.
Sorry my bad. I did remove this patch from my queue, but not sure how it got
here.
Tom,
Updated the tag without this patch. Build is going on, once it
completes will
send a v2.
Thanks and regards,
Lokesh
>
> Jan
Re: [GIT PULL] TI changes for v2020.10-rc3
On Tue, Aug 11, 2020 at 05:02:59PM +0200, Jan Kiszka wrote:
> On 11.08.20 16:56, Tom Rini wrote:
> > On Tue, Aug 11, 2020 at 04:02:37PM +0530, Lokesh Vutla wrote:
> >
> > > Hi Tom,
> > > Please find the pull request for v2020.10-rc3 containing TI specific
> > > changes. This should have been sent for rc2 but delayed due to some
> > > comments in the last minute. Please look at the PR description for the
> > > details on the PR.
> > >
> > > Travis-CI build:
> > > https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052
> > >
> > > The following changes since commit
> > > c045207f96f7f7ae8c7f134a6010e636176b:
> > >
> > >Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400)
> > >
> > > are available in the Git repository at:
> > >
> > >https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git
> > > tags/ti-v2020.10-rc3
> > >
> > > for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df:
> > >
> > >arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11
> > > 10:22:11 +0530)
> > >
> > >
> > > Below are the major changes in this PR:
> > > - Added support for J7200 evm
> > > - DM_ETH and DM_USB migrations for omap3
> > > - USB DFU and mass storage support for AM65x evm
> > > - RTI watchdog support for K3 devices
> > > - Fix an issue with L3 cache on K3 devices
> > >
> > > Andrew F. Davis (1):
> > >arm: mach-k3: Clean non-coherent lines out of L3 cache
> > >
> > > Dave Gerlach (1):
> > >arm: dts: k3-j7200: Add R5 specific dts support
> > >
> > > Derald D. Woods (1):
> > >ARM: omap3: evm: Complete DM_ETH and DM_USB migrations
> > >
> > > Faiz Abbas (14):
> > >mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded
> > > value
> > >spl: usb: Create an API spl_usb_load()
> > >spl: usb: Only init usb once
> > >armv7R: K3: am654: Use full malloc in SPL both pre and post reloc
> > >arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB
> > >arm: mach-k3: am6_init: Gate mmc related configurations with the
> > > appropriate config
> > >arm: mach-k3: am6_init: Do USB fixups to facilitate host and
> > > device boot modes
> > >arm: mach-k3: am6_init: Add support for USB boot mode
> > >arm: dts: k3-am654-r5-base-board: Add USB0 nodes
> > >arm: dts: k3-am654-base-board: Add support for USB0 in SPL
> > >configs: am65x_evm: Add support for DFU related configs
> > >configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes
> > >configs: Add defconfig for USB DFU bootmode
> > >configs: Add new config for supporting USB mass storage boot
> > >
> > > Jan Kiszka (3):
> > >watchdog: Add support for K3 RTI watchdog
> > >arm: dts: k3: Add RTI watchdogs
> > >am654_sdhci: mmc fail to send stop cmd
> >
> > OK, so the last change from Jan here is:
> >
> > commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
> > Author: Jan Kiszka
> > Date: Sat Jul 18 16:47:04 2020 +0200
> >
> > am654_sdhci: mmc fail to send stop cmd
> >
> > Hi all,
> >
> > on one device with one specific SD-card (possibly an aging one), I'm
> > seeing frequent "mmc fail to send stop cmd" messages, followed by read
> > errors when loading kernel and dtb. -ETIMEDOUT is returned by
> > mmd_send_cmd. However, I can always resolve this by simply retrying the
> > stop command like this:
> >
> > Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
> > board-enabling and a bunch of patches from your tree [1]. However,
> > already 4d6da10ce611 exposes the problem.
> >
> > What could cause this?
> >
> > Jan
> >
> > [1] https://github.com/siemens/u-boot/commits/jan/iot2050
> >
> > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
> > index d79cdef62ed2..2aca8d3a4d32 100644
> > --- a/drivers/mmc/mmc.c
> > +++ b/drivers/mmc/mmc.c
> > @@ -407,7 +407,11 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
> > lbaint_t start,
> > #if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
> > pr_err("mmc fail to send stop cmd\n");
> > #endif
> > - return 0;
> > + pr_err("retrying...\n");
> > + if (mmc_send_cmd(mmc, , NULL)) {
> > + pr_err("failed again\n");
> > + return 0;
> > + }
> > }
> > }
> >
> > Which is a generic MMC change, grows everyone by a little bit and lacks
> > both an S-o-B from the author and Reviewed-by of the MMC maintainer.
> > Please drop this patch. Thanks!
> >
>
> That was an instrumentation hunk for the issue described above. Never
> intended to be a patch.
I kind of thought that might be the case from the
Re: [GIT PULL] TI changes for v2020.10-rc3
On 11.08.20 16:56, Tom Rini wrote:
On Tue, Aug 11, 2020 at 04:02:37PM +0530, Lokesh Vutla wrote:
Hi Tom,
Please find the pull request for v2020.10-rc3 containing TI specific
changes. This should have been sent for rc2 but delayed due to some
comments in the last minute. Please look at the PR description for the
details on the PR.
Travis-CI build:
https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052
The following changes since commit c045207f96f7f7ae8c7f134a6010e636176b:
Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.10-rc3
for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df:
arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11
10:22:11 +0530)
Below are the major changes in this PR:
- Added support for J7200 evm
- DM_ETH and DM_USB migrations for omap3
- USB DFU and mass storage support for AM65x evm
- RTI watchdog support for K3 devices
- Fix an issue with L3 cache on K3 devices
Andrew F. Davis (1):
arm: mach-k3: Clean non-coherent lines out of L3 cache
Dave Gerlach (1):
arm: dts: k3-j7200: Add R5 specific dts support
Derald D. Woods (1):
ARM: omap3: evm: Complete DM_ETH and DM_USB migrations
Faiz Abbas (14):
mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
spl: usb: Create an API spl_usb_load()
spl: usb: Only init usb once
armv7R: K3: am654: Use full malloc in SPL both pre and post reloc
arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB
arm: mach-k3: am6_init: Gate mmc related configurations with the
appropriate config
arm: mach-k3: am6_init: Do USB fixups to facilitate host and device boot
modes
arm: mach-k3: am6_init: Add support for USB boot mode
arm: dts: k3-am654-r5-base-board: Add USB0 nodes
arm: dts: k3-am654-base-board: Add support for USB0 in SPL
configs: am65x_evm: Add support for DFU related configs
configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes
configs: Add defconfig for USB DFU bootmode
configs: Add new config for supporting USB mass storage boot
Jan Kiszka (3):
watchdog: Add support for K3 RTI watchdog
arm: dts: k3: Add RTI watchdogs
am654_sdhci: mmc fail to send stop cmd
OK, so the last change from Jan here is:
commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
Author: Jan Kiszka
Date: Sat Jul 18 16:47:04 2020 +0200
am654_sdhci: mmc fail to send stop cmd
Hi all,
on one device with one specific SD-card (possibly an aging one), I'm
seeing frequent "mmc fail to send stop cmd" messages, followed by read
errors when loading kernel and dtb. -ETIMEDOUT is returned by
mmd_send_cmd. However, I can always resolve this by simply retrying the
stop command like this:
Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
board-enabling and a bunch of patches from your tree [1]. However,
already 4d6da10ce611 exposes the problem.
What could cause this?
Jan
[1] https://github.com/siemens/u-boot/commits/jan/iot2050
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d79cdef62ed2..2aca8d3a4d32 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -407,7 +407,11 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");
#endif
- return 0;
+ pr_err("retrying...\n");
+ if (mmc_send_cmd(mmc, , NULL)) {
+ pr_err("failed again\n");
+ return 0;
+ }
}
}
Which is a generic MMC change, grows everyone by a little bit and lacks
both an S-o-B from the author and Reviewed-by of the MMC maintainer.
Please drop this patch. Thanks!
That was an instrumentation hunk for the issue described above. Never
intended to be a patch.
Jan
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
On Tue, Aug 11, 2020 at 03:22:48PM +0200, Pali Rohár wrote:
> On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
> > On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> > > Hi Pali,
> > >
> > > On 11.08.20 10:00, Pali Rohár wrote:
> > > > Hello!
> > > >
> > > > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > > > Hi Tom,
> > > > > Hi Pali,
> > > > >
> > > > > (added Pali because of the Nokia RX51 issue)
> > > >
> > > > Could you please send me a link to "problematic" patch? As you have not
> > > > inlined it in this email.
> > >
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
> > >
> > > Its a rebase of the original patch.
> > >
> > > > > On 07.08.20 21:21, Tom Rini wrote:
> > > > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > > > >
> > > > > > > Since commit 86cf1c82850f ("configs: Migrate
> > > > > > > CONFIG_NR_DRAM_BANKS") &
> > > > > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is
> > > > > > > default).
> > > > > > > It makes no sense to still carry code that is guarded with
> > > > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
> > > > > > > all these unreferenced code paths.
> > > > > > >
> > > > > > > Also complete remove bi_memstart & bi_memsize from the board-info
> > > > > > > struct. As now bi_dram[] is always enabled and should be used
> > > > > > > instead.
> > > > > > > This removes the redundant varriables.
> > > > > > >
> > > > > > > Signed-off-by: Stefan Roese
> > > > > > > Cc: Daniel Schwierzeck
> > > > > > > Cc: Tom Rini
> > > > > > > Cc: Ramon Fried
> > > > > > > Cc: Simon Glass
> > > > > > > Cc: Michal Simek
> > > > > > > Reviewed-by: Daniel Schwierzeck
> > > > > >
> > > > > > I don't see quite how, but this is breaking running
> > > > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to current
> > > > > > master
> > > > > > was wrong, and is what's breaking the test). Please rebase and
> > > > > > confirm
> > > > > > that test passes as well, thanks!
> > > > >
> > > > > I've checked the issue with nokia_rx51_test.sh and could not find any
> > > > > issues in the patch. My assumption now is, that the very old Linux
> > > > > kernel (2.6.28) that is used in this Nokia test, still uses the
> > > > > bd_info
> > > > > struct in Linux to pass the memory information (via bd_memstart &
> > > > > bi_memsize), as was also done in the very old PowerPC days. With this
> > > > > patch now and the removal of these fields from bd_info, this might
> > > > > explain why this kernel does not boot any more (no output on the
> > > > > serial
> > > > > console at all).
> > > > >
> > > > > Pali, could you please check if my assumption is correct here? And if
> > > > > yes, could please switch the test to using a newer kernel version? Or
> > > > > remove the Linux kernel booting from the test?
> > > >
> > > > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
> > > > version does not contain Maemo patches which are required for Maemo
> > > > system which is still widely used. And yes, people are using it with
> > > > U-Boot.
> > > >
> > > > Second reason why we cannot remove support for ATAGs is that Nokia's
> > > > signed first stage bootloader pass other setup data via ATAGs for kernel
> > > > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> > > >
> > > > And replacing first stage bootloader is not possible because it is
> > > > signed and signing keys are secret (now probably lost).
> > >
> > > Okay. But this patch is not removing ATAG support, but removes 2
> > > member from the bd_info struct (bi_memstart & bi_memsize), which are
> > > replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
> > > the generation of the memory ATAG is already done based on these
> > > values:
> > >
> > > setup_memory_tags() in arch/arm/lib/bootm.c
> > >
> > > So I still fail to understand, why booting of this old kernel using
> > > ATAGs does not work with this patch applied. Perhaps you could give
> > > it a quick test? That would be really helpful. Here again the gitlab
> > > branch that you can use for some tests:
> > >
> > > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
>
> I can do some tests on real N900 device at the end of week. But I doubt
> that I could debug something on device if kernel does not print any
> message.
>
> Running u-boot and kernel in N900 emulator with debug serial console is
> easier and you can do it too locally. If you look at that test script
> test/nokia_rx51_test.sh you could see that it downloads & compile qemu
> and prepare OneNAND MTD image with compiled u-boot + kernel binary.
>
> You can also run that test script locally, it does not require root and
> all data it stores into temporary
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
On 11.08.20 16:36, Lokesh Vutla wrote: Hi Jan, On 11/08/20 6:07 pm, Jan Kiszka wrote: On 11.08.20 12:46, Lokesh Vutla wrote: On 11/08/20 4:12 pm, Jan Kiszka wrote: On 11.08.20 12:33, Lokesh Vutla wrote: On 23/06/20 4:45 pm, Jan Kiszka wrote: This brings watchdog support for the TI K3 SoCs, derived from the Linux kernel, augmented with firmware loading as needed on the AM65x. Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream support will be posted soon). Changes in v2: - keep watchdog powered when handing over to Linux - drop unneeded explicit power-on - account for RTI firmware locking the power domain Patch 1 and 3 merged applied. Thanks. Still taking workable suggestions for loading the firmware. FIT image is the one that I can think off. Since SPL is loading the FIT image, SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot can start the remote cores using this info. OK, just the ensure I got the idea correctly: - extend struct spl_handoff or arch_spl_handoff with the fit image loadaddr that spl is processing Yes - stick the watchdog firmware into the u-boot proper fit image (generated by tools/k3_fit_atf.sh or shipped via the board folder, as in our case) IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May Yeah, right. We also have a fit image for u-boot proper, that confused me. be create a new one that packs fit image with u-boot and firmware. Or can you check if binman in u-boot works for you? You mean, pack the u-boot proper with the firmware? Then we could stick the result in an signed fit image when needed. And I could read the offset of the firmware from the generated dtb - provided binman can deal with multiple configurations like we have. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [GIT PULL] TI changes for v2020.10-rc3
On Tue, Aug 11, 2020 at 04:02:37PM +0530, Lokesh Vutla wrote:
> Hi Tom,
> Please find the pull request for v2020.10-rc3 containing TI specific
> changes. This should have been sent for rc2 but delayed due to some
> comments in the last minute. Please look at the PR description for the
> details on the PR.
>
> Travis-CI build:
> https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052
>
> The following changes since commit c045207f96f7f7ae8c7f134a6010e636176b:
>
> Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400)
>
> are available in the Git repository at:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.10-rc3
>
> for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df:
>
> arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11
> 10:22:11 +0530)
>
>
> Below are the major changes in this PR:
> - Added support for J7200 evm
> - DM_ETH and DM_USB migrations for omap3
> - USB DFU and mass storage support for AM65x evm
> - RTI watchdog support for K3 devices
> - Fix an issue with L3 cache on K3 devices
>
> Andrew F. Davis (1):
> arm: mach-k3: Clean non-coherent lines out of L3 cache
>
> Dave Gerlach (1):
> arm: dts: k3-j7200: Add R5 specific dts support
>
> Derald D. Woods (1):
> ARM: omap3: evm: Complete DM_ETH and DM_USB migrations
>
> Faiz Abbas (14):
> mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
> spl: usb: Create an API spl_usb_load()
> spl: usb: Only init usb once
> armv7R: K3: am654: Use full malloc in SPL both pre and post reloc
> arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB
> arm: mach-k3: am6_init: Gate mmc related configurations with the
> appropriate config
> arm: mach-k3: am6_init: Do USB fixups to facilitate host and device
> boot modes
> arm: mach-k3: am6_init: Add support for USB boot mode
> arm: dts: k3-am654-r5-base-board: Add USB0 nodes
> arm: dts: k3-am654-base-board: Add support for USB0 in SPL
> configs: am65x_evm: Add support for DFU related configs
> configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes
> configs: Add defconfig for USB DFU bootmode
> configs: Add new config for supporting USB mass storage boot
>
> Jan Kiszka (3):
> watchdog: Add support for K3 RTI watchdog
> arm: dts: k3: Add RTI watchdogs
> am654_sdhci: mmc fail to send stop cmd
OK, so the last change from Jan here is:
commit 6bc290047b6e0209dd8183ce78be2f9297feb3c6
Author: Jan Kiszka
Date: Sat Jul 18 16:47:04 2020 +0200
am654_sdhci: mmc fail to send stop cmd
Hi all,
on one device with one specific SD-card (possibly an aging one), I'm
seeing frequent "mmc fail to send stop cmd" messages, followed by read
errors when loading kernel and dtb. -ETIMEDOUT is returned by
mmd_send_cmd. However, I can always resolve this by simply retrying the
stop command like this:
Hardware is our IOT2050, baseline is today's master (1c4b5038afcc) with
board-enabling and a bunch of patches from your tree [1]. However,
already 4d6da10ce611 exposes the problem.
What could cause this?
Jan
[1] https://github.com/siemens/u-boot/commits/jan/iot2050
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index d79cdef62ed2..2aca8d3a4d32 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -407,7 +407,11 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");
#endif
- return 0;
+ pr_err("retrying...\n");
+ if (mmc_send_cmd(mmc, , NULL)) {
+ pr_err("failed again\n");
+ return 0;
+ }
}
}
Which is a generic MMC change, grows everyone by a little bit and lacks
both an S-o-B from the author and Reviewed-by of the MMC maintainer.
Please drop this patch. Thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH 2/2] board: armltd: Add support for Total Compute platform
Total Compute is based on ARM architecture and has
the following features enabled in u-boot:
- PL011 UART
- PL180 MMC
- NOR Flash
- FIT image with Signature
- AVB
Signed-off-by: Usama Arif
---
arch/arm/Kconfig | 11 +++
arch/arm/dts/Makefile | 2 +
arch/arm/dts/total_compute.dts | 48
arch/arm/include/asm/gpio.h| 2 +-
board/armltd/total_compute/Kconfig | 12 +++
board/armltd/total_compute/MAINTAINERS | 6 ++
board/armltd/total_compute/Makefile| 6 ++
board/armltd/total_compute/total_compute.c | 67
configs/total_compute_defconfig| 53 +
include/configs/total_compute.h| 91 ++
10 files changed, 297 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/total_compute.dts
create mode 100644 board/armltd/total_compute/Kconfig
create mode 100644 board/armltd/total_compute/MAINTAINERS
create mode 100644 board/armltd/total_compute/Makefile
create mode 100644 board/armltd/total_compute/total_compute.c
create mode 100644 configs/total_compute_defconfig
create mode 100644 include/configs/total_compute.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b8a32c38d..20ae4af9c2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1195,6 +1195,15 @@ config TARGET_VEXPRESS64_JUNO
select USB
select DM_USB
+config TARGET_TOTAL_COMPUTE
+ bool "Support Total Compute Platform"
+ select ARM64
+ select PL01X_SERIAL
+ select DM
+ select DM_SERIAL
+ select DM_MMC
+ select DM_GPIO
+
config TARGET_LS2080A_EMU
bool "Support ls2080a_emu"
select ARCH_LS2080A
@@ -1893,6 +1902,8 @@ source "arch/arm/mach-imx/Kconfig"
source "arch/arm/mach-nexell/Kconfig"
+source "board/armltd/total_compute/Kconfig"
+
source "board/bosch/shc/Kconfig"
source "board/bosch/guardian/Kconfig"
source "board/CarMediaLab/flea3/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8ecf63e988..5fc0840c5a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -978,6 +978,8 @@ dtb-$(CONFIG_TARGET_VEXPRESS_CA5X2) += vexpress-v2p-ca5s.dtb
dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb
dtb-$(CONFIG_TARGET_VEXPRESS_CA15_TC2) += vexpress-v2p-ca15_a7.dtb
+dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
+
dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
diff --git a/arch/arm/dts/total_compute.dts b/arch/arm/dts/total_compute.dts
new file mode 100644
index 00..4399269a44
--- /dev/null
+++ b/arch/arm/dts/total_compute.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020 Arm Limited
+ */
+
+/dts-v1/;
+
+/ {
+ model = "total_compute";
+ compatible = "arm,total_compute";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ sysreg: sysreg@1c01 {
+ compatible = "arm,vexpress-sysreg";
+ reg = <0x0 0x001c01 0x0 0x1000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ fixed_3v3: v2m-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ mmci@1c05 {
+ compatible = "arm,pl180", "arm,primecell";
+ reg = <0x0 0x001c05 0x0 0x1000>;
+ cd-gpios = < 0 0>;
+ arm,primecell-periphid = <0x00880180>;
+ wp-gpios = < 1 0>;
+ bus-width = <8>;
+ max-frequency = <1200>;
+ vmmc-supply = <_3v3>;
+ clocks = <>, <>;
+ clock-names = "mclk", "apb_pclk";
+ };
+
+ clock24mhz: clock24mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ clock-output-names = "bp:clock24mhz";
+ };
+};
diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index 7dc87afb83..6ecb876eda 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -3,7 +3,7 @@
!defined(CONFIG_ARCH_BCM6858) && !defined(CONFIG_ARCH_BCM63158) && \
!defined(CONFIG_ARCH_ROCKCHIP) && !defined(CONFIG_ARCH_ASPEED) && \
!defined(CONFIG_ARCH_U8500) && !defined(CONFIG_CORTINA_PLATFORM) && \
- !defined(CONFIG_TARGET_BCMNS3)
+ !defined(CONFIG_TARGET_BCMNS3) && !defined(CONFIG_TARGET_TOTAL_COMPUTE)
#include
#endif
#include
diff --git a/board/armltd/total_compute/Kconfig
b/board/armltd/total_compute/Kconfig
new file mode 100644
index 00..62e6e6f4ac
--- /dev/null
+++ b/board/armltd/total_compute/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_TOTAL_COMPUTE
+
+config SYS_BOARD
+
[PATCH 1/2] avb: Make AVB independent of fastboot
AVB only uses CONFIG_FASTBOOT_BUF_ADDR from fastboot for memory.
This memory is used for assigning temporary buffers.
This can be assigned a new variable and used as CONFIG_AVB_BUF_ADDR.
This is to support future boards that support AVB but dont support
USB and therefore dont support FASTBOOT.
Signed-off-by: Usama Arif
Cc: Igor Opaniuk
---
common/Kconfig | 18 +-
common/avb_verify.c | 1 -
configs/am57xx_evm_defconfig| 2 ++
configs/am57xx_hs_evm_defconfig | 2 ++
configs/am57xx_hs_evm_usb_defconfig | 2 ++
include/avb_verify.h| 4 ++--
6 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index 62d78c5bd7..bbacc33f80 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -986,7 +986,7 @@ config HASH
config AVB_VERIFY
bool "Build Android Verified Boot operations"
- depends on LIBAVB && FASTBOOT
+ depends on LIBAVB
depends on PARTITION_UUIDS
help
This option enables compilation of bootloader-dependent operations,
@@ -995,6 +995,22 @@ config AVB_VERIFY
* Helpers to access MMC, similar to drivers/fastboot/fb_mmc.c.
* Helpers to alloc/init/free avb ops.
+if AVB_VERIFY
+
+config AVB_BUF_ADDR
+ hex "Define AVB buffer address"
+ help
+ AVB requires a buffer for memory transactions. This variable defines
the
+ buffer address.
+
+config AVB_BUF_SIZE
+ hex "Define AVB buffer SIZE"
+ help
+ AVB requires a buffer for memory transactions. This variable defines
the
+ buffer size.
+
+endif # AVB_VERIFY
+
config SPL_HASH
bool # "Support hashing API (SHA1, SHA256, etc.)"
help
diff --git a/common/avb_verify.c b/common/avb_verify.c
index a2b739626b..db10d0f21f 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -7,7 +7,6 @@
#include
#include
#include
-#include
#include
#include
#include
diff --git a/configs/am57xx_evm_defconfig b/configs/am57xx_evm_defconfig
index 2e6787a906..41cd76d198 100644
--- a/configs/am57xx_evm_defconfig
+++ b/configs/am57xx_evm_defconfig
@@ -28,6 +28,8 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_VERSION_VARIABLE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_AVB_VERIFY=y
+CONFIG_AVB_BUF_ADDR=0x8200
+CONFIG_AVB_BUF_SIZE=0x2F00
CONFIG_ANDROID_AB=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_SEPARATE_BSS=y
diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index 808bd2881e..9505549439 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -33,6 +33,8 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_VERSION_VARIABLE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_AVB_VERIFY=y
+CONFIG_AVB_BUF_ADDR=0x8200
+CONFIG_AVB_BUF_SIZE=0x2F00
CONFIG_ANDROID_AB=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_SEPARATE_BSS=y
diff --git a/configs/am57xx_hs_evm_usb_defconfig
b/configs/am57xx_hs_evm_usb_defconfig
index 8698b7c8b5..73df983e2d 100644
--- a/configs/am57xx_hs_evm_usb_defconfig
+++ b/configs/am57xx_hs_evm_usb_defconfig
@@ -35,6 +35,8 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
CONFIG_VERSION_VARIABLE=y
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_AVB_VERIFY=y
+CONFIG_AVB_BUF_ADDR=0x8200
+CONFIG_AVB_BUF_SIZE=0x2F00
CONFIG_ANDROID_AB=y
CONFIG_SPL_SYS_MALLOC_SIMPLE=y
CONFIG_SPL_SEPARATE_BSS=y
diff --git a/include/avb_verify.h b/include/avb_verify.h
index a8d7090f79..1e787ba666 100644
--- a/include/avb_verify.h
+++ b/include/avb_verify.h
@@ -72,12 +72,12 @@ static inline uint64_t calc_offset(struct mmc_part *part,
int64_t offset)
static inline size_t get_sector_buf_size(void)
{
- return (size_t)CONFIG_FASTBOOT_BUF_SIZE;
+ return (size_t)CONFIG_AVB_BUF_SIZE;
}
static inline void *get_sector_buf(void)
{
- return map_sysmem(CONFIG_FASTBOOT_BUF_ADDR, CONFIG_FASTBOOT_BUF_SIZE);
+ return map_sysmem(CONFIG_AVB_BUF_ADDR, CONFIG_AVB_BUF_SIZE);
}
static inline bool is_buf_unaligned(void *buffer)
--
2.17.1
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
Hi Jan, On 11/08/20 6:07 pm, Jan Kiszka wrote: > On 11.08.20 12:46, Lokesh Vutla wrote: >> >> >> On 11/08/20 4:12 pm, Jan Kiszka wrote: >>> On 11.08.20 12:33, Lokesh Vutla wrote: On 23/06/20 4:45 pm, Jan Kiszka wrote: > This brings watchdog support for the TI K3 SoCs, derived from the Linux > kernel, augmented with firmware loading as needed on the AM65x. > > Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream > support will be posted soon). > > Changes in v2: > - keep watchdog powered when handing over to Linux > - drop unneeded explicit power-on > - account for RTI firmware locking the power domain Patch 1 and 3 merged applied. >>> >>> Thanks. Still taking workable suggestions for loading the firmware. >> >> FIT image is the one that I can think off. Since SPL is loading the FIT >> image, >> SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot >> can start the remote cores using this info. > > OK, just the ensure I got the idea correctly: > > - extend struct spl_handoff or arch_spl_handoff with the fit image > loadaddr that spl is processing Yes > > - stick the watchdog firmware into the u-boot proper fit image > (generated by tools/k3_fit_atf.sh or shipped via the board folder, as > in our case) IMHO, not via board folder. k3_fit_atf is used to generate a53 spl images. May be create a new one that packs fit image with u-boot and firmware. Or can you check if binman in u-boot works for you? > > - from the watchdog driver, trigger parsing of that fit image and > extracting of the firmware from there Yes Thanks and regards, Lokesh > > Jan >
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
On Tue, Aug 11, 2020 at 04:29:46PM +0200, Simon Goldschmidt wrote: > Am 11.08.2020 um 16:21 schrieb Tom Rini: > > On Tue, Aug 11, 2020 at 03:14:39PM +0200, Marek Vasut wrote: > >> On 8/11/20 3:06 PM, Tom Rini wrote: > >>> On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote: > >>> > Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required > for booting up Cyclone5/Arria10. > > For Cyclone5 using NAND flash image layout for 128 KB memory blocks, > 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp > which contains four 128KB SPL images (each 64KB SPL is followed by > 64KB of zero-padding). > > Signed-off-by: Chee Hong Ang > --- > Makefile | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Makefile b/Makefile > index 4483a9b..f4631f1 100644 > --- a/Makefile > +++ b/Makefile > @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE > ifneq ($(CONFIG_ARCH_SOCFPGA),) > quiet_cmd_socboot = SOCBOOT $@ > cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > -spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > -u-boot.img > $@ || rm -f $@ > +spl/u-boot-spl.sfp \ > +spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ > + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ > u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > $(call if_changed,socboot) > > @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero > of=spl/u-boot-spl.pad bs=64 count=1024 ; \ > cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > -spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > -u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad > +spl/u-boot-spl.sfp \ > +spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp > ; \ > + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ > + rm -f $@ spl/u-boot-spl.pad > u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > $(call if_changed,socnandboot) > >>> > >>> It's not immediately clear to me why we're doing this here, rather than > >>> instructing the user to write the file 4 times when programming. On TI > >>> platforms, even on NAND, for forever there's been multiple locations the > >>> ROM will check for the loader. Is there a reason to not handle this at > >>> that level? > >> > >> The u-boot-with-spl.sfp was there to have one U-Boot image including > >> SPL, other platforms do that as well. Except for the NAND case, where > >> the padding is different. > > > > Right, it's a convenience file and handy in some cases. But what's the > > reason for doing the 4 copy case? It makes sense to create > > "u-boot-with-stuff-plus-header" when there's a header that has to cover > > the whole load, or you're going to write it to an SD card or there's > > some non-trivial mangling involved. Is the problem that > > "u-boot-spl.sfp" isn't ever expected to be seen by the user and so it > > would be odd to tell them to write that in the 4 places and then write > > u-boot.img in the correct place, so instead we have to pad everything > > out and make a large file? > > As U-Boot and SPL have to fit together, I think it's better to create > just one file that has to be written to SD card or flash. And writing to > NOR flash is, depending on how you do it, not too quick, so it's *very* > convenient to have this "4x SPL plus U-Boot" single file (start the > command, get a coffee and wait). > > And yes, it *is* just a convenience thing. But I think it's a good thing > to have as result from the build. Even if it's only for the "dumb > standard user" not having to know the offset where U-Boot has to be put... Alright, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
Am 11.08.2020 um 16:21 schrieb Tom Rini: > On Tue, Aug 11, 2020 at 03:14:39PM +0200, Marek Vasut wrote: >> On 8/11/20 3:06 PM, Tom Rini wrote: >>> On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote: >>> Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required for booting up Cyclone5/Arria10. For Cyclone5 using NAND flash image layout for 128 KB memory blocks, 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp which contains four 128KB SPL images (each 64KB SPL is followed by 64KB of zero-padding). Signed-off-by: Chee Hong Ang --- Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 4483a9b..f4631f1 100644 --- a/Makefile +++ b/Makefile @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE ifneq ($(CONFIG_ARCH_SOCFPGA),) quiet_cmd_socboot = SOCBOOT $@ cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ - u-boot.img > $@ || rm -f $@ + spl/u-boot-spl.sfp \ + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ +cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socboot) @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \ cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad + spl/u-boot-spl.sfp \ + spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ + rm -f $@ spl/u-boot-spl.pad u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socnandboot) >>> >>> It's not immediately clear to me why we're doing this here, rather than >>> instructing the user to write the file 4 times when programming. On TI >>> platforms, even on NAND, for forever there's been multiple locations the >>> ROM will check for the loader. Is there a reason to not handle this at >>> that level? >> >> The u-boot-with-spl.sfp was there to have one U-Boot image including >> SPL, other platforms do that as well. Except for the NAND case, where >> the padding is different. > > Right, it's a convenience file and handy in some cases. But what's the > reason for doing the 4 copy case? It makes sense to create > "u-boot-with-stuff-plus-header" when there's a header that has to cover > the whole load, or you're going to write it to an SD card or there's > some non-trivial mangling involved. Is the problem that > "u-boot-spl.sfp" isn't ever expected to be seen by the user and so it > would be odd to tell them to write that in the 4 places and then write > u-boot.img in the correct place, so instead we have to pad everything > out and make a large file? As U-Boot and SPL have to fit together, I think it's better to create just one file that has to be written to SD card or flash. And writing to NOR flash is, depending on how you do it, not too quick, so it's *very* convenient to have this "4x SPL plus U-Boot" single file (start the command, get a coffee and wait). And yes, it *is* just a convenience thing. But I think it's a good thing to have as result from the build. Even if it's only for the "dumb standard user" not having to know the offset where U-Boot has to be put... Regards, Simon
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
On Tue, Aug 11, 2020 at 03:14:39PM +0200, Marek Vasut wrote: > On 8/11/20 3:06 PM, Tom Rini wrote: > > On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote: > > > >> Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required > >> for booting up Cyclone5/Arria10. > >> > >> For Cyclone5 using NAND flash image layout for 128 KB memory blocks, > >> 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp > >> which contains four 128KB SPL images (each 64KB SPL is followed by > >> 64KB of zero-padding). > >> > >> Signed-off-by: Chee Hong Ang > >> --- > >> Makefile | 11 +++ > >> 1 file changed, 7 insertions(+), 4 deletions(-) > >> > >> diff --git a/Makefile b/Makefile > >> index 4483a9b..f4631f1 100644 > >> --- a/Makefile > >> +++ b/Makefile > >> @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE > >> ifneq ($(CONFIG_ARCH_SOCFPGA),) > >> quiet_cmd_socboot = SOCBOOT $@ > >> cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > >> - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > >> - u-boot.img > $@ || rm -f $@ > >> + spl/u-boot-spl.sfp \ > >> + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ > >> +cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ > >> u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > >>$(call if_changed,socboot) > >> > >> @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero > >> of=spl/u-boot-spl.pad bs=64 count=1024 ; \ > >> cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > >>spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > >>spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > >> - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > >> - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad > >> + spl/u-boot-spl.sfp \ > >> + spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ > >> + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ > >> + rm -f $@ spl/u-boot-spl.pad > >> u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > >>$(call if_changed,socnandboot) > > > > It's not immediately clear to me why we're doing this here, rather than > > instructing the user to write the file 4 times when programming. On TI > > platforms, even on NAND, for forever there's been multiple locations the > > ROM will check for the loader. Is there a reason to not handle this at > > that level? > > The u-boot-with-spl.sfp was there to have one U-Boot image including > SPL, other platforms do that as well. Except for the NAND case, where > the padding is different. Right, it's a convenience file and handy in some cases. But what's the reason for doing the 4 copy case? It makes sense to create "u-boot-with-stuff-plus-header" when there's a header that has to cover the whole load, or you're going to write it to an SD card or there's some non-trivial mangling involved. Is the problem that "u-boot-spl.sfp" isn't ever expected to be seen by the user and so it would be odd to tell them to write that in the 4 places and then write u-boot.img in the correct place, so instead we have to pad everything out and make a large file? -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] fs/squashfs: add support for ZSTD decompression
On Tue, 11 Aug 2020 15:29:51 +0200
Thomas Petazzoni wrote:
> On Tue, 11 Aug 2020 15:17:55 +0200
> Joao Marcos Costa wrote:
>
> > +#if IS_ENABLED(CONFIG_ZSTD)
> > +static int sqfs_zstd_decompress(void *dest, unsigned long dest_len,
> > + void *source, u32 src_len)
> > +{
> > + void *workspace;
> > + ZSTD_DCtx *ctx;
> > + size_t wsize;
> > + int ret;
> > +
> > + wsize = ZSTD_DCtxWorkspaceBound();
>
> So apparently this "workspace" has a constant size, which does not
> depend on the size of the input buffer. Correct ?
Yes, correct.
> If that's the case, can we instead allocate it once for all in
> sqfs_probe() if the filesystem is zstd-compressed ? I.e perhaps
> sqfs_probe() could call a sqfs_decompressor_init() function,
> implemented in sqfs_decompressor.c, which will do this sort of
> initialization. And of course this memory area would be freed up in
> sqfs_close(), calling a sqfs_decompressor_{deinit,cleanup,close}
> function.
Sure, it can be done. I will prepare a v2 addressing your suggestion.
Thanks!
> Best regards,
>
> Thomas
Best regards,
Joao
[PATCH v3 1/1] Makefile: socfpga: Generate sfp file with 4 SPL images
Generate 'u-boot-splx4.sfp' which consist of 4 SPL images required for booting up Cyclone5/Arria10. By default, this 'u-boot-splx4.sfp' is generated without extra padding after each SPL image. For Cyclone5, 'u-boot-splx4.sfp' contains: 4 x SPL(64KB) = 256KB For Arria10, 'u-boot-splx4.sfp' contains: 4 x SPL(256KB) = 1024KB For Cyclone5 using NAND flash image layout for 128 KB memory blocks, user can 'make' the following target to generate 4 SPL images with padding: make u-boot-spl-padx4.sfp 'u-boot-spl-padx4.sfp' contains four 128KB SPL images (each 64KB SPL is followed by 64KB of zero-padding). 4 x (SPL(64KB) + zero-padding(64KB)) = 512KB Signed-off-by: Chee Hong Ang --- v3 changes: - add 'u-boot-splx4.sfp' make target (4 x SPL image without paddings) - add 'u-boot-spl-padx4.sfp' make target (4 x SPL image with 64KB paddings) - Update commit message (refer to commit message for details explanation) Makefile | 27 ++- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 4483a9bc8a..20357adebb 100644 --- a/Makefile +++ b/Makefile @@ -1580,21 +1580,30 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE $(call if_changed,pad_cat) ifneq ($(CONFIG_ARCH_SOCFPGA),) +quiet_cmd_gensplx4 = GENSPLX4 $@ +cmd_gensplx4 = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ + spl/u-boot-spl.sfp spl/u-boot-spl.sfp > $@ || rm -f $@ +u-boot-splx4.sfp: spl/u-boot-spl.sfp FORCE + $(call if_changed,gensplx4) + quiet_cmd_socboot = SOCBOOT $@ -cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ - u-boot.img > $@ || rm -f $@ -u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE +cmd_socboot = cat u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ +u-boot-with-spl.sfp: u-boot-splx4.sfp u-boot.img FORCE $(call if_changed,socboot) -quiet_cmd_socnandboot = SOCNANDBOOT $@ -cmd_socnandboot = dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \ +quiet_cmd_gensplpadx4 = GENSPLPADX4 $@ +cmd_gensplpadx4 = dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \ cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad -u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE + spl/u-boot-spl.sfp spl/u-boot-spl.pad > $@ || \ + rm -f $@ spl/u-boot-spl.pad +u-boot-spl-padx4.sfp: spl/u-boot-spl.sfp FORCE + $(call if_changed,gensplpadx4) + +quiet_cmd_socnandboot = SOCNANDBOOT $@ +cmd_socnandboot = cat u-boot-spl-padx4.sfp u-boot.img > $@ || rm -f $@ +u-boot-with-nand-spl.sfp: u-boot-spl-padx4.sfp u-boot.img FORCE $(call if_changed,socnandboot) endif -- 2.19.0
Re: [PATCH 2/2] fs/squashfs: add support for ZSTD decompression
On Tue, 11 Aug 2020 15:17:55 +0200
Joao Marcos Costa wrote:
> +#if IS_ENABLED(CONFIG_ZSTD)
> +static int sqfs_zstd_decompress(void *dest, unsigned long dest_len,
> + void *source, u32 src_len)
> +{
> + void *workspace;
> + ZSTD_DCtx *ctx;
> + size_t wsize;
> + int ret;
> +
> + wsize = ZSTD_DCtxWorkspaceBound();
So apparently this "workspace" has a constant size, which does not
depend on the size of the input buffer. Correct ?
If that's the case, can we instead allocate it once for all in
sqfs_probe() if the filesystem is zstd-compressed ? I.e perhaps
sqfs_probe() could call a sqfs_decompressor_init() function,
implemented in sqfs_decompressor.c, which will do this sort of
initialization. And of course this memory area would be freed up in
sqfs_close(), calling a sqfs_decompressor_{deinit,cleanup,close}
function.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
On Tuesday 11 August 2020 09:08:33 Tom Rini wrote:
> On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> > Hi Pali,
> >
> > On 11.08.20 10:00, Pali Rohár wrote:
> > > Hello!
> > >
> > > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > > Hi Tom,
> > > > Hi Pali,
> > > >
> > > > (added Pali because of the Nokia RX51 issue)
> > >
> > > Could you please send me a link to "problematic" patch? As you have not
> > > inlined it in this email.
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
> >
> > Its a rebase of the original patch.
> >
> > > > On 07.08.20 21:21, Tom Rini wrote:
> > > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > > >
> > > > > > Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS")
> > > > > > &
> > > > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
> > > > > > It makes no sense to still carry code that is guarded with
> > > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
> > > > > > all these unreferenced code paths.
> > > > > >
> > > > > > Also complete remove bi_memstart & bi_memsize from the board-info
> > > > > > struct. As now bi_dram[] is always enabled and should be used
> > > > > > instead.
> > > > > > This removes the redundant varriables.
> > > > > >
> > > > > > Signed-off-by: Stefan Roese
> > > > > > Cc: Daniel Schwierzeck
> > > > > > Cc: Tom Rini
> > > > > > Cc: Ramon Fried
> > > > > > Cc: Simon Glass
> > > > > > Cc: Michal Simek
> > > > > > Reviewed-by: Daniel Schwierzeck
> > > > >
> > > > > I don't see quite how, but this is breaking running
> > > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to current
> > > > > master
> > > > > was wrong, and is what's breaking the test). Please rebase and
> > > > > confirm
> > > > > that test passes as well, thanks!
> > > >
> > > > I've checked the issue with nokia_rx51_test.sh and could not find any
> > > > issues in the patch. My assumption now is, that the very old Linux
> > > > kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
> > > > struct in Linux to pass the memory information (via bd_memstart &
> > > > bi_memsize), as was also done in the very old PowerPC days. With this
> > > > patch now and the removal of these fields from bd_info, this might
> > > > explain why this kernel does not boot any more (no output on the serial
> > > > console at all).
> > > >
> > > > Pali, could you please check if my assumption is correct here? And if
> > > > yes, could please switch the test to using a newer kernel version? Or
> > > > remove the Linux kernel booting from the test?
> > >
> > > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
> > > version does not contain Maemo patches which are required for Maemo
> > > system which is still widely used. And yes, people are using it with
> > > U-Boot.
> > >
> > > Second reason why we cannot remove support for ATAGs is that Nokia's
> > > signed first stage bootloader pass other setup data via ATAGs for kernel
> > > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> > >
> > > And replacing first stage bootloader is not possible because it is
> > > signed and signing keys are secret (now probably lost).
> >
> > Okay. But this patch is not removing ATAG support, but removes 2
> > member from the bd_info struct (bi_memstart & bi_memsize), which are
> > replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
> > the generation of the memory ATAG is already done based on these
> > values:
> >
> > setup_memory_tags() in arch/arm/lib/bootm.c
> >
> > So I still fail to understand, why booting of this old kernel using
> > ATAGs does not work with this patch applied. Perhaps you could give
> > it a quick test? That would be really helpful. Here again the gitlab
> > branch that you can use for some tests:
> >
> > https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
I can do some tests on real N900 device at the end of week. But I doubt
that I could debug something on device if kernel does not print any
message.
Running u-boot and kernel in N900 emulator with debug serial console is
easier and you can do it too locally. If you look at that test script
test/nokia_rx51_test.sh you could see that it downloads & compile qemu
and prepare OneNAND MTD image with compiled u-boot + kernel binary.
You can also run that test script locally, it does not require root and
all data it stores into temporary "nokia_rx51_tmp" directory. This could
help you to test your changes without need to push them to travis/gitlab
ci testing.
> So, I also thought maybe changing bd_t was it, and reverted just that
> part locally, and it was still breaking. It's also only breaking in one
> of the three boot tests, if I
[PATCH 2/2] fs/squashfs: add support for ZSTD decompression
Add call to ZSTD's ZSTD_decompressDCtx(). In this use case, the caller
can upper bound the decompressed size, which will be the SquashFS data
block (or metadata block) size, so there is no need to use streaming
API.
Signed-off-by: Joao Marcos Costa
---
fs/squashfs/sqfs_decompressor.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/fs/squashfs/sqfs_decompressor.c b/fs/squashfs/sqfs_decompressor.c
index 9285df5d3b..b5a9d92808 100644
--- a/fs/squashfs/sqfs_decompressor.c
+++ b/fs/squashfs/sqfs_decompressor.c
@@ -18,6 +18,10 @@
#include
#endif
+#if IS_ENABLED(CONFIG_ZSTD)
+#include
+#endif
+
#include "sqfs_decompressor.h"
#include "sqfs_filesystem.h"
#include "sqfs_utils.h"
@@ -39,6 +43,31 @@ static void zlib_decompression_status(int ret)
}
#endif
+#if IS_ENABLED(CONFIG_ZSTD)
+static int sqfs_zstd_decompress(void *dest, unsigned long dest_len,
+ void *source, u32 src_len)
+{
+ void *workspace;
+ ZSTD_DCtx *ctx;
+ size_t wsize;
+ int ret;
+
+ wsize = ZSTD_DCtxWorkspaceBound();
+
+ workspace = malloc(wsize);
+ if (!workspace)
+ return -ENOMEM;
+
+ ctx = ZSTD_initDCtx(workspace, wsize);
+
+ ret = ZSTD_decompressDCtx(ctx, dest, dest_len, source, src_len);
+
+ free(workspace);
+
+ return ZSTD_isError(ret);
+}
+#endif /* CONFIG_ZSTD */
+
int sqfs_decompress(u16 comp_type, void *dest, unsigned long *dest_len,
void *source, u32 src_len)
{
@@ -67,6 +96,16 @@ int sqfs_decompress(u16 comp_type, void *dest, unsigned long
*dest_len,
break;
}
#endif
+#if IS_ENABLED(CONFIG_ZSTD)
+ case SQFS_COMP_ZSTD:
+ ret = sqfs_zstd_decompress(dest, *dest_len, source, src_len);
+ if (ret) {
+ printf("ZSTD Error code: %d\n", ZSTD_getErrorCode(ret));
+ return -EINVAL;
+ }
+
+ break;
+#endif /* CONFIG_ZSTD */
default:
printf("Error: unknown compression type.\n");
return -EINVAL;
--
2.17.1
[PATCH 1/2] fs/squashfs: add support for LZO decompression
Add call to lzo's lzo1x_decompress_safe() and rename source length
parameter from 'lenp' to 'src_len'.
Signed-off-by: Joao Marcos Costa
---
fs/squashfs/sqfs_decompressor.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/fs/squashfs/sqfs_decompressor.c b/fs/squashfs/sqfs_decompressor.c
index 09ca6cf6d0..9285df5d3b 100644
--- a/fs/squashfs/sqfs_decompressor.c
+++ b/fs/squashfs/sqfs_decompressor.c
@@ -9,6 +9,11 @@
#include
#include
#include
+
+#if IS_ENABLED(CONFIG_LZO)
+#include
+#endif
+
#if IS_ENABLED(CONFIG_ZLIB)
#include
#endif
@@ -35,20 +40,32 @@ static void zlib_decompression_status(int ret)
#endif
int sqfs_decompress(u16 comp_type, void *dest, unsigned long *dest_len,
- void *source, u32 lenp)
+ void *source, u32 src_len)
{
int ret = 0;
switch (comp_type) {
#if IS_ENABLED(CONFIG_ZLIB)
case SQFS_COMP_ZLIB:
- ret = uncompress(dest, dest_len, source, lenp);
+ ret = uncompress(dest, dest_len, source, src_len);
if (ret) {
zlib_decompression_status(ret);
return -EINVAL;
}
break;
+#endif
+#if IS_ENABLED(CONFIG_LZO)
+ case SQFS_COMP_LZO: {
+ size_t lzo_dest_len = *dest_len;
+ ret = lzo1x_decompress_safe(source, src_len, dest,
_dest_len);
+ if (ret) {
+ printf("LZO decompression failed. Error code: %d\n",
ret);
+ return -EINVAL;
+ }
+
+ break;
+ }
#endif
default:
printf("Error: unknown compression type.\n");
--
2.17.1
[PATCH 0/2] fs/squashfs: Add new decompression algorithms
Hello, Following the SquashFS support, this series adds support for LZO and ZSTD algorithms. The only compression type enabled by default is ZLIB, so LZO and ZSTD need to be manually selected. Joao Marcos Costa (2): fs/squashfs: add support for LZO decompression fs/squashfs: add support for ZSTD decompression fs/squashfs/sqfs_decompressor.c | 60 +++-- 1 file changed, 58 insertions(+), 2 deletions(-) -- 2.17.1
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
On 8/11/20 3:06 PM, Tom Rini wrote: > On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote: > >> Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required >> for booting up Cyclone5/Arria10. >> >> For Cyclone5 using NAND flash image layout for 128 KB memory blocks, >> 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp >> which contains four 128KB SPL images (each 64KB SPL is followed by >> 64KB of zero-padding). >> >> Signed-off-by: Chee Hong Ang >> --- >> Makefile | 11 +++ >> 1 file changed, 7 insertions(+), 4 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index 4483a9b..f4631f1 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE >> ifneq ($(CONFIG_ARCH_SOCFPGA),) >> quiet_cmd_socboot = SOCBOOT $@ >> cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ >> -spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ >> -u-boot.img > $@ || rm -f $@ >> +spl/u-boot-spl.sfp \ >> +spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ >> + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ >> u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE >> $(call if_changed,socboot) >> >> @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero >> of=spl/u-boot-spl.pad bs=64 count=1024 ; \ >> cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ >> spl/u-boot-spl.sfp spl/u-boot-spl.pad \ >> spl/u-boot-spl.sfp spl/u-boot-spl.pad \ >> -spl/u-boot-spl.sfp spl/u-boot-spl.pad \ >> -u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad >> +spl/u-boot-spl.sfp \ >> +spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ >> + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ >> + rm -f $@ spl/u-boot-spl.pad >> u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE >> $(call if_changed,socnandboot) > > It's not immediately clear to me why we're doing this here, rather than > instructing the user to write the file 4 times when programming. On TI > platforms, even on NAND, for forever there's been multiple locations the > ROM will check for the loader. Is there a reason to not handle this at > that level? The u-boot-with-spl.sfp was there to have one U-Boot image including SPL, other platforms do that as well. Except for the NAND case, where the padding is different.
Re: u-boot tarball downloads via https
On Tue, Aug 11, 2020 at 03:34:50PM +1200, Chris Packham wrote: > Hi Tom, Wolfgang, > > Today I found myself in need of a u-boot source tarball (usually I > just use git). > > I notice the link on http://www.denx.de/wiki/U-Boot/SourceCode points > to ftp://ftp.denx.de/pub/u-boot/ but it appears that the same content > is available via https://ftp.denx.de/pub/u-boot/ > > I know some browsers are moving towards dropping support for ftp and > there are all kinds of good reasons to be using https. Since it seems > to already work would it be possible to get the link on the denx page > updated to use https: instead of ftp: Good point, updated. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
On Tue, Aug 11, 2020 at 02:39:53PM +0200, Stefan Roese wrote:
> Hi Pali,
>
> On 11.08.20 10:00, Pali Rohár wrote:
> > Hello!
> >
> > On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> > > Hi Tom,
> > > Hi Pali,
> > >
> > > (added Pali because of the Nokia RX51 issue)
> >
> > Could you please send me a link to "problematic" patch? As you have not
> > inlined it in this email.
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
>
> Its a rebase of the original patch.
>
> > > On 07.08.20 21:21, Tom Rini wrote:
> > > > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> > > >
> > > > > Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
> > > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
> > > > > It makes no sense to still carry code that is guarded with
> > > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
> > > > > all these unreferenced code paths.
> > > > >
> > > > > Also complete remove bi_memstart & bi_memsize from the board-info
> > > > > struct. As now bi_dram[] is always enabled and should be used instead.
> > > > > This removes the redundant varriables.
> > > > >
> > > > > Signed-off-by: Stefan Roese
> > > > > Cc: Daniel Schwierzeck
> > > > > Cc: Tom Rini
> > > > > Cc: Ramon Fried
> > > > > Cc: Simon Glass
> > > > > Cc: Michal Simek
> > > > > Reviewed-by: Daniel Schwierzeck
> > > >
> > > > I don't see quite how, but this is breaking running
> > > > test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
> > > > was wrong, and is what's breaking the test). Please rebase and confirm
> > > > that test passes as well, thanks!
> > >
> > > I've checked the issue with nokia_rx51_test.sh and could not find any
> > > issues in the patch. My assumption now is, that the very old Linux
> > > kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
> > > struct in Linux to pass the memory information (via bd_memstart &
> > > bi_memsize), as was also done in the very old PowerPC days. With this
> > > patch now and the removal of these fields from bd_info, this might
> > > explain why this kernel does not boot any more (no output on the serial
> > > console at all).
> > >
> > > Pali, could you please check if my assumption is correct here? And if
> > > yes, could please switch the test to using a newer kernel version? Or
> > > remove the Linux kernel booting from the test?
> >
> > Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
> > version does not contain Maemo patches which are required for Maemo
> > system which is still widely used. And yes, people are using it with
> > U-Boot.
> >
> > Second reason why we cannot remove support for ATAGs is that Nokia's
> > signed first stage bootloader pass other setup data via ATAGs for kernel
> > and U-Boot N900 board code parses it, reuse it and pass to kernel.
> >
> > And replacing first stage bootloader is not possible because it is
> > signed and signing keys are secret (now probably lost).
>
> Okay. But this patch is not removing ATAG support, but removes 2
> member from the bd_info struct (bi_memstart & bi_memsize), which are
> replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
> the generation of the memory ATAG is already done based on these
> values:
>
> setup_memory_tags() in arch/arm/lib/bootm.c
>
> So I still fail to understand, why booting of this old kernel using
> ATAGs does not work with this patch applied. Perhaps you could give
> it a quick test? That would be really helpful. Here again the gitlab
> branch that you can use for some tests:
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
So, I also thought maybe changing bd_t was it, and reverted just that
part locally, and it was still breaking. It's also only breaking in one
of the three boot tests, if I follow things correctly.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote: > Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required > for booting up Cyclone5/Arria10. > > For Cyclone5 using NAND flash image layout for 128 KB memory blocks, > 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp > which contains four 128KB SPL images (each 64KB SPL is followed by > 64KB of zero-padding). > > Signed-off-by: Chee Hong Ang > --- > Makefile | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Makefile b/Makefile > index 4483a9b..f4631f1 100644 > --- a/Makefile > +++ b/Makefile > @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE > ifneq ($(CONFIG_ARCH_SOCFPGA),) > quiet_cmd_socboot = SOCBOOT $@ > cmd_socboot = catspl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > - u-boot.img > $@ || rm -f $@ > + spl/u-boot-spl.sfp \ > + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ > + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ > u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > $(call if_changed,socboot) > > @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero > of=spl/u-boot-spl.pad bs=64 count=1024 ; \ > cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ > - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad > + spl/u-boot-spl.sfp \ > + spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ > +cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ > +rm -f $@ spl/u-boot-spl.pad > u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > $(call if_changed,socnandboot) It's not immediately clear to me why we're doing this here, rather than instructing the user to write the file 4 times when programming. On TI platforms, even on NAND, for forever there's been multiple locations the ROM will check for the loader. Is there a reason to not handle this at that level? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hi Pali,
On 11.08.20 10:00, Pali Rohár wrote:
Hello!
On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
Hi Tom,
Hi Pali,
(added Pali because of the Nokia RX51 issue)
Could you please send me a link to "problematic" patch? As you have not
inlined it in this email.
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commit/7196447f2e708a83c653f39c97f2439960482ad6
Its a rebase of the original patch.
On 07.08.20 21:21, Tom Rini wrote:
On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Also complete remove bi_memstart & bi_memsize from the board-info
struct. As now bi_dram[] is always enabled and should be used instead.
This removes the redundant varriables.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Tom Rini
Cc: Ramon Fried
Cc: Simon Glass
Cc: Michal Simek
Reviewed-by: Daniel Schwierzeck
I don't see quite how, but this is breaking running
test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
was wrong, and is what's breaking the test). Please rebase and confirm
that test passes as well, thanks!
I've checked the issue with nokia_rx51_test.sh and could not find any
issues in the patch. My assumption now is, that the very old Linux
kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
struct in Linux to pass the memory information (via bd_memstart &
bi_memsize), as was also done in the very old PowerPC days. With this
patch now and the removal of these fields from bd_info, this might
explain why this kernel does not boot any more (no output on the serial
console at all).
Pali, could you please check if my assumption is correct here? And if
yes, could please switch the test to using a newer kernel version? Or
remove the Linux kernel booting from the test?
Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
version does not contain Maemo patches which are required for Maemo
system which is still widely used. And yes, people are using it with
U-Boot.
Second reason why we cannot remove support for ATAGs is that Nokia's
signed first stage bootloader pass other setup data via ATAGs for kernel
and U-Boot N900 board code parses it, reuse it and pass to kernel.
And replacing first stage bootloader is not possible because it is
signed and signing keys are secret (now probably lost).
Okay. But this patch is not removing ATAG support, but removes 2
member from the bd_info struct (bi_memstart & bi_memsize), which are
replaced (superseeded) by the bi_dram[].start/.size values. And AFAICT,
the generation of the memory ATAG is already done based on these
values:
setup_memory_tags() in arch/arm/lib/bootm.c
So I still fail to understand, why booting of this old kernel using
ATAGs does not work with this patch applied. Perhaps you could give
it a quick test? That would be really helpful. Here again the gitlab
branch that you can use for some tests:
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
Thanks,
Stefan
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
On 11.08.20 12:46, Lokesh Vutla wrote: On 11/08/20 4:12 pm, Jan Kiszka wrote: On 11.08.20 12:33, Lokesh Vutla wrote: On 23/06/20 4:45 pm, Jan Kiszka wrote: This brings watchdog support for the TI K3 SoCs, derived from the Linux kernel, augmented with firmware loading as needed on the AM65x. Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream support will be posted soon). Changes in v2: - keep watchdog powered when handing over to Linux - drop unneeded explicit power-on - account for RTI firmware locking the power domain Patch 1 and 3 merged applied. Thanks. Still taking workable suggestions for loading the firmware. FIT image is the one that I can think off. Since SPL is loading the FIT image, SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot can start the remote cores using this info. OK, just the ensure I got the idea correctly: - extend struct spl_handoff or arch_spl_handoff with the fit image loadaddr that spl is processing - stick the watchdog firmware into the u-boot proper fit image (generated by tools/k3_fit_atf.sh or shipped via the board folder, as in our case) - from the watchdog driver, trigger parsing of that fit image and extracting of the firmware from there Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
On 8/11/20 1:34 PM, Ang, Chee Hong wrote: >> On 8/11/20 10:01 AM, Chee Hong Ang wrote: >>> Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required >>> for booting up Cyclone5/Arria10. >>> >>> For Cyclone5 using NAND flash image layout for 128 KB memory blocks, >>> 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp >>> which contains four 128KB SPL images (each 64KB SPL is followed by >>> 64KB of zero-padding). >>> >>> Signed-off-by: Chee Hong Ang >>> --- >> >> What changed between V1 and V2 ? Changelog is missing. > In V2, 'make u-boot-with-nand-spl.sfp' will generate > spl/u-boot-nand-splx4.sfp which contains 4 x (SPL + 64KB padding). > Commit message already mentioned how to generate this SFP file with 64Kb > padding for each SPL in SFP. The changelog in the patches is there so it's quickly obvious what changed in the patch without searching for previous version and running a diff. >>> Makefile | 11 +++ >>> 1 file changed, 7 insertions(+), 4 deletions(-) >>> >>> diff --git a/Makefile b/Makefile >>> index 4483a9b..f4631f1 100644 >>> --- a/Makefile >>> +++ b/Makefile >>> @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE >>> ifneq ($(CONFIG_ARCH_SOCFPGA),) quiet_cmd_socboot = SOCBOOT $@ >>> cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ >>> - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ >>> - u-boot.img > $@ || rm -f $@ >>> + spl/u-boot-spl.sfp \ >>> + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ >>> + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ >>> u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE >>> $(call if_changed,socboot) >> >> Also, now that I look at it, if you want to generate some new target, it >> should be a Makefile target, just like u-boot-with-spl.sfp is a Makefile >> target. >> So then you can do make . > > There is already a target 'u-boot-with-nand-spl.sfp' in Makefile: > u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > $(call if_changed,socnandboot) Right, so there should be a new one, u-boot-with-spl-x4.sfp: spl/u-boot-spl.sfp FORCE and then whatever target needs the -x4 variant should again depend on it, e.g. u-boot-with-nand-spl.sfp: spl/u-boot-spl-x4.sfp u-boot.img FORCE
RE: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
> On 8/11/20 10:01 AM, Chee Hong Ang wrote: > > Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required > > for booting up Cyclone5/Arria10. > > > > For Cyclone5 using NAND flash image layout for 128 KB memory blocks, > > 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp > > which contains four 128KB SPL images (each 64KB SPL is followed by > > 64KB of zero-padding). > > > > Signed-off-by: Chee Hong Ang > > --- > > What changed between V1 and V2 ? Changelog is missing. In V2, 'make u-boot-with-nand-spl.sfp' will generate spl/u-boot-nand-splx4.sfp which contains 4 x (SPL + 64KB padding). Commit message already mentioned how to generate this SFP file with 64Kb padding for each SPL in SFP. > > > Makefile | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index 4483a9b..f4631f1 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE > > ifneq ($(CONFIG_ARCH_SOCFPGA),) quiet_cmd_socboot = SOCBOOT $@ > > cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > > - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > > - u-boot.img > $@ || rm -f $@ > > + spl/u-boot-spl.sfp \ > > + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ > > + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ > > u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > > $(call if_changed,socboot) > > Also, now that I look at it, if you want to generate some new target, it > should be a Makefile target, just like u-boot-with-spl.sfp is a Makefile > target. > So then you can do make . There is already a target 'u-boot-with-nand-spl.sfp' in Makefile: u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socnandboot) V2 patch contains the following changes as well which are missing in this email thread: @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \ cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad + spl/u-boot-spl.sfp \ + spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ + rm -f $@ spl/u-boot-spl.pad u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socnandboot)
Re: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
On 8/11/20 10:01 AM, Chee Hong Ang wrote: > Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required > for booting up Cyclone5/Arria10. > > For Cyclone5 using NAND flash image layout for 128 KB memory blocks, > 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp > which contains four 128KB SPL images (each 64KB SPL is followed by > 64KB of zero-padding). > > Signed-off-by: Chee Hong Ang > --- What changed between V1 and V2 ? Changelog is missing. > Makefile | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Makefile b/Makefile > index 4483a9b..f4631f1 100644 > --- a/Makefile > +++ b/Makefile > @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE > ifneq ($(CONFIG_ARCH_SOCFPGA),) > quiet_cmd_socboot = SOCBOOT $@ > cmd_socboot = catspl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > - u-boot.img > $@ || rm -f $@ > + spl/u-boot-spl.sfp \ > + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ > + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ > u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > $(call if_changed,socboot) Also, now that I look at it, if you want to generate some new target, it should be a Makefile target, just like u-boot-with-spl.sfp is a Makefile target. So then you can do make .
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
On 11/08/20 4:12 pm, Jan Kiszka wrote: > On 11.08.20 12:33, Lokesh Vutla wrote: >> >> >> On 23/06/20 4:45 pm, Jan Kiszka wrote: >>> This brings watchdog support for the TI K3 SoCs, derived from the Linux >>> kernel, augmented with firmware loading as needed on the AM65x. >>> >>> Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream >>> support will be posted soon). >>> >>> Changes in v2: >>> - keep watchdog powered when handing over to Linux >>> - drop unneeded explicit power-on >>> - account for RTI firmware locking the power domain >> >> Patch 1 and 3 merged applied. >> > > Thanks. Still taking workable suggestions for loading the firmware. FIT image is the one that I can think off. Since SPL is loading the FIT image, SPL_HANDOFF can be used to pass on the loadaddr from SPL to U-Boot and U-Boot can start the remote cores using this info. Thanks and regards, Lokesh
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
On 11.08.20 12:33, Lokesh Vutla wrote: On 23/06/20 4:45 pm, Jan Kiszka wrote: This brings watchdog support for the TI K3 SoCs, derived from the Linux kernel, augmented with firmware loading as needed on the AM65x. Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream support will be posted soon). Changes in v2: - keep watchdog powered when handing over to Linux - drop unneeded explicit power-on - account for RTI firmware locking the power domain Patch 1 and 3 merged applied. Thanks. Still taking workable suggestions for loading the firmware. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
Re: [PATCH 0/6] J2700: Enable various peripherals
On 07/08/20 12:26 am, Vignesh Raghavendra wrote: > Enable USB, HyperFlasha and CPSW on J7200 SoC > > Based on top of https://patchwork.ozlabs.org/project/uboot/list/?series=194305 Applied to u-boot-ti Thanks and regards, Lokesh
Re: [PATCH v4 00/19] arm: mach-k3: Initial support for Texas Instrument's J7200 Platform
On 08/08/20 4:22 pm, Lokesh Vutla wrote: > This series adds initial support for latest new SoC, J7200, from Texas > Instruments. > > The J7200 SoC is a part of the K3 Multicore SoC architecture platform. > It is targeted for for automotive gateway, vehicle compute systems, > Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications. > The SoC aims to meet the complex processing needs of modern embedded products. > > See J7200 Technical Reference Manual (SPRUIU1, June 2020) > for further details: https://www.ti.com/lit/pdf/spruiu1 > > Changes since v3: > - Fixed CONFIG_USB_GADGET_PRODUCT_NUM id j7200_evm_a72_defconfig > - Enable CONFIG_ENV_OVERWRITE in j7200_evm_a72_defconfig > - Dropped R5F and DSP REMOTEPROC support in j7200_evm_a72_defconfig > - Enabled TARGET_J7200_A72_EVM where ever needed. Applied to u-boot-ti Thanks and regards, Lokesh
Re: [PATCH] mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value
On 29/07/20 7:03 am, Faiz Abbas wrote: > The hardcoded array size leads to array overflows with changes in > speed modes enum in mmc core. Use MMC_MODES_END for otap_del_sel > array declaration to fix this. > > Signed-off-by: Faiz Abbas Applied to u-boot-ti Thanks and regards, Lokesh
Re: [PATCH v2 00/13] Add support for USB host and peripheral bootmodes on am65x-idk
On 03/08/20 11:35 am, Faiz Abbas wrote: > The following patches add support for USB mass storage and USB dfu > bootmodes on am654x-idk. > > Because of space constrains and the size of the USB stack, > there are two different usbmsc and usbdfu defconfigs for building R5 SPL. > Fitting both of these into one defconfig requires some changes in the > USB subsystem which is a longer term effort Applied to u-boot-ti Thanks and regards, Lokesh
Re: [PATCH 0/2] Update TI K3 cbass interconnect node names
On 25/07/20 4:21 am, Suman Anna wrote: > Hi Lokesh, > > The following 2 patches are minor cleanups that fix the various > CBASS interconnect node names from "interconnect" to "bus" on > K3 AM65x and J721E SoCs. "bus" is the correct dt-schema acceptible > node name. Applied to u-boot-ti Thanks and regards, Lokesh
Re: [PATCH v2] board: ti: am65x: Update fdt fixup logic for interconnect nodes
On 30/07/20 12:11 am, Suman Anna wrote: > The DT nodes on AM65x SoCs currently use a node name "interconnect" for > the various interconnects. This name is not following the DT schema, and > should simply be "bus". Update the fdt fixup logic to use both the > current and the expected corrected path names so that this logic won't > be broken with newer kernels. > > The logic also corrects the crypto node name as the DT node > unit-addresses are all expected to be lower case. > > Signed-off-by: Suman Anna > --- > v2: dropped the local variable due to its usage only in the conditional > CONFIG_TI_SECURE_DEVICE compilation path > v1: > https://patchwork.ozlabs.org/project/uboot/patch/20200723225609.29404-1-s-a...@ti.com/ Applied to u-boot-ti Thanks and regards, Lokesh
Re: [PATCH] arm: mach-k3: Clean non-coherent lines out of L3 cache
On 16/07/20 2:32 am, Andrew F. Davis wrote: > When switching on or off the ARM caches some care must be taken to ensure > existing cache line allocations are not left in an inconsistent state. > An example of this is when cache lines are considered non-shared by > and L3 controller even though the lines are shared. To prevent these > and other issues all cache lines should be cleared before enabling > or disabling a coherent master's cache. ARM cores and many L3 controllers > provide a way to efficiently clean out all cache lines to allow for > this, unfortunately there is no such easy way to do this on current K3 > MSMC based systems. > > We could explicitly clean out every valid external address tracked by > MSMC (all of DRAM), or we could attempt to identify only the set of > addresses accessed by a given boot stage and flush only those > specifically. This patch attempts the latter. We start with cleaning the > SPL load address. More addresses can be added here later as they are > identified. > > Note that we perform a flush operation for both the flush and invalidate > operations, this is not a typo. We do this to avoid the situation that > some ARM cores will promote an invalidate to a clean+invalidate, but only > emit the invalidation operation externally, leading to a loss of data. > > Signed-off-by: Andrew F. Davis > Tested-by: Faiz Abbas Applied to u-boot-ti Thanks and regards, Lokesh > --- > arch/arm/mach-k3/Makefile | 1 + > arch/arm/mach-k3/cache.S | 24 > 2 files changed, 25 insertions(+) > create mode 100644 arch/arm/mach-k3/cache.S > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile > index 028015ed66..7572f56925 100644 > --- a/arch/arm/mach-k3/Makefile > +++ b/arch/arm/mach-k3/Makefile > @@ -8,6 +8,7 @@ obj-$(CONFIG_SOC_K3_J721E) += j721e_init.o > obj-$(CONFIG_ARM64) += arm64-mmu.o > obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o > obj-$(CONFIG_TI_SECURE_DEVICE) += security.o > +obj-$(CONFIG_ARM64) += cache.o > ifeq ($(CONFIG_SPL_BUILD),y) > obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o > endif > diff --git a/arch/arm/mach-k3/cache.S b/arch/arm/mach-k3/cache.S > new file mode 100644 > index 00..a5717ea203 > --- /dev/null > +++ b/arch/arm/mach-k3/cache.S > @@ -0,0 +1,24 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2020 Texas Instruments Incorporated - http://www.ti.com/ > + * Andrew F. Davis > + */ > + > +#include > +#include > + > +#if defined(CONFIG_SPL_BUILD) > +ENTRY(__asm_invalidate_l3_dcache) > + /* Invalidate SPL address range */ > + mov x0, #CONFIG_SPL_TEXT_BASE > + add x1, x0, #CONFIG_SPL_MAX_SIZE > + b __asm_flush_dcache_range > +ENDPROC(__asm_invalidate_l3_dcache) > + > +ENTRY(__asm_flush_l3_dcache) > + /* Flush SPL address range */ > + mov x0, #CONFIG_SPL_TEXT_BASE > + add x1, x0, #CONFIG_SPL_MAX_SIZE > + b __asm_flush_dcache_range > +ENDPROC(__asm_flush_l3_dcache) > +#endif >
Re: [PATCH v2 0/3] watchdog: K3: Add RTI watchdog support
On 23/06/20 4:45 pm, Jan Kiszka wrote: > This brings watchdog support for the TI K3 SoCs, derived from the Linux > kernel, augmented with firmware loading as needed on the AM65x. > > Tested on the AM65x EVM and the IOT2050 (also AM65x-based, upstream > support will be posted soon). > > Changes in v2: > - keep watchdog powered when handing over to Linux > - drop unneeded explicit power-on > - account for RTI firmware locking the power domain Patch 1 and 3 merged applied. Thanks and regards, Lokesh
Re: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi()
On 8/11/20 3:50 AM, Heinrich Schuchardt wrote: > On 11.08.20 08:20, Rick Chen wrote: >> Hi Heinrich >> >>> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] >>> Sent: Tuesday, August 11, 2020 11:57 AM >>> To: Rick Jian-Zhi Chen(陳建志) >>> Cc: Sean Anderson; Lukas Auer; Simon Glass; Anup Patel; Daniel Schwierzeck; >>> u-boot@lists.denx.de; Heinrich Schuchardt >>> Subject: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi() >>> >>> At least on the Kendryte K210: >>> >>> gd->arch.available_harts= 0x0003 arch.ipi[0].addr= >>> gd->0x arch.ipi[0].arg0= 0x >>> gd->arch.ipi[0].arg1= 0x arch.ipi[1].addr= >>> gd->0x arch.ipi[1].arg0= 0x >>> gd->arch.ipi[1].arg1= 0x >>> >>> We should not jump to 0x0 to handle an interrupt. >> >> Can you explain why K210 be affected by it ? > > I have been running U-Boot on the MaixDuino. > > Without this patch secondary_hart_loop() is reached only once. With the > patch it is reached several thousand times. Hm, interesting. To me, this is a symptom of something else going terribly wrong. I originally had this check in place so that it would be easier to detect these sorts of errors. I don't think this is the correct fix, however. We should really try and find the root cause of the bug. > I would not expect NULL to contain any code that should be executed by > the secondary hart. See doc/board/sipeed/maix.rst: > > AddressSize Description > == = === > 0x 0x1000debug > 0x1000 0x1000rom > 0x0200 0xC000clint > >> >>> >>> Signed-off-by: Heinrich Schuchardt >>> --- >>> arch/riscv/lib/smp.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c index >>> ac22136314..d725fa32e8 100644 >>> --- a/arch/riscv/lib/smp.c >>> +++ b/arch/riscv/lib/smp.c >>> @@ -96,6 +96,8 @@ void handle_ipi(ulong hart) >>> return; >>> } >>> >>> + if (!smp_function) >>> + return; >>> smp_function(hart, gd->arch.ipi[hart].arg0, >>> gd->arch.ipi[hart].arg1); } >> >> I remember Sean add this check in >> [v10,14/21] riscv: Clean up IPI initialization code >> . And I ask him to remove. >> https://patchwork.ozlabs.org/project/uboot/patch/20200503024637.327733-15-sean...@gmail.com/ > > Your comment was: "Please remove the sanity check. If zero address is > the intended jump point, then system will work abnormal." > > The only place where gd->arch.ipi[hart].addr is set is: > > arch/riscv/lib/smp.c:53 send_ipi_many(): > gd->arch.ipi[reg].addr = ipi->addr; > > send_ipi_many() is only called in smp_call_function(). > > So the line > > smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1); > > can only work if smp_function() has been called before this point at any > time. The start code only calls it in spl_secondary_hart_stack_gd_setup(). Can you retry with [1]? I think Bin Meng removed a call to sbi_init_ipi in [2] as part of a larger revert. The actual revert-of-revert is in [3], though it really should be split out into its own patch. The original commit making these changes is [4]. Note that the situation before [4] was that the IPI got initialized by the first hart to call any IPI function. If that hart was not the boot hart, Bad Things started to happen (e.g. race conditions, memory corruption, etc). In that patch, I moved the initialization to its own function so we would not have any race conditions and instead have (easier-to-debug imo) calls to handle_ipi with bogus arguments. Of course, when everything is working properly, we should get neither of these. [1] https://patchwork.ozlabs.org/project/uboot/list/?series=193047 [2] https://patchwork.ozlabs.org/project/uboot/patch/1595225827-23674-1-git-send-email-bmeng...@gmail.com/ [3] https://patchwork.ozlabs.org/project/uboot/patch/20200729095636.1077054-5-sean...@gmail.com/ [4] https://patchwork.ozlabs.org/project/uboot/patch/20200521161503.384823-15-sean...@gmail.com/ > Why do we call handle_ipi() on the secondary hart at all? Presumably to handle the IPI it got sent? Sorry, I'm confused as to what you're getting at. > Where do you expect it to jump if U-Boot is the first binary loaded? > > Even if spl_secondary_hart_stack_gd_setup() has initialized the jump > address to secondary_hart_relocate(), do we want the secondary hart to > execute it again and again? --Sean
[GIT PULL] TI changes for v2020.10-rc3
Hi Tom, Please find the pull request for v2020.10-rc3 containing TI specific changes. This should have been sent for rc2 but delayed due to some comments in the last minute. Please look at the PR description for the details on the PR. Travis-CI build: https://travis-ci.org/github/lokeshvutla/u-boot/builds/716796052 The following changes since commit c045207f96f7f7ae8c7f134a6010e636176b: Prepare v2020.10-rc2 (2020-08-10 16:10:09 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2020.10-rc3 for you to fetch changes up to ce2e881bb791dca33b122fd901820deef303f6df: arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port (2020-08-11 10:22:11 +0530) Below are the major changes in this PR: - Added support for J7200 evm - DM_ETH and DM_USB migrations for omap3 - USB DFU and mass storage support for AM65x evm - RTI watchdog support for K3 devices - Fix an issue with L3 cache on K3 devices Andrew F. Davis (1): arm: mach-k3: Clean non-coherent lines out of L3 cache Dave Gerlach (1): arm: dts: k3-j7200: Add R5 specific dts support Derald D. Woods (1): ARM: omap3: evm: Complete DM_ETH and DM_USB migrations Faiz Abbas (14): mmc: am654_sdhci: Use MMC_MODES_END value instead of hardcoded value spl: usb: Create an API spl_usb_load() spl: usb: Only init usb once armv7R: K3: am654: Use full malloc in SPL both pre and post reloc arm: mach-k3: sysfw-loader: Add support to load SYSFW from USB arm: mach-k3: am6_init: Gate mmc related configurations with the appropriate config arm: mach-k3: am6_init: Do USB fixups to facilitate host and device boot modes arm: mach-k3: am6_init: Add support for USB boot mode arm: dts: k3-am654-r5-base-board: Add USB0 nodes arm: dts: k3-am654-base-board: Add support for USB0 in SPL configs: am65x_evm: Add support for DFU related configs configs: am65x_evm_a53: Enable USB Mass storage and DFU boot modes configs: Add defconfig for USB DFU bootmode configs: Add new config for supporting USB mass storage boot Jan Kiszka (3): watchdog: Add support for K3 RTI watchdog arm: dts: k3: Add RTI watchdogs am654_sdhci: mmc fail to send stop cmd Jean-Jacques Hiblot (1): arm: mach-k3: Fix platform hang when SPL_MULTI_DTB_FIT is not enabled Kishon Vijay Abraham I (1): soc: soc_ti_k3: Add device identification for J7200 SoC Lokesh Vutla (15): board: ti: board_detect: Add stub functions for EEPROM detection apis board: ti: j721e: Probe eeprom only when CONFIG_TI_I2C_BOARD_DETECT is defined arm: mach-k3: Move mmr_unlock to a common location arm: mach-k3: sysfw-loader: Add support for rom loading sysfw image arm: mach-k3: j721e: Add detection for j721e arm: mach-k3: j721e: Fix unlocking control module registers arm: mach-k3: j7200: Add support for SOC detection arm: mach-k3: j7200: Add support for storing extended boot info from ROM arm: mach-k3: j7200: Detect if ROM has already loaded sysfw board: ti: j7200: Introduce support for j7200 build targets board: ti: j7200: Add board detection support for j7200 ram: k3-j721e: Relax version checks for memory controller arm: dts: k3-j7200: Add dts support configs: j7200_evm_r5: Add initial support configs: j7200_evm_a72: Add Initial support Suman Anna (4): arm: dts: k3-am65: Fix interconnect node names arm: dts: k3-j721e: Fix interconnect node names board: ti: am65x: Update fdt fixup logic for interconnect nodes board: ti: j721e: Update fdt fixup logic for interconnect nodes Vignesh Raghavendra (6): arm: dts: k3-j7200: Add USB related DT entries board: ti: j721e: Add support for HyperFlash detection ARM: dts: k3-j7200: Add wkup gpio node ARM: dts: k3-j7200: Add HyperBus and HyperFlash nodes ARM: dts: k3-j7200-mcu-wakeup: Add CPSW2G support arm: dts: k3-j7200-common-proc-board: Enable CPSW2G port arch/arm/dts/Makefile |4 +- arch/arm/dts/k3-am65-mcu.dtsi |9 + arch/arm/dts/k3-am65.dtsi |6 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 27 + arch/arm/dts/k3-am654-r5-base-board.dts| 35 + .../arm/dts/k3-j7200-common-proc-board-u-boot.dtsi | 133 ++ arch/arm/dts/k3-j7200-common-proc-board.dts| 195 ++ arch/arm/dts/k3-j7200-ddr-evm-lp4-1600.dtsi| 2195 arch/arm/dts/k3-j7200-main.dtsi| 343 +++ arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 272 +++ arch/arm/dts/k3-j7200-r5-common-proc-board.dts | 217 ++ arch/arm/dts/k3-j7200-som-p0.dtsi | 62 + arch/arm/dts/k3-j7200.dtsi
Re: [RFC PATCH 1/4] mt7622: Support to build 32 bits version.
Am 11. August 2020 04:11:46 MESZ schrieb Sam Shih : >Thank you for your continued support to mt7622 (bpir64) > >Because we recently completed an ATF based on the mainline ATF 2.1 >which >is a standard ATF containing BL2 (equal to the preloader in the old >bpir64 image, but implemented in aarch64), >and BL31 security monitor (equivalent to ATF in the old bpir64 image, >implemented in aarch64) Can you point us to source and maybe binary to this ATF and install instructions as this may need other preloader? Does it work for sd and emmc (maybe nand/nor)? >Using this new ATF 2.1, MT7622 mainline U-boot can detect the FIT >description in the liunx image and jump to aarch32/aarch64 mode and >boot >to Shell. Please give us Instructions for FIT-creation/booting too as we only use legacy boot atm based on bananpi's sources. I know this page, but here much things are changing now (preloader,atf,uboot,kernelpackage) so if you have it already working it will save us much time on try https://gitlab.denx.de/u-boot/u-boot/raw/HEAD/doc/uImage.FIT/beaglebone_vboot.txt >Therefore, I think we should keep the mt7622 upstream uboot code clear >and keep no proprietary code to support the old ATF. Then we need to know exact information about new bootup >The new architecture of mt7622 (bpir64) will be: >aarch64 prelaoder (BL2), aarch64 bl31 and aarch64 u-boot and optional >arch32/aarch64 of the Linux kernel Same as above regards Frank
[PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required for booting up Cyclone5/Arria10. For Cyclone5 using NAND flash image layout for 128 KB memory blocks, 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp which contains four 128KB SPL images (each 64KB SPL is followed by 64KB of zero-padding). Signed-off-by: Chee Hong Ang --- Makefile | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 4483a9b..f4631f1 100644 --- a/Makefile +++ b/Makefile @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE ifneq ($(CONFIG_ARCH_SOCFPGA),) quiet_cmd_socboot = SOCBOOT $@ cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ - u-boot.img > $@ || rm -f $@ + spl/u-boot-spl.sfp \ + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socboot) @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \ cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad + spl/u-boot-spl.sfp \ + spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ + rm -f $@ spl/u-boot-spl.pad u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socnandboot) -- 2.2.0
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hello!
On Tuesday 11 August 2020 08:37:46 Stefan Roese wrote:
> Hi Tom,
> Hi Pali,
>
> (added Pali because of the Nokia RX51 issue)
Could you please send me a link to "problematic" patch? As you have not
inlined it in this email.
> On 07.08.20 21:21, Tom Rini wrote:
> > On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
> >
> > > Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
> > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
> > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
> > > It makes no sense to still carry code that is guarded with
> > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
> > > all these unreferenced code paths.
> > >
> > > Also complete remove bi_memstart & bi_memsize from the board-info
> > > struct. As now bi_dram[] is always enabled and should be used instead.
> > > This removes the redundant varriables.
> > >
> > > Signed-off-by: Stefan Roese
> > > Cc: Daniel Schwierzeck
> > > Cc: Tom Rini
> > > Cc: Ramon Fried
> > > Cc: Simon Glass
> > > Cc: Michal Simek
> > > Reviewed-by: Daniel Schwierzeck
> >
> > I don't see quite how, but this is breaking running
> > test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
> > was wrong, and is what's breaking the test). Please rebase and confirm
> > that test passes as well, thanks!
>
> I've checked the issue with nokia_rx51_test.sh and could not find any
> issues in the patch. My assumption now is, that the very old Linux
> kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
> struct in Linux to pass the memory information (via bd_memstart &
> bi_memsize), as was also done in the very old PowerPC days. With this
> patch now and the removal of these fields from bd_info, this might
> explain why this kernel does not boot any more (no output on the serial
> console at all).
>
> Pali, could you please check if my assumption is correct here? And if
> yes, could please switch the test to using a newer kernel version? Or
> remove the Linux kernel booting from the test?
Yes, Nokia N900 uses "old" ATAGs. But we cannot remove it. New kernel
version does not contain Maemo patches which are required for Maemo
system which is still widely used. And yes, people are using it with
U-Boot.
Second reason why we cannot remove support for ATAGs is that Nokia's
signed first stage bootloader pass other setup data via ATAGs for kernel
and U-Boot N900 board code parses it, reuse it and pass to kernel.
And replacing first stage bootloader is not possible because it is
signed and signing keys are secret (now probably lost).
> I've pushed the latest patch version into this branch (based on top of
> the latest TOT):
>
> https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
>
> The failing Azure CI report can be found here:
>
> https://dev.azure.com/sr0718/u-boot/_build/results?buildId=20=results
>
> A working Azure report is here for comparison:
>
> https://dev.azure.com/sr0718/u-boot/_build/results?buildId=18=results
>
> Thanks,
> Stefan
Re: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi()
On 11.08.20 08:20, Rick Chen wrote: > Hi Heinrich > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] >> Sent: Tuesday, August 11, 2020 11:57 AM >> To: Rick Jian-Zhi Chen(陳建志) >> Cc: Sean Anderson; Lukas Auer; Simon Glass; Anup Patel; Daniel Schwierzeck; >> u-boot@lists.denx.de; Heinrich Schuchardt >> Subject: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi() >> >> At least on the Kendryte K210: >> >> gd->arch.available_harts= 0x0003 arch.ipi[0].addr= >> gd->0x arch.ipi[0].arg0= 0x >> gd->arch.ipi[0].arg1= 0x arch.ipi[1].addr= >> gd->0x arch.ipi[1].arg0= 0x >> gd->arch.ipi[1].arg1= 0x >> >> We should not jump to 0x0 to handle an interrupt. > > Can you explain why K210 be affected by it ? I have been running U-Boot on the MaixDuino. Without this patch secondary_hart_loop() is reached only once. With the patch it is reached several thousand times. I would not expect NULL to contain any code that should be executed by the secondary hart. See doc/board/sipeed/maix.rst: AddressSize Description == = === 0x 0x1000debug 0x1000 0x1000rom 0x0200 0xC000clint > >> >> Signed-off-by: Heinrich Schuchardt >> --- >> arch/riscv/lib/smp.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c index >> ac22136314..d725fa32e8 100644 >> --- a/arch/riscv/lib/smp.c >> +++ b/arch/riscv/lib/smp.c >> @@ -96,6 +96,8 @@ void handle_ipi(ulong hart) >> return; >> } >> >> + if (!smp_function) >> + return; >> smp_function(hart, gd->arch.ipi[hart].arg0, >> gd->arch.ipi[hart].arg1); } > > I remember Sean add this check in > [v10,14/21] riscv: Clean up IPI initialization code > . And I ask him to remove. > https://patchwork.ozlabs.org/project/uboot/patch/20200503024637.327733-15-sean...@gmail.com/ Your comment was: "Please remove the sanity check. If zero address is the intended jump point, then system will work abnormal." The only place where gd->arch.ipi[hart].addr is set is: arch/riscv/lib/smp.c:53 send_ipi_many(): gd->arch.ipi[reg].addr = ipi->addr; send_ipi_many() is only called in smp_call_function(). So the line smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1); can only work if smp_function() has been called before this point at any time. The start code only calls it in spl_secondary_hart_stack_gd_setup(). Why do we call handle_ipi() on the secondary hart at all? Where do you expect it to jump if U-Boot is the first binary loaded? Even if spl_secondary_hart_stack_gd_setup() has initialized the jump address to secondary_hart_relocate(), do we want the secondary hart to execute it again and again? Best regards Heinrich
Re: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched on and off"
On Tuesday 11 August 2020 08:39:24 Faiz Abbas wrote: > Pali, Peng, > > On 10/08/20 6:25 am, Peng Fan wrote: > > Faiz, Jean > > > >> Subject: [PATCH] Revert "mmc: disable UHS modes if Vcc cannot be switched > >> on and off" > > > > Got time to take a look? > > > > When this issue was reported in the last thread, Pali said that he was unable > to get > prints because of the constant reboot loops? Shouldn't it be easy to put > while(1) > at different points in this execution and see which step causes the reboot > loop? In May in that last thread I wrote details which I was able to gather: Month ago I was able to detect that problem is somewhere in function mmc_set_ios() from mmc.c file. I put long debug line prior and also after mmc_set_ios() call. And it was printed only prior. Not after. So I think NULL pointer dereference is in mmc_set_ios() function. I could try with that while(1) loop to print detailed log message and read/capture it. But what information for debugging you need? Or what do you want to print which could help you?
Re: OpenBSI and U-Boot
On Mon, Aug 10, 2020 at 10:30 PM Heinrich Schuchardt wrote: > > On 8/11/20 3:55 AM, Rick Chen wrote: > > Hi Heinrich > > > >> Am 9. August 2020 22:08:23 MESZ schrieb Atish Patra > >> : > >>> On Sat, Aug 8, 2020 at 9:17 AM Heinrich Schuchardt > >>> wrote: > > On 8/8/20 5:32 PM, Sean Anderson wrote: > > On 8/8/20 10:59 AM, Heinrich Schuchardt wrote: > >> Hello Anup, > >> > >> I have looking at you OpenSBI code firmware/payloads/test_head.S. > >>> Here > > > > I think the real start is in firmware/fw_base.S. From there, > >>> secondary > > harts loop first in _wait_relocate_copy_done, and then in > > _wait_for_boot_hart, and then they execute the next stage via > > _start_warm and sbi_init. > > > >> like in U-Boot's common/spl/spl_opensbi.c you put all but one hart > >>> in to > >> an enless loop (hang). > > > > As far as I can tell, U-Boot has all harts execute the next stage > >>> when > > SMP is enabled. smp_call_function has all harts execute that > >>> function. > > U-Boot can only run on one hart. Are the other harts trapped in > secondary_hart_loop()? How do we ensure that an UEFI payload does not > overwrite this memory location? > > >>> > >>> If you are booting Linux, U-Boot runs in S-mode and SMP is disabled. > >> > >> Would that also hold true on the Kendryte K210? For all what can see the > >> secondary hart enters U-Boot and is only restrained by WFI and otherwise > >> kept in an endless loop. > >> > >> I am wondering if that endless loop needs to be marked as reserved memory > >> for Linux. > > > > Currently if U-Boot run in S-Mode, SMP is disable, there will exist > > OpenSBI version compatible issue. > > You shall use OpenSBI v0.7 with HSM, thus it will trap the other harts > > in OpenSBI and only main hart will jump to kernel from U-Boot proper. > > > > Thanks, > > Rick > > > > HSM is described here: > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#hart-state-management-extension-extension-id-0x48534d-hsm > > Currently the Kendryte K210 has no SPL. So OpenSBI would be running > before U-Boot. > > Will OpenSBI v0.7 by itself stop the other harts or do we need to call > sbi_hart_stop() in U-Boot? Unfortunately opensbi/README.md and > riscv-sbi.adoc both leave this open. > OpenSBI will put all non-booting harts into wfi in sbi_hsm_wait https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_hsm.c#L119 The S-mode OS is required to call sbi_hsm_start for all non-booting harts so that they enter S-mode. Are you planning to add HSM extension just for Kendryte ? > Best regards > > Heinrich > > >> > >>> All memory regions containing OpenSBI code are reserved. Thus, U-Boot > >>> won't touch that. > >>> U-Boot also marks the run time services memory region as reserved as > >>> well. > >>> Thus, Linux kernel won't touch any of those memory regions either. > >>> > spl_secondary_hart_stack_gd_setup() can jump to hang() if the call to > secondary_hart_relocate() fails. > > > > >> > >> When Linux boots via UEFI it will wake up the extra harts after > >> ExitBootServices(). So I assume we should define function hang() > >>> in > >> lib/hang.c as __efi_runtime to avoid seeing it overwritten by the > >>> EFI > >> payload. > >> > >> @Ard: > >> Does Linux take care of the hanging harts and redirect them to its > >>> own > >> routine before SetVirtualAddressMap()? Otherwise anything could > >>> happen. > >> > >> On the Kendryte K210 we don't have SPL. So we will not boot in the > >> sequence SPL->OpenSBI->U-Boot but OpenSBI->U-Boot. Does this imply > >>> that > >> we have to implement the hart lottery at the entry point of main > >>> U-Boot > >> in this case? > > > > Isn't the hart lottery already implemented for U-Boot? E.g. around > >>> line > > 100 of arch/riscv/cpu/start.S. > > Thanks for the hint. > > > > > On another note, does Linux support S-Mode NOMMU? I was under the > > impression that NOMMU implied M-Mode (or the other way around). > > Have a look at > > > >>> https://linuxplumbersconf.org/event/4/contributions/386/attachments/298/502/RISC-V-NOMMU-Linux-Plumbers-2019.pdf > > Best regards > > Heinrich > >> > -- Regards, Atish
[PATCH 1/2] rockchip: dts: rk3399-evb: add sdmmc node
The sdmmc node is missing after the dts sync patch:
167efc2c7a arm64: dts: rk3399: Sync v5.7-rc1 from Linux
But we still need it for boot from SD card, so add it.
Signed-off-by: Kever Yang
---
arch/arm/dts/rk3399-evb-u-boot.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi
b/arch/arm/dts/rk3399-evb-u-boot.dtsi
index 1be54feacc..8056dc843e 100644
--- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
@@ -37,3 +37,16 @@
dr_mode = "host";
status = "okay";
};
+
+ {
+ u-boot,dm-pre-reloc;
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ cd-gpios = < 7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <15000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_clk _cmd _bus4>;
+ status = "okay";
+};
--
2.25.1
[PATCH 2/2] rockchip: config: evb-rk3399: Add rockchip dwmmc support
This enable support for SD card on evb-rk3399. Signed-off-by: Kever Yang --- configs/evb-rk3399_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index 612a8e4e98..3dda91ac03 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -30,6 +30,7 @@ CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_SF_DEFAULT_SPEED=2000 -- 2.25.1
Re: [PATCH] pci: layerscape: Fix spurious writes and panic
Hi Tom, Hi Priyanka, Am 2020-08-04 00:16, schrieb Michael Walle: The fdt_fixup_pcie_ls() scans all PCI devices and assumes that all PCI root devices are layerscape PCIe controllers. Unfortunately, this is not true for the LS1028A. There is one additional static PCI root complex (this contains the networking devices) which has nothing to do with the layerscape PCIe controllers. On recent U-Boot versions this results in the following panic: "Synchronous Abort" handler, esr 0x9644 elr: 9602fa04 lr : 9602f9f4 (reloc) elr: fbd73a04 lr : fbd739f4 x0 : 008002000101 x1 : x2 : fbde9000 x3 : 0001 x4 : x5 : 0030 x6 : fbdbd460 x7 : fbb3d3a0 x8 : 0002 x9 : 000c x10: ffe8 x11: 0006 x12: 0001869f x13: 0a2c x14: fbb3d2cc x15: x16: 0001 x17: x18: fbb3fda0 x19: 0800 x20: x21: 0001f000 x22: 0800 x23: 0009 x24: fbdc3c1b x25: fbdc28e5 x26: fbdcc008 x27: fbdc16e2 x28: 0f00 x29: fbb3d3a0 Code: 394072a1 f94006a0 3441 5ac00a94 (b8336814) Resetting CPU ... This bug already existed in former versions, but the spurious write was never trapped, because the destination address was a valid address (by pure luck). Can we get this into the -rc ? -michael
Re: [PATCH v2] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined
Hi Tom,
Hi Pali,
(added Pali because of the Nokia RX51 issue)
On 07.08.20 21:21, Tom Rini wrote:
On Thu, Jul 30, 2020 at 12:51:10PM +0200, Stefan Roese wrote:
Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") &
commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"),
CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default).
It makes no sense to still carry code that is guarded with
"#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes
all these unreferenced code paths.
Also complete remove bi_memstart & bi_memsize from the board-info
struct. As now bi_dram[] is always enabled and should be used instead.
This removes the redundant varriables.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
Cc: Tom Rini
Cc: Ramon Fried
Cc: Simon Glass
Cc: Michal Simek
Reviewed-by: Daniel Schwierzeck
I don't see quite how, but this is breaking running
test/nokia_rx51_test.sh (or, my fixup of this to apply to current master
was wrong, and is what's breaking the test). Please rebase and confirm
that test passes as well, thanks!
I've checked the issue with nokia_rx51_test.sh and could not find any
issues in the patch. My assumption now is, that the very old Linux
kernel (2.6.28) that is used in this Nokia test, still uses the bd_info
struct in Linux to pass the memory information (via bd_memstart &
bi_memsize), as was also done in the very old PowerPC days. With this
patch now and the removal of these fields from bd_info, this might
explain why this kernel does not boot any more (no output on the serial
console at all).
Pali, could you please check if my assumption is correct here? And if
yes, could please switch the test to using a newer kernel version? Or
remove the Linux kernel booting from the test?
I've pushed the latest patch version into this branch (based on top of
the latest TOT):
https://gitlab.denx.de/u-boot/custodians/u-boot-marvell/-/commits/remove-config-nr-dram-banks-v3-2020-08-11
The failing Azure CI report can be found here:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=20=results
A working Azure report is here for comparison:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=18=results
Thanks,
Stefan
Re: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi()
Hi Heinrich > From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > Sent: Tuesday, August 11, 2020 11:57 AM > To: Rick Jian-Zhi Chen(陳建志) > Cc: Sean Anderson; Lukas Auer; Simon Glass; Anup Patel; Daniel Schwierzeck; > u-boot@lists.denx.de; Heinrich Schuchardt > Subject: [PATCH 1/1] riscv: don't jump to 0x0 in handle_ipi() > > At least on the Kendryte K210: > > gd->arch.available_harts= 0x0003 arch.ipi[0].addr= > gd->0x arch.ipi[0].arg0= 0x > gd->arch.ipi[0].arg1= 0x arch.ipi[1].addr= > gd->0x arch.ipi[1].arg0= 0x > gd->arch.ipi[1].arg1= 0x > > We should not jump to 0x0 to handle an interrupt. Can you explain why K210 be affected by it ? > > Signed-off-by: Heinrich Schuchardt > --- > arch/riscv/lib/smp.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c index > ac22136314..d725fa32e8 100644 > --- a/arch/riscv/lib/smp.c > +++ b/arch/riscv/lib/smp.c > @@ -96,6 +96,8 @@ void handle_ipi(ulong hart) > return; > } > > + if (!smp_function) > + return; > smp_function(hart, gd->arch.ipi[hart].arg0, gd->arch.ipi[hart].arg1); > } I remember Sean add this check in [v10,14/21] riscv: Clean up IPI initialization code . And I ask him to remove. https://patchwork.ozlabs.org/project/uboot/patch/20200503024637.327733-15-sean...@gmail.com/ Thanks, Rick > > -- > 2.28.0
