On Sun, 30 Jun 2019, Mark Kettenis wrote:
> > 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.
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 dw...@fe320000.blk...
Card did not respond to voltage select!
Scanning disk sd...@fe330000.blk...
Disk sd...@fe330000.blk 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
> > >
> > >
> >
>
>
