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