ROCKPro64 firmware

classic Classic list List threaded Threaded
11 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
> > >
> > >
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Jonathan Gray-11
In reply to this post by Mark Kettenis
On Fri, Jun 21, 2019 at 10:24:48PM +0200, 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.
>
> 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.

I have committed a U-Boot 2019.07 update which builds the
rockpro64-rk3399 target and patches the default baud to 115200.

As on firefly it has file named idbspl.img instead of idbloader.img.
Don't have hardware so not sure if further patches are required.

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Mark Kettenis
> Date: Sun, 28 Jul 2019 17:04:12 +1000
> From: Jonathan Gray <[hidden email]>
>
> On Fri, Jun 21, 2019 at 10:24:48PM +0200, 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.
> >
> > 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.
>
> I have committed a U-Boot 2019.07 update which builds the
> rockpro64-rk3399 target and patches the default baud to 115200.
>
> As on firefly it has file named idbspl.img instead of idbloader.img.
> Don't have hardware so not sure if further patches are required.

Unfortunately the LPDDR4 support patches landed after 2019.07 was
released.  The ROCKPro64 won't work without those patches, and it is a
rather large set of patches :(.

I'm somewhat surprised to see that the rk3399 targets still build
without TPL.  But maybe the SPL overflow happens because of the LPDDR4
patches.  When we switch to TPL, I think it makes sense to start using
idbloader.img instead of idspl.img to be consistent with rk3288 and
the Rockchip documentation.

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Jonathan Gray-11
On Sun, Jul 28, 2019 at 11:40:26PM +0200, Mark Kettenis wrote:

> > Date: Sun, 28 Jul 2019 17:04:12 +1000
> > From: Jonathan Gray <[hidden email]>
> >
> > On Fri, Jun 21, 2019 at 10:24:48PM +0200, 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.
> > >
> > > 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.
> >
> > I have committed a U-Boot 2019.07 update which builds the
> > rockpro64-rk3399 target and patches the default baud to 115200.
> >
> > As on firefly it has file named idbspl.img instead of idbloader.img.
> > Don't have hardware so not sure if further patches are required.
>
> Unfortunately the LPDDR4 support patches landed after 2019.07 was
> released.  The ROCKPro64 won't work without those patches, and it is a
> rather large set of patches :(.

Alright, I'll remove it until the next release.

>
> I'm somewhat surprised to see that the rk3399 targets still build
> without TPL.  But maybe the SPL overflow happens because of the LPDDR4
> patches.  When we switch to TPL, I think it makes sense to start using
> idbloader.img instead of idspl.img to be consistent with rk3288 and
> the Rockchip documentation.

Aren't the rk3399 targets already using TPL with 2019.07?

evb-rk3399_defconfig:CONFIG_TPL=y
firefly-rk3399_defconfig:CONFIG_TPL=y
nanopc-t4-rk3399_defconfig:CONFIG_TPL=y
nanopi-m4-rk3399_defconfig:CONFIG_TPL=y
nanopi-neo4-rk3399_defconfig:CONFIG_TPL=y
orangepi-rk3399_defconfig:CONFIG_TPL=y
rock-pi-4-rk3399_defconfig:CONFIG_TPL=y
rockpro64-rk3399_defconfig:CONFIG_TPL=y

$ git tag --contains bdc00080111f6dc1e48586239e71e22665004aca
v2019.07
v2019.07-rc2
v2019.07-rc3
v2019.07-rc4

Index: Makefile
===================================================================
RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.54
diff -u -p -r1.54 Makefile
--- Makefile 28 Jul 2019 06:57:19 -0000 1.54
+++ Makefile 29 Jul 2019 01:00:37 -0000
@@ -7,6 +7,7 @@ FLAVOR?= arm
 
 COMMENT= U-Boot firmware
 VERSION= 2019.07
+REVISION= 0
 DISTNAME= u-boot-${VERSION}
 PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
 FULLPKGNAME= ${PKGNAME}
@@ -68,7 +69,6 @@ BOARDS=\
  mvebu_espressobin-88f3720 \
  mvebu_mcbin-88f8040 \
  qemu_arm64 \
- rockpro64-rk3399 \
  rpi_3
 .elif "${FLAVOR}" == "arm"
 OMAP=\
@@ -140,7 +140,6 @@ FILES=\
  u-boot-spl.kwb \
  u-boot-with-spl.bin \
  u-boot.itb \
- idbspl.img \
  idbloader.img \
  spl/sunxi-spl.bin \
 
@@ -165,12 +164,12 @@ do-build:
         idbloader.img && \
     cat spl/u-boot-spl-dtb.bin >> idbloader.img
 .endif
-.if "${BOARD}" == "firefly-rk3399" || "${BOARD}" == "rockpro64-rk3399"
+.if "${BOARD}" == "firefly-rk3399"
  cd ${WRKSRC}/build/${BOARD} && \
     ${SETENV} ${MAKE_ENV} BL31=${RK3399_BL31} ${MAKE_PROGRAM} \
  ${MAKE_FLAGS} O="build/${BOARD}" \
         -f ${MAKE_FILE} u-boot.itb && \
-    tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
+    tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbloader.img
 .endif
 .endfor
 .for BOARD in ${SUNXI64}
Index: pkg/PFRAG.aarch64
===================================================================
RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.aarch64,v
retrieving revision 1.11
diff -u -p -r1.11 PFRAG.aarch64
--- pkg/PFRAG.aarch64 28 Jul 2019 06:57:20 -0000 1.11
+++ pkg/PFRAG.aarch64 29 Jul 2019 03:05:37 -0000
@@ -16,7 +16,7 @@ share/u-boot/bananapi_m64/u-boot.bin
 share/u-boot/bananapi_m64/u-boot.img
 share/u-boot/bananapi_m64/u-boot.itb
 share/u-boot/firefly-rk3399/
-share/u-boot/firefly-rk3399/idbspl.img
+share/u-boot/firefly-rk3399/idbloader.img
 share/u-boot/firefly-rk3399/u-boot
 share/u-boot/firefly-rk3399/u-boot.bin
 share/u-boot/firefly-rk3399/u-boot.img
@@ -86,12 +86,6 @@ share/u-boot/pinebook/u-boot.itb
 share/u-boot/qemu_arm64/
 share/u-boot/qemu_arm64/u-boot
 share/u-boot/qemu_arm64/u-boot.bin
-share/u-boot/rockpro64-rk3399/
-share/u-boot/rockpro64-rk3399/idbspl.img
-share/u-boot/rockpro64-rk3399/u-boot
-share/u-boot/rockpro64-rk3399/u-boot.bin
-share/u-boot/rockpro64-rk3399/u-boot.img
-share/u-boot/rockpro64-rk3399/u-boot.itb
 share/u-boot/rpi_3/
 share/u-boot/rpi_3/u-boot
 share/u-boot/rpi_3/u-boot.bin

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Mark Kettenis
> Date: Mon, 29 Jul 2019 14:07:09 +1000
> From: Jonathan Gray <[hidden email]>
>
> On Sun, Jul 28, 2019 at 11:40:26PM +0200, Mark Kettenis wrote:
> > > Date: Sun, 28 Jul 2019 17:04:12 +1000
> > > From: Jonathan Gray <[hidden email]>
> > >
> > > On Fri, Jun 21, 2019 at 10:24:48PM +0200, 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.
> > > >
> > > > 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.
> > >
> > > I have committed a U-Boot 2019.07 update which builds the
> > > rockpro64-rk3399 target and patches the default baud to 115200.
> > >
> > > As on firefly it has file named idbspl.img instead of idbloader.img.
> > > Don't have hardware so not sure if further patches are required.
> >
> > Unfortunately the LPDDR4 support patches landed after 2019.07 was
> > released.  The ROCKPro64 won't work without those patches, and it is a
> > rather large set of patches :(.
>
> Alright, I'll remove it until the next release.
>
> >
> > I'm somewhat surprised to see that the rk3399 targets still build
> > without TPL.  But maybe the SPL overflow happens because of the LPDDR4
> > patches.  When we switch to TPL, I think it makes sense to start using
> > idbloader.img instead of idspl.img to be consistent with rk3288 and
> > the Rockchip documentation.
>
> Aren't the rk3399 targets already using TPL with 2019.07?
>
> evb-rk3399_defconfig:CONFIG_TPL=y
> firefly-rk3399_defconfig:CONFIG_TPL=y
> nanopc-t4-rk3399_defconfig:CONFIG_TPL=y
> nanopi-m4-rk3399_defconfig:CONFIG_TPL=y
> nanopi-neo4-rk3399_defconfig:CONFIG_TPL=y
> orangepi-rk3399_defconfig:CONFIG_TPL=y
> rock-pi-4-rk3399_defconfig:CONFIG_TPL=y
> rockpro64-rk3399_defconfig:CONFIG_TPL=y
>
> $ git tag --contains bdc00080111f6dc1e48586239e71e22665004aca
> v2019.07
> v2019.07-rc2
> v2019.07-rc3
> v2019.07-rc4
>

Your diff is not quite right as it doesn't concatenate tpl and spl.
Fix below.  Still need to test this though.  But ok if it boots on the
firefly?


Index: sysutils/u-boot/Makefile
===================================================================
RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
retrieving revision 1.54
diff -u -p -r1.54 Makefile
--- sysutils/u-boot/Makefile 28 Jul 2019 06:57:19 -0000 1.54
+++ sysutils/u-boot/Makefile 29 Jul 2019 22:23:29 -0000
@@ -7,6 +7,7 @@ FLAVOR?= arm
 
 COMMENT= U-Boot firmware
 VERSION= 2019.07
+REVISION= 0
 DISTNAME= u-boot-${VERSION}
 PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
 FULLPKGNAME= ${PKGNAME}
@@ -68,7 +69,6 @@ BOARDS=\
  mvebu_espressobin-88f3720 \
  mvebu_mcbin-88f8040 \
  qemu_arm64 \
- rockpro64-rk3399 \
  rpi_3
 .elif "${FLAVOR}" == "arm"
 OMAP=\
@@ -140,7 +140,6 @@ FILES=\
  u-boot-spl.kwb \
  u-boot-with-spl.bin \
  u-boot.itb \
- idbspl.img \
  idbloader.img \
  spl/sunxi-spl.bin \
 
@@ -165,12 +164,14 @@ do-build:
         idbloader.img && \
     cat spl/u-boot-spl-dtb.bin >> idbloader.img
 .endif
-.if "${BOARD}" == "firefly-rk3399" || "${BOARD}" == "rockpro64-rk3399"
+.if "${BOARD}" == "firefly-rk3399"
  cd ${WRKSRC}/build/${BOARD} && \
     ${SETENV} ${MAKE_ENV} BL31=${RK3399_BL31} ${MAKE_PROGRAM} \
  ${MAKE_FLAGS} O="build/${BOARD}" \
         -f ${MAKE_FILE} u-boot.itb && \
-    tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
+    tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl.bin \
+ idbloader.img && \
+    cat spl/u-boot-spl-dtb.bin >> idbloader.img
 .endif
 .endfor
 .for BOARD in ${SUNXI64}
Index: sysutils/u-boot/pkg/PFRAG.aarch64
===================================================================
RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.aarch64,v
retrieving revision 1.11
diff -u -p -r1.11 PFRAG.aarch64
--- sysutils/u-boot/pkg/PFRAG.aarch64 28 Jul 2019 06:57:20 -0000 1.11
+++ sysutils/u-boot/pkg/PFRAG.aarch64 29 Jul 2019 18:17:20 -0000
@@ -16,7 +16,7 @@ share/u-boot/bananapi_m64/u-boot.bin
 share/u-boot/bananapi_m64/u-boot.img
 share/u-boot/bananapi_m64/u-boot.itb
 share/u-boot/firefly-rk3399/
-share/u-boot/firefly-rk3399/idbspl.img
+share/u-boot/firefly-rk3399/idbloader.img
 share/u-boot/firefly-rk3399/u-boot
 share/u-boot/firefly-rk3399/u-boot.bin
 share/u-boot/firefly-rk3399/u-boot.img
@@ -86,12 +86,6 @@ share/u-boot/pinebook/u-boot.itb
 share/u-boot/qemu_arm64/
 share/u-boot/qemu_arm64/u-boot
 share/u-boot/qemu_arm64/u-boot.bin
-share/u-boot/rockpro64-rk3399/
-share/u-boot/rockpro64-rk3399/idbspl.img
-share/u-boot/rockpro64-rk3399/u-boot
-share/u-boot/rockpro64-rk3399/u-boot.bin
-share/u-boot/rockpro64-rk3399/u-boot.img
-share/u-boot/rockpro64-rk3399/u-boot.itb
 share/u-boot/rpi_3/
 share/u-boot/rpi_3/u-boot
 share/u-boot/rpi_3/u-boot.bin

Reply | Threaded
Open this post in threaded view
|

Re: ROCKPro64 firmware

Jonathan Gray-11
On Tue, Jul 30, 2019 at 12:25:08AM +0200, Mark Kettenis wrote:

> > Date: Mon, 29 Jul 2019 14:07:09 +1000
> > From: Jonathan Gray <[hidden email]>
> >
> > On Sun, Jul 28, 2019 at 11:40:26PM +0200, Mark Kettenis wrote:
> > > > Date: Sun, 28 Jul 2019 17:04:12 +1000
> > > > From: Jonathan Gray <[hidden email]>
> > > >
> > > > On Fri, Jun 21, 2019 at 10:24:48PM +0200, 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.
> > > > >
> > > > > 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.
> > > >
> > > > I have committed a U-Boot 2019.07 update which builds the
> > > > rockpro64-rk3399 target and patches the default baud to 115200.
> > > >
> > > > As on firefly it has file named idbspl.img instead of idbloader.img.
> > > > Don't have hardware so not sure if further patches are required.
> > >
> > > Unfortunately the LPDDR4 support patches landed after 2019.07 was
> > > released.  The ROCKPro64 won't work without those patches, and it is a
> > > rather large set of patches :(.
> >
> > Alright, I'll remove it until the next release.
> >
> > >
> > > I'm somewhat surprised to see that the rk3399 targets still build
> > > without TPL.  But maybe the SPL overflow happens because of the LPDDR4
> > > patches.  When we switch to TPL, I think it makes sense to start using
> > > idbloader.img instead of idspl.img to be consistent with rk3288 and
> > > the Rockchip documentation.
> >
> > Aren't the rk3399 targets already using TPL with 2019.07?
> >
> > evb-rk3399_defconfig:CONFIG_TPL=y
> > firefly-rk3399_defconfig:CONFIG_TPL=y
> > nanopc-t4-rk3399_defconfig:CONFIG_TPL=y
> > nanopi-m4-rk3399_defconfig:CONFIG_TPL=y
> > nanopi-neo4-rk3399_defconfig:CONFIG_TPL=y
> > orangepi-rk3399_defconfig:CONFIG_TPL=y
> > rock-pi-4-rk3399_defconfig:CONFIG_TPL=y
> > rockpro64-rk3399_defconfig:CONFIG_TPL=y
> >
> > $ git tag --contains bdc00080111f6dc1e48586239e71e22665004aca
> > v2019.07
> > v2019.07-rc2
> > v2019.07-rc3
> > v2019.07-rc4
> >
>
> Your diff is not quite right as it doesn't concatenate tpl and spl.
> Fix below.  Still need to test this though.  But ok if it boots on the
> firefly?

yes

>
>
> Index: sysutils/u-boot/Makefile
> ===================================================================
> RCS file: /cvs/ports/sysutils/u-boot/Makefile,v
> retrieving revision 1.54
> diff -u -p -r1.54 Makefile
> --- sysutils/u-boot/Makefile 28 Jul 2019 06:57:19 -0000 1.54
> +++ sysutils/u-boot/Makefile 29 Jul 2019 22:23:29 -0000
> @@ -7,6 +7,7 @@ FLAVOR?= arm
>  
>  COMMENT= U-Boot firmware
>  VERSION= 2019.07
> +REVISION= 0
>  DISTNAME= u-boot-${VERSION}
>  PKGNAME= u-boot-${FLAVOR}-${VERSION:S/-//}
>  FULLPKGNAME= ${PKGNAME}
> @@ -68,7 +69,6 @@ BOARDS=\
>   mvebu_espressobin-88f3720 \
>   mvebu_mcbin-88f8040 \
>   qemu_arm64 \
> - rockpro64-rk3399 \
>   rpi_3
>  .elif "${FLAVOR}" == "arm"
>  OMAP=\
> @@ -140,7 +140,6 @@ FILES=\
>   u-boot-spl.kwb \
>   u-boot-with-spl.bin \
>   u-boot.itb \
> - idbspl.img \
>   idbloader.img \
>   spl/sunxi-spl.bin \
>  
> @@ -165,12 +164,14 @@ do-build:
>          idbloader.img && \
>      cat spl/u-boot-spl-dtb.bin >> idbloader.img
>  .endif
> -.if "${BOARD}" == "firefly-rk3399" || "${BOARD}" == "rockpro64-rk3399"
> +.if "${BOARD}" == "firefly-rk3399"
>   cd ${WRKSRC}/build/${BOARD} && \
>      ${SETENV} ${MAKE_ENV} BL31=${RK3399_BL31} ${MAKE_PROGRAM} \
>   ${MAKE_FLAGS} O="build/${BOARD}" \
>          -f ${MAKE_FILE} u-boot.itb && \
> -    tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl.bin idbspl.img
> +    tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl.bin \
> + idbloader.img && \
> +    cat spl/u-boot-spl-dtb.bin >> idbloader.img
>  .endif
>  .endfor
>  .for BOARD in ${SUNXI64}
> Index: sysutils/u-boot/pkg/PFRAG.aarch64
> ===================================================================
> RCS file: /cvs/ports/sysutils/u-boot/pkg/PFRAG.aarch64,v
> retrieving revision 1.11
> diff -u -p -r1.11 PFRAG.aarch64
> --- sysutils/u-boot/pkg/PFRAG.aarch64 28 Jul 2019 06:57:20 -0000 1.11
> +++ sysutils/u-boot/pkg/PFRAG.aarch64 29 Jul 2019 18:17:20 -0000
> @@ -16,7 +16,7 @@ share/u-boot/bananapi_m64/u-boot.bin
>  share/u-boot/bananapi_m64/u-boot.img
>  share/u-boot/bananapi_m64/u-boot.itb
>  share/u-boot/firefly-rk3399/
> -share/u-boot/firefly-rk3399/idbspl.img
> +share/u-boot/firefly-rk3399/idbloader.img
>  share/u-boot/firefly-rk3399/u-boot
>  share/u-boot/firefly-rk3399/u-boot.bin
>  share/u-boot/firefly-rk3399/u-boot.img
> @@ -86,12 +86,6 @@ share/u-boot/pinebook/u-boot.itb
>  share/u-boot/qemu_arm64/
>  share/u-boot/qemu_arm64/u-boot
>  share/u-boot/qemu_arm64/u-boot.bin
> -share/u-boot/rockpro64-rk3399/
> -share/u-boot/rockpro64-rk3399/idbspl.img
> -share/u-boot/rockpro64-rk3399/u-boot
> -share/u-boot/rockpro64-rk3399/u-boot.bin
> -share/u-boot/rockpro64-rk3399/u-boot.img
> -share/u-boot/rockpro64-rk3399/u-boot.itb
>  share/u-boot/rpi_3/
>  share/u-boot/rpi_3/u-boot
>  share/u-boot/rpi_3/u-boot.bin