date:20240222


On 2/22/24 17:18, Bob Wolff wrote:

If mixed rsa and ecdsa keys are specified in dtsi, an rsa key can be sent
into the ecdsa verify. Without the ecdsa,curve property, this function will
crash due to lack of checking the null pointer return.


nit: there should be a blank line here


Signed-off-by: Bob Wolff 
---

  lib/ecdsa/ecdsa-verify.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/lib/ecdsa/ecdsa-verify.c b/lib/ecdsa/ecdsa-verify.c
index 0601700c4f..4d1835b598 100644
--- a/lib/ecdsa/ecdsa-verify.c
+++ b/lib/ecdsa/ecdsa-verify.c
@@ -31,6 +31,11 @@ static int fdt_get_key(struct ecdsa_public_key *key, const 
void *fdt, int node)
int x_len, y_len;
  
  	key->curve_name = fdt_getprop(fdt, node, "ecdsa,curve", NULL);

+   if (!key->curve_name) {
+   debug("Error: ecdsa cannot get 'ecdsa,curve' property from key. 
Likely not an ecdsa key.\n");
+   return -ENOMSG;
+   }
+
key->size_bits = ecdsa_key_size(key->curve_name);
if (key->size_bits == 0) {
debug("Unknown ECDSA curve '%s'", key->curve_name);


Reviewed-by: Sean Anderson

Re: ECDSA related PRs

2024-02-22 Thread Bob Wolff

Peter,
Thanks for helping lead me down the right path here.

WRT tinycrypt, the license is quite permissive.
https://github.com/intel/tinycrypt

Also, I'd like your advice - I was thinking for the larger patch that I'd
do it in two commits. The first would be the addition of the tinycrypt
files and the second is the actual changes and additions to support ecdsa
verification. I doubt that's controversial. However when I run a trial
`patman` against the tinycrypt commit, I geta huge number of issues:
*checkpatch.pl  found 186 error(s), 380
warning(s), 481 checks(s)*

What's your advice on this? I would tend to think we'd want to /not/ change
the source files directly for such purposes so that updates could be
brought in with greater ease.

Let me know your thoughts.

Thanks,
Bob Wolff

On Wed, Feb 21, 2024 at 6:03 AM Peter Robinson  wrote:

>
>
> On Wed, 21 Feb 2024, 11:30 Bob Wolff,  wrote:
>
>> Hi there,
>> I have two separate but related pull requests I'd like to contribute. They
>> both have to do with ECDSA support.
>> - The simple one is a lack of null-pointer check that can cause a crash in
>> certain situations. Easy peasy.
>>
>
> Just send that one on it's own
>
> - The less simple one (and hopefully not too controversial) adds an ecdsa
>> verify driver (UCLASS_ECDSA) which utilizes tinycrypt to do the crypto
>> work.
>>
>
> Do we already use tiny crypt in the project, if not things like license
> need to be taken into account in the context of the GPLv2
>
> Please advise on how best to proceed. Happy to work within the confines of
>> what works best for the larger group.
>>
>> Thanks,
>> Bob Wolff
>>
>

[PATCH] Check curve_name for null to avoid crash

2024-02-22 Thread Bob Wolff

If mixed rsa and ecdsa keys are specified in dtsi, an rsa key can be sent
into the ecdsa verify. Without the ecdsa,curve property, this function will
crash due to lack of checking the null pointer return.
Signed-off-by: Bob Wolff 
---

 lib/ecdsa/ecdsa-verify.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/ecdsa/ecdsa-verify.c b/lib/ecdsa/ecdsa-verify.c
index 0601700c4f..4d1835b598 100644
--- a/lib/ecdsa/ecdsa-verify.c
+++ b/lib/ecdsa/ecdsa-verify.c
@@ -31,6 +31,11 @@ static int fdt_get_key(struct ecdsa_public_key *key, const 
void *fdt, int node)
int x_len, y_len;
 
key->curve_name = fdt_getprop(fdt, node, "ecdsa,curve", NULL);
+   if (!key->curve_name) {
+   debug("Error: ecdsa cannot get 'ecdsa,curve' property from key. 
Likely not an ecdsa key.\n");
+   return -ENOMSG;
+   }
+
key->size_bits = ecdsa_key_size(key->curve_name);
if (key->size_bits == 0) {
debug("Unknown ECDSA curve '%s'", key->curve_name);
-- 
2.39.3 (Apple Git-145)

[RESEND PATCH v2] arm64: zynqmp: Support semihosting boot method

Currently, when we boot from JTAG we try to boot U-Boot from RAM.
However, this is a bit tricky to time, since the debugger has to wait
for SPL to initialize RAM before it can load U-Boot. This can result in
long waits, since occasionally initializing RAM (and other things in
psu_init) takes a long time to complete and the debugger must wait for
this worst case.

Support semihosting if it is enabled, as it lets U-Boot tell the
debugger when we are ready for the image. This means we don't have to
wait any more than necessary. We don't change the default config to
ensure we don't break compatibility with existing debuggers that don't
expect us to hit semihosting breakpoints.

Signed-off-by: Sean Anderson 
---
I'm resending this from my linux.dev email as my regular email is
mangling my patches.

Changes in v2:
- Fix typo in subject

 arch/arm/mach-zynqmp/spl.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index a0f35f36faa..5af735aa5ce 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +67,11 @@ void spl_board_init(void)
 }
 #endif
 
+static u32 jtag_boot_device(void)
+{
+   return semihosting_enabled() ? BOOT_DEVICE_SMH : BOOT_DEVICE_RAM;
+}
+
 void board_boot_order(u32 *spl_boot_list)
 {
spl_boot_list[0] = spl_boot_device();
@@ -75,7 +81,7 @@ void board_boot_order(u32 *spl_boot_list)
if (spl_boot_list[0] == BOOT_DEVICE_MMC2)
spl_boot_list[1] = BOOT_DEVICE_MMC1;
 
-   spl_boot_list[2] = BOOT_DEVICE_RAM;
+   spl_boot_list[2] = jtag_boot_device();
 }
 
 u32 spl_boot_device(void)
@@ -97,7 +103,7 @@ u32 spl_boot_device(void)
 
switch (bootmode) {
case JTAG_MODE:
-   return BOOT_DEVICE_RAM;
+   return jtag_boot_device();
 #ifdef CONFIG_SPL_MMC
case SD_MODE1:
case SD1_LSHFT_MODE: /* not working on silicon v1 */
-- 
2.35.1.1320.gc452695387.dirty

Re: [PATCH v2] arm64: zynqmp: Support semihosting boot method

On 2/22/24 14:36, Fabio Estevam wrote:
> On Thu, Feb 22, 2024 at 1:53 PM Sean Anderson  wrote:
>>
>> From: Sean Anderson 
> ...
>> Signed-off-by: Sean Anderson 
>> ---
>> I'm resending this from my linux.dev email as my regular email is
>> mangling my patches.
> 
> That's OK, but you need to make sure that the From and Signed-off-by
> fields match.
> 
> Otherwise, checkpatch complains.

Yeah, I thought I had fixed the authors, but I guess not.

--Sean

Re: [PATCH v2] arm64: zynqmp: Support semihosting boot method

2024-02-22 Thread Fabio Estevam

On Thu, Feb 22, 2024 at 1:53 PM Sean Anderson  wrote:
>
> From: Sean Anderson 
...
> Signed-off-by: Sean Anderson 
> ---
> I'm resending this from my linux.dev email as my regular email is
> mangling my patches.

That's OK, but you need to make sure that the From and Signed-off-by
fields match.

Otherwise, checkpatch complains.

Re: [PATCH 11/16] rockchip: adc: rockchip-saradc: add support for RK3588


Hi all,

On 2/21/24 18:07, Quentin Schulz wrote:

From: Quentin Schulz 

This adds support for the SARADCv2 found on RK3588.

There is no stop callback as it is currently configured in single
conversion mode, where the ADC is powered down after a single conversion
has been made.

Cc: Quentin Schulz 
Signed-off-by: Quentin Schulz 
---
  drivers/adc/rockchip-saradc.c | 76 ++-
  1 file changed, 75 insertions(+), 1 deletion(-)

diff --git a/drivers/adc/rockchip-saradc.c b/drivers/adc/rockchip-saradc.c
index b5df58fe3eb..05c93cedcf1 100644
--- a/drivers/adc/rockchip-saradc.c
+++ b/drivers/adc/rockchip-saradc.c
@@ -10,7 +10,8 @@
  #include 
  #include 
  #include 
-#include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -30,8 +31,37 @@ struct rockchip_saradc_regs_v1 {
unsigned int dly_pu_soc;
  };
  
+struct rockchip_saradc_regs_v2 {

+   unsigned int conv_con;
+#define SARADC2_SINGLE_MODEBIT(5)
+#define SARADC2_START  BIT(4)
+#define SARADC2_CONV_CHANNELS  GENMASK(3, 0)
+   unsigned int t_pd_soc;
+   unsigned int t_as_soc;
+   unsigned int t_das_soc;
+   unsigned int t_sel_soc;
+   unsigned int high_comp[16];
+   unsigned int low_comp[16];
+   unsigned int debounce;
+   unsigned int ht_int_en;
+   unsigned int lt_int_en;
+   unsigned int reserved[24];
+   unsigned int mt_int_en;
+   unsigned int end_int_en;
+#define SARADC2_EN_END_INT BIT(0)
+   unsigned int st_con;
+   unsigned int status;
+   unsigned int end_int_st;
+   unsigned int ht_int_st;
+   unsigned int lt_int_st;
+   unsigned int mt_int_st;
+   unsigned int data[16];
+   unsigned int auto_ch_en;
+};
+
  union rockchip_saradc_regs {
struct rockchip_saradc_regs_v1  *v1;
+   struct rockchip_saradc_regs_v2  *v2;
  };
  struct rockchip_saradc_data {
int num_bits;
@@ -66,6 +96,22 @@ int rockchip_saradc_channel_data_v1(struct udevice *dev, int 
channel,
return 0;
  }
  
+int rockchip_saradc_channel_data_v2(struct udevice *dev, int channel,

+   unsigned int *data)
+{
+   struct rockchip_saradc_priv *priv = dev_get_priv(dev);
+
+   if (!(readl(&priv->regs.v2->end_int_st) & SARADC2_EN_END_INT))
+   return -EBUSY;
+
+   /* Read value */
+   *data = readl(&priv->regs.v2->data[channel]);
+
+   /* Acknowledge the interrupt */
+   writel(SARADC2_EN_END_INT, &priv->regs.v2->end_int_st);
+
+   return 0;
+}
  int rockchip_saradc_channel_data(struct udevice *dev, int channel,
 unsigned int *data)
  {
@@ -104,6 +150,24 @@ int rockchip_saradc_start_channel_v1(struct udevice *dev, 
int channel)
return 0;
  }
  
+int rockchip_saradc_start_channel_v2(struct udevice *dev, int channel)

+{
+   struct rockchip_saradc_priv *priv = dev_get_priv(dev);
+
+   writel(0xc, &priv->regs.v2->t_das_soc);
+   writel(0x20, &priv->regs.v2->t_pd_soc);
+
+   /* Acknowledge any previous interrupt */
+   writel(SARADC2_EN_END_INT, &priv->regs.v2->end_int_st);
+
+   rk_setreg(&priv->regs.v2->conv_con,
+ FIELD_PREP(SARADC2_CONV_CHANNELS, channel) |
+ FIELD_PREP(SARADC2_START, 1) |
+ FIELD_PREP(SARADC2_SINGLE_MODE, 1));
+


This is incorrect because we need to also write zeroes in the 
SARADC2_CONV_CHANNELS bitfield and rk_setreg takes the argument and 
shifts it by 16 for the write_enable mask, not taking into account the 
mask in which those bits are set. Will send a v2 soon, trying to figure 
out why this isn't an issue in Linux kernel which is using the same 
logic


Cheers,
Quentin

Re: [PATCH] cmd: eeprom: Fix config dependency

2024-02-22 Thread Tom Rini

On Mon, Feb 19, 2024 at 06:18:38PM +, Ivan Orlov wrote:

> We should have CONFIG_DM_I2C or CONFIG_(SPL_)SYS_I2C_LEGACY enabled in
> order for `cmd/eeprom.c` to compile as it depends on the i2c functions
> which are not compiled otherwise. Update the Kconfig entry for the
> 'eeprom' command correspondingly.
> 
> Signed-off-by: Ivan Orlov 
> ---
>  cmd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index a86b570517..6a1a64566c 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -740,6 +740,7 @@ config CRC32_VERIFY
>  
>  config CMD_EEPROM
>   bool "eeprom - EEPROM subsystem"
> + depends on DM_I2C || SYS_I2C_LEGACY || SPL_SYS_I2C_LEGACY

You cannot enable commands in SPL, so SPL_SYS_I2C_LEGACY doesn't make
sense here.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] arm64: zynqmp: Support semhosting boot method

On 2/22/24 05:34, Michal Simek wrote:
>
>
> On 2/20/24 20:30, Sean Anderson wrote:
>> On 2/20/24 14:18, Michal Simek wrote:
>>>
>>>
>>> On 2/20/24 19:43, Sean Anderson wrote:
 On 2/20/24 13:24, Michal Simek wrote:
>
>
> On 2/16/24 17:09, Sean Anderson wrote:
>> On 2/16/24 11:03, Sean Anderson wrote:
>>> On 2/16/24 10:06, Michal Simek wrote:


 On 2/16/24 14:48, Michal Simek wrote:
>
>
> On 2/15/24 20:31, Sean Anderson wrote:
>> On 2/15/24 14:08, Michal Simek wrote:
>>>
>>>
>>> On 2/15/24 18:19, Sean Anderson wrote:
 Currently, when we boot from JTAG we try to boot U-Boot from RAM.
 However, this is a bit tricky to time, since the debugger has to 
 wait
 for SPL to initialize RAM before it can load U-Boot. This can 
 result in
 long waits, since occasionally initializing RAM (and other things 
 in
 psu_init) takes a long time to complete and the debugger must wait 
 for
 this worst case.

 Support semihosting if it is enabled, as it lets U-Boot tell the
 debugger when we are ready for the image. This means we don't have 
 to
 wait any more than necessary. We don't change the default config to
 ensure we don't break compatibility with existing debuggers that 
 don't
 expect us to hit semihosting breakpoints.

 Signed-off-by: Sean Anderson 
 ---

   arch/arm/mach-zynqmp/spl.c | 10 --
   1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/mach-zynqmp/spl.c 
 b/arch/arm/mach-zynqmp/spl.c
 index a0f35f36faa..5af735aa5ce 100644
 --- a/arch/arm/mach-zynqmp/spl.c
 +++ b/arch/arm/mach-zynqmp/spl.c
 @@ -9,6 +9,7 @@
   #include 
   #include 
   #include 
 +#include 
   #include 
   #include 

 @@ -66,6 +67,11 @@ void spl_board_init(void)
   }
   #endif

 +static u32 jtag_boot_device(void)
 +{
 +   return semihosting_enabled() ? BOOT_DEVICE_SMH : 
 BOOT_DEVICE_RAM;
 +}
 +
   void board_boot_order(u32 *spl_boot_list)
   {
  spl_boot_list[0] = spl_boot_device();
 @@ -75,7 +81,7 @@ void board_boot_order(u32 *spl_boot_list)
  if (spl_boot_list[0] == BOOT_DEVICE_MMC2)
  spl_boot_list[1] = BOOT_DEVICE_MMC1;

 -   spl_boot_list[2] = BOOT_DEVICE_RAM;
 +   spl_boot_list[2] = jtag_boot_device();
   }

   u32 spl_boot_device(void)
 @@ -97,7 +103,7 @@ u32 spl_boot_device(void)

  switch (bootmode) {
  case JTAG_MODE:
 -   return BOOT_DEVICE_RAM;
 +   return jtag_boot_device();
   #ifdef CONFIG_SPL_MMC
  case SD_MODE1:
  case SD1_LSHFT_MODE: /* not working on silicon v1 */
>>>
>>> Good timing. Can you please tell me how to test this? What's the 
>>> setup?
>>> Which debugger are you using?
>>
>> I am using OpenOCD with the patches at 
>> https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2freview.openocd.org%2fc%2fopenocd%2f%2b%2f8133&umid=6e1be473-0b3f-4bc4-a4f0-403592e74baf&auth=d807158c60b7d2502abde8a2fc01f40662980862-afc15b07b0f91c910f832185958363d84f990a08
>>
>
> I am trying it on the top of the latest git but getting issue with 
> event block and no idea how to fix it.
>
> # sudo openocd -f 
> /usr/local/share/openocd/scripts/interface/ftdi/digilent_jtag_hs3.cfg 
> -f /usr/local/share/openocd/scripts/target/xilinx_zynqmp.cfg
> Open On-Chip Debugger 0.12.0+dev-01509-g6d288937cb2d 
> (2024-02-16-12:22)
> Licensed under GNU GPL v2
> For bug reports, read
> 
> https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fopenocd.org%2fdoc%2fdoxygen%2fbugs.html&umid=6e1be473-0b3f-4bc4-a4f0-403592e74baf&auth=d807158c60b7d2502abde8a2fc01f40662980862-f501ab9aa5516ff666e387e53598fd624398f1bc
> Info : auto-selecting first available session transport "jtag". To 
> override use 'transport select '.
> wrong # args: should be "-event  "
>
>
>

Re: [PULL] Please pull qcom/qcom-fixes-2024.04

2024-02-22 Thread Tom Rini

On Thu, Feb 22, 2024 at 04:08:45PM +, Caleb Connolly wrote:

> Hi Tom,
> 
> Just a few button fixes that I realise should probably make it in.
> 
> The following changes since commit 37345abb97ef0dd9c50a03b2a72617612dcae585:
> 
>   Prepare v2024.04-rc2 (2024-02-13 18:16:57 -0500)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:/u-boot/custodians/u-boot-snapdragon.git 
> qcom-fixes-2024.04
> 
> for you to fetch changes up to 22f391e8be11986bae824509470cf11e7bac31b0:
> 
>   button: qcom-pmic: demote "unknown button" message to debug (2024-02-14 
> 17:21:50 +)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

[PATCH v2] arm64: zynqmp: Support semihosting boot method

From: Sean Anderson 

Currently, when we boot from JTAG we try to boot U-Boot from RAM.
However, this is a bit tricky to time, since the debugger has to wait
for SPL to initialize RAM before it can load U-Boot. This can result in
long waits, since occasionally initializing RAM (and other things in
psu_init) takes a long time to complete and the debugger must wait for
this worst case.

Support semihosting if it is enabled, as it lets U-Boot tell the
debugger when we are ready for the image. This means we don't have to
wait any more than necessary. We don't change the default config to
ensure we don't break compatibility with existing debuggers that don't
expect us to hit semihosting breakpoints.

Signed-off-by: Sean Anderson 
---
I'm resending this from my linux.dev email as my regular email is
mangling my patches.

Changes in v2:
- Fix typo in subject

 arch/arm/mach-zynqmp/spl.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index a0f35f36faa..5af735aa5ce 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -66,6 +67,11 @@ void spl_board_init(void)
 }
 #endif
 
+static u32 jtag_boot_device(void)
+{
+   return semihosting_enabled() ? BOOT_DEVICE_SMH : BOOT_DEVICE_RAM;
+}
+
 void board_boot_order(u32 *spl_boot_list)
 {
spl_boot_list[0] = spl_boot_device();
@@ -75,7 +81,7 @@ void board_boot_order(u32 *spl_boot_list)
if (spl_boot_list[0] == BOOT_DEVICE_MMC2)
spl_boot_list[1] = BOOT_DEVICE_MMC1;
 
-   spl_boot_list[2] = BOOT_DEVICE_RAM;
+   spl_boot_list[2] = jtag_boot_device();
 }
 
 u32 spl_boot_device(void)
@@ -97,7 +103,7 @@ u32 spl_boot_device(void)
 
switch (bootmode) {
case JTAG_MODE:
-   return BOOT_DEVICE_RAM;
+   return jtag_boot_device();
 #ifdef CONFIG_SPL_MMC
case SD_MODE1:
case SD1_LSHFT_MODE: /* not working on silicon v1 */
-- 
2.35.1.1320.gc452695387.dirty

[PULL] Please pull qcom/qcom-fixes-2024.04

2024-02-22 Thread Caleb Connolly

Hi Tom,

Just a few button fixes that I realise should probably make it in.

The following changes since commit 37345abb97ef0dd9c50a03b2a72617612dcae585:

  Prepare v2024.04-rc2 (2024-02-13 18:16:57 -0500)

are available in the Git repository at:

  g...@source.denx.de:/u-boot/custodians/u-boot-snapdragon.git 
qcom-fixes-2024.04

for you to fetch changes up to 22f391e8be11986bae824509470cf11e7bac31b0:

  button: qcom-pmic: demote "unknown button" message to debug (2024-02-14 
17:21:50 +)


Caleb Connolly (1):
  button: qcom-pmic: demote "unknown button" message to debug

Dan Carpenter (1):
  button: qcom-pmic: fix some error checking

 drivers/button/button-qcom-pmic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH] arch: mach-k3: fix mapping higher DDR addresses as device memory

2024-02-22 Thread Nishanth Menon

On 12:15-20240222, Neha Malcom Francis wrote:
> From: Sekhar Nori 
> 
> An entry in memory map table for MMU configuration is spilling over and
> inadvertently mapping DDR available at higher address (above 4GB address
> space) as device memory (nGnRnE).
> 
> Fix this by adjusting entry size. Tested on AM62A SK by enabling
> CONFIG_CMD_TIME. Before this patch:
> 
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 5a7a5760
> 
> time: 1 minutes, 14.715 seconds
> 
> After patch:
> 
> => time crc32 0x88100 0x2000
> crc32 for 88100 ... 8a0ff ==> 3df1ce02
> 
> time: 2.711 seconds
> 
> Signed-off-by: Sekhar Nori 
> [n-fran...@ti.com: rebased on next, retested on all devices inc. commit]
> Signed-off-by: Neha Malcom Francis 
> Cc: Andrew Davis 
> ---
> Boot logs:
> https://gist.github.com/nehamalcom/7b101ea8b97f5a9433a553ef881166a1
> 
>  arch/arm/mach-k3/arm64-mmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-k3/arm64-mmu.c b/arch/arm/mach-k3/arm64-mmu.c
> index b4308205b2..0e07b1b7ce 100644
> --- a/arch/arm/mach-k3/arm64-mmu.c
> +++ b/arch/arm/mach-k3/arm64-mmu.c
> @@ -41,7 +41,7 @@ struct mm_region k3_mem_map[] = {
>   }, {
>   .virt = 0x5UL,
>   .phys = 0x5UL,
> - .size = 0x4UL,
> + .size = 0x38000UL,
>   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
> -- 
> 2.34.1
> 
https://lore.kernel.org/u-boot/20240119160900.GU12635@bill-the-cat/ ??

Something was missing?

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

[PATCH 2/2] chameleonv3: set in defconfig for FPGA to reprogram every reboot

2024-02-22 Thread Michał Barnaś

Set CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM as enabled in
chameleon v3 board's defconfig.

Signed-off-by: Michał Barnaś 
---

 configs/socfpga_chameleonv3_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_chameleonv3_defconfig 
b/configs/socfpga_chameleonv3_defconfig
index 6ea61ca6ea..25615bb4b4 100644
--- a/configs/socfpga_chameleonv3_defconfig
+++ b/configs/socfpga_chameleonv3_defconfig
@@ -7,6 +7,7 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_chameleonv3_480_2"
 CONFIG_SPL_TEXT_BASE=0xFFE0
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_TARGET_SOCFPGA_CHAMELEONV3=y
+CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM=y
 CONFIG_SPL_FS_FAT=y
 CONFIG_FIT=y
 CONFIG_SPL_FIT=y
-- 
2.44.0.rc1.240.g4c46232300-goog

[PATCH 1/2] arm: socfpga: arria10: add option to reprogram the FPGA every reboot

2024-02-22 Thread Michał Barnaś

Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
This option allows to change the bitstream on the filesystem and apply
changes with warm reboot without the need for a power cycle.

Signed-off-by: Michał Barnaś 
---

 arch/arm/mach-socfpga/Kconfig   | 8 
 arch/arm/mach-socfpga/spl_a10.c | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 114d243812..89303f1f16 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -80,6 +80,14 @@ config TARGET_SOCFPGA_ARRIA10
imply FPGA_SOCFPGA
imply SPL_USE_TINY_PRINTF
 
+config TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   bool "Always reprogram Arria 10 FPGA"
+   depends on TARGET_SOCFPGA_ARRIA10
+   help
+ Arria 10 FPGA is only programmed during the cold boot.
+ This option forces the FPGA to be reprogrammed every reboot,
+ allowing to change the bitstream and apply it with warm reboot.
+
 config TARGET_SOCFPGA_CYCLONE5
bool
select TARGET_SOCFPGA_GEN5
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index 9edbbf4a29..d5d3327a42 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -122,7 +122,11 @@ void spl_board_init(void)
arch_early_init_r();
 
/* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */
+#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   if (is_regular_boot_valid()) {
+#else
if (is_fpgamgr_user_mode()) {
+#endif
ret = config_pins(gd->fdt_blob, "shared");
if (ret)
return;
@@ -130,7 +134,11 @@ void spl_board_init(void)
ret = config_pins(gd->fdt_blob, "fpga");
if (ret)
return;
+#ifdef CONFIG_TARGET_SOCFPGA_ARRIA10_ALWAYS_REPROGRAM
+   } else {
+#else
} else if (!is_fpgamgr_early_user_mode()) {
+#endif
/* Program IOSSM(early IO release) or full FPGA */
fpgamgr_program(buf, FPGA_BUFSIZ, 0);
 
-- 
2.44.0.rc1.240.g4c46232300-goog

[PATCH 0/2] arm: socfpga: arria10: allow to reprogram FPGA with warm reboot

2024-02-22 Thread Michał Barnaś



By default, the board requires power cycle (cold boot) to program the
FPGA with bitstream. This change adds Kconfig that allows to enable
reprogramming the FPGA with every boot. This makes the update process
of the bitstream on the filesystem to be applied with simple system
reboot.


Michał Barnaś (2):
  arm: socfpga: arria10: add option to reprogram the FPGA every reboot
  chameleonv3: set in defconfig for FPGA to reprogram every reboot

 arch/arm/mach-socfpga/Kconfig | 8 
 arch/arm/mach-socfpga/spl_a10.c   | 8 
 configs/socfpga_chameleonv3_defconfig | 1 +
 3 files changed, 17 insertions(+)

-- 
2.44.0.rc1.240.g4c46232300-goog

[PATCH] riscv: sifive: fu740: reduce DDR speed from 1866MT/s to 1600MT/s

2024-02-22 Thread thomas . perrot

From: Thomas Perrot 

It appears that there is some timing marginality either in the
board layout or the SoC that results in occasional data corruption
on some boards.
We observed this issue on some of the new HiFive Unmatched RevB
boards during volume production as well as some of the original
HiFive Unmatched boards from 2021 in our possession. This means
that there are other boards out there that might have the issue
too.

We have done some limited testing with DDR4 at 1600MT/s and
faulty boards (failing at 1866MT/s) passed.
We plan further testing after we procure a temperature chamber.

Signed-off-by: Thomas Perrot 
---
 arch/riscv/dts/fu740-c000-u-boot.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/dts/fu740-c000-u-boot.dtsi 
b/arch/riscv/dts/fu740-c000-u-boot.dtsi
index 706224b384d2..956237c3218e 100644
--- a/arch/riscv/dts/fu740-c000-u-boot.dtsi
+++ b/arch/riscv/dts/fu740-c000-u-boot.dtsi
@@ -77,7 +77,7 @@
   0x0 0x100b2000 0x0 0x2000
   0x0 0x100b8000 0x0 0x1000>;
clocks = <&prci FU740_PRCI_CLK_DDRPLL>;
-   clock-frequency = <93324>;
+   clock-frequency = <80004>;
bootph-pre-ram;
};
};
-- 
2.43.2

Re: [PATCH] ARM: Enable CONFIG_64BIT for static analysis

2024-02-22 Thread Dan Carpenter

On Thu, Feb 22, 2024 at 08:16:19AM -0500, Tom Rini wrote:
> 
> That we have 'config 64BIT' in arch/{mips,riscv}/Kconfig as well is a
> leftover of thinking this is like the Linux Kernel where there's no
> top-level arch/Kconfig file, can you please move the two existing config
> 64BIT entries to arch/Kconfig and then select it for ARM64? Thanks.

Sure.  Even better.

regards,
dan carpenter

Re: [PATCH] ARM: Enable CONFIG_64BIT for static analysis

2024-02-22 Thread Tom Rini

On Thu, Feb 22, 2024 at 09:47:58AM +0300, Dan Carpenter wrote:

> In the Makefile there is a line that says this:
> 
> # the checker needs the correct machine size
> CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
> 
> So set CONFIG_64BIT so that we don't pass -m32 to the static checker.
> 
> Signed-off-by: Dan Carpenter 
> ---
>  arch/arm/Kconfig | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index fde85dc0d537..4c7be7cf9c33 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1,11 +1,15 @@
>  menu "ARM architecture"
>   depends on ARM
>  
> +config 64BIT
> + bool
> +
>  config SYS_ARCH
>   default "arm"
>  
>  config ARM64
>   bool
> + select 64BIT
>   select PHYS_64BIT
>   select SYS_CACHE_SHIFT_6
>   imply SPL_SEPARATE_BSS

That we have 'config 64BIT' in arch/{mips,riscv}/Kconfig as well is a
leftover of thinking this is like the Linux Kernel where there's no
top-level arch/Kconfig file, can you please move the two existing config
64BIT entries to arch/Kconfig and then select it for ARM64? Thanks.

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 4/4] board: ti: am62x: evm: Update simple-framebuffer node in device-tree

Update simple-framebuffer device-tree node by enumerating framebuffer
related information in existing simple-framebuffer node in Linux
device-tree file and enabling it.

In case there is no simple-framebuffer stub detected in Linux kernel
device-tree and video is still active, then update the device-tree to
reserve the framebuffer region for the active splash screen.

This helps preserve the splash screen till the display server takes over
after OS is booted.

Signed-off-by: Devarsh Thakkar 
---
 board/ti/am62x/evm.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 88e02155ee..c825af3368 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -118,3 +119,21 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
 #endif
 }
 #endif
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+   int ret = -1;
+
+   if (IS_ENABLED(CONFIG_FDT_SIMPLEFB))
+   ret = fdt_simplefb_enable_and_mem_rsv(blob);
+
+   /* If simplefb is not enabled and video is active, then at least reserve
+* the framebuffer region to preserve the splash screen while OS is 
booting
+*/
+   if (ret && video_is_active())
+   return fdt_add_fb_mem_rsv(blob);
+
+   return 0;
+}
+#endif
-- 
2.34.1

[PATCH 3/4] boot: Move framebuffer reservation to separate helper

Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.

This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.

Signed-off-by: Devarsh Thakkar 
---
 boot/fdt_simplefb.c   | 12 +---
 boot/fdt_support.c| 21 +
 include/fdt_support.h |  2 ++
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/boot/fdt_simplefb.c b/boot/fdt_simplefb.c
index b0221eaf2a..837920bd3a 100644
--- a/boot/fdt_simplefb.c
+++ b/boot/fdt_simplefb.c
@@ -107,7 +107,6 @@ static int fdt_simplefb_enable_existing_node(void *blob)
 #if IS_ENABLED(CONFIG_VIDEO)
 int fdt_simplefb_enable_and_mem_rsv(void *blob)
 {
-   struct fdt_memory mem;
int ret;
 
/* nothing to do when video is not active */
@@ -118,15 +117,6 @@ int fdt_simplefb_enable_and_mem_rsv(void *blob)
if (ret)
return ret;
 
-   /* nothing to do when the frame buffer is not defined */
-   if (gd->video_bottom == gd->video_top)
-   return 0;
-
-   /* reserved with no-map tag the video buffer */
-   mem.start = gd->video_bottom;
-   mem.end = gd->video_top - 1;
-
-   return fdtdec_add_reserved_memory(blob, "framebuffer", &mem, NULL, 0, 
NULL,
- FDTDEC_RESERVED_MEMORY_NO_MAP);
+   return fdt_add_fb_mem_rsv(blob);
 }
 #endif
diff --git a/boot/fdt_support.c b/boot/fdt_support.c
index 090d82ee80..07aa7337e8 100644
--- a/boot/fdt_support.c
+++ b/boot/fdt_support.c
@@ -22,6 +22,9 @@
 #include 
 #include 
 #include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
 
 /**
  * fdt_getprop_u32_default_node - Return a node's property or a default
@@ -2042,6 +2045,24 @@ int fdt_setup_simplefb_node(void *fdt, int node, u64 
base_address, u32 width,
return 0;
 }
 
+#if IS_ENABLED(CONFIG_VIDEO)
+int fdt_add_fb_mem_rsv(void *blob)
+{
+   struct fdt_memory mem;
+
+   /* nothing to do when the frame buffer is not defined */
+   if (gd->video_bottom == gd->video_top)
+   return 0;
+
+   /* reserved with no-map tag the video buffer */
+   mem.start = gd->video_bottom;
+   mem.end = gd->video_top - 1;
+
+   return fdtdec_add_reserved_memory(blob, "framebuffer", &mem, NULL, 0, 
NULL,
+ FDTDEC_RESERVED_MEMORY_NO_MAP);
+}
+#endif
+
 /*
  * Update native-mode in display-timings from display environment variable.
  * The node to update are specified by path.
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 25600d62f2..4b71b8948d 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -423,6 +423,8 @@ int arch_fixup_memory_node(void *blob);
 int fdt_setup_simplefb_node(void *fdt, int node, u64 base_address, u32 width,
u32 height, u32 stride, const char *format);
 
+int fdt_add_fb_mem_rsv(void *blob);
+
 int fdt_overlay_apply_verbose(void *fdt, void *fdto);
 
 int fdt_valid(struct fdt_header **blobp);
-- 
2.34.1

[PATCH 2/4] video: Assume video to be active if SPL is passing video hand-off

If SPL is passing video handoff structure to U-boot then it is safe to
assume that SPL has already enabled video and that's why it is passing
video handoff structure to U-boot so that U-boot can preserve the
framebuffer.

Signed-off-by: Devarsh Thakkar 
---
 drivers/video/video-uclass.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 3571e62ba2..7b5d1dfbb3 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -404,6 +404,10 @@ bool video_is_active(void)
 {
struct udevice *dev;
 
+   /* Assume video to be active if SPL passed video hand-off to U-boot */
+   if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL)
+   return true;
+
for (uclass_find_first_device(UCLASS_VIDEO, &dev);
 dev;
 uclass_find_next_device(&dev)) {
-- 
2.34.1

[PATCH 1/4] boot: fdt_simplefb: Enumerate framebuffer info from video handoff

Enable and update simple-framebuffer node using the video handoff
bloblist if video was enabled at SPL stage and corresponding video
bloblist was received at u-boot proper with necessary parameters.

Signed-off-by: Devarsh Thakkar 
---
 boot/fdt_simplefb.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/boot/fdt_simplefb.c b/boot/fdt_simplefb.c
index 069ced75a7..b0221eaf2a 100644
--- a/boot/fdt_simplefb.c
+++ b/boot/fdt_simplefb.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -26,15 +28,29 @@ static int fdt_simplefb_configure_node(void *blob, int off)
struct udevice *dev;
int ret;
 
-   ret = uclass_first_device_err(UCLASS_VIDEO, &dev);
-   if (ret)
-   return ret;
-   uc_priv = dev_get_uclass_priv(dev);
-   plat = dev_get_uclass_plat(dev);
-   xsize = uc_priv->xsize;
-   ysize = uc_priv->ysize;
-   bpix = uc_priv->bpix;
-   fb_base = plat->base;
+   if (IS_ENABLED(CONFIG_SPL_VIDEO_HANDOFF) && spl_phase() > PHASE_SPL) {
+   struct video_handoff *ho;
+
+   ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
+   if (!ho)
+   return log_msg_ret("Missing video bloblist", -ENOENT);
+
+   xsize = ho->xsize;
+   ysize = ho->ysize;
+   bpix = ho->bpix;
+   fb_base = ho->fb;
+   } else {
+   ret = uclass_first_device_err(UCLASS_VIDEO, &dev);
+   if (ret)
+   return ret;
+   uc_priv = dev_get_uclass_priv(dev);
+   plat = dev_get_uclass_plat(dev);
+   xsize = uc_priv->xsize;
+   ysize = uc_priv->ysize;
+   bpix = uc_priv->bpix;
+   fb_base = plat->base;
+   }
+
switch (bpix) {
case 4: /* VIDEO_BPP16 */
name = "r5g6b5";
-- 
2.34.1

[PATCH 0/4] Simplefb and fb reservation related updates

This adds support for simple-framebuffer reservation using video handoff
when splash is enabled at SPL stage.

Also adds helper function to only enable framebuffer reservation without
enabling simple-framebuffer in case user want to continue display
bootloader splash without displaying anything else in between until
kernel boots up.

Lastly, it enables above support on AM62x.

Devarsh Thakkar (4):
  boot: fdt_simplefb: Enumerate framebuffer info from video handoff
  video: Assume video to be active if SPL is passing video hand-off
  boot: Move framebuffer reservation to separate helper
  board: ti: am62x: evm: Update simple-framebuffer node in device-tree

 board/ti/am62x/evm.c | 19 +++
 boot/fdt_simplefb.c  | 46 
 boot/fdt_support.c   | 21 
 drivers/video/video-uclass.c |  4 
 include/fdt_support.h|  2 ++
 5 files changed, 72 insertions(+), 20 deletions(-)

-- 
2.34.1

Re: [PATCH v2 13/15] rockchip: rk3328: Add support to build bootable SPI image

2024-02-22 Thread Jonas Karlman

Hi Quentin,

On 2024-02-22 11:18, Quentin Schulz wrote:
> Hi Jonas,
> 
> On 2/17/24 01:22, Jonas Karlman wrote:
>> Similar to RK35xx the BootRom in RK3328 can read all data and look for
>> idbloader at 0x8000, same as it does for SD and eMMC.
>>
>> Use the rksd format and modify the mkimage offset to generate a bootable
>> u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>> v2:
>> - No change
>> ---
>>   arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
>>   arch/arm/mach-rockchip/rk3328/rk3328.c |  1 +
>>   2 files changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3328-u-boot.dtsi 
>> b/arch/arm/dts/rk3328-u-boot.dtsi
>> index a030f1a5e51d..4d43fe2fb51a 100644
>> --- a/arch/arm/dts/rk3328-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3328-u-boot.dtsi
>> @@ -133,3 +133,14 @@
>>   &usb20_otg {
>>  hnp-srp-disable;
>>   };
>> +
>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>> +&binman {
>> +simple-bin-spi {
>> +mkimage {
>> +args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
>> +offset = <0x8000>;
>> +};
>> +};
>> +};
>> +#endif
> 
> Do we have a list of SoCs that need to use rkspi type for booting from 
> SPI flashes? I would much rather have rksd the default in 
> rockchip-u-boot.dtsi instead of having to add it for each and every SoC 
> which is not impacted by this change (which I assume should be now all 
> new SoCs?).

My best guess is that any BROM prior to and including RK3399 use the 2K
per page read code for SPI flash. Any newer SoC seem to have SPI more in
common with MMC, i.e. read full page data and look for boot header at
similar offsets, @ 32KiB.

I have been able to read out the BROM version (last 16 bytes of BROM)
from my RK ARM64 SoCs:

Read 2K per page:
RK3399:  330C 20160118 V100

Read full SPI flash data:
RK3328:  320C 20161117 V100
RK356x:  350A 20210322 V300
RK3588:  350B 20210512 V100

Unsure, guessing it read full SPI flash data:
RK3308B: 330E 20180806 V200

There is also a longer list of BROM versions of older SoCs at [1].

[1] 
https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/chip_info.c

> 
> I could also imagine a Kconfig symbol just for that, one that would NOT 
> appear in menuconfig because it makes no sense to make it selectable (I 
> think this can be achieved without a prompt?), e.g. (not tested):
> """
> config ROCKCHIP_SPI_IMAGE_TYPE
>  string
>  depends on ROCKCHIP_SPI_IMAGE
>  default "rksd"
>  default "rkspi" if ROCKCHIP_RK3399
>  help
>The type passed to mkimage to generate a TPL+SPL image bootable 
> from SPI flash on Rockchip SoCs.
> """
> 
> and then have
> """
> args = "-n", CONFIG_SYS_SOC, "-T", CONFIG_ROCKCHIP_SPI_IMAGE_TYPE;
> """
> 
> in rockchip-u-boot.dtsi instead?

Agree that we should try to fix this in a different way, still not sure
what the best approach will be.

Another approach I played around with was to modify the mkimage rkspi
format to only apply the 2K padding on affected SoCs [2]. At that time I
used the RK_HEADER_V1/V2 flag, but as seen for RK3328 that cannot be
used to reliably know if the padding is needed or not.

>From what I can see in mainline U-Boot only boards with the following
SoCs have ROCKCHIP_SPI_IMAGE enabled:

- RK3288 and RK3399 (2K per page)
- RK356x and RK3588 (full page)

With RK3328 also using full page read the scale have now tipped over so
that we could prefer rksd format over rkspi. Unless anyone would like
to enable it for a board with an older SoC.

I am open for any suggestion on how we should proceed :-)

[2] 
https://github.com/Kwiboo/u-boot-rockchip/commit/7b42660412493496c379015dc5019c89caf85ddf

> 
> I've missed those changes for other SoCs but did you explain why the SPI 
> image is expected to start at offset 0x8000? We don't have that in 
> rockchip-u-boot.dtsi by default, so offset 0 I assume.

Based on my testing of boot from SPI flash on RK356x booting worked when
I wrote ID block @ 32 KiB offset from start of SPI flash. This was
different to the @ 0 offset used on RK3288 and RK3399.

Most documentation already mentioned that u-boot-rockchip-spi.bin should
be written to start of SPI flash. Adding an offset of 32 KiB so that the
same instruction can be used across SoCs seemed like the best approach.

Regards,
Jonas

> 
> Cheers,
> Quentin

Re: [PATCH 7/7] verdin-imx8mp_defconfig: Enable PCIe/NVMe support

2024-02-22 Thread Marcel Ziswiler

On Wed, 2024-02-21 at 15:31 +0100, Francesco Dolcini wrote:
> On Wed, Feb 21, 2024 at 09:18:51AM +, Marcel Ziswiler wrote:
> > On Wed, 2024-02-21 at 08:55 +0100, Francesco Dolcini wrote:
> > > On Tue, Feb 20, 2024 at 06:40:56PM +0530, Sumit Garg wrote:
> > > > Also, enable reset driver which is a prerequisite for PCIe support.
> > > > 
> > > > Signed-off-by: Sumit Garg 
> > > > ---
> > > >  configs/verdin-imx8mp_defconfig | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/configs/verdin-imx8mp_defconfig 
> > > > b/configs/verdin-imx8mp_defconfig
> > > > index 22b8a334dfa..d8bd644322b 100644
> > > > --- a/configs/verdin-imx8mp_defconfig
> > > > +++ b/configs/verdin-imx8mp_defconfig
> > > > @@ -185,3 +185,12 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x1b67
> > > >  CONFIG_USB_GADGET_PRODUCT_NUM=0x4000
> > > >  CONFIG_IMX_WATCHDOG=y
> > > >  CONFIG_HEXDUMP=y
> > > > +CONFIG_DM_RESET=y
> > > > +CONFIG_RESET_IMX=y
> > > > +CONFIG_PCI=y
> > > > +CONFIG_PCIE_DW_IMX8=y
> > > > +CONFIG_PHY_IMX8M_PCIE=y
> > > > +CONFIG_CMD_PCI=y
> > > > +CONFIG_NVME=y
> > > > +CONFIG_NVME_PCI=y
> > > > +CONFIG_CMD_NVME=y
> > > 
> > > This will increase the u-boot proper size
> > 
> > Yes, I checked and it is actually slightly more than 32 K.
> > 
> > > and marginally increase the
> > > boot time (because of a bigger binary to be read from the eMMC).
> > 
> > That was also my concern.
> > 
> > > Apart of that do you expect any other impact on those changes? SPL
> > > binary size should not be affected, correct?
> > > 
> > > Asking this out loudly to confirm that nothing unexpected is going to
> > > happen because of these changes.
> > 
> > Other than that I actually gave it a quick try and PCIe/NVMe does indeed 
> > work and the regular boot is not
> > affected (other than the slight size and boot time increase, of course).
> > 
> > > For my curiosity, care to share what's the use case? Do you plan to have
> > > the OS stored into an NVME device?
> > 
> > For us the question is basically whether that use case does mandate
> > enforcing such changes for each and every customer. Plus the regular
> > expected maintenance effort any such change brings with it, of course.
> 
> Marcel, given all you wrote here I would personally be fine
> on having this enabled in the verdin_imx8mp defconfig.
> 
> What's your idea? Are you good with it?

Yes, I do agree.

> Francesco

Cheers

Marcel

Re: riscv: supports_extension() broken for long isa strings

2024-02-22 Thread Heinrich Schuchardt


On 21.02.24 18:59, Conor Dooley wrote:

Yo,

I mentioned this last night to Heinrich on IRC, supports_extension() is
broken for ISA strings longer than 32 characters. M-Mode U-Boot doesn't
parse a devicetree, so this doesn't apply there, but for S-mode
supports_extension() looks like:

static inline bool supports_extension(char ext)
{

struct udevice *dev;
char desc[32];
int i;

uclass_find_first_device(UCLASS_CPU, &dev);
if (!dev) {
debug("unable to find the RISC-V cpu device\n");
return false;
}
if (!cpu_get_desc(dev, desc, sizeof(desc))) {
/*
 * skip the first 4 characters (rv32|rv64) and
 * check until underscore
 */
for (i = 4; i < sizeof(desc); i++) {
if (desc[i] == '_' || desc[i] == '\0')
break;
if (desc[i] == ext)
return true;
}
}

return false;
}

cpu_get_desc is implemented by riscv_cpu_get_desc():
static int riscv_cpu_get_desc(const struct udevice *dev, char *buf, int size)


Thanks Conor for reporting the issue. We should change all cpu_get_desc
implementations to:

int riscv_cpu_get_desc(const struct udevice *dev, char *buf, size_t *size)
{
size_t old_size = *size;

*size = snprintf(buf, *size, "%s", info) + 1;
if (*size > old_size)
return -ENOSPC;
return 0;
}

With this change

size = 0;
cpu_get_desc(dev, desc, &size);

can be used to get the size of the information before allocating a buffer.

desc = malloc(size);
cpu_get_desc(dev, desc, size);

Best regards

Heinrich


{
const char *isa;

isa = dev_read_string(dev, "riscv,isa");
if (size < (strlen(isa) + 1))
return -ENOSPC;

strcpy(buf, isa);

return 0;
}

On most extant systems, riscv,isa is a pretty short string - between 10
and 20 characters. In QEMU's default virt machine however, we get:
riscv,isa = 
"rv64imafdch_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintntl_zihintpause_zihpm_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu";

Since desc can only contain 32 elements, the size < strlen() test fails
and cpu_get_desc() returns an error and supports_extension() in turn
returns false.

Currently, in S-Mode, there's only two extensions that U-Boot ever looks
for and they lie inside the single letter section, so 32 charcters would
be sufficiently sized, if cpu_get_desc() supported undersized buffers.

I came across this while adding support for a different way of detecting
ISA extensions, rather than running into an actual problem because U-Boot
seems not to actually make use of supports_extension() other than enabling
an FPU that there seem to be no users of in U-Boot at present. I also
assume that using U-Boot in QEMU is somewhat of a rare case, given with
virt you can boot an OS kernel directly. That'd make the impact of this
problem pretty low, given I just happened to notice that in my test
environment no extensions were being detected and the operation of
U-Boot seemed unaffected.

I'm mostly just wondering if, given the impact seems to be rather low,
if I should "bother" making a minimal fix for this that would be
applied to master (or backported? not 100% sure of the release process
for U-Boot), or if I can just fix it in passing while making "riscv,isa"
optional?

A minimal fix would look something like the following:

diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index 8445c5823e..df508ac4a1 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -39,7 +39,6 @@ static inline bool supports_extension(char ext)
return csr_read(CSR_MISA) & (1 << (ext - 'a'));
  #elif CONFIG_CPU
struct udevice *dev;
-   char desc[32];
int i;

uclass_find_first_device(UCLASS_CPU, &dev);
@@ -47,15 +46,16 @@ static inline bool supports_extension(char ext)
debug("unable to find the RISC-V cpu device\n");
return false;
}
-   if (!cpu_get_desc(dev, desc, sizeof(desc))) {
+   const char *isa = dev_read_string(dev, "riscv,isa");
+   if (isa) {
/*
 * skip the first 4 characters (rv32|rv64) and
 * check until underscore
 */
-   for (i = 4; i < sizeof(desc); i++) {
-   if (desc[i] == '_' || desc[i] == '\0')
+   for (i = 4; i < strlen(isa); i++) {
+   if (isa[i] == '_' || isa[i] == '\0')
break;
-   if (desc[i] == ext)
+   if (isa[i] == ext)
return true;
}
}

Cheers,
Conor.

[PATCH v6 04/11] Makefile: Allow upstream DT subtree to provide DT includes

Allow platforms to reuse DT headers and dtsi includes directly form
upstream DT subtree which will be frequently synced with Linux kernel.
This will further allow us to drop corresponding DT includes copy from
U-Boot tree.

Also, since the DT includes from upstream DT subtree are done after DT
includes from U-Boot tree, so it shouldn't cause any conflicts.

Tested-by: Bryan Brattlof 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- New patch to reuse upstream DT includes by U-Boot as per Brian's use-case
  for TI K3 SoCs.

 Makefile | 3 ++-
 scripts/Makefile.lib | 5 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 9604a4c517e5..0f0c7f30d271 100644
--- a/Makefile
+++ b/Makefile
@@ -835,7 +835,8 @@ UBOOTINCLUDE:= \
-I$(srctree)/arch/arm/thumb1/include), \
-I$(srctree)/arch/arm/thumb1/include)) \
-I$(srctree)/arch/$(ARCH)/include \
-   -include $(srctree)/include/linux/kconfig.h
+   -include $(srctree)/include/linux/kconfig.h \
+   -I$(srctree)/dts/upstream/include
 
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 9e38d75443c9..12857316c582 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -189,12 +189,17 @@ dtsi_include_list = $(strip $(u_boot_dtsi_options_debug) \
 dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
 
 # Modified for U-Boot
+upstream_dtsi_include = $(addprefix -I, $(srctree)/dts/upstream/src/ \
+   $(sort $(dir $(wildcard $(srctree)/dts/upstream/src/$(ARCH)/*/*))) \
+   $(if (CONFIG_ARM64), \
+$(sort $(dir $(wildcard 
$(srctree)/dts/upstream/src/arm64/*/*)
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc\
 $(UBOOTINCLUDE) \
 -I$(dir $<) \
 -I$(u_boot_dtsi_loc) \
 -I$(srctree)/arch/$(ARCH)/dts/include   \
 -I$(srctree)/include\
+$(upstream_dtsi_include)\
 -D__ASSEMBLY__  \
 -undef -D__DTS__
 
-- 
2.34.1

[PATCH v6 05/11] dts: Add alternative location for upstream DTB builds

Allow platform owners to mirror devicetree files from devitree-rebasing
directory into dts/upstream/src/$(ARCH) (special case for arm64). Then
build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
directory. Also add a new Makefile for arm64.

This will help easy migration for platforms which currently are compliant
with upstream Linux kernel devicetree files.

Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather
  than devicetree-rebasing sub-directory to better suite U-Boot
  directory structure.
- Added a note to OF_UPSTREAM Kconfig option.

Changes in v3:
- Minor commit message update

Changes in v2:
- s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/

 dts/Kconfig | 16 
 dts/Makefile| 17 ++---
 dts/upstream/src/arm64/Makefile | 14 ++
 3 files changed, 44 insertions(+), 3 deletions(-)
 create mode 100644 dts/upstream/src/arm64/Makefile

diff --git a/dts/Kconfig b/dts/Kconfig
index 00c0aeff893b..09789d3e18b3 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -85,6 +85,22 @@ config OF_LIVE
  enables a live tree which is available after relocation,
  and can be adjusted as needed.
 
+config OF_UPSTREAM
+   bool "Enable use of devicetree imported from Linux kernel release"
+   help
+ Traditionally, U-Boot platforms used to have their custom devicetree
+ files or copy devicetree files from Linux kernel which are hard to
+ maintain and can usually get out-of-sync from Linux kernel. This
+ option enables platforms to migrate to devicetree-rebasing repo where
+ a regular sync will be maintained every major Linux kernel release
+ cycle. However, platforms can still have some custom u-boot specific
+ bits maintained as part of *-u-boot.dtsi files.
+
+ Note: This option should be set in Kconfig, for the SoC as a whole.
+ However, newer boards whose devicetree source files haven't landed in
+ the dts/upstream subtree, they can override this option to have the
+ DT build from existing U-Boot tree location instead.
+
 choice
prompt "Provider of DTB for DT control"
depends on OF_CONTROL
diff --git a/dts/Makefile b/dts/Makefile
index 3437e54033db..d6c2c9daf31d 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
 DEVICE_TREE := unset
 endif
 
+ifeq ($(CONFIG_OF_UPSTREAM),y)
+ifeq ($(CONFIG_ARM64),y)
+dt_dir := dts/upstream/src/arm64
+else
+dt_dir := dts/upstream/src/$(ARCH)
+endif
+else
+dt_dir := arch/$(ARCH)/dts
+endif
+
 ifneq ($(EXT_DTB),)
 DTB := $(EXT_DTB)
 else
-DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
+DTB := $(dt_dir)/$(DEVICE_TREE).dtb
 endif
 
 $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE
@@ -41,7 +51,7 @@ $(DTB): arch-dtbs
 
 PHONY += arch-dtbs
 arch-dtbs:
-   $(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
+   $(Q)$(MAKE) $(build)=$(dt_dir) dtbs
 
 ifeq ($(CONFIG_SPL_BUILD),y)
 obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
@@ -65,4 +75,5 @@ clean-files := dt.dtb.S
 # Let clean descend into dts directories
 subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts 
../arch/microblaze/dts \
   ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts 
../arch/riscv/dts \
-  ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
+  ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts 
../arch/xtensa/dts\
+  ./upstream/src/arm64 ./upstream/src/$(ARCH)
diff --git a/dts/upstream/src/arm64/Makefile b/dts/upstream/src/arm64/Makefile
new file mode 100644
index ..9a8f6aa35846
--- /dev/null
+++ b/dts/upstream/src/arm64/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+include $(srctree)/scripts/Makefile.dts
+
+targets += $(dtb-y)
+
+# Add any required device tree compiler flags here
+DTC_FLAGS += -a 0x8
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+   @:
+
+clean-files := */*.dtb */*.dtbo
-- 
2.34.1

[PATCH v6 11/11] dts: meson-gxbb: Drop redundant devicetree files

Since meson-gxbb based boards switched to using upstream DT, so drop
redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files
kept in arch/arm/dts directory for these boards.

Reviewed-by: Neil Armstrong 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- None

Changes in v3:
- Picked up review tag

Changes in v2:
- None

 arch/arm/dts/Makefile   |   8 -
 arch/arm/dts/meson-gxbb-kii-pro.dts | 140 
 arch/arm/dts/meson-gxbb-nanopi-k2.dts   | 426 
 arch/arm/dts/meson-gxbb-odroidc2.dts| 414 ---
 arch/arm/dts/meson-gxbb-p200.dts| 100 ---
 arch/arm/dts/meson-gxbb-p201.dts|  26 -
 arch/arm/dts/meson-gxbb-p20x.dtsi   | 250 ---
 arch/arm/dts/meson-gxbb-wetek-hub.dts   |  58 --
 arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 
 arch/arm/dts/meson-gxbb-wetek.dtsi  | 292 
 arch/arm/dts/meson-gxbb.dtsi| 870 
 11 files changed, 2703 deletions(-)
 delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi
 delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts
 delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi
 delete mode 100644 arch/arm/dts/meson-gxbb.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d9725030d5a0..7c2681eb9377 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -216,14 +216,6 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-a1-ad401.dtb \
meson-axg-s400.dtb \
meson-axg-jethome-jethub-j100.dtb \
-   meson-gxbb-kii-pro.dtb \
-   meson-gxbb-nanopi-k2.dtb \
-   meson-gxbb-odroidc2.dtb \
-   meson-gxbb-nanopi-k2.dtb \
-   meson-gxbb-p200.dtb \
-   meson-gxbb-p201.dtb \
-   meson-gxbb-wetek-hub.dtb \
-   meson-gxbb-wetek-play2.dtb \
meson-gxl-s805x-libretech-ac.dtb \
meson-gxl-s905d-libretech-pc.dtb \
meson-gxl-s905w-jethome-jethub-j80.dtb \
diff --git a/arch/arm/dts/meson-gxbb-kii-pro.dts 
b/arch/arm/dts/meson-gxbb-kii-pro.dts
deleted file mode 100644
index e238f1f10124..
--- a/arch/arm/dts/meson-gxbb-kii-pro.dts
+++ /dev/null
@@ -1,140 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2019 Mohammad Rasim 
- */
-
-/dts-v1/;
-
-#include "meson-gxbb-p20x.dtsi"
-#include 
-#include 
-#include 
-#include 
-
-/ {
-   compatible = "videostrong,kii-pro", "amlogic,meson-gxbb";
-   model = "Videostrong KII Pro";
-
-   spdif_dit: audio-codec-0 {
-   #sound-dai-cells = <0>;
-   compatible = "linux,spdif-dit";
-   status = "okay";
-   sound-name-prefix = "DIT";
-   };
-
-   leds {
-   compatible = "gpio-leds";
-   led {
-   gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
-   color = ;
-   function = LED_FUNCTION_STATUS;
-   default-state = "off";
-   };
-   };
-
-   gpio-keys-polled {
-   compatible = "gpio-keys-polled";
-   poll-interval = <20>;
-
-   button-reset {
-   label = "reset";
-   linux,code = ;
-   gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
-   };
-   };
-
-   sound {
-   compatible = "amlogic,gx-sound-card";
-   model = "KII-PRO";
-   assigned-clocks = <&clkc CLKID_MPLL0>,
- <&clkc CLKID_MPLL1>,
- <&clkc CLKID_MPLL2>;
-   assigned-clock-parents = <0>, <0>, <0>;
-   assigned-clock-rates = <294912000>,
-  <270950400>,
-  <393216000>;
-
-   dai-link-0 {
-   sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
-   };
-
-   dai-link-1 {
-   sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
-   };
-
-   dai-link-2 {
-   sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
-   dai-format = "i2s";
-   mclk-fs = <256>;
-
-   codec-0 {
-   sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
-   };
-   };
-
-   dai-link-3 {
-   sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;
-
-   codec-0 {
-   sound-dai = <&spdif_dit>;
-   };
-   };
-
-   dai-link-4 {
-

[PATCH v6 08/11] doc: devicetree: Updates for devicetree-rebasing subtree

Encourage SoC/board maintainers to migrate to using devicetree-rebasing
subtree and maintain a regular sync with Linux kernel devicetree files
and bindings.

Along with that add documentation regarding how to run DT bindings
schema checks.

Signed-off-by: Sumit Garg 
---

Changes in v6:
- Incorporate documentation review comments from Paul.

Changes in v5:
- Document how to cherry-pick fixes from devicetree-rebasing tree.

Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather
  than devicetree-rebasing sub-directory to better suite U-Boot
  directory structure.
- Since we now have v6.7-dts tag available now, so switch subtree to
  that from its beginning.
- Clarify subtree uprev schedule as a separate documentation section.
  Also, fixed documentation typos.

Changes in v3:
- Replace CONFIG_* with Kconfig options

Changes in v2:
- s/U-boot/U-Boot/

 doc/develop/devicetree/control.rst | 115 -
 1 file changed, 95 insertions(+), 20 deletions(-)

diff --git a/doc/develop/devicetree/control.rst 
b/doc/develop/devicetree/control.rst
index 9a0cb90336df..c94d84192b71 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -1,5 +1,6 @@
 .. SPDX-License-Identifier: GPL-2.0+
 .. sectionauthor:: Copyright 2011 The Chromium OS Authors
+.. Copyright 2023-2024 Linaro Ltd.
 
 Devicetree Control in U-Boot
 
@@ -22,12 +23,11 @@ for three reasons:
   hierarchical format
 - It is fairly efficient to read incrementally
 
-The arch//dts directories contains a Makefile for building the devicetree
-blob and embedding it in the U-Boot image. This is useful since it allows
-U-Boot to configure itself according to what it finds there. If you have
-a number of similar boards with different peripherals, you can describe
-the features of each board in the devicetree file, and have a single
-generic source base.
+The U-Boot Makefile infrastructure allows for building the devicetree blob
+and embedding it in the U-Boot image. This is useful since it allows U-Boot
+to configure itself according to what it finds there. If you have a number
+of similar boards with different peripherals, you can describe the features
+of each board in the devicetree file, and have a single generic source base.
 
 To enable this feature, select `OF_CONTROL` via Kconfig.
 
@@ -68,8 +68,16 @@ a binary file. U-Boot adds its own `fdtgrep` for creating 
subsets of the file.
 Where do I get a devicetree file for my board?
 --
 
-You may find that the Linux kernel has a suitable file. Look in the
-kernel source in arch//boot/dts.
+The devicetree files and devicetree bindings are maintained as part of the 
Linux
+kernel git repository. Traditionally, U-Boot placed copies of devicetree source
+files from the Linux kernel into `arch//dts/.dts`. However, this
+required each board maintainer to manually keep their devicetree in sync with
+the Linux kernel and often led to divergence between these copies.
+
+U-Boot rather maintains a Git subtree as `dts/upstream/` sub-directory. It is
+regularly synced with the Linux kernel and hence no need for manual devicetree
+sync. You may find that the `dts/upstream/` already has a suitable devicetree
+file for your board. Look in `dts/upstream/src//`.
 
 If not you might find other boards with suitable files that you can
 modify to your needs. Look in the board directories for files with a
@@ -78,17 +86,39 @@ modify to your needs. Look in the board directories for 
files with a
 Failing that, you could write one from scratch yourself!
 
 
+Resyncing with devicetree-rebasing
+--
+
+The devicetee-rebasing repository (dtrepo_) maintains a fork cum mirror copy of
+devicetree files along with the bindings synced at every Linux kernel major
+release or intermediate release candidates. The U-Boot maintainers regularly
+sync the `dts/upstream/` subtree from the devicetree-rebasing repo whenever
+the next branch opens (refer: :doc:`../release_cycle`) with the latest mainline
+Linux kernel release. To sync the `dts/upstream/` subtree, run::
+
+./dts/update-dts-subtree.sh pull 
+
+If required it is also possible to cherry-pick fixes from the
+devicetree-rebasing repository prior to next sync, usage::
+
+./dts/update-dts-subtree.sh pick 
+
+
 Configuration
 -
 
-Set up "" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. Then put
-your devicetree file into::
+SoC/board maintainers are encouraged to migrate to use synced copies from
+`dts/upstream/src//`. To do that add `imply OF_UPSTREAM` for the
+SoC being used via Kconfig and set `DEFAULT_DEVICE_TREE=/` when
+prompted by Kconfig.
 
-   arch//dts/.dts
+However, if `dts/upstream/` hasn't yet received devicetree source file for your
+newly added board support then you can add corresponding devicetree source file
+as `arch//dts/.dts`. To select that add `# CONFIG_OF_UPSTREAM is

[PATCH v6 09/11] MAINTAINERS: Add myself as devicetree-rebasing maintainer

Add myself as devicetree-rebasing maintainer.

Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather
  than devicetree-rebasing sub-directory to better suite U-Boot
  directory structure.
- Added commit description.

Changes in v3:
- Picked up review tags

Changes in v2:
- Picked up review tags

 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 0b08ca192397..6541ab2b3a87 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -989,6 +989,11 @@ F: cmd/cyclic.c
 F: common/cyclic.c
 F: include/cyclic.h
 
+DEVICETREE REBASING SUBTREE
+M: Sumit Garg 
+S: Maintained
+F: dts/upstream/
+
 DFU
 M: Lukasz Majewski 
 M: Mattijs Korpershoek 
-- 
2.34.1

[PATCH v6 10/11] dts: meson-gxbb: Switch to using upstream DT

Although there were still some variations in board DTS files based on
meson-gxbb SoC but I think those were minor differences from upstream
and shouldn't impact boot on these devices.

So enable OF_UPSTREAM to use upstream DT and add amlogic/ prefix to the
DEFAULT_DEVICE_TREE. And thereby directly build DTB from dts/upstream/src/
including *-u-boot.dtsi files from arch/$(ARCH)/dts/ directory.

Reviewed-by: Neil Armstrong 
Reviewed-by: Simon Glass 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- Picked up review tag

Changes in v3:
- Dropped Makefile portion and enabled OF_UPSTREAM for SoC instead.

Changes in v2:
- Picked up review tag

 arch/arm/mach-meson/Kconfig   | 1 +
 configs/nanopi-k2_defconfig   | 2 +-
 configs/odroid-c2_defconfig   | 2 +-
 configs/p200_defconfig| 2 +-
 configs/p201_defconfig| 2 +-
 configs/videostrong-kii-pro_defconfig | 2 +-
 configs/wetek-hub_defconfig   | 2 +-
 configs/wetek-play2_defconfig | 2 +-
 8 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index d6c890580617..8ddb59161a0d 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -25,6 +25,7 @@ choice
 config MESON_GXBB
bool "GXBB"
select MESON_GX
+   imply OF_UPSTREAM
help
  Select this if your SoC is an S905
 
diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig
index 41dbf7981f8b..2e1c756bf7a8 100644
--- a/configs/nanopi-k2_defconfig
+++ b/configs/nanopi-k2_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index 5f9f323e06ea..ce5eaec3cd2a 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/p200_defconfig b/configs/p200_defconfig
index cd579ef5f142..b69460347954 100644
--- a/configs/p200_defconfig
+++ b/configs/p200_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/p201_defconfig b/configs/p201_defconfig
index b2f0a0ccdb4a..dcc1454be16c 100644
--- a/configs/p201_defconfig
+++ b/configs/p201_defconfig
@@ -7,7 +7,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/videostrong-kii-pro_defconfig 
b/configs/videostrong-kii-pro_defconfig
index 3eda8f14a21b..7a5af234471f 100644
--- a/configs/videostrong-kii-pro_defconfig
+++ b/configs/videostrong-kii-pro_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig
index fd92b041e739..85cff73f50f7 100644
--- a/configs/wetek-hub_defconfig
+++ b/configs/wetek-hub_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig
index b887419a6bab..efdf820165b5 100644
--- a/configs/wetek-play2_defconfig
+++ b/configs/wetek-play2_defconfig
@@ -6,7 +6,7 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x2000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2"
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BA

[PATCH v6 07/11] doc: devicetree: Align documentation to use Kconfig options

Since U-Boot switched away from manual CONFIG_* defines to Kconfig
options, align devicetree documentation accordingly.

Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- Fixed inappropriate documentation update.

Changes in v4:
- Separate patch to align documentation to use Kconfig symbols instead.

 doc/develop/devicetree/control.rst | 48 ++
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/doc/develop/devicetree/control.rst 
b/doc/develop/devicetree/control.rst
index 11c92d440f4d..9a0cb90336df 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -29,7 +29,7 @@ a number of similar boards with different peripherals, you 
can describe
 the features of each board in the devicetree file, and have a single
 generic source base.
 
-To enable this feature, add CONFIG_OF_CONTROL to your board config file.
+To enable this feature, select `OF_CONTROL` via Kconfig.
 
 
 What is a Flattened Devicetree?
@@ -81,12 +81,8 @@ Failing that, you could write one from scratch yourself!
 Configuration
 -
 
-Use::
-
-   #define CONFIG_DEFAULT_DEVICE_TREE  ""
-
-to set the filename of the devicetree source. Then put your devicetree
-file into::
+Set up "" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig. Then put
+your devicetree file into::
 
arch//dts/.dts
 
@@ -94,24 +90,24 @@ This should include your CPU or SOC's devicetree file, 
placed in
 `arch//dts`, and then make any adjustments required using a u-boot-dtsi
 file for your board.
 
-If CONFIG_OF_EMBED is defined, then it will be picked up and built into
+If `OF_EMBED` is selected by Kconfig, then it will be picked up and built into
 the U-Boot image (including u-boot.bin). This is suitable for debugging
 and development only and is not recommended for production devices.
 
-If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
+If `OF_SEPARATE` is selected by Kconfig, then it will be built and placed in
 a u-boot.dtb file alongside u-boot-nodtb.bin with the combined result placed
-in u-boot.bin so you can still just flash u-boot.bin onto your board. If you 
are
-using CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
-tree binary.
+in u-boot.bin so you can still just flash u-boot.bin onto your board. If 
Kconfig
+option `SPL_FRAMEWORK` is enabled, then u-boot.img will be built to include the
+device tree binary.
 
-If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
+If `OF_BOARD` is selected by Kconfig, a board-specific routine will provide the
 devicetree at runtime, for example if an earlier bootloader stage creates
 it and passes it to U-Boot.
 
-If CONFIG_BLOBLIST is defined, the devicetree may come from a bloblist passed
-from a previous stage, if present.
+If `BLOBLIST` is selected by Kconfig, the devicetree may come from a bloblist
+passed from a previous stage, if present.
 
-If CONFIG_SANDBOX is defined, then it will be read from a file on
+If `SANDBOX` is selected by Kconfig, then it will be read from a file on
 startup. Use the -d flag to U-Boot to specify the file to read, -D for the
 default and -T for the test devicetree, used to run sandbox unit tests.
 
@@ -145,7 +141,7 @@ Build:
 After the board configuration is done, fdt supported u-boot can be built in two
 ways:
 
-#  build the default dts which is defined from CONFIG_DEFAULT_DEVICE_TREE::
+#  build the default dts which is selected by DEFAULT_DEVICE_TREE Kconfig::
 
 $ make
 
@@ -198,8 +194,8 @@ As mentioned above, the U-Boot build system automatically 
includes a
 `*-u-boot.dtsi` file, if found, containing U-Boot specific
 quirks. However, some data, such as the mentioned public keys, are not
 appropriate for upstream U-Boot but are better kept and maintained
-outside the U-Boot repository. You can use CONFIG_DEVICE_TREE_INCLUDES
-to specify a list of .dtsi files that will also be included when
+outside the U-Boot repository. You can use `DEVICE_TREE_INCLUDES` Kconfig
+option to specify a list of .dtsi files that will also be included when
 building .dtb files.
 
 
@@ -213,14 +209,14 @@ The full devicetree is available to U-Boot proper, but 
normally only a subset
 'SPL Support' in doc/driver-model/design.rst for more details.
 
 
-Using several DTBs in the SPL (CONFIG_SPL_MULTI_DTB)
-
+Using several DTBs in the SPL (SPL_MULTI_DTB_FIT Kconfig option)
+
 In some rare cases it is desirable to let SPL be able to select one DTB among
 many. This usually not very useful as the DTB for the SPL is small and usually
 fits several platforms. However the DTB sometimes include information that do
 work on several platforms (like IO tuning parameters).
-In this case it is possible to use CONFIG_SPL_MULTI_DTB. This option appends to
-the SPL a FIT image containing several DTBs listed in SPL_OF_LIST.
+In this case

[PATCH v6 06/11] dts: Add script to uprev dts/upstream subtree

dts/update-dts-subtree.sh is just a wrapper around git subtree commands.
Usage from the top level U-Boot source tree, run:

$ ./dts/update-dts-subtree.sh pull 
$ ./dts/update-dts-subtree.sh pick 

Signed-off-by: Sumit Garg 
---

Changes in v6:
- Incorporate shell script comments from Marek.

Changes in v5:
- Added support to cherry-pick fixes in subtree update script. Also, used
  https:// instead of git://.

Changes in v4:
- New patch to add script dts/update-dts-subtree.sh as per Rob's comments.

 dts/update-dts-subtree.sh | 48 +++
 1 file changed, 48 insertions(+)
 create mode 100755 dts/update-dts-subtree.sh

diff --git a/dts/update-dts-subtree.sh b/dts/update-dts-subtree.sh
new file mode 100755
index ..a57b78a41d34
--- /dev/null
+++ b/dts/update-dts-subtree.sh
@@ -0,0 +1,48 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright 2024 Linaro Ltd.
+#
+# Usage: from the top level U-Boot source tree, run:
+# $ ./dts/update-dts-subtree.sh pull 
+# $ ./dts/update-dts-subtree.sh pick 
+#
+# The script will pull changes from devicetree-rebasing repo into U-Boot
+# as a subtree located as /dts/upstream sub-directory. It will
+# automatically create a squash/merge commit listing the commits imported.
+
+set -e
+
+merge_commit_msg=$(cat << EOF
+Subtree merge tag '$2' of devicetree-rebasing repo [1] into dts/upstream
+
+[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
+EOF
+)
+
+remote_add_and_fetch() {
+if ! git remote get-url devicetree-rebasing 2>/dev/null
+then
+echo "Warning: Script automatically adds new git remote via:"
+echo "git remote add devicetree-rebasing \\"
+echo "
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git";
+git remote add devicetree-rebasing \
+
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
+fi
+git fetch devicetree-rebasing master
+}
+
+if [ "$1" = "pull" ]
+then
+remote_add_and_fetch
+git subtree pull --prefix dts/upstream devicetree-rebasing \
+"$2" --squash -m "${merge_commit_msg}"
+elif [ "$1" = "pick" ]
+then
+remote_add_and_fetch
+git cherry-pick -x --strategy=subtree -Xsubtree=dts/upstream/ "$2"
+else
+echo "usage: $0  "
+echo "   pull or pick"
+echo "  release tag [pull] or commit id [pick]"
+fi
-- 
2.34.1

[PATCH v6 03/11] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

Allow u-boot to build DTB from a different directory tree such that
*-u-boot.dtsi files can be included from a common location. Currently
that location is arch/$(ARCH)/dts/, so statically define that common
location.

This is needed for platform owners to start building DTB files from
devicetree-rebasing directory but still being able to include
*-u-boot.dtsi files.

Reviewed-by: Tom Rini 
Reviewed-by: Simon Glass 
Reviewed-by: Ilias Apalodimas 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- Incorporate fix for sandbox CI failure.

Changes in v5:
- None

Changes in v4:
- Incorporate fix to resolve rk3399 migration issue reported by Simon.

Changes in v3:
- Picked up review tags

Changes in v2:
- s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/

 scripts/Makefile.lib | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index f82b3169e874..9e38d75443c9 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -159,18 +159,20 @@ cpp_flags  = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) 
$(UBOOTINCLUDE) \
 ld_flags   = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
 
 # Try these files in order to find the U-Boot-specific .dtsi include file
-u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir 
$<))-u-boot.dtsi) \
-   $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
-   $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
-   $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
-   $(wildcard $(dir $<)u-boot.dtsi))
+u_boot_dtsi_loc = $(srctree)/arch/$(ARCH)/dts/
+
+u_boot_dtsi_options = $(strip $(wildcard $(u_boot_dtsi_loc)$(basename $(notdir 
$<))-u-boot.dtsi) \
+   $(wildcard $(u_boot_dtsi_loc)$(subst 
$\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
+   $(wildcard $(u_boot_dtsi_loc)$(subst 
$\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
+   $(wildcard $(u_boot_dtsi_loc)$(subst 
$\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
+   $(wildcard $(u_boot_dtsi_loc)u-boot.dtsi))
 
 u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
-   $(dir $<)$(basename $(notdir $<))-u-boot.dtsi \
-   $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
-   $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
-   $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
-   $(dir $<)u-boot.dtsi ... \
+   $(u_boot_dtsi_loc)$(basename $(notdir $<))-u-boot.dtsi \
+   $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
+   $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
+   $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
+   $(u_boot_dtsi_loc)u-boot.dtsi ... \
found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
 
 # Uncomment for debugging
@@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc\
 $(UBOOTINCLUDE) \
 -I$(dir $<) \
+-I$(u_boot_dtsi_loc) \
 -I$(srctree)/arch/$(ARCH)/dts/include   \
 -I$(srctree)/include\
 -D__ASSEMBLY__  \
@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
  echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
$(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) 
$(pre-tmp) ; \
$(DTC) -O dtb -o $@ -b 0 \
-   -i $(dir $<) $(DTC_FLAGS) \
+   -i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \
-d $(depfile).dtc.tmp $(dtc-tmp) || \
(echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \
; \
@@ -350,12 +353,13 @@ 
capsule_esl_input_file=$(srctree)/lib/efi_loader/capsule_esl.dtsi.in
 capsule_esl_dtsi = .capsule_esl.dtsi
 capsule_esl_path=$(abspath $(srctree)/$(subst 
$(quote),,$(CONFIG_EFI_CAPSULE_ESL_FILE)))
 
+dtsi_include_list_deps := $(addprefix $(u_boot_dtsi_loc),$(subst 
$(quote),,$(dtsi_include_list)))
+
 ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
 dtsi_include_list += $(capsule_esl_dtsi)
+dtsi_include_list_deps += $(obj)/$(capsule_esl_dtsi)
 endif
 
-dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
$(quote),,$(dtsi_include_list)))
-
 ifneq ($(CHECK_DTBS),)
 DT_CHECKER ?= dt-validate
 DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m)
-- 
2.34.1

[PATCH v6 01/11] CI: Exclude devicetree-rebasing subtree for CONFIG checks

Since devicetree-rebasing is an external repo with its own coding style,
exclude it from Azure and gitlab CI CONFIG checks.

Reviewed-by: Tom Rini 
Reviewed-by: Ilias Apalodimas 
Reviewed-by: Simon Glass 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather
  than devicetree-rebasing sub-directory to better suite U-Boot
  directory structure.

Changes in v3:
- Picked up review tags

Changes in v2:
- excluded gitab CI config check and added commit description.

 .azure-pipelines.yml | 3 ++-
 .gitlab-ci.yml   | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index e2646783ee62..1d73215afbae 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -65,7 +65,8 @@ stages:
   # have no matches.
   - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
   :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
-  :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
+  :^include/linux/kconfig.h :^tools/ :^dts/upstream/ &&
+  exit 1 || exit 0
 
   - job: docs
 displayName: 'Build documentation'
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 278a2e2bbf31..8bfbadd6c89f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -161,7 +161,8 @@ check for new CONFIG symbols outside Kconfig:
 # have no matches.
 - git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
 :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
-:^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
+:^include/linux/kconfig.h :^tools/ :^dts/upstream/ &&
+exit 1 || exit 0
 
 # build documentation
 docs:
-- 
2.34.1

[PATCH v6 02/11] Makefile: Add support for DT bindings schema checks

This adds the build infrastructure for checking DT binding schema
documents and validating dtb files using the binding schema. Here we use
devicetree-rebasing subtree to provide the DT bindings. Along with that
adapt dts/upstream/Bindings/Makefile to align with old U-Boot Kbuild
infrastructure.

Dependency:
---

The DT schema project must be installed in order to validate the DT schema
binding documents and validate DTS files using the DT schema. The DT schema
project can be installed with pip::

pip3 install dtschema

Note that 'dtschema' installation requires 'swig' and Python development
files installed first. On Debian/Ubuntu systems::

apt install swig python3-dev

Testing:


Build dts files and check using DT binding schema:
$ make dtbs_check

Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
use for validation. This makes it easier to find and fix errors
generated by a specific schema.

Note, at this point dtbs_check is an optional build target as there are
many warnings generated due to custom DT properties used by many
platforms in u-boot. It is expected with these checks that compliance
with DT bindings to take place. Once that's done it can be added to CI
builds to remain compliant with DT bindings.

Reviewed-by: Simon Glass 
Tested-by: Simon Glass 
Signed-off-by: Sumit Garg 
---

Changes in v6:
- None

Changes in v5:
- None

Changes in v4:
- Switched subtree to be imported as dts/upstream sub-directory rather
  than devicetree-rebasing sub-directory to better suite U-Boot
  directory structure.
- Incorporate build fix to adjust Bindings Makefile rules to old U-Boot
  Kbuild infrastructure.

Changes in v3:
- None

Changes in v2:
- None

 Makefile   | 20 ++--
 dts/upstream/Bindings/Makefile |  6 +++---
 scripts/Makefile.lib   | 17 +++--
 3 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 3b5db90df6f9..9604a4c517e5 100644
--- a/Makefile
+++ b/Makefile
@@ -1158,12 +1158,28 @@ endif
@# disabling OF_BOARD.
$(call cmd,ofcheck,$(KCONFIG_CONFIG))
 
-PHONY += dtbs
+PHONY += dtbs dtbs_check
 dtbs: dts/dt.dtb
@:
-dts/dt.dtb: u-boot
+dts/dt.dtb: dtbs_prepare u-boot
$(Q)$(MAKE) $(build)=dts dtbs
 
+dtbs_prepare: prepare3
+
+ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),)
+export CHECK_DTBS=y
+endif
+
+ifneq ($(CHECK_DTBS),)
+dtbs_prepare: dt_binding_check
+endif
+
+dtbs_check: dt_binding_check dtbs
+
+DT_BINDING_DIR := dts/upstream/Bindings
+dt_binding_check: scripts_dtc
+   $(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) 
$(DT_BINDING_DIR)/processed-schema.json
+
 quiet_cmd_copy = COPY$@
   cmd_copy = cp $< $@
 
diff --git a/dts/upstream/Bindings/Makefile b/dts/upstream/Bindings/Makefile
index 3e886194b043..e799963a599d 100644
--- a/dts/upstream/Bindings/Makefile
+++ b/dts/upstream/Bindings/Makefile
@@ -47,9 +47,9 @@ quiet_cmd_mk_schema = SCHEMA  $@
  rm -f $$f
 
 define rule_chkdt
-   $(if $(DT_SCHEMA_LINT),$(call cmd,yamllint),)
-   $(call cmd,chk_bindings)
-   $(call cmd,mk_schema)
+   $(if $(DT_SCHEMA_LINT),$(call echo-cmd,yamllint) $(cmd_yamllint),); \
+   $(call echo-cmd,chk_bindings) $(cmd_chk_bindings); \
+   $(call echo-cmd,mk_schema) $(cmd_mk_schema)
 endef
 
 DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 1ca84195c997..f82b3169e874 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -356,8 +356,21 @@ endif
 
 dtsi_include_list_deps = $(addprefix $(obj)/,$(subst 
$(quote),,$(dtsi_include_list)))
 
-$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
-   $(call if_changed_dep,dtc)
+ifneq ($(CHECK_DTBS),)
+DT_CHECKER ?= dt-validate
+DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m)
+DT_BINDING_DIR := dts/upstream/Bindings
+DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json
+
+quiet_cmd_dtb = DTC_CHK $@
+  cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u 
$(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true
+else
+quiet_cmd_dtb = $(quiet_cmd_dtc)
+  cmd_dtb = $(cmd_dtc)
+endif
+
+$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) 
FORCE
+   $(call if_changed_dep,dtb)
 
 pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
-- 
2.34.1

[PATCH v6 00/11] An effort to bring DT bindings compliance within U-Boot

Changes in v6:
--
- v6_dt: https://github.com/b49020/u-boot/tree/v6_dt
- Patch #3: Incorporate fix for sandbox CI failure.
- Patch #6: Incorporate shell script comments from Marek.
- Patch #8: Incorporate documentation review comments from Paul.

Changes in v5:
--
- Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41)
- Created v5_dt branch for testing purposes:
https://github.com/b49020/u-boot/tree/v5_dt
- Patch #6: Added support to cherry-pick fixes in subtree update script.
Also, used https:// instead of git://.
- Patch #7: Fixed inappropriate documentation update.
- Patch #8: Document how to cherry-pick fixes from devicetree-rebasing
tree.

Changes in v4:
--
- Switched subtree to be imported as dts/upstream sub-directory rather
than devicetree-rebasing sub-directory to better suite U-Boot
directory structure.
- Since we now have v6.7-dts tag available now, so switch subtree to
that from its beginning.
- Patch #2: Incorporate build fix to adjust Bindings Makefile rules to
old U-Boot Kbuild infrastructure.
- Patch #3: Incorporate fix to resolve rk3399 migration issue reported
by Simon.
- Patch #4: New patch to reuse upstream DT includes by U-Boot as per
Brian's use-case for TI K3 SoCs.
- Patch #5: Added a note to OF_UPSTREAM Kconfig option.
- Patch #6: New patch to add script dts/update-dts-subtree.sh as per
Rob's comments.
- Patch #7: Separate patch to align documentation to use Kconfig symbols
instead.
- Patch #8: Clarify subtree uprev schedule as a separate documentation
section. Also, fixed documentation typos.
- Patch #9: Added commit description.

Changes in v3:
--
- Patch #4: Minor commit message update
- Patch #5: Replace CONFIG_* with Kconfig options
- Patch #7: Dropped Makefile portion and enabled OF_UPSTREAM for SoC
instead.
- Patch #1, #3, #6 and #8: Picked up review tags

Changes in v2:
--
- Patch #1: excluded gitab CI config check and added commit description.
- Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
- Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
- Patch #5: s/U-boot/U-Boot/
- Patch #6 and #7: Picked up review tags

Prerequisite

This patch series requires devicetree-rebasing git repo to be added as a
subtree to the main U-Boot repo via:

$ git subtree add --prefix dts/upstream \

https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
\
v6.7-dts --squash

Background
--

This effort started while I was reviewing patch series corresponding to
Qcom platforms [1] which was about to import modified devicetree source
files from Linux kernel. I suppose keeping devicetree files sync with
Linux kernel without any DT bindings schema validation has been a pain
for U-Boot SoC/platform maintainers. There has been past discussions
about a single DT repo but that hasn't come up and Linux kernel remained
the place where DT source files as well as bindings are placed and
maintained.

However, Linux kernel DT maintainers proposed [2] for U-Boot to rather
use devicetree-rebasing repo [3] which is a forked copy from Linux
kernel for DT source files as well as bindings. It is tagged at every
Linux kernel major release or intermideate release candidates. So here I
have tried to reuse that to bring DT bingings compliance as well as a
standard way to maintain a regular sync of DT source files with Linux
kernel.

In order to maintain devicetree files sync, U-Boot will maintains a Git
subtree for devicetee-rebasing repo as `dts/upstream` sub-directory.
U-Boot will regularly sync `dts/upstream/` subtree whenever the next window
opens with the next available kernel major release.
`dts/update-dts-subtree.sh` script provides a wrapper around git subtree
pull command, usage from the top level U-Boot source tree, run:

$ ./dts/update-dts-subtree.sh pull

If required it is also possible to cherry-pick fixes from
devicetree-rebasing tree prior to next sync, usage:

$ ./dts/update-dts-subtree.sh pick

The RFC/prototype for this series has been discussed with Linux DT
maintainers as well as U-Boot maintainers here [4]. Now we would like to
reach out to wider U-Boot community to seek feedback.

[1]
https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=r0uur+1uetmkkjm2zddmjtxb3nmrlk+...@mail.gmail.com/
[2]
https://lore.kernel.org/all/cal_jsqkejv2tsgmt+0zio7_qbbfhtycbgnhjhypkdfzfo9j...@mail.gmail.com/
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/
[4] https://github.com/u-boot/u-boot/pull/451

Changes
---

Traditionally, U-Boot placed copies of devicetree source files from Linux
kernel into `arch//dts/.dts` which can be selected via setting
"" when prompted for `DEFAULT_DEVICE_TREE` by Kconfig.

SoC/board maintainers are encouraged to migrate to use synced copies from
`dts/upstream/src//`. To do that enable `OF_UPSTREAM` for the
SoC being used via Kconfig and set up "/" when prompted for
`DEFAULT_DEVICE_TREE` by

Re: [PATCH] implement policy_pcr commands to lock NV-indexes behind a PCR

2024-02-22 Thread niek.nooij...@omron.com

Hi Illias

sure I pushed it here:
https://github.com/nieknooijens/u-boot/tree/tpm_policy_patch


Niek


差出人: Ilias Apalodimas 
送信日時: 2024年2月21日 18:01
宛先: Niek Nooijens / OC-IAB PBD-C DEVEL 1-1 
CC: Dan Carpenter ; u-boot@lists.denx.de 

件名: Re: [PATCH] implement policy_pcr commands to lock NV-indexes behind a PCR

[ilias.apalodi...@linaro.org 
からのメールを受け取る頻度は高くありません。これが問題である可能性の理由については、https://aka.ms/LearnAboutSenderIdentification
 をご覧ください。]

Hi Niek,

Thanks for the patch. The reason it's hard for us to apply it, is that
this patch seems copy-pasted on an email.

Instead, you should follow the guidelines here [0]. Till you get this
sorted, do you have it on a git branch somewhere, so I can cherry-pick
it and run it through the CI?

[0] 
https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.u-boot.org%2Fen%2Flatest%2Fdevelop%2Fsending_patches.html&data=05%7C02%7Cniek.nooijens%40omron.com%7Ccecf2d3ccfee492b819a08dc32bbd390%7C0ecff5a94bef4a7b96eca96579b4ac37%7C0%7C0%7C638441029505061036%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UFTu5wiss76QRjy6rZxMRl43o90j%2BWn0UVrSPGRdaLU%3D&reserved=0

Thanks
/Ilias


On Wed, 21 Feb 2024 at 02:12, niek.nooij...@omron.com
 wrote:
>
> Hi dan
>
> This might be because I used the checkpatch.pl script.
> Here's one without it.
>
> Niek
>
> =START PATCH ===
> From de056f510156a2fa1b4b439e1fa1f44516aa8add Mon Sep 17 00:00:00 2001
> From: Niek Nooijens 
> Date: Tue, 20 Feb 2024 13:42:57 +0900
> Subject: [PATCH] [TPM] implement commands to lock NV-indexes behind a PCR
>  policy
>
> Added commands are:
> - start auth session
> - flush context
> - policyPCR
> - getPolicyDigest
>
> Signed-off-by: Niek Nooijens 
> ---
>  cmd/tpm-v2.c | 258 +++
>  include/tpm-common.h |   2 +
>  include/tpm-v2.h | 126 ---
>  lib/tpm-v2.c | 355 +--
>  lib/tpm_api.c|   4 +-
>  5 files changed, 669 insertions(+), 76 deletions(-)
>
> diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> index 7e479b9dfe..6b6f4629ea 100644
> --- a/cmd/tpm-v2.c
> +++ b/cmd/tpm-v2.c
> @@ -356,6 +356,221 @@ static int do_tpm_pcr_setauthvalue(struct cmd_tbl 
> *cmdtp, int flag,
>   key, key_sz));
>  }
>
> +static int do_tpm_nv_define(struct cmd_tbl *cmdtp, int flag,
> +      int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + struct tpm_chip_priv *priv;
> + u32 nv_addr, nv_size, rc;
> + void *policy_addr = NULL;
> + size_t policy_size = 0;
> + int ret;
> +
> + u32 nv_attributes = TPMA_NV_PLATFORMCREATE | TPMA_NV_OWNERWRITE | 
> TPMA_NV_OWNERREAD | TPMA_NV_PPWRITE | TPMA_NV_PPREAD;
> +
> + if (argc < 3 && argc > 7)
> +   return CMD_RET_USAGE;
> +
> + ret = get_tpm(&dev);
> + if (ret)
> +   return ret;
> +
> + priv = dev_get_uclass_priv(dev);
> + if (!priv)
> +   return -EINVAL;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> +
> + nv_size = simple_strtoul(argv[2], NULL, 0);
> +
> + if (argc > 3)
> +   nv_attributes = simple_strtoul(argv[3], NULL, 0);
> +
> + if (argc > 4) {
> +   policy_addr = map_sysmem(simple_strtoul(argv[4], NULL, 0), 0);
> +   nv_attributes |= (TPMA_NV_POLICYREAD | TPMA_NV_POLICYWRITE); 
> //obligated, might as well force it
> +   if (argc < 5)
> + return CMD_RET_USAGE;
> +   policy_size = simple_strtoul(argv[5], NULL, 0);
> + }
> +
> + rc = tpm2_nv_define_space(dev, nv_addr, nv_size, nv_attributes, 
> policy_addr, policy_size);
> +
> + if (rc)
> +   printf("ERROR: nv_define #%u returns: 0x%x\n", nv_addr, rc);
> +
> + if (policy_addr)
> +   unmap_sysmem(policy_addr);
> +
> + return report_return_code(rc);
> +}
> +
> +static int do_tpm_nv_undefine(struct cmd_tbl *cmdtp, int flag,
> +      int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + u32 nv_addr, ret, rc;
> +
> + ret = get_tpm(&dev);
> + if (ret)
> +   return ret;
> +
> + if (argc != 2)
> +   return CMD_RET_USAGE;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> + rc = tpm2_nv_undefine_space(dev, nv_addr);
> +
> + return report_return_code(rc);
> +}
> +
> +static int do_tpm_nv_read_value(struct cmd_tbl *cmdtp, int flag,
> +      int argc, char *const argv[])
> +{
> + struct udevice *dev;
> + u32 nv_addr, nv_size, rc;
> + void *session_addr = NULL;
> + int ret;
> + void *out_data;
> +
> + ret = get_tpm(&dev);
> + if (ret)
> +   return ret;
> +
> + if (argc < 4)
> +   return CMD_RET_USAGE;
> +
> + nv_addr = simple_strtoul(argv[1], NULL, 0);
> +
> + nv_size = simple_

Re: [PATCH] arm64: zynqmp: Support semhosting boot method

2024-02-22 Thread Michal Simek





On 2/20/24 20:30, Sean Anderson wrote:

On 2/20/24 14:18, Michal Simek wrote:



On 2/20/24 19:43, Sean Anderson wrote:

On 2/20/24 13:24, Michal Simek wrote:



On 2/16/24 17:09, Sean Anderson wrote:

On 2/16/24 11:03, Sean Anderson wrote:

On 2/16/24 10:06, Michal Simek wrote:



On 2/16/24 14:48, Michal Simek wrote:



On 2/15/24 20:31, Sean Anderson wrote:

On 2/15/24 14:08, Michal Simek wrote:



On 2/15/24 18:19, Sean Anderson wrote:

Currently, when we boot from JTAG we try to boot U-Boot from RAM.
However, this is a bit tricky to time, since the debugger has to wait
for SPL to initialize RAM before it can load U-Boot. This can result in
long waits, since occasionally initializing RAM (and other things in
psu_init) takes a long time to complete and the debugger must wait for
this worst case.

Support semihosting if it is enabled, as it lets U-Boot tell the
debugger when we are ready for the image. This means we don't have to
wait any more than necessary. We don't change the default config to
ensure we don't break compatibility with existing debuggers that don't
expect us to hit semihosting breakpoints.

Signed-off-by: Sean Anderson 
---

  arch/arm/mach-zynqmp/spl.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-zynqmp/spl.c b/arch/arm/mach-zynqmp/spl.c
index a0f35f36faa..5af735aa5ce 100644
--- a/arch/arm/mach-zynqmp/spl.c
+++ b/arch/arm/mach-zynqmp/spl.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 

@@ -66,6 +67,11 @@ void spl_board_init(void)
  }
  #endif

+static u32 jtag_boot_device(void)
+{
+   return semihosting_enabled() ? BOOT_DEVICE_SMH : BOOT_DEVICE_RAM;
+}
+
  void board_boot_order(u32 *spl_boot_list)
  {
 spl_boot_list[0] = spl_boot_device();
@@ -75,7 +81,7 @@ void board_boot_order(u32 *spl_boot_list)
 if (spl_boot_list[0] == BOOT_DEVICE_MMC2)
 spl_boot_list[1] = BOOT_DEVICE_MMC1;

-   spl_boot_list[2] = BOOT_DEVICE_RAM;
+   spl_boot_list[2] = jtag_boot_device();
  }

  u32 spl_boot_device(void)
@@ -97,7 +103,7 @@ u32 spl_boot_device(void)

 switch (bootmode) {
 case JTAG_MODE:
-   return BOOT_DEVICE_RAM;
+   return jtag_boot_device();
  #ifdef CONFIG_SPL_MMC
 case SD_MODE1:
 case SD1_LSHFT_MODE: /* not working on silicon v1 */


Good timing. Can you please tell me how to test this? What's the setup?
Which debugger are you using?


I am using OpenOCD with the patches at 
https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2freview.openocd.org%2fc%2fopenocd%2f%2b%2f8133&umid=6e1be473-0b3f-4bc4-a4f0-403592e74baf&auth=d807158c60b7d2502abde8a2fc01f40662980862-afc15b07b0f91c910f832185958363d84f990a08



I am trying it on the top of the latest git but getting issue with event block 
and no idea how to fix it.

# sudo openocd -f 
/usr/local/share/openocd/scripts/interface/ftdi/digilent_jtag_hs3.cfg -f 
/usr/local/share/openocd/scripts/target/xilinx_zynqmp.cfg
Open On-Chip Debugger 0.12.0+dev-01509-g6d288937cb2d (2024-02-16-12:22)
Licensed under GNU GPL v2
For bug reports, read

https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fopenocd.org%2fdoc%2fdoxygen%2fbugs.html&umid=6e1be473-0b3f-4bc4-a4f0-403592e74baf&auth=d807158c60b7d2502abde8a2fc01f40662980862-f501ab9aa5516ff666e387e53598fd624398f1bc
Info : auto-selecting first available session transport "jtag". To override use 
'transport select '.
wrong # args: should be "-event  "


Do you know how to fix it?



I actually bisect it and found that it is caused by
jtag: rewrite jim_jtag_configure() as COMMAND_HANDLER
ea2e26f7d521f5755b4bfda7bf12d99650277421


Interesting. I have been testing with 0.12.


# sudo openocd -f 
/usr/local/share/openocd/scripts/interface/ftdi/digilent_jtag_smt2_nc.cfg -f 
/usr/local/share/openocd/scripts/target/xilinx_zynqmp.cfg


FWIW after installing the udev rules I do not need sudo


Open On-Chip Debugger 0.12.0+dev-01512-g214206ebb972 (2024-02-16-15:38)
Licensed under GNU GPL v2
For bug reports, read
   
https://cas5-0-urlprotect.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fopenocd.org%2fdoc%2fdoxygen%2fbugs.html&umid=6e1be473-0b3f-4bc4-a4f0-403592e74baf&auth=d807158c60b7d2502abde8a2fc01f40662980862-f501ab9aa5516ff666e387e53598fd624398f1bc
none separate
Info : auto-selecting first available session transport "jtag". To override use 
'transport select '.
Info : Hardware thread awareness created
boot_apu
Info : Listening on port  for tcl connections
Info : Listening on port  for telnet connections
Warn : An adapter speed is not selected in the init scripts. OpenOCD will try 
to run the adapter at very low speed (100 kHz).
Warn : To remove this warnings and achieve reasonable communication speed with the target, set 
"adapter speed" or "jtag_rclk" i

Re: [PATCH v2 13/15] rockchip: rk3328: Add support to build bootable SPI image


Hi Jonas,

On 2/17/24 01:22, Jonas Karlman wrote:

Similar to RK35xx the BootRom in RK3328 can read all data and look for
idbloader at 0x8000, same as it does for SD and eMMC.

Use the rksd format and modify the mkimage offset to generate a bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash.

Signed-off-by: Jonas Karlman 
---
v2:
- No change
---
  arch/arm/dts/rk3328-u-boot.dtsi| 11 +++
  arch/arm/mach-rockchip/rk3328/rk3328.c |  1 +
  2 files changed, 12 insertions(+)

diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index a030f1a5e51d..4d43fe2fb51a 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -133,3 +133,14 @@
  &usb20_otg {
hnp-srp-disable;
  };
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+&binman {
+   simple-bin-spi {
+   mkimage {
+   args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+   offset = <0x8000>;
+   };
+   };
+};
+#endif


Do we have a list of SoCs that need to use rkspi type for booting from 
SPI flashes? I would much rather have rksd the default in 
rockchip-u-boot.dtsi instead of having to add it for each and every SoC 
which is not impacted by this change (which I assume should be now all 
new SoCs?).


I could also imagine a Kconfig symbol just for that, one that would NOT 
appear in menuconfig because it makes no sense to make it selectable (I 
think this can be achieved without a prompt?), e.g. (not tested):

"""
config ROCKCHIP_SPI_IMAGE_TYPE
string
depends on ROCKCHIP_SPI_IMAGE
default "rksd"
default "rkspi" if ROCKCHIP_RK3399
help
  The type passed to mkimage to generate a TPL+SPL image bootable 
from SPI flash on Rockchip SoCs.

"""

and then have
"""
args = "-n", CONFIG_SYS_SOC, "-T", CONFIG_ROCKCHIP_SPI_IMAGE_TYPE;
"""

in rockchip-u-boot.dtsi instead?

I've missed those changes for other SoCs but did you explain why the SPI 
image is expected to start at offset 0x8000? We don't have that in 
rockchip-u-boot.dtsi by default, so offset 0 I assume.


Cheers,
Quentin

Re: [PATCH v2 09/15] gpio: rockchip: Use gpio alias id as gpio bank id


Hi Jonas,

On 2/17/24 01:22, Jonas Karlman wrote:

The U-Boot driver try to base the gpio bank id on the gpio-ranges prop
and fall back to base the bank id on the node name. However, the linux
driver try to base the bank id on the gpio alias id and fall back on
node order.

This can cause issues when SoC DT is synced from linux and gpioX@ nodes
has been renamed to gpio@ and gpio-ranges or a SoC specific alias has
not been assigned.

Try to use the gpio alias id as first fallback when a gpio-ranges prop
is missing to ease sync of updated SoC DT. Keep the current fallback on
node name as a third fallback to not affect any existing unsynced DT.



The gpio alias is not necessarily the same as the gpio bank in the SoC. 
But I guess if it's good enough for the Linux kernel AND the fact that 
we take our device trees from the Linux kernel, it'd be near impossible 
to have a non-working setup for upstream-supported devices. But 
considering all Rockchip SoCs in the Linux kernel have the gpio aliases 
set in the SoC.dtsi and that no board seems to be overriding them, it is 
safe to do.


There's also a possible issue with two gpio controllers using the same 
bank, e.g. if there's one using the first of the three methods, another 
the second one and another one the third one. But again considering all 
Rockchip SoCs in the Linux kernel have the gpio aliases set in the 
SoC.dtsi, this should be covered as well during the next DT sync from Linux.


Therefore,

Reviewed-by: Quentin Schulz 

Thanks,
Quentin

Re: [PATCH 05/11] rockchip: io-domain: Add support for RK3399