Message ID | 20240816213429.1093-2-naoki@radxa.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [v5,1/2] dt-bindings: arm: rockchip: add support for Radxa ROCK Pi E v3.0 | expand |
Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: > Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip > RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations: > > - Rockchip RK3328 SoC > - Quad A53 CPU > - 512MB/1GB/2GB DDR4 RAM > - 4/8/16/32GB eMMC > - Micro SD Card slot > - WiFi 4 and BT 4, or WiFi 5 and BT 5 > - 1x 1000M Ethernet supporting PoE with add‑on PoE HAT > - 1x 100M Ethernet > - 1x USB 3.0 Type-A port (Host) > - 1x 4-ring 3.5mm headphone jack > - 40 Pin GPIO header > > [1] https://radxa.com/products/rockpi/pie > > Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> > --- > Changes in v5: > - revert compatible string > Changes in v4: > - update compatible string for OpenWrt > Changes in v3: > - fix conflict for recent change > Changes in v2: > - fix typo in commit message > - add missing --- in commit message > --- > arch/arm64/boot/dts/rockchip/Makefile | 1 + > .../boot/dts/rockchip/rk3328-rock-pi-e-v3.dts | 15 + > .../boot/dts/rockchip/rk3328-rock-pi-e.dts | 460 +----------------- > ...28-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} | 5 - > 4 files changed, 31 insertions(+), 450 deletions(-) > create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts > rewrite arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts (97%) > copy arch/arm64/boot/dts/rockchip/{rk3328-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} (98%) > > diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile > index cb309b1975ba..cc74cd17850a 100644 > --- a/arch/arm64/boot/dts/rockchip/Makefile > +++ b/arch/arm64/boot/dts/rockchip/Makefile > @@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s-plus.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus-lts.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e-v3.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-pc.dtb > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts > new file mode 100644 > index 000000000000..ad9c4c562914 > --- /dev/null > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts > @@ -0,0 +1,15 @@ > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + > +/dts-v1/; > + > +#include "rk3328-rock-pi-e.dtsi" > + > +/ { > + model = "Radxa ROCK Pi E v3.0"; > + compatible = "radxa,rockpi-e-v3", "rockchip,rk3328"; > + > + aliases { > + mmc0 = &emmc; > + mmc1 = &sdmmc; > + }; > +}; > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts > dissimilarity index 97% > index 3e08e2fd0a78..0929df3c803a 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts > +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts > @@ -1,445 +1,15 @@ [...] > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > + > +/dts-v1/; > + > +#include "rk3328-rock-pi-e.dtsi" > + > +/ { > + model = "Radxa ROCK Pi E"; > + compatible = "radxa,rockpi-e", "rockchip,rk3328"; > + > + aliases { > + mmc0 = &sdmmc; > + mmc1 = &emmc; > + }; > +}; can you please describe what is different in that v3 board? Describing what is different to require a separate board should've been part of the commit message. Because from those changes, the bottom line currently seems to be the same board with swapped mmc aliases? Heiko
Hi, On 8/17/24 07:11, Heiko Stübner wrote: > Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip >> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations: >> >> - Rockchip RK3328 SoC >> - Quad A53 CPU >> - 512MB/1GB/2GB DDR4 RAM (snip) > can you please describe what is different in that v3 board? > Describing what is different to require a separate board should've been > part of the commit message. > > Because from those changes, the bottom line currently seems to be > the same board with swapped mmc aliases? it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). different bootloader (U-Boot) is required. adding v3 dts seems not to be so important for Linux, but it's very important for U-Boot and OpenWrt(it includes bootloader for distributed binary). Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. > Heiko > > > > >
Hello Fukaumi, On 2024-08-17 00:20, FUKAUMI Naoki wrote: > On 8/17/24 07:11, Heiko Stübner wrote: >> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>> Rockchip >>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>> configurations: >>> >>> - Rockchip RK3328 SoC >>> - Quad A53 CPU >>> - 512MB/1GB/2GB DDR4 RAM > (snip) >> can you please describe what is different in that v3 board? >> Describing what is different to require a separate board should've >> been >> part of the commit message. >> >> Because from those changes, the bottom line currently seems to be >> the same board with swapped mmc aliases? > > it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). > different bootloader (U-Boot) is required. > > adding v3 dts seems not to be so important for Linux, but it's very > important for U-Boot and OpenWrt(it includes bootloader for > distributed binary). Aren't there different methods that allow such board variants to be supported in U-Boot, with no need for a separate DT in the kernel? IIRC, there are already more than a few examples of such board variants, which require different DRAM initialization, which is covered in U-Boot by providing different builds that use the same DT.
On 2024-08-17 21:28, Dragan Simic wrote: > Hello Fukaumi, > > On 2024-08-17 00:20, FUKAUMI Naoki wrote: >> On 8/17/24 07:11, Heiko Stübner wrote: >>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>> Rockchip >>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>> configurations: >>>> >>>> - Rockchip RK3328 SoC >>>> - Quad A53 CPU >>>> - 512MB/1GB/2GB DDR4 RAM >> (snip) >>> can you please describe what is different in that v3 board? >>> Describing what is different to require a separate board should've >>> been >>> part of the commit message. >>> >>> Because from those changes, the bottom line currently seems to be >>> the same board with swapped mmc aliases? >> >> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >> different bootloader (U-Boot) is required. >> >> adding v3 dts seems not to be so important for Linux, but it's very >> important for U-Boot and OpenWrt(it includes bootloader for >> distributed binary). > > Aren't there different methods that allow such board variants to be > supported in U-Boot, with no need for a separate DT in the kernel? > IIRC, there are already more than a few examples of such board > variants, > which require different DRAM initialization, which is covered in U-Boot > by providing different builds that use the same DT. As an example, please have a look at the following files in U-Boot: - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi - configs/nanopi-m4-rk3399_defconfig - configs/nanopi-m4-2gb-rk3399_defconfig Basically, there's no need for separate DTs in the kernel, just to support board variants with different DRAM types in U-Boot.
Hi, On 8/18/24 04:51, Dragan Simic wrote: > On 2024-08-17 21:28, Dragan Simic wrote: >> Hello Fukaumi, >> >> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>> On 8/17/24 07:11, Heiko Stübner wrote: >>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip >>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations: >>>>> >>>>> - Rockchip RK3328 SoC >>>>> - Quad A53 CPU >>>>> - 512MB/1GB/2GB DDR4 RAM >>> (snip) >>>> can you please describe what is different in that v3 board? >>>> Describing what is different to require a separate board should've been >>>> part of the commit message. >>>> >>>> Because from those changes, the bottom line currently seems to be >>>> the same board with swapped mmc aliases? >>> >>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>> different bootloader (U-Boot) is required. >>> >>> adding v3 dts seems not to be so important for Linux, but it's very >>> important for U-Boot and OpenWrt(it includes bootloader for >>> distributed binary). >> >> Aren't there different methods that allow such board variants to be >> supported in U-Boot, with no need for a separate DT in the kernel? >> IIRC, there are already more than a few examples of such board variants, >> which require different DRAM initialization, which is covered in U-Boot >> by providing different builds that use the same DT. > > As an example, please have a look at the following files in U-Boot: > > - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi > - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi > - configs/nanopi-m4-rk3399_defconfig > - configs/nanopi-m4-2gb-rk3399_defconfig > > Basically, there's no need for separate DTs in the kernel, just to support > board variants with different DRAM types in U-Boot. OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" string to validate new firmware file is surely "for this board". currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong firmware (include bootloaer, U-Boot) possible. Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different incompatible boards, it must have different "compatible" string. Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd.
On 8/18/24 05:04, FUKAUMI Naoki wrote: > Hi, > > On 8/18/24 04:51, Dragan Simic wrote: >> On 2024-08-17 21:28, Dragan Simic wrote: >>> Hello Fukaumi, >>> >>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>> Rockchip >>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>> configurations: >>>>>> >>>>>> - Rockchip RK3328 SoC >>>>>> - Quad A53 CPU >>>>>> - 512MB/1GB/2GB DDR4 RAM >>>> (snip) >>>>> can you please describe what is different in that v3 board? >>>>> Describing what is different to require a separate board should've >>>>> been >>>>> part of the commit message. >>>>> >>>>> Because from those changes, the bottom line currently seems to be >>>>> the same board with swapped mmc aliases? >>>> >>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>> different bootloader (U-Boot) is required. >>>> >>>> adding v3 dts seems not to be so important for Linux, but it's very >>>> important for U-Boot and OpenWrt(it includes bootloader for >>>> distributed binary). >>> >>> Aren't there different methods that allow such board variants to be >>> supported in U-Boot, with no need for a separate DT in the kernel? >>> IIRC, there are already more than a few examples of such board variants, >>> which require different DRAM initialization, which is covered in U-Boot >>> by providing different builds that use the same DT. >> >> As an example, please have a look at the following files in U-Boot: >> >> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >> - configs/nanopi-m4-rk3399_defconfig >> - configs/nanopi-m4-2gb-rk3399_defconfig >> >> Basically, there's no need for separate DTs in the kernel, just to >> support >> board variants with different DRAM types in U-Boot. > > OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" string > to validate new firmware file is surely "for this board". > > currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong > firmware (include bootloaer, U-Boot) possible. ^Currently both Pi E firmware have ... > Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different > incompatible boards, it must have different "compatible" string. > > Best regards, > > -- > FUKAUMI Naoki > Radxa Computer (Shenzhen) Co., Ltd.
On 2024-08-17 22:04, FUKAUMI Naoki wrote: > On 8/18/24 04:51, Dragan Simic wrote: >> On 2024-08-17 21:28, Dragan Simic wrote: >>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>> Rockchip >>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>> configurations: >>>>>> >>>>>> - Rockchip RK3328 SoC >>>>>> - Quad A53 CPU >>>>>> - 512MB/1GB/2GB DDR4 RAM >>>> (snip) >>>>> can you please describe what is different in that v3 board? >>>>> Describing what is different to require a separate board should've >>>>> been >>>>> part of the commit message. >>>>> >>>>> Because from those changes, the bottom line currently seems to be >>>>> the same board with swapped mmc aliases? >>>> >>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>> different bootloader (U-Boot) is required. >>>> >>>> adding v3 dts seems not to be so important for Linux, but it's very >>>> important for U-Boot and OpenWrt(it includes bootloader for >>>> distributed binary). >>> >>> Aren't there different methods that allow such board variants to be >>> supported in U-Boot, with no need for a separate DT in the kernel? >>> IIRC, there are already more than a few examples of such board >>> variants, >>> which require different DRAM initialization, which is covered in >>> U-Boot >>> by providing different builds that use the same DT. >> >> As an example, please have a look at the following files in U-Boot: >> >> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >> - configs/nanopi-m4-rk3399_defconfig >> - configs/nanopi-m4-2gb-rk3399_defconfig >> >> Basically, there's no need for separate DTs in the kernel, just to >> support >> board variants with different DRAM types in U-Boot. > > OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" > string to validate new firmware file is surely "for this board". > > currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong > firmware (include bootloaer, U-Boot) possible. Could you, please, explain what's the actual issue with OpenWrt? I did read some GitHub issue that described it, IIRC, but I was unable to fully understand what's the underlying issue. > Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different > incompatible boards, it must have different "compatible" string. Well, the above-mentioned Nano Pi M4 boards share the same DT and the same "compatible" value, because for all consumers of the DT, except for U-Boot that can already handle the differences, they are the same boards.
On 8/18/24 05:12, Dragan Simic wrote: > On 2024-08-17 22:04, FUKAUMI Naoki wrote: >> On 8/18/24 04:51, Dragan Simic wrote: >>> On 2024-08-17 21:28, Dragan Simic wrote: >>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>>> Rockchip >>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>>> configurations: >>>>>>> >>>>>>> - Rockchip RK3328 SoC >>>>>>> - Quad A53 CPU >>>>>>> - 512MB/1GB/2GB DDR4 RAM >>>>> (snip) >>>>>> can you please describe what is different in that v3 board? >>>>>> Describing what is different to require a separate board should've >>>>>> been >>>>>> part of the commit message. >>>>>> >>>>>> Because from those changes, the bottom line currently seems to be >>>>>> the same board with swapped mmc aliases? >>>>> >>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>>> different bootloader (U-Boot) is required. >>>>> >>>>> adding v3 dts seems not to be so important for Linux, but it's very >>>>> important for U-Boot and OpenWrt(it includes bootloader for >>>>> distributed binary). >>>> >>>> Aren't there different methods that allow such board variants to be >>>> supported in U-Boot, with no need for a separate DT in the kernel? >>>> IIRC, there are already more than a few examples of such board >>>> variants, >>>> which require different DRAM initialization, which is covered in U-Boot >>>> by providing different builds that use the same DT. >>> >>> As an example, please have a look at the following files in U-Boot: >>> >>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >>> - configs/nanopi-m4-rk3399_defconfig >>> - configs/nanopi-m4-2gb-rk3399_defconfig >>> >>> Basically, there's no need for separate DTs in the kernel, just to >>> support >>> board variants with different DRAM types in U-Boot. >> >> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" >> string to validate new firmware file is surely "for this board". >> >> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong >> firmware (include bootloaer, U-Boot) possible. > > Could you, please, explain what's the actual issue with OpenWrt? I did > read some GitHub issue that described it, IIRC, but I was unable to fully > understand what's the underlying issue. $ wget https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz $ strings openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep metadata { "metadata_version": "1.1", "compat_version": "1.0", "supported_devices":["radxa,rock-pi-e"], "version": { "dist": "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } } $ wget https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz $ strings openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | grep metadata { "metadata_version": "1.1", "compat_version": "1.0", "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } } since they are incompatible firmware, it needs to have different "supported_devices" string. if both are "radxa,rockpi-e", firmware validation will not work correctly. (currently both values are wrong, it needs to be fixed, but it's another story) >> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different >> incompatible boards, it must have different "compatible" string. > > Well, the above-mentioned Nano Pi M4 boards share the same DT and the same > "compatible" value, because for all consumers of the DT, except for U-Boot > that can already handle the differences, they are the same boards. (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd.
for the record, https://openwrt.org/docs/guide-developer/device-support-policies#modeldevice_name https://openwrt.org/docs/techref/sysupgrade -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. On 8/18/24 05:28, FUKAUMI Naoki wrote: > On 8/18/24 05:12, Dragan Simic wrote: >> On 2024-08-17 22:04, FUKAUMI Naoki wrote: >>> On 8/18/24 04:51, Dragan Simic wrote: >>>> On 2024-08-17 21:28, Dragan Simic wrote: >>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>>>> Rockchip >>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>>>> configurations: >>>>>>>> >>>>>>>> - Rockchip RK3328 SoC >>>>>>>> - Quad A53 CPU >>>>>>>> - 512MB/1GB/2GB DDR4 RAM >>>>>> (snip) >>>>>>> can you please describe what is different in that v3 board? >>>>>>> Describing what is different to require a separate board >>>>>>> should've been >>>>>>> part of the commit message. >>>>>>> >>>>>>> Because from those changes, the bottom line currently seems to be >>>>>>> the same board with swapped mmc aliases? >>>>>> >>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>>>> different bootloader (U-Boot) is required. >>>>>> >>>>>> adding v3 dts seems not to be so important for Linux, but it's very >>>>>> important for U-Boot and OpenWrt(it includes bootloader for >>>>>> distributed binary). >>>>> >>>>> Aren't there different methods that allow such board variants to be >>>>> supported in U-Boot, with no need for a separate DT in the kernel? >>>>> IIRC, there are already more than a few examples of such board >>>>> variants, >>>>> which require different DRAM initialization, which is covered in >>>>> U-Boot >>>>> by providing different builds that use the same DT. >>>> >>>> As an example, please have a look at the following files in U-Boot: >>>> >>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >>>> - configs/nanopi-m4-rk3399_defconfig >>>> - configs/nanopi-m4-2gb-rk3399_defconfig >>>> >>>> Basically, there's no need for separate DTs in the kernel, just to >>>> support >>>> board variants with different DRAM types in U-Boot. >>> >>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" >>> string to validate new firmware file is surely "for this board". >>> >>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong >>> firmware (include bootloaer, U-Boot) possible. >> >> Could you, please, explain what's the actual issue with OpenWrt? I did >> read some GitHub issue that described it, IIRC, but I was unable to fully >> understand what's the underlying issue. > > $ wget > https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz > $ strings openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz > | grep metadata > { "metadata_version": "1.1", "compat_version": "1.0", > "supported_devices":["radxa,rock-pi-e"], "version": { "dist": "OpenWrt", > "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", "target": > "rockchip/armv8", "board": "radxa_rock-pi-e" } } > > $ wget > https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz > $ strings > openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | grep > metadata > { "metadata_version": "1.1", "compat_version": "1.0", > "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": > "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", > "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } } > > since they are incompatible firmware, it needs to have different > "supported_devices" string. if both are "radxa,rockpi-e", firmware > validation will not work correctly. > > (currently both values are wrong, it needs to be fixed, but it's another > story) > >>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different >>> incompatible boards, it must have different "compatible" string. >> >> Well, the above-mentioned Nano Pi M4 boards share the same DT and the >> same >> "compatible" value, because for all consumers of the DT, except for >> U-Boot >> that can already handle the differences, they are the same boards. > > (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt > > https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ > > Best regards, > > -- > FUKAUMI Naoki > Radxa Computer (Shenzhen) Co., Ltd.
On 2024-08-17 22:28, FUKAUMI Naoki wrote: > On 8/18/24 05:12, Dragan Simic wrote: >> On 2024-08-17 22:04, FUKAUMI Naoki wrote: >>> On 8/18/24 04:51, Dragan Simic wrote: >>>> On 2024-08-17 21:28, Dragan Simic wrote: >>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>>>> Rockchip >>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>>>> configurations: >>>>>>>> >>>>>>>> - Rockchip RK3328 SoC >>>>>>>> - Quad A53 CPU >>>>>>>> - 512MB/1GB/2GB DDR4 RAM >>>>>> (snip) >>>>>>> can you please describe what is different in that v3 board? >>>>>>> Describing what is different to require a separate board >>>>>>> should've been >>>>>>> part of the commit message. >>>>>>> >>>>>>> Because from those changes, the bottom line currently seems to be >>>>>>> the same board with swapped mmc aliases? >>>>>> >>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>>>> different bootloader (U-Boot) is required. >>>>>> >>>>>> adding v3 dts seems not to be so important for Linux, but it's >>>>>> very >>>>>> important for U-Boot and OpenWrt(it includes bootloader for >>>>>> distributed binary). >>>>> >>>>> Aren't there different methods that allow such board variants to be >>>>> supported in U-Boot, with no need for a separate DT in the kernel? >>>>> IIRC, there are already more than a few examples of such board >>>>> variants, >>>>> which require different DRAM initialization, which is covered in >>>>> U-Boot >>>>> by providing different builds that use the same DT. >>>> >>>> As an example, please have a look at the following files in U-Boot: >>>> >>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >>>> - configs/nanopi-m4-rk3399_defconfig >>>> - configs/nanopi-m4-2gb-rk3399_defconfig >>>> >>>> Basically, there's no need for separate DTs in the kernel, just to >>>> support >>>> board variants with different DRAM types in U-Boot. >>> >>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" >>> string to validate new firmware file is surely "for this board". >>> >>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing >>> wrong >>> firmware (include bootloaer, U-Boot) possible. >> >> Could you, please, explain what's the actual issue with OpenWrt? I >> did >> read some GitHub issue that described it, IIRC, but I was unable to >> fully >> understand what's the underlying issue. > > $ wget > https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz > $ strings > openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep > metadata > { "metadata_version": "1.1", "compat_version": "1.0", > "supported_devices":["radxa,rock-pi-e"], "version": { "dist": > "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", > "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } } > > $ wget > https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz > $ strings > openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | > grep metadata > { "metadata_version": "1.1", "compat_version": "1.0", > "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": > "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", > "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } } > > since they are incompatible firmware, it needs to have different > "supported_devices" string. if both are "radxa,rockpi-e", firmware > validation will not work correctly. > > (currently both values are wrong, it needs to be fixed, but it's > another story) > >>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different >>> incompatible boards, it must have different "compatible" string. >> >> Well, the above-mentioned Nano Pi M4 boards share the same DT and the >> same >> "compatible" value, because for all consumers of the DT, except for >> U-Boot >> that can already handle the differences, they are the same boards. > > (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt > > https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ Thanks for the explanations. As discussed further in #linux-rockchip on Libera.Chat, we do need a general solution for this issue, which would get us covered for all the board variants that use different DRAM chips, which are currently known to U-Boot only. I'll keep thinking about this in the next couple of days, and I'll come back with an update.
Hello Naoki, On 2024-08-18 00:30, Dragan Simic wrote: > On 2024-08-17 22:28, FUKAUMI Naoki wrote: >> On 8/18/24 05:12, Dragan Simic wrote: >>> On 2024-08-17 22:04, FUKAUMI Naoki wrote: >>>> On 8/18/24 04:51, Dragan Simic wrote: >>>>> On 2024-08-17 21:28, Dragan Simic wrote: >>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>>>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI >>>>>>>> Naoki: >>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>>>>> Rockchip >>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>>>>> configurations: >>>>>>>>> >>>>>>>>> - Rockchip RK3328 SoC >>>>>>>>> - Quad A53 CPU >>>>>>>>> - 512MB/1GB/2GB DDR4 RAM >>>>>>> (snip) >>>>>>>> can you please describe what is different in that v3 board? >>>>>>>> Describing what is different to require a separate board >>>>>>>> should've been >>>>>>>> part of the commit message. >>>>>>>> >>>>>>>> Because from those changes, the bottom line currently seems to >>>>>>>> be >>>>>>>> the same board with swapped mmc aliases? >>>>>>> >>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>>>>> different bootloader (U-Boot) is required. >>>>>>> >>>>>>> adding v3 dts seems not to be so important for Linux, but it's >>>>>>> very >>>>>>> important for U-Boot and OpenWrt(it includes bootloader for >>>>>>> distributed binary). >>>>>> >>>>>> Aren't there different methods that allow such board variants to >>>>>> be >>>>>> supported in U-Boot, with no need for a separate DT in the kernel? >>>>>> IIRC, there are already more than a few examples of such board >>>>>> variants, >>>>>> which require different DRAM initialization, which is covered in >>>>>> U-Boot >>>>>> by providing different builds that use the same DT. >>>>> >>>>> As an example, please have a look at the following files in U-Boot: >>>>> >>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >>>>> - configs/nanopi-m4-rk3399_defconfig >>>>> - configs/nanopi-m4-2gb-rk3399_defconfig >>>>> >>>>> Basically, there's no need for separate DTs in the kernel, just to >>>>> support >>>>> board variants with different DRAM types in U-Boot. >>>> >>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" >>>> string to validate new firmware file is surely "for this board". >>>> >>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing >>>> wrong >>>> firmware (include bootloaer, U-Boot) possible. >>> >>> Could you, please, explain what's the actual issue with OpenWrt? I >>> did >>> read some GitHub issue that described it, IIRC, but I was unable to >>> fully >>> understand what's the underlying issue. >> >> $ wget >> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz >> $ strings >> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep >> metadata >> { "metadata_version": "1.1", "compat_version": "1.0", >> "supported_devices":["radxa,rock-pi-e"], "version": { "dist": >> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", >> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } } >> >> $ wget >> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz >> $ strings >> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | >> grep metadata >> { "metadata_version": "1.1", "compat_version": "1.0", >> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": >> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", >> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } } >> >> since they are incompatible firmware, it needs to have different >> "supported_devices" string. if both are "radxa,rockpi-e", firmware >> validation will not work correctly. >> >> (currently both values are wrong, it needs to be fixed, but it's >> another story) >> >>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different >>>> incompatible boards, it must have different "compatible" string. >>> >>> Well, the above-mentioned Nano Pi M4 boards share the same DT and the >>> same >>> "compatible" value, because for all consumers of the DT, except for >>> U-Boot >>> that can already handle the differences, they are the same boards. >> >> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt >> >> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ > > Thanks for the explanations. As discussed further in #linux-rockchip > on Libera.Chat, we do need a general solution for this issue, which > would > get us covered for all the board variants that use different DRAM > chips, > which are currently known to U-Boot only. > > I'll keep thinking about this in the next couple of days, and I'll come > back with an update. As a separate thought, is there some way to detect the actual ROCK Pi E board variant at runtime, using some GPIO line, ADC readout, or something similar? That would help with making it possible to have a single U-Boot build for both board variants.
Hi, On 8/26/24 20:25, Dragan Simic wrote: > Hello Naoki, > > On 2024-08-18 00:30, Dragan Simic wrote: >> On 2024-08-17 22:28, FUKAUMI Naoki wrote: >>> On 8/18/24 05:12, Dragan Simic wrote: >>>> On 2024-08-17 22:04, FUKAUMI Naoki wrote: >>>>> On 8/18/24 04:51, Dragan Simic wrote: >>>>>> On 2024-08-17 21:28, Dragan Simic wrote: >>>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>>>>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>>>>>> Rockchip >>>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>>>>>> configurations: >>>>>>>>>> >>>>>>>>>> - Rockchip RK3328 SoC >>>>>>>>>> - Quad A53 CPU >>>>>>>>>> - 512MB/1GB/2GB DDR4 RAM >>>>>>>> (snip) >>>>>>>>> can you please describe what is different in that v3 board? >>>>>>>>> Describing what is different to require a separate board >>>>>>>>> should've been >>>>>>>>> part of the commit message. >>>>>>>>> >>>>>>>>> Because from those changes, the bottom line currently seems to be >>>>>>>>> the same board with swapped mmc aliases? >>>>>>>> >>>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>>>>>> different bootloader (U-Boot) is required. >>>>>>>> >>>>>>>> adding v3 dts seems not to be so important for Linux, but it's very >>>>>>>> important for U-Boot and OpenWrt(it includes bootloader for >>>>>>>> distributed binary). >>>>>>> >>>>>>> Aren't there different methods that allow such board variants to be >>>>>>> supported in U-Boot, with no need for a separate DT in the kernel? >>>>>>> IIRC, there are already more than a few examples of such board >>>>>>> variants, >>>>>>> which require different DRAM initialization, which is covered in >>>>>>> U-Boot >>>>>>> by providing different builds that use the same DT. >>>>>> >>>>>> As an example, please have a look at the following files in U-Boot: >>>>>> >>>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >>>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >>>>>> - configs/nanopi-m4-rk3399_defconfig >>>>>> - configs/nanopi-m4-2gb-rk3399_defconfig >>>>>> >>>>>> Basically, there's no need for separate DTs in the kernel, just to >>>>>> support >>>>>> board variants with different DRAM types in U-Boot. >>>>> >>>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" >>>>> string to validate new firmware file is surely "for this board". >>>>> >>>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong >>>>> firmware (include bootloaer, U-Boot) possible. >>>> >>>> Could you, please, explain what's the actual issue with OpenWrt? I did >>>> read some GitHub issue that described it, IIRC, but I was unable to >>>> fully >>>> understand what's the underlying issue. >>> >>> $ wget >>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz >>> $ strings >>> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep >>> metadata >>> { "metadata_version": "1.1", "compat_version": "1.0", >>> "supported_devices":["radxa,rock-pi-e"], "version": { "dist": >>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", >>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } } >>> >>> $ wget >>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz >>> $ strings >>> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | >>> grep metadata >>> { "metadata_version": "1.1", "compat_version": "1.0", >>> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": >>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", >>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } } >>> >>> since they are incompatible firmware, it needs to have different >>> "supported_devices" string. if both are "radxa,rockpi-e", firmware >>> validation will not work correctly. >>> >>> (currently both values are wrong, it needs to be fixed, but it's >>> another story) >>> >>>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different >>>>> incompatible boards, it must have different "compatible" string. >>>> >>>> Well, the above-mentioned Nano Pi M4 boards share the same DT and >>>> the same >>>> "compatible" value, because for all consumers of the DT, except for >>>> U-Boot >>>> that can already handle the differences, they are the same boards. >>> >>> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt >>> >>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ >> >> Thanks for the explanations. As discussed further in #linux-rockchip >> on Libera.Chat, we do need a general solution for this issue, which would >> get us covered for all the board variants that use different DRAM chips, >> which are currently known to U-Boot only. >> >> I'll keep thinking about this in the next couple of days, and I'll come >> back with an update. > > As a separate thought, is there some way to detect the actual ROCK Pi E > board variant at runtime, using some GPIO line, ADC readout, or something > similar? That would help with making it possible to have a single U-Boot > build for both board variants. as far as I know, no difference. (I asked my colleague) I will compare schematics. but, if there is difference, is it possible to replace RAM initialization on u-boot? btw, RFC: https://github.com/RadxaNaoki/u-boot/commit/ff1aa39ffb725d10fbb1608062debe6657f40acc -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd.
Hi, RFC: https://patchwork.ozlabs.org/project/uboot/patch/20240827013111.633-1-naoki@radxa.com/ Best regards, -- FUKAUMI Naoki Radxa Computer (Shenzhen) Co., Ltd. On 8/27/24 08:20, FUKAUMI Naoki wrote: > Hi, > > On 8/26/24 20:25, Dragan Simic wrote: >> Hello Naoki, >> >> On 2024-08-18 00:30, Dragan Simic wrote: >>> On 2024-08-17 22:28, FUKAUMI Naoki wrote: >>>> On 8/18/24 05:12, Dragan Simic wrote: >>>>> On 2024-08-17 22:04, FUKAUMI Naoki wrote: >>>>>> On 8/18/24 04:51, Dragan Simic wrote: >>>>>>> On 2024-08-17 21:28, Dragan Simic wrote: >>>>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote: >>>>>>>>> On 8/17/24 07:11, Heiko Stübner wrote: >>>>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki: >>>>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the >>>>>>>>>>> Rockchip >>>>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT >>>>>>>>>>> configurations: >>>>>>>>>>> >>>>>>>>>>> - Rockchip RK3328 SoC >>>>>>>>>>> - Quad A53 CPU >>>>>>>>>>> - 512MB/1GB/2GB DDR4 RAM >>>>>>>>> (snip) >>>>>>>>>> can you please describe what is different in that v3 board? >>>>>>>>>> Describing what is different to require a separate board >>>>>>>>>> should've been >>>>>>>>>> part of the commit message. >>>>>>>>>> >>>>>>>>>> Because from those changes, the bottom line currently seems to be >>>>>>>>>> the same board with swapped mmc aliases? >>>>>>>>> >>>>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E). >>>>>>>>> different bootloader (U-Boot) is required. >>>>>>>>> >>>>>>>>> adding v3 dts seems not to be so important for Linux, but it's >>>>>>>>> very >>>>>>>>> important for U-Boot and OpenWrt(it includes bootloader for >>>>>>>>> distributed binary). >>>>>>>> >>>>>>>> Aren't there different methods that allow such board variants to be >>>>>>>> supported in U-Boot, with no need for a separate DT in the kernel? >>>>>>>> IIRC, there are already more than a few examples of such board >>>>>>>> variants, >>>>>>>> which require different DRAM initialization, which is covered in >>>>>>>> U-Boot >>>>>>>> by providing different builds that use the same DT. >>>>>>> >>>>>>> As an example, please have a look at the following files in U-Boot: >>>>>>> >>>>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi >>>>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi >>>>>>> - configs/nanopi-m4-rk3399_defconfig >>>>>>> - configs/nanopi-m4-2gb-rk3399_defconfig >>>>>>> >>>>>>> Basically, there's no need for separate DTs in the kernel, just >>>>>>> to support >>>>>>> board variants with different DRAM types in U-Boot. >>>>>> >>>>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" >>>>>> string to validate new firmware file is surely "for this board". >>>>>> >>>>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing >>>>>> wrong >>>>>> firmware (include bootloaer, U-Boot) possible. >>>>> >>>>> Could you, please, explain what's the actual issue with OpenWrt? I >>>>> did >>>>> read some GitHub issue that described it, IIRC, but I was unable to >>>>> fully >>>>> understand what's the underlying issue. >>>> >>>> $ wget >>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz >>>> $ strings >>>> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep >>>> metadata >>>> { "metadata_version": "1.1", "compat_version": "1.0", >>>> "supported_devices":["radxa,rock-pi-e"], "version": { "dist": >>>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", >>>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } } >>>> >>>> $ wget >>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz >>>> $ strings >>>> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | >>>> grep metadata >>>> { "metadata_version": "1.1", "compat_version": "1.0", >>>> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": >>>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", >>>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } } >>>> >>>> since they are incompatible firmware, it needs to have different >>>> "supported_devices" string. if both are "radxa,rockpi-e", firmware >>>> validation will not work correctly. >>>> >>>> (currently both values are wrong, it needs to be fixed, but it's >>>> another story) >>>> >>>>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different >>>>>> incompatible boards, it must have different "compatible" string. >>>>> >>>>> Well, the above-mentioned Nano Pi M4 boards share the same DT and >>>>> the same >>>>> "compatible" value, because for all consumers of the DT, except for >>>>> U-Boot >>>>> that can already handle the differences, they are the same boards. >>>> >>>> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt >>>> >>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/ >>> >>> Thanks for the explanations. As discussed further in #linux-rockchip >>> on Libera.Chat, we do need a general solution for this issue, which >>> would >>> get us covered for all the board variants that use different DRAM chips, >>> which are currently known to U-Boot only. >>> >>> I'll keep thinking about this in the next couple of days, and I'll come >>> back with an update. >> >> As a separate thought, is there some way to detect the actual ROCK Pi E >> board variant at runtime, using some GPIO line, ADC readout, or something >> similar? That would help with making it possible to have a single U-Boot >> build for both board variants. > > as far as I know, no difference. (I asked my colleague) > I will compare schematics. > > but, if there is difference, is it possible to replace RAM > initialization on u-boot? > > btw, RFC: > > https://github.com/RadxaNaoki/u-boot/commit/ff1aa39ffb725d10fbb1608062debe6657f40acc > > -- > FUKAUMI Naoki > Radxa Computer (Shenzhen) Co., Ltd.
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile index cb309b1975ba..cc74cd17850a 100644 --- a/arch/arm64/boot/dts/rockchip/Makefile +++ b/arch/arm64/boot/dts/rockchip/Makefile @@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s-plus.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus-lts.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e-v3.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-pc.dtb diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts new file mode 100644 index 000000000000..ad9c4c562914 --- /dev/null +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts @@ -0,0 +1,15 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +/dts-v1/; + +#include "rk3328-rock-pi-e.dtsi" + +/ { + model = "Radxa ROCK Pi E v3.0"; + compatible = "radxa,rockpi-e-v3", "rockchip,rk3328"; + + aliases { + mmc0 = &emmc; + mmc1 = &sdmmc; + }; +}; diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts dissimilarity index 97% index 3e08e2fd0a78..0929df3c803a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts @@ -1,445 +1,15 @@ -// SPDX-License-Identifier: (GPL-2.0+ OR MIT) -/* - * (C) Copyright 2020 Chen-Yu Tsai <wens@csie.org> - * - * Based on ./rk3328-rock64.dts, which is - * - * Copyright (c) 2017 PINE64 - */ - -/dts-v1/; - -#include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/input/input.h> -#include <dt-bindings/leds/common.h> -#include <dt-bindings/pinctrl/rockchip.h> - -#include "rk3328.dtsi" - -/ { - model = "Radxa ROCK Pi E"; - compatible = "radxa,rockpi-e", "rockchip,rk3328"; - - aliases { - ethernet0 = &gmac2io; - ethernet1 = &gmac2phy; - mmc0 = &sdmmc; - mmc1 = &emmc; - }; - - chosen { - stdout-path = "serial2:1500000n8"; - }; - - adc-keys { - compatible = "adc-keys"; - io-channels = <&saradc 0>; - io-channel-names = "buttons"; - keyup-threshold-microvolt = <1750000>; - - /* This button is unpopulated out of the factory. */ - button-recovery { - label = "Recovery"; - linux,code = <KEY_VENDOR>; - press-threshold-microvolt = <10000>; - }; - }; - - gmac_clkin: external-gmac-clock { - compatible = "fixed-clock"; - clock-frequency = <125000000>; - clock-output-names = "gmac_clkin"; - #clock-cells = <0>; - }; - - leds { - compatible = "gpio-leds"; - pinctrl-0 = <&led_pin>; - pinctrl-names = "default"; - - led-0 { - color = <LED_COLOR_ID_BLUE>; - gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_LOW>; - linux,default-trigger = "heartbeat"; - }; - }; - - vcc_sd: sdmmc-regulator { - compatible = "regulator-fixed"; - gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&sdmmc0m1_pin>; - regulator-name = "vcc_sd"; - regulator-boot-on; - vin-supply = <&vcc_io>; - }; - - vcc_host_5v: vcc-host-5v-regulator { - compatible = "regulator-fixed"; - gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>; - pinctrl-names = "default"; - pinctrl-0 = <&usb30_host_drv>; - enable-active-high; - regulator-name = "vcc_host_5v"; - regulator-always-on; - regulator-boot-on; - vin-supply = <&vcc_sys>; - }; - - vcc_sys: vcc-sys { - compatible = "regulator-fixed"; - regulator-name = "vcc_sys"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <5000000>; - regulator-max-microvolt = <5000000>; - }; - - vcc_wifi: vcc-wifi-regulator { - compatible = "regulator-fixed"; - gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>; - pinctrl-names = "default"; - pinctrl-0 = <&wifi_en>; - regulator-name = "vcc_wifi"; - regulator-always-on; - regulator-boot-on; - vin-supply = <&vcc_io>; - }; -}; - -&analog_sound { - status = "okay"; -}; - -&codec { - status = "okay"; -}; - -&cpu0 { - cpu-supply = <&vdd_arm>; -}; - -&cpu1 { - cpu-supply = <&vdd_arm>; -}; - -&cpu2 { - cpu-supply = <&vdd_arm>; -}; - -&cpu3 { - cpu-supply = <&vdd_arm>; -}; - -&emmc { - bus-width = <8>; - cap-mmc-highspeed; - mmc-ddr-1_8v; - mmc-hs200-1_8v; - non-removable; - pinctrl-names = "default"; - pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>; - vmmc-supply = <&vcc_io>; - vqmmc-supply = <&vcc18_emmc>; - status = "okay"; -}; - -&gmac2io { - assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>; - assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>; - clock_in_out = "input"; - phy-handle = <&rtl8211>; - phy-mode = "rgmii"; - phy-supply = <&vcc_io>; - pinctrl-names = "default"; - pinctrl-0 = <&rgmiim1_pins>; - snps,aal; - snps,rxpbl = <0x4>; - snps,txpbl = <0x4>; - tx_delay = <0x26>; - rx_delay = <0x11>; - status = "okay"; - - mdio { - compatible = "snps,dwmac-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - rtl8211: ethernet-phy@1 { - reg = <1>; - pinctrl-0 = <ð_phy_int_pin>, <ð_phy_reset_pin>; - pinctrl-names = "default"; - interrupt-parent = <&gpio1>; - interrupts = <24 IRQ_TYPE_LEVEL_LOW>; - reset-assert-us = <10000>; - reset-deassert-us = <50000>; - reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>; - }; - }; -}; - -&gmac2phy { - status = "okay"; -}; - -&gpio0 { - gpio-line-names = - /* GPIO0_A0 - A7 */ - "", "", "", "", "", "", "", "", - /* GPIO0_B0 - B7 */ - "", "", "", "", "", "", "", "", - /* GPIO0_C0 - C7 */ - "", "", "", "", "", "", "", "", - /* GPIO0_D0 - D7 */ - "", "", "", "pin-15 [GPIO0_D3]", "", "", "", ""; -}; - -&gpio1 { - gpio-line-names = - /* GPIO1_A0 - A7 */ - "", "", "", "", "", "", "", "", - /* GPIO1_B0 - B7 */ - "", "", "", "", "", "", "", "", - /* GPIO1_C0 - C7 */ - "", "", "", "", "", "", "", "", - /* GPIO1_D0 - D7 */ - "", "", "", "", "pin-07 [GPIO1_D4]", "", "", ""; -}; - -&gpio2 { - gpio-line-names = - /* GPIO2_A0 - A7 */ - "pin-08 [GPIO2_A0]", "pin-10 [GPIO2_A1]", "pin-11 [GPIO2_A2]", - "pin-13 [GPIO2-A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]", - "pin-33 [GPIO2_A6]", "", - /* GPIO2_B0 - B7 */ - "", "", "", "", "pin-26 [GPIO2_B4]", "", "", "pin-36 [GPIO2_B7]", - /* GPIO2_C0 - C7 */ - "pin-32 [GPIO2_C0]", "pin-35 [GPIO2_C1]", "pin-12 [GPIO2_C2]", - "pin-38 [GPIO2_C3]", "pin-29 [GPIO2_C4]", "pin-31 [GPIO2_C5]", - "pin-37 [GPIO2_C6]", "pin-40 [GPIO2_C7]", - /* GPIO2_D0 - D7 */ - "", "", "", "", "", "", "", ""; -}; - -&gpio3 { - gpio-line-names = - /* GPIO3_A0 - A7 */ - "pin-23 [GPIO3_A0]", "pin-19 [GPIO3_A1]", "pin-21 [GPIO3_A2]", - "", "pin-03 [GPIO3_A4]", "", "pin-05 [GPIO3_A6]", "", - /* GPIO3_B0 - B7 */ - "pin-24 [GPIO3_B0]", "", "", "", "", "", "", "", - /* GPIO3_C0 - C7 */ - "", "", "", "", "", "", "", "", - /* GPIO3_D0 - D7 */ - "", "", "", "", "", "", "", ""; -}; - -&i2c1 { - status = "okay"; - - rk805: pmic@18 { - compatible = "rockchip,rk805"; - reg = <0x18>; - interrupt-parent = <&gpio0>; - interrupts = <2 IRQ_TYPE_LEVEL_LOW>; - #clock-cells = <1>; - clock-output-names = "xin32k", "rk805-clkout2"; - gpio-controller; - #gpio-cells = <2>; - pinctrl-names = "default"; - pinctrl-0 = <&pmic_int_l>; - rockchip,system-power-controller; - wakeup-source; - - vcc1-supply = <&vcc_sys>; - vcc2-supply = <&vcc_sys>; - vcc3-supply = <&vcc_sys>; - vcc4-supply = <&vcc_sys>; - vcc5-supply = <&vcc_io>; - vcc6-supply = <&vcc_sys>; - - regulators { - vdd_log: DCDC_REG1 { - regulator-name = "vdd_log"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <712500>; - regulator-max-microvolt = <1450000>; - regulator-ramp-delay = <12500>; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <1000000>; - }; - }; - - vdd_arm: DCDC_REG2 { - regulator-name = "vdd_arm"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <712500>; - regulator-max-microvolt = <1450000>; - regulator-ramp-delay = <12500>; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <950000>; - }; - }; - - vcc_ddr: DCDC_REG3 { - regulator-name = "vcc_ddr"; - regulator-always-on; - regulator-boot-on; - - regulator-state-mem { - regulator-on-in-suspend; - }; - }; - - vcc_io: DCDC_REG4 { - regulator-name = "vcc_io"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <3300000>; - }; - }; - - vcc_18: LDO_REG1 { - regulator-name = "vcc_18"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <1800000>; - }; - }; - - vcc18_emmc: LDO_REG2 { - regulator-name = "vcc18_emmc"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <1800000>; - }; - }; - - vdd_10: LDO_REG3 { - regulator-name = "vdd_10"; - regulator-always-on; - regulator-boot-on; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - - regulator-state-mem { - regulator-on-in-suspend; - regulator-suspend-microvolt = <1000000>; - }; - }; - }; - }; -}; - -&i2s1 { - status = "okay"; -}; - -&io_domains { - pmuio-supply = <&vcc_io>; - vccio1-supply = <&vcc_io>; - vccio2-supply = <&vcc18_emmc>; - vccio3-supply = <&vcc_io>; - vccio4-supply = <&vcc_io>; - vccio5-supply = <&vcc_io>; - vccio6-supply = <&vcc_io>; - status = "okay"; -}; - -&pinctrl { - ephy { - eth_phy_int_pin: eth-phy-int-pin { - rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>; - }; - - eth_phy_reset_pin: eth-phy-reset-pin { - rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>; - }; - }; - - leds { - led_pin: led-pin { - rockchip,pins = <3 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>; - }; - }; - - pmic { - pmic_int_l: pmic-int-l { - rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>; - }; - }; - - usb3 { - usb30_host_drv: usb30-host-drv { - rockchip,pins = <3 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>; - }; - }; - - wifi { - wifi_en: wifi-en { - rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>; - }; - }; -}; - -&sdmmc { - bus-width = <4>; - cap-sd-highspeed; - disable-wp; - pinctrl-names = "default"; - pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>, <&sdmmc0_bus4>; - vmmc-supply = <&vcc_sd>; - status = "okay"; -}; - -&saradc { - vref-supply = <&vcc_18>; - status = "okay"; -}; - -&tsadc { - status = "okay"; -}; - -&u2phy { - status = "okay"; -}; - -&u2phy_host { - status = "okay"; -}; - -&uart2 { - status = "okay"; -}; - -&usbdrd3 { - dr_mode = "host"; - status = "okay"; -}; - -&usb_host0_ehci { - status = "okay"; -}; +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +/dts-v1/; + +#include "rk3328-rock-pi-e.dtsi" + +/ { + model = "Radxa ROCK Pi E"; + compatible = "radxa,rockpi-e", "rockchip,rk3328"; + + aliases { + mmc0 = &sdmmc; + mmc1 = &emmc; + }; +}; diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dtsi similarity index 98% copy from arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts copy to arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dtsi index 3e08e2fd0a78..bb01143dc91a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dtsi @@ -17,14 +17,9 @@ #include "rk3328.dtsi" / { - model = "Radxa ROCK Pi E"; - compatible = "radxa,rockpi-e", "rockchip,rk3328"; - aliases { ethernet0 = &gmac2io; ethernet1 = &gmac2phy; - mmc0 = &sdmmc; - mmc1 = &emmc; }; chosen {
Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations: - Rockchip RK3328 SoC - Quad A53 CPU - 512MB/1GB/2GB DDR4 RAM - 4/8/16/32GB eMMC - Micro SD Card slot - WiFi 4 and BT 4, or WiFi 5 and BT 5 - 1x 1000M Ethernet supporting PoE with add‑on PoE HAT - 1x 100M Ethernet - 1x USB 3.0 Type-A port (Host) - 1x 4-ring 3.5mm headphone jack - 40 Pin GPIO header [1] https://radxa.com/products/rockpi/pie Signed-off-by: FUKAUMI Naoki <naoki@radxa.com> --- Changes in v5: - revert compatible string Changes in v4: - update compatible string for OpenWrt Changes in v3: - fix conflict for recent change Changes in v2: - fix typo in commit message - add missing --- in commit message --- arch/arm64/boot/dts/rockchip/Makefile | 1 + .../boot/dts/rockchip/rk3328-rock-pi-e-v3.dts | 15 + .../boot/dts/rockchip/rk3328-rock-pi-e.dts | 460 +----------------- ...28-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} | 5 - 4 files changed, 31 insertions(+), 450 deletions(-) create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts rewrite arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts (97%) copy arch/arm64/boot/dts/rockchip/{rk3328-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} (98%)