Re: [PATCH 1/2] arm: mvebu: armada-370-xp.dtsi: add u-boot,dm-pre-reloc to spi0

[Ezra Buehler]

Hi Stefan,


On 5 May 2020, at 08:45, Stefan Roese  wrote:
> U-Boot specific DT properties, like "u-boot,dm-pre-reloc" should be
> added in U-Boot specific DT dtsi files

OK, that makes sense. However, in your commit 1718a9f3b7 (arm: mvebu:
armada-370-xp.dtsi: Add "u-boot, dm-pre-reloc" to "internal-regs") you
wrote:

  I'm not adding this property in an *u-boot.dtsi file, since there is
  none matching the generic rules for all files including this dtsi
  file. So to not miss any of the boards using this dtsi file, I'm
  adding it to this file directly, which makes the Linux merge a less
  easy unforunately.


So, do you want me to try this now?

Cheers,
Ezra.

[PATCH 1/4] configs: ls1012a: Increase CONFIG_SYS_MALLOC_LEN size

[Kuldeep Singh]

CONFIG_SYS_MALLOC_LEN is currently set to low value and leaves very less
space to do malloc in flash environmet. Increase the value to get more
memory and also make it align with other boards(ls1046a, ls1043a etc.)
config values.

Signed-off-by: Kuldeep Singh 
---
 include/configs/ls1012a_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index e9baa2a..c34faf2 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -34,7 +34,7 @@
 #define CONFIG_LAYERSCAPE_NS_ACCESS
 
 /* Size of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 128 * 1024)
+#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 1024 * 1024)
 
 /*SPI device */
 #if defined(CONFIG_QSPI_BOOT) || defined(CONFIG_TFABOOT)
-- 
2.7.4

[PATCH 3/4] configs: nxp: Enable CONFIG_SYS_RELOC_GD_ENV_ADDR

[Kuldeep Singh]

Commit 323d3af59fe4 ("configs: ls1012ardb: Enable
CONFIG_SYS_RELOC_GD_ENV_ADDR") enables the config only for LS1012ARDB.

Apart from LS1012A-RDB, other platforms such as LS1012A-FRWY, LS2088A
and LS1046A-RDB/FRWY also require this config to be enabled. This also
helps in resolving booting crash observed in flash environment.

Signed-off-by: Kuldeep Singh 
---
 configs/ls1012afrwy_qspi_defconfig | 1 +
 configs/ls1012afrwy_tfa_defconfig  | 1 +
 configs/ls1046afrwy_tfa_defconfig  | 1 +
 configs/ls1046ardb_tfa_defconfig   | 1 +
 configs/ls2088aqds_tfa_defconfig   | 1 +
 configs/ls2088ardb_tfa_defconfig   | 1 +
 6 files changed, 6 insertions(+)

diff --git a/configs/ls1012afrwy_qspi_defconfig 
b/configs/ls1012afrwy_qspi_defconfig
index 50e261e..9514450 100644
--- a/configs/ls1012afrwy_qspi_defconfig
+++ b/configs/ls1012afrwy_qspi_defconfig
@@ -32,6 +32,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-frwy"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x401D
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
diff --git a/configs/ls1012afrwy_tfa_defconfig 
b/configs/ls1012afrwy_tfa_defconfig
index 5ac2656..83c7410 100644
--- a/configs/ls1012afrwy_tfa_defconfig
+++ b/configs/ls1012afrwy_tfa_defconfig
@@ -32,6 +32,7 @@ CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-frwy"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x401D
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
diff --git a/configs/ls1046afrwy_tfa_defconfig 
b/configs/ls1046afrwy_tfa_defconfig
index 48dc7ac..68271c3 100644
--- a/configs/ls1046afrwy_tfa_defconfig
+++ b/configs/ls1046afrwy_tfa_defconfig
@@ -32,6 +32,7 @@ CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-frwy"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x4050
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
 CONFIG_FSL_CAAM=y
diff --git a/configs/ls1046ardb_tfa_defconfig b/configs/ls1046ardb_tfa_defconfig
index eab34cd..c20e524 100644
--- a/configs/ls1046ardb_tfa_defconfig
+++ b/configs/ls1046ardb_tfa_defconfig
@@ -33,6 +33,7 @@ CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1046a-rdb"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x4050
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
 CONFIG_FSL_CAAM=y
diff --git a/configs/ls2088aqds_tfa_defconfig b/configs/ls2088aqds_tfa_defconfig
index 3116a99..7142f86 100644
--- a/configs/ls2088aqds_tfa_defconfig
+++ b/configs/ls2088aqds_tfa_defconfig
@@ -37,6 +37,7 @@ CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x2050
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
diff --git a/configs/ls2088ardb_tfa_defconfig b/configs/ls2088ardb_tfa_defconfig
index 4f1c2d6..8e087b8 100644
--- a/configs/ls2088ardb_tfa_defconfig
+++ b/configs/ls2088ardb_tfa_defconfig
@@ -39,6 +39,7 @@ CONFIG_ENV_IS_IN_FLASH=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_ADDR=0x2050
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SATA_CEVA=y
-- 
2.7.4

[PATCH 0/4] QSPI bugfixes of NXP layerscape platforms

[Kuldeep Singh]

This patch series is an attempt to fix qspi bugs on various NXP 
layerscape platforms like ls1012a, ls1046a, ls2088a.

Bug fixes involves crashes in flash environment.

Patch series depends on
https://patchwork.ozlabs.org/project/uboot/patch/1581413944-7958-3-git-send-email-kuldeep.si...@nxp.com/

Patch1: Increase malloc len for more space.
Patch2: Reduce ENV_SIZE to successfully store env in ls1012a.
Patch3: Enable RELOC_GD config to resolve environment booting crash.
Patch4: Unset ENV_ADDR value for ls1012a to resolve crash.

Ashish Kumar (1):
  configs: ls1012a: Reduce CONFIG_ENV_SIZE to 0x2000

Kuldeep Singh (3):
  configs: ls1012a: Increase CONFIG_SYS_MALLOC_LEN size
  configs: nxp: Enable CONFIG_SYS_RELOC_GD_ENV_ADDR
  configs: ls1012a: Unset ENV_ADDR value

 configs/ls1012a2g5rdb_qspi_defconfig   | 2 +-
 configs/ls1012a2g5rdb_tfa_defconfig| 2 +-
 configs/ls1012afrdm_qspi_defconfig | 2 +-
 configs/ls1012afrdm_tfa_defconfig  | 2 +-
 configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 2 +-
 configs/ls1012afrwy_qspi_defconfig | 3 ++-
 configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig  | 2 +-
 configs/ls1012afrwy_tfa_defconfig  | 4 ++--
 configs/ls1012aqds_qspi_defconfig  | 2 +-
 configs/ls1012aqds_tfa_SECURE_BOOT_defconfig   | 2 +-
 configs/ls1012aqds_tfa_defconfig   | 2 +-
 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig  | 2 +-
 configs/ls1012ardb_qspi_defconfig  | 2 +-
 configs/ls1012ardb_tfa_SECURE_BOOT_defconfig   | 2 +-
 configs/ls1012ardb_tfa_defconfig   | 3 +--
 configs/ls1046afrwy_tfa_defconfig  | 1 +
 configs/ls1046ardb_tfa_defconfig   | 1 +
 configs/ls2088aqds_tfa_defconfig   | 1 +
 configs/ls2088ardb_tfa_defconfig   | 1 +
 include/configs/ls1012a_common.h   | 2 +-
 20 files changed, 22 insertions(+), 18 deletions(-)

-- 
2.7.4

[PATCH 2/4] configs: ls1012a: Reduce CONFIG_ENV_SIZE to 0x2000

[Kuldeep Singh]

From: Ashish Kumar 

All LS1012A board variants have same CONFIG_ENV_SECT_SIZE and
CONFIG_ENV_SIZE values. If both config values are same, flash
environment cannot be saved. Since, CONFIG_ENV_SECT_SIZE needs to be
same as that of flash sector size, this entry cannot be changed.
Reduce CONFIG_ENV_SIZE value to 0x2000. This also helps in making config
value aligned with other boards environemt size.

Signed-off-by: Kuldeep Singh 
Signed-off-by: Ashish Kumar 
---
 configs/ls1012a2g5rdb_qspi_defconfig   | 2 +-
 configs/ls1012a2g5rdb_tfa_defconfig| 2 +-
 configs/ls1012afrdm_qspi_defconfig | 2 +-
 configs/ls1012afrdm_tfa_defconfig  | 2 +-
 configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 2 +-
 configs/ls1012afrwy_qspi_defconfig | 2 +-
 configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig  | 2 +-
 configs/ls1012afrwy_tfa_defconfig  | 2 +-
 configs/ls1012aqds_qspi_defconfig  | 2 +-
 configs/ls1012aqds_tfa_SECURE_BOOT_defconfig   | 2 +-
 configs/ls1012aqds_tfa_defconfig   | 2 +-
 configs/ls1012ardb_qspi_SECURE_BOOT_defconfig  | 2 +-
 configs/ls1012ardb_qspi_defconfig  | 2 +-
 configs/ls1012ardb_tfa_SECURE_BOOT_defconfig   | 2 +-
 configs/ls1012ardb_tfa_defconfig   | 2 +-
 15 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/configs/ls1012a2g5rdb_qspi_defconfig 
b/configs/ls1012a2g5rdb_qspi_defconfig
index 9bf5b9c..c539243 100644
--- a/configs/ls1012a2g5rdb_qspi_defconfig
+++ b/configs/ls1012a2g5rdb_qspi_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1012A2G5RDB=y
 CONFIG_SYS_TEXT_BASE=0x4010
-CONFIG_ENV_SIZE=0x4
+CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x30
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
diff --git a/configs/ls1012a2g5rdb_tfa_defconfig 
b/configs/ls1012a2g5rdb_tfa_defconfig
index d9d4f82..ac34acd 100644
--- a/configs/ls1012a2g5rdb_tfa_defconfig
+++ b/configs/ls1012a2g5rdb_tfa_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_TARGET_LS1012A2G5RDB=y
 CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
-CONFIG_ENV_SIZE=0x4
+CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x50
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
diff --git a/configs/ls1012afrdm_qspi_defconfig 
b/configs/ls1012afrdm_qspi_defconfig
index 02a80b1..5a5b8d9 100644
--- a/configs/ls1012afrdm_qspi_defconfig
+++ b/configs/ls1012afrdm_qspi_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1012AFRDM=y
 CONFIG_SYS_TEXT_BASE=0x4010
-CONFIG_ENV_SIZE=0x4
+CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x30
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
diff --git a/configs/ls1012afrdm_tfa_defconfig 
b/configs/ls1012afrdm_tfa_defconfig
index ecc4c81..3531aaa 100644
--- a/configs/ls1012afrdm_tfa_defconfig
+++ b/configs/ls1012afrdm_tfa_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_TARGET_LS1012AFRDM=y
 CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
-CONFIG_ENV_SIZE=0x4
+CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x50
 CONFIG_ENV_SECT_SIZE=0x4
 CONFIG_DM_GPIO=y
diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig 
b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
index addb31c..a2e85b2 100644
--- a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
+++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1012AFRWY=y
 CONFIG_SYS_TEXT_BASE=0x4010
-CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_SIZE=0x2000
 CONFIG_NXP_ESBC=y
 CONFIG_DM_GPIO=y
 CONFIG_FSL_LS_PPA=y
diff --git a/configs/ls1012afrwy_qspi_defconfig 
b/configs/ls1012afrwy_qspi_defconfig
index 2156f5e..50e261e 100644
--- a/configs/ls1012afrwy_qspi_defconfig
+++ b/configs/ls1012afrwy_qspi_defconfig
@@ -1,7 +1,7 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS1012AFRWY=y
 CONFIG_SYS_TEXT_BASE=0x4010
-CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x1D
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
diff --git a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig 
b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
index a4fdd0c..86d7689 100644
--- a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
+++ b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_TARGET_LS1012AFRWY=y
 CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
-CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_SIZE=0x2000
 CONFIG_NXP_ESBC=y
 CONFIG_DM_GPIO=y
 CONFIG_NR_DRAM_BANKS=2
diff --git a/configs/ls1012afrwy_tfa_defconfig 
b/configs/ls1012afrwy_tfa_defconfig
index 280dbd3..5ac2656 100644
--- a/configs/ls1012afrwy_tfa_defconfig
+++ b/configs/ls1012afrwy_tfa_defconfig
@@ -2,7 +2,7 @@ CONFIG_ARM=y
 CONFIG_TARGET_LS1012AFRWY=y
 CONFIG_TFABOOT=y
 CONFIG_SYS_TEXT_BASE=0x8200
-CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_SIZE=0x2000
 CONFIG_ENV_OFFSET=0x1D
 CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
diff --git a/configs/ls1012aqds_qspi_defconfig 
b/configs/ls1012aqds_qspi_defconfig
index 7826661..db7d6e1 100644
--- a/configs/ls1012aqds_qspi_defconfig
+++ b/configs/ls1012aqds_qspi_defconfig
@@ -1,

[PATCH 4/4] configs: ls1012a: Unset ENV_ADDR value

[Kuldeep Singh]

LS1012A-FRWY and LS1012A-RDB crashes in flash environment when
CONFIG_ENV_ADDR value is set. Unset the config value in *_tfa_defconfig*
to resolve booting crash.

Following crash is observed:
Using SERDES1 Protocol: 13576 (0x3508)
"Synchronous Abort" handler, esr 0x9606
elr: 820452c0 lr : 82013f54 (reloc)
elr: b7b932c0 lr : b7b61f54
x0 :  x1 : 7604e004
x2 : 0001 x3 : 
...
Code: 5480 9100c000 17f7 f9402241 (3860c820)
Resetting CPU ...

Signed-off-by: Kuldeep Singh 
---
 configs/ls1012afrwy_tfa_defconfig | 1 -
 configs/ls1012ardb_tfa_defconfig  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/ls1012afrwy_tfa_defconfig 
b/configs/ls1012afrwy_tfa_defconfig
index 83c7410..8ecbf7c 100644
--- a/configs/ls1012afrwy_tfa_defconfig
+++ b/configs/ls1012afrwy_tfa_defconfig
@@ -31,7 +31,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-frwy"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_ENV_ADDR=0x401D
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
diff --git a/configs/ls1012ardb_tfa_defconfig b/configs/ls1012ardb_tfa_defconfig
index 85d92cf..bf89730 100644
--- a/configs/ls1012ardb_tfa_defconfig
+++ b/configs/ls1012ardb_tfa_defconfig
@@ -33,7 +33,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1012a-rdb"
 CONFIG_ENV_IS_IN_SPI_FLASH=y
-CONFIG_ENV_ADDR=0x4050
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
-- 
2.7.4

Re: [PATCH v3 00/17] mtd: spi-nor-core: add xSPI Octal DTR support

[Vignesh Raghavendra]

On 21/04/20 1:19 pm, Pratyush Yadav wrote:
> Hi Jagan,
> 
> On 30/03/20 09:15PM, Pratyush Yadav wrote:
>> Hi,
>>
>> This series adds support for octal DTR flashes in the spi-nor framework,
>> and then adds hooks for the Cypress Semper flash which is an xSPI
>> compliant Octal DTR flash.
>>
>> The Cadence QSPI controller driver is also updated to run in Octal DTR
>> mode.
>>
>> Tested on TI J721e EVM with 1-bit ECC on the Cypress flash on top of
>> u-boot-ti/next.
>>
>> This series depends on [0].
>>
>> [0] cf. <20200224071051.19331-1-p.ya...@ti.com>
>> [0] https://lists.denx.de/pipermail/u-boot/2020-February/401192.html
>>
>> Changes in v3:
>> - Read 2 bytes in Octal DTR mode when reading SR and FSR to avoid
>>   tripping up controllers.
>> - Use op->data.nbytes as a measure of whether the data phase exists or
>>   not. This fixes data buswidth not being updadted for SR and FSR reads
>>   because they keep data buffer as NULL when calling spi_nor_setup_op().
>> - Add support for Micron mt35xu512aba to run in Octal DTR mode.
> 
> Any comments on the series? If not, please pull it in.
> 


Reviewed-by: Vignesh Raghavendra 

Re: Calling i2c set speed twice for i2c_mux_bus

[Michal Simek]

On 15. 04. 20 8:40, Michal Simek wrote:
> On 10. 04. 20 10:49, Heiko Schocher wrote:
>> Hello Michal,
>>
>> Am 10.04.2020 um 08:46 schrieb Michal Simek:
>>> Hi Heiko,
>>>
>>> On 10. 04. 20 7:11, Heiko Schocher wrote:
 Hello Michal,

 Am 09.04.2020 um 16:03 schrieb Michal Simek:
> Hi Heiko and Simon,
>
> I have find out one bug in i2c class. I am using zcu104 revC board
> which
> has dts in mainline where i2c1 has i2c mux with some channels.
> In DT clock-frequency = <40>; is specified and it is read in
> i2c_post_probe(). But i2c_mux_bus_drv is also UCLASS_I2C which means
> that post probe is called for it too. And because clock-frequency
> property is not there default 100k is used.
>
> I think that is bug and should be fixed.
> Heiko: Are you aware about this issue?

 No :-(

 The question is, is this a bug?
>>>
>>> I have never seen clock-frequency property in i2c mux bus node. Also I
>>> have looked at linux dt binding docs and nothing like that is specified
>>> there. From quick look also pca954x driver is not reading it.
>>
>> Indeed.
>>
 Should a i2c bus behind a mux not be able to set his own speed?
>>>
>>> Not sure if that make sense but Linux will likely ignore it. I am not
>>> saying it doesn't make sense but I haven't seen this feature.
>>
>> Ok.
>>
 But may as a feature (or bugfix?) if "clock-frequency" is not there,
 use the speed of the parent bus...?
>>>
>>> I was thinking about this too.
>>> just c&p quick implementation would look like this. Because it is
>>> i2c->i2c_mux->i2c. But maybe there is a better way how to do it.
>>>
>>> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
>>> index 2aa3efe8aaa0..982c467deba3 100644
>>> --- a/drivers/i2c/i2c-uclass.c
>>> +++ b/drivers/i2c/i2c-uclass.c
>>> @@ -640,9 +640,21 @@ static int i2c_post_probe(struct udevice *dev)
>>>   {
>>>   #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>>>  struct dm_i2c_bus *i2c = dev_get_uclass_priv(dev);
>>> +   int parent_speed = I2C_SPEED_STANDARD_RATE;
>>> +
>>> +   if (dev->parent &&
>>> +   device_get_uclass_id(dev->parent) == UCLASS_I2C_MUX &&
>>> +   dev->parent->parent &&
>>> +   device_get_uclass_id(dev->parent->parent) == UCLASS_I2C) {
>>> +   struct dm_i2c_bus *i2c_parent;
>>> +
>>> +   i2c_parent = dev_get_uclass_priv(dev->parent->parent);
>>> +   parent_speed = i2c_parent->speed_hz;
>>> +   /* Not sure if make sense to check that parent_speed is
>>> not 0 */
>>
>> I think this check is not needed.
>>
>>> +   }
>>>
>>>  i2c->speed_hz = dev_read_u32_default(dev, "clock-frequency",
>>> -    I2C_SPEED_STANDARD_RATE);
>>> +    parent_speed);
>>
>> Wow, a big if ... may this is clearer (not compile tested)?
>>
>> udevice *parent = dev_get_parent(dev);
>>
>> if (parent && device_get_uclass_id(parent) == UCLASS_I2C_MUX) {
>> udevice *parent2 = dev_get_parent(parent);
>> if (parent2 && device_get_uclass_id(parent2) == UCLASS_I2C) {
>>     struct dm_i2c_bus *i2cp = dev_get_uclass_priv(parent2);
>>
>>     parent_speed = i2cp->speed_hz;
>> }
>> }
>>
>> but Simon has a deeper DM knowledge, may there is a better approach.
> 
> Simon: any comment on this one?

Simon: Can you please comment this?

Thanks,
Michal

pull request of u-boot-mpc85xx for v2020.07

[Priyanka Jain]

Dear Tom,
Please find my pull-request for u-boot-mpc85xx
https://travis-ci.org/github/p-priyanka-jain/u-boot/builds/682767731

Summary
Add DM model for P1010RDB
Add I2C DM Model support for P1010RDB, T1042RDB, T2080, T4240RDB,
MPC8548CDS, T1024RDB, P4080, P3041DS, P2041RDB, P2020RDB, P1020RDB,
P5040DS
Fix reference to READM.qe_firmware

Thanks
Priyanka
--
The following changes since commit c693f212c5b0433b3a49a89d87cbff28bf78eb87:

  Merge branch '2020-05-01-master-imports' (2020-05-01 16:43:15 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-mpc85xx.git HEAD

for you to fetch changes up to 9e36eae1249f477275a607736eda75e663d1b57c:

  powerpc: dts: p1010: add i2c node (2020-05-04 09:12:37 +0530)


Biwen Li (28):
  rtc: ds1337: Add driver model support
  rtc: pt7c4338: Add driver model support
  powerpc: create dts component of i2c to build up an SoC
  dm: powerpc: P5040DS: add i2c DM support
  configs: P5040DS: enable DM_I2C
  dm: powerpc: P1020: add i2c DM support
  configs: P1020RDB: enable DM_I2C and DM_RTC
  dts: powerpc: P2020RDB: add i2c node
  configs: P2020RDB: enable DM_I2C and DM_RTC
  dm: powerpc: P2041RDB: add i2c DM support
  config: P2041RDB: enable DM_I2C
  powerpc: dts: P3041: add i2c node
  configs: P3041DS: enable DM_I2C
  powerpc: dts: P4080: add i2c node
  configs: P4080DS: enable DM_I2C
  dm: powerpc: T1023/T1024: add i2c DM support
  configs: T1024RDB: enable DM_I2C and DM_RTC
  dm: ppc: p1010: add i2c DM support
  configs: P1010: Enable DM_I2C and DM_RTC
  dm: ppc: MPC8548CDS: add i2c DM support
  configs: MPC8548CDS: enable DM_I2C
  dm: ppc: T4240: add i2c DM support
 configs: T4240RDB: enable DM_I2C
  dm: powerpc: T2080/T2081: add i2c DM support
  configs: T2080: enable DM_I2C
  dm: powerpc: T1040/T1042: add i2c DM support
  configs: T1042D4RDB: enable DM_I2C and DM_RTC
  powerpc: dts: p1010: add i2c node

Heinrich Schuchardt (1):
  doc: fix references to README.qe_firmware

Hou Zhiqiang (4):
  powerpc: Enable device tree support for P1010RDB
  powerpc: P1010RDB: Compile legacy PCIe routines conditionally
  powerpc: P1010RDB: Disable legacy PCIe driver when DM_PCI is enabled
  configs: P1010RDB: Enable PCIe driver

arch/powerpc/dts/Makefile|   2 +
arch/powerpc/dts/p1010rdb-pa.dts |  17 ++
arch/powerpc/dts/p1010rdb-pa_36b.dts |  17 ++
arch/powerpc/dts/p1010rdb-pb.dts |  18 ++
arch/powerpc/dts/p1010rdb-pb_36b.dts |  18 ++
arch/powerpc/dts/p1010rdb.dtsi   |  14 ++
arch/powerpc/dts/p1010rdb_32b.dtsi   |  22 +++
arch/powerpc/dts/p1010rdb_36b.dtsi   |  22 +++
arch/powerpc/dts/p1010si-post.dtsi   |  48 +
arch/powerpc/dts/p1010si-pre.dtsi|  27 +++
arch/powerpc/dts/p1020-post.dtsi |   2 +
arch/powerpc/dts/p2020-post.dtsi |   3 +
arch/powerpc/dts/p2041.dtsi  |   5 +-
arch/powerpc/dts/p3041.dtsi  |   4 +-
arch/powerpc/dts/p4080.dtsi  |   4 +-
arch/powerpc/dts/p5040.dtsi  |   5 +-
arch/powerpc/dts/pq3-i2c-0.dtsi  |  15 ++
arch/powerpc/dts/pq3-i2c-1.dtsi  |  15 ++
arch/powerpc/dts/qoriq-i2c-0.dtsi|  25 +++
arch/powerpc/dts/qoriq-i2c-1.dtsi|  25 +++
arch/powerpc/dts/t102x.dtsi  |   4 +-
arch/powerpc/dts/t104x.dtsi  |   4 +-
arch/powerpc/dts/t2080.dtsi  |   4 +-
arch/powerpc/dts/t4240.dtsi  |   5 +-
board/freescale/common/sys_eeprom.c  |   3 +-
board/freescale/common/vsc3316_3308.c| 258 ++-
board/freescale/p1010rdb/p1010rdb.c  | 160 -
board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c  |  24 ++-
board/freescale/t102xqds/t102xqds.c  |  95 +-
board/freescale/t102xqds/t102xqds.h  |   3 +-
board/freescale/t102xrdb/t102xrdb.c  |  71 +++-
board/freescale/t1040qds/diu.c   |   5 +-
board/freescale/t1040qds/t1040qds.c  |  18 +-
board/freescale/t1040qds/t1040qds.h  |   3 +-
board/freescale/t208xqds/t208xqds.c  |  19 +-
board/freescale/t4qds/t4240qds.c |  45 -
configs/MPC8548CDS_36BIT_defconfig   |   1 +
configs/MPC8548CDS_defconfig |   1 +
configs/MPC8548CDS_legacy_defconfig  |   1 +
configs/P1010RDB-PA_36BIT_NAND_defconfig |   9 +-
configs/P1010RDB-PA_36BIT_NOR_defconfig  |  10 +-
configs/P1010RDB-PA_36BIT_SDCARD_defconfig   |   9 +-
configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig |   9 +-
configs/P1010RDB-PA_NAND_defconfig   |   9 +-
configs/P1010RDB-PA_NOR_defconfig|  10 +-
configs/P1010RDB-PA_SDCAR

[PATCH v2 2/2] test: dm: update test for open-drain/open-source emulation in gpio-uclass

[Neil Armstrong]

Add tests for testing open-drain/open-source emulation in gpio-uclass.
It also adds two test3-gpios configured as GPIO_ACTIVE_LOW.

Signed-off-by: Neil Armstrong 
---
 arch/sandbox/dts/test.dts |  4 +-
 test/dm/gpio.c| 89 +++
 2 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 4bccfbe6e1..e9b9404363 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -104,7 +104,9 @@
<&gpio_c 2 GPIO_OUT>,
<&gpio_c 3 (GPIO_IN|GPIO_PULL_UP)>,
<&gpio_c 4 (GPIO_IN|GPIO_PULL_DOWN)>,
-   <&gpio_c 5 GPIO_IN>;
+   <&gpio_c 5 GPIO_IN>,
+   <&gpio_c 6 (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_DRAIN)>,
+   <&gpio_c 7 (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_SOURCE)>;
int-value = <1234>;
uint-value = <(-1234)>;
int64-value = /bits/ 64 <0x>;
diff --git a/test/dm/gpio.c b/test/dm/gpio.c
index f5c7aaf3bc..7c18e5c411 100644
--- a/test/dm/gpio.c
+++ b/test/dm/gpio.c
@@ -112,6 +112,95 @@ static int dm_test_gpio(struct unit_test_state *uts)
 }
 DM_TEST(dm_test_gpio, DM_TESTF_SCAN_PDATA | DM_TESTF_SCAN_FDT);
 
+/* Test that GPIO open-drain/open-source emulation works correctly */
+static int dm_test_gpio_opendrain_opensource(struct unit_test_state *uts)
+{
+   struct gpio_desc desc_list[8];
+   struct udevice *dev, *gpio_c;
+   char buf[80];
+
+   ut_assertok(uclass_get_device(UCLASS_TEST_FDT, 0, &dev));
+   ut_asserteq_str("a-test", dev->name);
+
+   ut_assertok(uclass_get_device(UCLASS_GPIO, 3, &gpio_c));
+   ut_asserteq_str("pinmux-gpios", gpio_c->name);
+
+   ut_asserteq(8, gpio_request_list_by_name(dev, "test3-gpios", desc_list,
+ARRAY_SIZE(desc_list), 0))
+
+   ut_asserteq(true, !!device_active(gpio_c));
+   ut_asserteq_ptr(gpio_c, desc_list[0].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[1].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[2].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[3].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[4].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[5].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[6].dev);
+   ut_asserteq_ptr(gpio_c, desc_list[7].dev);
+
+   /* GPIO 0 is (GPIO_OUT|GPIO_OPEN_DRAIN) */
+   ut_asserteq(GPIOD_IS_OUT | GPIOD_OPEN_DRAIN,
+   sandbox_gpio_get_dir_flags(gpio_c, 0));
+
+   /* Set it as output high, should become an input */
+   ut_assertok(dm_gpio_set_value(&desc_list[0], 1));
+   ut_assertok(gpio_get_status(gpio_c, 0, buf, sizeof(buf)));
+   ut_asserteq_str("c0: input: 0 [x] a-test.test3-gpios0", buf);
+
+   /* Set it as output low, should become output low */
+   ut_assertok(dm_gpio_set_value(&desc_list[0], 0));
+   ut_assertok(gpio_get_status(gpio_c, 0, buf, sizeof(buf)));
+   ut_asserteq_str("c0: output: 0 [x] a-test.test3-gpios0", buf);
+
+   /* GPIO 1 is (GPIO_OUT|GPIO_OPEN_SOURCE) */
+   ut_asserteq(GPIOD_IS_OUT | GPIOD_OPEN_SOURCE,
+   sandbox_gpio_get_dir_flags(gpio_c, 1));
+
+   /* Set it as output high, should become output high */
+   ut_assertok(dm_gpio_set_value(&desc_list[1], 1));
+   ut_assertok(gpio_get_status(gpio_c, 1, buf, sizeof(buf)));
+   ut_asserteq_str("c1: output: 1 [x] a-test.test3-gpios1", buf);
+
+   /* Set it as output low, should become an input */
+   ut_assertok(dm_gpio_set_value(&desc_list[1], 0));
+   ut_assertok(gpio_get_status(gpio_c, 1, buf, sizeof(buf)));
+   ut_asserteq_str("c1: input: 1 [x] a-test.test3-gpios1", buf);
+
+   /* GPIO 6 is (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_DRAIN) */
+   ut_asserteq(GPIOD_ACTIVE_LOW | GPIOD_IS_OUT | GPIOD_OPEN_DRAIN,
+   sandbox_gpio_get_dir_flags(gpio_c, 6));
+
+   /* Set it as output high, should become output low */
+   ut_assertok(dm_gpio_set_value(&desc_list[6], 1));
+   ut_assertok(gpio_get_status(gpio_c, 6, buf, sizeof(buf)));
+   ut_asserteq_str("c6: output: 0 [x] a-test.test3-gpios6", buf);
+
+   /* Set it as output low, should become an input */
+   ut_assertok(dm_gpio_set_value(&desc_list[6], 0));
+   ut_assertok(gpio_get_status(gpio_c, 6, buf, sizeof(buf)));
+   ut_asserteq_str("c6: input: 0 [x] a-test.test3-gpios6", buf);
+
+   /* GPIO 7 is (GPIO_ACTIVE_LOW|GPIO_OUT|GPIO_OPEN_SOURCE) */
+   ut_asserteq(GPIOD_ACTIVE_LOW | GPIOD_IS_OUT | GPIOD_OPEN_SOURCE,
+   sandbox_gpio_get_dir_flags(gpio_c, 7));
+
+   /* Set it as output high, should become an input */
+   ut_assertok(dm_gpio_set_value(&desc_list[7], 1));
+   ut_assertok(gpio_get_status(gpio_c, 7, buf, sizeof(buf)));
+   ut_asserteq_str("c7: input: 0 [x] a-test.test3-gpios7", buf);
+
+   /* Se

[PATCH v2 0/2] gpio: add gpio open-drain & open-source emulation

[Neil Armstrong]

When a line is in open-drain or open-source mode, U-Boot doesn't handle it
directly.

Let's add gpio open-drain & open-source emulation in gpio u-class to make
it transparent to driver using a gpio line from DT.

Changes since v1:
- fixed all open-drain/open source cases
- updated dm gpio test

Neil Armstrong (2):
  gpio: emulate open drain & open source in dm_gpio_set_value()
  test: dm: update test for open-drain/open-source emulation in
gpio-uclass

 arch/sandbox/dts/test.dts  |  4 +-
 drivers/gpio/gpio-uclass.c | 15 +++
 test/dm/gpio.c | 89 ++
 3 files changed, 107 insertions(+), 1 deletion(-)

-- 
2.22.0

[PATCH v2 1/2] gpio: emulate open drain & open source in dm_gpio_set_value()

[Neil Armstrong]

Handle the GPIOD_OPEN_DRAIN & GPIOD_OPEN_SOURCE flags to emulate open drain
and open source by setting the GPIO line as input depending on the
requested value.

The behaviour is taken from the Linux gpiolib.

Signed-off-by: Neil Armstrong 
---
 drivers/gpio/gpio-uclass.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 757ab7106e..d3cea11f76 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -526,6 +526,21 @@ int dm_gpio_set_value(const struct gpio_desc *desc, int 
value)
 
if (desc->flags & GPIOD_ACTIVE_LOW)
value = !value;
+
+   /*
+* Emulate open drain by not actively driving the line high or
+* Emulate open source by not actively driving the line low
+*/
+   if ((desc->flags & GPIOD_OPEN_DRAIN && value) ||
+   (desc->flags & GPIOD_OPEN_SOURCE && !value))
+   return gpio_get_ops(desc->dev)->direction_input(desc->dev,
+   desc->offset);
+   else if (desc->flags & GPIOD_OPEN_DRAIN ||
+desc->flags & GPIOD_OPEN_SOURCE)
+   return gpio_get_ops(desc->dev)->direction_output(desc->dev,
+   desc->offset,
+   value);
+
gpio_get_ops(desc->dev)->set_value(desc->dev, desc->offset, value);
return 0;
 }
-- 
2.22.0

Re: [PATCH 6/8] ARM: imx8m: Fix reset in SPL on NXP iMX8MP EVK

[Harald Seiler]

Hello Fabio,

On Mon, 2020-05-04 at 12:28 -0300, Fabio Estevam wrote:
> On Mon, May 4, 2020 at 12:21 PM Harald Seiler  wrote:
> 
> > With or without the revert?
> 
> When I change the defconfig like:
> 
> --- a/configs/imx8mp_evk_defconfig
> +++ b/configs/imx8mp_evk_defconfig
> @@ -57,7 +57,9 @@ CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>  CONFIG_SPL_DM=y
> +CONFIG_SPL_CLK_COMPOSITE_CCF=y
>  CONFIG_CLK_COMPOSITE_CCF=y
> +CONFIG_SPL_CLK_IMX8MP=y
>  CONFIG_CLK_IMX8MP=y
>  CONFIG_MXC_GPIO=y
>  CONFIG_DM_PCA953X=y
> 
> It prints a single SPL line with the revert and also without the revert.

Ok, I guess this means the imx8mp clock driver in SPL is broken and we
can't easily fix the DM_WATCHDOG issue without it.  I don't really know
much about imx8 nor do I have any hardware which I could use to debug with
so I can't help much with this.

Maybe Peng, who wrote the clock driver, can comment?

Otherwise, the series which contains this patch also fixed the non-DM
reset in SPL so we could revert back to that if all else fails ...

-- 
Harald

Re: [PATCH 1/2] arm: mvebu: armada-370-xp.dtsi: add u-boot,dm-pre-reloc to spi0

[Stefan Roese]

Hi Ezra,

On 05.05.20 09:10, Ezra Buehler wrote:

On 5 May 2020, at 08:45, Stefan Roese  wrote:

U-Boot specific DT properties, like "u-boot,dm-pre-reloc" should be
added in U-Boot specific DT dtsi files


OK, that makes sense. However, in your commit 1718a9f3b7 (arm: mvebu:
armada-370-xp.dtsi: Add "u-boot, dm-pre-reloc" to "internal-regs") you
wrote:

   I'm not adding this property in an *u-boot.dtsi file, since there is
   none matching the generic rules for all files including this dtsi
   file. So to not miss any of the boards using this dtsi file, I'm
   adding it to this file directly, which makes the Linux merge a less
   easy unforunately.


So, do you want me to try this now?


Hmmm, I can't remember the exact details. Thanks for the reference.
But perhaps there is a matching *-u-boot.dtsi rule / pattern that can
be used to include such a newly introduced file. I would very much
welcome it, when you would investigate here.

Thanks,
Stefan

Re: [PATCH v10 20/21] doc: riscv: Add documentation for Sipeed Maix Bit

[Rick Chen]

Hi Sean

> This patch adds documentation for the Sipeed Maix bit, and more generally
> for the Kendryte K210 processor.
>
> Signed-off-by: Sean Anderson 
> ---
>
> Changes in v9:
> - Mark dts code block as "none" explicitly
> Changes in v7:
> - Split off into its own patch
> - Fix size of clint
>
>  doc/board/index.rst|   1 +
>  doc/board/sipeed/index.rst |   9 ++
>  doc/board/sipeed/maix.rst  | 298 +
>  3 files changed, 308 insertions(+)
>  create mode 100644 doc/board/sipeed/index.rst
>  create mode 100644 doc/board/sipeed/maix.rst
>

The CI verification of v10 still fail, please check:
https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/683207657

Thanks,
Rick

> diff --git a/doc/board/index.rst b/doc/board/index.rst
> index 51a2ae6f28..dcc47c5a21 100644
> --- a/doc/board/index.rst
> +++ b/doc/board/index.rst
> @@ -16,6 +16,7 @@ Board-specific doc
> renesas/index
> rockchip/index
> sifive/index
> +   sipeed/index
> st/index
> toradex/index
> xilinx/index
> diff --git a/doc/board/sipeed/index.rst b/doc/board/sipeed/index.rst
> new file mode 100644
> index 00..3518e2d8f4
> --- /dev/null
> +++ b/doc/board/sipeed/index.rst
> @@ -0,0 +1,9 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +
> +Sipeed
> +==
> +
> +.. toctree::
> +   :maxdepth: 2
> +
> +   maix
> diff --git a/doc/board/sipeed/maix.rst b/doc/board/sipeed/maix.rst
> new file mode 100644
> index 00..06e0008b9f
> --- /dev/null
> +++ b/doc/board/sipeed/maix.rst
> @@ -0,0 +1,298 @@
> +.. SPDX-License-Identifier: GPL-2.0+
> +.. Copyright (C) 2020 Sean Anderson 
> +
> +Maix Bit
> +
> +
> +Several of the Sipeed Maix series of boards cotain the Kendryte K210 
> processor,
> +a 64-bit RISC-V CPU. This processor contains several peripherals to 
> accelerate
> +neural network processing and other "ai" tasks. This includes a "KPU" neural
> +network processor, an audio processor supporting beamforming reception, and a
> +digital video port supporting capture and output at VGA resolution. Other
> +peripherals include 8M of SRAM (accessible with and without caching); 
> remappable
> +pins, including 40 GPIOs; AES, FFT, and SHA256 accelerators; a DMA 
> controller;
> +and I2C, I2S, and SPI controllers. Maix peripherals vary, but include spi 
> flash;
> +on-board usb-serial bridges; ports for cameras, displays, and sd cards; and
> +ESP32 chips. Currently, only the Sipeed Maix Bit V2.0 (bitm) is supported, 
> but
> +the boards are fairly similar.
> +
> +Documentation for Maix boards is available from
> +`Sipeed's website `_.
> +Documentation for the Kendryte K210 is available from
> +`Kendryte's website `_. However, hardware
> +details are rather lacking, so most technical reference has been taken from 
> the
> +`standalone sdk `_.
> +
> +Build and boot steps
> +
> +
> +To build u-boot, run
> +
> +.. code-block:: none
> +
> +make sipeed_maix_bitm_defconfig
> +make CROSS_COMPILE=
> +
> +To flash u-boot to a maix bit, run
> +
> +.. code-block:: none
> +
> +kflash -tp /dev/ -B bit_mic u-boot-dtb.bin
> +
> +Boot output should look like the following:
> +
> +.. code-block:: none
> +
> +U-Boot 2020.04-rc2-00087-g2221cc09c1-dirty (Feb 28 2020 - 13:53:09 -0500)
> +
> +DRAM:  8 MiB
> +In:serial@3800
> +Out:   serial@3800
> +Err:   serial@3800
> +=>
> +
> +Loading Images
> +^^
> +
> +To load a kernel, transfer it over serial.
> +
> +.. code-block:: none
> +
> +=> loady 8000 150
> +## Switch baudrate to 150 bps and press ENTER ...
> +
> +*** baud: 150
> +
> +*** baud: 150 ***
> +## Ready for binary (ymodem) download to 0x8000 at 150 bps...
> +C
> +*** file: loader.bin
> +$ sz -vv loader.bin
> +Sending: loader.bin
> +Bytes Sent:2478208   BPS:72937
> +Sending:
> +Ymodem sectors/kbytes sent:   0/ 0k
> +Transfer complete
> +
> +*** exit status: 0 ***
> +## Total Size  = 0x0025d052 = 2478162 Bytes
> +## Switch baudrate to 115200 bps and press ESC ...
> +
> +*** baud: 115200
> +
> +*** baud: 115200 ***
> +=>
> +
> +Running Programs
> +
> +
> +Binaries
> +
> +
> +To run a bare binary, use the ``go`` command:
> +
> +.. code-block:: none
> +
> +=> loady
> +## Ready for binary (ymodem) download to 0x8000 at 115200 bps...
> +C
> +*** file: ./examples/standalone/hello_world.bin
> +$ sz -vv ./examples/standalone/hello_world.bin
> +Sending: hello_world.bin
> +Bytes Sent:   4864   BPS:649
> +Sending:
> +Ymodem sectors/kbytes sent:   0/ 0k
> +Transfer complete
> +
> +*** exit status: 0 ***
> +(CAN) packets, 5 retries
> +## Total Size  = 0x12f8 = 4856 Bytes
> +=> go 8000
> +## Starting applic

RE: [RFC PATCH 3/3] net: tsec: convert fsl_pq_mdio to DM_MDIO

[Madalin Bucur (OSS)]

Hi Vladimir,

a patch for tsec migration to DM_MDIO has already been submitted, part of the 
DPAA 1 PowerPC patch set:

https://patchwork.ozlabs.org/project/uboot/patch/1588251616-14976-3-git-send-email-madalin.bu...@oss.nxp.com/

Madalin

> -Original Message-
> From: U-Boot  On Behalf Of Vladimir Oltean
> Sent: Sunday, May 3, 2020 9:52 PM
> To: u-boot@lists.denx.de; joe.hershber...@ni.com; Priyanka Jain
> 
> Cc: Z.q. Hou ; bmeng...@gmail.com; Claudiu Manoil
> ; Alexandru Marginean
> 
> Subject: [RFC PATCH 3/3] net: tsec: convert fsl_pq_mdio to DM_MDIO
> 
> From: Vladimir Oltean 
> 
> For the platforms on which the eTSEC driver uses DM_ETH, convert its
> MDIO controller code to also use DM_MDIO.
> 
> Note that for handling the TBI PHY (the MAC PCS for SGMII), we still
> don't register a udevice for it, since we can drive it locally and there
> is no point in doing otherwise.
> 
> Signed-off-by: Vladimir Oltean 

Fwd: Re: ZynqMP boot: no messages from SPL other than "Debug uart enabled"

[Major A]

Hi Michal,

The link I sent discusses boards that are externally identical but still 
different, even though they are all labeled Rev1.1.  My understanding is 
that there are differences between boards other than the SODIMM issue 
(from Rev1.0 to Rev1.1).  Don't you have a reasonably new board (I guess 
anything with a 2019 build date should do to test the file that you sent 
me?  I'm pretty sure you only tested it on older boards (still Rev1.1, 
but older).


Cheers,

  András


On 05/05/2020 09:58, Michal Simek wrote:

Hi,

yes there are new sodimms for sure that's why there is separate folder
for this board revision.
You can try to generate psu_init for 1.1 from vivado and then ddr
configuration should be right.
You can also use psu_init and run memory test on the top to see if ddr
is configured properly.

Thanks,
Michal

On 05. 05. 20 9:43, Major A wrote:

Hi Michal,

I appreciate that, thanks for your help.  I mentioned this earlier but
never got a reply: can this have something to do with


https://forums.xilinx.com/t5/ACAP-and-SoC-Boot-and/Booting-ZCU-102-from-SD-Card/td-p/926649


by any chance?

Cheers,

   András


On 05/05/2020 08:14, Michal Simek wrote:

On 04. 05. 20 16:41, Major A wrote:

Dear Michal,

There's no output on the console whatsoever.  I tried booting off SD
directly, and also via JTAG and your script.


I am out of ideas what can be wrong. It is just working on our revision
1.1. I can only recommend you to debug it step by step and see where you
end and what can be wrong.
I can imagine that your zcu102 can have older memory module but it is
unlikely if it is new. Or something else is broken there.

Just keep in your mind that SPL is not supported official recommend boot
flow and it is community driven first stage bootloader.
I can help with brainstorming but you need to debug it self to find out
where the problem is.

Thanks,
Michal

[PATCH] configs: rpi_arm64: sync env size with rpi_{3,4}_defconfig

[Marek Szyprowski]

Use the same environment size as the configs dedicated for rpi3 and rpi4.
This allows to switch between the builds and not to loose the settings
stored on the SD card.

Signed-off-by: Marek Szyprowski 
---
 configs/rpi_arm64_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 926dfc3..7c59400 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_BCM283X=y
 CONFIG_SYS_TEXT_BASE=0x0008
 CONFIG_TARGET_RPI_ARM64=y
 CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_ENV_SIZE=0x4000
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_DISTRO_DEFAULTS=y
 CONFIG_OF_BOARD_SETUP=y
-- 
1.9.1

Pull request for UEFI sub-system for efi-2020-07-rc2 (2)

[Heinrich Schuchardt]

The following changes since commit c693f212c5b0433b3a49a89d87cbff28bf78eb87:

  Merge branch '2020-05-01-master-imports' (2020-05-01 16:43:15 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
tags/efi-2020-07-rc2-2

for you to fetch changes up to 16ad946f41d3dc3e475d8313f4acbba0df527a2a:

  efi_loader: change setup sequence (2020-05-04 12:26:12 +0200)

No problems where reported by Gitlab and Travis:

https://gitlab.denx.de/u-boot/custodians/u-boot-efi/pipelines/3072
https://travis-ci.org/github/xypron2/u-boot/builds/682864922


Pull request for UEFI sub-system for efi-2020-07-rc2-2

This patch contains error corrections and code simplifications for the UEFI
sub-system.


AKASHI Takahiro (5):
  lib/crypto, efi_loader: avoid multiple inclusions of header files
  lib/crypto, efi_loader: move some headers to include/crypto
  efi_loader: fix unreachable statement in efi_sigstore_parse_siglist
  efi_loader: factor out the common code from
efi_transfer_secure_state()
  efi_loader: disk: add efi_disk_is_system_part()

Heinrich Schuchardt (6):
  cmd: efidebug: simplify UEFI protocol calls
  efi_loader: eliminate efi_get_(non)volatile_variable
  efi_loader: eliminate efi_set_(non)volatile_variable
  efi_loader: correct comments for efi_status_t
  test: stabilize test_efi_secboot
  efi_loader: change setup sequence

 cmd/efidebug.c  |  40 ++-
 {lib => include}/crypto/pkcs7_parser.h  |   4 +
 {lib => include}/crypto/x509_parser.h   |   4 +
 include/efi_loader.h|   2 +
 lib/crypto/pkcs7_parser.c   |   4 +
 lib/crypto/x509_cert_parser.c   |   4 +
 lib/crypto/x509_public_key.c|   6 +-
 lib/efi_loader/efi_disk.c   |  29 +++
 lib/efi_loader/efi_image_loader.c   |   2 +-
 lib/efi_loader/efi_setup.c  |  12 +-
 lib/efi_loader/efi_signature.c  |   6 +-
 lib/efi_loader/efi_variable.c   | 325
++--
 test/lib/asn1.c |   4 +-
 test/py/tests/test_efi_secboot/test_authvar.py  |   8 +-
 test/py/tests/test_efi_secboot/test_signed.py   |   4 +-
 test/py/tests/test_efi_secboot/test_unsigned.py |   6 +-
 16 files changed, 174 insertions(+), 286 deletions(-)
 rename {lib => include}/crypto/pkcs7_parser.h (96%)
 rename {lib => include}/crypto/x509_parser.h (96%)

Re: [PATCH 6/8] ARM: imx8m: Fix reset in SPL on NXP iMX8MP EVK

[Marek Vasut]

On 5/5/20 10:54 AM, Harald Seiler wrote:
> Hello Fabio,

Hi

> On Mon, 2020-05-04 at 12:28 -0300, Fabio Estevam wrote:
>> On Mon, May 4, 2020 at 12:21 PM Harald Seiler  wrote:
>>
>>> With or without the revert?
>>
>> When I change the defconfig like:
>>
>> --- a/configs/imx8mp_evk_defconfig
>> +++ b/configs/imx8mp_evk_defconfig
>> @@ -57,7 +57,9 @@ CONFIG_ENV_IS_IN_MMC=y
>>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>>  CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
>>  CONFIG_SPL_DM=y
>> +CONFIG_SPL_CLK_COMPOSITE_CCF=y
>>  CONFIG_CLK_COMPOSITE_CCF=y
>> +CONFIG_SPL_CLK_IMX8MP=y
>>  CONFIG_CLK_IMX8MP=y
>>  CONFIG_MXC_GPIO=y
>>  CONFIG_DM_PCA953X=y
>>
>> It prints a single SPL line with the revert and also without the revert.
> 
> Ok, I guess this means the imx8mp clock driver in SPL is broken and we
> can't easily fix the DM_WATCHDOG issue without it.  I don't really know
> much about imx8 nor do I have any hardware which I could use to debug with
> so I can't help much with this.
> 
> Maybe Peng, who wrote the clock driver, can comment?
> 
> Otherwise, the series which contains this patch also fixed the non-DM
> reset in SPL so we could revert back to that if all else fails ...

Fix the clock driver. Reverting a patch to work around bugs is bad.

Re: [PATCH v2 07/10] linux/bitfield.h: Add primitives for manipulating bitfields both in host- and fixed-endian

[Bin Meng]

On Mon, May 4, 2020 at 8:45 PM Sylwester Nawrocki
 wrote:
>
> From: Nicolas Saenz Julienne 
>
> Imports Al Viro's original Linux commit 00b0c9b82663a, which contains
> an in depth explanation and two fixes from Johannes Berg:
>  e7d4a95da86e0 "bitfield: fix *_encode_bits()",
>  37a3862e12382 "bitfield: add u8 helpers".
>
> Signed-off-by: Nicolas Saenz Julienne 
> [s.nawrocki: added empty lines between functions and macros]
> Signed-off-by: Sylwester Nawrocki 
> ---
> Changes since v1:
>  - added empty lines between functions and macros.
>
> Changes since RFC:
>  - new patch.
> ---
>  include/linux/bitfield.h | 50 
> 
>  1 file changed, 50 insertions(+)
>

Reviewed-by: Bin Meng 

Re: [PATCH v2 10/10] config: Enable support for the XHCI controller on RPI4 board

[Bin Meng]

On Mon, May 4, 2020 at 8:45 PM Sylwester Nawrocki
 wrote:
>
> From: Marek Szyprowski 
>
> This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
> and USB commands. To get it working one has to call the following commands:
> "pci enum; usb start;", thus such commands have been added to the default
> "preboot" environment variable. One has to update their environment if it
> is already configured to get this feature working out of the box.
>
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Sylwester Nawrocki 
> ---
> Changes since v1:
>  - removed unneeded CONFIG_XHCI_64BIT_DWORD_ACCESS_ONLY entry.
>
> Changes since RFC:
>  - none.
> ---
>  configs/rpi_4_32b_defconfig | 9 +
>  configs/rpi_4_defconfig | 9 +
>  configs/rpi_arm64_defconfig | 8 +++-
>  3 files changed, 25 insertions(+), 1 deletion(-)
>

What are these 3 defconfigs files for? Seems there is no MAINTAINERS
mentioning them.

I assume rpi_4_32b_defconfig is for 32-bit U-Boot and rpi_4_defconfig
is for 64-bit U-Boot for RPi 4? What is rpi_arm64_defconfig?

Regards,
Bin

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

[Grant Likely]

On 01/05/2020 10:33, Heinrich Schuchardt wrote:

On 4/30/20 9:13 PM, Sughosh Ganu wrote:


On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

 On 4/30/20 7:36 PM, Sughosh Ganu wrote:
 > Add support for the get_image_info and set_image routines, which are
 > part of the efi firmware management protocol.
 >
 > The current implementation uses the set_image routine for updating the
 > u-boot binary image for the qemu arm64 platform. This is supported
 > using the capsule-on-disk feature of the uefi specification, wherein
 > the firmware image to be updated is placed on the efi system partition
 > as a efi capsule under EFI/UpdateCapsule/ directory. Support has been
 > added for updating the u-boot image on platforms booting with arm
 > trusted firmware(tf-a), where the u-boot image gets booted as the BL33
 > payload(bl33.bin).
 >
 > The feature can be enabled by the following config options
 >
 > CONFIG_EFI_CAPSULE_ON_DISK=y
 > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

 U-Boot's UEFI subsystem should work in the same way for x86, ARM, and
 RISC-V. Please, come up with an architecture independent solution.


Please check the explanation that I gave in the other mail. If you check
the patch series, the actual capsule authentication logic has been kept
architecture agnostic, in efi_capsule.c. The fmp protocol is very much
intended for allowing platforms to define their firmware update
routines. Edk2 also has platform specific implementation of the fmp
protocol under the edk2-platforms directory.

-sughosh




My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
   for each of the binaries

The protocol implementation then will write the binaries to the device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
   for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
   (and truncate it if the truncation flag is set)


Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it did.

In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device & file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case. Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.


If for some devices like a SPI flash we do not have a media device path
yet, then the only platform specific bit would be the block device
driver exposing the media device path.

Same with a semi-hosted file: just add a driver exposing it as a media
path with an EFI_BLOCK_IO_PROTOCOL.


Sughosh and I chatted about this and took a look a the semihosting
driver. Right now it is a standalone component implementing only the
smhload command. It looks like it easily maps onto fstype_info
operations which would be a better fit than the block IO protocol. Am I
correct in assuming that would also make semihosting available to the
EFI_FILE_PROTOCOL? The FMP backend code could be common for all
filesystem targets, with the only platform specific bit being the path
to the firmware files.

How does that sound?

g.


For security reasons it may be advisable to make the device read-only
when reaching ExitBootServices() or even better before the first
execution of StartImage(). For this purpose we could use the Reset()
service of the EFI_BLOCK_IO_PROTOCOL or provide a U-Boot specific
service in the EFI_BLOCK_IO_PROTOCOL.

Best regards

Heinrich


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

Re: [PATCH v2 10/10] config: Enable support for the XHCI controller on RPI4 board

[Nicolas Saenz Julienne]

[ Adding Matthias as he's the board maintainer ]

On Tue, 2020-05-05 at 19:15 +0800, Bin Meng wrote:
> On Mon, May 4, 2020 at 8:45 PM Sylwester Nawrocki
>  wrote:
> > From: Marek Szyprowski 
> > 
> > This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
> > and USB commands. To get it working one has to call the following commands:
> > "pci enum; usb start;", thus such commands have been added to the default
> > "preboot" environment variable. One has to update their environment if it
> > is already configured to get this feature working out of the box.
> > 
> > Signed-off-by: Marek Szyprowski 
> > Signed-off-by: Sylwester Nawrocki 
> > ---
> > Changes since v1:
> >  - removed unneeded CONFIG_XHCI_64BIT_DWORD_ACCESS_ONLY entry.
> > 
> > Changes since RFC:
> >  - none.
> > ---
> >  configs/rpi_4_32b_defconfig | 9 +
> >  configs/rpi_4_defconfig | 9 +
> >  configs/rpi_arm64_defconfig | 8 +++-
> >  3 files changed, 25 insertions(+), 1 deletion(-)
> > 
> 
> What are these 3 defconfigs files for? Seems there is no MAINTAINERS
> mentioning them.
> 
> I assume rpi_4_32b_defconfig is for 32-bit U-Boot and rpi_4_defconfig
> is for 64-bit U-Boot for RPi 4? What is rpi_arm64_defconfig?

I think rpi_arm64_defconfig is for both rpi3 & rpi4.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 10/10] config: Enable support for the XHCI controller on RPI4 board

[Marek Szyprowski]

Hi

On 05.05.2020 13:15, Bin Meng wrote:
> On Mon, May 4, 2020 at 8:45 PM Sylwester Nawrocki
>  wrote:
>> From: Marek Szyprowski 
>>
>> This requires enabling BRCMSTB PCIe and XHCI_PCI drivers as well as PCI
>> and USB commands. To get it working one has to call the following commands:
>> "pci enum; usb start;", thus such commands have been added to the default
>> "preboot" environment variable. One has to update their environment if it
>> is already configured to get this feature working out of the box.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Sylwester Nawrocki 
>> ---
>> Changes since v1:
>>   - removed unneeded CONFIG_XHCI_64BIT_DWORD_ACCESS_ONLY entry.
>>
>> Changes since RFC:
>>   - none.
>> ---
>>   configs/rpi_4_32b_defconfig | 9 +
>>   configs/rpi_4_defconfig | 9 +
>>   configs/rpi_arm64_defconfig | 8 +++-
>>   3 files changed, 25 insertions(+), 1 deletion(-)
>>
> What are these 3 defconfigs files for? Seems there is no MAINTAINERS
> mentioning them.
>
> I assume rpi_4_32b_defconfig is for 32-bit U-Boot and rpi_4_defconfig
> is for 64-bit U-Boot for RPi 4? What is rpi_arm64_defconfig?

rpi_arm64_defconfig is for common image, which works on both RPi 3 and 
RPi 4.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH 01/13] net: fsl_pq_mdio: Add the compatible "fsl, gianfar-mdio" support

[Zhiqiang Hou]

From: Hou Zhiqiang 

Add compatible string "fsl,gianfar-mdio" support and update the
device-tree-bindings doc.

Signed-off-by: Hou Zhiqiang 
---
 doc/device-tree-bindings/net/fsl-tsec-phy.txt |  3 ++-
 drivers/net/fsl_mdio.c| 15 +--
 include/fsl_mdio.h|  4 
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt 
b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
index 8e8574bc97..a709b89a5c 100644
--- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
+++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
@@ -28,7 +28,8 @@ device that exists on this bus, a PHY node should be created.
 
 Required properties:
   - compatible : Should define the compatible device type for the
-mdio. Currently supported string/device is "fsl,etsec2-mdio".
+mdio. Currently supported string/device is "fsl,etsec2-mdio" and
+"fsl,gianfar-mdio".
   - reg : Offset and length of the register set for the device
 
 Example:
diff --git a/drivers/net/fsl_mdio.c b/drivers/net/fsl_mdio.c
index 284508062c..ea9c37ad19 100644
--- a/drivers/net/fsl_mdio.c
+++ b/drivers/net/fsl_mdio.c
@@ -138,10 +138,12 @@ static int dm_fsl_pq_mdio_write(struct udevice *dev, int 
addr, int devad,
 static int fsl_pq_mdio_probe(struct udevice *dev)
 {
struct fsl_pq_mdio_info *info = dev_get_priv(dev);
+   struct fsl_pq_mdio_data *data;
fdt_addr_t reg;
 
+   data = (struct fsl_pq_mdio_data *)dev_get_driver_data(dev);
reg = devfdt_get_addr(dev);
-   info->regs = map_physmem(reg + TSEC_MDIO_REGS_OFFSET, 0, MAP_NOCACHE);
+   info->regs = map_physmem(reg + data->mdio_regs_off, 0, MAP_NOCACHE);
 
return fsl_pq_mdio_reset(info->regs);
 }
@@ -151,8 +153,17 @@ static const struct mdio_ops fsl_pq_mdio_ops = {
.write  = dm_fsl_pq_mdio_write,
 };
 
+static struct fsl_pq_mdio_data etsec2_data = {
+   .mdio_regs_off = TSEC_MDIO_REGS_OFFSET,
+};
+
+static struct fsl_pq_mdio_data gianfar_data = {
+   .mdio_regs_off = 0x0,
+};
+
 static const struct udevice_id fsl_pq_mdio_ids[] = {
-   { .compatible = "fsl,etsec2-mdio" },
+   { .compatible = "fsl,etsec2-mdio", .data = (ulong)&etsec2_data },
+   { .compatible = "fsl,gianfar-mdio", .data = (ulong)&gianfar_data },
{ }
 };
 
diff --git a/include/fsl_mdio.h b/include/fsl_mdio.h
index 386c477a8b..80e3100cda 100644
--- a/include/fsl_mdio.h
+++ b/include/fsl_mdio.h
@@ -53,6 +53,10 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int 
dev_addr,
int regnum);
 int memac_mdio_reset(struct mii_dev *bus);
 
+struct fsl_pq_mdio_data {
+   u32 mdio_regs_off;
+};
+
 struct fsl_pq_mdio_info {
struct tsec_mii_mng __iomem *regs;
char *name;
-- 
2.17.1

[PATCH 02/13] net: tsec: Add the compatible string "gianfar" support

[Zhiqiang Hou]

From: Hou Zhiqiang 

Add compatible string "gianfar" support and update the
device-tree-bindings doc.

Signed-off-by: Hou Zhiqiang 
---
 doc/device-tree-bindings/net/fsl-tsec-phy.txt |  2 +-
 drivers/net/tsec.c| 16 ++--
 include/tsec.h|  4 
 3 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/doc/device-tree-bindings/net/fsl-tsec-phy.txt 
b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
index a709b89a5c..fae6770cbe 100644
--- a/doc/device-tree-bindings/net/fsl-tsec-phy.txt
+++ b/doc/device-tree-bindings/net/fsl-tsec-phy.txt
@@ -2,7 +2,7 @@
 
 Properties:
 
-  - compatible : Should be "fsl,etsec2"
+  - compatible : Should be "fsl,etsec2" or "gianfar"
   - reg : Offset and length of the register set for the device
   - phy-handle : See ethernet.txt file in the same directory.
   - phy-connection-type : See ethernet.txt file in the same directory. This
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 93f151a8a6..f7c70bb08d 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -804,11 +804,14 @@ int tsec_probe(struct udevice *dev)
struct tsec_private *priv = dev_get_priv(dev);
struct ofnode_phandle_args phandle_args;
u32 tbiaddr = CONFIG_SYS_TBIPA_VALUE;
+   struct tsec_data *data;
const char *phy_mode;
fdt_addr_t reg;
ofnode parent;
int ret;
 
+   data = (struct tsec_data *)dev_get_driver_data(dev);
+
pdata->iobase = (phys_addr_t)dev_read_addr(dev);
priv->regs = dev_remap_addr(dev);
 
@@ -829,7 +832,7 @@ int tsec_probe(struct udevice *dev)
return -ENOENT;
}
 
-   priv->phyregs_sgmii = map_physmem(reg + TSEC_MDIO_REGS_OFFSET,
+   priv->phyregs_sgmii = map_physmem(reg + data->mdio_regs_off,
  0, MAP_NOCACHE);
}
 
@@ -883,8 +886,17 @@ static const struct eth_ops tsec_ops = {
.mcast = tsec_mcast_addr,
 };
 
+static struct tsec_data etsec2_data = {
+   .mdio_regs_off = TSEC_MDIO_REGS_OFFSET,
+};
+
+static struct tsec_data gianfar_data = {
+   .mdio_regs_off = 0x0,
+};
+
 static const struct udevice_id tsec_ids[] = {
-   { .compatible = "fsl,etsec2" },
+   { .compatible = "fsl,etsec2", .data = (ulong)&etsec2_data },
+   { .compatible = "gianfar", .data = (ulong)&gianfar_data },
{ }
 };
 
diff --git a/include/tsec.h b/include/tsec.h
index b17fa957df..047dd3c373 100644
--- a/include/tsec.h
+++ b/include/tsec.h
@@ -394,6 +394,10 @@ struct tsec {
 
 #define TX_BUF_CNT 2
 
+struct tsec_data {
+   u32 mdio_regs_off;
+};
+
 struct tsec_private {
struct txbd8 __iomem txbd[TX_BUF_CNT];
struct rxbd8 __iomem rxbd[PKTBUFSRX];
-- 
2.17.1

[PATCH 04/13] fsl: p1_p2_rdb: Move vsc7835 firmware uploading to board_early_init_r()

[Zhiqiang Hou]

From: Hou Zhiqiang 

Move vsc7835 firmware uploading to board_early_init_r(), so that
the switch also can work in DM eTSEC driver.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 35 +++--
 1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 71fca8ca1e..890abd76b5 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -291,6 +291,10 @@ int board_early_init_r(void)
 {
const unsigned int flashbase = CONFIG_SYS_FLASH_BASE;
int flash_esel = find_tlb_idx((void *)flashbase, 1);
+#ifdef CONFIG_VSC7385_ENET
+   unsigned int vscfw_addr;
+   char *tmp;
+#endif
 
/*
 * Remap Boot flash region to caching-inhibited
@@ -313,6 +317,20 @@ int board_early_init_r(void)
set_tlb(1, flashbase, CONFIG_SYS_FLASH_BASE_PHYS, /* tlb, epn, rpn */
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,/* perms, wimge */
0, flash_esel, BOOKE_PAGESZ_64M, 1);/* ts, esel, tsize, iprot */
+
+#ifdef CONFIG_VSC7385_ENET
+   /* If a VSC7385 microcode image is present, then upload it. */
+   tmp = env_get("vscfw_addr");
+   if (tmp) {
+   vscfw_addr = simple_strtoul(tmp, NULL, 16);
+   printf("uploading VSC7385 microcode from %x\n", vscfw_addr);
+   if (vsc7385_upload_firmware((void *)vscfw_addr,
+   CONFIG_VSC7385_IMAGE_SIZE))
+   puts("Failure uploading VSC7385 microcode.\n");
+   } else {
+   puts("No address specified for VSC7385 microcode.\n");
+   }
+#endif
return 0;
 }
 
@@ -323,10 +341,6 @@ int board_eth_init(bd_t *bis)
ccsr_gur_t *gur __attribute__((unused)) =
(void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
int num = 0;
-#ifdef CONFIG_VSC7385_ENET
-   char *tmp;
-   unsigned int vscfw_addr;
-#endif
 
 #ifdef CONFIG_TSEC1
SET_STD_TSEC_INFO(tsec_info[num], 1);
@@ -350,19 +364,6 @@ int board_eth_init(bd_t *bis)
return 0;
}
 
-#ifdef CONFIG_VSC7385_ENET
-   /* If a VSC7385 microcode image is present, then upload it. */
-   tmp = env_get("vscfw_addr");
-   if (tmp) {
-   vscfw_addr = simple_strtoul(tmp, NULL, 16);
-   printf("uploading VSC7385 microcode from %x\n", vscfw_addr);
-   if (vsc7385_upload_firmware((void *) vscfw_addr,
-   CONFIG_VSC7385_IMAGE_SIZE))
-   puts("Failure uploading VSC7385 microcode.\n");
-   } else
-   puts("No address specified for VSC7385 microcode.\n");
-#endif
-
mdio_info.regs = TSEC_GET_MDIO_REGS_BASE(1);
mdio_info.name = DEFAULT_MII_NAME;
 
-- 
2.17.1

[PATCH 00/13] powerpc: covert p1010, p1020 and p2020 RDB board

[Zhiqiang Hou]

From: Hou Zhiqiang 

This patch set depends on:
https://patchwork.ozlabs.org/project/uboot/list/?series=174343

Hou Zhiqiang (13):
  net: fsl_pq_mdio: Add the compatible "fsl,gianfar-mdio" support
  net: tsec: Add the compatible string "gianfar" support
  powerpc: mpc8xxx: Don't compile cpu_eth_init() when DM_ETH enabled
  fsl: p1_p2_rdb: Move vsc7835 firmware uploading to
board_early_init_r()
  configs: p1_p2_rdb: Add the default address of vsc7385 firmware
  dts: powerpc: p1020rdb: Add eTSEC DT nodes
  powerpc: p1_p2_rdb: Don't compile board_eth_init() when DM_ETH enabled
  configs: P1020RDB: Enable DM_ETH config
  dts: powerpc: p1010rdb: Add eTSEC DT nodes
  powerpc: p1010rdb: Compile legacy ethernet init function when no
DM_ETH
  configs: P1010RDB: Enable DM_ETH config
  dts: powerpc: p2020rdb: Add eTSEC DT nodes
  configs: P2020RDB: Enable DM_ETH config

 arch/powerpc/cpu/mpc8xxx/cpu.c|  2 +
 arch/powerpc/dts/p1010rdb-pa.dts  |  1 +
 arch/powerpc/dts/p1010rdb-pa_36b.dts  |  1 +
 arch/powerpc/dts/p1010rdb-pb.dts  |  1 +
 arch/powerpc/dts/p1010rdb-pb_36b.dts  |  1 +
 arch/powerpc/dts/p1010rdb.dtsi| 71 +++
 arch/powerpc/dts/p1010si-post.dtsi| 25 +++
 arch/powerpc/dts/p1020-post.dtsi  | 15 
 arch/powerpc/dts/p1020rdb-pc.dts  |  1 +
 arch/powerpc/dts/p1020rdb-pc.dtsi | 55 ++
 arch/powerpc/dts/p1020rdb-pc_36b.dts  |  1 +
 arch/powerpc/dts/p1020rdb-pd.dts  | 57 +++
 arch/powerpc/dts/p2020-post.dtsi  | 10 +++
 arch/powerpc/dts/p2020rdb-pc.dts  |  1 +
 arch/powerpc/dts/p2020rdb-pc.dtsi | 59 +++
 arch/powerpc/dts/p2020rdb-pc_36b.dts  |  1 +
 arch/powerpc/dts/pq3-etsec1-0.dtsi| 28 
 arch/powerpc/dts/pq3-etsec1-1.dtsi| 28 
 arch/powerpc/dts/pq3-etsec1-2.dtsi| 28 
 arch/powerpc/dts/pq3-etsec1-3.dtsi| 28 
 arch/powerpc/dts/pq3-etsec1-timer-0.dtsi  | 13 
 arch/powerpc/dts/pq3-etsec2-0.dtsi| 35 +
 arch/powerpc/dts/pq3-etsec2-1.dtsi| 35 +
 arch/powerpc/dts/pq3-etsec2-2.dtsi| 35 +
 arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi   | 16 +
 arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi   | 16 +
 arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi   | 16 +
 board/freescale/p1010rdb/p1010rdb.c   |  2 +
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c   | 37 +-
 configs/P1010RDB-PA_36BIT_NAND_defconfig  |  2 +
 configs/P1010RDB-PA_36BIT_NOR_defconfig   |  2 +
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig|  2 +
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig  |  2 +
 configs/P1010RDB-PA_NAND_defconfig|  2 +
 configs/P1010RDB-PA_NOR_defconfig |  2 +
 configs/P1010RDB-PA_SDCARD_defconfig  |  2 +
 configs/P1010RDB-PA_SPIFLASH_defconfig|  2 +
 configs/P1010RDB-PB_36BIT_NAND_defconfig  |  2 +
 configs/P1010RDB-PB_36BIT_NOR_defconfig   |  2 +
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig|  2 +
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig  |  2 +
 configs/P1010RDB-PB_NAND_defconfig|  2 +
 configs/P1010RDB-PB_NOR_defconfig |  2 +
 configs/P1010RDB-PB_SDCARD_defconfig  |  2 +
 configs/P1010RDB-PB_SPIFLASH_defconfig|  2 +
 configs/P1020RDB-PC_36BIT_NAND_defconfig  |  3 +
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig|  3 +
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig  |  3 +
 configs/P1020RDB-PC_36BIT_defconfig   |  3 +
 configs/P1020RDB-PC_NAND_defconfig|  3 +
 configs/P1020RDB-PC_SDCARD_defconfig  |  3 +
 configs/P1020RDB-PC_SPIFLASH_defconfig|  3 +
 configs/P1020RDB-PC_defconfig |  3 +
 configs/P1020RDB-PD_NAND_defconfig|  3 +
 configs/P1020RDB-PD_SDCARD_defconfig  |  3 +
 configs/P1020RDB-PD_SPIFLASH_defconfig|  3 +
 configs/P1020RDB-PD_defconfig |  3 +
 configs/P2020RDB-PC_36BIT_NAND_defconfig  |  3 +
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig|  3 +
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig  |  3 +
 configs/P2020RDB-PC_36BIT_defconfig   |  3 +
 configs/P2020RDB-PC_NAND_defconfig|  3 +
 configs/P2020RDB-PC_SDCARD_defconfig  |  3 +
 configs/P2020RDB-PC_SPIFLASH_defconfig|  3 +
 configs/P2020RDB-PC_defconfig |  3 +
 doc/device-tree-bindings/net/fsl-tsec-phy.txt |  5 +-
 drivers/net/fsl_mdio.c| 15 +++-
 drivers/net/tsec.c| 16 -
 include/configs/p1_p2_rdb_pc.h|  2 +
 include/fsl_mdio.h|  4 ++
 include/tsec.h|  4 ++
 71 files changed, 734 insertions(+), 23 deletions(-)
 create mode 100644 arch/powerpc/dts/p1010rdb.dtsi
 create mode 100644 arch

[PATCH 08/13] configs: P1020RDB: Enable DM_ETH config

[Zhiqiang Hou]

From: Hou Zhiqiang 

Enable the DM_ETH and DM_MDIO config.

On P1020RDB, the eTSEC1 is connecting with a switch VSC7385,
so also enable the fixed PHY support.

Signed-off-by: Hou Zhiqiang 
---
 configs/P1020RDB-PC_36BIT_NAND_defconfig | 3 +++
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   | 3 +++
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 3 +++
 configs/P1020RDB-PC_36BIT_defconfig  | 3 +++
 configs/P1020RDB-PC_NAND_defconfig   | 3 +++
 configs/P1020RDB-PC_SDCARD_defconfig | 3 +++
 configs/P1020RDB-PC_SPIFLASH_defconfig   | 3 +++
 configs/P1020RDB-PC_defconfig| 3 +++
 configs/P1020RDB-PD_NAND_defconfig   | 3 +++
 configs/P1020RDB-PD_SDCARD_defconfig | 3 +++
 configs/P1020RDB-PD_SPIFLASH_defconfig   | 3 +++
 configs/P1020RDB-PD_defconfig| 3 +++
 12 files changed, 36 insertions(+)

diff --git a/configs/P1020RDB-PC_36BIT_NAND_defconfig 
b/configs/P1020RDB-PC_36BIT_NAND_defconfig
index 2396d91011..847dad4072 100644
--- a/configs/P1020RDB-PC_36BIT_NAND_defconfig
+++ b/configs/P1020RDB-PC_36BIT_NAND_defconfig
@@ -61,6 +61,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -72,8 +73,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig 
b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
index 745200da51..a3f8761c9b 100644
--- a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
+++ b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
@@ -56,6 +56,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -67,8 +68,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig 
b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
index 3eadd3d83c..da3e2b3563 100644
--- a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
+++ b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
@@ -58,6 +58,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -69,8 +70,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P1020RDB-PC_36BIT_defconfig 
b/configs/P1020RDB-PC_36BIT_defconfig
index 9b7901f5c3..5c6281ef11 100644
--- a/configs/P1020RDB-PC_36BIT_defconfig
+++ b/configs/P1020RDB-PC_36BIT_defconfig
@@ -45,6 +45,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -56,8 +57,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P1020RDB-PC_NAND_defconfig 
b/configs/P1020RDB-PC_NAND_defconfig
index e99709a2b8..78948e4a06 100644
--- a/configs/P1020RDB-PC_NAND_defconfig
+++ b/configs/P1020RDB-PC_NAND_defconfig
@@ -60,6 +60,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -71,8 +72,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P1020RDB-PC_SDCARD_defconfig 
b/configs/P1020RDB-PC_SDCARD_defconfig
index ef007e5fe4..0518083cd9 100644
--- a/configs/P1020RDB-PC_SDCARD_defconfig
+++ b/configs/P1020RDB-PC_SDCARD_defconfig
@@ -55,6 +55,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -66,8 +67,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P1020RDB-PC_SPIFLASH_defconfig 
b/configs/P1020RDB-PC_SPIFLASH_defconfig
index c8b0923cb5..284ef2c55a 100644
--- a/configs/P1020RDB-PC_SPIFLASH_defconfi

[PATCH 03/13] powerpc: mpc8xxx: Don't compile cpu_eth_init() when DM_ETH enabled

[Zhiqiang Hou]

From: Hou Zhiqiang 

The cpu_eth_init() is only used by the legacy ethernet driver framework.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/cpu/mpc8xxx/cpu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/cpu/mpc8xxx/cpu.c b/arch/powerpc/cpu/mpc8xxx/cpu.c
index ed482a9c09..d41d6a6110 100644
--- a/arch/powerpc/cpu/mpc8xxx/cpu.c
+++ b/arch/powerpc/cpu/mpc8xxx/cpu.c
@@ -345,6 +345,7 @@ int fixup_cpu(void)
  * Initializes on-chip ethernet controllers.
  * to override, implement board_eth_init()
  */
+#ifndef CONFIG_DM_ETH
 int cpu_eth_init(bd_t *bis)
 {
 #if defined(CONFIG_ETHER_ON_FCC)
@@ -368,3 +369,4 @@ int cpu_eth_init(bd_t *bis)
 #endif
return 0;
 }
+#endif
-- 
2.17.1

[PATCH 05/13] configs: p1_p2_rdb: Add the default address of vsc7385 firmware

[Zhiqiang Hou]

From: Hou Zhiqiang 

Add the environment 'vscfw_addr' to assign a default address for
vsc7385 firmware uploading.

Signed-off-by: Hou Zhiqiang 
---
 include/configs/p1_p2_rdb_pc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h
index c42f1a9fce..b2fdf47104 100644
--- a/include/configs/p1_p2_rdb_pc.h
+++ b/include/configs/p1_p2_rdb_pc.h
@@ -460,6 +460,7 @@
 
 /* Vsc7385 switch */
 #ifdef CONFIG_VSC7385_ENET
+#define __VSCFW_ADDR   "vscfw_addr=ef00"
 #define CONFIG_SYS_VSC7385_BASE0xffb0
 
 #ifdef CONFIG_PHYS_64BIT
@@ -813,6 +814,7 @@ i2c mw 18 3 __SW_BOOT_MASK 1; reset
 "ramdisk_size=12\0"\
 "map_lowernorbank=i2c dev 1; i2c mw 18 1 02 1; i2c mw 18 3 fd 1\0" \
 "map_uppernorbank=i2c dev 1; i2c mw 18 1 00 1; i2c mw 18 3 fd 1\0" \
+__stringify(__VSCFW_ADDR)"\0" \
 __stringify(__NOR_RST_CMD)"\0" \
 __stringify(__SPI_RST_CMD)"\0" \
 __stringify(__SD_RST_CMD)"\0" \
-- 
2.17.1

[PATCH 07/13] powerpc: p1_p2_rdb: Don't compile board_eth_init() when DM_ETH enabled

[Zhiqiang Hou]

From: Hou Zhiqiang 

The board_eth_init() is only used by legacy ethernet driver framework,
so do not compile it when DM_ETH config has been selected.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 890abd76b5..5349df5910 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -334,6 +334,7 @@ int board_early_init_r(void)
return 0;
 }
 
+#ifndef CONFIG_DM_ETH
 int board_eth_init(bd_t *bis)
 {
struct fsl_pq_mdio_info mdio_info;
@@ -381,6 +382,7 @@ int board_eth_init(bd_t *bis)
 
return pci_eth_init(bis);
 }
+#endif
 
 #if defined(CONFIG_QE) && \
(defined(CONFIG_TARGET_P1025RDB) || defined(CONFIG_TARGET_P1021RDB))
-- 
2.17.1

[PATCH 06/13] dts: powerpc: p1020rdb: Add eTSEC DT nodes

[Zhiqiang Hou]

From: Hou Zhiqiang 

P1020RDB implements 3 enhanced three-speed Ethernet controllers,
and the connection is shown below:
eTSEC1: Connected to RGMII PHY VSC7385
eTSEC2: Connected to SGMII PHY VSC8221
eTSEC3: Connected to SGMII PHY AR8021

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/p1020-post.dtsi| 15 +++
 arch/powerpc/dts/p1020rdb-pc.dts|  1 +
 arch/powerpc/dts/p1020rdb-pc.dtsi   | 55 
 arch/powerpc/dts/p1020rdb-pc_36b.dts|  1 +
 arch/powerpc/dts/p1020rdb-pd.dts| 57 +
 arch/powerpc/dts/pq3-etsec2-0.dtsi  | 35 +++
 arch/powerpc/dts/pq3-etsec2-1.dtsi  | 35 +++
 arch/powerpc/dts/pq3-etsec2-2.dtsi  | 35 +++
 arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi | 16 +++
 arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi | 16 +++
 arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi | 16 +++
 11 files changed, 282 insertions(+)
 create mode 100644 arch/powerpc/dts/p1020rdb-pc.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec2-0.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec2-1.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec2-2.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-0.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-1.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec2-grp2-2.dtsi

diff --git a/arch/powerpc/dts/p1020-post.dtsi b/arch/powerpc/dts/p1020-post.dtsi
index 1c77702f01..d7b10a9ae9 100644
--- a/arch/powerpc/dts/p1020-post.dtsi
+++ b/arch/powerpc/dts/p1020-post.dtsi
@@ -44,8 +44,23 @@
clock-frequency = <0>;
};
 
+/include/ "pq3-etsec2-0.dtsi"
+   enet0: enet0_grp2: ethernet@b {
+   };
+
+/include/ "pq3-etsec2-1.dtsi"
+   enet1: enet1_grp2: ethernet@b1000 {
+   };
+
+/include/ "pq3-etsec2-2.dtsi"
+   enet2: enet2_grp2: ethernet@b2000 {
+   };
 };
 
+/include/ "pq3-etsec2-grp2-0.dtsi"
+/include/ "pq3-etsec2-grp2-1.dtsi"
+/include/ "pq3-etsec2-grp2-2.dtsi"
+
 /* PCIe controller base address 0x9000 */
 &pci1 {
compatible = "fsl,pcie-p1_p2", "fsl,pcie-fsl-qoriq";
diff --git a/arch/powerpc/dts/p1020rdb-pc.dts b/arch/powerpc/dts/p1020rdb-pc.dts
index 7ebaa619df..715330dc50 100644
--- a/arch/powerpc/dts/p1020rdb-pc.dts
+++ b/arch/powerpc/dts/p1020rdb-pc.dts
@@ -32,4 +32,5 @@
};
 };
 
+/include/ "p1020rdb-pc.dtsi"
 /include/ "p1020-post.dtsi"
diff --git a/arch/powerpc/dts/p1020rdb-pc.dtsi 
b/arch/powerpc/dts/p1020rdb-pc.dtsi
new file mode 100644
index 00..6bf424fd3f
--- /dev/null
+++ b/arch/powerpc/dts/p1020rdb-pc.dtsi
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P1020 RDB-PC Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ * Copyright 2020 NXP
+ */
+
+&soc {
+   mdio@24000 {
+   phy0: ethernet-phy@0 {
+   interrupt-parent = <&mpic>;
+   interrupts = <3 1 0 0>;
+   reg = <0x0>;
+   };
+
+   phy1: ethernet-phy@1 {
+   interrupt-parent = <&mpic>;
+   interrupts = <2 1 0 0>;
+   reg = <0x1>;
+   };
+
+   tbi0: tbi-phy@11 {
+   device_type = "tbi-phy";
+   reg = <0x11>;
+   };
+   };
+
+   mdio@25000 {
+   tbi1: tbi-phy@11 {
+   reg = <0x11>;
+   device_type = "tbi-phy";
+   };
+   };
+
+   enet0: ethernet@b {
+   phy-connection-type = "rgmii-id";
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+
+   };
+
+   enet1: ethernet@b1000 {
+   phy-handle = <&phy0>;
+   tbi-handle = <&tbi1>;
+   phy-connection-type = "sgmii";
+   };
+
+   enet2: ethernet@b2000 {
+   phy-handle = <&phy1>;
+   phy-connection-type = "rgmii-id";
+   };
+};
diff --git a/arch/powerpc/dts/p1020rdb-pc_36b.dts 
b/arch/powerpc/dts/p1020rdb-pc_36b.dts
index c0e5ef4cf4..7680b7c7e1 100644
--- a/arch/powerpc/dts/p1020rdb-pc_36b.dts
+++ b/arch/powerpc/dts/p1020rdb-pc_36b.dts
@@ -32,4 +32,5 @@
};
 };
 
+/include/ "p1020rdb-pc.dtsi"
 /include/ "p1020-post.dtsi"
diff --git a/arch/powerpc/dts/p1020rdb-pd.dts b/arch/powerpc/dts/p1020rdb-pd.dts
index 21174a09be..7868c9b95c 100644
--- a/arch/powerpc/dts/p1020rdb-pd.dts
+++ b/arch/powerpc/dts/p1020rdb-pd.dts
@@ -17,6 +17,63 @@
 
soc: soc@ffe0 {
ranges = <0x0 0x0 0xffe0 0x10>;
+
+   mdio@24000 {
+   phy0: ethernet-phy@0 {
+   interrupts = <3 1 0 0>;
+   reg = <0x0>;
+   };
+
+   phy1: ethernet-phy@1 {
+   interrupts

[PATCH 12/13] dts: powerpc: p2020rdb: Add eTSEC DT nodes

[Zhiqiang Hou]

From: Hou Zhiqiang 

P2020RDB implements 3 enhanced three-speed Ethernet controllers,
and the connection is shown below:
eTSEC1: Connected to RGMII PHY VSC7385
eTSEC2: Connected to SGMII PHY VSC8221
eTSEC3: Connected to SGMII PHY AR8021

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/p2020-post.dtsi | 10 
 arch/powerpc/dts/p2020rdb-pc.dts |  1 +
 arch/powerpc/dts/p2020rdb-pc.dtsi| 59 
 arch/powerpc/dts/p2020rdb-pc_36b.dts |  1 +
 arch/powerpc/dts/pq3-etsec1-0.dtsi   | 28 +++
 arch/powerpc/dts/pq3-etsec1-1.dtsi   | 28 +++
 arch/powerpc/dts/pq3-etsec1-2.dtsi   | 28 +++
 arch/powerpc/dts/pq3-etsec1-3.dtsi   | 28 +++
 arch/powerpc/dts/pq3-etsec1-timer-0.dtsi | 13 ++
 9 files changed, 196 insertions(+)
 create mode 100644 arch/powerpc/dts/p2020rdb-pc.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec1-0.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec1-1.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec1-2.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec1-3.dtsi
 create mode 100644 arch/powerpc/dts/pq3-etsec1-timer-0.dtsi

diff --git a/arch/powerpc/dts/p2020-post.dtsi b/arch/powerpc/dts/p2020-post.dtsi
index 5bbd5c5468..5cdc1655d9 100644
--- a/arch/powerpc/dts/p2020-post.dtsi
+++ b/arch/powerpc/dts/p2020-post.dtsi
@@ -37,6 +37,16 @@
/* Filled in by U-Boot */
clock-frequency = <0>;
};
+
+/include/ "pq3-etsec1-0.dtsi"
+/include/ "pq3-etsec1-timer-0.dtsi"
+
+   ptp_clock@24e00 {
+   interrupts = <68 2 0 0 69 2 0 0 70 2 0 0>;
+   };
+
+/include/ "pq3-etsec1-1.dtsi"
+/include/ "pq3-etsec1-2.dtsi"
 };
 
 /* PCIe controller base address 0x8000 */
diff --git a/arch/powerpc/dts/p2020rdb-pc.dts b/arch/powerpc/dts/p2020rdb-pc.dts
index 08befd4c59..f3f6be1080 100644
--- a/arch/powerpc/dts/p2020rdb-pc.dts
+++ b/arch/powerpc/dts/p2020rdb-pc.dts
@@ -37,4 +37,5 @@
};
 };
 
+/include/ "p2020rdb-pc.dtsi"
 /include/ "p2020-post.dtsi"
diff --git a/arch/powerpc/dts/p2020rdb-pc.dtsi 
b/arch/powerpc/dts/p2020rdb-pc.dtsi
new file mode 100644
index 00..9abd700999
--- /dev/null
+++ b/arch/powerpc/dts/p2020rdb-pc.dtsi
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P2020 RDB-PC Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2020 NXP
+ */
+
+&soc {
+   mdio@24520 {
+   phy0: ethernet-phy@0 {
+   interrupts = <3 1 0 0>;
+   reg = <0x0>;
+   };
+   phy1: ethernet-phy@1 {
+   interrupts = <2 1 0 0>;
+   reg = <0x1>;
+   };
+   };
+
+   mdio@25520 {
+   tbi0: tbi-phy@11 {
+   reg = <0x11>;
+   device_type = "tbi-phy";
+   };
+   };
+
+   mdio@26520 {
+   status = "disabled";
+   };
+
+   ptp_clock@24e00 {
+   fsl,tclk-period = <5>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add = <0xaaab>;
+   fsl,tmr-fiper1  = <5>;
+   fsl,tmr-fiper2  = <0>;
+   fsl,max-adj = <2>;
+   };
+
+   enet0: ethernet@24000 {
+   phy-connection-type = "rgmii-id";
+   fixed-link {
+   speed = <1000>;
+   full-duplex;
+   };
+   };
+
+   enet1: ethernet@25000 {
+   tbi-handle = <&tbi0>;
+   phy-handle = <&phy0>;
+   phy-connection-type = "sgmii";
+   };
+
+   enet2: ethernet@26000 {
+   phy-handle = <&phy1>;
+   phy-connection-type = "rgmii-id";
+   };
+};
diff --git a/arch/powerpc/dts/p2020rdb-pc_36b.dts 
b/arch/powerpc/dts/p2020rdb-pc_36b.dts
index 04b2519e1a..6d983b7d71 100644
--- a/arch/powerpc/dts/p2020rdb-pc_36b.dts
+++ b/arch/powerpc/dts/p2020rdb-pc_36b.dts
@@ -37,4 +37,5 @@
};
 };
 
+/include/ "p2020rdb-pc.dtsi"
 /include/ "p2020-post.dtsi"
diff --git a/arch/powerpc/dts/pq3-etsec1-0.dtsi 
b/arch/powerpc/dts/pq3-etsec1-0.dtsi
new file mode 100644
index 00..8800243f34
--- /dev/null
+++ b/arch/powerpc/dts/pq3-etsec1-0.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * PQ3 eTSEC device tree stub [ @ offsets 0x24000 ]
+ *
+ * Copyright 2011-2012 Freescale Semiconductor Inc.
+ * Copyright 2020 NXP
+ */
+
+ethernet@24000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   cell-index = <0>;
+   device_type = "network";
+   model = "eTSEC";
+   compatible = "gianfar";
+   reg = <0x24000 0x1000>;
+   ranges = <0x0 0x24000 0x1000>;
+   fsl,magic-packet;
+   local-mac-address = [ 00 00 00 00 00 00 ];
+   interrupts = <29 2 0 0 30 2 0 0 34 2 0 0>;
+};
+
+mdio@24520 {
+   #address

[PATCH 11/13] configs: P1010RDB: Enable DM_ETH config

[Zhiqiang Hou]

From: Hou Zhiqiang 

Enable the DM_ETH and DM_MDIO config.

Signed-off-by: Hou Zhiqiang 
---
 configs/P1010RDB-PA_36BIT_NAND_defconfig | 2 ++
 configs/P1010RDB-PA_36BIT_NOR_defconfig  | 2 ++
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   | 2 ++
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 2 ++
 configs/P1010RDB-PA_NAND_defconfig   | 2 ++
 configs/P1010RDB-PA_NOR_defconfig| 2 ++
 configs/P1010RDB-PA_SDCARD_defconfig | 2 ++
 configs/P1010RDB-PA_SPIFLASH_defconfig   | 2 ++
 configs/P1010RDB-PB_36BIT_NAND_defconfig | 2 ++
 configs/P1010RDB-PB_36BIT_NOR_defconfig  | 2 ++
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   | 2 ++
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 2 ++
 configs/P1010RDB-PB_NAND_defconfig   | 2 ++
 configs/P1010RDB-PB_NOR_defconfig| 2 ++
 configs/P1010RDB-PB_SDCARD_defconfig | 2 ++
 configs/P1010RDB-PB_SPIFLASH_defconfig   | 2 ++
 16 files changed, 32 insertions(+)

diff --git a/configs/P1010RDB-PA_36BIT_NAND_defconfig 
b/configs/P1010RDB-PA_36BIT_NAND_defconfig
index 83de3cee2c..f597a935e0 100644
--- a/configs/P1010RDB-PA_36BIT_NAND_defconfig
+++ b/configs/P1010RDB-PA_36BIT_NAND_defconfig
@@ -71,12 +71,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_36BIT_NOR_defconfig 
b/configs/P1010RDB-PA_36BIT_NOR_defconfig
index 7c1a3c8ee6..2817950cbd 100644
--- a/configs/P1010RDB-PA_36BIT_NOR_defconfig
+++ b/configs/P1010RDB-PA_36BIT_NOR_defconfig
@@ -53,12 +53,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig 
b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig
index 1de064ca8d..2db103da54 100644
--- a/configs/P1010RDB-PA_36BIT_SDCARD_defconfig
+++ b/configs/P1010RDB-PA_36BIT_SDCARD_defconfig
@@ -65,12 +65,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig 
b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
index d23d42a8b0..b618235f03 100644
--- a/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
+++ b/configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig
@@ -67,12 +67,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_NAND_defconfig 
b/configs/P1010RDB-PA_NAND_defconfig
index a218d143f5..375e7cf94c 100644
--- a/configs/P1010RDB-PA_NAND_defconfig
+++ b/configs/P1010RDB-PA_NAND_defconfig
@@ -70,12 +70,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_NOR_defconfig 
b/configs/P1010RDB-PA_NOR_defconfig
index f1e6553030..002f9ce208 100644
--- a/configs/P1010RDB-PA_NOR_defconfig
+++ b/configs/P1010RDB-PA_NOR_defconfig
@@ -52,12 +52,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_SDCARD_defconfig 
b/configs/P1010RDB-PA_SDCARD_defconfig
index 554e26febf..901e0ea794 100644
--- a/configs/P1010RDB-PA_SDCARD_defconfig
+++ b/configs/P1010RDB-PA_SDCARD_defconfig
@@ -64,12 +64,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_FSL_ESPI=y
diff --git a/configs/P1010RDB-PA_SPIFLASH_defconfig 
b/configs/P1010RDB-PA_SPIFLASH_defconfig
index 6211977901..4dbde0edfa 100644
--- a/configs/P1010RDB-PA_SPIFLASH_defconfig
+++ b/configs/P1010RDB-PA_SPIFLASH_defconfig
@@ -66,12 +66,14 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_DM=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TS

[PATCH 13/13] configs: P2020RDB: Enable DM_ETH config

[Zhiqiang Hou]

From: Hou Zhiqiang 

Enable the DM_ETH and DM_MDIO config.

On P2020RDB, the eTSEC1 is connecting with a switch VSC7385,
so also enable the fixed PHY support.

Signed-off-by: Hou Zhiqiang 
---
 configs/P2020RDB-PC_36BIT_NAND_defconfig | 3 +++
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig   | 3 +++
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig | 3 +++
 configs/P2020RDB-PC_36BIT_defconfig  | 3 +++
 configs/P2020RDB-PC_NAND_defconfig   | 3 +++
 configs/P2020RDB-PC_SDCARD_defconfig | 3 +++
 configs/P2020RDB-PC_SPIFLASH_defconfig   | 3 +++
 configs/P2020RDB-PC_defconfig| 3 +++
 8 files changed, 24 insertions(+)

diff --git a/configs/P2020RDB-PC_36BIT_NAND_defconfig 
b/configs/P2020RDB-PC_36BIT_NAND_defconfig
index b419367e7e..85b08c6769 100644
--- a/configs/P2020RDB-PC_36BIT_NAND_defconfig
+++ b/configs/P2020RDB-PC_36BIT_NAND_defconfig
@@ -66,6 +66,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -77,8 +78,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig 
b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig
index 0afddc2ed9..c4aa0abbfd 100644
--- a/configs/P2020RDB-PC_36BIT_SDCARD_defconfig
+++ b/configs/P2020RDB-PC_36BIT_SDCARD_defconfig
@@ -61,6 +61,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -72,8 +73,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig 
b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig
index 1a700a867f..d191a6010c 100644
--- a/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig
+++ b/configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig
@@ -63,6 +63,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -74,8 +75,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P2020RDB-PC_36BIT_defconfig 
b/configs/P2020RDB-PC_36BIT_defconfig
index 8b98cb8b9a..dc8a05c2d1 100644
--- a/configs/P2020RDB-PC_36BIT_defconfig
+++ b/configs/P2020RDB-PC_36BIT_defconfig
@@ -50,6 +50,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -61,8 +62,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P2020RDB-PC_NAND_defconfig 
b/configs/P2020RDB-PC_NAND_defconfig
index b1a26af0f4..f462f23355 100644
--- a/configs/P2020RDB-PC_NAND_defconfig
+++ b/configs/P2020RDB-PC_NAND_defconfig
@@ -65,6 +65,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -76,8 +77,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P2020RDB-PC_SDCARD_defconfig 
b/configs/P2020RDB-PC_SDCARD_defconfig
index c76958e1f3..1cf317297f 100644
--- a/configs/P2020RDB-PC_SDCARD_defconfig
+++ b/configs/P2020RDB-PC_SDCARD_defconfig
@@ -60,6 +60,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 CONFIG_PHY_BROADCOM=y
 CONFIG_PHY_DAVICOM=y
@@ -71,8 +72,10 @@ CONFIG_PHY_SMSC=y
 CONFIG_PHY_VITESSE=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
+CONFIG_DM_MDIO=y
 CONFIG_DM_PCI=y
 CONFIG_DM_PCI_COMPAT=y
 CONFIG_PCIE_FSL=y
diff --git a/configs/P2020RDB-PC_SPIFLASH_defconfig 
b/configs/P2020RDB-PC_SPIFLASH_defconfig
index 0892596fd6..c5e027959a 100644
--- a/configs/P2020RDB-PC_SPIFLASH_defconfig
+++ b/configs/P2020RDB-PC_SPIFLASH_defconfig
@@ -62,6 +62,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SF_DEFAULT_MODE=0
 CONFIG_SF_DEFAULT_SPEED=1000
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_PHY_FIXED=y
 CONFIG_PHY_ATHEROS=y
 C

[PATCH 10/13] powerpc: p1010rdb: Compile legacy ethernet init function when no DM_ETH

[Zhiqiang Hou]

From: Hou Zhiqiang 

The board_eth_init() is only used by legacy ethernet driver framework,
so do not compile it when DM_ETH config has been selected.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/p1010rdb/p1010rdb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/p1010rdb/p1010rdb.c 
b/board/freescale/p1010rdb/p1010rdb.c
index 5057eac38a..8b51d0cd75 100644
--- a/board/freescale/p1010rdb/p1010rdb.c
+++ b/board/freescale/p1010rdb/p1010rdb.c
@@ -327,6 +327,7 @@ int checkboard(void)
return 0;
 }
 
+#ifndef CONFIG_DM_ETH
 int board_eth_init(bd_t *bis)
 {
 #ifdef CONFIG_TSEC_ENET
@@ -367,6 +368,7 @@ int board_eth_init(bd_t *bis)
 
return pci_eth_init(bis);
 }
+#endif
 
 #if defined(CONFIG_OF_BOARD_SETUP)
 void fdt_del_flexcan(void *blob)
-- 
2.17.1

[PATCH 09/13] dts: powerpc: p1010rdb: Add eTSEC DT nodes

[Zhiqiang Hou]

From: Hou Zhiqiang 

P1010RDB implements 3 enhanced three-speed Ethernet controllers,
and the connection is shown below:
eTSEC1: Connected to RGMII PHY AR8033
eTSEC2: Connected to SGMII PHY AR8033
eTSEC3: Connected to SGMII PHY AR8033

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/p1010rdb-pa.dts |  1 +
 arch/powerpc/dts/p1010rdb-pa_36b.dts |  1 +
 arch/powerpc/dts/p1010rdb-pb.dts |  1 +
 arch/powerpc/dts/p1010rdb-pb_36b.dts |  1 +
 arch/powerpc/dts/p1010rdb.dtsi   | 71 
 arch/powerpc/dts/p1010si-post.dtsi   | 25 ++
 6 files changed, 100 insertions(+)
 create mode 100644 arch/powerpc/dts/p1010rdb.dtsi

diff --git a/arch/powerpc/dts/p1010rdb-pa.dts b/arch/powerpc/dts/p1010rdb-pa.dts
index c66c4923ac..d46080d3ba 100644
--- a/arch/powerpc/dts/p1010rdb-pa.dts
+++ b/arch/powerpc/dts/p1010rdb-pa.dts
@@ -14,4 +14,5 @@
/include/ "p1010rdb_32b.dtsi"
 };
 
+/include/ "p1010rdb.dtsi"
 /include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb-pa_36b.dts 
b/arch/powerpc/dts/p1010rdb-pa_36b.dts
index b943de7cbb..b9df5d46b2 100644
--- a/arch/powerpc/dts/p1010rdb-pa_36b.dts
+++ b/arch/powerpc/dts/p1010rdb-pa_36b.dts
@@ -14,4 +14,5 @@
/include/ "p1010rdb_36b.dtsi"
 };
 
+/include/ "p1010rdb.dtsi"
 /include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb-pb.dts b/arch/powerpc/dts/p1010rdb-pb.dts
index 2675d5d92b..65deabd288 100644
--- a/arch/powerpc/dts/p1010rdb-pb.dts
+++ b/arch/powerpc/dts/p1010rdb-pb.dts
@@ -14,4 +14,5 @@
/include/ "p1010rdb_32b.dtsi"
 };
 
+/include/ "p1010rdb.dtsi"
 /include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb-pb_36b.dts 
b/arch/powerpc/dts/p1010rdb-pb_36b.dts
index 45ccf91c41..1ba65a9f22 100644
--- a/arch/powerpc/dts/p1010rdb-pb_36b.dts
+++ b/arch/powerpc/dts/p1010rdb-pb_36b.dts
@@ -14,4 +14,5 @@
/include/ "p1010rdb_36b.dtsi"
 };
 
+/include/ "p1010rdb.dtsi"
 /include/ "p1010si-post.dtsi"
diff --git a/arch/powerpc/dts/p1010rdb.dtsi b/arch/powerpc/dts/p1010rdb.dtsi
new file mode 100644
index 00..2040465bf4
--- /dev/null
+++ b/arch/powerpc/dts/p1010rdb.dtsi
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * P1010 RDB Device Tree Source stub (no addresses or top-level ranges)
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ * Copyright 2020 NXP
+ */
+
+&soc {
+   mdio@24000 {
+   phy0: ethernet-phy@0 {
+   reg = <0x1>;
+   };
+
+   phy1: ethernet-phy@1 {
+   reg = <0x0>;
+   };
+
+   phy2: ethernet-phy@2 {
+   reg = <0x2>;
+   };
+
+   tbi-phy@3 {
+   device_type = "tbi-phy";
+   reg = <0x3>;
+   };
+   };
+
+   mdio@25000 {
+   tbi0: tbi-phy@11 {
+   reg = <0x11>;
+   device_type = "tbi-phy";
+   };
+   };
+
+   mdio@26000 {
+   tbi1: tbi-phy@11 {
+   reg = <0x11>;
+   device_type = "tbi-phy";
+   };
+   };
+
+   ptp_clock@b0e00 {
+   compatible = "fsl,etsec-ptp";
+   reg = <0xb0e00 0xb0>;
+   interrupts = <68 2 0 0 69 2 0 0>;
+   fsl,tclk-period = <10>;
+   fsl,tmr-prsc= <2>;
+   fsl,tmr-add = <0x8016>;
+   fsl,tmr-fiper1  = <0>;
+   fsl,tmr-fiper2  = <0>;
+   fsl,max-adj = <1>;
+   };
+
+   enet0: ethernet@b {
+   phy-handle = <&phy0>;
+   phy-connection-type = "rgmii-id";
+   };
+
+   enet1: ethernet@b1000 {
+   phy-handle = <&phy1>;
+   tbi-handle = <&tbi0>;
+   phy-connection-type = "sgmii";
+   };
+
+   enet2: ethernet@b2000 {
+   phy-handle = <&phy2>;
+   tbi-handle = <&tbi1>;
+   phy-connection-type = "sgmii";
+   };
+};
diff --git a/arch/powerpc/dts/p1010si-post.dtsi 
b/arch/powerpc/dts/p1010si-post.dtsi
index e24b5e4063..10de94a2e6 100644
--- a/arch/powerpc/dts/p1010si-post.dtsi
+++ b/arch/powerpc/dts/p1010si-post.dtsi
@@ -23,6 +23,31 @@
single-cpu-affinity;
last-interrupt-source = <255>;
};
+
+/include/ "pq3-etsec2-0.dtsi"
+   enet0: ethernet@b {
+   queue-group@b {
+   fsl,rx-bit-map = <0xff>;
+   fsl,tx-bit-map = <0xff>;
+   };
+   };
+
+/include/ "pq3-etsec2-1.dtsi"
+   enet1: ethernet@b1000 {
+   queue-group@b1000 {
+   fsl,rx-bit-map = <0xff>;
+   fsl,tx-bit-map = <0xff>;
+   };
+   };
+
+/include/ "pq3-etsec2-2.dtsi"
+   enet2: ethernet@b2000 {
+   queue-group@b2000 {
+   fsl,rx

[PATCH] imx: Kconfig: enable IMX_BOOTAUX for i.MX8M

[Peng Fan]

i.MX8M could use imx bootaux to boot m4/m7 core, so let's add it
to the dependency list.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 396f7c9288..2b97208445 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -23,7 +23,7 @@ config IMX_RDC
 
 config IMX_BOOTAUX
bool "Support boot auxiliary core"
-   depends on ARCH_MX7 || ARCH_MX6 || ARCH_VF610
+   depends on ARCH_MX7 || ARCH_MX6 || ARCH_VF610 || ARCH_IMX8M
help
  bootaux [addr] to boot auxiliary core.
 
-- 
2.16.4

[PATCH 03/10] imx: imx8qm/qxp: add get_board_serial

[Peng Fan]

Add get_board_serial support, the info could be got from fuse.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8/cpu.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 2c79bd0091..3bd0dee025 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -162,6 +163,37 @@ enum boot_device get_boot_device(void)
return boot_dev;
 }
 
+#ifdef CONFIG_SERIAL_TAG
+#define FUSE_UNIQUE_ID_WORD0 16
+#define FUSE_UNIQUE_ID_WORD1 17
+void get_board_serial(struct tag_serialnr *serialnr)
+{
+   sc_err_t err;
+   u32 val1 = 0, val2 = 0;
+   u32 word1, word2;
+
+   if (!serialnr)
+   return;
+
+   word1 = FUSE_UNIQUE_ID_WORD0;
+   word2 = FUSE_UNIQUE_ID_WORD1;
+
+   err = sc_misc_otp_fuse_read(-1, word1, &val1);
+   if (err != SC_ERR_NONE) {
+   printf("%s fuse %d read error: %d\n", __func__, word1, err);
+   return;
+   }
+
+   err = sc_misc_otp_fuse_read(-1, word2, &val2);
+   if (err != SC_ERR_NONE) {
+   printf("%s fuse %d read error: %d\n", __func__, word2, err);
+   return;
+   }
+   serialnr->low = val1;
+   serialnr->high = val2;
+}
+#endif /*CONFIG_SERIAL_TAG*/
+
 #ifdef CONFIG_ENV_IS_IN_MMC
 __weak int board_mmc_get_env_dev(int devno)
 {
-- 
2.16.4

[PATCH 00/10] imx: imx8qm/qxp update

[Peng Fan]

This patchset is various update for i.MX8 from NXP downstream

Support reserve ddr memory for M4
Add get board serial
power down resources when SPL jump to u-boot
recover SPL data
check m4 partition boot
Fix get_effective_memsize
select boot device dynamically

Peng Fan (8):
  imx: imx8qm/qxp: reserving DDR memory for M4
  imx: imx8qm/qxp: add get_board_serial
  imx: imx8qm/imx8qxp: Power down the resources before SPL jump to
u-boot
  imx: imx8qm/qxp: Recover SPL data section for partition reboot
  imx: imx8qm/qxp: check whether m4 partition booted
  imx: imx8qm: update fdt_file according to m4 state
  imx: imx8qxp: update fdt_file according to m4 state
  imx8: cpu: check resource owned after sid fail

Ye Li (2):
  imx: imx8qm/qxp: Fix issue in get_effective_memsize
  imx8: Select boot device dynamically

 arch/arm/cpu/armv8/Kconfig  |  6 ++
 arch/arm/cpu/armv8/Makefile |  4 ++
 arch/arm/cpu/armv8/spl_data.c   | 29 +
 arch/arm/cpu/armv8/u-boot-spl.lds   |  8 +++
 arch/arm/include/asm/arch-imx8/sys_proto.h  |  2 +
 arch/arm/mach-imx/imx8/Kconfig  | 10 +++
 arch/arm/mach-imx/imx8/cpu.c| 85 -
 arch/arm/mach-imx/imx8/fdt.c| 18 --
 board/freescale/imx8qm_mek/imx8qm_mek.c | 13 
 board/freescale/imx8qm_mek/spl.c|  6 ++
 board/freescale/imx8qxp_mek/imx8qxp_mek.c   | 13 
 board/freescale/imx8qxp_mek/spl.c   |  6 ++
 drivers/power/domain/imx8-power-domain-legacy.c | 35 ++
 include/configs/imx8qm_mek.h|  2 +-
 include/configs/imx8qxp_mek.h   |  2 +-
 include/spl.h   |  1 +
 16 files changed, 231 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/spl_data.c

-- 
2.16.4

[PATCH 01/10] imx: imx8qm/qxp: reserving DDR memory for M4

[Peng Fan]

The DDR memory from 0x8800 to 0x8FFF is assigned to M4 on
QM and QXP. The M4 can allocate this memory by two ways,
in SCD or u-boot.

In this patch, u-boot addes the memory reserve node to DTB to pass
the info to kernel, no matter the M4 memory is reserved in SCD
or u-boot. So kernel won't access M4 reserved memory.

Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8/Kconfig |  8 
 arch/arm/mach-imx/imx8/fdt.c   | 10 ++
 2 files changed, 18 insertions(+)

diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index 1f8add015f..69149d3cd5 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -41,6 +41,14 @@ config IMX_CONTAINER_CFG
  This is to specific the cfg file for generating container
  image which will be loaded by SPL.
 
+config BOOTAUX_RESERVED_MEM_BASE
+   hex "i.MX auxiliary core dram memory base"
+   default 0
+
+config BOOTAUX_RESERVED_MEM_SIZE
+   hex "i.MX auxiliary core dram memory size"
+   default 0
+
 choice
prompt "i.MX8 board select"
optional
diff --git a/arch/arm/mach-imx/imx8/fdt.c b/arch/arm/mach-imx/imx8/fdt.c
index 65c8ac1a7e..5993645378 100644
--- a/arch/arm/mach-imx/imx8/fdt.c
+++ b/arch/arm/mach-imx/imx8/fdt.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -279,6 +280,15 @@ static int ft_add_optee_node(void *fdt, bd_t *bd)
 int ft_system_setup(void *blob, bd_t *bd)
 {
int ret;
+   int off;
+
+   if (CONFIG_BOOTAUX_RESERVED_MEM_BASE) {
+   off = fdt_add_mem_rsv(blob, CONFIG_BOOTAUX_RESERVED_MEM_BASE,
+ CONFIG_BOOTAUX_RESERVED_MEM_SIZE);
+   if (off < 0)
+   printf("Failed  to reserve memory for bootaux: %s\n",
+  fdt_strerror(off));
+   }
 
update_fdt_with_owned_resources(blob);
 
-- 
2.16.4

[PATCH 02/10] imx: imx8qm/qxp: Fix issue in get_effective_memsize

[Peng Fan]

From: Ye Li 

When Trusty OS allocates the mem region from 0xfe000-0x,
the get_effective_memsize does not return correct memory size.
There is a check in get_effective_memsize to find the memreg where
the u-boot is running, and return the size of that memreg as the result
of get_effective_memsize. When using aligned start, the value is
0x8020 since it is 2MB aligned. Thus the finding of memreg will
fail and return the PHYS_SDRAM_1_SIZE because u-boot text base is
0x8002. This cause u-boot is relocated to the high memory where has
been occupied by Trusty OS.

Reviewed-by: Peng Fan 
Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8/cpu.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index f87276e8ea..2c79bd0091 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -223,7 +223,7 @@ static int get_owned_memreg(sc_rm_mr_t mr, sc_faddr_t 
*addr_start,
 phys_size_t get_effective_memsize(void)
 {
sc_rm_mr_t mr;
-   sc_faddr_t start, end, end1;
+   sc_faddr_t start, end, end1, start_aligned;
int err;
 
end1 = (sc_faddr_t)PHYS_SDRAM_1 + PHYS_SDRAM_1_SIZE;
@@ -231,9 +231,9 @@ phys_size_t get_effective_memsize(void)
for (mr = 0; mr < 64; mr++) {
err = get_owned_memreg(mr, &start, &end);
if (!err) {
-   start = roundup(start, MEMSTART_ALIGNMENT);
+   start_aligned = roundup(start, MEMSTART_ALIGNMENT);
/* Too small memory region, not use it */
-   if (start > end)
+   if (start_aligned > end)
continue;
 
/* Find the memory region runs the U-Boot */
-- 
2.16.4

[PATCH 04/10] imx: imx8qm/imx8qxp: Power down the resources before SPL jump to u-boot

[Peng Fan]

Make sure that all devices that are powered up by SPL are powered down
before entering into the u-boot. Otherwise the subsystem/device will
never be powered down by SCFW, due to SPL and u-boot are in different
partitions.

Benefiting from power domain driver, this patch implements the function
"imx8_power_off_pd_devices" to power off all active devices.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8/sys_proto.h  |  1 +
 board/freescale/imx8qm_mek/spl.c|  6 +
 board/freescale/imx8qxp_mek/spl.c   |  6 +
 drivers/power/domain/imx8-power-domain-legacy.c | 35 +
 4 files changed, 48 insertions(+)

diff --git a/arch/arm/include/asm/arch-imx8/sys_proto.h 
b/arch/arm/include/asm/arch-imx8/sys_proto.h
index fc33e6ed18..2a08ef939d 100644
--- a/arch/arm/include/asm/arch-imx8/sys_proto.h
+++ b/arch/arm/include/asm/arch-imx8/sys_proto.h
@@ -28,3 +28,4 @@ int print_bootinfo(void);
 int sc_pm_setup_uart(sc_rsrc_t uart_rsrc, sc_pm_clock_rate_t clk_rate);
 int imx8_power_domain_lookup_name(const char *name,
  struct power_domain *power_domain);
+void imx8_power_off_pd_devices(const char *permanent_on_devices[], int size);
diff --git a/board/freescale/imx8qm_mek/spl.c b/board/freescale/imx8qm_mek/spl.c
index cb4006eb2a..ba99002cf2 100644
--- a/board/freescale/imx8qm_mek/spl.c
+++ b/board/freescale/imx8qm_mek/spl.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -37,6 +38,11 @@ void spl_board_init(void)
puts("Normal Boot\n");
 }
 
+void spl_board_prepare_for_boot(void)
+{
+   imx8_power_off_pd_devices(NULL, 0);
+}
+
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
diff --git a/board/freescale/imx8qxp_mek/spl.c 
b/board/freescale/imx8qxp_mek/spl.c
index e4e4cbe716..32b61095b0 100644
--- a/board/freescale/imx8qxp_mek/spl.c
+++ b/board/freescale/imx8qxp_mek/spl.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -55,6 +56,11 @@ void spl_board_init(void)
puts("Normal Boot\n");
 }
 
+void spl_board_prepare_for_boot(void)
+{
+   imx_power_off_pd_devices(NULL, 0);
+}
+
 #ifdef CONFIG_SPL_LOAD_FIT
 int board_fit_config_name_match(const char *name)
 {
diff --git a/drivers/power/domain/imx8-power-domain-legacy.c 
b/drivers/power/domain/imx8-power-domain-legacy.c
index f679df9e5d..7ba4056e2d 100644
--- a/drivers/power/domain/imx8-power-domain-legacy.c
+++ b/drivers/power/domain/imx8-power-domain-legacy.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -19,6 +20,40 @@ struct imx8_power_domain_priv {
bool state_on;
 };
 
+static bool check_device_power_off(struct udevice *dev,
+  const char *permanent_on_devices[],
+  int size)
+{
+   int i;
+
+   for (i = 0; i < size; i++) {
+   if (!strcmp(dev->name, permanent_on_devices[i]))
+   return false;
+   }
+
+   return true;
+}
+
+void imx8_power_off_pd_devices(const char *permanent_on_devices[], int size)
+{
+   struct udevice *dev;
+   struct power_domain pd;
+
+   for (uclass_find_first_device(UCLASS_POWER_DOMAIN, &dev); dev;
+uclass_find_next_device(&dev)) {
+   if (!device_active(dev))
+   continue;
+   /*
+* Power off active pd devices except the permanent
+* power on devices
+*/
+   if (check_device_power_off(dev, permanent_on_devices, size)) {
+   pd.dev = dev;
+   power_domain_off(&pd);
+   }
+   }
+}
+
 int imx8_power_domain_lookup_name(const char *name,
  struct power_domain *power_domain)
 {
-- 
2.16.4

[PATCH 06/10] imx8: Select boot device dynamically

[Peng Fan]

From: Ye Li 

For fspi build, we will enable both SPL NOR support and SPL SPI
support. SPL will dynamically check the resource owner then
select corresponding boot device.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8/cpu.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index e03193cb4c..103a29746a 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -573,3 +574,14 @@ u32 get_cpu_rev(void)
 
return (id << 12) | rev;
 }
+
+void board_boot_order(u32 *spl_boot_list)
+{
+   spl_boot_list[0] = spl_boot_device();
+
+   if (spl_boot_list[0] == BOOT_DEVICE_SPI) {
+   /* Check whether we own the flexspi0, if not, use NOR boot */
+   if (!sc_rm_is_resource_owned(-1, SC_R_FSPI_0))
+   spl_boot_list[0] = BOOT_DEVICE_NOR;
+   }
+}
-- 
2.16.4

[PATCH 05/10] imx: imx8qm/qxp: Recover SPL data section for partition reboot

[Peng Fan]

When doing partition reboot, the boot image won't be reloaded by ROM,
it is just CPU reset to boot entry. The SW has to keep the boot image
inside the RAM unchanged. It includes both the TEXT section and DATA
section.

For SPL, the problem is DATA section will be updated at runtime, so in
next partition reboot the data is not same as the initial value from
cold boot. If any code depends on the initial value, then it will have
problem.

This patch introduces a mechanism to recover the data section
for partition reboot. It adds a new section in image for saving
data section. When from cold boot, the data section will be saved
to that new section at SPL early phase. When from partition reboot,
the data section will be restored from the new section.

Signed-off-by: Ye Li 
Signed-off-by: Peng Fan 
---
 arch/arm/cpu/armv8/Kconfig|  6 ++
 arch/arm/cpu/armv8/Makefile   |  4 
 arch/arm/cpu/armv8/spl_data.c | 29 +
 arch/arm/cpu/armv8/u-boot-spl.lds |  8 
 arch/arm/mach-imx/imx8/Kconfig|  2 ++
 arch/arm/mach-imx/imx8/cpu.c  |  5 +
 include/spl.h |  1 +
 7 files changed, 55 insertions(+)
 create mode 100644 arch/arm/cpu/armv8/spl_data.c

diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 16c83e8614..3655990772 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -76,6 +76,12 @@ config SPL_ARMV8_SEC_FIRMWARE_SUPPORT
help
  Say Y here to support this framework in SPL phase.
 
+config SPL_RECOVER_DATA_SECTION
+   bool "save/restore SPL data section"
+   help
+ Say Y here to save SPL data section for cold boot, and restore
+ at warm boot in SPL phase.
+
 config SEC_FIRMWARE_ARMV8_PSCI
bool "PSCI implementation in secure monitor firmware"
depends on ARMV8_SEC_FIRMWARE_SUPPORT || SPL_ARMV8_SEC_FIRMWARE_SUPPORT
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index b349b13f49..2e48df0eb9 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -30,6 +30,10 @@ obj-$(CONFIG_ARMV8_SPIN_TABLE) += spin_table.o 
spin_table_v8.o
 endif
 obj-$(CONFIG_$(SPL_)ARMV8_SEC_FIRMWARE_SUPPORT) += sec_firmware.o 
sec_firmware_asm.o
 
+ifdef CONFIG_SPL_BUILD
+obj-$(CONFIG_SPL_RECOVER_DATA_SECTION) += spl_data.o
+endif
+
 obj-$(CONFIG_FSL_LAYERSCAPE) += fsl-layerscape/
 obj-$(CONFIG_S32V234) += s32v234/
 obj-$(CONFIG_TARGET_HIKEY) += hisilicon/
diff --git a/arch/arm/cpu/armv8/spl_data.c b/arch/arm/cpu/armv8/spl_data.c
new file mode 100644
index 00..8fd986a67a
--- /dev/null
+++ b/arch/arm/cpu/armv8/spl_data.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 NXP
+ */
+
+#include 
+#include 
+
+char __data_save_start[0] __section(.__data_save_start);
+char __data_save_end[0] __section(.__data_save_end);
+
+u32 cold_reboot_flag = 1;
+
+void spl_save_restore_data(void)
+{
+   u32 data_size = __data_save_end - __data_save_start;
+
+   if (cold_reboot_flag == 1) {
+   /* Save data section to data_save section */
+   memcpy(__data_save_start, __data_save_start - data_size,
+  data_size);
+   } else {
+   /* Restore the data_save section to data section */
+   memcpy(__data_save_start - data_size, __data_save_start,
+  data_size);
+   }
+
+   cold_reboot_flag++;
+}
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index ccbf359bd1..0e67ab09d7 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -38,6 +38,14 @@ SECTIONS
*(.data*)
} >.sram
 
+#ifdef CONFIG_SPL_RECOVER_DATA_SECTION
+   .data_save : {
+   *(.__data_save_start)
+   . = SIZEOF(.data);
+   *(.__data_save_end)
+   } >.sram
+#endif
+
.u_boot_list : {
. = ALIGN(8);
KEEP(*(SORT(.u_boot_list*)));
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index 69149d3cd5..9d1f73dfc7 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -18,11 +18,13 @@ config MU_BASE_SPL
 config IMX8QM
select IMX8
select SUPPORT_SPL
+   select SPL_RECOVER_DATA_SECTION
bool
 
 config IMX8QXP
select IMX8
select SUPPORT_SPL
+   select SPL_RECOVER_DATA_SECTION
bool
 
 config SYS_SOC
diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 3bd0dee025..e03193cb4c 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,10 @@ struct pass_over_info_t *get_pass_over_info(void)
 
 int arch_cpu_init(void)
 {
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_RECOVER_DATA_SECTION)
+   spl_save_restore_data();
+#endif
+
 

[PATCH 07/10] imx: imx8qm/qxp: check whether m4 partition booted

[Peng Fan]

Add code to check m4 partition booted or not, we will use this
to runtime set device tree file that passed to Linux Kernel.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8/sys_proto.h |  1 +
 arch/arm/mach-imx/imx8/cpu.c   | 30 ++
 board/freescale/imx8qxp_mek/spl.c  |  2 +-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-imx8/sys_proto.h 
b/arch/arm/include/asm/arch-imx8/sys_proto.h
index 2a08ef939d..6f1fc8f999 100644
--- a/arch/arm/include/asm/arch-imx8/sys_proto.h
+++ b/arch/arm/include/asm/arch-imx8/sys_proto.h
@@ -29,3 +29,4 @@ int sc_pm_setup_uart(sc_rsrc_t uart_rsrc, sc_pm_clock_rate_t 
clk_rate);
 int imx8_power_domain_lookup_name(const char *name,
  struct power_domain *power_domain);
 void imx8_power_off_pd_devices(const char *permanent_on_devices[], int size);
+bool m4_parts_booted(void);
diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 103a29746a..6d7b17b464 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -585,3 +585,33 @@ void board_boot_order(u32 *spl_boot_list)
spl_boot_list[0] = BOOT_DEVICE_NOR;
}
 }
+
+bool m4_parts_booted(void)
+{
+   sc_rm_pt_t m4_parts[2];
+   int err;
+
+   err = sc_rm_get_resource_owner(-1, SC_R_M4_0_PID0, &m4_parts[0]);
+   if (err) {
+   printf("%s get resource [%d] owner error: %d\n", __func__,
+  SC_R_M4_0_PID0, err);
+   return false;
+   }
+
+   if (sc_pm_is_partition_started(-1, m4_parts[0]))
+   return true;
+
+   if (is_imx8qm()) {
+   err = sc_rm_get_resource_owner(-1, SC_R_M4_1_PID0, 
&m4_parts[1]);
+   if (err) {
+   printf("%s get resource [%d] owner error: %d\n",
+  __func__, SC_R_M4_1_PID0, err);
+   return false;
+   }
+
+   if (sc_pm_is_partition_started(-1, m4_parts[1]))
+   return true;
+   }
+
+   return false;
+}
diff --git a/board/freescale/imx8qxp_mek/spl.c 
b/board/freescale/imx8qxp_mek/spl.c
index 32b61095b0..eefee64ab1 100644
--- a/board/freescale/imx8qxp_mek/spl.c
+++ b/board/freescale/imx8qxp_mek/spl.c
@@ -58,7 +58,7 @@ void spl_board_init(void)
 
 void spl_board_prepare_for_boot(void)
 {
-   imx_power_off_pd_devices(NULL, 0);
+   imx8_power_off_pd_devices(NULL, 0);
 }
 
 #ifdef CONFIG_SPL_LOAD_FIT
-- 
2.16.4

[PATCH 09/10] imx: imx8qxp: update fdt_file according to m4 state

[Peng Fan]

Update fdt_file according to m4 parts state

Signed-off-by: Peng Fan 
---
 board/freescale/imx8qxp_mek/imx8qxp_mek.c | 13 +
 include/configs/imx8qxp_mek.h |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/board/freescale/imx8qxp_mek/imx8qxp_mek.c 
b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
index 93f0cd827c..dc9ffaabf2 100644
--- a/board/freescale/imx8qxp_mek/imx8qxp_mek.c
+++ b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
@@ -146,10 +146,23 @@ int board_mmc_get_env_dev(int devno)
 
 int board_late_init(void)
 {
+   char *fdt_file;
+   bool m4_booted;
+
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
env_set("board_name", "MEK");
env_set("board_rev", "iMX8QXP");
 #endif
 
+   fdt_file = env_get("fdt_file");
+   m4_booted = m4_parts_booted();
+
+   if (fdt_file && !strcmp(fdt_file, "undefined")) {
+   if (m4_booted)
+   env_set("fdt_file", "imx8qxp-mek-rpmsg.dtb");
+   else
+   env_set("fdt_file", "imx8qxp-mek.dtb");
+   }
+
return 0;
 }
diff --git a/include/configs/imx8qxp_mek.h b/include/configs/imx8qxp_mek.h
index 0aaca3325b..341e93e61e 100644
--- a/include/configs/imx8qxp_mek.h
+++ b/include/configs/imx8qxp_mek.h
@@ -69,7 +69,7 @@
"fdt_addr=0x8300\0" \
"fdt_high=0x\0" \
"boot_fdt=try\0" \
-   "fdt_file=imx8qxp-mek.dtb\0" \
+   "fdt_file=undefined\0" \
"initrd_addr=0x8380\0"  \
"initrd_high=0x\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
-- 
2.16.4

[PATCH 10/10] imx8: cpu: check resource owned after sid fail

[Peng Fan]

When we create software partition, we still need let parent
partition to configure sid, so move the check after sid failed.

Acked-by: Ye Li 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/imx8/fdt.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-imx/imx8/fdt.c b/arch/arm/mach-imx/imx8/fdt.c
index 5993645378..9a6822a929 100644
--- a/arch/arm/mach-imx/imx8/fdt.c
+++ b/arch/arm/mach-imx/imx8/fdt.c
@@ -106,13 +106,13 @@ static int config_smmu_resource_sid(int rsrc, int sid)
 {
int err;
 
-   if (!check_owned_resource(rsrc)) {
-   printf("%s rsrc[%d] not owned\n", __func__, rsrc);
-   return -1;
-   }
err = sc_rm_set_master_sid(-1, rsrc, sid);
debug("set_master_sid rsrc=%d sid=0x%x err=%d\n", rsrc, sid, err);
if (err != SC_ERR_NONE) {
+   if (!check_owned_resource(rsrc)) {
+   printf("%s rsrc[%d] not owned\n", __func__, rsrc);
+   return -1;
+   }
pr_err("fail set_master_sid rsrc=%d sid=0x%x err=%d\n", rsrc, 
sid, err);
return -EINVAL;
}
-- 
2.16.4

[PATCH 08/10] imx: imx8qm: update fdt_file according to m4 state

[Peng Fan]

Update fdt_file according to m4 parts state

Signed-off-by: Peng Fan 
---
 board/freescale/imx8qm_mek/imx8qm_mek.c | 13 +
 include/configs/imx8qm_mek.h|  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/board/freescale/imx8qm_mek/imx8qm_mek.c 
b/board/freescale/imx8qm_mek/imx8qm_mek.c
index c9b9b2547e..c0cae3540f 100644
--- a/board/freescale/imx8qm_mek/imx8qm_mek.c
+++ b/board/freescale/imx8qm_mek/imx8qm_mek.c
@@ -123,10 +123,23 @@ int board_mmc_get_env_dev(int devno)
 
 int board_late_init(void)
 {
+   char *fdt_file;
+   bool m4_booted;
+
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
env_set("board_name", "MEK");
env_set("board_rev", "iMX8QM");
 #endif
 
+   fdt_file = env_get("fdt_file");
+   m4_booted = m4_parts_booted();
+
+   if (fdt_file && !strcmp(fdt_file, "undefined")) {
+   if (m4_booted)
+   env_set("fdt_file", "imx8qm-mek-rpmsg.dtb");
+   else
+   env_set("fdt_file", "imx8qm-mek.dtb");
+   }
+
return 0;
 }
diff --git a/include/configs/imx8qm_mek.h b/include/configs/imx8qm_mek.h
index 97170dc949..22d80f1747 100644
--- a/include/configs/imx8qm_mek.h
+++ b/include/configs/imx8qm_mek.h
@@ -70,7 +70,7 @@
"fdt_addr=0x8300\0" \
"fdt_high=0x\0" \
"boot_fdt=try\0" \
-   "fdt_file=imx8qm-mek.dtb\0" \
+   "fdt_file=undefined\0" \
"initrd_addr=0x8380\0"  \
"initrd_high=0x\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
-- 
2.16.4

[PATCH] cmd: gpt: add eMMC and GPT support

[Rayagonda Kokatanur]

From: Corneliu Doban 

Add eMMC and GPT support.
- GPT partition list and command to create the GPT added to u-boot
  environment
- eMMC boot commands added to u-boot environment
- new gpt commands (enumarate and setenv) that are used by broadcom
  update scripts and boot commands
- eMMC specific u-boot configurations with environment saved in eMMC
  and GPT support

Signed-off-by: Corneliu Doban 
Signed-off-by: Rayagonda Kokatanur 

diff --git a/cmd/gpt.c b/cmd/gpt.c
index b8d11c167d..c32e272b25 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -616,6 +616,87 @@ static int gpt_verify(struct blk_desc *blk_dev_desc, const 
char *str_part)
return ret;
 }
 
+/*
+ * Enumerate partition names into environment variable.
+ */
+static int gpt_enumerate(struct blk_desc *blk_dev_desc)
+{
+   disk_partition_t pinfo;
+   struct part_driver *first_drv =
+   ll_entry_start(struct part_driver, part_driver);
+   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+   struct part_driver *part_drv;
+   char part_list[2048];
+
+   part_list[0] = 0;
+
+   for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+   int ret;
+   int i;
+
+   for (i = 1; i < part_drv->max_entries; i++) {
+   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
+   if (ret != 0) {
+   /* no more entries in table */
+   break;
+   }
+   strcat(part_list, (const char *)pinfo.name);
+   strcat(part_list, " ");
+   }
+   }
+   if (strlen(part_list) > 0)
+   part_list[strlen(part_list) - 1] = 0;
+   debug("setenv gpt_partition_list %s\n", part_list);
+   env_set("gpt_partition_list", part_list);
+   return 0;
+}
+
+/*
+ * Dynamically setup environment variables for name, index, offset and size
+ * for partition in GPT table after running "gpt setenv" for a partition name.
+ * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
+ * gpt_partition_size environment variables will be set.
+ */
+static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
+{
+   disk_partition_t pinfo;
+   struct part_driver *first_drv =
+   ll_entry_start(struct part_driver, part_driver);
+   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+   struct part_driver *part_drv;
+   char buf[32];
+
+   for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+   int ret;
+   int i;
+
+   for (i = 1; i < part_drv->max_entries; i++) {
+   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
+   if (ret != 0) {
+   /* no more entries in table */
+   break;
+   }
+   if (strcmp(name, (const char *)pinfo.name) == 0) {
+   /* match found, setup environment variables */
+   sprintf(buf, LBAF, pinfo.start);
+   debug("setenv gpt_partition_addr %s\n", buf);
+   env_set("gpt_partition_addr", buf);
+   sprintf(buf, LBAF, pinfo.size);
+   debug("setenv gpt_partition_size %s\n", buf);
+   env_set("gpt_partition_size", buf);
+   sprintf(buf, "%d", i);
+   debug("setenv gpt_partition_entry %s\n", buf);
+   env_set("gpt_partition_entry", buf);
+   sprintf(buf, "%s", pinfo.name);
+   debug("setenv gpt_partition_name %s\n", buf);
+   env_set("gpt_partition_name", buf);
+   return 0;
+   }
+   }
+   }
+   return -1;
+}
+
 static int do_disk_guid(struct blk_desc *dev_desc, char * const namestr)
 {
int ret;
@@ -822,6 +903,10 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
} else if ((strcmp(argv[1], "verify") == 0)) {
ret = gpt_verify(blk_dev_desc, argv[4]);
printf("Verify GPT: ");
+   } else if ((strcmp(argv[1], "setenv") == 0)) {
+   ret = gpt_setenv(blk_dev_desc, argv[4]);
+   } else if ((strcmp(argv[1], "enumerate") == 0)) {
+   ret = gpt_enumerate(blk_dev_desc);
} else if (strcmp(argv[1], "guid") == 0) {
ret = do_disk_guid(blk_dev_desc, argv[4]);
 #ifdef CONFIG_CMD_GPT_RENAME
@@ -852,7 +937,17 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" to interface\n"
" Example usage:\n"
" gpt write mmc 0 $partitions\n"
+   "- write the GPT to device\n"

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Matthias Brugger]

On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> When needed, RPi4's co-processor (called VideoCore) has to be instructed
> to load VL805's firmware (the chip providing xHCI support). VideoCore's
> firmware expects the board's PCIe bus to be already configured in order
> for it to load the xHCI chip firmware. So we have to make sure this
> happens in between the PCIe configuration and xHCI startup.
> 
> Introduce a callback in xhci_pci_probe() to run this platform specific
> routine.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> 
> ---
> 
> Changes since v1:
>  - Create callback
> 
>  board/raspberrypi/rpi/rpi.c | 12 
>  drivers/usb/host/xhci-pci.c |  6 ++
>  include/usb/xhci.h  |  3 +++
>  3 files changed, 21 insertions(+)
> 
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index e367ba3092..8aa78d1f48 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
>  
>   return 0;
>  }
> +
> +#ifdef CONFIG_BCM2711

This won't work with rpi_arm64_defconfig.
Can't we just evaluate at runtime if we need to do anything in xhci_pci_fixup.

I wonder if the newer RPi4 have also a newer revision ID (see get_board_rev). If
so we could add another bool to struct rpi_model which will indicate us if we
need to notify VideoCore about vl805's firmware.

Regards,
Matthias

> +void xhci_pci_fixup(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = bcm2711_notify_vl805_reset();
> + if (ret)
> + printf("RPI: Failed to notify VideoCore about vl805's 
> firmware\n");
> +}
> +#endif
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index c1f60da541..1285dde1ef 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -11,6 +11,10 @@
>  #include 
>  #include 
>  
> +__weak void xhci_pci_fixup(struct udevice *dev)
> +{
> +}
> +
>  static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
> struct xhci_hcor **ret_hcor)
>  {
> @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
>   struct xhci_hccr *hccr;
>   struct xhci_hcor *hcor;
>  
> + xhci_pci_fixup(dev);
> +
>   xhci_pci_init(dev, &hccr, &hcor);
>  
>   return xhci_register(dev, hccr, hcor);
> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> index c16106a2fc..57feed7603 100644
> --- a/include/usb/xhci.h
> +++ b/include/usb/xhci.h
> @@ -16,6 +16,7 @@
>  #ifndef HOST_XHCI_H_
>  #define HOST_XHCI_H_
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
>  
>  struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
>  
> +extern void xhci_pci_fixup(struct udevice *dev);
> +
>  #endif /* HOST_XHCI_H_ */
> 

Re: [PATCH] cmd: gpt: add eMMC and GPT support

[Rayagonda Kokatanur]

On Tue, May 5, 2020 at 5:43 PM Rayagonda Kokatanur
 wrote:
>
> From: Corneliu Doban 
>
> Add eMMC and GPT support.
> - GPT partition list and command to create the GPT added to u-boot
>   environment
> - eMMC boot commands added to u-boot environment
> - new gpt commands (enumarate and setenv) that are used by broadcom
>   update scripts and boot commands
> - eMMC specific u-boot configurations with environment saved in eMMC
>   and GPT support
>
> Signed-off-by: Corneliu Doban 
> Signed-off-by: Rayagonda Kokatanur 
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index b8d11c167d..c32e272b25 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -616,6 +616,87 @@ static int gpt_verify(struct blk_desc *blk_dev_desc, 
> const char *str_part)
> return ret;
>  }
>
> +/*
> + * Enumerate partition names into environment variable.
> + */
> +static int gpt_enumerate(struct blk_desc *blk_dev_desc)
> +{
> +   disk_partition_t pinfo;
> +   struct part_driver *first_drv =
> +   ll_entry_start(struct part_driver, part_driver);
> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
> +   struct part_driver *part_drv;
> +   char part_list[2048];
> +
> +   part_list[0] = 0;
> +
> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
> part_drv++) {
> +   int ret;
> +   int i;
> +
> +   for (i = 1; i < part_drv->max_entries; i++) {
> +   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
> +   if (ret != 0) {
> +   /* no more entries in table */
> +   break;
> +   }
> +   strcat(part_list, (const char *)pinfo.name);
> +   strcat(part_list, " ");
> +   }
> +   }
> +   if (strlen(part_list) > 0)
> +   part_list[strlen(part_list) - 1] = 0;
> +   debug("setenv gpt_partition_list %s\n", part_list);
> +   env_set("gpt_partition_list", part_list);
> +   return 0;
> +}
> +
> +/*
> + * Dynamically setup environment variables for name, index, offset and size
> + * for partition in GPT table after running "gpt setenv" for a partition 
> name.
> + * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
> + * gpt_partition_size environment variables will be set.
> + */
> +static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
> +{
> +   disk_partition_t pinfo;
> +   struct part_driver *first_drv =
> +   ll_entry_start(struct part_driver, part_driver);
> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
> +   struct part_driver *part_drv;
> +   char buf[32];
> +
> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
> part_drv++) {
> +   int ret;
> +   int i;
> +
> +   for (i = 1; i < part_drv->max_entries; i++) {
> +   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
> +   if (ret != 0) {
> +   /* no more entries in table */
> +   break;
> +   }
> +   if (strcmp(name, (const char *)pinfo.name) == 0) {
> +   /* match found, setup environment variables */
> +   sprintf(buf, LBAF, pinfo.start);
> +   debug("setenv gpt_partition_addr %s\n", buf);
> +   env_set("gpt_partition_addr", buf);
> +   sprintf(buf, LBAF, pinfo.size);
> +   debug("setenv gpt_partition_size %s\n", buf);
> +   env_set("gpt_partition_size", buf);
> +   sprintf(buf, "%d", i);
> +   debug("setenv gpt_partition_entry %s\n", buf);
> +   env_set("gpt_partition_entry", buf);
> +   sprintf(buf, "%s", pinfo.name);
> +   debug("setenv gpt_partition_name %s\n", buf);
> +   env_set("gpt_partition_name", buf);
> +   return 0;
> +   }
> +   }
> +   }
> +   return -1;
> +}
> +
>  static int do_disk_guid(struct blk_desc *dev_desc, char * const namestr)
>  {
> int ret;
> @@ -822,6 +903,10 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc, 
> char * const argv[])
> } else if ((strcmp(argv[1], "verify") == 0)) {
> ret = gpt_verify(blk_dev_desc, argv[4]);
> printf("Verify GPT: ");
> +   } else if ((strcmp(argv[1], "setenv") == 0)) {
> +   ret = gpt_setenv(blk_dev_desc, argv[4]);
> +   } else if ((strcmp(argv[1], "enumerate") == 0)) {
> +   ret = gpt_enumerate(blk_dev_desc);
> } else if (strcmp(argv[1], "guid") ==

[PATCH v1 1/1] cmd: gpt: add eMMC and GPT support

[Rayagonda Kokatanur]

From: Corneliu Doban 

Add eMMC and GPT support.
- GPT partition list and command to create the GPT added to u-boot
  environment
- eMMC boot commands added to u-boot environment
- new gpt commands (enumarate and setenv) that are used by broadcom
  update scripts and boot commands
- eMMC specific u-boot configurations with environment saved in eMMC
  and GPT support

Signed-off-by: Corneliu Doban 
Signed-off-by: Rayagonda Kokatanur 
---
 cmd/gpt.c | 95 +++
 1 file changed, 95 insertions(+)

diff --git a/cmd/gpt.c b/cmd/gpt.c
index b8d11c167d..c32e272b25 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -616,6 +616,87 @@ static int gpt_verify(struct blk_desc *blk_dev_desc, const 
char *str_part)
return ret;
 }
 
+/*
+ * Enumerate partition names into environment variable.
+ */
+static int gpt_enumerate(struct blk_desc *blk_dev_desc)
+{
+   disk_partition_t pinfo;
+   struct part_driver *first_drv =
+   ll_entry_start(struct part_driver, part_driver);
+   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+   struct part_driver *part_drv;
+   char part_list[2048];
+
+   part_list[0] = 0;
+
+   for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+   int ret;
+   int i;
+
+   for (i = 1; i < part_drv->max_entries; i++) {
+   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
+   if (ret != 0) {
+   /* no more entries in table */
+   break;
+   }
+   strcat(part_list, (const char *)pinfo.name);
+   strcat(part_list, " ");
+   }
+   }
+   if (strlen(part_list) > 0)
+   part_list[strlen(part_list) - 1] = 0;
+   debug("setenv gpt_partition_list %s\n", part_list);
+   env_set("gpt_partition_list", part_list);
+   return 0;
+}
+
+/*
+ * Dynamically setup environment variables for name, index, offset and size
+ * for partition in GPT table after running "gpt setenv" for a partition name.
+ * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
+ * gpt_partition_size environment variables will be set.
+ */
+static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
+{
+   disk_partition_t pinfo;
+   struct part_driver *first_drv =
+   ll_entry_start(struct part_driver, part_driver);
+   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
+   struct part_driver *part_drv;
+   char buf[32];
+
+   for (part_drv = first_drv; part_drv != first_drv + n_drvs; part_drv++) {
+   int ret;
+   int i;
+
+   for (i = 1; i < part_drv->max_entries; i++) {
+   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
+   if (ret != 0) {
+   /* no more entries in table */
+   break;
+   }
+   if (strcmp(name, (const char *)pinfo.name) == 0) {
+   /* match found, setup environment variables */
+   sprintf(buf, LBAF, pinfo.start);
+   debug("setenv gpt_partition_addr %s\n", buf);
+   env_set("gpt_partition_addr", buf);
+   sprintf(buf, LBAF, pinfo.size);
+   debug("setenv gpt_partition_size %s\n", buf);
+   env_set("gpt_partition_size", buf);
+   sprintf(buf, "%d", i);
+   debug("setenv gpt_partition_entry %s\n", buf);
+   env_set("gpt_partition_entry", buf);
+   sprintf(buf, "%s", pinfo.name);
+   debug("setenv gpt_partition_name %s\n", buf);
+   env_set("gpt_partition_name", buf);
+   return 0;
+   }
+   }
+   }
+   return -1;
+}
+
 static int do_disk_guid(struct blk_desc *dev_desc, char * const namestr)
 {
int ret;
@@ -822,6 +903,10 @@ static int do_gpt(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
} else if ((strcmp(argv[1], "verify") == 0)) {
ret = gpt_verify(blk_dev_desc, argv[4]);
printf("Verify GPT: ");
+   } else if ((strcmp(argv[1], "setenv") == 0)) {
+   ret = gpt_setenv(blk_dev_desc, argv[4]);
+   } else if ((strcmp(argv[1], "enumerate") == 0)) {
+   ret = gpt_enumerate(blk_dev_desc);
} else if (strcmp(argv[1], "guid") == 0) {
ret = do_disk_guid(blk_dev_desc, argv[4]);
 #ifdef CONFIG_CMD_GPT_RENAME
@@ -852,7 +937,17 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" to interface\n"

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Peter Robinson]

>
> On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> > When needed, RPi4's co-processor (called VideoCore) has to be instructed
> > to load VL805's firmware (the chip providing xHCI support). VideoCore's
> > firmware expects the board's PCIe bus to be already configured in order
> > for it to load the xHCI chip firmware. So we have to make sure this
> > happens in between the PCIe configuration and xHCI startup.
> >
> > Introduce a callback in xhci_pci_probe() to run this platform specific
> > routine.
> >
> > Signed-off-by: Nicolas Saenz Julienne 
> >
> > ---
> >
> > Changes since v1:
> >  - Create callback
> >
> >  board/raspberrypi/rpi/rpi.c | 12 
> >  drivers/usb/host/xhci-pci.c |  6 ++
> >  include/usb/xhci.h  |  3 +++
> >  3 files changed, 21 insertions(+)
> >
> > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> > index e367ba3092..8aa78d1f48 100644
> > --- a/board/raspberrypi/rpi/rpi.c
> > +++ b/board/raspberrypi/rpi/rpi.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> >
> >   return 0;
> >  }
> > +
> > +#ifdef CONFIG_BCM2711
>
> This won't work with rpi_arm64_defconfig.
> Can't we just evaluate at runtime if we need to do anything in xhci_pci_fixup.
>
> I wonder if the newer RPi4 have also a newer revision ID (see get_board_rev). 
> If
> so we could add another bool to struct rpi_model which will indicate us if we
> need to notify VideoCore about vl805's firmware.

I believe they're ones ending in 03112:
https://github.com/raspberrypi/documentation/tree/master/hardware/raspberrypi/revision-codes

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Nicolas Saenz Julienne]

Hi Matthias,

On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
> 
> On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> > When needed, RPi4's co-processor (called VideoCore) has to be instructed
> > to load VL805's firmware (the chip providing xHCI support). VideoCore's
> > firmware expects the board's PCIe bus to be already configured in order
> > for it to load the xHCI chip firmware. So we have to make sure this
> > happens in between the PCIe configuration and xHCI startup.
> > 
> > Introduce a callback in xhci_pci_probe() to run this platform specific
> > routine.
> > 
> > Signed-off-by: Nicolas Saenz Julienne 
> > 
> > ---
> > 
> > Changes since v1:
> >  - Create callback
> > 
> >  board/raspberrypi/rpi/rpi.c | 12 
> >  drivers/usb/host/xhci-pci.c |  6 ++
> >  include/usb/xhci.h  |  3 +++
> >  3 files changed, 21 insertions(+)
> > 
> > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> > index e367ba3092..8aa78d1f48 100644
> > --- a/board/raspberrypi/rpi/rpi.c
> > +++ b/board/raspberrypi/rpi/rpi.c
> > @@ -14,6 +14,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> >  
> > return 0;
> >  }
> > +
> > +#ifdef CONFIG_BCM2711
> 
> This won't work with rpi_arm64_defconfig.
> Can't we just evaluate at runtime if we need to do anything in xhci_pci_fixup.

I can't see why, who is going to call xhci_pci_probe() in RPi3?

Regards,
Nicolas

> I wonder if the newer RPi4 have also a newer revision ID (see get_board_rev).
> If
> so we could add another bool to struct rpi_model which will indicate us if we
> need to notify VideoCore about vl805's firmware.
> 
> > +void xhci_pci_fixup(struct udevice *dev)
> > +{
> > +   int ret;
> > +
> > +   ret = bcm2711_notify_vl805_reset();
> > +   if (ret)
> > +   printf("RPI: Failed to notify VideoCore about vl805's
> > firmware\n");
> > +}
> > +#endif
> > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > index c1f60da541..1285dde1ef 100644
> > --- a/drivers/usb/host/xhci-pci.c
> > +++ b/drivers/usb/host/xhci-pci.c
> > @@ -11,6 +11,10 @@
> >  #include 
> >  #include 
> >  
> > +__weak void xhci_pci_fixup(struct udevice *dev)
> > +{
> > +}
> > +
> >  static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
> >   struct xhci_hcor **ret_hcor)
> >  {
> > @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
> > struct xhci_hccr *hccr;
> > struct xhci_hcor *hcor;
> >  
> > +   xhci_pci_fixup(dev);
> > +
> > xhci_pci_init(dev, &hccr, &hcor);
> >  
> > return xhci_register(dev, hccr, hcor);
> > diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> > index c16106a2fc..57feed7603 100644
> > --- a/include/usb/xhci.h
> > +++ b/include/usb/xhci.h
> > @@ -16,6 +16,7 @@
> >  #ifndef HOST_XHCI_H_
> >  #define HOST_XHCI_H_
> >  
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
> >  
> >  struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
> >  
> > +extern void xhci_pci_fixup(struct udevice *dev);
> > +
> >  #endif /* HOST_XHCI_H_ */
> > 



signature.asc
Description: This is a digitally signed message part

[RFC] arm: dts: imx: imx8qm: usb support

[Oliver Graute]

Try to get USB working with imx8qm. Therefore I took below from NXP
vendor tree. Can someone point me to the missing driver parts that are
needed?

Best regards,

Oliver

---
 arch/arm/dts/fsl-imx8qm.dtsi | 71 
 1 file changed, 71 insertions(+)

diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
index 6808f68f9d..87c3bb2257 100644
--- a/arch/arm/dts/fsl-imx8qm.dtsi
+++ b/arch/arm/dts/fsl-imx8qm.dtsi
@@ -40,6 +40,10 @@
i2c1 = &i2c1;
i2c2 = &i2c2;
i2c3 = &i2c3;
+   usb0 = &usbotg1;
+   usbphy0 = &usbphy1;
+   usb1 = &usb2;
+   usbphy1 = &usb2_phy;
i2c4 = &i2c4;
};
 
@@ -142,6 +146,33 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   pd_conn_usbotg0: PD_CONN_USB_0 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_conn>;
+   };
+
+   pd_conn_usbotg0_phy: PD_CONN_USB_0_PHY {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_conn>;
+   };
+
+   pd_conn_usbotg1: PD_CONN_USB_1 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_conn>;
+   };
+   pd_conn_usb2: PD_CONN_USB_2 {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_conn>;
+   };
+   pd_conn_usb2_phy: PD_CONN_USB_2_PHY {
+   reg = ;
+   #power-domain-cells = <0>;
+   power-domains = <&pd_conn>;
+   };
pd_conn_sdch0: PD_CONN_SDHC_0 {
reg = ;
#power-domain-cells = <0>;
@@ -555,6 +586,46 @@
power-domains = <&pd_conn_enet1>;
status = "disabled";
};
+
+   usbmisc1: usbmisc@5b0d0200 {
+   #index-cells = <1>;
+   compatible = "fsl,imx7d-usbmisc", "fsl,imx6q-usbmisc";
+   reg = <0x0 0x5b0d0200 0x0 0x200>;
+   };
+
+   usbphy1: usbphy@0x5b10 {
+   compatible = "fsl,imx8qm-usbphy", "fsl,imx7ulp-usbphy", 
"fsl,imx6ul-usbphy", "fsl,imx23-usbphy";
+   reg = <0x0 0x5b10 0x0 0x200>;
+   clocks = <&clk IMX8QM_USB2_PHY_IPG_CLK>;
+   power-domains = <&pd_conn_usbotg0_phy>;
+   };
+
+   usbotg1: usb@5b0d {
+   compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
+   reg = <0x0 0x5b0d 0x0 0x200>;
+   interrupts = ;
+   fsl,usbphy = <&usbphy1>;
+   fsl,usbmisc = <&usbmisc1 0>;
+   clocks = <&clk IMX8QM_USB2_OH_AHB_CLK>;
+   phy-clkgate-delay-us = <400>;
+   status = "disabled";
+   #stream-id-cells = <1>;
+   power-domains = <&pd_conn_usbotg0>;
+   };
+
+   usb2_phy: phy@0x5b16 {
+   compatible = "fsl,imx8-usb-phy";
+   reg = <0x0 0x5b16 0x0 0x1>;
+   power-domains = <&pd_conn_usb2_phy>;
+   };
+
+   usb2: usb@0x5b11 {
+   compatible = "fsl,imx8-usb3";
+   reg = <0x0 0x5b11 0x0 0x38000>;
+   fsl,usbphy = <&usb2_phy>;
+   status = "disabled";
+   power-domains = <&pd_conn_usb2>;
+   };
 };
 
 &A53_0 {
-- 
2.17.1

RE: [RFC] arm: dts: imx: imx8qm: usb support

[Peng Fan]

> Subject: [RFC] arm: dts: imx: imx8qm: usb support
> 
> Try to get USB working with imx8qm. Therefore I took below from NXP vendor
> tree. Can someone point me to the missing driver parts that are needed?

The usb driver still not enabled.

Regards,
Peng.

> 
> Best regards,
> 
> Oliver
> 
> ---
>  arch/arm/dts/fsl-imx8qm.dtsi | 71
> 
>  1 file changed, 71 insertions(+)
> 
> diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
> index 6808f68f9d..87c3bb2257 100644
> --- a/arch/arm/dts/fsl-imx8qm.dtsi
> +++ b/arch/arm/dts/fsl-imx8qm.dtsi
> @@ -40,6 +40,10 @@
>   i2c1 = &i2c1;
>   i2c2 = &i2c2;
>   i2c3 = &i2c3;
> + usb0 = &usbotg1;
> + usbphy0 = &usbphy1;
> + usb1 = &usb2;
> + usbphy1 = &usb2_phy;
>   i2c4 = &i2c4;
>   };
> 
> @@ -142,6 +146,33 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
> + pd_conn_usbotg0: PD_CONN_USB_0 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_conn>;
> + };
> +
> + pd_conn_usbotg0_phy: PD_CONN_USB_0_PHY {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_conn>;
> + };
> +
> + pd_conn_usbotg1: PD_CONN_USB_1 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_conn>;
> + };
> + pd_conn_usb2: PD_CONN_USB_2 {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_conn>;
> + };
> + pd_conn_usb2_phy: PD_CONN_USB_2_PHY {
> + reg = ;
> + #power-domain-cells = <0>;
> + power-domains = <&pd_conn>;
> + };
>   pd_conn_sdch0: PD_CONN_SDHC_0 {
>   reg = ;
>   #power-domain-cells = <0>;
> @@ -555,6 +586,46 @@
>   power-domains = <&pd_conn_enet1>;
>   status = "disabled";
>   };
> +
> + usbmisc1: usbmisc@5b0d0200 {
> + #index-cells = <1>;
> + compatible = "fsl,imx7d-usbmisc", "fsl,imx6q-usbmisc";
> + reg = <0x0 0x5b0d0200 0x0 0x200>;
> + };
> +
> + usbphy1: usbphy@0x5b10 {
> + compatible = "fsl,imx8qm-usbphy", "fsl,imx7ulp-usbphy",
> "fsl,imx6ul-usbphy", "fsl,imx23-usbphy";
> + reg = <0x0 0x5b10 0x0 0x200>;
> + clocks = <&clk IMX8QM_USB2_PHY_IPG_CLK>;
> + power-domains = <&pd_conn_usbotg0_phy>;
> + };
> +
> + usbotg1: usb@5b0d {
> + compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
> + reg = <0x0 0x5b0d 0x0 0x200>;
> + interrupts = ;
> + fsl,usbphy = <&usbphy1>;
> + fsl,usbmisc = <&usbmisc1 0>;
> + clocks = <&clk IMX8QM_USB2_OH_AHB_CLK>;
> + phy-clkgate-delay-us = <400>;
> + status = "disabled";
> + #stream-id-cells = <1>;
> + power-domains = <&pd_conn_usbotg0>;
> + };
> +
> + usb2_phy: phy@0x5b16 {
> + compatible = "fsl,imx8-usb-phy";
> + reg = <0x0 0x5b16 0x0 0x1>;
> + power-domains = <&pd_conn_usb2_phy>;
> + };
> +
> + usb2: usb@0x5b11 {
> + compatible = "fsl,imx8-usb3";
> + reg = <0x0 0x5b11 0x0 0x38000>;
> + fsl,usbphy = <&usb2_phy>;
> + status = "disabled";
> + power-domains = <&pd_conn_usb2>;
> + };
>  };
> 
>  &A53_0 {
> --
> 2.17.1

Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data

[Alex Kiernan]

On Mon, May 4, 2020 at 12:28 PM Tom Rini  wrote:
>
> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote:
>
> > There is no reason to tail-pad fitImage with external data to 4-bytes,
> > while fitImage without external data does not have any such padding and
> > is often unaligned. DT spec also does not mandate any such padding.
> >
> > Moreover, the tail-pad fills the last few bytes with uninitialized data,
> > which could lead to a potential information leak.
> >
> > $ echo -n xy > /tmp/data ; \
> >   ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \
> >   hexdump -vC /tmp/fitImage | tail -n 3
> >
> > before:
> > 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
> > |a-offset.data-si|
> > 0270  7a 65 00 00 78 79 64 64   |ze..xydd|
> >^^   ^^ ^^
> > after:
> > 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
> > |a-offset.data-si|
> > 0270  7a 65 00 78 79|ze.xy|
> >
> > Signed-off-by: Marek Vasut 
> > Reviewed-by: Simon Glass 
> > Cc: Heinrich Schuchardt 
> > Cc: Tom Rini 
>
> Applied to u-boot/master, thanks!
>

This breaks booting on my board (am3352, eMMC boot, FIT u-boot,
CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it
from eMMC I get nothing at all on the console, if I boot over ymodem
it stalls at 420k, before continuing to 460k. My guess is there's some
error going to the console at the 420k mark, but obviously it's lost
in the ymodem... I have two DTBs in the FIT image, 420k would about
align to the point between them.

-- 
Alex Kiernan

Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data

[Marek Vasut]

On 5/5/20 3:22 PM, Alex Kiernan wrote:
> On Mon, May 4, 2020 at 12:28 PM Tom Rini  wrote:
>>
>> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote:
>>
>>> There is no reason to tail-pad fitImage with external data to 4-bytes,
>>> while fitImage without external data does not have any such padding and
>>> is often unaligned. DT spec also does not mandate any such padding.
>>>
>>> Moreover, the tail-pad fills the last few bytes with uninitialized data,
>>> which could lead to a potential information leak.
>>>
>>> $ echo -n xy > /tmp/data ; \
>>>   ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \
>>>   hexdump -vC /tmp/fitImage | tail -n 3
>>>
>>> before:
>>> 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
>>> |a-offset.data-si|
>>> 0270  7a 65 00 00 78 79 64 64   |ze..xydd|
>>>^^   ^^ ^^
>>> after:
>>> 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
>>> |a-offset.data-si|
>>> 0270  7a 65 00 78 79|ze.xy|
>>>
>>> Signed-off-by: Marek Vasut 
>>> Reviewed-by: Simon Glass 
>>> Cc: Heinrich Schuchardt 
>>> Cc: Tom Rini 
>>
>> Applied to u-boot/master, thanks!
>>
> 
> This breaks booting on my board (am3352, eMMC boot, FIT u-boot,
> CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it
> from eMMC I get nothing at all on the console, if I boot over ymodem
> it stalls at 420k, before continuing to 460k. My guess is there's some
> error going to the console at the 420k mark, but obviously it's lost
> in the ymodem... I have two DTBs in the FIT image, 420k would about
> align to the point between them.

My bet would be on some padding / unaligned access problem that this
patch uncovered. Can you take a look ?

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Matthias Brugger]

On 05/05/2020 14:53, Nicolas Saenz Julienne wrote:
> Hi Matthias,
> 
> On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
>>
>> On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
>>> When needed, RPi4's co-processor (called VideoCore) has to be instructed
>>> to load VL805's firmware (the chip providing xHCI support). VideoCore's
>>> firmware expects the board's PCIe bus to be already configured in order
>>> for it to load the xHCI chip firmware. So we have to make sure this
>>> happens in between the PCIe configuration and xHCI startup.
>>>
>>> Introduce a callback in xhci_pci_probe() to run this platform specific
>>> routine.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne 
>>>
>>> ---
>>>
>>> Changes since v1:
>>>  - Create callback
>>>
>>>  board/raspberrypi/rpi/rpi.c | 12 
>>>  drivers/usb/host/xhci-pci.c |  6 ++
>>>  include/usb/xhci.h  |  3 +++
>>>  3 files changed, 21 insertions(+)
>>>
>>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>>> index e367ba3092..8aa78d1f48 100644
>>> --- a/board/raspberrypi/rpi/rpi.c
>>> +++ b/board/raspberrypi/rpi/rpi.c
>>> @@ -14,6 +14,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
>>>  
>>> return 0;
>>>  }
>>> +
>>> +#ifdef CONFIG_BCM2711
>>
>> This won't work with rpi_arm64_defconfig.
>> Can't we just evaluate at runtime if we need to do anything in 
>> xhci_pci_fixup.
> 
> I can't see why, who is going to call xhci_pci_probe() in RPi3?
> 

If you do make rpi_arm64_defconfig and inspect the .config, you will see that
CONFIG_BCM2711 is not defined, so this code won't be called on RPi4.

Regards,
Matthias

> Regards,
> Nicolas
> 
>> I wonder if the newer RPi4 have also a newer revision ID (see get_board_rev).
>> If
>> so we could add another bool to struct rpi_model which will indicate us if we
>> need to notify VideoCore about vl805's firmware.
>>
>>> +void xhci_pci_fixup(struct udevice *dev)
>>> +{
>>> +   int ret;
>>> +
>>> +   ret = bcm2711_notify_vl805_reset();
>>> +   if (ret)
>>> +   printf("RPI: Failed to notify VideoCore about vl805's
>>> firmware\n");
>>> +}
>>> +#endif
>>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>>> index c1f60da541..1285dde1ef 100644
>>> --- a/drivers/usb/host/xhci-pci.c
>>> +++ b/drivers/usb/host/xhci-pci.c
>>> @@ -11,6 +11,10 @@
>>>  #include 
>>>  #include 
>>>  
>>> +__weak void xhci_pci_fixup(struct udevice *dev)
>>> +{
>>> +}
>>> +
>>>  static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
>>>   struct xhci_hcor **ret_hcor)
>>>  {
>>> @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
>>> struct xhci_hccr *hccr;
>>> struct xhci_hcor *hcor;
>>>  
>>> +   xhci_pci_fixup(dev);
>>> +
>>> xhci_pci_init(dev, &hccr, &hcor);
>>>  
>>> return xhci_register(dev, hccr, hcor);
>>> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
>>> index c16106a2fc..57feed7603 100644
>>> --- a/include/usb/xhci.h
>>> +++ b/include/usb/xhci.h
>>> @@ -16,6 +16,7 @@
>>>  #ifndef HOST_XHCI_H_
>>>  #define HOST_XHCI_H_
>>>  
>>> +#include 
>>>  #include 
>>>  #include 
>>>  #include 
>>> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
>>>  
>>>  struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
>>>  
>>> +extern void xhci_pci_fixup(struct udevice *dev);
>>> +
>>>  #endif /* HOST_XHCI_H_ */
>>>
> 

[PATCH 0/6] imx: nandbcb update

[Peng Fan]

i.MX nandbcb update to support i.MX8M, add dump command, restructure,
fix gf_14, add boot search count for i.MX8

Alice Guo (3):
  nandbcb: support i.MX8M
  nandbcb: add nandbcb dump command for i.MX8MM
  nandbcb: add nandbcb dump command for i.MX6

Han Xu (3):
  nandbcb: fix the issue cannot support gf_14 NAND boot
  cmd: nandbcb: Reconstruct the nandbcb tool for all platforms
  nandbcb: read boot search count from fuse for imx8qxp

 arch/arm/include/asm/mach-imx/imx-nandbcb.h |4 +-
 arch/arm/mach-imx/Kconfig   |2 +-
 arch/arm/mach-imx/cmd_nandbcb.c | 1241 +++
 3 files changed, 1094 insertions(+), 153 deletions(-)

-- 
2.16.4

[PATCH 1/6] nandbcb: fix the issue cannot support gf_14 NAND boot

[Peng Fan]

From: Han Xu 

bchtype in FCB should be associated to the gf_13/14 settings in BCH, fix
the issue and test on Micron 29F64G08CBABB, it can boot after the
change.

Signed-off-by: Han Xu 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/cmd_nandbcb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index b3e59b1b00..103c3d6a08 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -154,6 +154,7 @@ static void fill_fcb(struct fcb_block *fcb, struct mtd_info 
*mtd,
fcb->ecc_level = l.ecc0;
fcb->ecc_size = l.datan_size;
fcb->ecc_type = l.eccn;
+   fcb->bchtype = l.gf_len;
 
/* Also hardcoded in kobs-ng */
if (is_mx6()) {
-- 
2.16.4

[PATCH 2/6] nandbcb: support i.MX8M

[Peng Fan]

From: Alice Guo 

Tested on i.MX8MM EVK, imx8mm evk uses BCH
encoding and randomizer
modify macro and print size_t with %zx
use CONFIG_IMX8M because it should apply to imx8mq/mm/mn

Signed-off-by: Alice Guo 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/Kconfig   |  2 +-
 arch/arm/mach-imx/cmd_nandbcb.c | 88 +++--
 2 files changed, 68 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 2b97208445..6c3fedf665 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -89,7 +89,7 @@ config CMD_NANDBCB
bool "i.MX6 NAND Boot Control Block(BCB) command"
depends on MTD_RAW_NAND && CMD_MTDPARTS
select BCH if MX6UL || MX6ULL
-   default y if (ARCH_MX6 && NAND_MXS) || (ARCH_MX7 && NAND_MXS)
+   default y if ((ARCH_MX6 || ARCH_MX7 || ARCH_IMX8M) && NAND_MXS)
help
  Unlike normal 'nand write/erase' commands, this command update
  Boot Control Block(BCB) for i.MX6 platform NAND IP's.
diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index 103c3d6a08..682f5064e6 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -30,6 +30,8 @@
 
 #define BF_VAL(v, bf)  (((v) & bf##_MASK) >> bf##_OFFSET)
 #define GETBIT(v, n)   (((v) >> (n)) & 0x1)
+#define IMX8MQ_SPL_SZ 0x3e000
+#define IMX8MQ_HDMI_FW_SZ 0x19c00
 
 #if defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
 static uint8_t reverse_bit(uint8_t b)
@@ -157,7 +159,7 @@ static void fill_fcb(struct fcb_block *fcb, struct mtd_info 
*mtd,
fcb->bchtype = l.gf_len;
 
/* Also hardcoded in kobs-ng */
-   if (is_mx6()) {
+   if (is_mx6() || is_imx8m()) {
fcb->datasetup = 80;
fcb->datahold = 60;
fcb->addr_setup = 25;
@@ -260,11 +262,11 @@ static int write_fcb_dbbt(struct mtd_info *mtd, struct 
fcb_block *fcb,
/*
 * User BCH ECC hardware module for i.MX7
 */
-   if (is_mx7()) {
+   if (is_mx7() || is_imx8m()) {
u32 off = i * mtd->erasesize;
size_t rwsize = sizeof(*fcb);
 
-   printf("Writing %d bytes to 0x%x: ", rwsize, off);
+   printf("Writing %zd bytes to 0x%x: ", rwsize, off);
 
/* switch nand BCH to FCB compatible settings */
mxs_nand_mode_fcb(mtd);
@@ -287,7 +289,7 @@ static int write_fcb_dbbt(struct mtd_info *mtd, struct 
fcb_block *fcb,
ret = mtd_write_oob(mtd, mtd->erasesize * i, &ops);
if (ret)
goto fcb_raw_page_err;
-   debug("NAND fcb write: 0x%x offset 0x%x written: %s\n",
+   debug("NAND fcb write: 0x%x offset 0x%zx written: %s\n",
  mtd->erasesize * i, ops.len, ret ?
  "ERROR" : "OK");
}
@@ -296,7 +298,7 @@ static int write_fcb_dbbt(struct mtd_info *mtd, struct 
fcb_block *fcb,
mtd->writesize, &dummy, (void *)dbbt);
if (ret)
goto fcb_raw_page_err;
-   debug("NAND dbbt write: 0x%x offset, 0x%x bytes written: %s\n",
+   debug("NAND dbbt write: 0x%x offset, 0x%zx bytes written: %s\n",
  mtd->erasesize * i + mtd->writesize, dummy,
  ret ? "ERROR" : "OK");
 
@@ -330,6 +332,9 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t off, 
size_t size,
int nr_blks, nr_blks_fcb, fw1_blk;
size_t fwsize;
int ret;
+   size_t extra_fwsize;
+   void *extra_fwbuf;
+   loff_t extra_fw1_off;
 
/* erase */
memset(&opts, 0, sizeof(opts));
@@ -366,23 +371,62 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t 
off, size_t size,
fw1_blk = nr_blks_fcb;
 
/* write fw */
-   fwsize = ALIGN(size + FLASH_OFFSET_STANDARD + mtd->writesize,
-  mtd->writesize);
-   fwbuf = kzalloc(fwsize, GFP_KERNEL);
-   if (!fwbuf) {
-   debug("failed to allocate fwbuf\n");
-   ret = -ENOMEM;
-   goto err;
-   }
+   fwbuf = NULL;
+   if (is_mx6() || is_mx7()) {
+   fwsize = ALIGN(size + FLASH_OFFSET_STANDARD + mtd->writesize,
+  mtd->writesize);
+   fwbuf = kzalloc(fwsize, GFP_KERNEL);
+   if (!fwbuf) {
+   debug("failed to allocate fwbuf\n");
+   ret = -ENOMEM;
+   goto err;
+   }
 
-   memcpy(fwbuf + FLASH_OFFSET_STANDARD, buf, size);
-   fw1_off = fw1_blk * mtd->erasesize;
-   ret = nand_write_skip_bad(mtd, fw1_off, &fwsize, NULL, maxsize,
- (u_char *)

[PATCH 6/6] nandbcb: read boot search count from fuse for imx8qxp

[Peng Fan]

From: Han Xu 

add support for imx8qxp to read boot search count from fuse in nandbcb

Signed-off-by: Han Xu 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/cmd_nandbcb.c | 39 ++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index ab12b1f1cf..94cae146ce 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../../cmd/legacy-mtd-utils.h"
 
@@ -1260,6 +1261,35 @@ static bool check_fingerprint(void *data, int 
fingerprint)
return (*(int *)(data + off) == fingerprint);
 }
 
+static int fuse_to_search_count(u32 bank, u32 word, u32 mask, u32 off)
+{
+   int err;
+   u32 val;
+   int ret;
+
+   /* by default, the boot search count from fuse should be 2 */
+   err = fuse_read(bank, word, &val);
+   if (err)
+   return 2;
+
+   val = (val & mask) >> off;
+
+   switch (val) {
+   case 0:
+   ret = 2;
+   break;
+   case 1:
+   case 2:
+   case 3:
+   ret = 1 << val;
+   break;
+   default:
+   ret = 2;
+   }
+
+   return ret;
+}
+
 static int nandbcb_dump(struct boot_config *boot_cfg)
 {
int i;
@@ -1459,7 +1489,14 @@ static int do_nandbcb(cmd_tbl_t *cmdtp, int flag, int 
argc,
return CMD_RET_FAILURE;
}
 
-   /* TODO: set the boot search count if need to read from fuse */
+   if (plat_config.misc_flags & BT_SEARCH_CNT_FROM_FUSE) {
+   if (is_imx8qxp()) {
+   g_boot_search_count = fuse_to_search_count(0, 720,
+  0xc0, 6);
+   printf("search count set to %d from fuse\n",
+  g_boot_search_count);
+   }
+   }
 
cmd = argv[1];
--argc;
-- 
2.16.4

[PATCH 4/6] nandbcb: add nandbcb dump command for i.MX6

[Peng Fan]

From: Alice Guo 

Verify/dump boot structures.

Signed-off-by: Alice Guo 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/cmd_nandbcb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index 02a65ffd43..a8531def35 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -309,6 +309,10 @@ static int write_fcb_dbbt_and_readback(struct mtd_info 
*mtd,
debug("NAND fcb write: 0x%x offset 0x%zx written: %s\n",
  mtd->erasesize * i, ops.len, ret ?
  "ERROR" : "OK");
+
+   ops.datbuf = (u8 *)(dump_nand_fcb + i);
+   ops.oobbuf = ((u8 *)(dump_nand_fcb + i)) + 
mtd->writesize;
+   mtd_read_oob(mtd, mtd->erasesize * i, &ops);
}
 
ret = mtd_write(mtd, mtd->erasesize * i + mtd->writesize,
-- 
2.16.4

[PATCH 3/6] nandbcb: add nandbcb dump command for i.MX8MM

[Peng Fan]

From: Alice Guo 

Verify/dump boot structures written to NAND Flash chip.

Signed-off-by: Alice Guo 
Signed-off-by: Peng Fan 
---
 arch/arm/mach-imx/cmd_nandbcb.c | 266 ++--
 1 file changed, 258 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index 682f5064e6..02a65ffd43 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../../cmd/legacy-mtd-utils.h"
 
@@ -32,6 +33,16 @@
 #define GETBIT(v, n)   (((v) >> (n)) & 0x1)
 #define IMX8MQ_SPL_SZ 0x3e000
 #define IMX8MQ_HDMI_FW_SZ 0x19c00
+#define BOOT_SEARCH_COUNT 2
+
+struct mtd_info *dump_mtd;
+static loff_t dump_nandboot_size;
+static struct fcb_block dump_fill_fcb;
+static struct dbbt_block dump_fill_dbbt;
+static struct fcb_block dump_nand_fcb[BOOT_SEARCH_COUNT];
+static struct dbbt_block dump_nand_dbbt[BOOT_SEARCH_COUNT];
+static u32 dump_fcb_off[BOOT_SEARCH_COUNT];
+static u32 dump_dbbt_off[BOOT_SEARCH_COUNT];
 
 #if defined(CONFIG_MX6UL) || defined(CONFIG_MX6ULL)
 static uint8_t reverse_bit(uint8_t b)
@@ -212,9 +223,10 @@ static int dbbt_fill_data(struct mtd_info *mtd, void *buf, 
int num_blocks)
return n_bad_blocks;
 }
 
-static int write_fcb_dbbt(struct mtd_info *mtd, struct fcb_block *fcb,
- struct dbbt_block *dbbt, void *dbbt_data_page,
- loff_t off)
+static int write_fcb_dbbt_and_readback(struct mtd_info *mtd,
+  struct fcb_block *fcb,
+  struct dbbt_block *dbbt,
+  void *dbbt_data_page, loff_t off)
 {
void *fcb_raw_page = 0;
int i, ret;
@@ -272,6 +284,11 @@ static int write_fcb_dbbt(struct mtd_info *mtd, struct 
fcb_block *fcb,
mxs_nand_mode_fcb(mtd);
ret = nand_write(mtd, off, &rwsize,
 (unsigned char *)fcb);
+
+   dump_fcb_off[i] = off;
+   nand_read(mtd, off, &rwsize,
+ (unsigned char *)(dump_nand_fcb + i));
+
mxs_nand_mode_normal(mtd);
 
printf("%s\n", ret ? "ERROR" : "OK");
@@ -302,6 +319,12 @@ static int write_fcb_dbbt(struct mtd_info *mtd, struct 
fcb_block *fcb,
  mtd->erasesize * i + mtd->writesize, dummy,
  ret ? "ERROR" : "OK");
 
+   dump_dbbt_off[i] = mtd->erasesize * i + mtd->writesize;
+   size_t rwsize = sizeof(*dbbt);
+
+   nand_read(mtd, dump_dbbt_off[i], &rwsize,
+ (unsigned char *)(dump_nand_dbbt + i));
+
/* dbbtpages == 0 if no bad blocks */
if (dbbt->dbbtpages > 0) {
loff_t to = (mtd->erasesize * i + mtd->writesize * 5);
@@ -366,7 +389,7 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t off, 
size_t size,
 * - rest split in half for primary and secondary firmware
 * - same firmware will write two times
 */
-   nr_blks_fcb = 2;
+   nr_blks_fcb = BOOT_SEARCH_COUNT;
nr_blks = maxsize / mtd->erasesize;
fw1_blk = nr_blks_fcb;
 
@@ -442,6 +465,8 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t off, 
size_t size,
fw1_pages = (IMX8MQ_SPL_SZ + (mtd->writesize - 1)) / 
mtd->writesize;
fill_fcb(fcb, mtd, fw1_start, 0, fw1_pages);
 
+   dump_fill_fcb = *fcb;
+
/* fill dbbt */
dbbt_page = kzalloc(mtd->writesize, GFP_KERNEL);
if (!dbbt_page) {
@@ -467,8 +492,10 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t 
off, size_t size,
else if (ret > 0)
dbbt->dbbtpages = 1;
 
+   dump_fill_dbbt = *dbbt;
+
/* write fcb and dbbt to nand */
-   ret = write_fcb_dbbt(mtd, fcb, dbbt, dbbt_data_page, off);
+   ret = write_fcb_dbbt_and_readback(mtd, fcb, dbbt, dbbt_data_page, off);
if (ret < 0)
printf("failed to write FCB/DBBT\n");
 
@@ -550,7 +577,7 @@ static int do_nandbcb_bcbonly(int argc, char * const argv[])
dbbt->dbbtpages = 1;
 
/* write fcb and dbbt to nand */
-   ret = write_fcb_dbbt(mtd, fcb, dbbt, dbbt_data_page, 0);
+   ret = write_fcb_dbbt_and_readback(mtd, fcb, dbbt, dbbt_data_page, 0);
 dbbt_data_page_err:
kfree(dbbt_data_page);
 dbbt_page_err:
@@ -566,6 +593,218 @@ fcb_err:
return CMD_RET_SUCCESS;
 }
 
+/* dump data which is planned to be encoded and written to NAND chip */
+void mtd_cfg_dump(void)
+{
+   u64 blocks;
+
+   printf("MTD CONFIG:\n");
+   printf("  %s = %d\n", "data_setup_time", dump_fill_fcb.datasetup);
+   printf("  %s = %d\n", "data_hold_time", dump_fill_fcb.datahold);
+   printf("  %s = %d\n", "address_setup_time", dump_fil

[PATCH 5/6] cmd: nandbcb: Reconstruct the nandbcb tool for all platforms

[Peng Fan]

From: Han Xu 

The original nandbcb tool was designed for imx6 only, when trying to
leverage it to replace the kobs-ng tool, we found the design is not
friendly for supporting all platforms. To support all iMX6/7/8 platforms
and for easy further maintain, I reconstruct the structure of the tool.

The main changes including:

1. Use platform_data to determine the logic branches rather than simply
   use SOC name.
2. More data structures as parameter for functions.
3. Global variables to define the FCB/DBBT/FW locations.
4. Implement the kobs-ng default 4 FCB/4 DBBT/2 FW layout.
5. Support Hamming coding/ 40bit BCH/ 62bit BCH coding FCB.
6. Dump and compare all written FCB/DBBT to verify data integrity.

The tool has been verified on iMX6Q/DL, 6SX, 7D, 6ULL, iMX8QX, iMX8MM.

Signed-off-by: Han Xu 
Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/mach-imx/imx-nandbcb.h |4 +-
 arch/arm/mach-imx/cmd_nandbcb.c | 1303 +++
 2 files changed, 955 insertions(+), 352 deletions(-)

diff --git a/arch/arm/include/asm/mach-imx/imx-nandbcb.h 
b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
index 907e7ed8f9..74c9031d4e 100644
--- a/arch/arm/include/asm/mach-imx/imx-nandbcb.h
+++ b/arch/arm/include/asm/mach-imx/imx-nandbcb.h
@@ -9,9 +9,11 @@
 
 #define FCB_FINGERPRINT0x20424346  /* 'FCB' */
 #define FCB_VERSION_1  0x0100
+#define FCB_FINGERPRINT_OFF0x4 /* FCB fingerprint offset*/
 
-#define DBBT_FINGERPRINT2  0x54424244  /* 'DBBT' */
+#define DBBT_FINGERPRINT   0x54424244  /* 'DBBT' */
 #define DBBT_VERSION_1 0x0100
+#define DBBT_FINGERPRINT_OFF   0x4 /* DBBT fingerprint offset*/
 
 struct dbbt_block {
u32 checksum;   /* reserved on i.MX6 */
diff --git a/arch/arm/mach-imx/cmd_nandbcb.c b/arch/arm/mach-imx/cmd_nandbcb.c
index a8531def35..ab12b1f1cf 100644
--- a/arch/arm/mach-imx/cmd_nandbcb.c
+++ b/arch/arm/mach-imx/cmd_nandbcb.c
@@ -1,11 +1,13 @@
 /*
- * i.MX6 nand boot control block(bcb).
+ * i.MX nand boot control block(bcb).
  *
  * Based on the common/imx-bbu-nand-fcb.c from barebox and imx kobs-ng
  *
  * Copyright (C) 2017 Jagan Teki 
  * Copyright (C) 2016 Sergey Kubushyn 
  *
+ * Reconstucted by Han Xu 
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
@@ -25,24 +27,295 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "../../../cmd/legacy-mtd-utils.h"
 
-#define BF_VAL(v, bf)  (((v) & bf##_MASK) >> bf##_OFFSET)
+/* FCB related flags */
+/* FCB layout with leading 12B reserved */
+#define FCB_LAYOUT_RESV_12BBIT(0)
+/* FCB layout with leading 32B meta data */
+#define FCB_LAYOUT_META_32BBIT(1)
+/* FCB encrypted by Hamming code */
+#define FCB_ENCODE_HAMMING BIT(2)
+/* FCB encrypted by 40bit BCH */
+#define FCB_ENCODE_BCH_40b BIT(3)
+/* FCB encrypted by 62bit BCH */
+#define FCB_ENCODE_BCH_62b BIT(4)
+/* FCB encrypted by BCH */
+#define FCB_ENCODE_BCH (FCB_ENCODE_BCH_40b | 
FCB_ENCODE_BCH_62b)
+/* FCB data was randomized */
+#define FCB_RANDON_ENABLED BIT(5)
+
+/* Firmware related flags */
+/* No 1K padding */
+#define FIRMWARE_NEED_PADDING  BIT(8)
+/* Extra firmware*/
+#define FIRMWARE_EXTRA_ONE BIT(9)
+/* Secondary firmware on fixed address */
+#define FIRMWARE_SECONDARY_FIXED_ADDR  BIT(10)
+
+/* Boot search related flags */
+#define BT_SEARCH_CNT_FROM_FUSEBIT(16)
+
+struct platform_config {
+   int misc_flags;
+};
+
+static struct platform_config plat_config;
+
+/* imx6q/dl/solo */
+static struct platform_config imx6qdl_plat_config = {
+   .misc_flags = FCB_LAYOUT_RESV_12B |
+FCB_ENCODE_HAMMING |
+FIRMWARE_NEED_PADDING,
+};
+
+static struct platform_config imx6sx_plat_config = {
+   .misc_flags = FCB_LAYOUT_META_32B |
+FCB_ENCODE_BCH_62b |
+FIRMWARE_NEED_PADDING |
+FCB_RANDON_ENABLED,
+};
+
+static struct platform_config imx7d_plat_config = {
+   .misc_flags = FCB_LAYOUT_META_32B |
+FCB_ENCODE_BCH_62b |
+FIRMWARE_NEED_PADDING |
+FCB_RANDON_ENABLED,
+};
+
+/* imx6ul/ull/ulz */
+static struct platform_config imx6ul_plat_config = {
+   .misc_flags = FCB_LAYOUT_META_32B |
+FCB_ENCODE_BCH_40b |
+FIRMWARE_NEED_PADDING,
+};
+
+static struct platform_config imx8mq_plat_config = {
+   .misc_flags = FCB_LAYOUT_META_32B |
+FCB_ENCODE_BCH_62b |
+FIRMWARE_NEED_PADDING |
+FCB_RANDON_ENABLED |
+FIRMWARE_EXTRA_ONE,
+};
+
+/* all other imx8mm */
+static struct platform_config imx8mm_plat_config = {
+   .misc_flags = FCB_LAYOUT_META_32B |
+FCB_ENCODE_BCH_62b |
+FIRMWARE_NEED_PADDING |
+FCB_RANDON_EN

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Nicolas Saenz Julienne]

On Tue, 2020-05-05 at 15:39 +0200, Matthias Brugger wrote:
> 
> On 05/05/2020 14:53, Nicolas Saenz Julienne wrote:
> > Hi Matthias,
> > 
> > On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
> > > On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> > > > When needed, RPi4's co-processor (called VideoCore) has to be instructed
> > > > to load VL805's firmware (the chip providing xHCI support). VideoCore's
> > > > firmware expects the board's PCIe bus to be already configured in order
> > > > for it to load the xHCI chip firmware. So we have to make sure this
> > > > happens in between the PCIe configuration and xHCI startup.
> > > > 
> > > > Introduce a callback in xhci_pci_probe() to run this platform specific
> > > > routine.
> > > > 
> > > > Signed-off-by: Nicolas Saenz Julienne 
> > > > 
> > > > ---
> > > > 
> > > > Changes since v1:
> > > >  - Create callback
> > > > 
> > > >  board/raspberrypi/rpi/rpi.c | 12 
> > > >  drivers/usb/host/xhci-pci.c |  6 ++
> > > >  include/usb/xhci.h  |  3 +++
> > > >  3 files changed, 21 insertions(+)
> > > > 
> > > > diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> > > > index e367ba3092..8aa78d1f48 100644
> > > > --- a/board/raspberrypi/rpi/rpi.c
> > > > +++ b/board/raspberrypi/rpi/rpi.c
> > > > @@ -14,6 +14,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
> > > >  
> > > > return 0;
> > > >  }
> > > > +
> > > > +#ifdef CONFIG_BCM2711
> > > 
> > > This won't work with rpi_arm64_defconfig.
> > > Can't we just evaluate at runtime if we need to do anything in
> > > xhci_pci_fixup.
> > 
> > I can't see why, who is going to call xhci_pci_probe() in RPi3?
> > 
> 
> If you do make rpi_arm64_defconfig and inspect the .config, you will see that
> CONFIG_BCM2711 is not defined, so this code won't be called on RPi4.

Oh! Understood.

Well, given that only xhci_pci_probe() is called if we're running on RPi4, I
think I can disregard those defines altogether. I'll double-check that.

Regards,
Nicolas

> Regards,
> Matthias
> 
> > Regards,
> > Nicolas
> > 
> > > I wonder if the newer RPi4 have also a newer revision ID (see
> > > get_board_rev).
> > > If
> > > so we could add another bool to struct rpi_model which will indicate us if
> > > we
> > > need to notify VideoCore about vl805's firmware.
> > > 
> > > > +void xhci_pci_fixup(struct udevice *dev)
> > > > +{
> > > > +   int ret;
> > > > +
> > > > +   ret = bcm2711_notify_vl805_reset();
> > > > +   if (ret)
> > > > +   printf("RPI: Failed to notify VideoCore about vl805's
> > > > firmware\n");
> > > > +}
> > > > +#endif
> > > > diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> > > > index c1f60da541..1285dde1ef 100644
> > > > --- a/drivers/usb/host/xhci-pci.c
> > > > +++ b/drivers/usb/host/xhci-pci.c
> > > > @@ -11,6 +11,10 @@
> > > >  #include 
> > > >  #include 
> > > >  
> > > > +__weak void xhci_pci_fixup(struct udevice *dev)
> > > > +{
> > > > +}
> > > > +
> > > >  static void xhci_pci_init(struct udevice *dev, struct xhci_hccr
> > > > **ret_hccr,
> > > >   struct xhci_hcor **ret_hcor)
> > > >  {
> > > > @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
> > > > struct xhci_hccr *hccr;
> > > > struct xhci_hcor *hcor;
> > > >  
> > > > +   xhci_pci_fixup(dev);
> > > > +
> > > > xhci_pci_init(dev, &hccr, &hcor);
> > > >  
> > > > return xhci_register(dev, hccr, hcor);
> > > > diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> > > > index c16106a2fc..57feed7603 100644
> > > > --- a/include/usb/xhci.h
> > > > +++ b/include/usb/xhci.h
> > > > @@ -16,6 +16,7 @@
> > > >  #ifndef HOST_XHCI_H_
> > > >  #define HOST_XHCI_H_
> > > >  
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
> > > >  
> > > >  struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
> > > >  
> > > > +extern void xhci_pci_fixup(struct udevice *dev);
> > > > +
> > > >  #endif /* HOST_XHCI_H_ */
> > > > 



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)

[Matthias Brugger]

On 04/05/2020 14:45, Sylwester Nawrocki wrote:
> From: Marek Szyprowski 
> 
> Create a non-cacheable mapping for the 0x6 physical memory region,
> where MMIO registers for the PCIe XHCI controller are instantiated by the
> PCIe bridge.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Sylwester Nawrocki 
> Reviewed-by: Nicolas Saenz Julienne 
> ---
> Changes since v1:
>  - none.
> ---
>  arch/arm/mach-bcm283x/init.c | 18 +++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 4295356..6a748da 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -11,10 +11,15 @@
>  #include 
>  #include 
>  
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS 0x6UL
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE 0x80UL
> +
>  #ifdef CONFIG_ARM64
>  #include 
>  
> -static struct mm_region bcm283x_mem_map[] = {
> +#define MAX_MAP_MAX_ENTRIES (4)

What stands the second 'MAX' for?

> +
> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>   {
>   .virt = 0xUL,
>   .phys = 0xUL,
> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>   }
>  };
>  
> -static struct mm_region bcm2711_mem_map[] = {
> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>   {
>   .virt = 0xUL,
>   .phys = 0xUL,
> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>PTE_BLOCK_NON_SHARE |
>PTE_BLOCK_PXN | PTE_BLOCK_UXN
>   }, {

I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_* defines.

> + .virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys = 
> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
> + .size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> +  PTE_BLOCK_NON_SHARE |
> +  PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
>   /* List terminator */
>   0,
>   }
> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>  {
>   int i;
>  
> - for (i = 0; i < 2; i++) {
> + for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {

Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
(plus list terminator). So we have an overflow here. I think we should just
define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
comment on the define naming above).

Regards,
Matthias

>   mem_map[i].virt = pd[i].virt;
>   mem_map[i].phys = pd[i].phys;
>   mem_map[i].size = pd[i].size;
> 

Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)

[Matthias Brugger]

On 05/05/2020 16:00, Matthias Brugger wrote:
> 
> 
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski 
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Sylwester Nawrocki 
>> Reviewed-by: Nicolas Saenz Julienne 
>> ---
>> Changes since v1:
>>  - none.
>> ---
>>  arch/arm/mach-bcm283x/init.c | 18 +++---
>>  1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 4295356..6a748da 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -11,10 +11,15 @@
>>  #include 
>>  #include 
>>  
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS0x6UL
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE0x80UL
>> +
>>  #ifdef CONFIG_ARM64
>>  #include 
>>  
>> -static struct mm_region bcm283x_mem_map[] = {
>> +#define MAX_MAP_MAX_ENTRIES (4)
> 
> What stands the second 'MAX' for?
> 
>> +
>> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>  {
>>  .virt = 0xUL,
>>  .phys = 0xUL,
>> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>>  }
>>  };
>>  
>> -static struct mm_region bcm2711_mem_map[] = {
>> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>  {
>>  .virt = 0xUL,
>>  .phys = 0xUL,
>> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>>   PTE_BLOCK_NON_SHARE |
>>   PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>  }, {
> 
> I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_* 
> defines.
> 

Ok, I see now you use the defines later on, forget my comment. It's ok as is.

Regards,
Matthias

>> +.virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys = 
>> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
>> +.size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
>> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>> + PTE_BLOCK_NON_SHARE |
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> +}, {
>>  /* List terminator */
>>  0,
>>  }
>> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>>  {
>>  int i;
>>  
>> -for (i = 0; i < 2; i++) {
>> +for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
> 
> Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
> (plus list terminator). So we have an overflow here. I think we should just
> define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
> comment on the define naming above).
> 
> Regards,
> Matthias
> 
>>  mem_map[i].virt = pd[i].virt;
>>  mem_map[i].phys = pd[i].phys;
>>  mem_map[i].size = pd[i].size;
>>

Re: [PATCH v2 00/10] USB host support for Raspberry Pi 4 board

[Nicolas Saenz Julienne]

On Mon, 2020-05-04 at 14:45 +0200, Sylwester Nawrocki wrote:
> Hi all,
> 
> This patch series adds USB host support for Raspberry Pi 4 board. 
> It includes the Broadcom STB PCIe controller driver ported from Linux 
> kernel, a memory mapping update for the xHCI controller on PCIe bus
> for 32-bit and 64-bit system builds and some related fixes and updates
> in the usb/xhci and the pci driver core code.
> 
> This iteration includes minor corrections in patches 7, 9, 10 addressing
> review comments.
> 
> The patch series is based on v2020.07-rc1 tree.
> 
> Thanks,
> Sylwester

I tested the whole series with rpi_4_defconfig and rpi_arm64_defconfig.

Tested-by: Nicolas Saenz Julienne 

Regards,
Nicolas

> Marek Szyprowski (4):
>   rpi4: shorten a mapping for the DRAM
>   rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM
> 64bit)
>   rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM
> 32bit)
>   config: Enable support for the XHCI controller on RPI4 board
> 
> Nicolas Saenz Julienne (1):
>   linux/bitfield.h: Add primitives for manipulating bitfields both in
> host- and fixed-endian
> 
> Sylwester Nawrocki (5):
>   usb: xhci: Add missing cache flush in the scratchpad array
> initialization
>   usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq
>   pci: Move some PCIe register offset definitions to a common header
>   pci: Add some PCI Express capability register offset definitions
>   pci: Add driver for Broadcom STB PCIe controller
> 
>  arch/arm/mach-bcm283x/Kconfig |   1 +
>  arch/arm/mach-bcm283x/include/mach/base.h |   7 +
>  arch/arm/mach-bcm283x/init.c  |  72 +++-
>  configs/rpi_4_32b_defconfig   |   9 +
>  configs/rpi_4_defconfig   |   9 +
>  configs/rpi_arm64_defconfig   |   8 +-
>  drivers/pci/Kconfig   |   6 +
>  drivers/pci/Makefile  |   1 +
>  drivers/pci/pci-rcar-gen3.c   |   8 -
>  drivers/pci/pcie_brcmstb.c| 594
> ++
>  drivers/pci/pcie_intel_fpga.c |   3 -
>  drivers/usb/host/xhci-mem.c   |   3 +
>  include/linux/bitfield.h  |  50 +++
>  include/pci.h |  19 +-
>  include/usb/xhci.h|   8 -
>  15 files changed, 772 insertions(+), 26 deletions(-)
>  create mode 100644 drivers/pci/pcie_brcmstb.c
> 



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)

[Marek Szyprowski]

Hi Matthias,

On 05.05.2020 16:00, Matthias Brugger wrote:
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski 
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Sylwester Nawrocki 
>> Reviewed-by: Nicolas Saenz Julienne 
>> ---
>> Changes since v1:
>>   - none.
>> ---
>>   arch/arm/mach-bcm283x/init.c | 18 +++---
>>   1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 4295356..6a748da 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -11,10 +11,15 @@
>>   #include 
>>   #include 
>>   
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS0x6UL
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE0x80UL
>> +
>>   #ifdef CONFIG_ARM64
>>   #include 
>>   
>> -static struct mm_region bcm283x_mem_map[] = {
>> +#define MAX_MAP_MAX_ENTRIES (4)
> What stands the second 'MAX' for?
a simple copy/paste issue. I will fix it.
>> +
>> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>  {
>>  .virt = 0xUL,
>>  .phys = 0xUL,
>> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>>  }
>>   };
>>   
>> -static struct mm_region bcm2711_mem_map[] = {
>> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>  {
>>  .virt = 0xUL,
>>  .phys = 0xUL,
>> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>>   PTE_BLOCK_NON_SHARE |
>>   PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>  }, {
> I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_* 
> defines.

Those defines are also used in ARM 32bit code.

>> +.virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys = 
>> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
>> +.size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
>> +.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>> + PTE_BLOCK_NON_SHARE |
>> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
>> +}, {
>>  /* List terminator */
>>  0,
>>  }
>> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>>   {
>>  int i;
>>   
>> -for (i = 0; i < 2; i++) {
>> +for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
> Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
> (plus list terminator). So we have an overflow here.
Nope, I've changed the bcm283x_mem_map to be large enough, see the above 
diff.
>   I think we should just
> define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
> comment on the define naming above).

That's exactly what I did.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH v2 05/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 64bit)

[Matthias Brugger]

On 05/05/2020 16:10, Marek Szyprowski wrote:
> Hi Matthias,
> 
> On 05.05.2020 16:00, Matthias Brugger wrote:
>> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>>> From: Marek Szyprowski 
>>>
>>> Create a non-cacheable mapping for the 0x6 physical memory region,
>>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>>> PCIe bridge.
>>>
>>> Signed-off-by: Marek Szyprowski 
>>> Signed-off-by: Sylwester Nawrocki 
>>> Reviewed-by: Nicolas Saenz Julienne 
>>> ---
>>> Changes since v1:
>>>   - none.
>>> ---
>>>   arch/arm/mach-bcm283x/init.c | 18 +++---
>>>   1 file changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>>> index 4295356..6a748da 100644
>>> --- a/arch/arm/mach-bcm283x/init.c
>>> +++ b/arch/arm/mach-bcm283x/init.c
>>> @@ -11,10 +11,15 @@
>>>   #include 
>>>   #include 
>>>   
>>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS   0x6UL
>>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE   0x80UL
>>> +
>>>   #ifdef CONFIG_ARM64
>>>   #include 
>>>   
>>> -static struct mm_region bcm283x_mem_map[] = {
>>> +#define MAX_MAP_MAX_ENTRIES (4)
>> What stands the second 'MAX' for?
> a simple copy/paste issue. I will fix it.
>>> +
>>> +static struct mm_region bcm283x_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>> {
>>> .virt = 0xUL,
>>> .phys = 0xUL,
>>> @@ -34,7 +39,7 @@ static struct mm_region bcm283x_mem_map[] = {
>>> }
>>>   };
>>>   
>>> -static struct mm_region bcm2711_mem_map[] = {
>>> +static struct mm_region bcm2711_mem_map[MAX_MAP_MAX_ENTRIES] = {
>>> {
>>> .virt = 0xUL,
>>> .phys = 0xUL,
>>> @@ -49,6 +54,13 @@ static struct mm_region bcm2711_mem_map[] = {
>>>  PTE_BLOCK_NON_SHARE |
>>>  PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>> }, {
>> I'd prefer a comment instead of using the BCM2711_RPI4_PCIE_XHCI_MMIO_* 
>> defines.
> 
> Those defines are also used in ARM 32bit code.
> 
>>> +   .virt = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS> + .phys = 
>>> BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS,
>>> +   .size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE,
>>> +   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
>>> +PTE_BLOCK_NON_SHARE |
>>> +PTE_BLOCK_PXN | PTE_BLOCK_UXN
>>> +   }, {
>>> /* List terminator */
>>> 0,
>>> }
>>> @@ -71,7 +83,7 @@ static void _rpi_update_mem_map(struct mm_region *pd)
>>>   {
>>> int i;
>>>   
>>> -   for (i = 0; i < 2; i++) {
>>> +   for (i = 0; i < MAX_MAP_MAX_ENTRIES; i++) {
>> Variable mem_map points to bcm283x_mem_map which only holds two mm_region's
>> (plus list terminator). So we have an overflow here.
> Nope, I've changed the bcm283x_mem_map to be large enough, see the above 
> diff.
>>   I think we should just
>> define bcm2711_mem_map and bcm283x_mem_map with a fixed array size of 4 (see
>> comment on the define naming above).
> 
> That's exactly what I did.
> 

You are right, sorry for the noise!

Matthias

Re: [PATCH v2 09/10] pci: Add driver for Broadcom STB PCIe controller

[Nicolas Saenz Julienne]

On Mon, 2020-05-04 at 14:45 +0200, Sylwester Nawrocki wrote:
> This patch adds basic driver for the Broadcom STB PCIe host controller.
> The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
> handling removed. The inbound access memory region is not currently
> parsed from dma-ranges DT property and a fixed 4GB region is used.
> 
> The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
> USB Host Controller.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> Signed-off-by: Sylwester Nawrocki 

I don't know if it's a little redundant already having a Signed-off-by tag, but
if relevant you can add my:

Reviewed-by: Nicolas Saenz Julienne 

Regards,
Nicolas

> ---
> Changes since v1:
>  - fixed argument in brcm_pcie_set_ssc() function call
>  - changed rc_bar2_size assignment to value 0xC000, as in upstream
>devicetre
> Changes since RFC:
>  - reworked to align with current Linux mainline version and u-boot
>driver by Nicolas Saenz Julienne
> 
> brcmstb pcie
> ---
>  drivers/pci/Kconfig|   6 +
>  drivers/pci/Makefile   |   1 +
>  drivers/pci/pcie_brcmstb.c | 594
> +
>  3 files changed, 601 insertions(+)
>  create mode 100644 drivers/pci/pcie_brcmstb.c
> 
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index 437cd9a..056a021 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -197,4 +197,10 @@ config PCIE_MEDIATEK
> Say Y here if you want to enable Gen2 PCIe controller,
> which could be found on MT7623 SoC family.
>  
> +config PCI_BRCMSTB
> + bool "Broadcom STB PCIe controller"
> + depends on DM_PCI
> + depends on ARCH_BCM283X
> + help
> +   Say Y here if you want to enable Broadcom STB PCIe controller support.
>  endif
> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
> index c051ecc..3e53b1f 100644
> --- a/drivers/pci/Makefile
> +++ b/drivers/pci/Makefile
> @@ -43,3 +43,4 @@ obj-$(CONFIG_PCI_PHYTIUM) += pcie_phytium.o
>  obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o
>  obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o
>  obj-$(CONFIG_PCIE_MEDIATEK) += pcie_mediatek.o
> +obj-$(CONFIG_PCI_BRCMSTB) += pcie_brcmstb.o
> diff --git a/drivers/pci/pcie_brcmstb.c b/drivers/pci/pcie_brcmstb.c
> new file mode 100644
> index 000..c6ddf92
> --- /dev/null
> +++ b/drivers/pci/pcie_brcmstb.c
> @@ -0,0 +1,594 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Broadcom STB PCIe controller driver
> + *
> + * Copyright (C) 2020 Samsung Electronics Co., Ltd.
> + *
> + * Based on upstream Linux kernel driver:
> + * drivers/pci/controller/pcie-brcmstb.c
> + * Copyright (C) 2009 - 2017 Broadcom
> + *
> + * Based driver by Nicolas Saenz Julienne
> + * Copyright (C) 2020 Nicolas Saenz Julienne 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
> +#define BRCM_PCIE_CAP_REGS   0x00ac
> +
> +/* Broadcom STB PCIe Register Offsets */
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1  
> 0x0188
> +#define  PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK   
> 0xc
> +#define  PCIE_RC_CFG_VENDOR_SPCIFIC_REG1_LITTLE_ENDIAN   
> 0x0
> +
> +#define PCIE_RC_CFG_PRIV1_ID_VAL30x043c
> +#define  PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK   0xff
> +
> +#define PCIE_RC_DL_MDIO_ADDR 0x1100
> +#define PCIE_RC_DL_MDIO_WR_DATA  0x1104
> +#define PCIE_RC_DL_MDIO_RD_DATA  0x1108
> +
> +#define PCIE_MISC_MISC_CTRL  0x4008
> +#define  PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK  0x1000
> +#define  PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK   0x2000
> +#define  PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x30
> +#define  PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128  0x0
> +#define  PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK  0xf800
> +
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
> +#define PCIE_MEM_WIN0_LO(win)\
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + ((win) * 4)
> +
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
> +#define PCIE_MEM_WIN0_HI(win)\
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + ((win) * 4)
> +
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO  0x402c
> +#define  PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK   0x1f
> +
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO  0x4034
> +#define  PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK   0x1f
> +#define PCIE_MISC_RC_BAR2_CONFIG_HI  0x4038
> +
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO  0x403c
> +#define  PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK   0x1f
> +
> +#define PCIE_MISC_PCIE_STATUS0x4068
> +#def

Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Matthias Brugger]

On 04/05/2020 14:45, Sylwester Nawrocki wrote:
> From: Marek Szyprowski 
> 
> Create a non-cacheable mapping for the 0x6 physical memory region,
> where MMIO registers for the PCIe XHCI controller are instantiated by the
> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
> 
> Signed-off-by: Marek Szyprowski 
> Signed-off-by: Sylwester Nawrocki 
> ---
> Changes since v1:
>  - none.
> ---
>  arch/arm/mach-bcm283x/Kconfig |  1 +
>  arch/arm/mach-bcm283x/include/mach/base.h |  7 +
>  arch/arm/mach-bcm283x/init.c  | 52 
> +++
>  3 files changed, 60 insertions(+)
> 
> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
> index 00419bf..bcb7f1d 100644
> --- a/arch/arm/mach-bcm283x/Kconfig
> +++ b/arch/arm/mach-bcm283x/Kconfig
> @@ -36,6 +36,7 @@ config BCM2711_32B
>   select BCM2711
>   select ARMV7_LPAE
>   select CPU_V7A
> + select PHYS_64BIT
>  
>  config BCM2711_64B
>   bool "Broadcom BCM2711 SoC 64-bit support"
> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
> b/arch/arm/mach-bcm283x/include/mach/base.h
> index c4ae398..1d10dc9 100644
> --- a/arch/arm/mach-bcm283x/include/mach/base.h
> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
> @@ -6,6 +6,13 @@
>  #ifndef _BCM283x_BASE_H_
>  #define _BCM283x_BASE_H_
>  
> +#include 
> +
>  extern unsigned long rpi_bcm283x_base;
>  
> +#ifdef CONFIG_ARMV7_LPAE
> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
> +#endif
> +
>  #endif
> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
> index 6a748da..5d0d160 100644
> --- a/arch/arm/mach-bcm283x/init.c
> +++ b/arch/arm/mach-bcm283x/init.c
> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>  }
>  
>  #ifdef CONFIG_ARMV7_LPAE
> +
> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT 0xff80UL
> +
> +void *rpi4_phys_to_virt(phys_addr_t paddr)
> +{
> + if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
> + paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
> + BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
> + return (void *)(unsigned long)paddr;
> +}
> +
> +static void set_section_phys(unsigned int section, phys_addr_t phys,
> +  enum dcache_option option)
> +{
> + u64 *page_table = (u64 *)gd->arch.tlb_addr;
> + /* Need to set the access flag to not fault */
> + u64 value = TTB_SECT_AP | TTB_SECT_AF;
> +
> + /* Add the page offset */
> + value |= (phys);
> +
> + /* Add caching bits */
> + value |= option;
> +
> + /* Set PTE */
> + page_table[section] = value;
> +}
> +
> +static void rpi4_create_pcie_xhci_mapping(void)
> +{
> + unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
> + phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
> + unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
> +
> + while (size) {
> + set_section_phys(sect, phys_addr, DCACHE_OFF);
> + sect++;
> + phys_addr += MMU_SECTION_SIZE;
> + size -= MMU_SECTION_SIZE;
> + }

Why can't we reuse mmu_set_region_dcache_behaviour()?

> +}
> +
> +void arm_init_domains(void)
> +{
> + /*
> +  * Hijack this function to prepare a mappings for the PCIe MMIO
> +  * region for the XHCI controller on RPi4 board.
> +  * This code is called before enabling the MMU in ARM 32bit mode.
> +  */
> + rpi4_create_pcie_xhci_mapping();

I think this indirection is not necessary.

Regards,
Matthias

> +}
> +
>  void enable_caches(void)
>  {
>   dcache_enable();
> 

[PULL] u-boot-usb/master

[Marek Vasut]

The following changes since commit c693f212c5b0433b3a49a89d87cbff28bf78eb87:

  Merge branch '2020-05-01-master-imports' (2020-05-01 16:43:15 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-usb.git master

for you to fetch changes up to c01a7773a5e71322d3458f20560344ff475cd26c:

  MAINTAINERS: MediaTek: add USB related files (2020-05-02 12:32:28 +0200)


Chunfeng Yun (14):
  dm: core: Add function to get child count of ofnode or device
  test: dm: add test item for ofnode_get_child_count()
  phy: Add API for a bulk of phys
  test: dm: phy: add a test item for the phy_bulk API
  usb: dwc3: use the phy bulk API to get phys
  usb: dwc2_udc_otg: use the phy bulk API to get phys
  phy: phy-mtk-tphy: add support USB phys
  phy: phy-mtk-tphy: add support new version
  phy: phy-mtk-tphy: add a new reference clock
  xhci: mediatek: Add support for MTK xHCI host controller
  arm: dts: mt7629: add usb related nodes
  dt-bindings: phy-mtk-tphy: add properties of address mapping and
clocks
  dt-bindings: usb: mtk-xhci: Add binding for MediaTek xHCI host
controller
  MAINTAINERS: MediaTek: add USB related files

 MAINTAINERS|   3 +
 arch/arm/dts/mt7629-rfb.dts|   8 +++
 arch/arm/dts/mt7629.dtsi   |  41 +++
 arch/sandbox/dts/test.dts  |  29 
 doc/device-tree-bindings/phy/phy-mtk-tphy.txt  |  78
+---
 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt |  40 +++
 drivers/core/ofnode.c  |  11 +++
 drivers/core/read.c|   5 ++
 drivers/phy/phy-mtk-tphy.c | 316
+-
 drivers/phy/phy-uclass.c   |  97
+
 drivers/usb/dwc3/core.c|  87
+--
 drivers/usb/dwc3/dwc3-generic.c|   7 +-
 drivers/usb/gadget/dwc2_udc_otg.c  |  93
+---
 drivers/usb/host/Kconfig   |   6 ++
 drivers/usb/host/Makefile  |   1 +
 drivers/usb/host/xhci-dwc3.c   |   7 +-
 drivers/usb/host/xhci-mtk.c| 303
++
 drivers/usb/host/xhci.c|  10 +++
 include/dm/ofnode.h|   8 +++
 include/dm/read.h  |  13 
 include/dwc3-uboot.h   |  11 ++-
 include/generic-phy.h  |  92

 include/usb/xhci.h |   3 +
 test/dm/ofnode.c   |  21 ++
 test/dm/phy.c  |  33 +
 25 files changed, 1135 insertions(+), 188 deletions(-)
 create mode 100644 doc/device-tree-bindings/usb/mediatek,mtk-xhci.txt
 create mode 100644 drivers/usb/host/xhci-mtk.c

Re: [PATCH v2 06/10] rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM 32bit)

[Marek Szyprowski]

Hi Matthias,

On 05.05.2020 16:25, Matthias Brugger wrote:
> On 04/05/2020 14:45, Sylwester Nawrocki wrote:
>> From: Marek Szyprowski 
>>
>> Create a non-cacheable mapping for the 0x6 physical memory region,
>> where MMIO registers for the PCIe XHCI controller are instantiated by the
>> PCIe bridge. Due to 32bit limit in the CPU virtual address space in ARM
>> 32bit mode, this region is mapped at 0xff80 CPU virtual address.
>>
>> Signed-off-by: Marek Szyprowski 
>> Signed-off-by: Sylwester Nawrocki 
>> ---
>> Changes since v1:
>>   - none.
>> ---
>>   arch/arm/mach-bcm283x/Kconfig |  1 +
>>   arch/arm/mach-bcm283x/include/mach/base.h |  7 +
>>   arch/arm/mach-bcm283x/init.c  | 52 
>> +++
>>   3 files changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/mach-bcm283x/Kconfig b/arch/arm/mach-bcm283x/Kconfig
>> index 00419bf..bcb7f1d 100644
>> --- a/arch/arm/mach-bcm283x/Kconfig
>> +++ b/arch/arm/mach-bcm283x/Kconfig
>> @@ -36,6 +36,7 @@ config BCM2711_32B
>>  select BCM2711
>>  select ARMV7_LPAE
>>  select CPU_V7A
>> +select PHYS_64BIT
>>   
>>   config BCM2711_64B
>>  bool "Broadcom BCM2711 SoC 64-bit support"
>> diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
>> b/arch/arm/mach-bcm283x/include/mach/base.h
>> index c4ae398..1d10dc9 100644
>> --- a/arch/arm/mach-bcm283x/include/mach/base.h
>> +++ b/arch/arm/mach-bcm283x/include/mach/base.h
>> @@ -6,6 +6,13 @@
>>   #ifndef _BCM283x_BASE_H_
>>   #define _BCM283x_BASE_H_
>>   
>> +#include 
>> +
>>   extern unsigned long rpi_bcm283x_base;
>>   
>> +#ifdef CONFIG_ARMV7_LPAE
>> +extern void *rpi4_phys_to_virt(phys_addr_t paddr);
>> +#define phys_to_virt(x) rpi4_phys_to_virt(x)
>> +#endif
>> +
>>   #endif
>> diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
>> index 6a748da..5d0d160 100644
>> --- a/arch/arm/mach-bcm283x/init.c
>> +++ b/arch/arm/mach-bcm283x/init.c
>> @@ -145,6 +145,58 @@ int mach_cpu_init(void)
>>   }
>>   
>>   #ifdef CONFIG_ARMV7_LPAE
>> +
>> +#define BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT0xff80UL
>> +
>> +void *rpi4_phys_to_virt(phys_addr_t paddr)
>> +{
>> +if (paddr >= BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS)
>> +paddr = paddr - BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS +
>> +BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT;
>> +return (void *)(unsigned long)paddr;
>> +}
>> +
>> +static void set_section_phys(unsigned int section, phys_addr_t phys,
>> + enum dcache_option option)
>> +{
>> +u64 *page_table = (u64 *)gd->arch.tlb_addr;
>> +/* Need to set the access flag to not fault */
>> +u64 value = TTB_SECT_AP | TTB_SECT_AF;
>> +
>> +/* Add the page offset */
>> +value |= (phys);
>> +
>> +/* Add caching bits */
>> +value |= option;
>> +
>> +/* Set PTE */
>> +page_table[section] = value;
>> +}
>> +
>> +static void rpi4_create_pcie_xhci_mapping(void)
>> +{
>> +unsigned sect = BCM2711_RPI4_PCIE_XHCI_MMIO_VIRT >> MMU_SECTION_SHIFT;
>> +phys_addr_t phys_addr = BCM2711_RPI4_PCIE_XHCI_MMIO_PHYS;
>> +unsigned int size = BCM2711_RPI4_PCIE_XHCI_MMIO_SIZE;
>> +
>> +while (size) {
>> +set_section_phys(sect, phys_addr, DCACHE_OFF);
>> +sect++;
>> +phys_addr += MMU_SECTION_SIZE;
>> +size -= MMU_SECTION_SIZE;
>> +}
> Why can't we reuse mmu_set_region_dcache_behaviour()?

Because it doesn't allow to set arbirtary physical address - it only 
works for the cases where phys == virt.


>
>> +}
>> +
>> +void arm_init_domains(void)
>> +{
>> +/*
>> + * Hijack this function to prepare a mappings for the PCIe MMIO
>> + * region for the XHCI controller on RPi4 board.
>> + * This code is called before enabling the MMU in ARM 32bit mode.
>> + */
>> +rpi4_create_pcie_xhci_mapping();
> I think this indirection is not necessary.

Okay.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH] config: Enable USB Keyboard support on RPi4

[Nicolas Saenz Julienne]

Supporting USB keyboards out of the box is both handy for development
and production. Notably if u-boot is used to boot into GRUB.

Signed-off-by: Nicolas Saenz Julienne 

---

Note that rpi_arm64_defconfig already supports USB keyboard. This is to
be applied on top of Sylwester Nawrocki's PCIe/xHCI on RPi4 series.

 configs/rpi_4_32b_defconfig | 1 +
 configs/rpi_4_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index dd7da1cf06..9c5ad7684e 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -42,6 +42,7 @@ CONFIG_DM_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_PCI=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index 6eeec4592e..1a92cd637e 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -42,6 +42,7 @@ CONFIG_DM_USB=y
 CONFIG_DM_USB_GADGET=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_PCI=y
+CONFIG_USB_KEYBOARD=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_MANUFACTURER="FSL"
 CONFIG_USB_GADGET_VENDOR_NUM=0x0525
-- 
2.26.2

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Matthias Brugger]

On 05/05/2020 15:47, Nicolas Saenz Julienne wrote:
> On Tue, 2020-05-05 at 15:39 +0200, Matthias Brugger wrote:
>>
>> On 05/05/2020 14:53, Nicolas Saenz Julienne wrote:
>>> Hi Matthias,
>>>
>>> On Tue, 2020-05-05 at 14:15 +0200, Matthias Brugger wrote:
 On 30/04/2020 15:04, Nicolas Saenz Julienne wrote:
> When needed, RPi4's co-processor (called VideoCore) has to be instructed
> to load VL805's firmware (the chip providing xHCI support). VideoCore's
> firmware expects the board's PCIe bus to be already configured in order
> for it to load the xHCI chip firmware. So we have to make sure this
> happens in between the PCIe configuration and xHCI startup.
>
> Introduce a callback in xhci_pci_probe() to run this platform specific
> routine.
>
> Signed-off-by: Nicolas Saenz Julienne 
>
> ---
>
> Changes since v1:
>  - Create callback
>
>  board/raspberrypi/rpi/rpi.c | 12 
>  drivers/usb/host/xhci-pci.c |  6 ++
>  include/usb/xhci.h  |  3 +++
>  3 files changed, 21 insertions(+)
>
> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
> index e367ba3092..8aa78d1f48 100644
> --- a/board/raspberrypi/rpi/rpi.c
> +++ b/board/raspberrypi/rpi/rpi.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -494,3 +495,14 @@ int ft_board_setup(void *blob, bd_t *bd)
>  
>   return 0;
>  }
> +
> +#ifdef CONFIG_BCM2711

 This won't work with rpi_arm64_defconfig.
 Can't we just evaluate at runtime if we need to do anything in
 xhci_pci_fixup.
>>>
>>> I can't see why, who is going to call xhci_pci_probe() in RPi3?
>>>
>>
>> If you do make rpi_arm64_defconfig and inspect the .config, you will see that
>> CONFIG_BCM2711 is not defined, so this code won't be called on RPi4.
> 
> Oh! Understood.
> 
> Well, given that only xhci_pci_probe() is called if we're running on RPi4, I
> think I can disregard those defines altogether. I'll double-check that.
> 

Yes but from my understanding we only need to call the function on newer
revisions of RPi4. Does it have any side effect on older revisions, e.g. we get
error messages (see below)?

[...] I wonder if the newer RPi4 have also a newer revision ID (see
 get_board_rev).
 If
 so we could add another bool to struct rpi_model which will indicate us if
 we
 need to notify VideoCore about vl805's firmware.

> +void xhci_pci_fixup(struct udevice *dev)
> +{
> + int ret;
> +
> + ret = bcm2711_notify_vl805_reset();
> + if (ret)
> + printf("RPI: Failed to notify VideoCore about vl805's
> firmware\n");

We already have
printf("bcm2711: Faild to load vl805's firmware, %d\n", ret); in
bcm2711_notify_vl805_reset(). Do we really need two error messages?

Regards,
Matthias

> +}
> +#endif
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index c1f60da541..1285dde1ef 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -11,6 +11,10 @@
>  #include 
>  #include 
>  
> +__weak void xhci_pci_fixup(struct udevice *dev)
> +{
> +}
> +
>  static void xhci_pci_init(struct udevice *dev, struct xhci_hccr
> **ret_hccr,
> struct xhci_hcor **ret_hcor)
>  {
> @@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
>   struct xhci_hccr *hccr;
>   struct xhci_hcor *hcor;
>  
> + xhci_pci_fixup(dev);
> +
>   xhci_pci_init(dev, &hccr, &hcor);
>  
>   return xhci_register(dev, hccr, hcor);
> diff --git a/include/usb/xhci.h b/include/usb/xhci.h
> index c16106a2fc..57feed7603 100644
> --- a/include/usb/xhci.h
> +++ b/include/usb/xhci.h
> @@ -16,6 +16,7 @@
>  #ifndef HOST_XHCI_H_
>  #define HOST_XHCI_H_
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
>  
>  struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
>  
> +extern void xhci_pci_fixup(struct udevice *dev);
> +
>  #endif /* HOST_XHCI_H_ */
>
> 

Re: [PATCH v2 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Nicolas Saenz Julienne]

On Tue, 2020-05-05 at 16:59 +0200, Matthias Brugger wrote:
[...]
> > > > > > +#ifdef CONFIG_BCM2711
> > > > > 
> > > > > This won't work with rpi_arm64_defconfig.
> > > > > Can't we just evaluate at runtime if we need to do anything in
> > > > > xhci_pci_fixup.
> > > > 
> > > > I can't see why, who is going to call xhci_pci_probe() in RPi3?
> > > > 
> > > 
> > > If you do make rpi_arm64_defconfig and inspect the .config, you will see
> > > that
> > > CONFIG_BCM2711 is not defined, so this code won't be called on RPi4.
> > 
> > Oh! Understood.
> > 
> > Well, given that only xhci_pci_probe() is called if we're running on RPi4, I
> > think I can disregard those defines altogether. I'll double-check that.
> > 
> 
> Yes but from my understanding we only need to call the function on newer
> revisions of RPi4. Does it have any side effect on older revisions, e.g. we
> get
> error messages (see below)?

The firmware quirk supports older rpi4s and simply does nothing. Note that the
downstream Linux implementation runs this on all rpi4s.

> [...] I wonder if the newer RPi4 have also a newer revision ID (see
> > > > > get_board_rev).
> > > > > If
> > > > > so we could add another bool to struct rpi_model which will indicate
> > > > > us if
> > > > > we
> > > > > need to notify VideoCore about vl805's firmware.
> > > > > 
> > > > > > +void xhci_pci_fixup(struct udevice *dev)
> > > > > > +{
> > > > > > +   int ret;
> > > > > > +
> > > > > > +   ret = bcm2711_notify_vl805_reset();
> > > > > > +   if (ret)
> > > > > > +   printf("RPI: Failed to notify VideoCore about vl805's
> > > > > > firmware\n");
> 
> We already have
> printf("bcm2711: Faild to load vl805's firmware, %d\n", ret); in
> bcm2711_notify_vl805_reset(). Do we really need two error messages?

Agree, it's a little redundant. I'll get rid of it.

Regards,
Nicolas




signature.asc
Description: This is a digitally signed message part

Re: [PATCH] config: Enable USB Keyboard support on RPi4

[Sylwester Nawrocki]

On 05.05.2020 16:51, Nicolas Saenz Julienne wrote:
> Supporting USB keyboards out of the box is both handy for development
> and production. Notably if u-boot is used to boot into GRUB.
> 
> Signed-off-by: Nicolas Saenz Julienne 

Reviewed-by: Sylwester Nawrocki 

> --- 
> Note that rpi_arm64_defconfig already supports USB keyboard. This is to
> be applied on top of Sylwester Nawrocki's PCIe/xHCI on RPi4 series.
Thanks for the patch, USB keyboard worked well for me on rpi4. I actually
used that feature to verify my PCIe/xHCI patch series.

-- 
Regards,
Sylwester

Re: [PATCH v2 09/10] pci: Add driver for Broadcom STB PCIe controller

[Nicolas Saenz Julienne]

Hi All.

On Mon, 2020-05-04 at 14:45 +0200, Sylwester Nawrocki wrote:
> This patch adds basic driver for the Broadcom STB PCIe host controller.
> The code is based on Linux upstream driver (pcie-brcmstb.c) with MSI
> handling removed. The inbound access memory region is not currently
> parsed from dma-ranges DT property and a fixed 4GB region is used.
> 
> The patch has been tested on RPI4 board, i.e. on BCM2711 SoC with VL805
> USB Host Controller.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> Signed-off-by: Sylwester Nawrocki 
> ---

If it's OK with you, as I'm already familiar with the driver from maintaining
it on the Linux kernel, I wouldn't mind doing it here too.

Sylwester, if you're also interested I can send a patch adding both of us.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part

RE: [PATCH v7 04/22] lib: Makefile: build crc7.c when CONFIG_MMC_SPI

[Pragnesh Patel]

>-Original Message-
>From: U-Boot  On Behalf Of Pragnesh Patel
>Sent: 04 May 2020 11:15
>To: Jagan Teki ; Heinrich Schuchardt
>; Bin Meng 
>Cc: U-Boot Mailing List ; Atish Patra
>; Palmer Dabbelt ; Paul
>Walmsley ; Troy Benjegerdes
>; Anup Patel ; Sagar
>Kadam ; Rick Chen ; Peng
>Fan ; Lukasz Majewski ; Simon
>Goldschmidt ; Simon Glass
>; Markus Klotzbuecher
>; Baruch Siach ; Joel
>Johnson ; Anatolij Gustschin ; AKASHI
>Takahiro ; Marek Behún 
>Subject: RE: [PATCH v7 04/22] lib: Makefile: build crc7.c when
>CONFIG_MMC_SPI
>
>>-Original Message-
>>From: Jagan Teki 
>>Sent: 02 May 2020 21:04
>>To: Heinrich Schuchardt ; Pragnesh Patel
>>; Bin Meng 
>>Cc: U-Boot Mailing List ; Atish Patra
>>; Palmer Dabbelt ;
>Paul
>>Walmsley ; Troy Benjegerdes
>>; Anup Patel ; Sagar
>>Kadam ; Rick Chen ; Peng
>>Fan ; Lukasz Majewski ; Simon
>>Goldschmidt ; Simon Glass
>>; Markus Klotzbuecher
>>; Baruch Siach ;
>>Joel Johnson ; Anatolij Gustschin ;
>>AKASHI Takahiro ; Marek Behún
>>
>>Subject: Re: [PATCH v7 04/22] lib: Makefile: build crc7.c when
>>CONFIG_MMC_SPI
>>
>>[External Email] Do not click links or attachments unless you recognize
>>the sender and know the content is safe
>>
>>On Sat, May 2, 2020 at 6:45 PM Heinrich Schuchardt 
>>wrote:
>>>
>>> Am May 2, 2020 11:47:10 AM UTC schrieb Bin Meng
>>:
>>> >Hi Heinrich,
>>> >
>>> >On Sat, May 2, 2020 at 6:30 PM Heinrich Schuchardt
>>> >
>>> >wrote:
>>> >>
>>> >> On 5/2/20 12:06 PM, Pragnesh Patel wrote:
>>> >> > When build U-Boot SPL, meet an issue of undefined reference to
>>> >> > 'crc7' for drivers/mmc/mmc_spi.c, so let's compile crc7.c when
>>> >> > CONFIG_MMC_SPI selected.
>>> >> >
>>> >> > Signed-off-by: Pragnesh Patel 
>>> >> > Reviewed-by: Jagan Teki 
>>> >> > Reviewed-by: Bin Meng 
>>> >> > ---
>>> >> >  common/spl/Kconfig  | 6 ++
>>> >> >  drivers/mmc/Kconfig | 1 +
>>> >> >  lib/Makefile| 1 +
>>> >> >  3 files changed, 8 insertions(+)
>>> >> >
>>> >> > diff --git a/common/spl/Kconfig b/common/spl/Kconfig index
>>> >> > ef5bf66696..d1f0e6bc4c 100644
>>> >> > --- a/common/spl/Kconfig
>>> >> > +++ b/common/spl/Kconfig
>>> >> > @@ -401,6 +401,12 @@ config SPL_CRC32_SUPPORT
>>> >> > for detected accidental image corruption. For secure
>>> >applications you
>>> >> > should consider SHA1 or SHA256.
>>> >> >
>>> >> > +config SPL_CRC7_SUPPORT
>>> >> > + bool "Support CRC7"
>>> >> > + help
>>> >> > +   Enable CRC7 hashing for drivers which are using in SPL.
>>> >> > +   This is a 32-bit checksum value that can be used to
>>> >> > +verify
>>> >images.
>>> >> > +
>>> >> >  config SPL_MD5_SUPPORT
>>> >> >   bool "Support MD5"
>>> >> >   depends on SPL_FIT
>>> >> > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index
>>> >> > 8f0df568b9..139599072a 100644
>>> >> > --- a/drivers/mmc/Kconfig
>>> >> > +++ b/drivers/mmc/Kconfig
>>> >> > @@ -49,6 +49,7 @@ if MMC
>>> >> >  config MMC_SPI
>>> >> >   bool "Support for SPI-based MMC controller"
>>> >> >   depends on DM_MMC && DM_SPI
>>> >> > + select SPL_CRC7_SUPPORT if SPL
>>> >> >   help
>>> >> > This selects SPI-based MMC controllers.
>>> >> > If you have an MMC controller on a SPI bus, say Y here.
>>> >> > diff --git a/lib/Makefile b/lib/Makefile index
>>> >> > c6f862b0c2..fcd934857f 100644
>>> >> > --- a/lib/Makefile
>>> >> > +++ b/lib/Makefile
>>> >> > @@ -80,6 +80,7 @@ endif
>>> >> >
>>> >> >  ifdef CONFIG_SPL_BUILD
>>> >> >  obj-$(CONFIG_SPL_YMODEM_SUPPORT) += crc16.o
>>> >> > +obj-$(CONFIG_SPL_CRC7_SUPPORT) += crc7.o
>>> >>
>>> >> crc7.o is not needed in main U-Boot if MMC_SPI is not selected.
>>> >>
>>> >> So instead of adding a new configuration variable simply correct
>>> >> the existing line in lib/Makefile
>>> >>
>>> >> -obj-y += crc7.o
>>> >> +obj-$(CONFIG_MMC_SPI) += crc7.o
>>> >
>>> >This looks incorrect to me. CRC7 can be useful for other drivers too.
>>> >It should not depend on CONFIG_MMC_SPI.
>>>
>>> Using this argument you would always compile everything. Compiling
>>> files
>>that are not used is simply a waste of CPU time.
>>>
>>> Following your argument. you could also always compile crc7.c for SPL
>>> and
>>hope the compiler will eliminate it.
>>>
>>> Either way we do not need a new config symbol.
>>
>>This is one of the reasons I just suggested that the mark 'depends on
>>MMC_SPI' at the very initial patch.
>>
>>Marking config SPL_CRC7_SUPPORT which depends on MMC_SPI would work
>for
>>me.
>
>@Jagan Teki I think MMC_SPI should be depend on or select
>SPL_CRC7_SUPPORT.
>SPL_CRC7_SUPPORT is not depend on MMC_SPI.
>
>@Heinrich Schuchardt Compiling crc7.o every time is not a good idea. I have 1
>suggestion, Can we make 1 Kconfig like
>
>+config CRC7_SUPPORT
>+  bool "Support CRC7"
>+  help
>+Enable CRC7 hashing for drivers.
>+This is a 32-bit checksum value that can be used to verify images.
>
>Which is common for U-Boot proper and U-Boot SPL and compile crc7
>
>+ obj-$(CONFIG_CRC7_SU

Re: [PATCH v5 1/2] drivers: gpio: add broadcom iproc gpio driver support

[Simon Glass]

Hi Rayagonda,

On Tue, 5 May 2020 at 00:32, Rayagonda Kokatanur
 wrote:
>
> Hi Simon,
>
> On Tue, May 5, 2020 at 12:57 AM Simon Glass  wrote:
> >
> > Hi Rayagonda,
> >
> > On Mon, 4 May 2020 at 10:00, Rayagonda Kokatanur
> >  wrote:
> > >
> > > Add gpio driver support for Broadcom iproc-based socs.
> > >
> >
> > This seems to be missing a change log. Can I suggest using patman to
> > make this automatic?
>
> All change logs are present in the cover letter.
> Please let me know if I still need to have a change log for individual patch.

Yes please. As I mentioned, patman does this for you.


- Simon


>
> >
> > > Signed-off-by: Rayagonda Kokatanur 
> > > Signed-off-by: Sheetal Tigadoli 
> > > ---
> > >  drivers/gpio/Kconfig  |  11 ++
> > >  drivers/gpio/Makefile |   1 +
> > >  drivers/gpio/iproc_gpio.c | 275 ++
> > >  3 files changed, 287 insertions(+)
> > >  create mode 100644 drivers/gpio/iproc_gpio.c
> > >
> > Regards,
> > Simon

Re: [PATCH v5 1/2] drivers: gpio: add broadcom iproc gpio driver support

[Simon Glass]

Hi Rayagonda,

On Mon, 4 May 2020 at 10:00, Rayagonda Kokatanur
 wrote:
>
> Add gpio driver support for Broadcom iproc-based socs.
>
> Signed-off-by: Rayagonda Kokatanur 
> Signed-off-by: Sheetal Tigadoli 
> ---
>  drivers/gpio/Kconfig  |  11 ++
>  drivers/gpio/Makefile |   1 +
>  drivers/gpio/iproc_gpio.c | 275 ++
>  3 files changed, 287 insertions(+)
>  create mode 100644 drivers/gpio/iproc_gpio.c
>

Reviewed-by: Simon Glass 

nits and suggestions below

> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 2081520f42..57d2cd2e75 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -135,6 +135,17 @@ config IMX_RGPIO2P
> help
>   This driver supports i.MX7ULP Rapid GPIO2P controller.
>
> +config IPROC_GPIO
> +   bool "Broadcom iProc GPIO driver(without pinconf)"
> +   default n
> +   help
> + The Broadcom iProc based SoCs- Cygnus, NS2, NS3, NSP and Stingray,
> + use the same GPIO Controller IP hence this driver could be used
> + for all.
> +
> + The Broadcom iProc based SoCs have multiple GPIO controllers and 
> only
> + the always-ON GPIO controller (CRMU/AON) is supported by this 
> driver.
> +
>  config HSDK_CREG_GPIO
> bool "HSDK CREG GPIO griver"
> depends on DM_GPIO
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 7638259007..5dc5849477 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_CORTINA_GPIO)  += cortina_gpio.o
>  obj-$(CONFIG_INTEL_GPIO)   += intel_gpio.o
>  obj-$(CONFIG_INTEL_ICH6_GPIO)  += intel_ich6_gpio.o
>  obj-$(CONFIG_INTEL_BROADWELL_GPIO) += intel_broadwell_gpio.o
> +obj-$(CONFIG_IPROC_GPIO)   += iproc_gpio.o
>  obj-$(CONFIG_KIRKWOOD_GPIO)+= kw_gpio.o
>  obj-$(CONFIG_KONA_GPIO)+= kona_gpio.o
>  obj-$(CONFIG_MARVELL_GPIO) += mvgpio.o
> diff --git a/drivers/gpio/iproc_gpio.c b/drivers/gpio/iproc_gpio.c
> new file mode 100644
> index 00..f75831d6e7
> --- /dev/null
> +++ b/drivers/gpio/iproc_gpio.c
> @@ -0,0 +1,275 @@
> +// SPDX-License-Identifier:  GPL-2.0+
> +/*
> + * Copyright (C) 2020 Broadcom
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Do you need that one?

> +
> +/*
> + * There are five GPIO bank register. Each bank can configure max of 32 
> gpios.
> + * BANK0 - gpios 0 to 31
> + * BANK1 - gpios 32 to 63
> + * BANK2 - gpios 64 to 95
> + * BANK3 - gpios 96 to 127
> + * BANK4 - gpios 128 to 150
> + *
> + * Offset difference between consecutive bank register is 0x200
> + */
> +#define NGPIO_PER_BANK 32
> +#define GPIO_BANK_SIZE 0x200
> +#define GPIO_BANK(pin) ((pin) / NGPIO_PER_BANK)
> +#define IPROC_GPIO_SHIFT(pin)  ((pin) % NGPIO_PER_BANK)
> +#define IPROC_GPIO_REG(pin, reg) (GPIO_BANK_SIZE * GPIO_BANK(pin) + (reg))
> +
> +/* device register offset */
> +#define IPROC_GPIO_DATA_IN_OFFSET   0x00
> +#define IPROC_GPIO_DATA_OUT_OFFSET  0x04
> +#define IPROC_GPIO_OUT_EN_OFFSET0x08
> +
> +/**
> + * struct iproc_gpio_pctrl_map - mapping between gpio and pinctrl specfied
> + *  using gpio-ranges parameter in dt.
> + * @gpio_pin:  start of gpio number in gpio-ranges
> + * @pctrl_pin: start of pinctrl number in gpio-ranges
> + * @npins: total number of pins in gpio-ranges
> + * @node:  list node
> + */
> +struct iproc_gpio_pctrl_map {
> +   u32 gpio_pin;
> +   u32 pctrl_pin;
> +   u32 npins;
> +   struct list_head node;
> +};
> +
> +/**
> + * struct iproc_gpio_pctrl_map - gpio device instance
> + * @pinctrl_dev:pointer to pinctrl device
> + * @gpiomap:   list node having mapping between gpio and pinctrl
> + * @base:  I/O register base address of gpio device
> + * @name:  gpio device name, ex GPIO0, GPIO1
> + * @ngpios:total number of gpios
> + */
> +struct iproc_gpio_platdata {
> +   struct udevice *pinctrl_dev;
> +   struct list_head gpiomap;
> +   void __iomem *base;
> +   char *name;
> +   u32 ngpios;
> +};
> +
> +/**
> + *  iproc_gpio_set_bit - set or clear one bit (corresponding to the GPIO pin)

Please fit the title on a single line. You can add more detail later. E.g.

iproc_gpio_set_bit() - set or clear one bit in an iproc GPIO register

The bit relates to a GPIO pin



> + *  in a iproc GPIO register
> + *
> + *  @iproc_gpio: Iproc GPIO device

But here you are actually passing plat

> + *  @reg: register offset
> + *  @gpio: GPIO pin
> + *  @set: set or clear
> + */
> +static inline void iproc_gpio_set_bit(struct iproc_gpio_platdata *plat,
> + u32 reg, u32 gpio, bool set)
> +{
> +   u32 offset = IPROC_GPIO_REG(gpio, reg);
> +   u32 shift = IPROC_GPIO_SHIFT(gpio);
> +
> +   clrsetbits_le32(plat->base + offset, BIT(shift),
> +   (set ? BIT(shift) : 0));
> +}
> +
> +st

Re: [PATCH] cmd: gpt: add eMMC and GPT support

[Simon Glass]

Hi Rayagonda,

On Tue, 5 May 2020 at 06:17, Rayagonda Kokatanur
 wrote:
>
> On Tue, May 5, 2020 at 5:43 PM Rayagonda Kokatanur
>  wrote:
> >
> > From: Corneliu Doban 
> >
> > Add eMMC and GPT support.
> > - GPT partition list and command to create the GPT added to u-boot
> >   environment
> > - eMMC boot commands added to u-boot environment
> > - new gpt commands (enumarate and setenv) that are used by broadcom
> >   update scripts and boot commands
> > - eMMC specific u-boot configurations with environment saved in eMMC
> >   and GPT support
> >
> > Signed-off-by: Corneliu Doban 
> > Signed-off-by: Rayagonda Kokatanur 
> >

>
> Please ignore this patch, forgot to add "PATCH v1" in the subject line.
> Will send another  patch.

It's OK, you don't need to have v1 for the first patch.

Regards,
SImon

Re: [PATCH] cmd: gpt: add eMMC and GPT support

[Simon Glass]

Hi Rayagonda,

On Tue, 5 May 2020 at 06:13, Rayagonda Kokatanur
 wrote:
>
> From: Corneliu Doban 
>
> Add eMMC and GPT support.
> - GPT partition list and command to create the GPT added to u-boot
>   environment
> - eMMC boot commands added to u-boot environment
> - new gpt commands (enumarate and setenv) that are used by broadcom
>   update scripts and boot commands
> - eMMC specific u-boot configurations with environment saved in eMMC
>   and GPT support
>
> Signed-off-by: Corneliu Doban 
> Signed-off-by: Rayagonda Kokatanur 
>
> diff --git a/cmd/gpt.c b/cmd/gpt.c
> index b8d11c167d..c32e272b25 100644
> --- a/cmd/gpt.c
> +++ b/cmd/gpt.c
> @@ -616,6 +616,87 @@ static int gpt_verify(struct blk_desc *blk_dev_desc, 
> const char *str_part)
> return ret;
>  }
>
> +/*
> + * Enumerate partition names into environment variable.
> + */

Can you check the style for these comments? You can see examples in
bootcount.h. Please fix for all functions.

It should mention the params and return value.

Also in this case it should explain which environment variable is
updated and the format that is used in the variable.

> +static int gpt_enumerate(struct blk_desc *blk_dev_desc)
> +{
> +   disk_partition_t pinfo;
> +   struct part_driver *first_drv =
> +   ll_entry_start(struct part_driver, part_driver);
> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);

Can you create functions in part.h to handle this? Something like:

int part_driver_get_count()
struct part_driver *part_driver_get((int n);

Then we don't have lots of places accessing this.

> +   struct part_driver *part_drv;
> +   char part_list[2048];
> +
> +   part_list[0] = 0;
> +
> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
> part_drv++) {
> +   int ret;
> +   int i;
> +
> +   for (i = 1; i < part_drv->max_entries; i++) {
> +   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
> +   if (ret != 0) {

if (ret)

> +   /* no more entries in table */
> +   break;
> +   }
> +   strcat(part_list, (const char *)pinfo.name);
> +   strcat(part_list, " ");

Need to check that you don't go past sizeof(part_list). Can I suggest
that you have a ptr to the end of your string to avoid n^2 behaviour
here?

> +   }
> +   }
> +   if (strlen(part_list) > 0)

if (*part_list)

> +   part_list[strlen(part_list) - 1] = 0;
> +   debug("setenv gpt_partition_list %s\n", part_list);
> +   env_set("gpt_partition_list", part_list);

Please check return value


blank line here

> +   return 0;
> +}
> +
> +/*
> + * Dynamically setup environment variables for name, index, offset and size
> + * for partition in GPT table after running "gpt setenv" for a partition 
> name.
> + * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
> + * gpt_partition_size environment variables will be set.
> + */
> +static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
> +{
> +   disk_partition_t pinfo;
> +   struct part_driver *first_drv =
> +   ll_entry_start(struct part_driver, part_driver);
> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
> +   struct part_driver *part_drv;
> +   char buf[32];

put pinfo and buf inside loop?

> +
> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
> part_drv++) {
> +   int ret;
> +   int i;
> +
> +   for (i = 1; i < part_drv->max_entries; i++) {
> +   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
> +   if (ret != 0) {
> +   /* no more entries in table */
> +   break;
> +   }
> +   if (strcmp(name, (const char *)pinfo.name) == 0) {
> +   /* match found, setup environment variables */
> +   sprintf(buf, LBAF, pinfo.start);
> +   debug("setenv gpt_partition_addr %s\n", buf);
> +   env_set("gpt_partition_addr", buf);
> +   sprintf(buf, LBAF, pinfo.size);
> +   debug("setenv gpt_partition_size %s\n", buf);
> +   env_set("gpt_partition_size", buf);
> +   sprintf(buf, "%d", i);
> +   debug("setenv gpt_partition_entry %s\n", buf);
> +   env_set("gpt_partition_entry", buf);
> +   sprintf(buf, "%s", pinfo.name);
> +   debug("setenv gpt_partition_name %s\n", buf);
> +   env_set("gpt_partition_name", buf);

Need to check return values

[PATCH v3 0/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Nicolas Saenz Julienne]

Newer revisions of the RPi4 need their xHCI chip, VL805, firmware to be
loaded explicitly. Earlier versions didn't need that as they where using
an EEPROM for that purpose. This series takes care of setting up the
relevant infrastructure and run the firmware loading routine at the
right moment.

Note that this builds on top of Sylwester Nawrocki's "USB host support
for Raspberry Pi 4 board" series.

---

Note: this was tested on both rpi_arm64_defconfig on both rpi3 & rpi4.

Changes since v2:
 - Correct comment on patch #1
 - Address Matthias' comments

Changes since v1:
 - Rename function
 - Use callback in xhci-pci.c

Nicolas Saenz Julienne (2):
  arm: rpi: Add function to trigger VL805's firmware load
  usb: xhci: Load Raspberry Pi 4 VL805's firmware

 arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
 arch/arm/mach-bcm283x/include/mach/msg.h  |  7 
 arch/arm/mach-bcm283x/msg.c   | 45 +++
 board/raspberrypi/rpi/rpi.c   |  6 +++
 drivers/usb/host/xhci-pci.c   |  6 +++
 include/usb/xhci.h|  3 ++
 6 files changed, 80 insertions(+)

-- 
2.26.2

[PATCH v3 2/2] usb: xhci: Load Raspberry Pi 4 VL805's firmware

[Nicolas Saenz Julienne]

When needed, RPi4's co-processor (called VideoCore) has to be instructed
to load VL805's firmware (the chip providing xHCI support). VideCore's
firmware expects the board's PCIe bus to be already configured in order
for it to load the xHCI chip firmware. So we have to make sure this
happens in between the PCIe configuration and xHCI startup.

Introduce a callback in xhci_pci_probe() to run this platform specific
routine.

Signed-off-by: Nicolas Saenz Julienne 

---

Changes since v2:
 - Get rid of #ifdef CONFIG_BCM2711
 - Get rid of redundant error message

Changes since v1:
 - Create callback

 board/raspberrypi/rpi/rpi.c | 6 ++
 drivers/usb/host/xhci-pci.c | 6 ++
 include/usb/xhci.h  | 3 +++
 3 files changed, 15 insertions(+)

diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
index e367ba3092..dcaf45fbf2 100644
--- a/board/raspberrypi/rpi/rpi.c
+++ b/board/raspberrypi/rpi/rpi.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -494,3 +495,8 @@ int ft_board_setup(void *blob, bd_t *bd)
 
return 0;
 }
+
+void xhci_pci_fixup(struct udevice *dev)
+{
+   bcm2711_notify_vl805_reset();
+}
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index c1f60da541..1285dde1ef 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -11,6 +11,10 @@
 #include 
 #include 
 
+__weak void xhci_pci_fixup(struct udevice *dev)
+{
+}
+
 static void xhci_pci_init(struct udevice *dev, struct xhci_hccr **ret_hccr,
  struct xhci_hcor **ret_hcor)
 {
@@ -40,6 +44,8 @@ static int xhci_pci_probe(struct udevice *dev)
struct xhci_hccr *hccr;
struct xhci_hcor *hcor;
 
+   xhci_pci_fixup(dev);
+
xhci_pci_init(dev, &hccr, &hcor);
 
return xhci_register(dev, hccr, hcor);
diff --git a/include/usb/xhci.h b/include/usb/xhci.h
index c16106a2fc..57feed7603 100644
--- a/include/usb/xhci.h
+++ b/include/usb/xhci.h
@@ -16,6 +16,7 @@
 #ifndef HOST_XHCI_H_
 #define HOST_XHCI_H_
 
+#include 
 #include 
 #include 
 #include 
@@ -1281,4 +1282,6 @@ extern struct dm_usb_ops xhci_usb_ops;
 
 struct xhci_ctrl *xhci_get_ctrl(struct usb_device *udev);
 
+extern void xhci_pci_fixup(struct udevice *dev);
+
 #endif /* HOST_XHCI_H_ */
-- 
2.26.2

[PATCH v3 1/2] arm: rpi: Add function to trigger VL805's firmware load

[Nicolas Saenz Julienne]

On the Raspberry Pi 4, after a PCI reset, VL805's (a xHCI chip) firmware
may either be loaded directly from an EEPROM or, if not present, by the
SoC's VideCore (the SoC's co-processor). Introduce the function that
informs VideCore that VL805 may need its firmware loaded.

Signed-off-by: Nicolas Saenz Julienne 

---
Changes since v2:
 - Correct wrong function name in comment
 - Add better comment on rpi_firmware_init_vl805()

Changes since v1:
 - Rename function so it's not mistaken with regular firmware loading

 arch/arm/mach-bcm283x/include/mach/mbox.h | 13 +++
 arch/arm/mach-bcm283x/include/mach/msg.h  |  7 
 arch/arm/mach-bcm283x/msg.c   | 45 +++
 3 files changed, 65 insertions(+)

diff --git a/arch/arm/mach-bcm283x/include/mach/mbox.h 
b/arch/arm/mach-bcm283x/include/mach/mbox.h
index 60e226ce1d..2ae2d3d97c 100644
--- a/arch/arm/mach-bcm283x/include/mach/mbox.h
+++ b/arch/arm/mach-bcm283x/include/mach/mbox.h
@@ -491,6 +491,19 @@ struct bcm2835_mbox_tag_set_palette {
} body;
 };
 
+#define BCM2835_MBOX_TAG_NOTIFY_XHCI_RESET  0x00030058
+
+struct bcm2835_mbox_tag_pci_dev_addr {
+   struct bcm2835_mbox_tag_hdr tag_hdr;
+   union {
+   struct {
+   u32 dev_addr;
+   } req;
+   struct {
+   } resp;
+   } body;
+};
+
 /*
  * Pass a raw u32 message to the VC, and receive a raw u32 back.
  *
diff --git a/arch/arm/mach-bcm283x/include/mach/msg.h 
b/arch/arm/mach-bcm283x/include/mach/msg.h
index 4afb08631b..f5213dd0e0 100644
--- a/arch/arm/mach-bcm283x/include/mach/msg.h
+++ b/arch/arm/mach-bcm283x/include/mach/msg.h
@@ -48,4 +48,11 @@ int bcm2835_set_video_params(int *widthp, int *heightp, int 
depth_bpp,
 int pixel_order, int alpha_mode, ulong *fb_basep,
 ulong *fb_sizep, int *pitchp);
 
+/**
+ * bcm2711_notify_vl805_reset() - get vl805's firmware loaded
+ *
+ * @return 0 if OK, -EIO on error
+ */
+int bcm2711_notify_vl805_reset(void);
+
 #endif
diff --git a/arch/arm/mach-bcm283x/msg.c b/arch/arm/mach-bcm283x/msg.c
index 94b75283f8..f8ef531652 100644
--- a/arch/arm/mach-bcm283x/msg.c
+++ b/arch/arm/mach-bcm283x/msg.c
@@ -40,6 +40,12 @@ struct msg_setup {
u32 end_tag;
 };
 
+struct msg_notify_vl805_reset {
+   struct bcm2835_mbox_hdr hdr;
+   struct bcm2835_mbox_tag_pci_dev_addr dev_addr;
+   u32 end_tag;
+};
+
 int bcm2835_power_on_module(u32 module)
 {
ALLOC_CACHE_ALIGN_BUFFER(struct msg_set_power_state, msg_pwr, 1);
@@ -151,3 +157,42 @@ int bcm2835_set_video_params(int *widthp, int *heightp, 
int depth_bpp,
 
return 0;
 }
+
+/*
+ * The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip that
+ * implements xHCI. After a PCI reset, VL805's firmware may either be loaded
+ * directly from an EEPROM or, if not present, by the SoC's co-processor,
+ * VideoCore. RPi4's VideoCore OS contains both the non public firmware load
+ * logic and the VL805 firmware blob. This function triggers the aforementioned
+ * process.
+ */
+int bcm2711_notify_vl805_reset(void)
+{
+   ALLOC_CACHE_ALIGN_BUFFER(struct msg_notify_vl805_reset,
+msg_notify_vl805_reset, 1);
+   int ret;
+
+   BCM2835_MBOX_INIT_HDR(msg_notify_vl805_reset);
+   BCM2835_MBOX_INIT_TAG(&msg_notify_vl805_reset->dev_addr,
+ NOTIFY_XHCI_RESET);
+
+   /*
+* The pci device address is expected like this:
+*
+*   PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12
+*
+* But since RPi4's PCIe setup is hardwired, we know the address in
+* advance.
+*/
+   msg_notify_vl805_reset->dev_addr.body.req.dev_addr = 0x10;
+
+   ret = bcm2835_mbox_call_prop(BCM2835_MBOX_PROP_CHAN,
+&msg_notify_vl805_reset->hdr);
+   if (ret) {
+   printf("bcm2711: Faild to load vl805's firmware, %d\n", ret);
+   return -EIO;
+   }
+
+   return 0;
+}
+
-- 
2.26.2

Re: [PATCH v5 1/4] omap: mmc: Avoid using libfdt with of-platdata

[Bartosz Golaszewski]

wt., 5 maj 2020 o 08:50 Faiz Abbas  napisał(a):
>
> Hi,
>
> On 04/05/20 6:44 pm, Simon Glass wrote:
> > Hi Bart,
> >
> > On Mon, 4 May 2020 at 01:10, Bartosz Golaszewski  wrote:
> >>
> >> pt., 1 maj 2020 o 20:32 Tom Rini  napisał(a):
> >>>
> >>> On Thu, Apr 30, 2020 at 01:43:30PM +0200, Bartosz Golaszewski wrote:
>  wt., 28 kwi 2020 o 09:01 Faiz Abbas  napisał(a):
> >
> > +Bartosz
> >
> > On 28/04/20 9:47 am, Lokesh Vutla wrote:
> >> +Faiz,
> >>
> >> On 28/04/20 12:29 AM, Tom Rini wrote:
> >>> On Mon, Apr 27, 2020 at 05:33:41AM +, Peng Fan wrote:
> > Subject: [PATCH v5 1/4] omap: mmc: Avoid using libfdt with 
> > of-platdata
> >
> > At present this driver is enabled in SPL on omapl138_lcdk, which 
> > uses
> > of-platdata. The driver needs to be ported to use of-platdata 
> > properly.
> > For now, avoid a build error by returning an error.
> >
> > Signed-off-by: Simon Glass 
> >>
> >> Does this break the boot on omap l138?
> >>
> >
> > I don't have a board at hand to test this out. Bartosz can you help 
> > test this with
> > omapl138?
> >
> > Thanks,
> > Faiz
> 
>  Hi Faiz,
> 
>  I can confirm - this *does* break the mmc boot on da850-lcdk.
> >>>
> >>> So who is going to fix the driver to unblock Simon's series?
> >>>
> >>
> >> Is this something that will take a lot of work? What exactly needs
> >> doing? I'm not sure what "use of-platdata properly" means.
> >
> > This board is defining CONFIG_SPL_OF_PLATDATA which means that device
> > tree is not available in SPL. Instead you need to use a C structure
> > created by dtoc. It basically involves creating that struct and
> > getting the data from that instead of calling the DT functions. I
> > expect it will take 2-4 hours to figure out, code and test.
> >
> > See of-plat.rst for full documentation. There are quite a few examples for 
> > mmc:
> >
> > grep PLATDATA drivers/mmc/*.c
> > drivers/mmc/ftsdc010_mci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/ftsdc010_mci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/ftsdc010_mci.c:#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/ftsdc010_mci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/mxsmmc.c: debug("OF_PLATDATA: regs: 0x%p bw: %d clkid: %d
> > non_removable: %d\n",
> > drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/mxsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/omap_hsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/omap_hsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/omap_hsmmc.c:#if CONFIG_IS_ENABLED(OF_CONTROL) &&
> > !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/rockchip_dw_mmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/rockchip_dw_mmc.c:#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/rockchip_dw_mmc.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/rockchip_sdhci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/rockchip_sdhci.c:#if CONFIG_IS_ENABLED(OF_PLATDATA)
> > drivers/mmc/rockchip_sdhci.c:#if !CONFIG_IS_ENABLED(OF_PLATDATA)
> >
>
> I was able to get a setup to work on. Will post a fix for this soon.
>
> Thanks,
> Faiz

Thanks Faiz! Let me know if you need some help testing it.

Bart

Re: pull request of u-boot-mpc85xx for v2020.07

[Tom Rini]

On Tue, May 05, 2020 at 08:40:51AM +, Priyanka Jain wrote:

> Dear Tom,
> Please find my pull-request for u-boot-mpc85xx
> https://travis-ci.org/github/p-priyanka-jain/u-boot/builds/682767731
> 
> Summary
> Add DM model for P1010RDB
> Add I2C DM Model support for P1010RDB, T1042RDB, T2080, T4240RDB,
> MPC8548CDS, T1024RDB, P4080, P3041DS, P2041RDB, P2020RDB, P1020RDB,
> P5040DS
> Fix reference to READM.qe_firmware
> 
> Thanks
> Priyanka

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data

[Alex Kiernan]

On Tue, May 5, 2020 at 2:28 PM Marek Vasut  wrote:
>
> On 5/5/20 3:22 PM, Alex Kiernan wrote:
> > On Mon, May 4, 2020 at 12:28 PM Tom Rini  wrote:
> >>
> >> On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote:
> >>
> >>> There is no reason to tail-pad fitImage with external data to 4-bytes,
> >>> while fitImage without external data does not have any such padding and
> >>> is often unaligned. DT spec also does not mandate any such padding.
> >>>
> >>> Moreover, the tail-pad fills the last few bytes with uninitialized data,
> >>> which could lead to a potential information leak.
> >>>
> >>> $ echo -n xy > /tmp/data ; \
> >>>   ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \
> >>>   hexdump -vC /tmp/fitImage | tail -n 3
> >>>
> >>> before:
> >>> 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
> >>> |a-offset.data-si|
> >>> 0270  7a 65 00 00 78 79 64 64   |ze..xydd|
> >>>^^   ^^ ^^
> >>> after:
> >>> 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
> >>> |a-offset.data-si|
> >>> 0270  7a 65 00 78 79|ze.xy|
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Reviewed-by: Simon Glass 
> >>> Cc: Heinrich Schuchardt 
> >>> Cc: Tom Rini 
> >>
> >> Applied to u-boot/master, thanks!
> >>
> >
> > This breaks booting on my board (am3352, eMMC boot, FIT u-boot,
> > CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it
> > from eMMC I get nothing at all on the console, if I boot over ymodem
> > it stalls at 420k, before continuing to 460k. My guess is there's some
> > error going to the console at the 420k mark, but obviously it's lost
> > in the ymodem... I have two DTBs in the FIT image, 420k would about
> > align to the point between them.
>
> My bet would be on some padding / unaligned access problem that this
> patch uncovered. Can you take a look ?

Seems plausible. With this change my external data starts at 0x483 and
everything after it is non-aligned:

/dts-v1/;
// magic: 0xd00dfeed
// totalsize: 0x483 (1155)
// off_dt_struct: 0x38
// off_dt_strings: 0x3f8
// off_mem_rsvmap: 0x28
// version: 17
// last_comp_version: 2
// boot_cpuid_phys: 0x0
// size_dt_strings: 0x8b
// size_dt_struct: 0x3c0


-- 
Alex Kiernan

Re: [PATCH V2] mkimage: fit: Do not tail-pad fitImage with external data

[Marek Vasut]

On 5/5/20 6:37 PM, Alex Kiernan wrote:
> On Tue, May 5, 2020 at 2:28 PM Marek Vasut  wrote:
>>
>> On 5/5/20 3:22 PM, Alex Kiernan wrote:
>>> On Mon, May 4, 2020 at 12:28 PM Tom Rini  wrote:

 On Fri, May 01, 2020 at 05:40:25PM +0200, Marek Vasut wrote:

> There is no reason to tail-pad fitImage with external data to 4-bytes,
> while fitImage without external data does not have any such padding and
> is often unaligned. DT spec also does not mandate any such padding.
>
> Moreover, the tail-pad fills the last few bytes with uninitialized data,
> which could lead to a potential information leak.
>
> $ echo -n xy > /tmp/data ; \
>   ./tools/mkimage -E -f auto -d /tmp/data /tmp/fitImage ; \
>   hexdump -vC /tmp/fitImage | tail -n 3
>
> before:
> 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
> |a-offset.data-si|
> 0270  7a 65 00 00 78 79 64 64   |ze..xydd|
>^^   ^^ ^^
> after:
> 0260  61 2d 6f 66 66 73 65 74  00 64 61 74 61 2d 73 69  
> |a-offset.data-si|
> 0270  7a 65 00 78 79|ze.xy|
>
> Signed-off-by: Marek Vasut 
> Reviewed-by: Simon Glass 
> Cc: Heinrich Schuchardt 
> Cc: Tom Rini 

 Applied to u-boot/master, thanks!

>>>
>>> This breaks booting on my board (am3352, eMMC boot, FIT u-boot,
>>> CONFIG_SPL_LOAD_FIT). Not got any useful diagnostics - if I boot it
>>> from eMMC I get nothing at all on the console, if I boot over ymodem
>>> it stalls at 420k, before continuing to 460k. My guess is there's some
>>> error going to the console at the 420k mark, but obviously it's lost
>>> in the ymodem... I have two DTBs in the FIT image, 420k would about
>>> align to the point between them.
>>
>> My bet would be on some padding / unaligned access problem that this
>> patch uncovered. Can you take a look ?
> 
> Seems plausible. With this change my external data starts at 0x483 and
> everything after it is non-aligned:

Should the beginning of external data be aligned ?

Re: [PATCH] cmd: gpt: add eMMC and GPT support

[Heinrich Schuchardt]

On 05.05.20 18:02, Simon Glass wrote:
> Hi Rayagonda,
>
> On Tue, 5 May 2020 at 06:13, Rayagonda Kokatanur
>  wrote:
>>
>> From: Corneliu Doban 
>>
>> Add eMMC and GPT support.
>> - GPT partition list and command to create the GPT added to u-boot
>>   environment
>> - eMMC boot commands added to u-boot environment
>> - new gpt commands (enumarate and setenv) that are used by broadcom
>>   update scripts and boot commands
>> - eMMC specific u-boot configurations with environment saved in eMMC
>>   and GPT support
>>
>> Signed-off-by: Corneliu Doban 
>> Signed-off-by: Rayagonda Kokatanur 
>>
>> diff --git a/cmd/gpt.c b/cmd/gpt.c
>> index b8d11c167d..c32e272b25 100644
>> --- a/cmd/gpt.c
>> +++ b/cmd/gpt.c
>> @@ -616,6 +616,87 @@ static int gpt_verify(struct blk_desc *blk_dev_desc, 
>> const char *str_part)
>> return ret;
>>  }
>>
>> +/*
>> + * Enumerate partition names into environment variable.
>> + */
>
> Can you check the style for these comments? You can see examples in
> bootcount.h. Please fix for all functions.


Unfortunately bootcount.h itself is in bad shape. Please, use

https://www.kernel.org/doc/html/v4.10/doc-guide/kernel-doc.html#function-documentation

as reference.

Best regards

Heinrich

>
> It should mention the params and return value.
>
> Also in this case it should explain which environment variable is
> updated and the format that is used in the variable.
>
>> +static int gpt_enumerate(struct blk_desc *blk_dev_desc)
>> +{
>> +   disk_partition_t pinfo;
>> +   struct part_driver *first_drv =
>> +   ll_entry_start(struct part_driver, part_driver);
>> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
>
> Can you create functions in part.h to handle this? Something like:
>
> int part_driver_get_count()
> struct part_driver *part_driver_get((int n);
>
> Then we don't have lots of places accessing this.
>
>> +   struct part_driver *part_drv;
>> +   char part_list[2048];
>> +
>> +   part_list[0] = 0;
>> +
>> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
>> part_drv++) {
>> +   int ret;
>> +   int i;
>> +
>> +   for (i = 1; i < part_drv->max_entries; i++) {
>> +   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
>> +   if (ret != 0) {
>
> if (ret)
>
>> +   /* no more entries in table */
>> +   break;
>> +   }
>> +   strcat(part_list, (const char *)pinfo.name);
>> +   strcat(part_list, " ");
>
> Need to check that you don't go past sizeof(part_list). Can I suggest
> that you have a ptr to the end of your string to avoid n^2 behaviour
> here?
>
>> +   }
>> +   }
>> +   if (strlen(part_list) > 0)
>
> if (*part_list)
>
>> +   part_list[strlen(part_list) - 1] = 0;
>> +   debug("setenv gpt_partition_list %s\n", part_list);
>> +   env_set("gpt_partition_list", part_list);
>
> Please check return value
>
>
> blank line here
>
>> +   return 0;
>> +}
>> +
>> +/*
>> + * Dynamically setup environment variables for name, index, offset and size
>> + * for partition in GPT table after running "gpt setenv" for a partition 
>> name.
>> + * gpt_partition_name, gpt_partition_entry, gpt_partition_addr and
>> + * gpt_partition_size environment variables will be set.
>> + */
>> +static int gpt_setenv(struct blk_desc *blk_dev_desc, const char *name)
>> +{
>> +   disk_partition_t pinfo;
>> +   struct part_driver *first_drv =
>> +   ll_entry_start(struct part_driver, part_driver);
>> +   const int n_drvs = ll_entry_count(struct part_driver, part_driver);
>> +   struct part_driver *part_drv;
>> +   char buf[32];
>
> put pinfo and buf inside loop?
>
>> +
>> +   for (part_drv = first_drv; part_drv != first_drv + n_drvs; 
>> part_drv++) {
>> +   int ret;
>> +   int i;
>> +
>> +   for (i = 1; i < part_drv->max_entries; i++) {
>> +   ret = part_drv->get_info(blk_dev_desc, i, &pinfo);
>> +   if (ret != 0) {
>> +   /* no more entries in table */
>> +   break;
>> +   }
>> +   if (strcmp(name, (const char *)pinfo.name) == 0) {
>> +   /* match found, setup environment variables 
>> */
>> +   sprintf(buf, LBAF, pinfo.start);
>> +   debug("setenv gpt_partition_addr %s\n", buf);
>> +   env_set("gpt_partition_addr", buf);
>> +   sprintf(buf, LBAF, pinfo.size);
>> +   debug("setenv gpt_partition_size %s\n", buf);
>> +   env_set("gpt_partition_size", buf);
>> +   sprintf(buf, "%d", i);
>> + 

Re: [PATCH v10 20/21] doc: riscv: Add documentation for Sipeed Maix Bit

[Sean Anderson]

On 5/5/20 5:01 AM, Rick Chen wrote:
> Hi Sean
> 
>> This patch adds documentation for the Sipeed Maix bit, and more generally
>> for the Kendryte K210 processor.
>>
>> Signed-off-by: Sean Anderson 
>> ---
>>
>> Changes in v9:
>> - Mark dts code block as "none" explicitly
>> Changes in v7:
>> - Split off into its own patch
>> - Fix size of clint
>>
>>  doc/board/index.rst|   1 +
>>  doc/board/sipeed/index.rst |   9 ++
>>  doc/board/sipeed/maix.rst  | 298 +
>>  3 files changed, 308 insertions(+)
>>  create mode 100644 doc/board/sipeed/index.rst
>>  create mode 100644 doc/board/sipeed/maix.rst
>>
> 
> The CI verification of v10 still fail, please check:
> https://travis-ci.org/github/rickchen36/u-boot-riscv/builds/683207657
> 
> Thanks,
> Rick

Hm, that's strange. I didn't see any of these errors when I ran CI.
Perhaps it is an interaction with one of the other patches merged. Is
it possible to get the u-boot.map file? The EPC address is present, but
without the map we can't tell what function caused the error.

--Sean

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

[Heinrich Schuchardt]

On 05.05.20 13:15, Grant Likely wrote:
>
>
> On 01/05/2020 10:33, Heinrich Schuchardt wrote:
>> On 4/30/20 9:13 PM, Sughosh Ganu wrote:
>>>
>>> On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt >> > wrote:
>>>
>>>  On 4/30/20 7:36 PM, Sughosh Ganu wrote:
>>>  > Add support for the get_image_info and set_image routines,
>>> which are
>>>  > part of the efi firmware management protocol.
>>>  >
>>>  > The current implementation uses the set_image routine for
>>> updating the
>>>  > u-boot binary image for the qemu arm64 platform. This is
>>> supported
>>>  > using the capsule-on-disk feature of the uefi specification,
>>> wherein
>>>  > the firmware image to be updated is placed on the efi system
>>> partition
>>>  > as a efi capsule under EFI/UpdateCapsule/ directory. Support
>>> has been
>>>  > added for updating the u-boot image on platforms booting with arm
>>>  > trusted firmware(tf-a), where the u-boot image gets booted as
>>> the BL33
>>>  > payload(bl33.bin).
>>>  >
>>>  > The feature can be enabled by the following config options
>>>  >
>>>  > CONFIG_EFI_CAPSULE_ON_DISK=y
>>>  > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
>>>  >
>>>  > Signed-off-by: Sughosh Ganu >>  >
>>>
>>>  U-Boot's UEFI subsystem should work in the same way for x86,
>>> ARM, and
>>>  RISC-V. Please, come up with an architecture independent solution.
>>>
>>>
>>> Please check the explanation that I gave in the other mail. If you check
>>> the patch series, the actual capsule authentication logic has been kept
>>> architecture agnostic, in efi_capsule.c. The fmp protocol is very much
>>> intended for allowing platforms to define their firmware update
>>> routines. Edk2 also has platform specific implementation of the fmp
>>> protocol under the edk2-platforms directory.
>>>
>>> -sughosh
>>>
>>>
>>
>> My idea is that for most platforms it will be enough to have a common
>> FMP implementation that consumes a capsule
>>
>> * with one or more binaries
>> * a media device path, a start address, and a truncation flag
>>    for each of the binaries
>>
>> The protocol implementation then will write the binaries to the device
>> paths:
>>
>> * to an SD-Card or eMMC exposing the Block IO protocol
>>    for most devices
>> * to a file in case of the Raspberry Pi or the Sandbox or QEMU
>>    (and truncate it if the truncation flag is set)
>
> Does U-Boot have a common device path protocol that can be backed by
> either a block device or a file on a filesystem? I didn't think it did.

A block device, a partition, and a file all can be described by an UEFI
media device path.

>
> In the mean time, there are at least three backends that the FMP is
> going to have to deal with; the two you list above (block device & file)
> and SMC backed when updating firmware is managed by the secure world.
> This first implementation only handles the file-backed use case. Can we
> start with that limitation and refactor when the block-device and SMC
> use cases are added in? I would hate to see this functionality held up
> on having to refactor other functionality in U-Boot.

I would prefer one single FMP driver for all SMC use cases. Everything
device specific should be handled in the secure world.

Is there already a protocol defined for the communication of capsule
updates between the firmware and the secure monitor, e.g. in EDK2?

Would we simply use the UpdateCapsule() call parameters and pass them
via an SMC call?

>
>> If for some devices like a SPI flash we do not have a media device path
>> yet, then the only platform specific bit would be the block device
>> driver exposing the media device path.
>>
>> Same with a semi-hosted file: just add a driver exposing it as a media
>> path with an EFI_BLOCK_IO_PROTOCOL.
>
> Sughosh and I chatted about this and took a look a the semihosting
> driver. Right now it is a standalone component implementing only the
> smhload command. It looks like it easily maps onto fstype_info
> operations which would be a better fit than the block IO protocol. Am I
> correct in assuming that would also make semihosting available to the
> EFI_FILE_PROTOCOL? The FMP backend code could be common for all
> filesystem targets, with the only platform specific bit being the path
> to the firmware files.

According to my call with Sughosh the whole semihosting thing is about
providing a testing possibility not about any real use case.

On QEMU you can easily mount an image as block device using parameters
of the qemu-system-* command. On the mounted image/block-device you can
test both file and block device based firmware updates. On the sandbox
you could use the 'host bind' command for mounting an image.

For creating a Python unit test using the sandbox is the best fit.
Takahiro already did this for his secure boot patches.

Best regards

Heinrich

>
> How does that sound?
>
> g.
>
>> For securit

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

[Grant Likely]

On 05/05/2020 18:04, Heinrich Schuchardt wrote:

On 05.05.20 13:15, Grant Likely wrote:



On 01/05/2020 10:33, Heinrich Schuchardt wrote:

On 4/30/20 9:13 PM, Sughosh Ganu wrote:


On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:

  On 4/30/20 7:36 PM, Sughosh Ganu wrote:
  > Add support for the get_image_info and set_image routines,
which are
  > part of the efi firmware management protocol.
  >
  > The current implementation uses the set_image routine for
updating the
  > u-boot binary image for the qemu arm64 platform. This is
supported
  > using the capsule-on-disk feature of the uefi specification,
wherein
  > the firmware image to be updated is placed on the efi system
partition
  > as a efi capsule under EFI/UpdateCapsule/ directory. Support
has been
  > added for updating the u-boot image on platforms booting with arm
  > trusted firmware(tf-a), where the u-boot image gets booted as
the BL33
  > payload(bl33.bin).
  >
  > The feature can be enabled by the following config options
  >
  > CONFIG_EFI_CAPSULE_ON_DISK=y
  > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
  >
  > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

  U-Boot's UEFI subsystem should work in the same way for x86,
ARM, and
  RISC-V. Please, come up with an architecture independent solution.


Please check the explanation that I gave in the other mail. If you check
the patch series, the actual capsule authentication logic has been kept
architecture agnostic, in efi_capsule.c. The fmp protocol is very much
intended for allowing platforms to define their firmware update
routines. Edk2 also has platform specific implementation of the fmp
protocol under the edk2-platforms directory.

-sughosh




My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
for each of the binaries

The protocol implementation then will write the binaries to the device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
(and truncate it if the truncation flag is set)


Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it did.


A block device, a partition, and a file all can be described by an UEFI
media device path.


Sure, from a UEFI media path, but does the underlying U-Boot
implementation have that abstraction?


In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device & file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case. Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.


I would prefer one single FMP driver for all SMC use cases. Everything
device specific should be handled in the secure world.


Not all platforms will be able to put firmware update into the secure
world. For instance, Not many Arm v7 platforms have trustzone accessible
to open source developers. On non-secure platforms (e.g., anything that
loads firmware from a regular filesystem on SD or eMMC) it doesn't make
much sense to loop out to secure firmware when U-Boot owns the
filesystem and the secure world would then need to coordinate with
U-Boot to commit the writes.

All of the code can certainly be in the same location, but I do think
there are three distinct generic backends for firmware updates:
- normal-world file-backed (using filesystem)
- normal-world block-backed (offsets from start of device)
- secure device backed (needs to go into secure world for unpacking and
processing regardless)

There doesn't need to be platform-specific code in any of those back
ends, but they do have different behaviour.



Is there already a protocol defined for the communication of capsule
updates between the firmware and the secure monitor, e.g. in EDK2?


Nothing defined yet (see below)


Would we simply use the UpdateCapsule() call parameters and pass them
via an SMC call?


If secure world is handling the update? Yes, I think a thin
UpdateCapsule() SMC makes sense, with the bonus that UpdateCapsule() at
runtime becomes feasible on U-Boot. There are a couple of people inside
Arm looking at possible interfaces. In this situation there is very
little done in normal-world at all.

[...]



According to my call with Sughosh the whole semihosting thing is about
providing a testing possibility not about any real use case.


Yes, it's for testing, but it is particularly valuable testing because
it allows the host filesystem to be e