Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux