> Date: Sun, 30 Jun 2019 14:13:23 +0200 (CEST)
> From: Markus Hennecke <markus-henne...@markus-hennecke.de>
>
> On Fri, 21 Jun 2019, Mark Kettenis wrote:
>
> > I've finally managed to build a properly working (and fully open
> > source) firmware for the ROCKPro64. The firmware consists of two
> > files, which can be downloaded from:
> >
> > https://sibelius.home.xs4all.nl/firmware/rk3399-rockpro64/idbloader.img
> > https://sibelius.home.xs4all.nl/firmware/rk3399-rockpro64/u-boot.itb
> >
> > In order to use this firmware you'll have to write it to a uSD card or
> > an eMMC module with the following commands:
> >
> > # dd if=idbloader.img of=/dev/sdXc seek=64
> > # dd if=u-boot.itb of=/dev/sdXc seek=16384
> >
> > Note that if you flashed a firmware to the onboard SPI flash, you'll
> > have to erase it first or disable the SPI flash with a jumper wire
> > connecting pins 23 and 25.
> >
> > Also note that the firmware overlaps with the msdos partition in the
> > default OpenBSD/arm64 disk layout. Therefore you can't have the
> > firmware and the OpenBSD boot/root filesystems on the same device
> > without running through additional hoops. Ultimately the goal is to
> > make it possible to put this firmware in SPI flash, but I haven't
> > looked into that yet.
> >
> > This firmware uses a more standard serial speed of 115200, which means
> > you can use almost any USB TTL serial cable. DVFS is supported so you
> > can use sysctl hw.setperf to control to clock speed of the CPUs. But
> > be aware that without a fan the board will probably overheat if you
> > run it at the highest supported clock speed.
>
> Thanks, I was unable to boot bsd.rd, but setting up a system on a SD card
> and copying the dtb to the efi partition worked out and gave me a booting
> system. Well, most of the time it is booting. Sometimes the boot ends in
> input/output errors.
That suggests you're still using an old U-Boot that doesn't initialize
the voltage regulators properly. If you have a bootloader in SPI
flash, you'll have to erase it or disable the SPI clock by connecting
pin 23 and 25 with a jumper wire.
> Is there any smart way to put the system on NVMe while u-boot can't
> boot from it yet without having the root partition on SD card?
Unfortunately not.
> Just for the record, the following patch for ports sysutils/dtb will not
> change the console speed during the boot process and in addition will
> enable the pcie port:
Yes, I have a similar diff. I'll see if I can update the sysuitls/dtb
port.
> $OpenBSD$
>
> Index: arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
> --- arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts.orig
> +++ arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dts
> @@ -15,7 +15,7 @@
> compatible = "pine64,rockpro64", "rockchip,rk3399";
>
> chosen {
> - stdout-path = "serial2:1500000n8";
> + stdout-path = "serial2:115200n8";
> };
>
> clkin_gmac: external-gmac-clock {
> @@ -186,6 +186,20 @@
> };
>
> &emmc_phy {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + max-link-speed = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie_clkreqn_cpm>;
> + vpcie3v3-supply = <&vcc3v3_pcie>;
> status = "okay";
> };
>
>
> >
> > At some point this should land in the official u-boot-aarch64
> > packages. But since this build relies on a fairly large patch set
> > that hasn't landed upstream yet, this may take some time.
> >
> > Cheers,
> >
> > Mark
> >
> >
>
