ROCKPro64 firmware

Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ROCKPro64 firmware

Mark Kettenis
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Markus Hennecke
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. 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?

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:

$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
>
>

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Joseph Mayer
Hi Mark and Markus,

On Saturday, 22 June 2019 04:24, Mark Kettenis <[hidden email]> 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:

Wait the default one is a proprietary closed-source fork of uboot?


On Sunday, 30 June 2019 20:13, Markus Hennecke <[hidden email]> wrote:
..

> 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. 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?
>
> 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:

Wait enabling PCIe in the firmware has what effect, to enable it at all
(for use post-boot) or to make NVMe bootable?

Joseph

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Mark Kettenis
In reply to this post by Markus Hennecke
> Date: Sun, 30 Jun 2019 14:13:23 +0200 (CEST)
> From: Markus Hennecke <[hidden email]>
>
> 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
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Mark Kettenis
In reply to this post by Joseph Mayer
> Date: Sun, 30 Jun 2019 14:32:40 +0000
> From: Joseph Mayer <[hidden email]>
>
> Hi Mark and Markus,
>
> On Saturday, 22 June 2019 04:24, Mark Kettenis <[hidden email]> 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:
>
> Wait the default one is a proprietary closed-source fork of uboot?

The "ayufan" builds that most people seem to use include binary blobs
for the primary bootloader (that initializes DRAM) and ATF.  U-Boot
itself is open-source but based on a vendor fork of U-Boot.

> On Sunday, 30 June 2019 20:13, Markus Hennecke <[hidden email]> wrote:
> ..
> > 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. 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?
> >
> > 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:
>
> Wait enabling PCIe in the firmware has what effect, to enable it at all
> (for use post-boot) or to make NVMe bootable?

It makes rkpci(4) attach when OpenBSD boots, but anything in the PCIe
slot won't be available in the bootloader.

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Markus Hennecke
In reply to this post by Mark Kettenis
On Sun, 30 Jun 2019, Mark Kettenis wrote:

> > Date: Sun, 30 Jun 2019 14:13:23 +0200 (CEST)
> > From: Markus Hennecke <[hidden email]>
> >
> > 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.

No, the jumper is set and it should be the correct u-boot from the
download links you provided. Easy to recognize as the ayufan u-boot from
SPI is using 1500000 baud:

Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL board init
Trying to boot from MMC1
NOTICE:  BL31: v2.1(debug):2.1
NOTICE:  BL31: Built : 03:09:58, Apr 11 2019
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized
in EL3
INFO:    plat_rockchip_pmu_init(1596): pd status 3e
INFO:    BL31: Initializing runtime services
WARNING: BL31: cortex_a53: CPU workaround for 819472 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 824069 was missing!
WARNING: BL31: cortex_a53: CPU workaround for 827319 was missing!
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2019.07-rc4-00278-g0805a932f4-dirty (Jun 21 2019 - 21:33:15 +0200)

Model: Pine64 RockPro64
DRAM:  3.9 GiB
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Model: Pine64 RockPro64
Net:
Error: ethernet@fe300000 address not set.
eth-1: ethernet@fe300000
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:2...
53346 bytes read in 7 ms (7.3 MiB/s)
Found EFI removable media binary efi/boot/bootaa64.efi
Scanning disk [hidden email]...
Card did not respond to voltage select!
Scanning disk [hidden email]...
Disk [hidden email] not ready
Found 3 disks
BootOrder not defined
EFI boot manager: Cannot load any image
161322 bytes read in 12 ms (12.8 MiB/s)
disks: sd0*
>> OpenBSD/arm64 BOOTAA64 0.16

The bsd.rd from the last snapshot worked (28th June). I will try to
install the system on NVMe via the installer and boot using the -a switch
in the bootloader.

>
> > 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.

So I just keep entering boot -a on serial console during boot. After all
this is a system to play around with. I can live with that.
Or perhaps I will put / on SD card and copy it to NVMe via /altroot until
the situation changes.

 

> > 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
> > >
> > >
> >
>
>