board: rockchip: Add Kobol Helios64
Subsystems (2)
PATCH 1/1 board: rockchip: Add Kobol Helios64
Add support for the Kobol Helios64, an RK3399 NAS board with 4 GiB of LPDDR4, eMMC, SD card, SPI NOR flash, a 1 GbE RTL8211F PHY, a 2.5 GbE RTL8156 on USB and a JMB585 SATA controller on PCIe.
The board uses the upstream device tree. The -u-boot.dtsi adds the LPDDR4 timings for the open-source TPL and the vdd_log PWM regulator and the vdd_center RK808 buck, which the upstream device tree does not describe yet, and sets both rails to 950 mV. RockPro64 sets vdd_center the same way, see commit f210cbc1f3d4 ("arm: dts: rk3399-rockpro64:
slightly increase center voltage").
Without the vdd_log and vdd_center nodes, Linux 7.3 reset or hung about 2.3 s into the boot in 2 of 2 cold boots. With both rails at 950 mV, 20 cold boots of Linux 7.3 showed no memory errors.
Features tested on a Helios64:
- eMMC boot (TF-A v2.13.0 BL31, open-source TPL)
- GMAC Ethernet (DHCP, TFTP)
- USB 3 host
Not working yet: PCIe (pcie_rockchip fails to request ep-gpios). SD card and SPI flash boot are untested.
---
No MAINTAINERS entry on purpose: I cannot commit to maintaining the board. It falls under ARM ROCKCHIP via "N: rk3", and buildman --maintainer-check passes.
--- arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 56 +++++++++++++++++ configs/helios64-rk3399_defconfig | 84 ++++++++++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + 3 files changed, 141 insertions(+)
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi new file +56 -0
@@ -0,0 +1,56 @@ +// SPDX-License-Identifier: GPL-2.0+ + +#include "rk3399-u-boot.dtsi" +#include "rk3399-sdram-lpddr4-100.dtsi" + +/ { + vdd_log: regulator-vdd-log { + compatible = "pwm-regulator"; + pwms = <&pwm2 0 25000 1>; + pwm-supply = <&vcc5v0_sys>; + regulator-name = "vdd_log"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <830000>; + regulator-max-microvolt = <1400000>; + regulator-init-microvolt = <950000>; + }; +}; + +&pwm2 { + status = "okay"; +}; + +&rk808 { + regulators { + vdd_center: DCDC_REG1 { + regulator-name = "vdd_center"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <950000>; + }; + }; +}; + +&gpio0 { + bootph-pre-ram; +}; + +&sdhci { + cap-mmc-highspeed; + mmc-ddr-1_8v; +}; + +&sdmmc0_pwr_h { + bootph-pre-ram; +}; + +&spiflash { + bootph-pre-ram; + bootph-some-ram; +}; + +&vcc3v0_sd { + bootph-pre-ram; +};
configs/helios64-rk3399_defconfig new file +84 -0
84 lines not on this page · raw message
doc/board/rockchip/rockchip.rst +1 -0
@@ -92,6 +92,7 @@ List of mainline supported Rockchip boards: - Khadas Edge (khadas-edge-rk3399) - Khadas Edge-Captain (khadas-edge-captain-rk3399) - Khadas Edge-V (hadas-edge-v-rk3399) + - Kobol Helios64 (helios64-rk3399) - Orange Pi RK3399 (orangepi-rk3399) - Pine64 RockPro64 (rockpro64-rk3399) - Radxa ROCK 4C+ (rock-4c-plus-rk3399)
---
base-commit: 8d534cec0cc0109a37c0ded8854da03f1526dc0e
change-id: 20261021-b4-helios64-71f019de8d7d
Best regards,
Signature · 1 line
Igor Velkov <[email protected]>
Hi Igor,
Quoted 22 lines · On 10/21/26 3:04 AM, Igor Velkov via B4 Relay wrote:
From: Igor Velkov <[email protected]>
Add support for the Kobol Helios64, an RK3399 NAS board with 4 GiB of LPDDR4, eMMC, SD card, SPI NOR flash, a 1 GbE RTL8211F PHY, a 2.5 GbE RTL8156 on USB and a JMB585 SATA controller on PCIe.
The board uses the upstream device tree. The
-u-boot.dtsiadds the LPDDR4 timings for the open-source TPL and thevdd_logPWM regulator and thevdd_centerRK808 buck, which the upstream device tree does not describe yet, and sets both rails to 950 mV. RockPro64 setsvdd_centerthe same way, see commitf210cbc1f3d4("arm: dts: rk3399-rockpro64:
slightly increase center voltage").Without the
vdd_logandvdd_centernodes, Linux 7.3 reset or hung about 2.3 s into the boot in 2 of 2 cold boots. With both rails at 950 mV, 20 cold boots of Linux 7.3 showed no memory errors.Features tested on a Helios64:
- eMMC boot (TF-A v2.13.0 BL31, open-source TPL)
- GMAC Ethernet (DHCP, TFTP)
- USB 3 host
Quoted 8 lines
Not working yet: PCIe (
pcie_rockchipfails to request ep-gpios). SD card and SPI flash boot are untested.Signed-off-by Igor Velkov <[email protected]>---
NoMAINTAINERSentry on purpose: I cannot commit to maintaining the board. It falls under ARM ROCKCHIP via "N: rk3", and buildman --maintainer-check passes.
Can we have you as a reviewer at least, so that any patch modifying either of the first two helios64-specific patches are sent to you and you can review/test them? Is this something you'd be ok with?
Quoted 37 lines
--- arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi | 56 +++++++++++++++++ configs/helios64-rk3399_defconfig | 84 ++++++++++++++++++++++++++ doc/board/rockchip/rockchip.rst | 1 + 3 files changed, 141 insertions(+)arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi new file +25
-0@@ -0,0 +1,56 @@ +// SPDX-License-Identifier: GPL-2.0+ + +#include "rk3399-u-boot.dtsi" +#include "rk3399-sdram-lpddr4-100.dtsi" + +/ { + vdd_log: regulator-vdd-log { + compatible = "pwm-regulator"; + pwms = <&pwm2 0 25000 1>; + pwm-supply = <&vcc5v0_sys>; + regulator-name = "vdd_log"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <830000>; + regulator-max-microvolt = <1400000>; + regulator-init-microvolt = <950000>; + }; +}; + +&pwm2 { + status = "okay"; +}; + +&rk808 { + regulators {
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi line 35
Quoted 10 lines
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi new file +10
-0+ vdd_center: DCDC_REG1 { + regulator-name = "vdd_center"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <950000>; + }; + }; +}; +
Please work with the Linux kernel to get the vdd_log and vdd_center parts reviewed and merged there. Then we can have support for the Helios64 in here once merged there and available in devicetree-rebasing (https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/).
Quoted 27 lines
arch/arm/dts/rk3399-kobol-helios64-u-boot.dtsi new file +21
-0+&gpio0 { + bootph-pre-ram; +}; + +&sdhci { + cap-mmc-highspeed; + mmc-ddr-1_8v; +}; + +&sdmmc0_pwr_h { + bootph-pre-ram; +}; + +&spiflash { + bootph-pre-ram; + bootph-some-ram; +}; + +&vcc3v0_sd { + bootph-pre-ram; +};configs/helios64-rk3399_defconfig new file +0
-0
configs/helios64-rk3399_defconfig line 8
Quoted 8 lines
configs/helios64-rk3399_defconfig new file +8
-0@@ -0,0 +1,84 @@ +CONFIG_ARM=y +CONFIG_SKIP_LOWLEVEL_INIT=y +CONFIG_COUNTER_FREQUENCY=24000000 +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SPL_GPIO=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_SF_DEFAULT_SPEED=25000000 +CONFIG_ENV_OFFSET=0x3F8000
This is already the default (except it's a lowercase f by default, hence why it appears in the defconfig), please simply write it lowercase so it's using the default value.
configs/helios64-rk3399_defconfig line 12
Quoted 4 lines
configs/helios64-rk3399_defconfig new file +4
-0+CONFIG_DEFAULT_DEVICE_TREE="rockchip/rk3399-kobol-helios64" +CONFIG_DM_RESET=y +CONFIG_ROCKCHIP_RK3399=y +CONFIG_ROCKCHIP_SPI_IMAGE=y
You said SPI flash boot wasn't tested, maybe don't generate an image that we don't know is valid?
Quoted 5 lines
configs/helios64-rk3399_defconfig new file +5
-0+CONFIG_TARGET_EVB_RK3399=y +CONFIG_SYS_LOAD_ADDR=0x800800 +CONFIG_SF_DEFAULT_BUS=1 +CONFIG_DEBUG_UART_BASE=0xFF1A0000 +CONFIG_DEBUG_UART_CLOCK=24000000
configs/helios64-rk3399_defconfig line 27
Quoted 10 lines
configs/helios64-rk3399_defconfig new file +10
-0+CONFIG_SPL_SPI_FLASH_SUPPORT=y +CONFIG_SPL_SPI=y +CONFIG_PCI=y +CONFIG_DEBUG_UART=y +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-kobol-helios64.dtb" +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SPL_MAX_SIZE=0x40000 +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0xE0000
Considering you didn't test SPI flash boot, I would say this is not a good idea. Is the offset used by the Helios64 original support known? We should aim to reuse it if specified, so we don't break existing setups if they want to upgrade to upstream.
configs/helios64-rk3399_defconfig line 28
Quoted 1 line
configs/helios64-rk3399_defconfig new file +1
-0+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
Are you using the Rockchip bl31 blob as TF-A or upstream? This symbol is only required for the Rockchip blob.
configs/helios64-rk3399_defconfig line 38
Quoted 10 lines
configs/helios64-rk3399_defconfig new file +10
-0+CONFIG_TPL=y +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y +CONFIG_CMD_POWEROFF=y +CONFIG_CMD_USB=y +CONFIG_CMD_TIME=y +CONFIG_SPL_OF_CONTROL=y +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
Please remove clock-names from this here, I prefer we only keep a list of things that could be problematic in SPL DTB, and clock-names is not one of those (I believe at least).
Quoted 35 lines
configs/helios64-rk3399_defconfig new file +35
-0+CONFIG_ENV_IS_IN_MMC=y +CONFIG_ENV_RELOC_GD_ENV_ADDR=y +CONFIG_SCSI_AHCI=y +CONFIG_AHCI_PCI=y +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_LED=y +CONFIG_LED_GPIO=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y +CONFIG_MMC_SDHCI_ROCKCHIP=y +CONFIG_SPI_FLASH_SFDP_SUPPORT=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_DM_ETH_PHY=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_REALTEK=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_TYPEC=y +CONFIG_PMIC_RK8XX=y +CONFIG_REGULATOR_PWM=y +CONFIG_SPL_DM_REGULATOR_FIXED=y +CONFIG_REGULATOR_RK8XX=y +CONFIG_PWM_ROCKCHIP=y +CONFIG_RAM_ROCKCHIP_LPDDR4=y +CONFIG_SCSI=y +CONFIG_BAUDRATE=1500000 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550_MEM32=y +CONFIG_ROCKCHIP_SPI=y +CONFIG_SYSRESET=y +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y
configs/helios64-rk3399_defconfig line 83
Quoted 10 lines
configs/helios64-rk3399_defconfig new file +10
-0+CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_HOST_ETHER=y +CONFIG_USB_ETHER_ASIX=y +CONFIG_USB_ETHER_ASIX88179=y +CONFIG_USB_ETHER_MCS7830=y +CONFIG_USB_ETHER_RTL8152=y +CONFIG_USB_ETHER_SMSC95XX=y
Are there really that many USB Ethernet adapters on the board? From https://wiki.kobol.io/helios64/img/hardware/helios64_block_diagram.png there seems to be an RTL8156. Is it properly supported by any of the above drivers (maybe CONFIG_USB_ETHER_RTL8152?)? Did you test both Ethernet ports in U-Boot?
Cheers,
Quentin
Hi Quentin,
Quoted 3 lines · Quentin Schulz
Can we have you as a reviewer at least, so that any patch modifying either of the first two helios64-specific patches are sent to you and you can review/test them? Is this something you'd be ok with?
Yes, as R:. I can't review schematics or drivers, but I'll boot-test helios64 changes on my board.
Quoted 2 lines
Please work with the Linux kernel to get the
vdd_logandvdd_centerparts reviewed and merged there.
Sent on 21.10:
https://lore.kernel.org/r/[email protected]
I'll send v2 once it lands in devicetree-rebasing.
Quoted 3 lines
This is already the default (except it's a lowercase f by default, hence why it appears in the defconfig), please simply write it lowercase so it's using the default value.
Done, the line is gone.
Quoted 2 lines
You said SPI flash boot wasn't tested, maybe don't generate an image that we don't know is valid?
Tested now: SPL loads U-Boot from SPI, then Linux over TFTP, 6 of 6 boots.
Quoted 1 line
Is the offset used by the Helios64 original support known?
Kobol's U-Boot used 0x80000, which also boots here. I'd keep 0xE0000 like the other RK3399 boards: an update rewrites TPL/SPL as well, so the old offset doesn't matter.
Quoted 1 line
Are you using the Rockchip bl31 blob as TF-A or upstream?
Upstream v2.13.0, dropped.
Quoted 1 line
Please remove clock-names from this here
Dropped.
Quoted 1 line
Are there really that many USB Ethernet adapters on the board?
No, the list came from evb-rk3399. U-Boot has no RTL8156 support (r8152 knows 0x8050/0x8152/0x8153 only), so I dropped all of them. Only the GMAC port was tested.
Igor
Hi Igor,
Quoted 10 lines · Igor Velkov
Hi Quentin,
Quoted 3 lines · Quentin Schulz
Can we have you as a reviewer at least, so that any patch modifying either of the first two helios64-specific patches are sent to you and you can review/test them? Is this something you'd be ok with?
Yes, as R:. I can't review schematics or drivers, but I'll boot-test helios64 changes on my board.
Quoted 7 lines
Quoted 2 lines
Please work with the Linux kernel to get the
vdd_logandvdd_centerparts reviewed and merged there.Sent on 21.10:
https://lore.kernel.org/r/[email protected]
I'll send v2 once it lands in devicetree-rebasing.
Ah, should have checked myself. Thanks for working on this proactively!
Quoted 9 lines
Quoted 3 lines
This is already the default (except it's a lowercase f by default, hence why it appears in the defconfig), please simply write it lowercase so it's using the default value.
Done, the line is gone.
Quoted 2 lines
You said SPI flash boot wasn't tested, maybe don't generate an image that we don't know is valid?
Quoted 8 lines
Tested now: SPL loads U-Boot from SPI, then Linux over TFTP, 6 of 6 boots.
Quoted 1 line
Is the offset used by the Helios64 original support known?
Kobol's U-Boot used
0x80000, which also boots here. I'd keep0xE0000like the other RK3399 boards: an update rewrites TPL/SPL as well, so the old offset doesn't matter.
Technically, you could flash TPL/SPL and not proper and maybe still reach U-Boot proper (so new TPL/SPL + old U-Boot) or vice-versa. Using a different offset means you need to make sure both gets updated in lockstep. This is also not powerfail-safe (imagine a power cut between updating TPL/SPL and proper (or vice-versa), then you would have a bricked device. RK3399 Puma has a different offset as well, due to historical reasons.
Up to you in the end, but I guess it makes things easier if users don't need to figure out where to flash stuff (well, except if they use u-boot-rockchip-spi.bin at the actual expected offset).
Ack for the rest.
Cheers,
Quentin
Hi Igor,
Quoted 10 lines · Igor Velkov
Hi Quentin,
Quoted 3 lines · Quentin Schulz
Can we have you as a reviewer at least, so that any patch modifying either of the first two helios64-specific patches are sent to you and you can review/test them? Is this something you'd be ok with?
Yes, as R:. I can't review schematics or drivers, but I'll boot-test helios64 changes on my board.
Good :)
Quoted 7 lines
Quoted 2 lines
Please work with the Linux kernel to get the
vdd_logandvdd_centerparts reviewed and merged there.Sent on 21.10:
https://lore.kernel.org/r/[email protected]
I'll send v2 once it lands in devicetree-rebasing.
Thanks. I see it's in linux-next already, so probably will be in for v7.5-rc1 sometime in January.
Quoted 9 lines
Quoted 3 lines
This is already the default (except it's a lowercase f by default, hence why it appears in the defconfig), please simply write it lowercase so it's using the default value.
Done, the line is gone.
Quoted 2 lines
You said SPI flash boot wasn't tested, maybe don't generate an image that we don't know is valid?
Quoted 8 lines
Tested now: SPL loads U-Boot from SPI, then Linux over TFTP, 6 of 6 boots.
Quoted 1 line
Is the offset used by the Helios64 original support known?
Kobol's U-Boot used
0x80000, which also boots here. I'd keep0xE0000like the other RK3399 boards: an update rewrites TPL/SPL as well, so the old offset doesn't matter.
Technically speaking, you could have a partial/interrupted update and have a mix of old TPL/SPL with new proper and vice-versa.
RK3399 Puma has different offsets than the default ones for example, for backward compatibility, so if we can have cheap backward compatibility why not do it?
The thing is, you don't know what the user of Kobol's U-Boot put after U-Boot in their flash. Maybe if you write the new U-Boot at offset 0xE0000 instead of 0x80000 you overwrite important data (e.g. at the start of the rootfs partition).
Quoted 6 lines
Quoted 1 line
Are you using the Rockchip bl31 blob as TF-A or upstream?
Upstream v2.13.0, dropped.
Quoted 1 line
Please remove clock-names from this here
Quoted 8 lines
Dropped.
Quoted 1 line
Are there really that many USB Ethernet adapters on the board?
No, the list came from evb-rk3399. U-Boot has no RTL8156 support (r8152 knows 0x8050/0x8152/0x8153 only), so I dropped all of them. Only the GMAC port was tested.
Please make this clear in the commit log for v2.
Thanks!
Quentin