On Sat, Oct 12, 2019 at 08:31:07PM +0000, Zachary Buhman wrote: > > Some bright sould decided to change the clock binding when RK3328 > > support was added to the mailine Linux kernel. But U-Boot still uses > > an older clock binding. The OpenBSD kernel expects a device tree that > > uses the new clock binding and won't properly initialize some of the > > SoC clocks. > > This is genuinely fascinating. > > > You can fix this by explicitly providing a device tree on your boot > > media. Install the "dtb" package and copy the appropriate device tree > > into a subdirectory named "rockchip" on the msdos partition on your > > boot media. > > Sorry for being dense. I am a bit noob at all of this, but I did some reading > and came up with: > > $ sudo cp ./dtb-4.20p0/share/dtb/arm64/rockchip/rk3328-rock64.dtb > /mnt/rockchip > $ cat <<EOF> boot.cmd > fatload mmc 1:1 $fdt_addr_r rockchip/rk3328-rock64.dtb > fatload mmc 1:1 $kernel_addr_r efi/boot/bootaa64.efi > bootefi $kernel_addr_r $fdt_addr_r > EOF > $ ./u-boot/tools/mkimage -C none -A arm -T script -d boot.cmd boot.scr > Image Name: > Created: Sat Oct 12 12:50:15 2019 > Image Type: ARM Linux Script (uncompressed) > Data Size: 151 Bytes = 0.15 KiB = 0.00 MiB > Load Address: 00000000 > Entry Point: 00000000 > Contents: > Image 0: 143 Bytes = 0.14 KiB = 0.00 MiB > $ sudo cp boot.scr /mnt/boot.scr > > Where /mnt is the fat partition.
To use a non-builtin dtb on rock64 it should be enough to just put it in the rockchip directory. Without a script. The U-Boot port was patched to have the new clock binding as well though, so if you use U-Boot 2019.10 from ports/packages everything should work with the builtin dtb. > > This boots perfectly, and results in a working dwge (or 'working' as in: at > least not completely broken). > > > We are actually working on providing a proper completely open source > > U-Boot for the rock64 in the OpenBSD u-boot-aarch64 package. > > Very exciting! > > How are these intended to be used from a pre/post-install perspective? > Perhaps the install documentation could mention (how to use) these. I'd be > happy to help contribute that if considered desirable. > > > we think that is more usable than the rockchip default of 1500000. > > Constantly switching between 1500000/115200 while debugging the boot process > is painful indeed. > > > That said, even with that firmware the Ethernet port doesn't quite > > work flawlessly. It seems there is occasional packet loss that I'm > > not seeing on other hardware that uses the same dwge(4) driver. > > Huh. Happy to help test if desired. I have 3 dwge boards > (rock64/rockpro64/odriod-n2) currently. > > Thank you for your help! >
