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.
