date:20240212


On 2024-02-13 00:33, Marek Vasut wrote:

On 2/12/24 22:10, Dragan Simic wrote:

On 2024-02-12 21:19, Marek Vasut wrote:

On 2/12/24 14:41, Shantur Rathore wrote:
On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore  
wrote:
On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  
wrote:

On 2024-02-08 15:17, Dragan Simic wrote:

On 2024-02-08 15:10, Shantur Rathore wrote:

On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
wrote:

On 2024-02-08 14:33, Marek Vasut wrote:

On 2/8/24 12:30, Shantur Rathore wrote:
On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  
wrote:

On 2/7/24 11:23, Shantur Rathore wrote:

USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.

Resetting only when hub is USB 3.0 fixes it.


It would be good to include as many details about the faulty 
hardware

in
the commit message as possible, so that when someone else 
runs into

this, they would have all that information available.


Tested-by: Andre Przywara 

Signed-off-by: Shantur Rathore 
---

    common/usb_hub.c | 6 --
    1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
usb_hub_device *hub)

    debug("enabling power on all ports\n");
    for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, 
USB_PORT_FEAT_RESET);

- debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ if (usb_hub_is_superspeed(dev)) {


Should this condition be "all which are lower than 
superspeed"

instead ,
so when the next generation of USB comes, this problem won't 
trigger

?

What does Linux do btw ?


As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859

which is
   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; 
//

USB_HUB_PR_SS = 3

This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155

We can change the check to be  bDeviceProtocol > 2 but who 
knows if

things change in the newer version of spec.
I am open to suggestions.


Please just include the ^ in the commit description. Use link 
to

git.kernel.org , not some mirror . This is extremely useful
information and, well, you already wrote the V2 commit message
addition in this answer.


Shantur, if that would be easier or quicker for you, I can 
write

a quite detailed patch description for you, in exchange for a
"Helped-by" tag in the v2 patch submission. :)


That would be really kind of you Dragan.


Sure, I'll write the summary and send it over.

I am down with the flu so that would really help me as my brain 
is

working at 15% capacity.


Oh, I'm really sorry to hear that. :(  I hope you'll get better
soon, and I know very well what's it like;  I've also been sick
recently, as a result of some kind of flu that unfortunately 
found

its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity.  I'm still not back to
exactly 100%. :/

I really hope you'll recover much faster.


I hope you're feeling better.

Below are the patch subject and description that I prepared for 
you,

please have a look.

--- >8 - >8 - >8 - >8 
---

[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only

Additional testing of the changes introduced in commit 
33e06dcbe57a

("common:
usb-hub: Reset hub port before scanning") revealed that some USB 
3.0

flash


I think it was a USB 2.0 drive that didn't work on the USB 2.0 
port.


drives didn't work in U-Boot on some Allwinner SoCs that support 
USB 2.0

only.
More precisely, some tested USB 3.0 flash drives failed to be 
detected

and
work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports 
USB

2.0
only, while the same USB flash drives worked just fine on a Pine64 
H64

with
Allwinner H6 SoC, which supports both USB 2.0 and 3.0.

Resetting USB 3.0 hubs only has been tested to work as expected,
resolving
the previous issues on the Allwinner H616, while not introducing 
any new

issues on other Allwinner SoCs.  Thus, let's fix it that way.

According to the USB 3.0 specification, resetting a USB 3.0 port 
is

required
when an attached USB device transitions between different states, 
such

as
when it resumes from suspend.  Though, the Linux kernel performs
additional
USB 3.0 port resets upon initial USB device attachment, presumably 
to

ensure
proper state of the USB 3.0 hub port and proper USB mode 
negotiation

during
the initial USB device attachment and enumeration.

Such USB port resets don't seem to exist for USB 2.0 hubs, 
according the

USB
2.0 specification.  The resets seem to be added to the USB 3.0
specification
as part

Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub

2024-02-12 Thread Marek Vasut


On 2/12/24 22:10, Dragan Simic wrote:

Hello Marek, Andre and Shantur,

On 2024-02-12 21:19, Marek Vasut wrote:

On 2/12/24 14:41, Shantur Rathore wrote:

On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore  wrote:
On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  
wrote:

On 2024-02-08 15:17, Dragan Simic wrote:

On 2024-02-08 15:10, Shantur Rathore wrote:

On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
wrote:

On 2024-02-08 14:33, Marek Vasut wrote:

On 2/8/24 12:30, Shantur Rathore wrote:

On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  wrote:

On 2/7/24 11:23, Shantur Rathore wrote:

USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.

Resetting only when hub is USB 3.0 fixes it.


It would be good to include as many details about the faulty 
hardware

in
the commit message as possible, so that when someone else 
runs into

this, they would have all that information available.


Tested-by: Andre Przywara 

Signed-off-by: Shantur Rathore 
---

    common/usb_hub.c | 6 --
    1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
usb_hub_device *hub)

    debug("enabling power on all ports\n");
    for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, 
USB_PORT_FEAT_RESET);

- debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ if (usb_hub_is_superspeed(dev)) {


Should this condition be "all which are lower than superspeed"
instead ,
so when the next generation of USB comes, this problem won't 
trigger

?

What does Linux do btw ?


As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859

which is
   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
USB_HUB_PR_SS = 3

This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155

We can change the check to be  bDeviceProtocol > 2 but who 
knows if

things change in the newer version of spec.
I am open to suggestions.


Please just include the ^ in the commit description. Use link to
git.kernel.org , not some mirror . This is extremely useful
information and, well, you already wrote the V2 commit message
addition in this answer.


Shantur, if that would be easier or quicker for you, I can write
a quite detailed patch description for you, in exchange for a
"Helped-by" tag in the v2 patch submission. :)


That would be really kind of you Dragan.


Sure, I'll write the summary and send it over.


I am down with the flu so that would really help me as my brain is
working at 15% capacity.


Oh, I'm really sorry to hear that. :(  I hope you'll get better
soon, and I know very well what's it like;  I've also been sick
recently, as a result of some kind of flu that unfortunately found
its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity.  I'm still not back to
exactly 100%. :/

I really hope you'll recover much faster.


I hope you're feeling better.

Below are the patch subject and description that I prepared for you,
please have a look.

--- >8 - >8 - >8 - >8 ---
[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only

Additional testing of the changes introduced in commit 33e06dcbe57a
("common:
usb-hub: Reset hub port before scanning") revealed that some USB 3.0
flash


I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.

drives didn't work in U-Boot on some Allwinner SoCs that support 
USB 2.0

only.
More precisely, some tested USB 3.0 flash drives failed to be detected
and
work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
2.0
only, while the same USB flash drives worked just fine on a Pine64 H64
with
Allwinner H6 SoC, which supports both USB 2.0 and 3.0.

Resetting USB 3.0 hubs only has been tested to work as expected,
resolving
the previous issues on the Allwinner H616, while not introducing 
any new

issues on other Allwinner SoCs.  Thus, let's fix it that way.

According to the USB 3.0 specification, resetting a USB 3.0 port is
required
when an attached USB device transitions between different states, such
as
when it resumes from suspend.  Though, the Linux kernel performs
additional
USB 3.0 port resets upon initial USB device attachment, presumably to
ensure
proper state of the USB 3.0 hub port and proper USB mode negotiation
during
the initial USB device attachment and enumeration.

Such USB port resets don't seem to exist for USB 2.0 hubs, 
according the

USB
2.0 specification.  The resets seem to be added to the USB 3.0
specification
as part of the port and device mode negotiation.

[PATCH 1/1] rng: eliminate common.h include from RNG drivers

Usage of common.h is deprecated.

* Remove common.h from RNG drivers.
* Sort includes.
* Add time.h to sandbox driver.
* Add linux/types.h to rng.h to provide size_t.

Signed-off-by: Heinrich Schuchardt 
---
 drivers/rng/arm_rndr.c | 3 +--
 drivers/rng/iproc_rng200.c | 3 +--
 drivers/rng/meson-rng.c| 1 -
 drivers/rng/msm_rng.c  | 5 ++---
 drivers/rng/npcm_rng.c | 1 -
 drivers/rng/optee_rng.c| 2 --
 drivers/rng/rng-uclass.c   | 1 -
 drivers/rng/rockchip_rng.c | 6 +++---
 drivers/rng/sandbox_rng.c  | 3 +--
 drivers/rng/smccc_trng.c   | 1 -
 drivers/rng/stm32_rng.c| 4 +---
 include/rng.h  | 2 ++
 12 files changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/rng/arm_rndr.c b/drivers/rng/arm_rndr.c
index 4512330e68..bf54aec4f1 100644
--- a/drivers/rng/arm_rndr.c
+++ b/drivers/rng/arm_rndr.c
@@ -9,11 +9,10 @@
 
 #define LOG_CATEGORY UCLASS_RNG
 
-#include 
 #include 
-#include 
 #include 
 #include 
+#include 
 
 #define DRIVER_NAME"arm-rndr"
 
diff --git a/drivers/rng/iproc_rng200.c b/drivers/rng/iproc_rng200.c
index 85ac15bf9c..4c49aa9e44 100644
--- a/drivers/rng/iproc_rng200.c
+++ b/drivers/rng/iproc_rng200.c
@@ -5,11 +5,10 @@
  * Driver for Raspberry Pi hardware random number generator
  */
 
-#include 
 #include 
-#include 
 #include 
 #include 
+#include 
 
 #define usleep_range(a, b) udelay((b))
 
diff --git a/drivers/rng/meson-rng.c b/drivers/rng/meson-rng.c
index fd2988e91b..49037d1165 100644
--- a/drivers/rng/meson-rng.c
+++ b/drivers/rng/meson-rng.c
@@ -5,7 +5,6 @@
  * Driver for Amlogic hardware random number generator
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/rng/msm_rng.c b/drivers/rng/msm_rng.c
index 29e7354ece..658c153d3e 100644
--- a/drivers/rng/msm_rng.c
+++ b/drivers/rng/msm_rng.c
@@ -9,12 +9,11 @@
  * Based on Linux driver
  */
 
-#include 
 #include 
-#include 
 #include 
-#include 
 #include 
+#include 
+#include 
 
 /* Device specific register offsets */
 #define PRNG_DATA_OUT  0x
diff --git a/drivers/rng/npcm_rng.c b/drivers/rng/npcm_rng.c
index 70c1c032b6..3922acad5b 100644
--- a/drivers/rng/npcm_rng.c
+++ b/drivers/rng/npcm_rng.c
@@ -3,7 +3,6 @@
  * Copyright (c) 2022 Nuvoton Technology Corp.
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/rng/optee_rng.c b/drivers/rng/optee_rng.c
index 410dfc053f..f692681022 100644
--- a/drivers/rng/optee_rng.c
+++ b/drivers/rng/optee_rng.c
@@ -4,8 +4,6 @@
  */
 #define LOG_CATEGORY UCLASS_RNG
 
-#include 
-
 #include 
 #include 
 #include 
diff --git a/drivers/rng/rng-uclass.c b/drivers/rng/rng-uclass.c
index 53108e1b31..06ddfa14ac 100644
--- a/drivers/rng/rng-uclass.c
+++ b/drivers/rng/rng-uclass.c
@@ -5,7 +5,6 @@
 
 #define LOG_CATEGORY UCLASS_RNG
 
-#include 
 #include 
 #include 
 
diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
index 705b424cf3..ce5cbee30a 100644
--- a/drivers/rng/rockchip_rng.c
+++ b/drivers/rng/rockchip_rng.c
@@ -2,14 +2,14 @@
 /*
  * Copyright (c) 2020 Fuzhou Rockchip Electronics Co., Ltd
  */
+
+#include 
+#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
 
 #define RK_HW_RNG_MAX 32
 
diff --git a/drivers/rng/sandbox_rng.c b/drivers/rng/sandbox_rng.c
index cc5e1f6e25..071a3228e8 100644
--- a/drivers/rng/sandbox_rng.c
+++ b/drivers/rng/sandbox_rng.c
@@ -3,11 +3,10 @@
  * Copyright (c) 2019, Linaro Limited
  */
 
-#include 
 #include 
 #include 
 #include 
-
+#include 
 #include 
 
 static int sandbox_rng_read(struct udevice *dev, void *data, size_t len)
diff --git a/drivers/rng/smccc_trng.c b/drivers/rng/smccc_trng.c
index 3a4bb33941..5bb7ebe8a4 100644
--- a/drivers/rng/smccc_trng.c
+++ b/drivers/rng/smccc_trng.c
@@ -5,7 +5,6 @@
 
 #define LOG_CATEGORY UCLASS_RNG
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/rng/stm32_rng.c b/drivers/rng/stm32_rng.c
index c397b4d95c..61d5ed6158 100644
--- a/drivers/rng/stm32_rng.c
+++ b/drivers/rng/stm32_rng.c
@@ -5,16 +5,14 @@
 
 #define LOG_CATEGORY UCLASS_RNG
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-
-#include 
 #include 
 #include 
 
diff --git a/include/rng.h b/include/rng.h
index 37af554363..87e26f5647 100644
--- a/include/rng.h
+++ b/include/rng.h
@@ -6,6 +6,8 @@
 #if !defined _RNG_H_
 #define _RNG_H_
 
+#include 
+
 struct udevice;
 
 /**
-- 
2.43.0

Re: [PATCH 2/2] rockchip: rk3399: Update stack and bss addresses

2024-02-12 Thread Jonas Karlman

Hi Quentin,

On 2024-02-12 12:51, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 2/12/24 12:08, Jonas Karlman wrote:
>> Hi Quentin,
>>
>> On 2024-02-12 11:37, Quentin Schulz wrote:
>>> Hi Jonas,
>>>
>>> On 2/12/24 01:59, Jonas Karlman wrote:
 With the stack and text base used by U-Boot SPL and proper on RK3399
 there is a high likelihood of overlapping when U-Boot proper + FDT nears
 1 MiB in size.

 Currently the following memory layout is used:
 - 0x (@0 MiB): U-Boot SPL text base
 - 0x0004 (@256 KiB): TF-A
 - 0x0020 (@2 MiB): U-Boot proper text base
 - 0x0030 (@3 MiB): U-Boot proper init stack
 - 0x0040 (@4 MiB): U-Boot SPL init stack
 - 0x0040 (@4 MiB): U-Boot SPL bss
 - 0x0200 (@64 MiB): U-Boot SPL reloc stack
 - 0x0840 (@132 MiB): optional OPTEE

 SPL load TF-A, U-Boot proper and optional OPTEE after SPL stack has
 relocated, meaning that there is room for close to 2 MiB (@2-4 MiB).
 However, the initial stack used by U-Boot proper is limiting the size
 of U-Boot proper + FDT to below 1 MiB (@2-3 MiB).

 Instead change to use the following memory layout:
 - 0x (@0 MiB): U-Boot SPL text base
 - 0x0004 (@256 KiB): TF-A
 - 0x0020 (@2 MiB): U-Boot proper text base
 - 0x0040 (@4 MiB): U-Boot SPL init stack
 - 0x0080 (@8 MiB): U-Boot proper init stack (changed)
 - 0x0200 (@32 MiB): U-Boot SPL bss (changed)
 - 0x0400 (@64 MiB): U-Boot SPL reloc stack
 - 0x0840 (@132 MiB): optional OPTEE

 This should leave room for loading and running a U-Boot proper close
 to 6 MiB (@2-8 MiB) in size. When U-Boot proper has relocated is should
 be possible to use @2-132 MiB and @164 MiB+ for scripts, kernel etc.

 With the moved SPL reloc stack it is also possible to use a much larger
 malloc area in SPL, e.g. using default SPL_STACK_R_MALLOC_SIMPLE_LEN.

 Signed-off-by: Jonas Karlman 
>>>
>>> Do we not need to update memory addresses in the environment as well?
>>
>> The addresses in environment is to my knowledge only used in U-Boot
>> proper after relocation. And at that time we should be free to use @2+
>> MiB up to somewhere close to gd ram_top/relocaddr. The optional Rockchip
>> OPTEE blobb may occupy @132-164 MiB, but I do not think loading OPTEE
>> blobs works as-is, so that may not be a big issue.
>>
> 
> Upstream OP-TEE OS seems to support RK3399, c.f. 
> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/platform_rk3399.c
> 
> I cannot say whether it works, I have no knowledge of any of our 
> customers using it (but that predates my joining Theobroma, so maybe 
> long time customers do use it?). However, we do use an upstream-based 
> OP-TEE OS for one of our PX30-based boards, so I would say Rockchip's 
> OP-TEE OS is not the only option so we shouldn't just disregard this 
> location in RAM... especially since ramdisk_addr_r starts at 96MiB. But 
> since we're not changing that location people who would have this 
> issue, would have encountered the issue by now already (provided they 
> load a ramdisk bigger than 36MiB). So let's ignore that one actually :)

See my other mail, upstream OP-TEE OS seem to use @768 MiB and should
not cause issues.

Anyone trying to use Rockchip's OP-TEE OS blobs will get an error from
binman, so trying to get that working will already involve customization.

> 
>> So to my knowledge we do not need to update any of the memory addresses
>> in the environment as well.
>>
>>>
>>> scriptaddr=0x0050
>>>
>>> This is at 5MiB if I'm not mistaken?
>>>
>>> Basically everything in include/configs/rk3399_common.h in
>>> ENV_MEM_LAYOUT_SETTINGS needs to be updated to be located after 164MiB?
>>>
>>> Did I misunderstand something? I find it weird the current values seems
>>> to be located after U-Boot SPL bss and that e.g.
>>>
>>> kernel_addr_r=0x0208
>>>
>>> is at 32.5MiB, and with U-Boot SPL reloc stack currently at 64MiB... a
>>> 31.5+MiB kernel Image would mess up the data there? (what do we need it
>>> for BTW once in U-boot proper after relocation?).
>>
>> After SPL has jumped to TF-A and U-boot proper any memory used by SPL
>> can be overwritten/used for something else.
>>
>> My understanding is as follow:
>> - SPL always need access to bss
>> - SPL need access to init stack until it has relocated to reloc stack
>> - SPL will load FIT images using the reloc stack, at this time only
>>SPL code, bss and reloc stack matters
>> - U-boot proper will use its init stack until it has relocated to end
>>of memory. Until U-Boot proper has relocated it will use init stack
>> - We could use same memory position for init stack for SPL and proper,
>>e.g. SPL_SHARES_INIT_SP_ADDR=y without any issue
>> - After U-Boot proper has relocated we should be free to use @2+ MiB
>>up to where U-Boot proper was relocated.
>>
> 
> Not sure how

Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub


Hello Marek, Andre and Shantur,

On 2024-02-12 21:19, Marek Vasut wrote:

On 2/12/24 14:41, Shantur Rathore wrote:

On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore  wrote:
On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  
wrote:

On 2024-02-08 15:17, Dragan Simic wrote:

On 2024-02-08 15:10, Shantur Rathore wrote:

On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
wrote:

On 2024-02-08 14:33, Marek Vasut wrote:

On 2/8/24 12:30, Shantur Rathore wrote:
On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  
wrote:

On 2/7/24 11:23, Shantur Rathore wrote:

USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.

Resetting only when hub is USB 3.0 fixes it.


It would be good to include as many details about the faulty 
hardware

in
the commit message as possible, so that when someone else runs 
into

this, they would have all that information available.


Tested-by: Andre Przywara 

Signed-off-by: Shantur Rathore 
---

common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
usb_hub_device *hub)

debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, 
USB_PORT_FEAT_RESET);

- debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ if (usb_hub_is_superspeed(dev)) {


Should this condition be "all which are lower than superspeed"
instead ,
so when the next generation of USB comes, this problem won't 
trigger

?

What does Linux do btw ?


As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859

which is
   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
USB_HUB_PR_SS = 3

This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155

We can change the check to be  bDeviceProtocol > 2 but who 
knows if

things change in the newer version of spec.
I am open to suggestions.


Please just include the ^ in the commit description. Use link to
git.kernel.org , not some mirror . This is extremely useful
information and, well, you already wrote the V2 commit message
addition in this answer.


Shantur, if that would be easier or quicker for you, I can write
a quite detailed patch description for you, in exchange for a
"Helped-by" tag in the v2 patch submission. :)


That would be really kind of you Dragan.


Sure, I'll write the summary and send it over.


I am down with the flu so that would really help me as my brain is
working at 15% capacity.


Oh, I'm really sorry to hear that. :(  I hope you'll get better
soon, and I know very well what's it like;  I've also been sick
recently, as a result of some kind of flu that unfortunately found
its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity.  I'm still not back to
exactly 100%. :/

I really hope you'll recover much faster.


I hope you're feeling better.

Below are the patch subject and description that I prepared for you,
please have a look.

--- >8 - >8 - >8 - >8 
---

[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only

Additional testing of the changes introduced in commit 33e06dcbe57a
("common:
usb-hub: Reset hub port before scanning") revealed that some USB 3.0
flash


I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.

drives didn't work in U-Boot on some Allwinner SoCs that support USB 
2.0

only.
More precisely, some tested USB 3.0 flash drives failed to be 
detected

and
work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports 
USB

2.0
only, while the same USB flash drives worked just fine on a Pine64 
H64

with
Allwinner H6 SoC, which supports both USB 2.0 and 3.0.

Resetting USB 3.0 hubs only has been tested to work as expected,
resolving
the previous issues on the Allwinner H616, while not introducing any 
new

issues on other Allwinner SoCs.  Thus, let's fix it that way.

According to the USB 3.0 specification, resetting a USB 3.0 port is
required
when an attached USB device transitions between different states, 
such

as
when it resumes from suspend.  Though, the Linux kernel performs
additional
USB 3.0 port resets upon initial USB device attachment, presumably 
to

ensure
proper state of the USB 3.0 hub port and proper USB mode negotiation
during
the initial USB device attachment and enumeration.

Such USB port resets don't seem to exist for USB 2.0 hubs, according 
the

USB
2.0 specification.  The resets seem to be added to the USB 3.0
specification
as part of the port and device mode negotiation.

The Linux kernel also resets

Re: [PATCH] doc: fix mistyped "env flags" command


On 2/11/24 21:18, Thomas Weißschuh wrote:

Signed-off-by: Thomas Weißschuh 


Reviewed-by: Heinrich Schuchardt 


---
  doc/usage/cmd/env.rst | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/usage/cmd/env.rst b/doc/usage/cmd/env.rst
index a859e32798cb..a7e21693a672 100644
--- a/doc/usage/cmd/env.rst
+++ b/doc/usage/cmd/env.rst
@@ -350,7 +350,7 @@ edit
  exists
  CONFIG_CMD_ENV_EXISTS

-flsgs
+flags
  CONFIG_CMD_ENV_FLAGS

  erase

---
base-commit: d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8
change-id: 20240211-doc-flsgs-31daddb198ec

Best regards,

Re: [PATCH 2/2] rockchip: rk3399: Update stack and bss addresses

2024-02-12 Thread Jonas Karlman

On 2024-02-12 14:15, Jerome Forissier wrote:
> On 2/12/24 12:51, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 2/12/24 12:08, Jonas Karlman wrote:
>>> Hi Quentin,
>>>
>>> On 2024-02-12 11:37, Quentin Schulz wrote:
 Hi Jonas,

 On 2/12/24 01:59, Jonas Karlman wrote:
> With the stack and text base used by U-Boot SPL and proper on RK3399
> there is a high likelihood of overlapping when U-Boot proper + FDT nears
> 1 MiB in size.
>
> Currently the following memory layout is used:
> - 0x (@0 MiB): U-Boot SPL text base
> - 0x0004 (@256 KiB): TF-A
> - 0x0020 (@2 MiB): U-Boot proper text base
> - 0x0030 (@3 MiB): U-Boot proper init stack
> - 0x0040 (@4 MiB): U-Boot SPL init stack
> - 0x0040 (@4 MiB): U-Boot SPL bss
> - 0x0200 (@64 MiB): U-Boot SPL reloc stack
> - 0x0840 (@132 MiB): optional OPTEE
>
> SPL load TF-A, U-Boot proper and optional OPTEE after SPL stack has
> relocated, meaning that there is room for close to 2 MiB (@2-4 MiB).
> However, the initial stack used by U-Boot proper is limiting the size
> of U-Boot proper + FDT to below 1 MiB (@2-3 MiB).
>
> Instead change to use the following memory layout:
> - 0x (@0 MiB): U-Boot SPL text base
> - 0x0004 (@256 KiB): TF-A
> - 0x0020 (@2 MiB): U-Boot proper text base
> - 0x0040 (@4 MiB): U-Boot SPL init stack
> - 0x0080 (@8 MiB): U-Boot proper init stack (changed)
> - 0x0200 (@32 MiB): U-Boot SPL bss (changed)
> - 0x0400 (@64 MiB): U-Boot SPL reloc stack
> - 0x0840 (@132 MiB): optional OPTEE
>
> This should leave room for loading and running a U-Boot proper close
> to 6 MiB (@2-8 MiB) in size. When U-Boot proper has relocated is should
> be possible to use @2-132 MiB and @164 MiB+ for scripts, kernel etc.
>
> With the moved SPL reloc stack it is also possible to use a much larger
> malloc area in SPL, e.g. using default SPL_STACK_R_MALLOC_SIMPLE_LEN.
>
> Signed-off-by: Jonas Karlman 

 Do we not need to update memory addresses in the environment as well?
>>>
>>> The addresses in environment is to my knowledge only used in U-Boot
>>> proper after relocation. And at that time we should be free to use @2+
>>> MiB up to somewhere close to gd ram_top/relocaddr. The optional Rockchip
>>> OPTEE blobb may occupy @132-164 MiB, but I do not think loading OPTEE
>>> blobs works as-is, so that may not be a big issue.
>>>
>>
>> Upstream OP-TEE OS seems to support RK3399, c.f. 
>> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/platform_rk3399.c
> 
> It does indeed. I run the quarterly release tests on a RockPi4B. We record 
> which
> platforms have been tested in the commit description for each release tag. For
> example, see [1].
> 
> In the configuration I test, OP-TEE is loaded at 0x3000 and uses 32MB (for
> some reason the Linux DT reserves 36MB but I don't think it matters much).
> 
> [1] 
> https://github.com/OP-TEE/optee_os/commit/18b424c23aa5a798dfe2e4d20b4bde3919dc4e99
> 

Great, I did a quick test run with OP-TEE on my ROCK 4SE and seem to
work, see short boot log below.

Also good to know that it runs at @768 MiB, we should be able to use
@2-768 MiB for loading kernel, initrd etc in U-Boot proper with open
source OP-TEE.

---
U-Boot SPL 2024.04-rc1 (Feb 12 2024 - 20:39:20 +)
Trying to boot from MMC2
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
## Checking hash(es) for Image atf-4 ... sha256+ OK
load_simple_fit: Skip load 'atf-5': image size is 0!
## Checking hash(es) for Image tee-1 ... sha256+ OK
NOTICE:  BL31: v2.10.2(release):
NOTICE:  BL31: Built : 20:23:10, Feb 12 2024
INFO:GICv3 with legacy support detected.
INFO:ARM GICv3 driver initialized in EL3
INFO:Maximum SPI INTID supported: 287
INFO:plat_rockchip_pmu_init(1624): pd status 3e
INFO:BL31: Initializing runtime services
INFO:BL31: Initializing BL32
I/TC:
I/TC: No non-secure external DT
I/TC: OP-TEE version: Unknown_4.1 (gcc version 10.5.0 (Ubuntu 
10.5.0-1ubuntu1~22.04)) #2 Mon Feb 12 20:37:33 UTC 2024 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check 
https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: Primary CPU switching to normal world boot
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x20
INFO:SPSR = 0x3c9


U-Boot 2024.04-rc1 (Feb 12 2024 - 20:39:20 +)

SoC: Rockchip rk3399
Reset cause: POR

Re: Pull request doc-2024-04-rc2

On Mon, Feb 12, 2024 at 09:18:09PM +0100, Heinrich Schuchardt wrote:

> Dear Tom,
> 
> The following changes since commit 91c37c4a20db24a4fc1d565c70035072d355cce0:
> 
>   Merge tag 'u-boot-imx-master-20240212' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2024-02-12 09:26:20
> -0500)
> 
> are available in the Git repository at:
> 
>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> tags/doc-2024-04-rc2
> 
> for you to fetch changes up to 2eb39c9adafb4210c6bcf0aed75a34493c098c8e:
> 
>   doc/develop/codingstyle.rst: Clarify include section (2024-02-12
> 17:35:34 +0100)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH 1/4] board: beagle: beagleplay: Enable 32k crystal

2024-02-12 Thread Robert Nelson

On Mon, Feb 12, 2024 at 9:53 AM Nishanth Menon  wrote:
>
> Enable the external 32k crystal similar to that found on other
> production AM62X board. The trim settings for the crystal is board
> dependent, so the sequences tend to be board specific. Since this is
> a configuration that needs to be done prior to DM managing the system
> and all other muxes get set, do the same from R5 context.
>
> Signed-off-by: Nishanth Menon 

Tested-by: Robert Nelson 

Yay, WiFi (wl18xx) now works on the BeaglePay with these 4 patches on
top of v2024.01-rc1

debian@BeaglePlay-57:~$ dmesg | grep wl
[1.892839] wlan_en: supplied by vdd_3v3
[8.437425] systemd[1]: Expecting device
sys-subsystem-net-devices-wlan0.device -
/sys/subsystem/net/devices/wlan0...
[   13.241739] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[   13.246116] wlcore: WARNING Detected unconfigured mac address in
nvs, derive from fuse instead.
[   13.246155] wlcore: WARNING This default nvs file can be removed
from the file system
[   13.253088] wlcore: loaded
[   13.788451] wlcore: using inverted interrupt logic: 2
[   13.842464] wlcore: PHY firmware version: Rev 8.2.0.0.243
[   13.938371] wlcore: firmware booted (Rev 8.9.0.0.83)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

Re: [PATCH v2 2/3] arm: mvebu: helios4_defconfig: enable setexpr command

2024-02-12 Thread Dennis Gilmore

I am curious about your use cases for this. as ideally all systems use the
generic distro boot paths and it is not needed for them.

Dennis

On Fri, Feb 2, 2024 at 9:13 AM Josua Mayer  wrote:

> Update the helios4 defconfig to enable the 'setexpr' command, which is a
> default and useful for various complex boot-scripts.
>
> Signed-off-by: Josua Mayer 
> ---
>  configs/helios4_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
> index 04194004f0..73f0638344 100644
> --- a/configs/helios4_defconfig
> +++ b/configs/helios4_defconfig
> @@ -44,7 +44,6 @@ CONFIG_CMD_MMC=y
>  CONFIG_CMD_PCI=y
>  CONFIG_CMD_SPI=y
>  CONFIG_CMD_USB=y
> -# CONFIG_CMD_SETEXPR is not set
>  CONFIG_CMD_TFTPPUT=y
>  CONFIG_CMD_CACHE=y
>  CONFIG_CMD_TIME=y
>
> --
> 2.35.3
>
>

-- 
Dennis Gilmore
Senior Manager Systems Enablement OpenShift Development

Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub

2024-02-12 Thread Marek Vasut


On 2/12/24 14:41, Shantur Rathore wrote:

On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore  wrote:


Thanks Dragan,

On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  wrote:


Hello Shantur,

On 2024-02-08 15:17, Dragan Simic wrote:

On 2024-02-08 15:10, Shantur Rathore wrote:

On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
wrote:

On 2024-02-08 14:33, Marek Vasut wrote:

On 2/8/24 12:30, Shantur Rathore wrote:

On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  wrote:

On 2/7/24 11:23, Shantur Rathore wrote:

USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.

Resetting only when hub is USB 3.0 fixes it.


It would be good to include as many details about the faulty hardware
in
the commit message as possible, so that when someone else runs into
this, they would have all that information available.


Tested-by: Andre Przywara 

Signed-off-by: Shantur Rathore 
---

common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
usb_hub_device *hub)

debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ if (usb_hub_is_superspeed(dev)) {


Should this condition be "all which are lower than superspeed"
instead ,
so when the next generation of USB comes, this problem won't trigger
?

What does Linux do btw ?


As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859

which is
   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
USB_HUB_PR_SS = 3

This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155

We can change the check to be  bDeviceProtocol > 2 but who knows if
things change in the newer version of spec.
I am open to suggestions.


Please just include the ^ in the commit description. Use link to
git.kernel.org , not some mirror . This is extremely useful
information and, well, you already wrote the V2 commit message
addition in this answer.


Shantur, if that would be easier or quicker for you, I can write
a quite detailed patch description for you, in exchange for a
"Helped-by" tag in the v2 patch submission. :)


That would be really kind of you Dragan.


Sure, I'll write the summary and send it over.


I am down with the flu so that would really help me as my brain is
working at 15% capacity.


Oh, I'm really sorry to hear that. :(  I hope you'll get better
soon, and I know very well what's it like;  I've also been sick
recently, as a result of some kind of flu that unfortunately found
its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity.  I'm still not back to
exactly 100%. :/

I really hope you'll recover much faster.


I hope you're feeling better.

Below are the patch subject and description that I prepared for you,
please have a look.

--- >8 - >8 - >8 - >8 ---
[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only

Additional testing of the changes introduced in commit 33e06dcbe57a
("common:
usb-hub: Reset hub port before scanning") revealed that some USB 3.0
flash


I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.


drives didn't work in U-Boot on some Allwinner SoCs that support USB 2.0
only.
More precisely, some tested USB 3.0 flash drives failed to be detected
and
work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
2.0
only, while the same USB flash drives worked just fine on a Pine64 H64
with
Allwinner H6 SoC, which supports both USB 2.0 and 3.0.

Resetting USB 3.0 hubs only has been tested to work as expected,
resolving
the previous issues on the Allwinner H616, while not introducing any new
issues on other Allwinner SoCs.  Thus, let's fix it that way.

According to the USB 3.0 specification, resetting a USB 3.0 port is
required
when an attached USB device transitions between different states, such
as
when it resumes from suspend.  Though, the Linux kernel performs
additional
USB 3.0 port resets upon initial USB device attachment, presumably to
ensure
proper state of the USB 3.0 hub port and proper USB mode negotiation
during
the initial USB device attachment and enumeration.

Such USB port resets don't seem to exist for USB 2.0 hubs, according the
USB
2.0 specification.  The resets seem to be added to the USB 3.0
specification
as part of the port and device mode negotiation.

The Linux kernel also resets USB 3.0 (i.e. SuperSpeed) hubs only, as
visible
in file

[PATCH v2] cmd: add FDT setup for bootelf by flag

2024-02-12 Thread Maxim Moskalets

Added the ability to use FDT for ELF applications, required to run some OS. To 
make FDT setup, you need to set the -d fdt_addr_r cmd option for bootelf command

Signed-off-by: Maxim Moskalets 

Cc: Tom Rini 
---

 cmd/elf.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/cmd/elf.c b/cmd/elf.c
index b7b9f506a5..adf8536909 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -38,6 +38,8 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, char 
* const[]),
 /* Interpreter command to boot an arbitrary ELF image from memory */
 int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
+   struct bootm_headers img = {0};
+   unsigned long fdt_addr = 0; /* Address of the FDT */
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
char *sload = NULL;
@@ -46,13 +48,23 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
/* Consume 'bootelf' */
argc--; argv++;
 
-   /* Check for flag. */
+   /* Check for [-p|-s] flag. */
if (argc >= 1 && (argv[0][0] == '-' && \
(argv[0][1] == 'p' || argv[0][1] == 's'))) {
sload = argv[0];
/* Consume flag. */
argc--; argv++;
}
+
+   /* Check for [-d fdt_addr_r] option. */
+   if ((argc >= 2) && (argv[0][0] == '-') && (argv[0][1] == 'd')) {
+   if (strict_strtoul(argv[1], 16, _addr) == -EINVAL)
+   return CMD_RET_USAGE;
+   /* Consume option. */
+   argc -= 2;
+   argv += 2;
+   }
+
/* Check for address. */
if (argc >= 1 && strict_strtoul(argv[0], 16, ) != -EINVAL) {
/* Consume address */
@@ -68,6 +80,14 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
else
addr = load_elf_image_shdr(addr);
 
+   if (fdt_addr) {
+   printf("## Setting up FDT at 0x%08lx ...\n", fdt_addr);
+   flush();
+
+   if (image_setup_libfdt(, (void *)fdt_addr, NULL))
+   return 1;
+   }
+
if (!env_get_autostart())
return rcode;
 
@@ -298,7 +318,7 @@ int do_bootvx(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
 U_BOOT_CMD(
bootelf, CONFIG_SYS_MAXARGS, 0, do_bootelf,
"Boot from an ELF image in memory",
-   "[-p|-s] [address]\n"
+   "[-p|-s] [-d fdt_addr_r] [address]\n"
"\t- load ELF image at [address] via program headers (-p)\n"
"\t  or via section headers (-s)"
 );
-- 
2.39.2

Pull request doc-2024-04-rc2


Dear Tom,

The following changes since commit 91c37c4a20db24a4fc1d565c70035072d355cce0:

  Merge tag 'u-boot-imx-master-20240212' of
https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2024-02-12 09:26:20
-0500)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-efi.git
tags/doc-2024-04-rc2

for you to fetch changes up to 2eb39c9adafb4210c6bcf0aed75a34493c098c8e:

  doc/develop/codingstyle.rst: Clarify include section (2024-02-12
17:35:34 +0100)


Pull request doc-2024-04-rc2

Documenation:

* Fix and extend utf8_to_utf32_stream() documentation
* Fix rendering of OpenSBI logo in VisionFive 2 description
* Document imxrt1170-evk board
* codingstyle.rst: Clarify include section

UEFI:

* simplify error message in efi_disk_create_raw()


Heinrich Schuchardt (2):
  doc: board: starfive: fix rendering of OpenSBI logo
  efi_loader: simplify error message in efi_disk_create_raw()

Janne Grunau (1):
  lib: charset: Fix and extend utf8_to_utf32_stream() documentation

Jesse Taube (1):
  doc: imx: imxrt1170: Document imxrt1170-evk board

Tom Rini (1):
  doc/develop/codingstyle.rst: Clarify include section

 doc/board/nxp/imxrt1170-evk.rst| 50
++
 doc/board/nxp/index.rst|  1 +
 doc/board/starfive/visionfive2.rst | 10 
 doc/develop/codingstyle.rst| 23 +-
 include/charset.h  | 14 +--
 lib/efi_loader/efi_disk.c  |  3 ++-
 6 files changed, 81 insertions(+), 20 deletions(-)
 create mode 100644 doc/board/nxp/imxrt1170-evk.rst

Re: [PATCH v2] net: designware: Support high memory nodes

On Sat, 02 Dec 2023 10:39:49 +0100, Nils Le Roux wrote:

> Some platforms (such as the Lichee Pi 4A) have their dwmac device
> addressable only in high memory space. Storing the node's base address
> on 32 bits is not possible in such case.
> 
> Use platform's physical address type to store the base address.
> 
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH v2] net: designware: Support high memory nodes

On Mon, Feb 12, 2024 at 07:56:40PM +, Andre Przywara wrote:
> On Mon, 12 Feb 2024 13:40:31 -0500
> Tom Rini  wrote:
> 
> > On Sat, Feb 10, 2024 at 05:37:03PM +, Andre Przywara wrote:
> > 
> > > On Mon, 4 Dec 2023 01:09:30 +
> > > Andre Przywara  wrote:
> > > 
> > > Hi Joe, Ramon, Tom,
> > > 
> > > for some reason patchwork put this on my plate, but it looks like
> > > genuine network code to me, and the problem definitely doesn't affect
> > > sunxi.
> > > As tagged below, I am happy with this change, so if there are no
> > > objections, can one of you take this patch, please?  
> > 
> > I believe I delegated it to you since Ramon doesn't often have time to
> > put together a PR, and since it seems otherwise fine and relevant to
> > platforms you're the custodian for, I was fine with you grabbing it. But
> > yes, I can pick it up directly instead.
> 
> Ah, that's fine, I just didn't know and didn't want to interfere with
> any other ongoing merges. I am preparing a pull request for this
> week, and can surely put in there, unless you want to beat me to it.

I've already thrown it through CI just now, so no big deal.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2] net: designware: Support high memory nodes

2024-02-12 Thread Andre Przywara

On Mon, 12 Feb 2024 13:40:31 -0500
Tom Rini  wrote:

> On Sat, Feb 10, 2024 at 05:37:03PM +, Andre Przywara wrote:
> 
> > On Mon, 4 Dec 2023 01:09:30 +
> > Andre Przywara  wrote:
> > 
> > Hi Joe, Ramon, Tom,
> > 
> > for some reason patchwork put this on my plate, but it looks like
> > genuine network code to me, and the problem definitely doesn't affect
> > sunxi.
> > As tagged below, I am happy with this change, so if there are no
> > objections, can one of you take this patch, please?  
> 
> I believe I delegated it to you since Ramon doesn't often have time to
> put together a PR, and since it seems otherwise fine and relevant to
> platforms you're the custodian for, I was fine with you grabbing it. But
> yes, I can pick it up directly instead.

Ah, that's fine, I just didn't know and didn't want to interfere with
any other ongoing merges. I am preparing a pull request for this
week, and can surely put in there, unless you want to beat me to it.

Cheers,
Andre

[PATCH 03/11] board: ti: am62ax: Set fdtfile from C code instead of findfdt script

Stop using the findfdt script and switch to setting the fdtfile from
C code.

While at this, replace findfdt in environment with a warning as it is
no longer needed

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-4...@ti.com

 board/ti/am62ax/am62ax.env   |  1 -
 board/ti/am62ax/evm.c| 10 ++
 configs/am62ax_evm_a53_defconfig |  1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index a6d967e982d4..334374abb73e 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/board/ti/am62ax/evm.c b/board/ti/am62ax/evm.c
index cd3360a43029..62d3664936e7 100644
--- a/board/ti/am62ax/evm.c
+++ b/board/ti/am62ax/evm.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include "../common/fdt_ops.h"
+
 int board_init(void)
 {
return 0;
@@ -27,3 +29,11 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   ti_set_fdt_env(NULL, NULL);
+   return 0;
+}
+#endif
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 38083586a3ec..e5fcd8cc5b6f 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -24,6 +24,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
 CONFIG_BOOTSTD_FULL=y
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000
 CONFIG_SPL_PAD_TO=0x0
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-- 
2.43.0

[PATCH 10/11] board: beagle: beagleplay: Set fdtfile from C code instead of findfdt script

Stop using the findfdt script and switch to setting the fdtfile from C
code.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-11...@ti.com

 board/beagle/beagleplay/beagleplay.c   | 14 ++
 board/beagle/beagleplay/beagleplay.env |  1 -
 configs/am62x_beagleplay_a53_defconfig |  3 ++-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/board/beagle/beagleplay/beagleplay.c 
b/board/beagle/beagleplay/beagleplay.c
index 1c376dea372f..20819ecf45b4 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -27,3 +27,17 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   char fdtfile[50];
+
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+   env_set("fdtfile", fdtfile);
+
+   return 0;
+}
+#endif
diff --git a/board/beagle/beagleplay/beagleplay.env 
b/board/beagle/beagleplay/beagleplay.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleplay/beagleplay.env
+++ b/board/beagle/beagleplay/beagleplay.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/configs/am62x_beagleplay_a53_defconfig 
b/configs/am62x_beagleplay_a53_defconfig
index 0be20045a974..1f43891d10bb 100644
--- a/configs/am62x_beagleplay_a53_defconfig
+++ b/configs/am62x_beagleplay_a53_defconfig
@@ -33,7 +33,8 @@ CONFIG_AUTOBOOT_KEYED=y
 CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d seconds\n"
 CONFIG_AUTOBOOT_DELAY_STR="d"
 CONFIG_AUTOBOOT_STOP_STR=" "
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot; 
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan 
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x80c8
-- 
2.43.0

[PATCH 02/11] board: ti: common: Introduce a common fdt ops library

Introduce a common fdt operations library for basic device tree
operations that are common between various boards.

The first library to introduce here is the capability to set up
fdtfile as a standard variable as part of board identification rather
than depend on scripted ifdeffery.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-3...@ti.com

 board/ti/common/Kconfig   | 12 
 board/ti/common/Makefile  |  1 +
 board/ti/common/fdt_ops.c | 64 +++
 board/ti/common/fdt_ops.h | 42 +
 4 files changed, 119 insertions(+)
 create mode 100644 board/ti/common/fdt_ops.c
 create mode 100644 board/ti/common/fdt_ops.h

diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig
index 49edd98014ab..de44e4de2115 100644
--- a/board/ti/common/Kconfig
+++ b/board/ti/common/Kconfig
@@ -49,3 +49,15 @@ config TI_COMMON_CMD_OPTIONS
imply CMD_SPI
imply CMD_TIME
imply CMD_USB if USB
+
+config TI_FDT_FOLDER_PATH
+   string "Location of Folder path where dtb is present"
+   default "ti/davinci" if ARCH_DAVINCI
+   default "ti/keystone" if ARCH_KEYSTONE
+   default "ti/omap" if ARCH_OMAP2PLUS
+   default "ti" if ARCH_K3
+   depends on ARCH_DAVINCI || ARCH_KEYSTONE || ARCH_OMAP2PLUS || ARCH_K3
+   help
+  Folder path for kernel device tree default.
+  This is used along with fdtfile path to locate the kernel
+  device tree blob.
diff --git a/board/ti/common/Makefile b/board/ti/common/Makefile
index 26bf12e2e6d5..5ac361ba7fcf 100644
--- a/board/ti/common/Makefile
+++ b/board/ti/common/Makefile
@@ -3,3 +3,4 @@
 
 obj-${CONFIG_TI_I2C_BOARD_DETECT} += board_detect.o
 obj-${CONFIG_CMD_EXTENSION} += cape_detect.o
+obj-${CONFIG_OF_LIBFDT} += fdt_ops.o
diff --git a/board/ti/common/fdt_ops.c b/board/ti/common/fdt_ops.c
new file mode 100644
index ..eb917be9e0da
--- /dev/null
+++ b/board/ti/common/fdt_ops.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Library to support FDT file operations which are common
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include 
+#include 
+#include "fdt_ops.h"
+
+void ti_set_fdt_env(const char *board_name, struct ti_fdt_map *fdt_map)
+{
+   char *fdt_file_name = NULL;
+   char fdtfile[TI_FDT_FILE_MAX];
+
+   if (board_name) {
+   while (fdt_map) {
+   /* Check for NULL terminator in the list */
+   if (!fdt_map->board_name)
+   break;
+   if (!strncmp(fdt_map->board_name, board_name, 
TI_BOARD_NAME_MAX)) {
+   fdt_file_name = fdt_map->fdt_file_name;
+   break;
+   }
+   fdt_map++;
+   }
+   }
+
+   /* match not found OR null board_name */
+   if (!fdt_file_name) {
+   /*
+* Prioritize CONFIG_DEFAULT_FDT_FILE - if that is not defined,
+* or is empty, then use CONFIG_DEFAULT_DEVICE_TREE
+*/
+#ifdef CONFIG_DEFAULT_FDT_FILE
+   if (strlen(CONFIG_DEFAULT_FDT_FILE)) {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s",
+CONFIG_TI_FDT_FOLDER_PATH, 
CONFIG_DEFAULT_FDT_FILE);
+   } else
+#endif
+   {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, 
CONFIG_DEFAULT_DEVICE_TREE);
+   }
+   } else {
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s", 
CONFIG_TI_FDT_FOLDER_PATH,
+fdt_file_name);
+   }
+
+   env_set("fdtfile", fdtfile);
+
+   /*
+* XXX: DEPRECATION WARNING: 2 u-boot versions (2024.10).
+*
+* Maintain compatibility with downstream scripts that may be using
+* name_fdt
+*/
+   if (board_name)
+   env_set("name_fdt", fdtfile);
+   /* Also set the findfdt legacy script to warn users to stop using this 
*/
+   env_set("findfdt",
+   "echo WARN: fdtfile already set. Stop using findfdt in script");
+}
diff --git a/board/ti/common/fdt_ops.h b/board/ti/common/fdt_ops.h
new file mode 100644
index ..5d304994fb6e
--- /dev/null
+++ b/board/ti/common/fdt_ops.h
@@ -0,0 +1,42 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Library to support common device tree manipulation for TI EVMs
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#ifndef __FDT_OPS_H
+#define __FDT_OPS_H
+
+#define TI_BOARD_NAME_MAX 20
+#define TI_FDT_FILE_MAX 200
+
+/**
+ *  struct ti_fdt_map - mapping of device tree blob name to board name
+ *  @board_name:

[PATCH 05/11] board: ti: am64x: Set fdtfile from C code instead of findfdt script

We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-6...@ti.com

 board/ti/am64x/am64x.env | 9 -
 board/ti/am64x/evm.c | 8 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index efd736b99be4..9a8812d4ee54 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -2,14 +2,6 @@
 #include 
 #include 
 
-findfdt=
-   if test $board_name = am64x_gpevm; then
-   setenv name_fdt ti/k3-am642-evm.dtb; fi;
-   if test $board_name = am64x_skevm; then
-   setenv name_fdt ti/k3-am642-sk.dtb; fi;
-   if test $name_fdt = undefined; then
-   echo WARNING: Could not determine device tree to use; fi;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280 ${mtdparts}
@@ -43,7 +35,6 @@ get_fit_usb=load usb ${bootpart} ${addr_fit}
 usbboot=setenv boot usb;
setenv bootpart 0:2;
usb start;
-   run findfdt;
run init_usb;
run get_kern_usb;
run get_fdt_usb;
diff --git a/board/ti/am64x/evm.c b/board/ti/am64x/evm.c
index a7ca6be436eb..b8de69da06c5 100644
--- a/board/ti/am64x/evm.c
+++ b/board/ti/am64x/evm.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 #define board_is_am64x_gpevm() (board_ti_k3_is("AM64-GPEVM") || \
board_ti_k3_is("AM64-EVM") || \
@@ -181,6 +182,12 @@ int checkboard(void)
 }
 
 #ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_am64_evm_fdt_map[] = {
+   {"am64x_gpevm", "k3-am642-evm.dtb"},
+   {"am64x_skevm", "k3-am642-sk.dtb"},
+   { /* Sentinel. */ }
+};
+
 static void setup_board_eeprom_env(void)
 {
char *name = "am64x_gpevm";
@@ -198,6 +205,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(name, ti_am64_evm_fdt_map);
 }
 
 static void setup_serial(void)
-- 
2.43.0

[PATCH 06/11] board: ti: am65x: Set fdtfile from C code instead of findfdt script

We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-7...@ti.com

 board/ti/am65x/am65x.env | 3 ---
 board/ti/am65x/evm.c | 2 ++
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 286b9c300c05..814374d68cf0 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -5,9 +5,6 @@
 #include 
 #endif
 
-findfdt=
-   setenv name_fdt ti/k3-am654-base-board.dtb;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs ${optargs} earlycon=ns16550a,mmio32,0x0280
diff --git a/board/ti/am65x/evm.c b/board/ti/am65x/evm.c
index df209021c1b7..3109c9a2acac 100644
--- a/board/ti/am65x/evm.c
+++ b/board/ti/am65x/evm.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 #define board_is_am65x_base_board()board_ti_is("AM6-COMPROCEVM")
 
@@ -141,6 +142,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(NULL, NULL);
 }
 
 static int init_daughtercard_det_gpio(char *gpio_name, struct gpio_desc *desc)
-- 
2.43.0

[PATCH 08/11] board: ti: j721s2: Set fdtfile from C code instead of findfdt script

We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-9...@ti.com

 board/ti/j721s2/evm.c  | 8 
 board/ti/j721s2/j721s2.env | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/board/ti/j721s2/evm.c b/board/ti/j721s2/evm.c
index 1220cd84519b..5a0281d6b483 100644
--- a/board/ti/j721s2/evm.c
+++ b/board/ti/j721s2/evm.c
@@ -23,6 +23,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -114,6 +115,12 @@ int checkboard(void)
return 0;
 }
 
+static struct ti_fdt_map ti_j721s2_evm_fdt_map[] = {
+   {"j721s2", "k3-j721s2-common-proc-board.dtb"},
+   {"am68-sk", "k3-am68-sk-base-board.dtb"},
+   { /* Sentinel. */ }
+};
+
 static void setup_board_eeprom_env(void)
 {
char *name = "j721s2";
@@ -131,6 +138,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(name, ti_j721s2_evm_fdt_map);
 }
 
 static void setup_serial(void)
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 64e3d9da85f0..9a03b9f30aee 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -7,14 +7,6 @@
 #include 
 #endif
 
-default_device_tree=ti/k3-j721s2-common-proc-board.dtb
-findfdt=
-   setenv name_fdt ${default_device_tree};
-   if test $board_name = j721s2; then  \
-   setenv name_fdt ti/k3-j721s2-common-proc-board.dtb; fi;
-   if test $board_name = am68-sk; then
-   setenv name_fdt ti/k3-am68-sk-base-board.dtb; fi;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x0288
-- 
2.43.0

[PATCH 00/11] board/ti: k3 boards: Stop using findfdt

Hi,

Hopefully the last time. Apologies on the screw ups. Ran CI loop[1] to be
doubly sure that I have'nt yet again fat fingered something.

This is a wide cleanup to switch to setting fdtfile using env_set
instead of scripted magic. 'fdtfile' is expected to be set by default.
This allows the stdboot triggered efi loaders to find the correct OS
device tree file even if regular boot process is interrupted by user
intervention.

Fixes since V3:
 * fix up missing header for am62x evm (I seemed to have dropped the
   fixup somehow)

based on:
   master   e8f2404e093d Merge branch 'master-779h0-r2' of 
https://source.denx.de/u-boot/custodians/u-boot-sh

Since this impacts out of box distro support, will be great to get it as
part of 2024.04 release.

Testing (decided to retest it all): 
https://gist.github.com/nmenon/b9d49d752c27988aabdc062dcdc41e67

V3: https://lore.kernel.org/all/20240130130615.670783-1...@ti.com/
V2: https://lore.kernel.org/all/20240109191506.3820908-1...@ti.com/
V1: https://lore.kernel.org/all/20240108173301.2692332-1...@ti.com/

Nishanth Menon (11):
  board: ti: Add missing common/Kconfig references
  board: ti: common: Introduce a common fdt ops library
  board: ti: am62ax: Set fdtfile from C code instead of findfdt script
  board: ti: am62x: Set fdtfile from C code instead of findfdt script
  board: ti: am64x: Set fdtfile from C code instead of findfdt script
  board: ti: am65x: Set fdtfile from C code instead of findfdt script
  board: ti: j721e: Set fdtfile from C code instead of findfdt script
  board: ti: j721s2: Set fdtfile from C code instead of findfdt script
  board: beagle: beagleboneai64: Set fdtfile from C code instead of
findfdt script
  board: beagle: beagleplay: Set fdtfile from C code instead of findfdt
script
  include: env: ti: Drop default_findfdt

 board/beagle/beagleboneai64/beagleboneai64.c  | 14 
 .../beagle/beagleboneai64/beagleboneai64.env  |  1 -
 board/beagle/beagleplay/beagleplay.c  | 14 
 board/beagle/beagleplay/beagleplay.env|  1 -
 board/ti/am62ax/am62ax.env|  1 -
 board/ti/am62ax/evm.c | 10 +++
 board/ti/am62x/am62x.env  |  1 -
 board/ti/am62x/evm.c  | 10 +++
 board/ti/am64x/am64x.env  |  9 ---
 board/ti/am64x/evm.c  |  8 +++
 board/ti/am65x/am65x.env  |  3 -
 board/ti/am65x/evm.c  |  2 +
 board/ti/common/Kconfig   | 12 
 board/ti/common/Makefile  |  1 +
 board/ti/common/fdt_ops.c | 64 +++
 board/ti/common/fdt_ops.h | 42 
 board/ti/j721e/evm.c  |  8 +++
 board/ti/j721e/j721e.env  | 10 ---
 board/ti/j721s2/evm.c |  8 +++
 board/ti/j721s2/j721s2.env|  8 ---
 board/ti/omap3evm/Kconfig |  2 +
 board/ti/panda/Kconfig|  2 +
 board/ti/sdp4430/Kconfig  |  2 +
 configs/am62ax_evm_a53_defconfig  |  1 +
 configs/am62x_beagleplay_a53_defconfig|  3 +-
 configs/am62x_evm_a53_defconfig   |  1 +
 configs/j721e_beagleboneai64_a72_defconfig|  3 +-
 include/env/ti/default_findfdt.env| 12 
 28 files changed, 205 insertions(+), 48 deletions(-)
 create mode 100644 board/ti/common/fdt_ops.c
 create mode 100644 board/ti/common/fdt_ops.h
 delete mode 100644 include/env/ti/default_findfdt.env

[1] https://github.com/u-boot/u-boot/pull/487

base-commit: e8f2404e093daf6cc3ac2b3233e3c6770d13e371
-- 
2.43.0

[PATCH 04/11] board: ti: am62x: Set fdtfile from C code instead of findfdt script

Stop using the findfdt script and switch to setting the fdtfile from
C code.

While at this, replace findfdt in environment with a warning as it is
no longer needed

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* Add missing header file - have no idea how i dropped that fixup.. :(

V3: https://lore.kernel.org/r/20240130130615.670783-5...@ti.com

 board/ti/am62x/am62x.env|  1 -
 board/ti/am62x/evm.c| 10 ++
 configs/am62x_evm_a53_defconfig |  1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index e53a55c38fbb..9cb186c2a03c 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 88e02155ee33..b3e8680dfab2 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#include "../common/fdt_ops.h"
+
 DECLARE_GLOBAL_DATA_PTR;
 
 #if CONFIG_IS_ENABLED(SPLASH_SCREEN)
@@ -54,6 +56,14 @@ int dram_init(void)
return fdtdec_setup_mem_size_base();
 }
 
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   ti_set_fdt_env(NULL, NULL);
+   return 0;
+}
+#endif
+
 int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 457931faf210..a39b82d05a63 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -32,6 +32,7 @@ CONFIG_BOOTSTD_FULL=y
 CONFIG_BOOTSTD_DEFAULTS=y
 CONFIG_SYS_BOOTM_LEN=0x80
 CONFIG_BOOTCOMMAND="run envboot; bootflow scan -lb"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_SPL_MAX_SIZE=0x58000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x80c8
-- 
2.43.0

[PATCH 11/11] include: env: ti: Drop default_findfdt

We shouldn't need finfdt anymore. Drop the env script.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-12...@ti.com

 include/env/ti/default_findfdt.env | 12 
 1 file changed, 12 deletions(-)
 delete mode 100644 include/env/ti/default_findfdt.env

diff --git a/include/env/ti/default_findfdt.env 
b/include/env/ti/default_findfdt.env
deleted file mode 100644
index a2b51dd923bb..
--- a/include/env/ti/default_findfdt.env
+++ /dev/null
@@ -1,12 +0,0 @@
-default_device_tree=CONFIG_DEFAULT_DEVICE_TREE
-default_device_tree_arch=ti
-#ifdef CONFIG_ARM64
-findfdt=
-   setenv name_fdt ${default_device_tree_arch}/${default_device_tree}.dtb;
-   setenv fdtfile ${name_fdt}
-#else
-default_device_tree_subarch=omap
-findfdt=
-   setenv name_fdt 
${default_device_tree_arch}/${default_device_tree_subarch}/${default_device_tree}.dtb;
-   setenv fdtfile ${name_fdt}
-#endif
-- 
2.43.0

[PATCH 09/11] board: beagle: beagleboneai64: Set fdtfile from C code instead of findfdt script

Stop using the findfdt script and switch to setting the fdtfile from C
code.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-10...@ti.com

 board/beagle/beagleboneai64/beagleboneai64.c   | 14 ++
 board/beagle/beagleboneai64/beagleboneai64.env |  1 -
 configs/j721e_beagleboneai64_a72_defconfig |  3 ++-
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/board/beagle/beagleboneai64/beagleboneai64.c 
b/board/beagle/beagleboneai64/beagleboneai64.c
index c8c1c78ae5a2..c5b4ff7df47a 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.c
+++ b/board/beagle/beagleboneai64/beagleboneai64.c
@@ -28,3 +28,17 @@ int dram_init_banksize(void)
 {
return fdtdec_setup_memory_banksize();
 }
+
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+   char fdtfile[50];
+
+   snprintf(fdtfile, sizeof(fdtfile), "%s/%s.dtb",
+CONFIG_TI_FDT_FOLDER_PATH, CONFIG_DEFAULT_DEVICE_TREE);
+
+   env_set("fdtfile", fdtfile);
+
+   return 0;
+}
+#endif
diff --git a/board/beagle/beagleboneai64/beagleboneai64.env 
b/board/beagle/beagleboneai64/beagleboneai64.env
index 4f0a94a8113e..647b25d14c8e 100644
--- a/board/beagle/beagleboneai64/beagleboneai64.env
+++ b/board/beagle/beagleboneai64/beagleboneai64.env
@@ -1,5 +1,4 @@
 #include 
-#include 
 #include 
 
 name_kern=Image
diff --git a/configs/j721e_beagleboneai64_a72_defconfig 
b/configs/j721e_beagleboneai64_a72_defconfig
index 4b019fa2f30e..3f061381f06c 100644
--- a/configs/j721e_beagleboneai64_a72_defconfig
+++ b/configs/j721e_beagleboneai64_a72_defconfig
@@ -34,7 +34,8 @@ CONFIG_AUTOBOOT_PROMPT="Press SPACE to abort autoboot in %d 
seconds\n"
 CONFIG_AUTOBOOT_DELAY_STR="d"
 CONFIG_AUTOBOOT_STOP_STR=" "
 CONFIG_OF_SYSTEM_SETUP=y
-CONFIG_BOOTCOMMAND="run set_led_state_start_load;run findfdt; run envboot; 
bootflow scan -lb;run set_led_state_fail_load"
+CONFIG_BOOTCOMMAND="run set_led_state_start_load; run envboot; bootflow scan 
-lb;run set_led_state_fail_load"
+CONFIG_BOARD_LATE_INIT=y
 CONFIG_LOGLEVEL=7
 CONFIG_SPL_MAX_SIZE=0xc
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
-- 
2.43.0

[PATCH 01/11] board: ti: Add missing common/Kconfig references

Add missing board/ti/common/Kconfig references for the platforms that
missed it. The intent is for the common Kconfig to be usable across TI
reference boards as required.

Reported-by: Tom Rini 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-2...@ti.com

 board/ti/omap3evm/Kconfig | 2 ++
 board/ti/panda/Kconfig| 2 ++
 board/ti/sdp4430/Kconfig  | 2 ++
 3 files changed, 6 insertions(+)

diff --git a/board/ti/omap3evm/Kconfig b/board/ti/omap3evm/Kconfig
index 08a8aa20ae85..cd71fe083176 100644
--- a/board/ti/omap3evm/Kconfig
+++ b/board/ti/omap3evm/Kconfig
@@ -9,4 +9,6 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "omap3_evm"
 
+source "board/ti/common/Kconfig"
+
 endif
diff --git a/board/ti/panda/Kconfig b/board/ti/panda/Kconfig
index 8f277b612a45..5912f69babe2 100644
--- a/board/ti/panda/Kconfig
+++ b/board/ti/panda/Kconfig
@@ -9,4 +9,6 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
default "omap4_panda"
 
+source "board/ti/common/Kconfig"
+
 endif
diff --git a/board/ti/sdp4430/Kconfig b/board/ti/sdp4430/Kconfig
index 36f185282166..65e9107bc1b0 100644
--- a/board/ti/sdp4430/Kconfig
+++ b/board/ti/sdp4430/Kconfig
@@ -12,4 +12,6 @@ config SYS_CONFIG_NAME
 config CMD_BAT
bool "Enable board-specific battery command"
 
+source "board/ti/common/Kconfig"
+
 endif
-- 
2.43.0

[PATCH 07/11] board: ti: j721e: Set fdtfile from C code instead of findfdt script

We now can provide a map and have the standard fdtfile variable set from
code itself. This allows for bootstd to "just work".

While at this, replace findfdt in environment with a warning as it is no
longer needed.

Reviewed-by: Jonathan Humphreys 
Reviewed-by: Roger Quadros 
Signed-off-by: Nishanth Menon 
---
Changes since V3:
* No change

V3: https://lore.kernel.org/r/20240130130615.670783-8...@ti.com

 board/ti/j721e/evm.c |  8 
 board/ti/j721e/j721e.env | 10 --
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/board/ti/j721e/evm.c b/board/ti/j721e/evm.c
index b77cffc5ef56..9dc3ed6dfffa 100644
--- a/board/ti/j721e/evm.c
+++ b/board/ti/j721e/evm.c
@@ -16,6 +16,7 @@
 #include 
 
 #include "../common/board_detect.h"
+#include "../common/fdt_ops.h"
 
 #define board_is_j721e_som()   (board_ti_k3_is("J721EX-PM1-SOM") || \
 board_ti_k3_is("J721EX-PM2-SOM"))
@@ -353,6 +354,12 @@ static int probe_daughtercards(void)
 #endif
 
 #ifdef CONFIG_BOARD_LATE_INIT
+static struct ti_fdt_map ti_j721e_evm_fdt_map[] = {
+   {"j721e", "k3-j721e-common-proc-board.dtb"},
+   {"j721e-sk", "k3-j721e-sk.dtb"},
+   {"j7200", "k3-j7200-common-proc-board.dtb"},
+   { /* Sentinel. */ }
+};
 static void setup_board_eeprom_env(void)
 {
char *name = "j721e";
@@ -372,6 +379,7 @@ static void setup_board_eeprom_env(void)
 
 invalid_eeprom:
set_board_info_env_am6(name);
+   ti_set_fdt_env(name, ti_j721e_evm_fdt_map);
 }
 
 static void setup_serial(void)
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index cb27bf5e2b24..38bfd7d49634 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -7,16 +7,6 @@
 #include 
 #endif
 
-default_device_tree=ti/k3-j721e-common-proc-board.dtb
-findfdt=
-   setenv name_fdt ${default_device_tree};
-   if test $board_name = j721e; then
-   setenv name_fdt ti/k3-j721e-common-proc-board.dtb; fi;
-   if test $board_name = j7200; then
-   setenv name_fdt ti/k3-j7200-common-proc-board.dtb; fi;
-   if test $board_name = j721e-eaik || test $board_name = j721e-sk; then
-   setenv name_fdt ti/k3-j721e-sk.dtb; fi;
-   setenv fdtfile ${name_fdt}
 name_kern=Image
 console=ttyS2,115200n8
 args_all=setenv optargs earlycon=ns16550a,mmio32,0x0280
-- 
2.43.0

Re: [PATCH] cmd: add FDT setup for bootelf by flag

On Mon, Feb 12, 2024 at 09:41:17PM +0300, Maxim Moskalets wrote:

> Added the ability to use FDT for ELF applications, required to run some OS. 
> To make FDT setup, you need to set the elf_needed_fdt environment variable to 
> a value like y or yes.
> 
> Signed-off-by: Maxim Moskalets 
> 
> Cc: Tom Rini 
> ---
> 
>  cmd/elf.c | 14 ++
>  env/common.c  |  5 +
>  include/env.h |  7 +++
>  3 files changed, 26 insertions(+)

Is there some change compared with the last version of this patch? And,
I was thinking of how to reply to the previous one and I think my
question is why don't we just use a flag being passed to bootelf instead
of this? Doing bootelf addr -d fdt_addr seems clearer than bootelf addr1
addr2 and checking the environment.

-- 
Tom

signature.asc
Description: PGP signature

[PATCH] cmd: add FDT setup for bootelf by flag

2024-02-12 Thread Maxim Moskalets

Added the ability to use FDT for ELF applications, required to run some OS. To 
make FDT setup, you need to set the elf_needed_fdt environment variable to a 
value like y or yes.

Signed-off-by: Maxim Moskalets 

Cc: Tom Rini 
---

 cmd/elf.c | 14 ++
 env/common.c  |  5 +
 include/env.h |  7 +++
 3 files changed, 26 insertions(+)

diff --git a/cmd/elf.c b/cmd/elf.c
index b7b9f506a5..1ee86c03de 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -38,6 +38,8 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, char 
* const[]),
 /* Interpreter command to boot an arbitrary ELF image from memory */
 int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
+   struct bootm_headers img = {0};
+   unsigned long fdt_addr; /* Address of the FDT */
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
char *sload = NULL;
@@ -68,6 +70,18 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
else
addr = load_elf_image_shdr(addr);
 
+   if (env_get_elf_need_fdt()) {
+   if (argc >= 1 && strict_strtoul(argv[0], 16, _addr) != 
-EINVAL) {
+   printf("Got FDT at 0x%08lx ...\n", fdt_addr);
+
+   if (image_setup_libfdt(, (void *)fdt_addr, NULL)) {
+   printf("ERROR: Failed to process device 
tree\n");
+   return 1;
+   }
+   }
+   }
+
+
if (!env_get_autostart())
return rcode;
 
diff --git a/env/common.c b/env/common.c
index 48a565107c..8cd8558c3f 100644
--- a/env/common.c
+++ b/env/common.c
@@ -346,6 +346,11 @@ bool env_get_autostart(void)
return env_get_yesno("autostart") == 1;
 }
 
+bool env_get_elf_need_fdt(void)
+{
+   return env_get_yesno("elf_need_fdt") == 1;
+}
+
 /*
  * Look up the variable from the default environment
  */
diff --git a/include/env.h b/include/env.h
index d2a5954ded..384c312d2e 100644
--- a/include/env.h
+++ b/include/env.h
@@ -148,6 +148,13 @@ int env_get_yesno(const char *var);
  */
 bool env_get_autostart(void);
 
+/**
+ * env_get_elf_need_fdt() - Check if FDT is needed for ELF image
+ *
+ * Return: true if the "elf_need_fdt" env var exists and is set to "yes"
+ */
+bool env_get_elf_need_fdt(void);
+
 /**
  * env_set() - set an environment variable
  *
-- 
2.39.2

Re: [PATCH v2] net: designware: Support high memory nodes

On Sat, Feb 10, 2024 at 05:37:03PM +, Andre Przywara wrote:

> On Mon, 4 Dec 2023 01:09:30 +
> Andre Przywara  wrote:
> 
> Hi Joe, Ramon, Tom,
> 
> for some reason patchwork put this on my plate, but it looks like
> genuine network code to me, and the problem definitely doesn't affect
> sunxi.
> As tagged below, I am happy with this change, so if there are no
> objections, can one of you take this patch, please?

I believe I delegated it to you since Ramon doesn't often have time to
put together a PR, and since it seems otherwise fine and relevant to
platforms you're the custodian for, I was fine with you grabbing it. But
yes, I can pick it up directly instead.

-- 
Tom

signature.asc
Description: PGP signature

Re: [PATCH 3/4] arm: mach-k3: am62: Add Debounce configuration register definitions

On 09:53-20240212, Nishanth Menon wrote:
> Add the Debounce configuration registers that need to be configured one
> time for the platform for the entire SoC.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h 
> b/arch/arm/mach-k3/include/mach/am62_hardware.h
> index 54380f36e161..06fcab01a5b7 100644
> --- a/arch/arm/mach-k3/include/mach/am62_hardware.h
> +++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
> @@ -75,6 +75,9 @@
>  
>  #define CTRLMMR_MCU_RST_CTRL (MCU_CTRL_MMR0_BASE + 0x18170)
>  
> +/* Debounce register configuration */
> +#define CTRLMMR_DBOUNCE_CFG(index)   (MCU_CTRL_MMR0_BASE + 4080 + 
> (index * 4))

Grrr.. missed the fixup for 0x4080 here. will wait a couple of days for any 
other
review comments.


> +
>  #define ROM_EXTENDED_BOOT_DATA_INFO  0x43c3f1e0
>  
>  #define TI_SRAM_SCRATCH_BOARD_EEPROM_START   0x43c3
> -- 
> 2.43.0
> 

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH RFC] pinctrl: add support for HiSilicon HiSTB SoCs

2024-02-12 Thread Yang Xiwen


On 2/13/2024 1:08 AM, Tom Rini wrote:

On Tue, Feb 13, 2024 at 01:02:50AM +0800, Yang Xiwen wrote:

On 2/13/2024 12:58 AM, Tom Rini wrote:

On Tue, Feb 13, 2024 at 12:30:15AM +0800, Yang Xiwen via B4 Relay wrote:


From: Yang Xiwen 

The first supported SoC is Hi3798MV200.

Signed-off-by: Yang Xiwen 
---
This patchset adds support for HiSTB ioconfig module. The module is used
to set pins config(e.g. pull-up, pull-down, drive-strength etc..) and
pinmux.

The first supported chip is Hi3798MV200. Adding support for Hi3798CV200
should be also easy.

Below is an example of the dts node:

[snip]

Has this binding already been accepted to the kernel? Thanks.


No, I've not wrote the driver for linux yet. That's why it is RFC now. But
it is expected to be soon. I'm going to finish u-boot part first and work on
linux kernel later. After that, i can sync linux dts and bindings back to
u-boot.

How soon before you start on the Linux side of things? Given that this
wouldn't be merged for v2024.04, there's plenty of time to get that
Linux side going (or at least the binding reviewed and accepted to -next
or similar) before merging here, and for U-Boot the biggest feedback
(aside from anything checkpatch.pl may say) would be to get the binding
reviewed.

Sadly, it's not on my urgent list, since we only need to setup pinctrl 
stuff once during boot. Not even this SoC(Hi3798MV200) is supported in 
mainline Linux yet. I'm keeping working on this, but I really can't say 
how soon i can start working on Linux side. Though I can say it's not 
going to be very soon if i'm the only one who is working on this platform.


Maybe Jorge and Igor can join and speed up the process. Since 
Hi3798CV200 is supported by mainline(This SoC is used by 96boards 
poplar), writing a pinctrl driver for that SoC would receive more 
comments and reviews.


--
Regards,
Yang Xiwen

Re: [PATCH RFC] pinctrl: add support for HiSilicon HiSTB SoCs

On Tue, Feb 13, 2024 at 01:02:50AM +0800, Yang Xiwen wrote:
> On 2/13/2024 12:58 AM, Tom Rini wrote:
> > On Tue, Feb 13, 2024 at 12:30:15AM +0800, Yang Xiwen via B4 Relay wrote:
> > 
> > > From: Yang Xiwen 
> > > 
> > > The first supported SoC is Hi3798MV200.
> > > 
> > > Signed-off-by: Yang Xiwen 
> > > ---
> > > This patchset adds support for HiSTB ioconfig module. The module is used
> > > to set pins config(e.g. pull-up, pull-down, drive-strength etc..) and
> > > pinmux.
> > > 
> > > The first supported chip is Hi3798MV200. Adding support for Hi3798CV200
> > > should be also easy.
> > > 
> > > Below is an example of the dts node:
> > [snip]
> > 
> > Has this binding already been accepted to the kernel? Thanks.
> > 
> No, I've not wrote the driver for linux yet. That's why it is RFC now. But
> it is expected to be soon. I'm going to finish u-boot part first and work on
> linux kernel later. After that, i can sync linux dts and bindings back to
> u-boot.

How soon before you start on the Linux side of things? Given that this
wouldn't be merged for v2024.04, there's plenty of time to get that
Linux side going (or at least the binding reviewed and accepted to -next
or similar) before merging here, and for U-Boot the biggest feedback
(aside from anything checkpatch.pl may say) would be to get the binding
reviewed.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH RFC] pinctrl: add support for HiSilicon HiSTB SoCs

2024-02-12 Thread Yang Xiwen


On 2/13/2024 12:58 AM, Tom Rini wrote:

On Tue, Feb 13, 2024 at 12:30:15AM +0800, Yang Xiwen via B4 Relay wrote:


From: Yang Xiwen 

The first supported SoC is Hi3798MV200.

Signed-off-by: Yang Xiwen 
---
This patchset adds support for HiSTB ioconfig module. The module is used
to set pins config(e.g. pull-up, pull-down, drive-strength etc..) and
pinmux.

The first supported chip is Hi3798MV200. Adding support for Hi3798CV200
should be also easy.

Below is an example of the dts node:

[snip]

Has this binding already been accepted to the kernel? Thanks.

No, I've not wrote the driver for linux yet. That's why it is RFC now. 
But it is expected to be soon. I'm going to finish u-boot part first and 
work on linux kernel later. After that, i can sync linux dts and 
bindings back to u-boot.


--
Regards,
Yang Xiwen

Re: [PATCH RFC] pinctrl: add support for HiSilicon HiSTB SoCs

On Tue, Feb 13, 2024 at 12:30:15AM +0800, Yang Xiwen via B4 Relay wrote:

> From: Yang Xiwen 
> 
> The first supported SoC is Hi3798MV200.
> 
> Signed-off-by: Yang Xiwen 
> ---
> This patchset adds support for HiSTB ioconfig module. The module is used
> to set pins config(e.g. pull-up, pull-down, drive-strength etc..) and
> pinmux.
> 
> The first supported chip is Hi3798MV200. Adding support for Hi3798CV200
> should be also easy.
> 
> Below is an example of the dts node:
[snip]

Has this binding already been accepted to the kernel? Thanks.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] cmd: remove common.h from exception command implementations

On Mon, Feb 12, 2024 at 05:53:29PM +0100, Heinrich Schuchardt wrote:

> The common.h should not be used anymore.
> 
> Signed-off-by: Heinrich Schuchardt 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] doc/develop/codingstyle.rst: Clarify include section

On Mon, Feb 12, 2024 at 05:52:03PM +0100, Heinrich Schuchardt wrote:
> On 12.02.24 17:19, Tom Rini wrote:
> > On Sun, Feb 11, 2024 at 06:53:47PM +0100, Igor Opaniuk wrote:
> > > Hi Tom,
> > > 
> > > On Fri, Feb 9, 2024 at 3:52 PM Tom Rini  wrote:
> > > > 
> > > > Rework the section about includes slightly. We should not be using
> > > > common.h anywhere, so remove that from examples and ask people to send
> > > > patches removing it when found. Doing this also means we need to reword
> > > > other parts of this section. Be clearer about using alphabetical
> > > > ordering.
> > > > 
> > > > Signed-off-by: Tom Rini 
> > > > ---
> > > >   doc/develop/codingstyle.rst | 23 +++
> > > >   1 file changed, 11 insertions(+), 12 deletions(-)
> > > > 
> > > > diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> > > > index b25bfbd271f0..cdf5aedfcbb0 100644
> > > > --- a/doc/develop/codingstyle.rst
> > > > +++ b/doc/develop/codingstyle.rst
> > > > @@ -108,30 +108,29 @@ expected size, or that particular members appear 
> > > > at the right offset.
> > > >   Include files
> > > >   -
> > > > 
> > > > -You should follow this ordering in U-Boot. The common.h header (which 
> > > > is going
> > > > -away at some point) should always be first, followed by other headers 
> > > > in order,
> > > > -then headers with directories, then local files:
> > > > +You should follow this ordering in U-Boot. In all cases, they should 
> > > > be listed
> > > > +in alphabetical order. First comes headers which are located directly 
> > > > in our
> > > > +top-level include diretory. This excludes the common.h header file 
> > > > which is to
> > > > +be removed. Second are headers within subdirectories, Finally 
> > > > directory-local
> > > > +includes should be listed. See this example:
> > > > 
> > > >   .. code-block:: C
> > > > 
> > > > -   #include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > -   #include 
> > > > +   #include 
> > > >  #include 
> > > >  #include 
> > > >  #include "local.h"
> > > > 
> > > > -Within that order, sort your includes.
> > > > -
> > > > -It is important to include common.h first since it provides basic 
> > > > features used
> > > > -by most files, e.g. CONFIG options.
> > > > -
> > > >   For files that need to be compiled for the host (e.g. tools), you 
> > > > need to use
> > > > -``#ifndef USE_HOSTCC`` to avoid including common.h since it includes a 
> > > > lot of
> > > > -internal U-Boot things. See common/image.c for an example.
> > > > +``#ifndef USE_HOSTCC`` to avoid including U-Boot specific include 
> > > > files.  See
> > > > +common/image.c for an example.
> > > > +
> > > > +If you encounter ccode which still uses  a patch to remove 
> > > > that and
> > > nitpick: s/ccode/code/g
> > 
> > Whoops, Heinrich can you please fix when applying?
> > 
> 
> Hello Tom,
> 
> I am missing here some text about the includes that are automatically
> included, e.g.
> 
> linux/kconfig.h
> include/generated/autoconf.h
> 
> Maybe you could describe this in a future patch.

Yeah, that would be good as there's in turn a few places we do have to
manually include those files.

> We still have 4107 files including common.h. Should we have a Migration
> warning in Makefile?

checkpatch.pl already marks this as an error for new patches. In some
other threads I've talked with Simon about not wanting to script the
removal as there's some style to it (in short, the linux kernel doesn't
enforce direct #include of everything needed in every C file, so we
aren't either, so it's a matter of pulling common.h out and fixing
fallout rather than adding say errno.h everywhere first).

-- 
Tom


signature.asc
Description: PGP signature

[PATCH] cmd: remove common.h from exception command implementations

The common.h should not be used anymore.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/arm/exception.c | 1 -
 cmd/riscv/exception.c   | 1 -
 cmd/sandbox/exception.c | 1 -
 cmd/x86/exception.c | 1 -
 4 files changed, 4 deletions(-)

diff --git a/cmd/arm/exception.c b/cmd/arm/exception.c
index 522f6dff53f..98a9795b68c 100644
--- a/cmd/arm/exception.c
+++ b/cmd/arm/exception.c
@@ -5,7 +5,6 @@
  * Copyright (c) 2018, Heinrich Schuchardt 
  */
 
-#include 
 #include 
 
 static int do_unaligned(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/cmd/riscv/exception.c b/cmd/riscv/exception.c
index f38f454a0b1..14ad6c440a5 100644
--- a/cmd/riscv/exception.c
+++ b/cmd/riscv/exception.c
@@ -5,7 +5,6 @@
  * Copyright (c) 2018, Heinrich Schuchardt 
  */
 
-#include 
 #include 
 
 static int do_compressed(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/cmd/sandbox/exception.c b/cmd/sandbox/exception.c
index c082401ce6b..cfa153da260 100644
--- a/cmd/sandbox/exception.c
+++ b/cmd/sandbox/exception.c
@@ -5,7 +5,6 @@
  * Copyright (c) 2020, Heinrich Schuchardt 
  */
 
-#include 
 #include 
 
 static int do_sigsegv(struct cmd_tbl *cmdtp, int flag, int argc,
diff --git a/cmd/x86/exception.c b/cmd/x86/exception.c
index 82faaa913e5..14b6bd6f493 100644
--- a/cmd/x86/exception.c
+++ b/cmd/x86/exception.c
@@ -5,7 +5,6 @@
  * Copyright (c) 2018, Heinrich Schuchardt 
  */
 
-#include 
 #include 
 
 static int do_undefined(struct cmd_tbl *cmdtp, int flag, int argc,
-- 
2.43.0

Re: [PATCH] doc/develop/codingstyle.rst: Clarify include section


On 12.02.24 17:19, Tom Rini wrote:

On Sun, Feb 11, 2024 at 06:53:47PM +0100, Igor Opaniuk wrote:

Hi Tom,

On Fri, Feb 9, 2024 at 3:52 PM Tom Rini  wrote:


Rework the section about includes slightly. We should not be using
common.h anywhere, so remove that from examples and ask people to send
patches removing it when found. Doing this also means we need to reword
other parts of this section. Be clearer about using alphabetical
ordering.

Signed-off-by: Tom Rini 
---
  doc/develop/codingstyle.rst | 23 +++
  1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index b25bfbd271f0..cdf5aedfcbb0 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -108,30 +108,29 @@ expected size, or that particular members appear at the 
right offset.
  Include files
  -

-You should follow this ordering in U-Boot. The common.h header (which is going
-away at some point) should always be first, followed by other headers in order,
-then headers with directories, then local files:
+You should follow this ordering in U-Boot. In all cases, they should be listed
+in alphabetical order. First comes headers which are located directly in our
+top-level include diretory. This excludes the common.h header file which is to
+be removed. Second are headers within subdirectories, Finally directory-local
+includes should be listed. See this example:

  .. code-block:: C

-   #include 
 #include 
 #include 
 #include 
 #include 
-   #include 
+   #include 
 #include 
 #include 
 #include "local.h"

-Within that order, sort your includes.
-
-It is important to include common.h first since it provides basic features used
-by most files, e.g. CONFIG options.
-
  For files that need to be compiled for the host (e.g. tools), you need to use
-``#ifndef USE_HOSTCC`` to avoid including common.h since it includes a lot of
-internal U-Boot things. See common/image.c for an example.
+``#ifndef USE_HOSTCC`` to avoid including U-Boot specific include files.  See
+common/image.c for an example.
+
+If you encounter ccode which still uses  a patch to remove that and

nitpick: s/ccode/code/g


Whoops, Heinrich can you please fix when applying?



Hello Tom,

I am missing here some text about the includes that are automatically
included, e.g.

linux/kconfig.h
include/generated/autoconf.h

Maybe you could describe this in a future patch.

We still have 4107 files including common.h. Should we have a Migration
warning in Makefile?

Best regards

Heinrich

[PATCH RFC] pinctrl: add support for HiSilicon HiSTB SoCs

2024-02-12 Thread Yang Xiwen via B4 Relay

From: Yang Xiwen 

The first supported SoC is Hi3798MV200.

Signed-off-by: Yang Xiwen 
---
This patchset adds support for HiSTB ioconfig module. The module is used
to set pins config(e.g. pull-up, pull-down, drive-strength etc..) and
pinmux.

The first supported chip is Hi3798MV200. Adding support for Hi3798CV200
should be also easy.

Below is an example of the dts node:

```dts
ioconfig: pinctrl@8a21000 {
compatible = "hisilicon,hi3798mv200-ioconfig";
reg = <0x8a21000 0x180>;
#pinctrl-cells = <1>;

emmc_default: emmc-default-state {
cdata-pins {
// CDATA0-7
pins = "W20", "V20", "U20", "V19", "Y21", "W21", "V21", 
"U21";
bias-pullup;
slew-rate = <1>;

drive-strength = <8>;
function = "emmc_cdata";
};

cclk-pin {
pins = "T18";

bias-pullup;
slew-rate = <1>;

drive-strength = <8>;
function = "emmc_cclk";
};

ccmd-pin {
pins = "T20";

bias-pullup;
slew-rate = <1>;

drive-strength = <6>;
function = "emmc_ccmd";
};

reset-pin {
pins = "R20";

bias-disable;
slew-rate = <1>;

drive-strength = <1>;
function = "emmc_rst";
};

datastrobe-pin {
pins = "R21";

bias-pullup;
slew-rate;

drive-strength = <1>;
function = "emmc_datastrobe";
};
};
};
```
---
 drivers/pinctrl/Kconfig|   1 +
 drivers/pinctrl/Makefile   |   1 +
 drivers/pinctrl/hisilicon/Kconfig  |  21 ++
 drivers/pinctrl/hisilicon/Makefile |   6 +
 drivers/pinctrl/hisilicon/pinctrl-hi3798mv2x.c | 319 +
 drivers/pinctrl/hisilicon/pinctrl-histb.c  | 276 +
 drivers/pinctrl/hisilicon/pinctrl-histb.h  | 132 ++
 7 files changed, 756 insertions(+)

diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index a1d53cfbdb..d600a30492 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -346,6 +346,7 @@ endif
 
 source "drivers/pinctrl/broadcom/Kconfig"
 source "drivers/pinctrl/exynos/Kconfig"
+source "drivers/pinctrl/hisilicon/Kconfig"
 source "drivers/pinctrl/intel/Kconfig"
 source "drivers/pinctrl/mediatek/Kconfig"
 source "drivers/pinctrl/meson/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0e929d8ca0..79fb800faf 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -36,3 +36,4 @@ obj-$(CONFIG_$(SPL_)PINCTRL_STMFX)+= pinctrl-stmfx.o
 obj-y  += broadcom/
 obj-$(CONFIG_PINCTRL_ZYNQMP)   += pinctrl-zynqmp.o
 obj-$(CONFIG_PINCTRL_STARFIVE) += starfive/
+obj-$(CONFIG_PINCTRL_HISILICON)+= hisilicon/
diff --git a/drivers/pinctrl/hisilicon/Kconfig 
b/drivers/pinctrl/hisilicon/Kconfig
new file mode 100644
index 00..33c3048940
--- /dev/null
+++ b/drivers/pinctrl/hisilicon/Kconfig
@@ -0,0 +1,21 @@
+config PINCTRL_HISILICON
+   bool
+
+config PINCTRL_HISTB
+   bool "HiSilicon HiSTB pinctrl framework"
+   depends on PINCTRL
+   select PINCTRL_HISILICON
+   imply PINCONF
+   help
+ Support HiSTB SoCs IOCONFIG module
+
+menu "HiSTB pinctrl drivers"
+   depends on PINCTRL_HISTB
+
+config PINCTRL_HI3798MV2X
+   bool "HiSilicon Hi3798MV2X pinctrl driver"
+   depends on ARCH_HI3798MV2X
+   help
+ Support IOCONFIG on Hi3798MV2X SoCs
+
+endmenu
diff --git a/drivers/pinctrl/hisilicon/Makefile 
b/drivers/pinctrl/hisilicon/Makefile
new file mode 100644
index 00..5afb64d4b6
--- /dev/null
+++ b/drivers/pinctrl/hisilicon/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright 2024 (r) Yang Xiwen 
+
+obj-$(CONFIG_PINCTRL_HISTB)+= pinctrl-histb.o
+obj-$(CONFIG_PINCTRL_HI3798MV2X)   += pinctrl-hi3798mv2x.o
diff --git a/drivers/pinctrl/hisilicon/pinctrl-hi3798mv2x.c 
b/drivers/pinctrl/hisilicon/pinctrl-hi3798mv2x.c
new file mode 100644
index 00..1e0a89675a
--- /dev/null
+++ b/drivers/pinctrl/hisilicon/pinctrl-hi3798mv2x.c
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * IOCONFIG driver for Hi3798MV2x SoCs
+ *
+ * Copyright 2024 (r) Yang Xiwen 
+ */
+
+#include 
+
+#include "pinctrl-histb.h"
+
+// The sequence is important!
+enum hi3798mv2x_ioconfig_pins {
+   HI3798MV2X_Y19,
+   HI3798MV2X_W19,
+

Re: [PATCH] doc/develop/codingstyle.rst: Clarify include section

On Sun, Feb 11, 2024 at 06:53:47PM +0100, Igor Opaniuk wrote:
> Hi Tom,
> 
> On Fri, Feb 9, 2024 at 3:52 PM Tom Rini  wrote:
> >
> > Rework the section about includes slightly. We should not be using
> > common.h anywhere, so remove that from examples and ask people to send
> > patches removing it when found. Doing this also means we need to reword
> > other parts of this section. Be clearer about using alphabetical
> > ordering.
> >
> > Signed-off-by: Tom Rini 
> > ---
> >  doc/develop/codingstyle.rst | 23 +++
> >  1 file changed, 11 insertions(+), 12 deletions(-)
> >
> > diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
> > index b25bfbd271f0..cdf5aedfcbb0 100644
> > --- a/doc/develop/codingstyle.rst
> > +++ b/doc/develop/codingstyle.rst
> > @@ -108,30 +108,29 @@ expected size, or that particular members appear at 
> > the right offset.
> >  Include files
> >  -
> >
> > -You should follow this ordering in U-Boot. The common.h header (which is 
> > going
> > -away at some point) should always be first, followed by other headers in 
> > order,
> > -then headers with directories, then local files:
> > +You should follow this ordering in U-Boot. In all cases, they should be 
> > listed
> > +in alphabetical order. First comes headers which are located directly in 
> > our
> > +top-level include diretory. This excludes the common.h header file which 
> > is to
> > +be removed. Second are headers within subdirectories, Finally 
> > directory-local
> > +includes should be listed. See this example:
> >
> >  .. code-block:: C
> >
> > -   #include 
> > #include 
> > #include 
> > #include 
> > #include 
> > -   #include 
> > +   #include 
> > #include 
> > #include 
> > #include "local.h"
> >
> > -Within that order, sort your includes.
> > -
> > -It is important to include common.h first since it provides basic features 
> > used
> > -by most files, e.g. CONFIG options.
> > -
> >  For files that need to be compiled for the host (e.g. tools), you need to 
> > use
> > -``#ifndef USE_HOSTCC`` to avoid including common.h since it includes a lot 
> > of
> > -internal U-Boot things. See common/image.c for an example.
> > +``#ifndef USE_HOSTCC`` to avoid including U-Boot specific include files.  
> > See
> > +common/image.c for an example.
> > +
> > +If you encounter ccode which still uses  a patch to remove that 
> > and
> nitpick: s/ccode/code/g

Whoops, Heinrich can you please fix when applying?

-- 
Tom


signature.asc
Description: PGP signature

Re: Pull request: Please pull u-boot-imx-master-20240212

On Mon, Feb 12, 2024 at 08:01:59AM -0300, Fabio Estevam wrote:

> Hi Tom,
> 
> Please pull from u-boot-imx, thanks.
> 
> The following changes since commit d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8:
> 
>   Merge tag 'u-boot-dfu-20240209' of 
> https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-09 09:00:42 
> -0500)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
> tags/u-boot-imx-master-20240212
> 
> for you to fetch changes up to fcd377ed6480643b1f79188c7a8fb9280a211b4f:
> 
>   configs: imx93_var_som: Enable AHAB support (2024-02-10 15:16:13 -0300)
> 
> u-boot-imx-master-20240212

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 1/1] efi_driver: provide SBI based runtime system reset

On RISC-V systems system the Supervisory Binary Interface provides system
reset and poweroff. Use it at EFI runtime.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_driver/Makefile  |  1 +
 lib/efi_driver/efi_reset_riscv.c | 29 +
 lib/efi_loader/Kconfig   |  2 +-
 3 files changed, 31 insertions(+), 1 deletion(-)
 create mode 100644 lib/efi_driver/efi_reset_riscv.c

diff --git a/lib/efi_driver/Makefile b/lib/efi_driver/Makefile
index f2b6c05cc24..0da20fe91d3 100644
--- a/lib/efi_driver/Makefile
+++ b/lib/efi_driver/Makefile
@@ -9,3 +9,4 @@ obj-y += efi_uclass.o
 ifeq ($(CONFIG_PARTITIONS),y)
 obj-y += efi_block_device.o
 endif
+obj-$(CONFIG_SYSRESET_SBI) += efi_reset_riscv.o
diff --git a/lib/efi_driver/efi_reset_riscv.c b/lib/efi_driver/efi_reset_riscv.c
new file mode 100644
index 000..89b23522e95
--- /dev/null
+++ b/lib/efi_driver/efi_reset_riscv.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include 
+#include 
+
+void __efi_runtime EFIAPI efi_reset_system(enum efi_reset_type reset_type,
+  efi_status_t reset_status,
+  unsigned long data_size,
+  void *reset_data)
+{
+   register unsigned long eid asm("a7") = SBI_EXT_SRST;
+   register unsigned long fid asm("a6") = SBI_EXT_SRST_RESET;
+   register unsigned long type asm("a0");
+   register unsigned long reason asm("a1") = SBI_SRST_RESET_REASON_NONE;
+
+   switch (reset_type) {
+   case EFI_RESET_WARM:
+   type = SBI_SRST_RESET_TYPE_WARM_REBOOT;
+   break;
+   case EFI_RESET_SHUTDOWN:
+   type = SBI_SRST_RESET_TYPE_SHUTDOWN;
+   break;
+   default:
+   type = SBI_SRST_RESET_TYPE_COLD_REBOOT;
+   break;
+   }
+   asm volatile ("ecall\n"
+ : : "r" (eid), "r" (fid), "r" (type), "r" (reason));
+}
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index db5571de1d9..a7c3e05c13a 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -366,7 +366,7 @@ config EFI_HAVE_RUNTIME_RESET
bool
default y
depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET || \
-  SANDBOX || SYSRESET_X86
+  SANDBOX || SYSRESET_SBI || SYSRESET_X86
 
 config EFI_GRUB_ARM32_WORKAROUND
bool "Workaround for GRUB on 32bit ARM"
-- 
2.43.0

Re: [PATCH v2 5/6] efi_selftest: Add box drawing character selftest


On 10.02.24 13:46, Janne Grunau via B4 Relay wrote:

From: Andre Przywara 

UEFI applications rely on Unicode output capability, and might use that
for drawing pseudo-graphical interfaces using Unicode defined box
drawing characters.

Add a simple test to display the most basic box characters, which would
need to be checked manually on the screen for correctness.
To facilitate this, add a three second delay after the output at this
point.

Signed-off-by: Andre Przywara 
Suggested-by: Heinrich Schuchardt 
Signed-off-by: Janne Grunau 
---
  lib/efi_selftest/efi_selftest_textoutput.c | 20 
  1 file changed, 20 insertions(+)

diff --git a/lib/efi_selftest/efi_selftest_textoutput.c 
b/lib/efi_selftest/efi_selftest_textoutput.c
index 2aa81b0a80..cc11a22eee 100644
--- a/lib/efi_selftest/efi_selftest_textoutput.c
+++ b/lib/efi_selftest/efi_selftest_textoutput.c
@@ -33,6 +33,19 @@ static int execute(void)
const u16 text[] =
  u"\u00d6sterreich Edelwei\u00df Sm\u00f8rrebr\u00f8d Sm\u00f6rg"
  u"\u00e5s Ni\u00f1o Ren\u00e9 >\u1f19\u03bb\u03bb\u03ac\u03c2<\n";
+   const u16 boxes[] =
+u"This should render as four boxes with text\n"
+u"\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502"
+u" left top\u2502 right top \u2502\n\u251c\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502 "
+u"left bottom \u2502 right bottom  \u2502\n\u2514\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534"
+u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
+u"\u2500\u2500\u2500\u2500\u2518\n";

/* SetAttribute */
efi_st_printf("\nColor palette\n");
@@ -126,6 +139,13 @@ u"\u00e5s Ni\u00f1o Ren\u00e9 
>\u1f19\u03bb\u03bb\u03ac\u03c2<\n";
efi_st_error("OutputString failed for international chars\n");
return EFI_ST_FAILURE;
}
+   ret = con_out->output_string(con_out, boxes);
+   if (ret != EFI_ST_SUCCESS) {
+   efi_st_error("OutputString failed for box drawing chars\n");
+   return EFI_ST_FAILURE;
+   }
+   con_out->output_string(con_out, u"waiting for admiration...\n");
+   EFI_CALL(systab.boottime->stall(300));


We don't want to add any unnecessary waiting times in the unit tests. If
somebody wants to see the output, he can scroll up.

Best regards

Heinrich


efi_st_printf("\n");

return EFI_ST_SUCCESS;

[PATCH 1/4] board: beagle: beagleplay: Enable 32k crystal

Enable the external 32k crystal similar to that found on other
production AM62X board. The trim settings for the crystal is board
dependent, so the sequences tend to be board specific. Since this is
a configuration that needs to be done prior to DM managing the system
and all other muxes get set, do the same from R5 context.

Signed-off-by: Nishanth Menon 
---
 board/beagle/beagleplay/beagleplay.c | 37 
 1 file changed, 37 insertions(+)

diff --git a/board/beagle/beagleplay/beagleplay.c 
b/board/beagle/beagleplay/beagleplay.c
index 20819ecf45b4..a75b3145fa37 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -11,6 +11,8 @@
 #include 
 #include 
 
+#include 
+
 DECLARE_GLOBAL_DATA_PTR;
 
 int board_init(void)
@@ -28,6 +30,41 @@ int dram_init_banksize(void)
return fdtdec_setup_memory_banksize();
 }
 
+#ifdef CONFIG_SPL_BOARD_INIT
+
+/*
+ * Enable the 32k Crystal: needed for accurate 32k clock
+ * and external clock sources such as wlan 32k input clock
+ * supplied from the SoC to the wlan chip.
+ *
+ * The trim setup can be very highly board type specific choice of the crystal
+ * So this is done in the board file, though, in this case, no specific trim
+ * is necessary.
+ */
+static void crystal_32k_enable(void)
+{
+   /* Only mess with 32k at the start of boot from R5 */
+   if (IS_ENABLED(CONFIG_CPU_V7R)) {
+   /*
+* We have external 32k crystal, so lets enable it (0x0)
+* and disable bypass (0x0)
+*/
+   writel(0x0, MCU_CTRL_LFXOSC_CTRL);
+
+   /* Add any crystal specific TRIM needed here.. */
+
+   /* Make sure to mux the SoC 32k from the crystal */
+   writel(MCU_CTRL_DEVICE_CLKOUT_LFOSC_SELECT_VAL,
+  MCU_CTRL_DEVICE_CLKOUT_32K_CTRL);
+   }
+}
+
+void spl_board_init(void)
+{
+   crystal_32k_enable();
+}
+#endif
+
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
-- 
2.43.0

[PATCH 4/4] board: beagle: beagleplay: Configure debounce registers

Configure the debounce configuration that makes sense for BeaglePlay
usage model.

Signed-off-by: Nishanth Menon 
---
 board/beagle/beagleplay/beagleplay.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/board/beagle/beagleplay/beagleplay.c 
b/board/beagle/beagleplay/beagleplay.c
index a75b3145fa37..5640fdf41ed3 100644
--- a/board/beagle/beagleplay/beagleplay.c
+++ b/board/beagle/beagleplay/beagleplay.c
@@ -59,9 +59,33 @@ static void crystal_32k_enable(void)
}
 }
 
+static void debounce_configure(void)
+{
+   /* Configure debounce one time from R5 */
+   if (IS_ENABLED(CONFIG_CPU_V7R)) {
+   /*
+* Setup debounce time registers.
+* arbitrary values. Times are approx
+*/
+   /* 1.9ms debounce @ 32k */
+   writel(0x1, CTRLMMR_DBOUNCE_CFG(1));
+   /* 5ms debounce @ 32k */
+   writel(0x5, CTRLMMR_DBOUNCE_CFG(2));
+   /* 20ms debounce @ 32k */
+   writel(0x14, CTRLMMR_DBOUNCE_CFG(3));
+   /* 46ms debounce @ 32k */
+   writel(0x18, CTRLMMR_DBOUNCE_CFG(4));
+   /* 100ms debounce @ 32k */
+   writel(0x1c, CTRLMMR_DBOUNCE_CFG(5));
+   /* 156ms debounce @ 32k */
+   writel(0x1f, CTRLMMR_DBOUNCE_CFG(6));
+   }
+}
+
 void spl_board_init(void)
 {
crystal_32k_enable();
+   debounce_configure();
 }
 #endif
 
-- 
2.43.0

[PATCH 2/4] configs: am62x_beagleplay_r5_defconfig: Enable SPL_BOARD_INIT

Enable CONFIG_SPL_BOARD_INIT to configure the 32k crystal.

Signed-off-by: Nishanth Menon 
---
 configs/am62x_beagleplay_r5_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am62x_beagleplay_r5_defconfig 
b/configs/am62x_beagleplay_r5_defconfig
index 2f3264b7ede6..9413c859870f 100644
--- a/configs/am62x_beagleplay_r5_defconfig
+++ b/configs/am62x_beagleplay_r5_defconfig
@@ -36,6 +36,7 @@ CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x43c3b000
 CONFIG_SPL_BSS_MAX_SIZE=0x3000
 CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_BOARD_INIT=y
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_SEPARATE_BSS=y
-- 
2.43.0

[PATCH 0/4] board: beagle: Enable 32k and debounce configuration

Hi,

This is a follow up from [1] - Without the 32k crystal configuration,
wlan does'nt work. Debounce is needed for HDMI hpd gpio interrupt.

At least the 32k configuration has been done for toradex and phytec
boards, follow similar model of programming.

This series is based on master commit e8f2404e093d + the findfdt
series[2].

Nishanth Menon (4):
  board: beagle: beagleplay: Enable 32k crystal
  configs: am62x_beagleplay_r5_defconfig: Enable SPL_BOARD_INIT
  arm: mach-k3: am62: Add Debounce configuration register definitions
  board: beagle: beagleplay: Configure debounce registers

 arch/arm/mach-k3/include/mach/am62_hardware.h |  3 +
 board/beagle/beagleplay/beagleplay.c  | 61 +++
 configs/am62x_beagleplay_r5_defconfig |  1 +
 3 files changed, 65 insertions(+)

[1] https://lore.kernel.org/u-boot/20230725185253.2123433-4...@ti.com/
[2] https://lore.kernel.org/all/20240130130615.670783-1...@ti.com/
-- 
2.43.0

[PATCH 3/4] arm: mach-k3: am62: Add Debounce configuration register definitions

Add the Debounce configuration registers that need to be configured one
time for the platform for the entire SoC.

Signed-off-by: Nishanth Menon 
---
 arch/arm/mach-k3/include/mach/am62_hardware.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-k3/include/mach/am62_hardware.h 
b/arch/arm/mach-k3/include/mach/am62_hardware.h
index 54380f36e161..06fcab01a5b7 100644
--- a/arch/arm/mach-k3/include/mach/am62_hardware.h
+++ b/arch/arm/mach-k3/include/mach/am62_hardware.h
@@ -75,6 +75,9 @@
 
 #define CTRLMMR_MCU_RST_CTRL   (MCU_CTRL_MMR0_BASE + 0x18170)
 
+/* Debounce register configuration */
+#define CTRLMMR_DBOUNCE_CFG(index) (MCU_CTRL_MMR0_BASE + 4080 + 
(index * 4))
+
 #define ROM_EXTENDED_BOOT_DATA_INFO0x43c3f1e0
 
 #define TI_SRAM_SCRATCH_BOARD_EEPROM_START 0x43c3
-- 
2.43.0

Re: [PATCH v2] arm: mach-k3: Refactor QoS settings

2024-02-12 Thread Bryan Brattlof

Hey Aradhya!

On February 12, 2024 thus sayeth Aradhya Bhatia:
> Refactor common QoS code into a new common header file, and the soc
> specific setup_qos functions into a common API.
> 
> Rename $(soc)_qos_count and $(soc)_qos_data variables to qos_count and
> qos_data. When QoS settings of more SoCs are added, only one pair will
> be defined at a time, based on the config SOC_K3_$(soc).
> 
> This refactoring has been done for 2 major purposes.
> 
> - The auto-generated $(soc)_qos_data.c and $(soc)_qos.h files cannot
>   have any code that is specific to any bootloader. Those files have to
>   remain agnostic of different bootloader implementations and their
>   header files.
> 
> - The existing implementation was less than ideal and would have enabled
>   multiple $(soc)_qos_count and $(soc)_qos_data variables for all SoC
>   variants.
> 
> Signed-off-by: Aradhya Bhatia 
> ---
> 
> Change Log:
> 
>  - new in v2:
>- Move K3_QOS config to the r5/Kconfig.
> 
> Previous versions:
> 
>   - v1: https://lore.kernel.org/all/20240206085610.3226136-1-a-bhat...@ti.com/
> 

...

> diff --git a/arch/arm/mach-k3/r5/am62ax/Makefile 
> b/arch/arm/mach-k3/r5/am62ax/Makefile
> index 02a941805e9a..e4e55ce5c7dd 100644
> --- a/arch/arm/mach-k3/r5/am62ax/Makefile
> +++ b/arch/arm/mach-k3/r5/am62ax/Makefile
> @@ -4,4 +4,4 @@
>  
>  obj-y += clk-data.o
>  obj-y += dev-data.o
> -obj-y += am62a_qos_data.o
> +obj-y += am62a_qos_uboot.o

No objections from me though I am curious about the name change. Was 
there an issue with using the original am62a_qos_data.c

~Bryan

Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c


On 2024-02-12 15:21, Peter Robinson wrote:

On Mon, 12 Feb 2024 at 14:16, Dragan Simic  wrote:

On 2024-02-12 14:56, Peter Robinson wrote:
> On Fri, 9 Feb 2024 at 18:57, Dragan Simic  wrote:
>> On 2024-02-09 19:36, Mark Kettenis wrote:
>> >> Date: Fri, 09 Feb 2024 18:58:01 +0100
>> >> From: Dragan Simic 
>> >> Please, see my comments below.
>> >>
>> >> On 2024-02-09 10:50, Quentin Schulz wrote:
>> >> > From: Quentin Schulz 
>> >> >
>> >> > The functions aren't used anywhere else than in board.c, therefore,
>> >> > let's not expose them anymore at all.
>> >> >
>> >> > This merges misc.c and board.c together and removes the functions from
>> >> > the misc.h header file.
>> >>
>> >> The patches I'm going to send, which exclude the unneeded code
>> >> from the U-Boot images for the Pinebook Pro and the Pinebook Pro,
>> >> change the code that this patch moves around.
>> >>
>> >> Perhaps it would be better to have the move of the code and the
>> >> subsequent changes to it performed in a separate series, to make
>> >> checking and accepting the patches simpler as a group, and to
>> >> perhaps make it a bit more clear what actually happened to anyone
>> >> going through the repository history later.
>> >>
>> >> Thus, I was wondering would you, please, be fine with excluding
>> >> this patch from this series and letting me submit it, with proper
>> >> attribution tags, of course, as part of the series I'll submit
>> >> in the next couple of days?
>> >
>> > I'm not covinced your patches are a good idea.  Unless we're running
>> > into space constraints, or if there are noticable slowdowns in the
>> > boot process because of the extra code, I really don't see what the
>> > benefit of further differentiation between rk3399 boards would be.  It
>> > just makes testing things harder.
>>
>> Oh, I fully understand your position, but please let's also keep in
>> mind that the subject of those patches are actual devices with pretty
>> much fixed hardware configurations, instead of targeting development
>> boards whose actual hardware configurations, at least in theory,
>> depend on the user.
>>
>> In addition to preventing the unneeded code from entering the U-Boot
>> images, my patches would also prevent useless "ethaddr" and "eth1addr"
>> from appearing in the saved environments on those devices.  I think
>> that's useful and may actually prevent some confusion when the saved
>> environment is checked by the users on those devices.
>
> Maybe that code should be guarded on if the wired ethernet is enabled
> or not. Would allow one code but the ability to disable it when the
> ethernet isn't used.

Basically, we can't know for sure are the users going to supply
some DT overlays that add another Ethernet interface to an SBC,
for example a Fast Ethernet interface on RK3328-based SBCs, which
is the reason why we can't rely on the built-in DT to decide
whether to provide the stable MAC addresses or not.


That will likely not be solvable with purely an overlay, they may need
to enable drivers that aren't by default.


Sure, but from the Linux kernel's perspective, if the additional
Ethernet interface isn't going to be used in U-Boot, all the kernel
wants from U-Boot is the fixed MAC address in the DT.

By the way, I've got a hopefully neat Linux kernel patch in the
works, which will make the testing of fixed MAC addresses being
passed around correctly a bit easier.


However, it's highly unlikely that an Ethernet interface is going
to be added to a fixed-configuration device such as the Pinebook
Pro or the Pinephone.  Other than plugging in a USB Ethernet dongle,
that is, which already come with fixed MACA addresses.  Thus, not
providing stable MAC addresses should be just fine for such fixed-
configuration devices.


Don't disagree with that, which is why I did those configs like that.


Great, thanks.


>> > The smaller the number of special snow flakes, the better!
>>
>> I'd agree that having fewer special cases helps, but again, handling
>> the specifics of some devices also has its benefits.  Additionally,
>> perhaps simply the fact that those are actual devices makes them some
>> kind of special snowflakes. :)
>>
>> >> > Cc: Quentin Schulz 
>> >> > Reviewed-by: Kever Yang 
>> >> > Signed-off-by: Quentin Schulz 
>> >> > ---
>> >> >  arch/arm/include/asm/arch-rockchip/misc.h |   5 --
>> >> >  arch/arm/mach-rockchip/Makefile   |   1 -
>> >> >  arch/arm/mach-rockchip/board.c| 125
>> >> > +++
>> >> >  arch/arm/mach-rockchip/misc.c | 135
>> >> > --
>> >> >  4 files changed, 125 insertions(+), 141 deletions(-)
>> >> >
>> >> > diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
>> >> > b/arch/arm/include/asm/arch-rockchip/misc.h
>> >> > index 4155af8c3b0..ef37ff1661a 100644
>> >> > --- a/arch/arm/include/asm/arch-rockchip/misc.h
>> >> > +++ b/arch/arm/include/asm/arch-rockchip/misc.h
>> >> > @@ -6,9 +6,4 @@
>> >> >   *  Rohan Garg 
>>

Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c

On Mon, 12 Feb 2024 at 14:16, Dragan Simic  wrote:
>
> Hello Peter,
>
> On 2024-02-12 14:56, Peter Robinson wrote:
> > On Fri, 9 Feb 2024 at 18:57, Dragan Simic  wrote:
> >> On 2024-02-09 19:36, Mark Kettenis wrote:
> >> >> Date: Fri, 09 Feb 2024 18:58:01 +0100
> >> >> From: Dragan Simic 
> >> >> Please, see my comments below.
> >> >>
> >> >> On 2024-02-09 10:50, Quentin Schulz wrote:
> >> >> > From: Quentin Schulz 
> >> >> >
> >> >> > The functions aren't used anywhere else than in board.c, therefore,
> >> >> > let's not expose them anymore at all.
> >> >> >
> >> >> > This merges misc.c and board.c together and removes the functions from
> >> >> > the misc.h header file.
> >> >>
> >> >> The patches I'm going to send, which exclude the unneeded code
> >> >> from the U-Boot images for the Pinebook Pro and the Pinebook Pro,
> >> >> change the code that this patch moves around.
> >> >>
> >> >> Perhaps it would be better to have the move of the code and the
> >> >> subsequent changes to it performed in a separate series, to make
> >> >> checking and accepting the patches simpler as a group, and to
> >> >> perhaps make it a bit more clear what actually happened to anyone
> >> >> going through the repository history later.
> >> >>
> >> >> Thus, I was wondering would you, please, be fine with excluding
> >> >> this patch from this series and letting me submit it, with proper
> >> >> attribution tags, of course, as part of the series I'll submit
> >> >> in the next couple of days?
> >> >
> >> > I'm not covinced your patches are a good idea.  Unless we're running
> >> > into space constraints, or if there are noticable slowdowns in the
> >> > boot process because of the extra code, I really don't see what the
> >> > benefit of further differentiation between rk3399 boards would be.  It
> >> > just makes testing things harder.
> >>
> >> Oh, I fully understand your position, but please let's also keep in
> >> mind that the subject of those patches are actual devices with pretty
> >> much fixed hardware configurations, instead of targeting development
> >> boards whose actual hardware configurations, at least in theory,
> >> depend on the user.
> >>
> >> In addition to preventing the unneeded code from entering the U-Boot
> >> images, my patches would also prevent useless "ethaddr" and "eth1addr"
> >> from appearing in the saved environments on those devices.  I think
> >> that's useful and may actually prevent some confusion when the saved
> >> environment is checked by the users on those devices.
> >
> > Maybe that code should be guarded on if the wired ethernet is enabled
> > or not. Would allow one code but the ability to disable it when the
> > ethernet isn't used.
>
> Basically, we can't know for sure are the users going to supply
> some DT overlays that add another Ethernet interface to an SBC,
> for example a Fast Ethernet interface on RK3328-based SBCs, which
> is the reason why we can't rely on the built-in DT to decide
> whether to provide the stable MAC addresses or not.

That will likely not be solvable with purely an overlay, they may need
to enable drivers that aren't by default.

> However, it's highly unlikely that an Ethernet interface is going
> to be added to a fixed-configuration device such as the Pinebook
> Pro or the Pinephone.  Other than plugging in a USB Ethernet dongle,
> that is, which already come with fixed MACA addresses.  Thus, not
> providing stable MAC addresses should be just fine for such fixed-
> configuration devices.

Don't disagree with that, which is why I did those configs like that.

> >> > The smaller the number of special snow flakes, the better!
> >>
> >> I'd agree that having fewer special cases helps, but again, handling
> >> the specifics of some devices also has its benefits.  Additionally,
> >> perhaps simply the fact that those are actual devices makes them some
> >> kind of special snowflakes. :)
> >>
> >> >> > Cc: Quentin Schulz 
> >> >> > Reviewed-by: Kever Yang 
> >> >> > Signed-off-by: Quentin Schulz 
> >> >> > ---
> >> >> >  arch/arm/include/asm/arch-rockchip/misc.h |   5 --
> >> >> >  arch/arm/mach-rockchip/Makefile   |   1 -
> >> >> >  arch/arm/mach-rockchip/board.c| 125
> >> >> > +++
> >> >> >  arch/arm/mach-rockchip/misc.c | 135
> >> >> > --
> >> >> >  4 files changed, 125 insertions(+), 141 deletions(-)
> >> >> >
> >> >> > diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
> >> >> > b/arch/arm/include/asm/arch-rockchip/misc.h
> >> >> > index 4155af8c3b0..ef37ff1661a 100644
> >> >> > --- a/arch/arm/include/asm/arch-rockchip/misc.h
> >> >> > +++ b/arch/arm/include/asm/arch-rockchip/misc.h
> >> >> > @@ -6,9 +6,4 @@
> >> >> >   *  Rohan Garg 
> >> >> >   */
> >> >> >
> >> >> > -int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
> >> >> > -const u32 cpuid_length,
> >> >> > -u8 *cpuid);
> >> >> > -int

Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c

Hello Peter,

On 2024-02-12 14:56, Peter Robinson wrote:

On Fri, 9 Feb 2024 at 18:57, Dragan Simic  wrote:

On 2024-02-09 19:36, Mark Kettenis wrote:
>> Date: Fri, 09 Feb 2024 18:58:01 +0100
>> From: Dragan Simic 
>> Please, see my comments below.
>>
>> On 2024-02-09 10:50, Quentin Schulz wrote:
>> > From: Quentin Schulz 
>> >
>> > The functions aren't used anywhere else than in board.c, therefore,
>> > let's not expose them anymore at all.
>> >
>> > This merges misc.c and board.c together and removes the functions from
>> > the misc.h header file.
>>
>> The patches I'm going to send, which exclude the unneeded code
>> from the U-Boot images for the Pinebook Pro and the Pinebook Pro,
>> change the code that this patch moves around.
>>
>> Perhaps it would be better to have the move of the code and the
>> subsequent changes to it performed in a separate series, to make
>> checking and accepting the patches simpler as a group, and to
>> perhaps make it a bit more clear what actually happened to anyone
>> going through the repository history later.
>>
>> Thus, I was wondering would you, please, be fine with excluding
>> this patch from this series and letting me submit it, with proper
>> attribution tags, of course, as part of the series I'll submit
>> in the next couple of days?
>
> I'm not covinced your patches are a good idea.  Unless we're running
> into space constraints, or if there are noticable slowdowns in the
> boot process because of the extra code, I really don't see what the
> benefit of further differentiation between rk3399 boards would be.  It
> just makes testing things harder.

Oh, I fully understand your position, but please let's also keep in
mind that the subject of those patches are actual devices with pretty
much fixed hardware configurations, instead of targeting development
boards whose actual hardware configurations, at least in theory,
depend on the user.

In addition to preventing the unneeded code from entering the U-Boot
images, my patches would also prevent useless "ethaddr" and "eth1addr"
from appearing in the saved environments on those devices.  I think
that's useful and may actually prevent some confusion when the saved
environment is checked by the users on those devices.

Maybe that code should be guarded on if the wired ethernet is enabled
or not. Would allow one code but the ability to disable it when the
ethernet isn't used.

Basically, we can't know for sure are the users going to supply
some DT overlays that add another Ethernet interface to an SBC,
for example a Fast Ethernet interface on RK3328-based SBCs, which
is the reason why we can't rely on the built-in DT to decide
whether to provide the stable MAC addresses or not.

However, it's highly unlikely that an Ethernet interface is going
to be added to a fixed-configuration device such as the Pinebook
Pro or the Pinephone.  Other than plugging in a USB Ethernet dongle,
that is, which already come with fixed MACA addresses.  Thus, not
providing stable MAC addresses should be just fine for such fixed-
configuration devices.

> The smaller the number of special snow flakes, the better!

I'd agree that having fewer special cases helps, but again, handling
the specifics of some devices also has its benefits.  Additionally,
perhaps simply the fact that those are actual devices makes them some
kind of special snowflakes. :)

>> > Cc: Quentin Schulz 
>> > Reviewed-by: Kever Yang 
>> > Signed-off-by: Quentin Schulz 
>> > ---
>> >  arch/arm/include/asm/arch-rockchip/misc.h |   5 --
>> >  arch/arm/mach-rockchip/Makefile   |   1 -
>> >  arch/arm/mach-rockchip/board.c| 125
>> > +++
>> >  arch/arm/mach-rockchip/misc.c | 135
>> > --
>> >  4 files changed, 125 insertions(+), 141 deletions(-)
>> >
>> > diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
>> > b/arch/arm/include/asm/arch-rockchip/misc.h
>> > index 4155af8c3b0..ef37ff1661a 100644
>> > --- a/arch/arm/include/asm/arch-rockchip/misc.h
>> > +++ b/arch/arm/include/asm/arch-rockchip/misc.h
>> > @@ -6,9 +6,4 @@
>> >   *  Rohan Garg 
>> >   */
>> >
>> > -int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
>> > -const u32 cpuid_length,
>> > -u8 *cpuid);
>> > -int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length);
>> > -int rockchip_setup_macaddr(void);
>> >  void rockchip_capsule_update_board_setup(void);
>> > diff --git a/arch/arm/mach-rockchip/Makefile
>> > b/arch/arm/mach-rockchip/Makefile
>> > index 1dc92066bbf..c07bdaee4c3 100644
>> > --- a/arch/arm/mach-rockchip/Makefile
>> > +++ b/arch/arm/mach-rockchip/Makefile
>> > @@ -23,7 +23,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
>> >  # meaning "turn it off".
>> >  obj-y += boot_mode.o
>> >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
>> > -obj-$(CONFIG_MISC_INIT_R) += misc.o
>> >  endif
>> >
>> >  ifeq ($(CONFIG_TPL_BUILD),)
>> > diff --git

Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

On Mon, Feb 12, 2024 at 9:57 PM Peter Robinson  wrote:
>
> On Sat, 10 Feb 2024 at 06:32, Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > Hi folks,
> >
> > This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
> > and RK3399 so that the cpuid is read from the efuse and used to generate
> > a serial number and MAC addresses for all boards.
>
> For the series:
> Reviewed-by: Peter Robinson 

Thanks. I just sent out v2. Could you reply there as well?

Re: [PATCH v2 5/5] rockchip: nanopi-r4s: Drop ROCKCHIP_OTP


On 2024-02-12 14:51, Chen-Yu Tsai wrote:

From: Chen-Yu Tsai 

The NanoPi R4S has an RK3399 SoC, which has efuse supported by
ROCKCHIP_EFUSE, not ROCKCHIP_OTP.

Signed-off-by: Chen-Yu Tsai 


Reviewed-by: Dragan Simic 


---
 configs/nanopi-r4s-rk3399_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/nanopi-r4s-rk3399_defconfig
b/configs/nanopi-r4s-rk3399_defconfig
index f97c06412f07..50dbd7a854d4 100644
--- a/configs/nanopi-r4s-rk3399_defconfig
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_ROCKCHIP_OTP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y

Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

On Sat, 10 Feb 2024 at 06:32, Chen-Yu Tsai  wrote:
>
> From: Chen-Yu Tsai 
>
> Hi folks,
>
> This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
> and RK3399 so that the cpuid is read from the efuse and used to generate
> a serial number and MAC addresses for all boards.

For the series:
Reviewed-by: Peter Robinson 

> This stacks on top of the recent defconfig update series [1] from Jonas.
>
> [1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/
>
>
> Chen-Yu Tsai (4):
>   rockchip: rk3328: Read cpuid and generate MAC address from efuse
>   rockchip: rk3399: Read cpuid and generate MAC address from efuse
>   rockchip: rk3328: regenerate defconfigs
>   rockchip: rk3399: regenerate defconfigs
>
>  arch/arm/mach-rockchip/Kconfig| 4 
>  configs/chromebook_bob_defconfig  | 2 --
>  configs/chromebook_kevin_defconfig| 2 --
>  configs/evb-rk3328_defconfig  | 2 --
>  configs/firefly-rk3399_defconfig  | 2 --
>  configs/nanopi-r2c-plus-rk3328_defconfig  | 2 --
>  configs/nanopi-r2c-rk3328_defconfig   | 2 --
>  configs/nanopi-r2s-rk3328_defconfig   | 2 --
>  configs/nanopi-r4s-rk3399_defconfig   | 2 --
>  configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 --
>  configs/orangepi-r1-plus-rk3328_defconfig | 2 --
>  configs/pinebook-pro-rk3399_defconfig | 2 --
>  configs/pinephone-pro-rk3399_defconfig| 2 --
>  configs/puma-rk3399_defconfig | 2 --
>  configs/roc-cc-rk3328_defconfig   | 2 --
>  configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
>  configs/roc-pc-rk3399_defconfig   | 2 --
>  configs/rock-4c-plus-rk3399_defconfig | 3 ---
>  configs/rock-4se-rk3399_defconfig | 3 ---
>  configs/rock-pi-4-rk3399_defconfig| 3 ---
>  configs/rock-pi-4c-rk3399_defconfig   | 3 ---
>  configs/rock-pi-e-rk3328_defconfig| 2 --
>  configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
>  configs/rock64-rk3328_defconfig   | 2 --
>  configs/rock960-rk3399_defconfig  | 1 -
>  configs/rockpro64-rk3399_defconfig| 2 --
>  26 files changed, 4 insertions(+), 52 deletions(-)
>
> --
> 2.39.2
>

Re: [PATCH v2 09/20] rockchip: merge misc.c into board.c

On Fri, 9 Feb 2024 at 18:57, Dragan Simic  wrote:
>
> Hello Mark,
>
> On 2024-02-09 19:36, Mark Kettenis wrote:
> >> Date: Fri, 09 Feb 2024 18:58:01 +0100
> >> From: Dragan Simic 
> >> Please, see my comments below.
> >>
> >> On 2024-02-09 10:50, Quentin Schulz wrote:
> >> > From: Quentin Schulz 
> >> >
> >> > The functions aren't used anywhere else than in board.c, therefore,
> >> > let's not expose them anymore at all.
> >> >
> >> > This merges misc.c and board.c together and removes the functions from
> >> > the misc.h header file.
> >>
> >> The patches I'm going to send, which exclude the unneeded code
> >> from the U-Boot images for the Pinebook Pro and the Pinebook Pro,
> >> change the code that this patch moves around.
> >>
> >> Perhaps it would be better to have the move of the code and the
> >> subsequent changes to it performed in a separate series, to make
> >> checking and accepting the patches simpler as a group, and to
> >> perhaps make it a bit more clear what actually happened to anyone
> >> going through the repository history later.
> >>
> >> Thus, I was wondering would you, please, be fine with excluding
> >> this patch from this series and letting me submit it, with proper
> >> attribution tags, of course, as part of the series I'll submit
> >> in the next couple of days?
> >
> > I'm not covinced your patches are a good idea.  Unless we're running
> > into space constraints, or if there are noticable slowdowns in the
> > boot process because of the extra code, I really don't see what the
> > benefit of further differentiation between rk3399 boards would be.  It
> > just makes testing things harder.
>
> Oh, I fully understand your position, but please let's also keep in
> mind that the subject of those patches are actual devices with pretty
> much fixed hardware configurations, instead of targeting development
> boards whose actual hardware configurations, at least in theory,
> depend on the user.
>
> In addition to preventing the unneeded code from entering the U-Boot
> images, my patches would also prevent useless "ethaddr" and "eth1addr"
> from appearing in the saved environments on those devices.  I think
> that's useful and may actually prevent some confusion when the saved
> environment is checked by the users on those devices.

Maybe that code should be guarded on if the wired ethernet is enabled
or not. Would allow one code but the ability to disable it when the
ethernet isn't used.

> > The smaller the number of special snow flakes, the better!
>
> I'd agree that having fewer special cases helps, but again, handling
> the specifics of some devices also has its benefits.  Additionally,
> perhaps simply the fact that those are actual devices makes them some
> kind of special snowflakes. :)
>
> >> > Cc: Quentin Schulz 
> >> > Reviewed-by: Kever Yang 
> >> > Signed-off-by: Quentin Schulz 
> >> > ---
> >> >  arch/arm/include/asm/arch-rockchip/misc.h |   5 --
> >> >  arch/arm/mach-rockchip/Makefile   |   1 -
> >> >  arch/arm/mach-rockchip/board.c| 125
> >> > +++
> >> >  arch/arm/mach-rockchip/misc.c | 135
> >> > --
> >> >  4 files changed, 125 insertions(+), 141 deletions(-)
> >> >
> >> > diff --git a/arch/arm/include/asm/arch-rockchip/misc.h
> >> > b/arch/arm/include/asm/arch-rockchip/misc.h
> >> > index 4155af8c3b0..ef37ff1661a 100644
> >> > --- a/arch/arm/include/asm/arch-rockchip/misc.h
> >> > +++ b/arch/arm/include/asm/arch-rockchip/misc.h
> >> > @@ -6,9 +6,4 @@
> >> >   *  Rohan Garg 
> >> >   */
> >> >
> >> > -int rockchip_cpuid_from_efuse(const u32 cpuid_offset,
> >> > -const u32 cpuid_length,
> >> > -u8 *cpuid);
> >> > -int rockchip_cpuid_set(const u8 *cpuid, const u32 cpuid_length);
> >> > -int rockchip_setup_macaddr(void);
> >> >  void rockchip_capsule_update_board_setup(void);
> >> > diff --git a/arch/arm/mach-rockchip/Makefile
> >> > b/arch/arm/mach-rockchip/Makefile
> >> > index 1dc92066bbf..c07bdaee4c3 100644
> >> > --- a/arch/arm/mach-rockchip/Makefile
> >> > +++ b/arch/arm/mach-rockchip/Makefile
> >> > @@ -23,7 +23,6 @@ ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TPL_BUILD),)
> >> >  # meaning "turn it off".
> >> >  obj-y += boot_mode.o
> >> >  obj-$(CONFIG_ROCKCHIP_COMMON_BOARD) += board.o
> >> > -obj-$(CONFIG_MISC_INIT_R) += misc.o
> >> >  endif
> >> >
> >> >  ifeq ($(CONFIG_TPL_BUILD),)
> >> > diff --git a/arch/arm/mach-rockchip/board.c
> >> > b/arch/arm/mach-rockchip/board.c
> >> > index d5cb59c10fa..80b4514852f 100644
> >> > --- a/arch/arm/mach-rockchip/board.c
> >> > +++ b/arch/arm/mach-rockchip/board.c
> >> > @@ -1,20 +1,32 @@
> >> >  // SPDX-License-Identifier: GPL-2.0+
> >> >  /*
> >> >   * (C) Copyright 2019 Rockchip Electronics Co., Ltd.
> >> > + *
> >> > + * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> >> > + *  Rohan Garg 
> >> > + *
> >> > + * Based on puma-rk3399.c:
> >> > + *  (C) Copyright 2017

Re: [PATCH v2 04/20] rockchip: pine64: pinebook-pro: migrate to rockchip_early_misc_init_r


Hello Peter,

On 2024-02-12 14:41, Peter Robinson wrote:
On Fri, 9 Feb 2024 at 09:50, Quentin Schulz  
wrote:


From: Quentin Schulz 

Compared to the original misc_init_r from Rockchip mach code,
setup_iodomain() is added and rockchip_setup_macaddr() is not called.

It is assumed adding rockchip_setup_macaddr() back is fine.
Let's use rockchip_early_misc_init_r instead of reimplementing the 
whole

misc_init_r from Rockchip (the side effect being that
rockchip_setup_macaddr() is back).


The Pinebook Pro doesn't have onboard ethernet, nor an alias defined,
I wonder if rockchip_setup_macaddr should be gated on GMAC_ROCKCHIP or
something similar. Otherwise:


It's the same with the Pinephone Pro, plus we've got the Pinephone,
the PineTab, and the "OG" Pinebook with no Ethernet interfaces.  I've
already prepares patches that gate out the redundant code, and I'll
send them over after a bit more testing.


Reviewed-by: Peter Robinson 


Cc: Quentin Schulz 
Reviewed-by: Kever Yang 
Signed-off-by: Quentin Schulz 
---
 board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18 
++

 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c 
b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c

index 4ad780767ea..2408a367305 100644
--- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
+++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 

@@ -54,23 +53,10 @@ static void setup_iodomain(void)
rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
 }

-int misc_init_r(void)
+int rockchip_early_misc_init_r(void)
 {
-   const u32 cpuid_offset = 0x7;
-   const u32 cpuid_length = 0x10;
-   u8 cpuid[cpuid_length];
-   int ret;
-
setup_iodomain();

-   ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, 
cpuid);

-   if (ret)
-   return ret;
-
-   ret = rockchip_cpuid_set(cpuid, cpuid_length);
-   if (ret)
-   return ret;
-
-   return ret;
+   return 0;
 }
 #endif

--
2.43.0

Re: [PATCH v2 04/20] rockchip: pine64: pinebook-pro: migrate to rockchip_early_misc_init_r

2024-02-12 Thread Quentin Schulz

Hi Peter,

On 2/12/24 14:41, Peter Robinson wrote:

On Fri, 9 Feb 2024 at 09:50, Quentin Schulz  wrote:

From: Quentin Schulz 

Compared to the original misc_init_r from Rockchip mach code,
setup_iodomain() is added and rockchip_setup_macaddr() is not called.

It is assumed adding rockchip_setup_macaddr() back is fine.
Let's use rockchip_early_misc_init_r instead of reimplementing the whole
misc_init_r from Rockchip (the side effect being that
rockchip_setup_macaddr() is back).

The Pinebook Pro doesn't have onboard ethernet, nor an alias defined,
I wonder if rockchip_setup_macaddr should be gated on GMAC_ROCKCHIP or
something similar. Otherwise:

This was discussed here:

https://lore.kernel.org/u-boot/0d74e5e5482cd32d7cad714e731d4...@manjaro.org/ 
is the first message in the discussion, which raised the same question.

In short:
- gating on GMAC_ROCKCHIP is not wise,
- onboard Ethernet or not doesn't matter, it provides a sane mac address 
for any Ethernet device by default, based on the CPU ID.

Quoting Jonas:

"""
 > diff --git a/arch/arm/mach-rockchip/misc.c
 > b/arch/arm/mach-rockchip/misc.c
 > index 7d03f0c2b679..ed5bdab5a648 100644
 > --- a/arch/arm/mach-rockchip/misc.c
 > +++ b/arch/arm/mach-rockchip/misc.c
 > @@ -23,7 +23,8 @@
 >
 >   int rockchip_setup_macaddr(void)
 >   {
 > -#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
 > +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256) && \
 > +CONFIG_IS_ENABLED(GMAC_ROCKCHIP)

This would exclude any board not enabling GMAC_ROCKCHIP in U-Boot but
want a mac-address being set in DT fixup. And for newer RK35xx SoCs the
GMAC_ROCKCHIP driver is not used.

A new Kconfig option should be introduced if there is a need for some
boards to disable this.
"""

What is the actual concern of yours for pinebook-pro and this function 
now running? I think what ultimately would result from this is at worst 
the environment "polluted" with ethaddrX env variable?

Cheers,
Quentin

Re: [PATCH v2 10/20] rockchip: transform rockchip_capsule_update_board_setup into a weak function symbol

On Fri, 9 Feb 2024 at 09:50, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> There's only one user of rockchip_capsule_update_board_setup, which is
> in board.c, and only one board defines it, so instead of having a header
> only for one function symbol, let's just use a weak symbol instead.

Reviewed-by: Peter Robinson 
> Cc: Quentin Schulz 
> Reviewed-by: Kever Yang 
> Signed-off-by: Quentin Schulz 
> ---
>  arch/arm/include/asm/arch-rockchip/misc.h | 9 -
>  arch/arm/mach-rockchip/board.c| 5 -
>  2 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-rockchip/misc.h 
> b/arch/arm/include/asm/arch-rockchip/misc.h
> deleted file mode 100644
> index ef37ff1661a..000
> --- a/arch/arm/include/asm/arch-rockchip/misc.h
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -/* SPDX-License-Identifier: GPL-2.0+ */
> -/*
> - * RK3399: Architecture common definitions
> - *
> - * Copyright (C) 2019 Collabora Inc - https://www.collabora.com/
> - *  Rohan Garg 
> - */
> -
> -void rockchip_capsule_update_board_setup(void);
> diff --git a/arch/arm/mach-rockchip/board.c b/arch/arm/mach-rockchip/board.c
> index 80b4514852f..4f666aee706 100644
> --- a/arch/arm/mach-rockchip/board.c
> +++ b/arch/arm/mach-rockchip/board.c
> @@ -32,7 +32,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>
>  #if defined(CONFIG_EFI_HAVE_CAPSULE_SUPPORT) && defined(CONFIG_EFI_PARTITION)
> @@ -148,6 +147,10 @@ void set_dfu_alt_info(char *interface, char *devstr)
> env_set("dfu_alt_info", buf);
>  }
>
> +__weak void rockchip_capsule_update_board_setup(void)
> +{
> +}
> +
>  static void gpt_capsule_update_setup(void)
>  {
> int p, i, ret;
>
> --
> 2.43.0
>

Re: [PATCH v2 06/20] rockchip: pine64: rockpro64: migrate to rockchip_early_misc_init_r

On Fri, 9 Feb 2024 at 09:50, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Only setup_iodomain() differs from the original misc_init_r from
> Rockchip mach code, so let's use rockchip_early_misc_init_r instead of
> reimplementing the whole misc_init_r from Rockchip.

Reviewed-by: Peter Robinson 
> Cc: Quentin Schulz 
> Reviewed-by: Kever Yang 
> Signed-off-by: Quentin Schulz 
> ---
>  board/pine64/rockpro64_rk3399/rockpro64-rk3399.c | 20 ++--
>  1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c 
> b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> index d79084614f1..d0a694ead1d 100644
> --- a/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> +++ b/board/pine64/rockpro64_rk3399/rockpro64-rk3399.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>
>  #define GRF_IO_VSEL_BT565_SHIFT 0
>  #define PMUGRF_CON0_VSEL_SHIFT 8
> @@ -31,26 +30,11 @@ static void setup_iodomain(void)
> rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>  }
>
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>  {
> -   const u32 cpuid_offset = 0x7;
> -   const u32 cpuid_length = 0x10;
> -   u8 cpuid[cpuid_length];
> -   int ret;
> -
> setup_iodomain();
>
> -   ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -   if (ret)
> -   return ret;
> -
> -   ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -   if (ret)
> -   return ret;
> -
> -   ret = rockchip_setup_macaddr();
> -
> -   return ret;
> +   return 0;
>  }
>
>  #endif
>
> --
> 2.43.0
>

Re: [PATCH v2 05/20] rockchip: pine64: pinephone-pro: migrate to rockchip_early_misc_init_r

On Fri, 9 Feb 2024 at 09:50, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).

Same as for my comment on the Pinebook Pro, there's no wired ethernet
on these devices and the GMAC driver isn't enabled, I vaguely remember
we might have excluded rockchip_setup_macaddr because of an error but
that was some time ago.

Reviewed-by: Peter Robinson 

> Cc: Quentin Schulz 
> Reviewed-by: Kever Yang 
> Signed-off-by: Quentin Schulz 
> ---
>  .../pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c  | 17 
> ++---
>  1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c 
> b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> index b6ccbb9c1c4..de75ee329d8 100644
> --- a/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> +++ b/board/pine64/pinephone-pro-rk3399/pinephone-pro-rk3399.c
> @@ -12,7 +12,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>
>  #define GRF_IO_VSEL_BT565_GPIO2AB 1
> @@ -56,23 +55,11 @@ static void setup_iodomain(void)
> rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>  }
>
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>  {
> -   const u32 cpuid_offset = 0x7;
> -   const u32 cpuid_length = 0x10;
> -   u8 cpuid[cpuid_length];
> -   int ret;
> -
> setup_iodomain();
>
> -   ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -   if (ret)
> -   return ret;
> -
> -   ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -   if (ret)
> -   return ret;
> +   return 0;
>
> -   return ret;
>  }
>  #endif
>
> --
> 2.43.0
>

[PATCH v2 5/5] rockchip: nanopi-r4s: Drop ROCKCHIP_OTP

From: Chen-Yu Tsai 

The NanoPi R4S has an RK3399 SoC, which has efuse supported by
ROCKCHIP_EFUSE, not ROCKCHIP_OTP.

Signed-off-by: Chen-Yu Tsai 
---
 configs/nanopi-r4s-rk3399_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/nanopi-r4s-rk3399_defconfig 
b/configs/nanopi-r4s-rk3399_defconfig
index f97c06412f07..50dbd7a854d4 100644
--- a/configs/nanopi-r4s-rk3399_defconfig
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_ROCKCHIP_OTP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
-- 
2.39.2

[PATCH v2 4/5] rockchip: rk3399: regenerate defconfigs

From: Chen-Yu Tsai 

Regenerate RK3399 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
Reviewed-by: Quentin Schulz 
---
 configs/chromebook_bob_defconfig | 3 ---
 configs/chromebook_kevin_defconfig   | 3 ---
 configs/eaidk-610-rk3399_defconfig   | 1 -
 configs/evb-rk3399_defconfig | 1 -
 configs/firefly-rk3399_defconfig | 3 ---
 configs/khadas-edge-captain-rk3399_defconfig | 1 -
 configs/khadas-edge-rk3399_defconfig | 1 -
 configs/khadas-edge-v-rk3399_defconfig   | 1 -
 configs/leez-rk3399_defconfig| 1 -
 configs/nanopc-t4-rk3399_defconfig   | 1 -
 configs/nanopi-m4-2gb-rk3399_defconfig   | 1 -
 configs/nanopi-m4-rk3399_defconfig   | 1 -
 configs/nanopi-m4b-rk3399_defconfig  | 1 -
 configs/nanopi-neo4-rk3399_defconfig | 1 -
 configs/nanopi-r4s-rk3399_defconfig  | 3 ---
 configs/orangepi-rk3399_defconfig| 1 -
 configs/pinebook-pro-rk3399_defconfig| 3 ---
 configs/pinephone-pro-rk3399_defconfig   | 3 ---
 configs/puma-rk3399_defconfig| 3 ---
 configs/roc-pc-mezzanine-rk3399_defconfig| 3 ---
 configs/roc-pc-rk3399_defconfig  | 3 ---
 configs/rock-4c-plus-rk3399_defconfig| 3 ---
 configs/rock-4se-rk3399_defconfig| 3 ---
 configs/rock-pi-4-rk3399_defconfig   | 3 ---
 configs/rock-pi-4c-rk3399_defconfig  | 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig  | 2 --
 configs/rock960-rk3399_defconfig | 2 --
 configs/rockpro64-rk3399_defconfig   | 3 ---
 28 files changed, 58 deletions(-)

diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index b5a5ae737e52..989a8211f64d 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -27,7 +27,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -67,8 +66,6 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 20913d2cf0fe..07a96aa18989 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -28,7 +28,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -68,8 +67,6 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/eaidk-610-rk3399_defconfig 
b/configs/eaidk-610-rk3399_defconfig
index 22ad98b95ad3..0ca4cebc4d90 100644
--- a/configs/eaidk-610-rk3399_defconfig
+++ b/configs/eaidk-610-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 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
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index d6140527b752..1d1e55162290 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -43,7 +43,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index b7c8e95b7b89..2fe38f81c50d 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -20,7 +20,6 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -45,8 +44,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/khadas-edge-captain-rk3399_defconfig 
b/configs/khadas-edge-captain-rk3399_defconfig
index 7f4e48a4e750..28a59899e1cb 100644
--- a/configs/khadas-edge-captain-rk3399_defconfig
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -43,7 +43,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y

[PATCH v2 3/5] rockchip: rk3328: regenerate defconfigs

From: Chen-Yu Tsai 

Regenerate RK3328 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 configs/evb-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-rk3328_defconfig   | 3 ---
 configs/nanopi-r2s-rk3328_defconfig   | 3 ---
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
 configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
 configs/roc-cc-rk3328_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 3 ---
 configs/rock64-rk3328_defconfig   | 3 ---
 9 files changed, 27 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 995bfd0558b1..c3bde3e5c457 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -30,7 +30,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -70,8 +69,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
index 1cb0ed855398..1b0fa27ced16 100644
--- a/configs/nanopi-r2c-plus-rk3328_defconfig
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-rk3328_defconfig 
b/configs/nanopi-r2c-rk3328_defconfig
index 59801328deda..edf24623da2a 100644
--- a/configs/nanopi-r2c-rk3328_defconfig
+++ b/configs/nanopi-r2c-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 61914b1650d2..32c99dfecb86 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2s.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
index 968110c8cd6f..f554a284d930 100644
--- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus-lts.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -77,8 +76,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
diff --git a/configs/orangepi-r1-plus-rk3328_defconfig 
b/configs/orangepi-r1-plus-rk3328_defconfig
index 7038f09f202c..162032460fe0 100644
--- a/configs/orangepi-r1-plus-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000

[PATCH v2 2/5] rockchip: rk3399: Read cpuid and generate MAC address from efuse

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3399. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3399.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 0553967b947f..2c6b045c51c8 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -270,6 +270,9 @@ config ROCKCHIP_RK3399
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
imply BOOTSTD_FULL
imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT
+   imply MISC
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
  and quad-core Cortex-A53.
-- 
2.39.2

[PATCH v2 1/5] rockchip: rk3328: Read cpuid and generate MAC address from efuse

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3328. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3328.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1bc7ee904275..0553967b947f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -189,6 +189,9 @@ config ROCKCHIP_RK3328
select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
select SYS_NS16550
+   imply MISC
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3328 is a ARM-based SoC with a quad-core Cortex-A53.
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
-- 
2.39.2

[PATCH v2 0/5] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

From: Chen-Yu Tsai 

Hi folks,

This is v2 of my "read cpuid and generate MAC address from efuse on
RK3328 and RK3399 by default" series.

Changes since v1:
- Also imply "CONFIG_MISC"
- Add back unintentionally removed CONFIG_OF_LIBFDT_OVERLAY=y
- Remove ROCKCHIP_OTP from nanopi-r4s-rk3399_defconfig as requested by
  Jonas

This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
and RK3399 so that the cpuid is read from the efuse and used to generate
a serial number and MAC addresses for all boards.

This stacks on top of the recent defconfig update series [1] from Jonas.

[1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/

Chen-Yu Tsai (5):
  rockchip: rk3328: Read cpuid and generate MAC address from efuse
  rockchip: rk3399: Read cpuid and generate MAC address from efuse
  rockchip: rk3328: regenerate defconfigs
  rockchip: rk3399: regenerate defconfigs
  rockchip: nanopi-r4s: Drop ROCKCHIP_OTP

 arch/arm/mach-rockchip/Kconfig| 6 ++
 configs/chromebook_bob_defconfig  | 3 ---
 configs/chromebook_kevin_defconfig| 3 ---
 configs/eaidk-610-rk3399_defconfig| 1 -
 configs/evb-rk3328_defconfig  | 3 ---
 configs/evb-rk3399_defconfig  | 1 -
 configs/firefly-rk3399_defconfig  | 3 ---
 configs/khadas-edge-captain-rk3399_defconfig  | 1 -
 configs/khadas-edge-rk3399_defconfig  | 1 -
 configs/khadas-edge-v-rk3399_defconfig| 1 -
 configs/leez-rk3399_defconfig | 1 -
 configs/nanopc-t4-rk3399_defconfig| 1 -
 configs/nanopi-m4-2gb-rk3399_defconfig| 1 -
 configs/nanopi-m4-rk3399_defconfig| 1 -
 configs/nanopi-m4b-rk3399_defconfig   | 1 -
 configs/nanopi-neo4-rk3399_defconfig  | 1 -
 configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-rk3328_defconfig   | 3 ---
 configs/nanopi-r2s-rk3328_defconfig   | 3 ---
 configs/nanopi-r4s-rk3399_defconfig   | 4 
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
 configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
 configs/orangepi-rk3399_defconfig | 1 -
 configs/pinebook-pro-rk3399_defconfig | 3 ---
 configs/pinephone-pro-rk3399_defconfig| 3 ---
 configs/puma-rk3399_defconfig | 3 ---
 configs/roc-cc-rk3328_defconfig   | 3 ---
 configs/roc-pc-mezzanine-rk3399_defconfig | 3 ---
 configs/roc-pc-rk3399_defconfig   | 3 ---
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig   | 2 --
 configs/rock64-rk3328_defconfig   | 3 ---
 configs/rock960-rk3399_defconfig  | 2 --
 configs/rockpro64-rk3399_defconfig| 3 ---
 38 files changed, 6 insertions(+), 86 deletions(-)

-- 
2.39.2

Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub


Hello Shantur,

On 2024-02-12 14:40, Shantur Rathore wrote:
On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  
wrote:

On 2024-02-08 15:17, Dragan Simic wrote:
> On 2024-02-08 15:10, Shantur Rathore wrote:
>> On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
>> wrote:
>>> On 2024-02-08 14:33, Marek Vasut wrote:
>>> > On 2/8/24 12:30, Shantur Rathore wrote:
>>> >> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  wrote:
>>> >>> On 2/7/24 11:23, Shantur Rathore wrote:
>>>  USB 3.0 spec requires hub to reset device while
>>>  enumeration. Some USB 2.0 hubs / devices don't
>>>  handle this well and after implementation of
>>>  reset some USB 2.0 disks weren't detected on
>>>  Allwinner based boards.
>>> 
>>>  Resetting only when hub is USB 3.0 fixes it.
>>> >>>
>>> >>> It would be good to include as many details about the faulty hardware
>>> >>> in
>>> >>> the commit message as possible, so that when someone else runs into
>>> >>> this, they would have all that information available.
>>> >>>
>>>  Tested-by: Andre Przywara 
>>> 
>>>  Signed-off-by: Shantur Rathore 
>>>  ---
>>> 
>>> common/usb_hub.c | 6 --
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>> 
>>>  diff --git a/common/usb_hub.c b/common/usb_hub.c
>>>  index 3fb7e14d10..2e054eb935 100644
>>>  --- a/common/usb_hub.c
>>>  +++ b/common/usb_hub.c
>>>  @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
>>>  usb_hub_device *hub)
>>> 
>>> debug("enabling power on all ports\n");
>>> for (i = 0; i < dev->maxchild; i++) {
>>>  - usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
>>>  - debug("Reset : port %d returns %lX\n", i + 1,
>>>  dev->status);
>>>  + if (usb_hub_is_superspeed(dev)) {
>>> >>>
>>> >>> Should this condition be "all which are lower than superspeed"
>>> >>> instead ,
>>> >>> so when the next generation of USB comes, this problem won't trigger
>>> >>> ?
>>> >>>
>>> >>> What does Linux do btw ?
>>> >>
>>> >> As of now Linux checks if the hub is superspeed
>>> >> 
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
>>> >>
>>> >> which is
>>> >>   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
>>> >> USB_HUB_PR_SS = 3
>>> >>
>>> >> This holds true for newer SuperSpeedPlus hubs as well.
>>> >> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
>>> >>
>>> >> We can change the check to be  bDeviceProtocol > 2 but who knows if
>>> >> things change in the newer version of spec.
>>> >> I am open to suggestions.
>>> >
>>> > Please just include the ^ in the commit description. Use link to
>>> > git.kernel.org , not some mirror . This is extremely useful
>>> > information and, well, you already wrote the V2 commit message
>>> > addition in this answer.
>>>
>>> Shantur, if that would be easier or quicker for you, I can write
>>> a quite detailed patch description for you, in exchange for a
>>> "Helped-by" tag in the v2 patch submission. :)
>>
>> That would be really kind of you Dragan.
>
> Sure, I'll write the summary and send it over.
>
>> I am down with the flu so that would really help me as my brain is
>> working at 15% capacity.
>
> Oh, I'm really sorry to hear that. :(  I hope you'll get better
> soon, and I know very well what's it like;  I've also been sick
> recently, as a result of some kind of flu that unfortunately found
> its way into my lungs, and it took me about a month to get back
> to about 90% of my usual mental capacity.  I'm still not back to
> exactly 100%. :/
>
> I really hope you'll recover much faster.

I hope you're feeling better.

Below are the patch subject and description that I prepared for you,
please have a look.

--- >8 - >8 - >8 - >8 ---
[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only

Additional testing of the changes introduced in commit 33e06dcbe57a
("common:
usb-hub: Reset hub port before scanning") revealed that some USB 3.0
flash


s/some USB 3.0 flash/some USB 2.0 and 3.0 flash/


I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.


As visible in the message linked below, there was one USB 3.0 flash
drive that didn't work in a USB 2.0 port.  Though, you're right, there
was also a USB 2.0 drive that didn't work.  Thus, it's perhaps best to
adjust the wording as I suggested above and below.

https://lore.kernel.org/u-boot/20240202001218.63b4e...@minigeek.lan/

drives didn't work in U-Boot on some Allwinner SoCs that support USB 
2.0

only.
More precisely, some tested USB 3.0 flash drives failed to be detected
and


s/some tested USB 3.0 flash drives/some tested USB 2.0 and 3.0 flash 
drives/



work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
2.0
only, while the same USB flash drives worked just fine on a Pine64 H64
with
Allwinner H6 SoC, which supports both USB 2.0 and 3.0.

Resetting USB 3.0

Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub

2024-02-12 Thread Shantur Rathore

On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore  wrote:
>
> Thanks Dragan,
>
> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  wrote:
> >
> > Hello Shantur,
> >
> > On 2024-02-08 15:17, Dragan Simic wrote:
> > > On 2024-02-08 15:10, Shantur Rathore wrote:
> > >> On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
> > >> wrote:
> > >>> On 2024-02-08 14:33, Marek Vasut wrote:
> > >>> > On 2/8/24 12:30, Shantur Rathore wrote:
> > >>> >> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  wrote:
> > >>> >>> On 2/7/24 11:23, Shantur Rathore wrote:
> > >>>  USB 3.0 spec requires hub to reset device while
> > >>>  enumeration. Some USB 2.0 hubs / devices don't
> > >>>  handle this well and after implementation of
> > >>>  reset some USB 2.0 disks weren't detected on
> > >>>  Allwinner based boards.
> > >>> 
> > >>>  Resetting only when hub is USB 3.0 fixes it.
> > >>> >>>
> > >>> >>> It would be good to include as many details about the faulty 
> > >>> >>> hardware
> > >>> >>> in
> > >>> >>> the commit message as possible, so that when someone else runs into
> > >>> >>> this, they would have all that information available.
> > >>> >>>
> > >>>  Tested-by: Andre Przywara 
> > >>> 
> > >>>  Signed-off-by: Shantur Rathore 
> > >>>  ---
> > >>> 
> > >>> common/usb_hub.c | 6 --
> > >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> > >>> 
> > >>>  diff --git a/common/usb_hub.c b/common/usb_hub.c
> > >>>  index 3fb7e14d10..2e054eb935 100644
> > >>>  --- a/common/usb_hub.c
> > >>>  +++ b/common/usb_hub.c
> > >>>  @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
> > >>>  usb_hub_device *hub)
> > >>> 
> > >>> debug("enabling power on all ports\n");
> > >>> for (i = 0; i < dev->maxchild; i++) {
> > >>>  - usb_set_port_feature(dev, i + 1, 
> > >>>  USB_PORT_FEAT_RESET);
> > >>>  - debug("Reset : port %d returns %lX\n", i + 1,
> > >>>  dev->status);
> > >>>  + if (usb_hub_is_superspeed(dev)) {
> > >>> >>>
> > >>> >>> Should this condition be "all which are lower than superspeed"
> > >>> >>> instead ,
> > >>> >>> so when the next generation of USB comes, this problem won't trigger
> > >>> >>> ?
> > >>> >>>
> > >>> >>> What does Linux do btw ?
> > >>> >>
> > >>> >> As of now Linux checks if the hub is superspeed
> > >>> >> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
> > >>> >>
> > >>> >> which is
> > >>> >>   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
> > >>> >> USB_HUB_PR_SS = 3
> > >>> >>
> > >>> >> This holds true for newer SuperSpeedPlus hubs as well.
> > >>> >> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
> > >>> >>
> > >>> >> We can change the check to be  bDeviceProtocol > 2 but who knows if
> > >>> >> things change in the newer version of spec.
> > >>> >> I am open to suggestions.
> > >>> >
> > >>> > Please just include the ^ in the commit description. Use link to
> > >>> > git.kernel.org , not some mirror . This is extremely useful
> > >>> > information and, well, you already wrote the V2 commit message
> > >>> > addition in this answer.
> > >>>
> > >>> Shantur, if that would be easier or quicker for you, I can write
> > >>> a quite detailed patch description for you, in exchange for a
> > >>> "Helped-by" tag in the v2 patch submission. :)
> > >>
> > >> That would be really kind of you Dragan.
> > >
> > > Sure, I'll write the summary and send it over.
> > >
> > >> I am down with the flu so that would really help me as my brain is
> > >> working at 15% capacity.
> > >
> > > Oh, I'm really sorry to hear that. :(  I hope you'll get better
> > > soon, and I know very well what's it like;  I've also been sick
> > > recently, as a result of some kind of flu that unfortunately found
> > > its way into my lungs, and it took me about a month to get back
> > > to about 90% of my usual mental capacity.  I'm still not back to
> > > exactly 100%. :/
> > >
> > > I really hope you'll recover much faster.
> >
> > I hope you're feeling better.
> >
> > Below are the patch subject and description that I prepared for you,
> > please have a look.
> >
> > --- >8 - >8 - >8 - >8 ---
> > [PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
> >
> > Additional testing of the changes introduced in commit 33e06dcbe57a
> > ("common:
> > usb-hub: Reset hub port before scanning") revealed that some USB 3.0
> > flash
>
> I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.
>
> > drives didn't work in U-Boot on some Allwinner SoCs that support USB 2.0
> > only.
> > More precisely, some tested USB 3.0 flash drives failed to be detected
> > and
> > work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
> > 2.0
> > only, while the same USB flash drives worked just fine on a Pine64 H64
> > with
> > Allwinner H6 SoC, which supports

Re: [PATCH v2 04/20] rockchip: pine64: pinebook-pro: migrate to rockchip_early_misc_init_r

On Fri, 9 Feb 2024 at 09:50, Quentin Schulz  wrote:
>
> From: Quentin Schulz 
>
> Compared to the original misc_init_r from Rockchip mach code,
> setup_iodomain() is added and rockchip_setup_macaddr() is not called.
>
> It is assumed adding rockchip_setup_macaddr() back is fine.
> Let's use rockchip_early_misc_init_r instead of reimplementing the whole
> misc_init_r from Rockchip (the side effect being that
> rockchip_setup_macaddr() is back).

The Pinebook Pro doesn't have onboard ethernet, nor an alias defined,
I wonder if rockchip_setup_macaddr should be gated on GMAC_ROCKCHIP or
something similar. Otherwise:
Reviewed-by: Peter Robinson 

> Cc: Quentin Schulz 
> Reviewed-by: Kever Yang 
> Signed-off-by: Quentin Schulz 
> ---
>  board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c | 18 
> ++
>  1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c 
> b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> index 4ad780767ea..2408a367305 100644
> --- a/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> +++ b/board/pine64/pinebook-pro-rk3399/pinebook-pro-rk3399.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>
> @@ -54,23 +53,10 @@ static void setup_iodomain(void)
> rk_setreg(>soc_con0, 1 << PMUGRF_CON0_VSEL_SHIFT);
>  }
>
> -int misc_init_r(void)
> +int rockchip_early_misc_init_r(void)
>  {
> -   const u32 cpuid_offset = 0x7;
> -   const u32 cpuid_length = 0x10;
> -   u8 cpuid[cpuid_length];
> -   int ret;
> -
> setup_iodomain();
>
> -   ret = rockchip_cpuid_from_efuse(cpuid_offset, cpuid_length, cpuid);
> -   if (ret)
> -   return ret;
> -
> -   ret = rockchip_cpuid_set(cpuid, cpuid_length);
> -   if (ret)
> -   return ret;
> -
> -   return ret;
> +   return 0;
>  }
>  #endif
>
> --
> 2.43.0
>

Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub

2024-02-12 Thread Shantur Rathore

Thanks Dragan,

On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic  wrote:
>
> Hello Shantur,
>
> On 2024-02-08 15:17, Dragan Simic wrote:
> > On 2024-02-08 15:10, Shantur Rathore wrote:
> >> On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic 
> >> wrote:
> >>> On 2024-02-08 14:33, Marek Vasut wrote:
> >>> > On 2/8/24 12:30, Shantur Rathore wrote:
> >>> >> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut  wrote:
> >>> >>> On 2/7/24 11:23, Shantur Rathore wrote:
> >>>  USB 3.0 spec requires hub to reset device while
> >>>  enumeration. Some USB 2.0 hubs / devices don't
> >>>  handle this well and after implementation of
> >>>  reset some USB 2.0 disks weren't detected on
> >>>  Allwinner based boards.
> >>> 
> >>>  Resetting only when hub is USB 3.0 fixes it.
> >>> >>>
> >>> >>> It would be good to include as many details about the faulty hardware
> >>> >>> in
> >>> >>> the commit message as possible, so that when someone else runs into
> >>> >>> this, they would have all that information available.
> >>> >>>
> >>>  Tested-by: Andre Przywara 
> >>> 
> >>>  Signed-off-by: Shantur Rathore 
> >>>  ---
> >>> 
> >>> common/usb_hub.c | 6 --
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>> 
> >>>  diff --git a/common/usb_hub.c b/common/usb_hub.c
> >>>  index 3fb7e14d10..2e054eb935 100644
> >>>  --- a/common/usb_hub.c
> >>>  +++ b/common/usb_hub.c
> >>>  @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
> >>>  usb_hub_device *hub)
> >>> 
> >>> debug("enabling power on all ports\n");
> >>> for (i = 0; i < dev->maxchild; i++) {
> >>>  - usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
> >>>  - debug("Reset : port %d returns %lX\n", i + 1,
> >>>  dev->status);
> >>>  + if (usb_hub_is_superspeed(dev)) {
> >>> >>>
> >>> >>> Should this condition be "all which are lower than superspeed"
> >>> >>> instead ,
> >>> >>> so when the next generation of USB comes, this problem won't trigger
> >>> >>> ?
> >>> >>>
> >>> >>> What does Linux do btw ?
> >>> >>
> >>> >> As of now Linux checks if the hub is superspeed
> >>> >> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
> >>> >>
> >>> >> which is
> >>> >>   return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
> >>> >> USB_HUB_PR_SS = 3
> >>> >>
> >>> >> This holds true for newer SuperSpeedPlus hubs as well.
> >>> >> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
> >>> >>
> >>> >> We can change the check to be  bDeviceProtocol > 2 but who knows if
> >>> >> things change in the newer version of spec.
> >>> >> I am open to suggestions.
> >>> >
> >>> > Please just include the ^ in the commit description. Use link to
> >>> > git.kernel.org , not some mirror . This is extremely useful
> >>> > information and, well, you already wrote the V2 commit message
> >>> > addition in this answer.
> >>>
> >>> Shantur, if that would be easier or quicker for you, I can write
> >>> a quite detailed patch description for you, in exchange for a
> >>> "Helped-by" tag in the v2 patch submission. :)
> >>
> >> That would be really kind of you Dragan.
> >
> > Sure, I'll write the summary and send it over.
> >
> >> I am down with the flu so that would really help me as my brain is
> >> working at 15% capacity.
> >
> > Oh, I'm really sorry to hear that. :(  I hope you'll get better
> > soon, and I know very well what's it like;  I've also been sick
> > recently, as a result of some kind of flu that unfortunately found
> > its way into my lungs, and it took me about a month to get back
> > to about 90% of my usual mental capacity.  I'm still not back to
> > exactly 100%. :/
> >
> > I really hope you'll recover much faster.
>
> I hope you're feeling better.
>
> Below are the patch subject and description that I prepared for you,
> please have a look.
>
> --- >8 - >8 - >8 - >8 ---
> [PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
>
> Additional testing of the changes introduced in commit 33e06dcbe57a
> ("common:
> usb-hub: Reset hub port before scanning") revealed that some USB 3.0
> flash

I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.

> drives didn't work in U-Boot on some Allwinner SoCs that support USB 2.0
> only.
> More precisely, some tested USB 3.0 flash drives failed to be detected
> and
> work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
> 2.0
> only, while the same USB flash drives worked just fine on a Pine64 H64
> with
> Allwinner H6 SoC, which supports both USB 2.0 and 3.0.
>
> Resetting USB 3.0 hubs only has been tested to work as expected,
> resolving
> the previous issues on the Allwinner H616, while not introducing any new
> issues on other Allwinner SoCs.  Thus, let's fix it that way.
>
> According to the USB 3.0 specification, resetting a USB 3.0 port is
>

Re: [PATCH v2 6/6] efi_selftest: Add symbol character selftest


On 10.02.24 13:46, Janne Grunau via B4 Relay wrote:

From: Janne Grunau 

Draw symbols from code page 437 code points 0x01 - 01f used by UEFI
applications to draw user interfaces using
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.

Add a simple test to displaying the Konami code using symbols used by


The Unicode standards calls page 25A0 "Geometric shapes".

Konami is an unrelated brand of 'Konami Digital Entertainment".


grub2. The output has to be checked manually on the screen for
correctness.

Signed-off-by: Janne Grunau 
---
  lib/efi_selftest/efi_selftest_textoutput.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/lib/efi_selftest/efi_selftest_textoutput.c 
b/lib/efi_selftest/efi_selftest_textoutput.c
index cc11a22eee..9e5d944fa0 100644
--- a/lib/efi_selftest/efi_selftest_textoutput.c
+++ b/lib/efi_selftest/efi_selftest_textoutput.c
@@ -46,6 +46,8 @@ u"left bottom \u2502 right bottom  
\u2502\n\u2514\u2500\u2500\u2500"
  u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2534"
  u"\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500"
  u"\u2500\u2500\u2500\u2500\u2518\n";
+   const u16 konami[] =
+u"Konami code: \u25b2 \u25b2 \u25bc \u25bc \u25c4 \u25ba \u25c4 \u25ba B A\n";


If you want a human to check the output visually, how about:

Geometric shapes:
U+25B2 ▲ - Black up-pointing triangle
U+25BA ► - Black right-pointing pointer
U+25BC ▼ - Black down-pointing triangle
U+25C4 ◄ - Black left-pointing pointer

Best regards

Heinrich



/* SetAttribute */
efi_st_printf("\nColor palette\n");
@@ -144,6 +146,11 @@ u"\u2500\u2500\u2500\u2500\u2518\n";
efi_st_error("OutputString failed for box drawing chars\n");
return EFI_ST_FAILURE;
}
+   ret = con_out->output_string(con_out, konami);
+   if (ret != EFI_ST_SUCCESS) {
+   efi_st_error("OutputString failed for symbol chars\n");
+   return EFI_ST_FAILURE;
+   }
con_out->output_string(con_out, u"waiting for admiration...\n");
EFI_CALL(systab.boottime->stall(300));
efi_st_printf("\n");

[PATCH] bootdev: drop unnecessary assert on bootflow->bdev

2024-02-12 Thread Thomas Weißschuh

Not all flows have a device and the function already contains logic to
handle this case.

Fixes: eccb25cd5922 ("bootstd: Allow the bootdev to be optional in bootflows")
Signed-off-by: Thomas Weißschuh 
---
 boot/bootdev-uclass.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 35afb93c0e73..0fa6dad8b11b 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -39,7 +39,6 @@ int bootdev_add_bootflow(struct bootflow *bflow)
struct bootflow *new;
int ret;
 
-   assert(bflow->dev);
ret = bootstd_get_priv();
if (ret)
return ret;

---
base-commit: e8f2404e093daf6cc3ac2b3233e3c6770d13e371
change-id: 20240209-bootdev-assert-11714f63d72d

Best regards,
-- 
Thomas Weißschuh

[PATCH] log: make global data relocatable

2024-02-12 Thread Thomas Weißschuh

When `gd` is relocated during `spl_relocate_stack_gd()` the
doubly-linked circular list in the `log_head` member is broken.

The last element of the list should point back to the initial
`list_head`, but as the initial `list_head` is moved the pointer becomes
stale. As a result the loop in `log_dispatch` would never finish.

Migrate the list to a singly-linked non-circular one which is
easily relocatable.

This should also remove the special handling introduced in
commit e7595aa350ae ("x86: Allow logging to be used in SPL reliably").

Signed-off-by: Thomas Weißschuh 
---
 common/log.c  | 15 +--
 include/asm-generic/global_data.h |  2 +-
 include/log.h |  2 +-
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/common/log.c b/common/log.c
index b2de57fcb3b8..098d40c86d81 100644
--- a/common/log.c
+++ b/common/log.c
@@ -109,7 +109,7 @@ struct log_device *log_device_find_by_name(const char 
*drv_name)
 {
struct log_device *ldev;
 
-   list_for_each_entry(ldev, >log_head, sibling_node) {
+   for (ldev = gd->log_head; ldev; ldev = ldev->sibling_node) {
if (!strcmp(drv_name, ldev->drv->name))
return ldev;
}
@@ -218,7 +218,7 @@ static int log_dispatch(struct log_rec *rec, const char 
*fmt, va_list args)
 
/* Emit message */
gd->processing_msg = true;
-   list_for_each_entry(ldev, >log_head, sibling_node) {
+   for (ldev = gd->log_head; ldev; ldev = ldev->sibling_node) {
if ((ldev->flags & LOGDF_ENABLE) &&
log_passes_filters(ldev, rec)) {
if (!rec->msg) {
@@ -400,7 +400,7 @@ static struct log_device *log_find_device_by_drv(struct 
log_driver *drv)
 {
struct log_device *ldev;
 
-   list_for_each_entry(ldev, >log_head, sibling_node) {
+   for (ldev = gd->log_head; ldev; ldev = ldev->sibling_node) {
if (ldev->drv == drv)
return ldev;
}
@@ -433,13 +433,16 @@ int log_init(void)
struct log_driver *drv = ll_entry_start(struct log_driver, log_driver);
const int count = ll_entry_count(struct log_driver, log_driver);
struct log_driver *end = drv + count;
+   struct log_device **log_head;
+
+   gd->log_head = NULL;
+   log_head = (struct log_device **)>log_head;
 
/*
 * We cannot add runtime data to the driver since it is likely stored
 * in rodata. Instead, set up a 'device' corresponding to each driver.
 * We only support having a single device for each driver.
 */
-   INIT_LIST_HEAD((struct list_head *)>log_head);
while (drv < end) {
struct log_device *ldev;
 
@@ -451,8 +454,8 @@ int log_init(void)
INIT_LIST_HEAD(>filter_head);
ldev->drv = drv;
ldev->flags = drv->flags;
-   list_add_tail(>sibling_node,
- (struct list_head *)>log_head);
+   *log_head = ldev;
+   log_head = >sibling_node;
drv++;
}
gd->flags |= GD_FLG_LOG_READY;
diff --git a/include/asm-generic/global_data.h 
b/include/asm-generic/global_data.h
index fcc3c6e14ca3..a9a407b801c2 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -404,7 +404,7 @@ struct global_data {
/**
 * @log_head: list of logging devices
 */
-   struct list_head log_head;
+   struct log_device *log_head;
/**
 * @log_fmt: bit mask for logging format
 *
diff --git a/include/log.h b/include/log.h
index 6e84f080ef3d..961233684d2a 100644
--- a/include/log.h
+++ b/include/log.h
@@ -455,7 +455,7 @@ struct log_device {
unsigned short flags;
struct log_driver *drv;
struct list_head filter_head;
-   struct list_head sibling_node;
+   struct log_device *sibling_node;
 };
 
 enum {

---
base-commit: e8f2404e093daf6cc3ac2b3233e3c6770d13e371
change-id: 20240208-spl-logging-14a1257c3147

Best regards,
-- 
Thomas Weißschuh

[PATCH] virtio: fix get_config / set_config for legacy VirtIO targets

2024-02-12 Thread Dmitry Baryshkov

The functions virtio_pci_get_config() and virtio_pci_set_config() don't
take the offset into account when reading the config space. For example
this manifests when U-Boot tries to read the MAC address of the VirtIO
networking device. It reads 6 equa bytes instead of the proper addess.

Fix those functions by taking the offset in the config space into
account.

Fixes: 4135e10732a0 ("virtio: Add virtio over pci transport driver")
Signed-off-by: Dmitry Baryshkov 
---
 drivers/virtio/virtio_pci_legacy.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/virtio/virtio_pci_legacy.c 
b/drivers/virtio/virtio_pci_legacy.c
index cf5dfb17a94d..aa89604ae84d 100644
--- a/drivers/virtio/virtio_pci_legacy.c
+++ b/drivers/virtio/virtio_pci_legacy.c
@@ -107,7 +107,7 @@ static int virtio_pci_get_config(struct udevice *udev, 
unsigned int offset,
int i;
 
for (i = 0; i < len; i++)
-   ptr[i] = ioread8(ioaddr + i);
+   ptr[i] = ioread8(ioaddr + offset + i);
 
return 0;
 }
@@ -121,7 +121,7 @@ static int virtio_pci_set_config(struct udevice *udev, 
unsigned int offset,
int i;
 
for (i = 0; i < len; i++)
-   iowrite8(ptr[i], ioaddr + i);
+   iowrite8(ptr[i], ioaddr + offset + i);
 
return 0;
 }
-- 
2.39.2

[PATCH] command: add FDT setup for bootelf by flag

2024-02-12 Thread Maxim Moskalets

Added the ability to use FDT for ELF applications, required to run some OS. To 
make FDT setup, you need to set the elf_needed_fdt environment variable to a 
value like y or yes.

Signed-off-by: Maxim Moskalets 

Cc: Tom Rini 
---

 cmd/elf.c | 14 ++
 env/common.c  |  5 +
 include/env.h |  7 +++
 3 files changed, 26 insertions(+)

diff --git a/cmd/elf.c b/cmd/elf.c
index b7b9f506a5..4d365771eb 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -38,6 +38,8 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, char 
* const[]),
 /* Interpreter command to boot an arbitrary ELF image from memory */
 int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
 {
+   unsigned long fdt_addr;
+   struct bootm_headers img = { 0 };
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
char *sload = NULL;
@@ -68,6 +70,18 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, 
char *const argv[])
else
addr = load_elf_image_shdr(addr);
 
+   if (!env_get_elf_need_fdt()) {
+   if (argc >= 1 && strict_strtoul(argv[0], 16, _addr) != 
-EINVAL) {
+   printf("Got FDT at 0x%08lx ...\n", fdt_addr);
+
+   if (image_setup_libfdt(, (void *)fdt_addr, 0, 
NULL)) {
+   printf("ERROR: Failed to process device 
tree\n");
+   return 1;
+   }
+   }
+   }
+
+
if (!env_get_autostart())
return rcode;
 
diff --git a/env/common.c b/env/common.c
index 48a565107c..8cd8558c3f 100644
--- a/env/common.c
+++ b/env/common.c
@@ -346,6 +346,11 @@ bool env_get_autostart(void)
return env_get_yesno("autostart") == 1;
 }
 
+bool env_get_elf_need_fdt(void)
+{
+   return env_get_yesno("elf_need_fdt") == 1;
+}
+
 /*
  * Look up the variable from the default environment
  */
diff --git a/include/env.h b/include/env.h
index d2a5954ded..384c312d2e 100644
--- a/include/env.h
+++ b/include/env.h
@@ -148,6 +148,13 @@ int env_get_yesno(const char *var);
  */
 bool env_get_autostart(void);
 
+/**
+ * env_get_elf_need_fdt() - Check if FDT is needed for ELF image
+ *
+ * Return: true if the "elf_need_fdt" env var exists and is set to "yes"
+ */
+bool env_get_elf_need_fdt(void);
+
 /**
  * env_set() - set an environment variable
  *
-- 
2.39.2

Re: [PATCH 2/2] rockchip: rk3399: Update stack and bss addresses

2024-02-12 Thread Jerome Forissier

On 2/12/24 12:51, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 2/12/24 12:08, Jonas Karlman wrote:
>> Hi Quentin,
>>
>> On 2024-02-12 11:37, Quentin Schulz wrote:
>>> Hi Jonas,
>>>
>>> On 2/12/24 01:59, Jonas Karlman wrote:
 With the stack and text base used by U-Boot SPL and proper on RK3399
 there is a high likelihood of overlapping when U-Boot proper + FDT nears
 1 MiB in size.

 Currently the following memory layout is used:
 - 0x (@0 MiB): U-Boot SPL text base
 - 0x0004 (@256 KiB): TF-A
 - 0x0020 (@2 MiB): U-Boot proper text base
 - 0x0030 (@3 MiB): U-Boot proper init stack
 - 0x0040 (@4 MiB): U-Boot SPL init stack
 - 0x0040 (@4 MiB): U-Boot SPL bss
 - 0x0200 (@64 MiB): U-Boot SPL reloc stack
 - 0x0840 (@132 MiB): optional OPTEE

 SPL load TF-A, U-Boot proper and optional OPTEE after SPL stack has
 relocated, meaning that there is room for close to 2 MiB (@2-4 MiB).
 However, the initial stack used by U-Boot proper is limiting the size
 of U-Boot proper + FDT to below 1 MiB (@2-3 MiB).

 Instead change to use the following memory layout:
 - 0x (@0 MiB): U-Boot SPL text base
 - 0x0004 (@256 KiB): TF-A
 - 0x0020 (@2 MiB): U-Boot proper text base
 - 0x0040 (@4 MiB): U-Boot SPL init stack
 - 0x0080 (@8 MiB): U-Boot proper init stack (changed)
 - 0x0200 (@32 MiB): U-Boot SPL bss (changed)
 - 0x0400 (@64 MiB): U-Boot SPL reloc stack
 - 0x0840 (@132 MiB): optional OPTEE

 This should leave room for loading and running a U-Boot proper close
 to 6 MiB (@2-8 MiB) in size. When U-Boot proper has relocated is should
 be possible to use @2-132 MiB and @164 MiB+ for scripts, kernel etc.

 With the moved SPL reloc stack it is also possible to use a much larger
 malloc area in SPL, e.g. using default SPL_STACK_R_MALLOC_SIMPLE_LEN.

 Signed-off-by: Jonas Karlman 
>>>
>>> Do we not need to update memory addresses in the environment as well?
>>
>> The addresses in environment is to my knowledge only used in U-Boot
>> proper after relocation. And at that time we should be free to use @2+
>> MiB up to somewhere close to gd ram_top/relocaddr. The optional Rockchip
>> OPTEE blobb may occupy @132-164 MiB, but I do not think loading OPTEE
>> blobs works as-is, so that may not be a big issue.
>>
> 
> Upstream OP-TEE OS seems to support RK3399, c.f. 
> https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/platform_rk3399.c

It does indeed. I run the quarterly release tests on a RockPi4B. We record which
platforms have been tested in the commit description for each release tag. For
example, see [1].

In the configuration I test, OP-TEE is loaded at 0x3000 and uses 32MB (for
some reason the Linux DT reserves 36MB but I don't think it matters much).

[1] 
https://github.com/OP-TEE/optee_os/commit/18b424c23aa5a798dfe2e4d20b4bde3919dc4e99

-- 
Jerome

Re: [PATCH v2 4/6] efi_selftest: Add international characters test


On 10.02.24 13:46, Janne Grunau via B4 Relay wrote:

From: Andre Przywara 

UEFI relies entirely on unicode output, which actual fonts displayed on
the screen might not be ready for.

Add a test displaying some international characters, to reveal missing
glyphs, especially in our builtin fonts.
This would be needed to be manually checked on the screen for
correctness.

Signed-off-by: Andre Przywara 
Suggested-by: Heinrich Schuchardt 
Signed-off-by: Janne Grunau 
---
  lib/efi_selftest/efi_selftest_textoutput.c | 8 
  1 file changed, 8 insertions(+)

diff --git a/lib/efi_selftest/efi_selftest_textoutput.c 
b/lib/efi_selftest/efi_selftest_textoutput.c
index cc44b38bc2..2aa81b0a80 100644
--- a/lib/efi_selftest/efi_selftest_textoutput.c
+++ b/lib/efi_selftest/efi_selftest_textoutput.c
@@ -30,6 +30,9 @@ static int execute(void)
0xD804, 0xDC05,
0xD804, 0xDC22,
0};
+   const u16 text[] =


A person not speaking German, Danish, French, Spanish, and Greek would
not know which characters to look for.

How about printing

U+00D6 Ö - Latin capital O with diaresis
U+00DF ß - Latin small letter sharp s
U+00E5 å - Latin small a with ring above
U+00E5 é - Latin small e with acute
U+00F1 ñ - Latin small n with tilde
U+00F6 ö - Latin small o with diaresis
U+00F8 ø - Latin small letter o with stroke
U+03AC ά - Greek small letter alpha with tonus
U+03BB λ - Greek small letter lambda
U+03C2 ς - Greek small letter final sigma
U+1F19 Ἑ - Greek capital letter epsilon with dasia

Best regards

Heinrich


+u"\u00d6sterreich Edelwei\u00df Sm\u00f8rrebr\u00f8d Sm\u00f6rg"
+u"\u00e5s Ni\u00f1o Ren\u00e9 >\u1f19\u03bb\u03bb\u03ac\u03c2<\n";

/* SetAttribute */
efi_st_printf("\nColor palette\n");
@@ -118,6 +121,11 @@ static int execute(void)
efi_st_printf("Unicode not handled properly\n");
return EFI_ST_FAILURE;
}
+   ret = con_out->output_string(con_out, text);
+   if (ret != EFI_ST_SUCCESS) {
+   efi_st_error("OutputString failed for international chars\n");
+   return EFI_ST_FAILURE;
+   }
efi_st_printf("\n");

return EFI_ST_SUCCESS;

Re: [PATCH v2] imx: imx8mp: Add support for Polyhex Debix Model A SBC

2024-02-12 Thread Gilles Talis

Hi Milan,


Le mar. 30 janv. 2024 à 15:55, Milan Zamazal  a écrit :
>
> Fabio Estevam  writes:
>
> > Hi Milan,
> >
> > On Tue, Jan 30, 2024 at 9:22 AM Milan Zamazal  wrote:
> >
> >> Well, after trying both the SD cards again with fresh reinstallations, it 
> >> works
> >> with a 32 GB card and I get the error above with a 64 GB card.  Is it 
> >> possible
> >> that there is something wrong with SDXC cards?
> >
> > Does the change below help?
> >
> > --- a/arch/arm/dts/imx8mp-debix-model-a-u-boot.dtsi
> > +++ b/arch/arm/dts/imx8mp-debix-model-a-u-boot.dtsi
> > @@ -128,6 +128,9 @@
> > bootph-pre-ram;
> > sd-uhs-sdr104;
> > sd-uhs-ddr50;
> > +   assigned-clocks = < IMX8MP_CLK_USDHC2>;
> > +   assigned-clock-rates = <4>;
> > +   assigned-clock-parents = < IMX8MP_SYS_PLL1_400M>;
> >  };
> >
> >   {
>
> No, the same error. :-(
>
> Regards,
> Milan
>
I tried with a  32GB Sandisk high endurance SD and a 64GB Sandisk
Ultra SDXC UHS-I and both worked.
Can you tell me which 64GB sd cards you tried booting with? And also,
which steps you followed to get the errors (which image to download,
etc...)?

thanks
Gilles.

Re: [PATCH v2 3/6] lib/charset: Map Unicode code points to CP437 code points 0-31


On 10.02.24 13:46, Janne Grunau via B4 Relay wrote:

From: Janne Grunau 

Code page 437 uses code points 1-31 for glyphs instead of control
characters. Map the appropriate Unicode code points to this code points.
Fixes rendering of grub2's menu as EFI application using the
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL on a console with bitmap fonts.

Signed-off-by: Janne Grunau 
---
  include/charset.h  |  2 +-
  include/cp1250.h   | 12 ++--
  include/cp437.h| 12 ++--
  lib/charset.c  |  9 ++---
  lib/efi_loader/efi_unicode_collation.c |  2 +-
  5 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/include/charset.h b/include/charset.h
index f1050c903d..348bad5883 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -16,7 +16,7 @@
  /*
   * codepage_437 - Unicode to codepage 437 translation table
   */
-extern const u16 codepage_437[128];
+extern const u16 codepage_437[160];

  /**
   * console_read_unicode() - read Unicode code point from console
diff --git a/include/cp1250.h b/include/cp1250.h
index adacf8a958..b762c78d9f 100644
--- a/include/cp1250.h
+++ b/include/cp1250.h
@@ -1,10 +1,18 @@
  /* SPDX-License-Identifier: GPL-2.0+ */

  /*
- * Constant CP1250 contains the Unicode code points for characters 0x80 - 0xff
- * of the code page 1250.
+ * Constant CP1250 contains the Unicode code points for characters 0x00 - 0x1f
+ * and 0x80 - 0xff of the code page 1250.
   */
  #define vi  { \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
+   0x, 0x, 0x, 0x, \
0x20ac, 0x, 0x201a, 0x, \
0x201e, 0x2026, 0x2020, 0x2021, \
0x, 0x2030, 0x0160, 0x2039, \
diff --git a/include/cp437.h b/include/cp437.h
index 0b2b97132e..5093130f5e 100644
--- a/include/cp437.h
+++ b/include/cp437.h
@@ -1,10 +1,18 @@
  /* SPDX-License-Identifier: GPL-2.0+ */

  /*
- * Constant CP437 contains the Unicode code points for characters 0x80 - 0xff
- * of the code page 437.
+ * Constant CP437 contains the Unicode code points for characters 0x00 - 0x1f
+ * and 0x80 - 0xff of the code page 437.
   */
  #define CP437 { \
+   0x, 0x263a, 0x263b, 0x2665, \
+   0x2666, 0x2663, 0x2660, 0x2022, \
+   0x25d8, 0x25cb, 0x25d9, 0x2642, \
+   0x2640, 0x266a, 0x266b, 0x263c, \
+   0x25ba, 0x25c4, 0x2195, 0x203c, \
+   0x00b6, 0x00a7, 0x25ac, 0x21a8, \
+   0x2191, 0x2193, 0x2192, 0x2190, \
+   0x221f, 0x2194, 0x25b2, 0x25bc, \
0x00c7, 0x00fc, 0x00e9, 0x00e2, \
0x00e4, 0x00e0, 0x00e5, 0x00e7, \
0x00ea, 0x00eb, 0x00e8, 0x00ef, \
diff --git a/lib/charset.c b/lib/charset.c
index 5e4c4f948a..1f8480150a 100644
--- a/lib/charset.c
+++ b/lib/charset.c
@@ -16,7 +16,7 @@
  /**
   * codepage_437 - Unicode to codepage 437 translation table
   */
-const u16 codepage_437[128] = CP437;
+const u16 codepage_437[160] = CP437;

  static struct capitalization_table capitalization_table[] =
  #ifdef CONFIG_EFI_UNICODE_CAPITALIZATION
@@ -517,9 +517,12 @@ int utf_to_cp(s32 *c, const u16 *codepage)


This functions is used by the implementation of the Unicode Collation
Protocol.

In lib/efi_selftest/efi_selftest_unicode_collation.c, function
test_str_to_fat() we should test that the added Unicode characters are
translated to '_' and not to control codes (< 0x20).

Best regards

Heinrich


int j;

/* Look up codepage translation */
-   for (j = 0; j < 0x80; ++j) {
+   for (j = 0; j < 0xA0; ++j) {
if (*c == codepage[j]) {
-   *c = j + 0x80;
+   if (j < 0x20)
+   *c = j;
+   else
+   *c = j + 0x60;
return 0;
}
}
diff --git a/lib/efi_loader/efi_unicode_collation.c 
b/lib/efi_loader/efi_unicode_collation.c
index c4c7572063..4b2c52918a 100644
--- a/lib/efi_loader/efi_unicode_collation.c
+++ b/lib/efi_loader/efi_unicode_collation.c
@@ -257,7 +257,7 @@ static void EFIAPI efi_fat_to_str(struct 
efi_unicode_collation_protocol *this,
for (i = 0; i < fat_size; ++i) {
c = (unsigned char)fat[i];
if (c > 0x80)
-   c = codepage[c - 0x80];
+   c = codepage[c - 0x60];
string[i] = c;
if (!c)
break;

Re: [PATCH v2 2/6] video: console: Parse UTF-8 character sequences


On 10.02.24 13:46, Janne Grunau via B4 Relay wrote:

From: Janne Grunau 

efi_console / UEFI applications (grub2, sd-boot, ...) pass UTF-8
character sequences to vidconsole which results in wrong glyphs for code
points outside of ASCII. The truetype console expects Unicode code
points and bitmap font based consoles expect code page 437 code points.
To support both convert UTF-8 to UTF-32 and pass Unicode code points in
vidconsole_ops.putc_xy(). These can be used directly in console_truetype
and after conversion to code page 437 in console_{normal,rotate}.

This fixes rendering of international, symbol and box drawing characters
used by UEFI applications.

Signed-off-by: Janne Grunau 
---
  drivers/video/console_normal.c  |  6 --
  drivers/video/console_rotate.c  | 16 ++--
  drivers/video/console_truetype.c|  8 
  drivers/video/vidconsole-uclass.c   | 18 +-
  drivers/video/vidconsole_internal.h | 15 +++
  include/video_console.h | 10 ++
  6 files changed, 52 insertions(+), 21 deletions(-)

diff --git a/drivers/video/console_normal.c b/drivers/video/console_normal.c
index a0231293f3..34ef5a5229 100644
--- a/drivers/video/console_normal.c
+++ b/drivers/video/console_normal.c
@@ -7,6 +7,7 @@
   */

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -63,7 +64,7 @@ static int console_move_rows(struct udevice *dev, uint rowdst,
return 0;
  }

-static int console_putc_xy(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy(struct udevice *dev, uint x_frac, uint y, int cp)
  {
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -73,8 +74,9 @@ static int console_putc_xy(struct udevice *dev, uint x_frac, 
uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int x, linenum, ret;
void *start, *line;
+   u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
-   (u8)ch * fontdata->char_pixel_bytes;
+   ch * fontdata->char_pixel_bytes;

if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
diff --git a/drivers/video/console_rotate.c b/drivers/video/console_rotate.c
index 65358a1c6e..e4303dfb36 100644
--- a/drivers/video/console_rotate.c
+++ b/drivers/video/console_rotate.c
@@ -7,6 +7,7 @@
   */

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -67,7 +68,7 @@ static int console_move_rows_1(struct udevice *dev, uint 
rowdst, uint rowsrc,
return 0;
  }

-static int console_putc_xy_1(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy_1(struct udevice *dev, uint x_frac, uint y, int cp)
  {
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -77,8 +78,9 @@ static int console_putc_xy_1(struct udevice *dev, uint 
x_frac, uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int x, linenum, ret;
void *start, *line;
+   u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
-   (u8)ch * fontdata->char_pixel_bytes;
+   ch * fontdata->char_pixel_bytes;

if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
@@ -145,7 +147,7 @@ static int console_move_rows_2(struct udevice *dev, uint 
rowdst, uint rowsrc,
return 0;
  }

-static int console_putc_xy_2(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy_2(struct udevice *dev, uint x_frac, uint y, int cp)
  {
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -155,8 +157,9 @@ static int console_putc_xy_2(struct udevice *dev, uint 
x_frac, uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int linenum, x, ret;
void *start, *line;
+   u8 ch = console_utf_to_cp437(cp);
uchar *pfont = fontdata->video_fontdata +
-   (u8)ch * fontdata->char_pixel_bytes;
+   ch * fontdata->char_pixel_bytes;

if (x_frac + VID_TO_POS(vc_priv->x_charsize) > vc_priv->xsize_frac)
return -EAGAIN;
@@ -227,7 +230,7 @@ static int console_move_rows_3(struct udevice *dev, uint 
rowdst, uint rowsrc,
return 0;
  }

-static int console_putc_xy_3(struct udevice *dev, uint x_frac, uint y, char ch)
+static int console_putc_xy_3(struct udevice *dev, uint x_frac, uint y, int cp)
  {
struct vidconsole_priv *vc_priv = dev_get_uclass_priv(dev);
struct udevice *vid = dev->parent;
@@ -237,8 +240,9 @@ static int console_putc_xy_3(struct udevice *dev, uint 
x_frac, uint y, char ch)
int pbytes = VNBYTES(vid_priv->bpix);
int linenum, x, ret;
void *start, *line;
+   u8 ch =

Re: [PATCH v2 1/6] lib: charset: Fix and extend utf8_to_utf32_stream() documentation


On 10.02.24 13:46, Janne Grunau via B4 Relay wrote:

From: Janne Grunau 

Suggested-by: Heinrich Schuchardt 
Signed-off-by: Janne Grunau 


Reviewed-by: Heinrich Schuchardt 


---
  include/charset.h | 14 --
  1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/charset.h b/include/charset.h
index 44034c71d3..f1050c903d 100644
--- a/include/charset.h
+++ b/include/charset.h
@@ -324,11 +324,21 @@ int utf_to_cp(s32 *c, const u16 *codepage);
  int utf8_to_cp437_stream(u8 c, char *buffer);

  /**
- * utf8_to_utf32_stream() - convert UTF-8 stream to UTF-32
+ * utf8_to_utf32_stream() - convert UTF-8 byte stream to Unicode code points
+ *
+ * The function is called for each byte @c in a UTF-8 stream. The byte is
+ * appended to the temporary storage @buffer until the UTF-8 stream in
+ * @buffer describes a Unicode code point.
+ *
+ * When a new code point has been decoded it is returned and buffer[0] is
+ * set to '\0', otherwise the return value is 0.
+ *
+ * The buffer must be at least 5 characters long. Before the first function
+ * invocation buffer[0] must be set to '\0'."
   *
   * @c:next UTF-8 character to convert
   * @buffer:   buffer, at least 5 characters
- * Return: next codepage 437 character or 0
+ * Return: Unicode code point or 0
   */
  int utf8_to_utf32_stream(u8 c, char *buffer);

Re: [PATCH 2/2] rockchip: rk3399: Update stack and bss addresses

2024-02-12 Thread Quentin Schulz

Hi Jonas,

On 2/12/24 12:08, Jonas Karlman wrote:

Hi Quentin,

On 2024-02-12 11:37, Quentin Schulz wrote:

Hi Jonas,

On 2/12/24 01:59, Jonas Karlman wrote:

With the stack and text base used by U-Boot SPL and proper on RK3399
there is a high likelihood of overlapping when U-Boot proper + FDT nears
1 MiB in size.

Currently the following memory layout is used:
- 0x (@0 MiB): U-Boot SPL text base
- 0x0004 (@256 KiB): TF-A
- 0x0020 (@2 MiB): U-Boot proper text base
- 0x0030 (@3 MiB): U-Boot proper init stack
- 0x0040 (@4 MiB): U-Boot SPL init stack
- 0x0040 (@4 MiB): U-Boot SPL bss
- 0x0200 (@64 MiB): U-Boot SPL reloc stack
- 0x0840 (@132 MiB): optional OPTEE

SPL load TF-A, U-Boot proper and optional OPTEE after SPL stack has
relocated, meaning that there is room for close to 2 MiB (@2-4 MiB).
However, the initial stack used by U-Boot proper is limiting the size
of U-Boot proper + FDT to below 1 MiB (@2-3 MiB).

Instead change to use the following memory layout:
- 0x (@0 MiB): U-Boot SPL text base
- 0x0004 (@256 KiB): TF-A
- 0x0020 (@2 MiB): U-Boot proper text base
- 0x0040 (@4 MiB): U-Boot SPL init stack
- 0x0080 (@8 MiB): U-Boot proper init stack (changed)
- 0x0200 (@32 MiB): U-Boot SPL bss (changed)
- 0x0400 (@64 MiB): U-Boot SPL reloc stack
- 0x0840 (@132 MiB): optional OPTEE

This should leave room for loading and running a U-Boot proper close
to 6 MiB (@2-8 MiB) in size. When U-Boot proper has relocated is should
be possible to use @2-132 MiB and @164 MiB+ for scripts, kernel etc.

With the moved SPL reloc stack it is also possible to use a much larger
malloc area in SPL, e.g. using default SPL_STACK_R_MALLOC_SIMPLE_LEN.

Signed-off-by: Jonas Karlman

Do we not need to update memory addresses in the environment as well?

The addresses in environment is to my knowledge only used in U-Boot
proper after relocation. And at that time we should be free to use @2+
MiB up to somewhere close to gd ram_top/relocaddr. The optional Rockchip
OPTEE blobb may occupy @132-164 MiB, but I do not think loading OPTEE
blobs works as-is, so that may not be a big issue.

Upstream OP-TEE OS seems to support RK3399, c.f.
https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-rockchip/platform_rk3399.c

I cannot say whether it works, I have no knowledge of any of our
customers using it (but that predates my joining Theobroma, so maybe
long time customers do use it?). However, we do use an upstream-based
OP-TEE OS for one of our PX30-based boards, so I would say Rockchip's
OP-TEE OS is not the only option so we shouldn't just disregard this
location in RAM... especially since ramdisk_addr_r starts at 96MiB. But
since we're not changing that location people who would have this
issue, would have encountered the issue by now already (provided they
load a ramdisk bigger than 36MiB). So let's ignore that one actually :)

So to my knowledge we do not need to update any of the memory addresses
in the environment as well.

scriptaddr=0x0050

This is at 5MiB if I'm not mistaken?

Basically everything in include/configs/rk3399_common.h in
ENV_MEM_LAYOUT_SETTINGS needs to be updated to be located after 164MiB?

Did I misunderstand something? I find it weird the current values seems
to be located after U-Boot SPL bss and that e.g.

kernel_addr_r=0x0208

is at 32.5MiB, and with U-Boot SPL reloc stack currently at 64MiB... a
31.5+MiB kernel Image would mess up the data there? (what do we need it
for BTW once in U-boot proper after relocation?).

After SPL has jumped to TF-A and U-boot proper any memory used by SPL
can be overwritten/used for something else.

My understanding is as follow:
- SPL always need access to bss
- SPL need access to init stack until it has relocated to reloc stack
- SPL will load FIT images using the reloc stack, at this time only
SPL code, bss and reloc stack matters
- U-boot proper will use its init stack until it has relocated to end
of memory. Until U-Boot proper has relocated it will use init stack
- We could use same memory position for init stack for SPL and proper,
e.g. SPL_SHARES_INIT_SP_ADDR=y without any issue
- After U-Boot proper has relocated we should be free to use @2+ MiB
up to where U-Boot proper was relocated.

Not sure how Falcon boot fit in all of this and whether it makes use of
the environment variable (likely in the SPL binary itself).

Was this from experience and/or is there some literature in U-Boot git
repo already? Couldn't find much in the 5min I looked for it :)

Thanks for the taking the time to explain this, much appreciated.

Side question, what about making those values the default for RK3399
instead of having it in each defconfig? This could grow quickly out of
hands to move this to the Kconfig symbol itself, so not sure it's that
interesting to the project, but raising this anyway.

Agree, was trying to define these as defaults in soc Kconfig,

Re: [PATCH 3/3] ARM: renesas: Enable LTO on R-Car

2024-02-12 Thread Paul Barker

On 11/02/2024 17:34, Marek Vasut wrote:
> Enable LTO globally on Renesas R-Car platforms. This has been enabled
> on a subset of boards already, but at this point it is safe to enable
> it globally. This saves units or tens of kiB from the resulting build.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Niklas Söderlund 
> Cc: Paul Barker 
> ---
>  arch/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Paul Barker 


OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/3] ARM: renesas: Set R-Car Gen2 board size limit to 512 kiB

2024-02-12 Thread Paul Barker

On 11/02/2024 17:34, Marek Vasut wrote:
> The maximum size of u-boot.img on R-Car Gen2 is 0x8 or 512 kiB,
> set the limit to avoid overflows as new functionality gets pulled in.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Niklas Söderlund 
> Cc: Paul Barker 
> ---
>  Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Paul Barker 


OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/3] ARM: renesas: Disable EFI on R-Car Gen2

2024-02-12 Thread Paul Barker

On 11/02/2024 17:34, Marek Vasut wrote:
> These systems are unlikely to use EFI as this functionality has not been
> enabled until it got pulled in by Kconfig default. This functionality
> does add some 60-70 kiB to the u-boot.img size, which overflows the size
> limit. Disable it.
> 
> Signed-off-by: Marek Vasut 
> ---
> Cc: Niklas Söderlund 
> Cc: Paul Barker 
> ---
>  configs/alt_defconfig | 2 ++
>  configs/blanche_defconfig | 2 ++
>  configs/gose_defconfig| 2 ++
>  configs/koelsch_defconfig | 2 ++
>  configs/lager_defconfig   | 2 ++
>  configs/porter_defconfig  | 2 ++
>  configs/silk_defconfig| 2 ++
>  configs/stout_defconfig   | 2 ++
>  8 files changed, 16 insertions(+)

Reviewed-by: Paul Barker 

OpenPGP_0x27F4B3459F002257.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2] armv8: crypto: SHA-512 using ARMv8 Crypto Extensions

2024-02-12 Thread Ard Biesheuvel

On Mon, 12 Feb 2024 at 11:45, Igor Opaniuk  wrote:
>
> From: Igor Opaniuk 
>
> Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto
> Extensions. The CPU should support ARMv8.2 instruction set and implement
> SHA512H, SHA512H2, SHA512SU0, and SHA512SU1 instructions.
>
> This information can be obtained from ID_AA64ISAR0_EL1 (AArch64 Instruction
> Set Attribute Register 0), bits [15:12] should be 0b0010 [1], that
> indicates support for SHA512* instructions in AArch64 state. As not all
> ARMv8-base SoCs support that, ARMV8_CE_SHA512 is left disabled by
> default for now.
>
> Validated in QEMU for ARMv8 with compiled-in SHA-2 support (because of
> absence of hw with ARMv8.2-A ready SoC at hand):
>
> => hash sha512 0x4020 0x200
> sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37...
>
> The implementation is based on original implementation from Ard Biesheuvel in
> Linux kernel [2]
>
> [1] 
> https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0
> [2] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/crypto/sha2-ce-core.S
>
> CC: Ard Biesheuvel >
> CC: Loic Poulain 
> Signed-off-by: Igor Opaniuk 
> ---
>
> Changes in v2:
> - Dropped "Default n" in Kconfig as Michal Simek suggested
> - Adjusted commit message about QEMU validation
>
>  arch/arm/cpu/armv8/Kconfig  |   4 +
>  arch/arm/cpu/armv8/Makefile |   1 +
>  arch/arm/cpu/armv8/sha512_ce_core.S | 210 
>  arch/arm/cpu/armv8/sha512_ce_glue.c |  20 +++
>  lib/sha512.c|   6 +-
>  5 files changed, 239 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/cpu/armv8/sha512_ce_core.S
>  create mode 100644 arch/arm/cpu/armv8/sha512_ce_glue.c
>
> diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
> index 9f0fb369f7..37b8b60914 100644
> --- a/arch/arm/cpu/armv8/Kconfig
> +++ b/arch/arm/cpu/armv8/Kconfig
> @@ -204,6 +204,10 @@ config ARMV8_CE_SHA256
> bool "SHA-256 digest algorithm (ARMv8 Crypto Extensions)"
> default y if SHA256
>
> +config ARMV8_CE_SHA512
> +   bool "SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
> +   depends on SHA512
> +
>  endif
>
>  endif
> diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
> index bba4f570db..3894f2bb2a 100644
> --- a/arch/arm/cpu/armv8/Makefile
> +++ b/arch/arm/cpu/armv8/Makefile
> @@ -45,3 +45,4 @@ obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/
>  obj-$(CONFIG_XEN) += xen/
>  obj-$(CONFIG_ARMV8_CE_SHA1) += sha1_ce_glue.o sha1_ce_core.o
>  obj-$(CONFIG_ARMV8_CE_SHA256) += sha256_ce_glue.o sha256_ce_core.o
> +obj-$(CONFIG_ARMV8_CE_SHA512) += sha512_ce_glue.o sha512_ce_core.o
> \ No newline at end of file
> diff --git a/arch/arm/cpu/armv8/sha512_ce_core.S 
> b/arch/arm/cpu/armv8/sha512_ce_core.S
> new file mode 100644
> index 00..906291f35b
> --- /dev/null
> +++ b/arch/arm/cpu/armv8/sha512_ce_core.S
> @@ -0,0 +1,210 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * sha512-ce-core.S - core SHA-384/SHA-512 transform using v8 Crypto
> + * Extensions
> + *
> + * Copyright (C) 2018 Linaro Ltd 
> + * Copyright (C) 2024 Igor Opaniuk 
> + */
> +
> + #include 
> + #include 
> + #include 
> + #include 
> +
> +   .macro  adr_l, dst, sym
> +   adrp\dst, \sym
> +   add \dst, \dst, :lo12:\sym
> +   .endm
> +
> +   .irpb,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19
> +   .set.Lq\b, \b
> +   .set.Lv\b\().2d, \b
> +   .endr
> +
> +   .macro  sha512h, rd, rn, rm
> +   .inst   0xce608000 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> +   .endm
> +
> +   .macro  sha512h2, rd, rn, rm
> +   .inst   0xce608400 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> +   .endm
> +
> +   .macro  sha512su0, rd, rn
> +   .inst   0xcec08000 | .L\rd | (.L\rn << 5)
> +   .endm
> +
> +   .macro  sha512su1, rd, rn, rm
> +   .inst   0xce608800 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
> +   .endm
> +

You might check which binutils version supports these instructions
natively, and whether anything older is still supported by u-boot. If
not, you can just drop these macros.

> +   /*
> +* The SHA-512 round constants
> +*/
> +   .section".rodata", "a"
> +   .align  4
> +.Lsha512_rcon:
> +   .quad   0x428a2f98d728ae22, 0x7137449123ef65cd
> +   .quad   0xb5c0fbcfec4d3b2f, 0xe9b5dba58189dbbc
> +   .quad   0x3956c25bf348b538, 0x59f111f1b605d019
> +   .quad   0x923f82a4af194f9b, 0xab1c5ed5da6d8118
> +   .quad   0xd807aa98a3030242, 0x12835b0145706fbe
> +   .quad   0x243185be4ee4b28c, 0x550c7dc3d5ffb4e2
> +   .quad   0x72be5d74f27b896f, 0x80deb1fe3b1696b1
> +   .quad

Re: [PATCH v2] armv8: crypto: SHA-512 using ARMv8 Crypto Extensions

2024-02-12 Thread Michal Simek





On 2/12/24 11:45, Igor Opaniuk wrote:

From: Igor Opaniuk 

Add support for the SHA-512 Secure Hash Algorithm which uses ARMv8 Crypto
Extensions. The CPU should support ARMv8.2 instruction set and implement
SHA512H, SHA512H2, SHA512SU0, and SHA512SU1 instructions.

This information can be obtained from ID_AA64ISAR0_EL1 (AArch64 Instruction
Set Attribute Register 0), bits [15:12] should be 0b0010 [1], that
indicates support for SHA512* instructions in AArch64 state. As not all
ARMv8-base SoCs support that, ARMV8_CE_SHA512 is left disabled by
default for now.

Validated in QEMU for ARMv8 with compiled-in SHA-2 support (because of
absence of hw with ARMv8.2-A ready SoC at hand):

=> hash sha512 0x4020 0x200
sha512 for 4020 ... 421f ==> 1aeae269f4eb7c37...

The implementation is based on original implementation from Ard Biesheuvel in
Linux kernel [2]

[1] 
https://developer.arm.com/documentation/ddi0601/2023-12/AArch64-Registers/ID-AA64ISAR0-EL1--AArch64-Instruction-Set-Attribute-Register-0
[2] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/crypto/sha2-ce-core.S

CC: Ard Biesheuvel >
CC: Loic Poulain 
Signed-off-by: Igor Opaniuk 
---

Changes in v2:
- Dropped "Default n" in Kconfig as Michal Simek suggested
- Adjusted commit message about QEMU validation

  arch/arm/cpu/armv8/Kconfig  |   4 +
  arch/arm/cpu/armv8/Makefile |   1 +
  arch/arm/cpu/armv8/sha512_ce_core.S | 210 
  arch/arm/cpu/armv8/sha512_ce_glue.c |  20 +++
  lib/sha512.c|   6 +-
  5 files changed, 239 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/cpu/armv8/sha512_ce_core.S
  create mode 100644 arch/arm/cpu/armv8/sha512_ce_glue.c

diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 9f0fb369f7..37b8b60914 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -204,6 +204,10 @@ config ARMV8_CE_SHA256
bool "SHA-256 digest algorithm (ARMv8 Crypto Extensions)"
default y if SHA256
  
+config ARMV8_CE_SHA512

+   bool "SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
+   depends on SHA512
+
  endif
  
  endif

diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index bba4f570db..3894f2bb2a 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -45,3 +45,4 @@ obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/
  obj-$(CONFIG_XEN) += xen/
  obj-$(CONFIG_ARMV8_CE_SHA1) += sha1_ce_glue.o sha1_ce_core.o
  obj-$(CONFIG_ARMV8_CE_SHA256) += sha256_ce_glue.o sha256_ce_core.o
+obj-$(CONFIG_ARMV8_CE_SHA512) += sha512_ce_glue.o sha512_ce_core.o
\ No newline at end of file


Add that newline here.


M

Re: [PATCH 2/2] rockchip: rk3399: Update stack and bss addresses

2024-02-12 Thread Jonas Karlman

Hi Quentin,

On 2024-02-12 11:37, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 2/12/24 01:59, Jonas Karlman wrote:
>> With the stack and text base used by U-Boot SPL and proper on RK3399
>> there is a high likelihood of overlapping when U-Boot proper + FDT nears
>> 1 MiB in size.
>>
>> Currently the following memory layout is used:
>> - 0x (@0 MiB): U-Boot SPL text base
>> - 0x0004 (@256 KiB): TF-A
>> - 0x0020 (@2 MiB): U-Boot proper text base
>> - 0x0030 (@3 MiB): U-Boot proper init stack
>> - 0x0040 (@4 MiB): U-Boot SPL init stack
>> - 0x0040 (@4 MiB): U-Boot SPL bss
>> - 0x0200 (@64 MiB): U-Boot SPL reloc stack
>> - 0x0840 (@132 MiB): optional OPTEE
>>
>> SPL load TF-A, U-Boot proper and optional OPTEE after SPL stack has
>> relocated, meaning that there is room for close to 2 MiB (@2-4 MiB).
>> However, the initial stack used by U-Boot proper is limiting the size
>> of U-Boot proper + FDT to below 1 MiB (@2-3 MiB).
>>
>> Instead change to use the following memory layout:
>> - 0x (@0 MiB): U-Boot SPL text base
>> - 0x0004 (@256 KiB): TF-A
>> - 0x0020 (@2 MiB): U-Boot proper text base
>> - 0x0040 (@4 MiB): U-Boot SPL init stack
>> - 0x0080 (@8 MiB): U-Boot proper init stack (changed)
>> - 0x0200 (@32 MiB): U-Boot SPL bss (changed)
>> - 0x0400 (@64 MiB): U-Boot SPL reloc stack
>> - 0x0840 (@132 MiB): optional OPTEE
>>
>> This should leave room for loading and running a U-Boot proper close
>> to 6 MiB (@2-8 MiB) in size. When U-Boot proper has relocated is should
>> be possible to use @2-132 MiB and @164 MiB+ for scripts, kernel etc.
>>
>> With the moved SPL reloc stack it is also possible to use a much larger
>> malloc area in SPL, e.g. using default SPL_STACK_R_MALLOC_SIMPLE_LEN.
>>
>> Signed-off-by: Jonas Karlman 
> 
> Do we not need to update memory addresses in the environment as well?

The addresses in environment is to my knowledge only used in U-Boot
proper after relocation. And at that time we should be free to use @2+
MiB up to somewhere close to gd ram_top/relocaddr. The optional Rockchip
OPTEE blobb may occupy @132-164 MiB, but I do not think loading OPTEE
blobs works as-is, so that may not be a big issue.

So to my knowledge we do not need to update any of the memory addresses
in the environment as well.

> 
> scriptaddr=0x0050
> 
> This is at 5MiB if I'm not mistaken?
> 
> Basically everything in include/configs/rk3399_common.h in 
> ENV_MEM_LAYOUT_SETTINGS needs to be updated to be located after 164MiB?
> 
> Did I misunderstand something? I find it weird the current values seems 
> to be located after U-Boot SPL bss and that e.g.
> 
> kernel_addr_r=0x0208
> 
> is at 32.5MiB, and with U-Boot SPL reloc stack currently at 64MiB... a 
> 31.5+MiB kernel Image would mess up the data there? (what do we need it 
> for BTW once in U-boot proper after relocation?).

After SPL has jumped to TF-A and U-boot proper any memory used by SPL
can be overwritten/used for something else.

My understanding is as follow:
- SPL always need access to bss
- SPL need access to init stack until it has relocated to reloc stack
- SPL will load FIT images using the reloc stack, at this time only
  SPL code, bss and reloc stack matters
- U-boot proper will use its init stack until it has relocated to end
  of memory. Until U-Boot proper has relocated it will use init stack
- We could use same memory position for init stack for SPL and proper,
  e.g. SPL_SHARES_INIT_SP_ADDR=y without any issue
- After U-Boot proper has relocated we should be free to use @2+ MiB
  up to where U-Boot proper was relocated.

> 
> Side question, what about making those values the default for RK3399 
> instead of having it in each defconfig? This could grow quickly out of 
> hands to move this to the Kconfig symbol itself, so not sure it's that 
> interesting to the project, but raising this anyway.

Agree, was trying to define these as defaults in soc Kconfig, but that
rearranged some values in other defconfigs so I avoided doing that in
this series. Also touching each defconfig helped me ping board
maintainers of the change.

Hopefully a follow-up series can move these, and other options, into
soc Kconfig.

Regards,
Jonas

> 
> Cheers,
> Quentin

Pull request: Please pull u-boot-imx-master-20240212

Hi Tom,

Please pull from u-boot-imx, thanks.

The following changes since commit d7aaaf4223d0a2f9f8c9eed47d7431860b3116d8:

  Merge tag 'u-boot-dfu-20240209' of 
https://source.denx.de/u-boot/custodians/u-boot-dfu (2024-02-09 09:00:42 -0500)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git 
tags/u-boot-imx-master-20240212

for you to fetch changes up to fcd377ed6480643b1f79188c7a8fb9280a211b4f:

  configs: imx93_var_som: Enable AHAB support (2024-02-10 15:16:13 -0300)

u-boot-imx-master-20240212
--

CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19583

- Fix the i.MX8MP SPI compatible string.
- Let the SPL clock code do the configuration on Data Modul i.MX8M Plus eDM SBC.
- Enable secure boot on the imx93_var_som board.

Marek Vasut (2):
  ARM: imx: Let SPL configure ECSPI1 clock on Data Modul i.MX8M Plus eDM SBC
  spi: mxc_spi: Add imx6ul-ecspi compatible string

Mathieu Othacehe (3):
  imx93: Use a header for imx9_probe_mu declaration
  board: imx93_var_som: Probe ELE MU
  configs: imx93_var_som: Enable AHAB support

 arch/arm/dts/imx8mp-data-modul-edm-sbc-u-boot.dtsi |  3 +++
 arch/arm/include/asm/arch-imx9/mu.h| 13 +
 board/freescale/imx93_evk/spl.c|  2 +-
 board/phytec/phycore_imx93/spl.c   |  2 +-
 board/variscite/imx93_var_som/spl.c|  5 +++--
 configs/imx93_var_som_defconfig|  1 +
 drivers/spi/mxc_spi.c  |  1 +
 7 files changed, 23 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-imx9/mu.h

Re: [PATCH v2 0/3] imx93_var_som: Enable AHAB support

On Fri, Feb 9, 2024 at 7:30 AM Mathieu Othacehe  wrote:
>
> Hello,
>
> In this v2, I moved imx93_probe_mu to a dedicated header.

Applied all, thanks.

Re: [PATCH v2] spi: mxc_spi: Add imx6ul-ecspi compatible string

On Thu, Feb 8, 2024 at 9:00 PM Marek Vasut  wrote:
>
> Recent i.MX8MP DTs use new fsl,imx6ul-ecspi compatible string instead
> of the fsl,imx51-ecspi compatible string. Add the new compatible string
> to fix ECSPI operation on i.MX8MP.
>
> For details, see Linux:
> 48d74376fb68 ("arm64: dts: imx8mp: update ecspi compatible and clk")
> 8eb1252bbedf ("spi: imx: remove ERR009165 workaround on i.mx6ul")
>
> Fixes: 451799a6ceac ("arm: dts: imx8mp: Sync the DT with kernel 6.4-rc4")
> Reviewed-by: Fabio Estevam 
> Signed-off-by: Marek Vasut 

Applied, thanks.

Re: [PATCH] ARM: imx: Let SPL configure ECSPI1 clock on Data Modul i.MX8M Plus eDM SBC