Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Andrew On 23/03/24 21:37, Andrew Davis wrote: On 3/22/24 8:10 AM, Neha Malcom Francis wrote: Clean up templatized boot binaries for all K3 boards. This includes modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse code. All k3--binman.dtsi will contain only templates. Only required boot binaries can be built from the templates in the boards' respective -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows clear distinction between the SoC common stuff vs. what is additionally needed to boot up a specific board. Signed-off-by: Neha Malcom Francis --- arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi | 161 +- arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 291 + arch/arm/dts/k3-am625-r5-beagleplay.dts | 39 --- arch/arm/dts/k3-am625-sk-binman.dtsi | 148 + arch/arm/dts/k3-am625-sk-u-boot.dtsi | 42 +++ .../dts/k3-am625-verdin-wifi-dev-binman.dtsi | 296 +- arch/arm/dts/k3-am62a-sk-binman.dtsi | 146 + arch/arm/dts/k3-am62a7-sk-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am642-sk-u-boot.dtsi | 42 +++ arch/arm/dts/k3-am64x-binman.dtsi | 239 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 49 +++ arch/arm/dts/k3-am65x-binman.dtsi | 144 + .../arm/dts/k3-am68-sk-base-board-u-boot.dtsi | 26 ++ arch/arm/dts/k3-am69-sk-u-boot.dtsi | 31 +- arch/arm/dts/k3-binman.dtsi | 96 ++ arch/arm/dts/k3-j7200-binman.dtsi | 145 + .../k3-j7200-common-proc-board-u-boot.dtsi | 40 +++ .../dts/k3-j721e-beagleboneai64-u-boot.dtsi | 154 + arch/arm/dts/k3-j721e-binman.dtsi | 262 +++- .../k3-j721e-common-proc-board-u-boot.dtsi | 84 + arch/arm/dts/k3-j721e-r5-beagleboneai64.dts | 91 +- arch/arm/dts/k3-j721e-sk-u-boot.dtsi | 84 + arch/arm/dts/k3-j721s2-binman.dtsi | 231 +- .../k3-j721s2-common-proc-board-u-boot.dtsi | 42 +++ arch/arm/dts/k3-j784s4-binman.dtsi | 154 + arch/arm/dts/k3-j784s4-evm-u-boot.dtsi | 42 +++ 27 files changed, 858 insertions(+), 2305 deletions(-) diff --git a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi index cca0f44b7d8..fc1898f1510 100644 --- a/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi +++ b/arch/arm/dts/k3-am625-beagleplay-u-boot.dtsi @@ -6,7 +6,11 @@ * Copyright (C) 2022-2023 Robert Nelson, BeagleBoard.org Foundation */ -#include "k3-binman.dtsi" +#define SPL_BOARD_DTB "spl/dts/k3-am625-beagleplay.dtb" +#define BOARD_DESCRIPTION "k3-am625-beagleplay" +#define UBOOT_BOARD_DESCRIPTION "U-Boot for AM625 BeaglePlay" + +#include "k3-am625-sk-binman.dtsi" Why is the BeaglePlay board including the SK binman file? Looks like you made `k3-am625-sk-binman.dtsi` into the SoC general file, which is good, but you should probably also rename it here to match: `k3-am625-binman.dtsi`. Andrew Yes intention was that it's going to be the SoC file, didn't catch on the filename, will change it in v2. Thanks! -- Thanking You Neha Malcom Francis
回复: [PATCH v2 0/6] riscv: add support for Milk-V Mars board
> > The Milk-V Mars board is technically very close to the StarFive VisionFive 2 > board. > > With this patch series the VisionFive 2 U-Boot SPL will detect that it is > running on > a Milk-V board and patch the device-tree accordingly. > This is the same approach that has been taken to handle the differences > between the Visionfive 2 1.2B and 1.3A revisions. > > v2: > do not set default fdt for VisionFive 2 > do not overwrite /soc/i2c@1205/eeprom@50/compatible > Hi Heinrich I will test this series patch first. Next version please cc Hal，He will help to review this series patch. Minda > *** BLURB HERE *** > > Heinrich Schuchardt (6): > riscv: do not set default fdt for VisionFive 2 > eeprom: starfive: function get_product_id_from_eeprom() > riscv: set fdtfile on Milk-V Mars > board: starfive: support Milk-V Mars board > riscv: starfive: avoid including common.h > doc: describe Milk-V Mars board > > arch/riscv/include/asm/arch-jh7110/eeprom.h | 9 ++ > board/starfive/visionfive2/spl.c | 100 ++-- > .../visionfive2/starfive_visionfive2.c| 48 +--- > .../visionfive2/visionfive2-i2c-eeprom.c | 9 +- > configs/starfive_visionfive2_defconfig| 1 - > doc/board/starfive/index.rst | 1 + > doc/board/starfive/milk-v_mars.rst| 111 ++ > doc/board/starfive/visionfive2.rst| 18 +++ > 8 files changed, 268 insertions(+), 29 deletions(-) create mode 100644 > doc/board/starfive/milk-v_mars.rst > > -- > 2.43.0
Re: [PATCH v2 3/3] rockchip: spl: Add SPI NOR flash to boot_devices array
On 2024-03-24 22:23, Jonas Karlman wrote:
On 2024-03-24 21:58, Dragan Simic wrote:
On 2024-03-24 18:28, Jonas Karlman wrote:
On 2024-03-24 17:52, Dragan Simic wrote:
On 2024-03-22 21:50, Jonas Karlman wrote:
diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c
b/arch/arm/mach-rockchip/rk3308/rk3308.c
index 27a748327e31..b3ffabc5449a 100644
--- a/arch/arm/mach-rockchip/rk3308/rk3308.c
+++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
@@ -141,6 +141,7 @@ enum {
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff49",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff4c/flash@0",
AFAICT, no RK3308-based board contains an SPI chip, and I'm not
really
sure where does /spi@ff4c/flash@0 come from.
RK3308 TRM mention that it can boot from the SFC. And yes there is no
upstream board that currently have a jedec,spi-nor node, it however
have the sfc (spi@ff4c) node so this adds correct node path.
Hmm, I see no sfc node in any of the arch/arm/dts/rk3308* files?
Maybe I'm missing something, but there's also no "ff4c" string
in the entire arch/arm/dts directory.
The rk3308 DTs in U-Boot is very outdated so the sfc node cannot be
found in current master branch.
The sfc node is part of linux upstream DT, should also match in
dts/upstream in next branch and after the rk3308 DT sync series [1].
rockchip: rk3308: Sync DT with linux v6.8 and update defconfigs:
[1] https://patchwork.ozlabs.org/cover/1912830/
All good, thanks for explaining it further. Please add
Reviewed-by: Dragan Simic
Re: [PATCH v3 2/3] configs: imx93-phyboard-segin: Add USB support
On 3/24/24 7:00 PM, Fabio Estevam wrote: On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: $ git grep -i usb.*phytec configs configs/phycore_pcl063_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" configs/phycore_pcl063_ull_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" It would be good to be consistent. Also, what is the vendor/product number those two boards use ? They both use: CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 USB VID is 16bit number, the nubmer above is 20bit , drop the leading zero while at it.
Re: [PATCH v2 3/3] rockchip: spl: Add SPI NOR flash to boot_devices array
On 2024-03-24 21:58, Dragan Simic wrote:
> On 2024-03-24 18:28, Jonas Karlman wrote:
>> On 2024-03-24 17:52, Dragan Simic wrote:
>>> Please see my comments below.
>>>
>>> On 2024-03-22 21:50, Jonas Karlman wrote:
Add missing boot source id <-> device tree node path mapping for SPI
NOR
flash on PX30, RK3288, RK3308, RK3368 and RV1126.
Signed-off-by: Jonas Karlman
---
v2:
- New patch
---
arch/arm/mach-rockchip/px30/px30.c | 1 +
arch/arm/mach-rockchip/rk3288/rk3288.c | 1 +
arch/arm/mach-rockchip/rk3308/rk3308.c | 1 +
arch/arm/mach-rockchip/rk3368/rk3368.c | 1 +
arch/arm/mach-rockchip/rv1126/rv1126.c | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-rockchip/px30/px30.c
b/arch/arm/mach-rockchip/px30/px30.c
index b4f655fa4b3e..2ec3289d75b7 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -19,6 +19,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff39",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff3a/flash@0",
>>>
>>> AFAICT, no PX30-based board contains an SPI chip, but making this
>>> future-proof perhaps shouldn't hurt.
>>
>> The rk3326-odroid-go2 variant of PX30 has a jedec,spi-nor node.
>
> Ah, I see, I missed that. Thanks for the clarification.
>
[BROM_BOOTSOURCE_SD] = "/mmc@ff37",
};
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index c77c56c1dab5..70cf50029121 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff13/flash@0",
>>>
>>> Using spi2 for a flash chip applies to some RK3288-based boards, but
>>> AFAICT not to all of them. For example, arch/arm/dts/rk3288-evb.dtsi
>>> uses spi0 for a flash chip, which in turn translates to
>>> /spi@ff11/flash@0. The same also applies to
>>> arch/arm/dts/rk3288-firefly.dtsi, for example.
>>
>> The RK3288 TRM explicitly mention that it can boot from SPI2 CS0.
>>
>> Also I can only find jedec,spi-nor reference in rk3288-phycore-som.dtsi
>> and rk3288-veyron.dtsi, nothing in rk3288-evb.dtsi or
>> rk3288-firefly.dtsi.
>
> Oh, I see now, you're right. I've checked the Firefly-RK3288 schematic
> and it just exposes the spi0 interface on one of its expansion headers.
>
[BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
};
diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c
b/arch/arm/mach-rockchip/rk3308/rk3308.c
index 27a748327e31..b3ffabc5449a 100644
--- a/arch/arm/mach-rockchip/rk3308/rk3308.c
+++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
@@ -141,6 +141,7 @@ enum {
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff49",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff4c/flash@0",
>>>
>>> AFAICT, no RK3308-based board contains an SPI chip, and I'm not really
>>> sure where does /spi@ff4c/flash@0 come from.
>>
>> RK3308 TRM mention that it can boot from the SFC. And yes there is no
>> upstream board that currently have a jedec,spi-nor node, it however
>> have the sfc (spi@ff4c) node so this adds correct node path.
>
> Hmm, I see no sfc node in any of the arch/arm/dts/rk3308* files?
> Maybe I'm missing something, but there's also no "ff4c" string
> in the entire arch/arm/dts directory.
The rk3308 DTs in U-Boot is very outdated so the sfc node cannot be
found in current master branch.
The sfc node is part of linux upstream DT, should also match in
dts/upstream in next branch and after the rk3308 DT sync series [1].
rockchip: rk3308: Sync DT with linux v6.8 and update defconfigs:
[1] https://patchwork.ozlabs.org/cover/1912830/
Regards,
Jonas
Re: [PATCH v2 3/3] rockchip: spl: Add SPI NOR flash to boot_devices array
On 2024-03-24 18:28, Jonas Karlman wrote:
On 2024-03-24 17:52, Dragan Simic wrote:
Please see my comments below.
On 2024-03-22 21:50, Jonas Karlman wrote:
Add missing boot source id <-> device tree node path mapping for SPI
NOR
flash on PX30, RK3288, RK3308, RK3368 and RV1126.
Signed-off-by: Jonas Karlman
---
v2:
- New patch
---
arch/arm/mach-rockchip/px30/px30.c | 1 +
arch/arm/mach-rockchip/rk3288/rk3288.c | 1 +
arch/arm/mach-rockchip/rk3308/rk3308.c | 1 +
arch/arm/mach-rockchip/rk3368/rk3368.c | 1 +
arch/arm/mach-rockchip/rv1126/rv1126.c | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-rockchip/px30/px30.c
b/arch/arm/mach-rockchip/px30/px30.c
index b4f655fa4b3e..2ec3289d75b7 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -19,6 +19,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff39",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff3a/flash@0",
AFAICT, no PX30-based board contains an SPI chip, but making this
future-proof perhaps shouldn't hurt.
The rk3326-odroid-go2 variant of PX30 has a jedec,spi-nor node.
Ah, I see, I missed that. Thanks for the clarification.
[BROM_BOOTSOURCE_SD] = "/mmc@ff37",
};
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index c77c56c1dab5..70cf50029121 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff13/flash@0",
Using spi2 for a flash chip applies to some RK3288-based boards, but
AFAICT not to all of them. For example, arch/arm/dts/rk3288-evb.dtsi
uses spi0 for a flash chip, which in turn translates to
/spi@ff11/flash@0. The same also applies to
arch/arm/dts/rk3288-firefly.dtsi, for example.
The RK3288 TRM explicitly mention that it can boot from SPI2 CS0.
Also I can only find jedec,spi-nor reference in rk3288-phycore-som.dtsi
and rk3288-veyron.dtsi, nothing in rk3288-evb.dtsi or
rk3288-firefly.dtsi.
Oh, I see now, you're right. I've checked the Firefly-RK3288 schematic
and it just exposes the spi0 interface on one of its expansion headers.
[BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
};
diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c
b/arch/arm/mach-rockchip/rk3308/rk3308.c
index 27a748327e31..b3ffabc5449a 100644
--- a/arch/arm/mach-rockchip/rk3308/rk3308.c
+++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
@@ -141,6 +141,7 @@ enum {
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff49",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff4c/flash@0",
AFAICT, no RK3308-based board contains an SPI chip, and I'm not really
sure where does /spi@ff4c/flash@0 come from.
RK3308 TRM mention that it can boot from the SFC. And yes there is no
upstream board that currently have a jedec,spi-nor node, it however
have the sfc (spi@ff4c) node so this adds correct node path.
Hmm, I see no sfc node in any of the arch/arm/dts/rk3308* files?
Maybe I'm missing something, but there's also no "ff4c" string
in the entire arch/arm/dts directory.
Re: [PATCH v2 3/3] rockchip: spl: Add SPI NOR flash to boot_devices array
Hi Dragan,
On 2024-03-24 17:52, Dragan Simic wrote:
> Hello Jonas,
>
> Please see my comments below.
>
> On 2024-03-22 21:50, Jonas Karlman wrote:
>> Add missing boot source id <-> device tree node path mapping for SPI
>> NOR
>> flash on PX30, RK3288, RK3308, RK3368 and RV1126.
>>
>> Signed-off-by: Jonas Karlman
>> ---
>> v2:
>> - New patch
>> ---
>> arch/arm/mach-rockchip/px30/px30.c | 1 +
>> arch/arm/mach-rockchip/rk3288/rk3288.c | 1 +
>> arch/arm/mach-rockchip/rk3308/rk3308.c | 1 +
>> arch/arm/mach-rockchip/rk3368/rk3368.c | 1 +
>> arch/arm/mach-rockchip/rv1126/rv1126.c | 1 +
>> 5 files changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/mach-rockchip/px30/px30.c
>> b/arch/arm/mach-rockchip/px30/px30.c
>> index b4f655fa4b3e..2ec3289d75b7 100644
>> --- a/arch/arm/mach-rockchip/px30/px30.c
>> +++ b/arch/arm/mach-rockchip/px30/px30.c
>> @@ -19,6 +19,7 @@
>>
>> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>> [BROM_BOOTSOURCE_EMMC] = "/mmc@ff39",
>> +[BROM_BOOTSOURCE_SPINOR] = "/spi@ff3a/flash@0",
>
> AFAICT, no PX30-based board contains an SPI chip, but making this
> future-proof perhaps shouldn't hurt.
The rk3326-odroid-go2 variant of PX30 has a jedec,spi-nor node.
>
>> [BROM_BOOTSOURCE_SD] = "/mmc@ff37",
>> };
>>
>> diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
>> b/arch/arm/mach-rockchip/rk3288/rk3288.c
>> index c77c56c1dab5..70cf50029121 100644
>> --- a/arch/arm/mach-rockchip/rk3288/rk3288.c
>> +++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
>> @@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>> [BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
>> +[BROM_BOOTSOURCE_SPINOR] = "/spi@ff13/flash@0",
>
> Using spi2 for a flash chip applies to some RK3288-based boards, but
> AFAICT
> not to all of them. For example, arch/arm/dts/rk3288-evb.dtsi uses spi0
> for a flash chip, which in turn translates to /spi@ff11/flash@0.
> The
> same also applies to arch/arm/dts/rk3288-firefly.dtsi, for example.
The RK3288 TRM explicitly mention that it can boot from SPI2 CS0.
Also I can only find jedec,spi-nor reference in rk3288-phycore-som.dtsi
and rk3288-veyron.dtsi, nothing in rk3288-evb.dtsi or rk3288-firefly.dtsi.
>
>> [BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
>> };
>>
>> diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c
>> b/arch/arm/mach-rockchip/rk3308/rk3308.c
>> index 27a748327e31..b3ffabc5449a 100644
>> --- a/arch/arm/mach-rockchip/rk3308/rk3308.c
>> +++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
>> @@ -141,6 +141,7 @@ enum {
>>
>> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>> [BROM_BOOTSOURCE_EMMC] = "/mmc@ff49",
>> +[BROM_BOOTSOURCE_SPINOR] = "/spi@ff4c/flash@0",
>
> AFAICT, no RK3308-based board contains an SPI chip, and I'm not really
> sure where does /spi@ff4c/flash@0 come from.
RK3308 TRM mention that it can boot from the SFC. And yes there is no
upstream board that currently have a jedec,spi-nor node, it however
have the sfc (spi@ff4c) node so this adds correct node path.
Regards,
Jonas
>
>> [BROM_BOOTSOURCE_SD] = "/mmc@ff48",
>> };
>>
>> diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c
>> b/arch/arm/mach-rockchip/rk3368/rk3368.c
>> index 651ba1090206..8f5ca1dfa7c9 100644
>> --- a/arch/arm/mach-rockchip/rk3368/rk3368.c
>> +++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
>> @@ -55,6 +55,7 @@ struct mm_region *mem_map = rk3368_mem_map;
>>
>> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>> [BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
>> +[BROM_BOOTSOURCE_SPINOR] = "/spi@ff12/flash@0",
>
> This is fine.
>
>> [BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
>> };
>>
>> diff --git a/arch/arm/mach-rockchip/rv1126/rv1126.c
>> b/arch/arm/mach-rockchip/rv1126/rv1126.c
>> index 8589c46f10aa..40eb9eb7b196 100644
>> --- a/arch/arm/mach-rockchip/rv1126/rv1126.c
>> +++ b/arch/arm/mach-rockchip/rv1126/rv1126.c
>> @@ -15,6 +15,7 @@
>>
>> const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
>> [BROM_BOOTSOURCE_EMMC] = "/mmc@ffc5",
>> +[BROM_BOOTSOURCE_SPINOR] = "/spi@ffc9/flash@0",
>
> This is also fine.
>
>> [BROM_BOOTSOURCE_SD] = "/mmc@ffc6",
>> };
Re: [PATCH] board: phytec: phycore_imx8mp.env fix netboot issues
On Fri, Mar 22, 2024 at 9:55 AM Yannic Moog wrote:
>
> The "run netargs" command should come later in the "netboot" command
> order when using dhcp since it sets the server and client ip addresses.
> The previous order led to misconfigured kernel boot params and thus
> kernel panic when serverip was not manually set.
> Further, following Linux FHS 3.0, change the nfsroot default directory
> to /srv/nfs.
>
> Fixes: 60f64bec414e ("board: phytec: phycore_imx8mp: Add fec support")
> Signed-off-by: Yannic Moog
Applied to u-boot-imx/next, thanks.
Re: [PATCH v3 2/3] configs: imx93-phyboard-segin: Add USB support
On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: > $ git grep -i usb.*phytec configs > configs/phycore_pcl063_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" > configs/phycore_pcl063_ull_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" > > It would be good to be consistent. > > Also, what is the vendor/product number those two boards use ? They both use: CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff configs/phycore-imx8mp_defconfig has: CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 I agree we should make this consistent. To not block this series, I applied it, but it would be great if Phytec could submit a separate series making it consistent across their boards. Thanks
Re: [PATCH v3 1/3] arm: dts: imx93-phyboard-segin: Add USB support
On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: > > On 3/21/24 3:45 PM, Mathieu Othacehe wrote: > > Enable both usbotg1 and usbotg2 ports. Disable over-current as OC pins are > > not connected to the SoC. > > > > This > > "This addition to ...-u-boot.dtsi is temporary, ..." would be clearer. I fixed as Marek's suggestion and applied it to u-boot-imx/next, thanks.
Re: [PATCH] imx: ele_ahab: Add ahab_commit command support
On Thu, Mar 21, 2024 at 4:20 AM Mathieu Othacehe wrote: > > This message is used to commit into the fuses any new SRK revocation and > FW version information that have been found into the NXP (ELE FW) and > OEM containers. > > Signed-off-by: Mathieu Othacehe Applied to u-boot-imx/next, thanks.
Re: [PATCH v4 00/11] imx8mp: Enable PCIe/NVMe support
On Fri, Mar 22, 2024 at 10:51 AM Fabio Estevam wrote: > > Hi Sumit, > > On Thu, Mar 21, 2024 at 11:55 AM Sumit Garg wrote: > > > Changes in v4: > > - Incorporated misc comments from Marek and added his review tag. > > - Dropped patch #4 (imx8mp: power-domain: Don't power off pd_bus) > > since power domain off path is never excercised for DT based devices. > > - Added patch#8 as suggested by Peter to describe older pcie_imx.c > > driver as legacy one. > > v4 looks good, thanks. > > I'll wait a few days and will queue it to next. Applied to u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240324
Hi Tom,
Please pull this material for next from u-boot-imx, thanks.
The following changes since commit fb49d6c289d942ff7de309a5c5eaa37a7f4235db:
remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
(2024-03-22 15:50:28 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
tags/u-boot-imx-next-20240324
for you to fetch changes up to 9d27e441bb14dd526c60c13d5ff16353ca322eb3:
board: phytec: phycore_imx8mp.env fix netboot issues (2024-03-24 13:42:10
-0300)
u-boot-imx-next-20240324
--
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20056
- Add ahab_commit command support.
- Add USB support for the imx93-phyboard-segin board.
- Add i.MX8MP PCIe support.
- Fix netboot environment on phycore_imx8mp.
Mathieu Othacehe (4):
imx: ele_ahab: Add ahab_commit command support
arm: dts: imx93-phyboard-segin: Add USB support
configs: imx93-phyboard-segin: Add USB support
configs: imx93-phyboard-segin: Add fastboot support
Sumit Garg (10):
clk: imx8mp: Add support for PCIe clocks
reset: imx: Refactor driver to simplify function names
reset: imx: Add support for i.MX8MP reset controller
imx8mp: power-domain: Add PCIe support
imx8mp: power-domain: Expose high performance PLL clock
phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
pci: Add DW PCIe controller support for iMX8MP SoC
pcie_imx: Update header to describe it as a legacy driver
verdin-imx8mp_defconfig: Enable PCIe/NVMe support
MAINTAINERS: Add entry for PCIe DWC IMX driver
Tim Harvey (1):
imx8mp_venice_defconfig: Enable PCIe/NVMe support
Yannic Moog (1):
board: phytec: phycore_imx8mp.env fix netboot issues
MAINTAINERS| 6 +
arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi | 15 ++
arch/arm/include/asm/mach-imx/ele_api.h| 2 +
arch/arm/mach-imx/ele_ahab.c | 29 +++
board/phytec/phycore_imx8mp/phycore_imx8mp.env | 4 +-
configs/imx8mp_venice_defconfig| 8 +
configs/imx93-phyboard-segin_defconfig | 14 +
configs/verdin-imx8mp_defconfig| 6 +
drivers/clk/imx/clk-imx8mp.c | 6 +
drivers/misc/imx_ele/ele_api.c | 32 +++
drivers/pci/Kconfig| 11 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_dw_imx.c | 338 +
drivers/pci/pcie_imx.c | 8 +
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-imx8m-pcie.c | 283 +
drivers/power/domain/imx8mp-hsiomix.c | 190 +++---
drivers/reset/reset-imx7.c | 143 +--
19 files changed, 1049 insertions(+), 59 deletions(-)
create mode 100644 drivers/pci/pcie_dw_imx.c
create mode 100644 drivers/phy/phy-imx8m-pcie.c
Re: [PATCH v2 2/3] rockchip: spl: Cache boot source id for later use
On 2024-03-22 21:50, Jonas Karlman wrote:
Rockchip BROM writes a boot source id at CFG_IRAM_BASE + 0x10, this id
indicates from what storage media TPL/SPL was loaded from.
SPL uses this id to determine what device "same-as-spl" represent when
determining from where FIT should be loaded. This works as long as the
boot_devices array contain a matching id <-> node path entry.
However, SPL typically load a small part of TF-A into SRAM and on
RK3399
this overwrites the CFG_IRAM_BASE + 0x10 addr used for boot source id.
For affected devices the u-boot,spl-boot-device would not be set when
booting from SPI flash and the flash@0 node was not explicitly listed
in the u-boot,spl-boot-order prop.
Here boot source id is 3 before FIT images is loaded, and 0 after:
U-Boot SPL 2024.04-rc4 (Mar 15 2024 - 17:26:19 +)
board_spl_was_booted_from: brom_bootdevice_id 3 maps to
'/spi@ff1d/flash@0'
Trying to boot from SPI
## Checking hash(es) for config config-1 ... OK
## Checking hash(es) for Image atf-1 ... sha256+ OK
## Checking hash(es) for Image u-boot ... sha256+ OK
## Checking hash(es) for Image fdt-1 ... sha256+ OK
## Checking hash(es) for Image atf-2 ... sha256+ OK
## Checking hash(es) for Image atf-3 ... sha256+ OK
board_spl_was_booted_from: failed to resolve brom_bootdevice_id 0
spl_decode_boot_device: could not find udevice for /mmc@fe33
spl_decode_boot_device: could not find udevice for /mmc@fe32
spl_perform_fixups: could not map boot_device to ofpath: -19
Use a static brom_bootsource_id_cache to save the boot source id after
an initial read from SRAM to fix this, this allow spl_perform_fixups()
to resolve correct boot source path for "same-as-spl" after SPL have
loaded TF-A related FIT images into memory.
With this the spl-boot-device prop can correctly be resolved to the
SPI flash node in the control FDT:
=> fdt addr ${fdtcontroladdr}
Working FDT set to f1ee6710
=> fdt list /chosen
chosen {
u-boot,spl-boot-device = "/spi@ff1d/flash@0";
stdout-path = "serial2:150n8";
u-boot,spl-boot-order = "same-as-spl", "/mmc@fe33",
"/mmc@fe32";
};
Fixes: d57e16c7e712 ("rockchip: find U-boot proper boot device by
inverting the logic that sets it")
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Looking good to me! Thanks for taking the time to implement this
version, as a more robust approach.
Reviewed-by: Dragan Simic
---
v2:
- Only cache boot source id that can be resolved to a node path
- Make use of the new BROM_BOOTSOURCE_UNKNOWN enum value
- Update commit message
- Add fixes tag
- Collect r-b tag
---
arch/arm/mach-rockchip/spl.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-rockchip/spl.c
b/arch/arm/mach-rockchip/spl.c
index 1586a093fc37..3ce7e792b5a2 100644
--- a/arch/arm/mach-rockchip/spl.c
+++ b/arch/arm/mach-rockchip/spl.c
@@ -32,18 +32,26 @@ __weak const char * const
boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
const char *board_spl_was_booted_from(void)
{
- u32 bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+ static u32 brom_bootsource_id_cache = BROM_BOOTSOURCE_UNKNOWN;
+ u32 bootdevice_brom_id;
const char *bootdevice_ofpath = NULL;
+ if (brom_bootsource_id_cache != BROM_BOOTSOURCE_UNKNOWN)
+ bootdevice_brom_id = brom_bootsource_id_cache;
+ else
+ bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);
+
if (bootdevice_brom_id < ARRAY_SIZE(boot_devices))
bootdevice_ofpath = boot_devices[bootdevice_brom_id];
- if (bootdevice_ofpath)
+ if (bootdevice_ofpath) {
+ brom_bootsource_id_cache = bootdevice_brom_id;
debug("%s: brom_bootdevice_id %x maps to '%s'\n",
__func__, bootdevice_brom_id, bootdevice_ofpath);
- else
+ } else {
debug("%s: failed to resolve brom_bootdevice_id %x\n",
__func__, bootdevice_brom_id);
+ }
return bootdevice_ofpath;
}
Re: [PATCH v2 3/3] rockchip: spl: Add SPI NOR flash to boot_devices array
Hello Jonas,
Please see my comments below.
On 2024-03-22 21:50, Jonas Karlman wrote:
Add missing boot source id <-> device tree node path mapping for SPI
NOR
flash on PX30, RK3288, RK3308, RK3368 and RV1126.
Signed-off-by: Jonas Karlman
---
v2:
- New patch
---
arch/arm/mach-rockchip/px30/px30.c | 1 +
arch/arm/mach-rockchip/rk3288/rk3288.c | 1 +
arch/arm/mach-rockchip/rk3308/rk3308.c | 1 +
arch/arm/mach-rockchip/rk3368/rk3368.c | 1 +
arch/arm/mach-rockchip/rv1126/rv1126.c | 1 +
5 files changed, 5 insertions(+)
diff --git a/arch/arm/mach-rockchip/px30/px30.c
b/arch/arm/mach-rockchip/px30/px30.c
index b4f655fa4b3e..2ec3289d75b7 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -19,6 +19,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff39",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff3a/flash@0",
AFAICT, no PX30-based board contains an SPI chip, but making this
future-proof perhaps shouldn't hurt.
[BROM_BOOTSOURCE_SD] = "/mmc@ff37",
};
diff --git a/arch/arm/mach-rockchip/rk3288/rk3288.c
b/arch/arm/mach-rockchip/rk3288/rk3288.c
index c77c56c1dab5..70cf50029121 100644
--- a/arch/arm/mach-rockchip/rk3288/rk3288.c
+++ b/arch/arm/mach-rockchip/rk3288/rk3288.c
@@ -28,6 +28,7 @@ DECLARE_GLOBAL_DATA_PTR;
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff13/flash@0",
Using spi2 for a flash chip applies to some RK3288-based boards, but
AFAICT
not to all of them. For example, arch/arm/dts/rk3288-evb.dtsi uses spi0
for a flash chip, which in turn translates to /spi@ff11/flash@0.
The
same also applies to arch/arm/dts/rk3288-firefly.dtsi, for example.
[BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
};
diff --git a/arch/arm/mach-rockchip/rk3308/rk3308.c
b/arch/arm/mach-rockchip/rk3308/rk3308.c
index 27a748327e31..b3ffabc5449a 100644
--- a/arch/arm/mach-rockchip/rk3308/rk3308.c
+++ b/arch/arm/mach-rockchip/rk3308/rk3308.c
@@ -141,6 +141,7 @@ enum {
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff49",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff4c/flash@0",
AFAICT, no RK3308-based board contains an SPI chip, and I'm not really
sure where does /spi@ff4c/flash@0 come from.
[BROM_BOOTSOURCE_SD] = "/mmc@ff48",
};
diff --git a/arch/arm/mach-rockchip/rk3368/rk3368.c
b/arch/arm/mach-rockchip/rk3368/rk3368.c
index 651ba1090206..8f5ca1dfa7c9 100644
--- a/arch/arm/mach-rockchip/rk3368/rk3368.c
+++ b/arch/arm/mach-rockchip/rk3368/rk3368.c
@@ -55,6 +55,7 @@ struct mm_region *mem_map = rk3368_mem_map;
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ff0f",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ff12/flash@0",
This is fine.
[BROM_BOOTSOURCE_SD] = "/mmc@ff0c",
};
diff --git a/arch/arm/mach-rockchip/rv1126/rv1126.c
b/arch/arm/mach-rockchip/rv1126/rv1126.c
index 8589c46f10aa..40eb9eb7b196 100644
--- a/arch/arm/mach-rockchip/rv1126/rv1126.c
+++ b/arch/arm/mach-rockchip/rv1126/rv1126.c
@@ -15,6 +15,7 @@
const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@ffc5",
+ [BROM_BOOTSOURCE_SPINOR] = "/spi@ffc9/flash@0",
This is also fine.
[BROM_BOOTSOURCE_SD] = "/mmc@ffc6",
};
Re: [PATCH v2 1/3] rockchip: bootrom: Sync bootsource id enum from bootrom
On 2024-03-22 21:50, Jonas Karlman wrote:
From: Jason Zhu
Add more bootsource id:
1. BROM_BOOTSOURCE_UNKNOWN
2. BROM_BOOTSOURCE_I2C
3. BROM_BOOTSOURCE_SPI
Signed-off-by: Jason Zhu
[jo...@kwiboo.se: Update commit message]
Signed-off-by: Jonas Karlman
Looking good to me.
Reviewed-by: Dragan Simic
---
v2:
- New patch
---
arch/arm/include/asm/arch-rockchip/bootrom.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
b/arch/arm/include/asm/arch-rockchip/bootrom.h
index 4276a0f6811a..ecf3b4e7428c 100644
--- a/arch/arm/include/asm/arch-rockchip/bootrom.h
+++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
@@ -43,11 +43,14 @@ void back_to_bootrom(enum rockchip_bootrom_cmd
brom_cmd);
* Boot-device identifiers as used by the BROM
*/
enum {
+ BROM_BOOTSOURCE_UNKNOWN = 0,
BROM_BOOTSOURCE_NAND = 1,
BROM_BOOTSOURCE_EMMC = 2,
BROM_BOOTSOURCE_SPINOR = 3,
BROM_BOOTSOURCE_SPINAND = 4,
BROM_BOOTSOURCE_SD = 5,
+ BROM_BOOTSOURCE_I2C = 8,
+ BROM_BOOTSOURCE_SPI = 9,
BROM_BOOTSOURCE_USB = 10,
BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
};
[PATCH v2 2/2] board: amlogic: add meson_generate_serial_ethaddr fallback to p200
Add a fall-back method to generate ethaddr from CPU serial on p200 boards
if the MAC cannot be read from efuse. This prevents random MAC addresses
on the WeTek Hub/Play2 boards.
Signed-off-by: Christian Hewitt
---
board/amlogic/p200/p200.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/board/amlogic/p200/p200.c b/board/amlogic/p200/p200.c
index 7c432f9d281..3061f7a6b3c 100644
--- a/board/amlogic/p200/p200.c
+++ b/board/amlogic/p200/p200.c
@@ -30,6 +30,8 @@ int misc_init_r(void)
mac_addr, EFUSE_MAC_SIZE);
if (len == EFUSE_MAC_SIZE && is_valid_ethaddr(mac_addr))
eth_env_set_enetaddr("ethaddr", mac_addr);
+ else
+ meson_generate_serial_ethaddr();
}
if (!env_get("serial#")) {
--
2.34.1
[PATCH v2 1/2] ARM: dts: fix Ethernet on WeTek Hub/Play2
Placing the snps,reset content needed for Ethernet to probe in a common
uboot.dtsi results in the content not being used and broken Ethernet. Fix
this by creating two board specific dtsi files with the right content.
Fixes: 67d5128df950 ("ARM: dts: add support for WeTek Hub and WeTek Play2")
Signed-off-by: Christian Hewitt
---
...u-boot.dtsi => meson-gxbb-wetek-hub-u-boot.dtsi} | 0
arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi | 13 +
2 files changed, 13 insertions(+)
rename arch/arm/dts/{meson-gxbb-wetek-u-boot.dtsi =>
meson-gxbb-wetek-hub-u-boot.dtsi} (100%)
create mode 100644 arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
diff --git a/arch/arm/dts/meson-gxbb-wetek-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-wetek-hub-u-boot.dtsi
similarity index 100%
rename from arch/arm/dts/meson-gxbb-wetek-u-boot.dtsi
rename to arch/arm/dts/meson-gxbb-wetek-hub-u-boot.dtsi
diff --git a/arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
b/arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
new file mode 100644
index 000..3743053eb9c
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS.
+ * Author: Neil Armstrong
+ */
+
+#include "meson-gx-u-boot.dtsi"
+
+ {
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+};
--
2.34.1
[PATCH v2 0/2] ARM: dts: fix Ethernet and random MAC's on WeTek Hub/Play2
In submitting the original patches for WeTek Hub/Play2 I appear to have
squashed an experimental change to place the u-boot.dtsi file on the common
board dtsi, but this was incorrect and results in broken Ethernet. Patch 1
creates per-board u-boot.dtsi files to fix that. However, while the NIC is
now probed correctly the current p200.c board file doesn't find the MAC in
efuse and we get random MAC addresses. Patch 2 adds a fallback method for
generating a MAC from the CPU serial.
Changes from v1:
- Simplified p200.c changes
- Drop patch 3
Christian Hewitt (2):
ARM: dts: fix Ethernet on WeTek Hub/Play2
board: amlogic: add meson_generate_serial_ethaddr fallback to p200
...u-boot.dtsi => meson-gxbb-wetek-hub-u-boot.dtsi} | 0
arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi | 13 +
board/amlogic/p200/p200.c | 2 ++
3 files changed, 15 insertions(+)
rename arch/arm/dts/{meson-gxbb-wetek-u-boot.dtsi =>
meson-gxbb-wetek-hub-u-boot.dtsi} (100%)
create mode 100644 arch/arm/dts/meson-gxbb-wetek-play2-u-boot.dtsi
--
2.34.1
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
On 2024-03-21 19:11, Heinrich Schuchardt wrote: > The differences between the Milk-V Mars board and the VisionFive 2 board > are small enough that we can support both using the same U-Boot build. > > * The model and compatible property are taken from proposed Linux patches. > * The EEPROM is atmel,24c02 according to the vendor U-Boot. > * The second Ethernet port is not available. From the device tree that have been submitted to the kernel [1] it seems another difference is that there is a CD gpio for mmc1. From the schematics, it also seems that the usb0 port is not in peripheral mode, but in host mode. That said on the submitted kernel device tree it seems simply disabled. Aurelien [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszh...@kernel.org/T/ -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
