I can't install FreeBSD 13.1-Release from an image and make it boot by copying idbloader.img and u-boot.itb to a SD drive as mentioned in the README. Is this simply because this version doesn't support my hardware which is an Radxa pi 4 SE?
I'll note that the Armbian web materials indicate: "For Model SE, use the Model B builds" From what I saw there were 4A, 4B, 4C, and 4C+ but it was not obvious if any shared the same mainline U-Boot or not. (They are using a mainline U-Boot because it boots a generally wider variety of NVMe drives, from what one of its pages says.) It looks like finding material that references 4B may be easier than finding material that references 4SE.
I have followed a discussion over at the Radxa forum: https://forum.radxa.com/t/freebsd-13-current-on-rock-pi4/2071/26 Ashley Mills writes the following as part of an answer to getting it to work on a Radxa Rock pi 4C board: 1.On your FreeBSD machine (or in a VM) goto /usr/ports/sysutils/u-boot-rock-pi-4 2. Edit the Makefile and change BOARD_CONFIG to rock-pi-4c-rk3399_defconfig 3. Build that port 4. Download the official rockpro64 image for freebsd and unxz it 5. Write the image to your emmc/SD card 6.Then write the uboot with the port you built I am not sure if changing the BOARD_CONFIG would case u-boot to pick up the right DTB? All this ARM and u-boot stuff is new to me...
(In reply to Jon Theil Nielsen from comment #2) https://elixir.bootlin.com/u-boot/latest/source/configs/rock-pi-4-rk3399_defconfig shows in the file's content: CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-pi-4b" and: CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4b.dtb" Looks like it has been that way since 2020.10 of U-Boot. Of course, this need not match the linux kernel in various ways.
(In reply to Mark Millard from comment #3) Thanks, I see that now. So if I don't want to wait until the actual board is included with a device tree upstream - can I do something on my own? It seems to be working quite good with an installation of Debian.
(In reply to Jon Theil Nielsen from comment #4) Looking in: https://elixir.bootlin.com/linux/v5.10/source/arch/arm64/boot/dts/rockchip I see a rk3399-rock-pi-4b.dts listed. It has been around since then (5.10) from what I can tell. https://elixir.bootlin.com/linux/v5.16/source/arch/arm64/boot/dts/rockchip (5.16) lists a rk3399-rock-pi-4b-plus.dts as well. So it seems that both U-Boot and Linux mainlines have rock-pi-4b support to some extent and have been for some time. Thus the Linux one should be in the main [so: 14] source tree. I see in my somewhat old FreeBSD main [so: 14] source tree: sys/contrib/device-tree/src/arm64/rockchip/rk3399-rock-pi-4b.dts sys/contrib/device-tree/src/arm64/rockchip/rk3399-rock-pi-4b-plus.dts I do not see them in my somewhat old stable/13 source tree. I do not see a /boot/dtb/rockchip/rk3399-rock-pi-4.dtb in my main [so: 14] install. Because FreeBSD is set up for the Linux dts content, you likely need to put the FreeBSD built rk3399-rock-pi-4.dtb appropriately placed in the msdosfs file system. U-Boot will pick up the .dtb you provide and hand it's content over to the FreeBSD loader. I do such for the Rock64, placing the .dtb at: dtb/rockchip/rk3328-rock64.dtb Then U-Boot uses it and hands to over to the FreeBSD loader. If I have the .dtb missing from there for some reason, U-Boot uses its internal one that does not match what the FreeBSD kernel handles and the boot fails via the kernel. (The Rock64 already has its .dtb built installed into /boot/dtb/rockchip/ for FreeBSD, including via stable/13 and releng/13.* .) So, likely some makefile(s) needs to list the rk3399-rock-pi-4b.dts as one to be built and to put the .dtb into /boot/dtb/rockchip/ on installation, for you to then copy to the msdosfs as dtb/rockchip/rk3399-rock-pi-4b.dtb . (Installing the appropriate U-Boot itself is a separate issue.)
(In reply to Mark Millard from comment #5) I will see if I can make it work. But I feel a little uncertain about the actual steps involved. In parallel to this bug, I participate in a discussion over at the Radxa forum: https://forum.radxa.com/t/freebsd-13-current-on-rock-pi4/2071/71
(In reply to Jon Theil Nielsen from comment #6) As for adding rockchip/rk3399-rock-pi-4b.dts to a Makefile goes . . . Looking for where my Rock64 example is listed in source files: (I have multiple source trees, thus the "main-src" instead of just src) # grep -r rk3328-rock64 /usr/main-src/ | more /usr/main-src/sys/modules/dtb/rockchip/Makefile: rockchip/rk3328-rock64.dts \ /usr/main-src/sys/contrib/device-tree/src/arm64/rockchip/rk3328-rock-pi-e.dts: * Based on ./rk3328-rock64.dts, which is So /usr/src/sys/modules/dtb/rockchip/Makefile looks to be where you would add a line to the existing list of dts files in that Makefile, the line looking like: rockchip/rk3399-rock-pi-4b.dts \ (no whitespace after the "\", just the end of the line). The white space at the line start is a tab character. With that in place, a build install sequence should put in place a: /boot/dtb/rockchip/rk3399-rock-pi-4b.dtb for you to then copy to the msdosfs under/as: dtb/rockchip/rk3399-rock-pi-4b.dtb
(In reply to Mark Millard from comment #7) My wording did presume that you would leave: rockchip/rk3399-rockpro64.dts as the last of the list of *.dts files. Otherwise, the details for the "\" parts of what I wrote would be wrong.
(In reply to Mark Millard from comment #8) I really appreciate your thorough explanations so I hate to ask more questions. I am not even close to be a system developer (wish I were). I am able to find the Makefile all right. And so I can add the line for the rockchip/rk3399-rock-pi-4b.dts \ But I don't know how to get further from there. I have a couple of machines running FreeBSD 13.1-RELEASE-p3 GENERIC amd64. A long time ago, I used to do manual upgrades according to the Handbook, but now I am used to use freebsd-update. Therefore, I have forgotten how to build things. I seems to me that I somehow have to build what I have in /usr/current-src/sys/modules/dtb/rockchip (this is the directory holding the lates souces). And after that, I should copy the rk3399-rock-pi-4b.dtb to the boot sector of the installation medium. I can mount the medium by iscsi. Maybe I misunderstood your explanation, so I have to do something completely different? If the explanation would be to long for posting here, could you direct me to useful documentation (e.g. the Handbook)?
(In reply to Jon Theil Nielsen from comment #9) I use the pre-existing rk3399-rock-pi-4.dts for illustration below. Looks like the include in the Makefile for rockchip: (example paths are my style "main-src" paths) /usr/main-src/sys/modules/dtb/rockchip/Makefile:.include <bsd.dtb.mk> means that using make in /usr/main-src/sys/modules/dtb/rockchip/ will deal with building .dtb files from DTS files. bsd.dtb.mk has: .include <bsd.sysdir.mk> .include "${SYSDIR}/conf/dtb.mk" .include <bsd.sys.mk> and the ${SYSDIR}/conf/dtb.mk has: .include "dtb.build.mk" .if !target(install) && !target(realinstall) all: ${DTB} ${DTBO} realinstall: _dtbinstall .ORDER: beforeinstall _dtbinstall CLEANFILES+=${DTB} ${DTBO} .endif # !target(install) && !target(realinstall) .include <bsd.dep.mk> .include <bsd.obj.mk> .include <bsd.links.mk> So it looks like a sequence like: (using an example context with less pre-built) # cd /usr/13S-src/sys/modules/dtb/rockchip/ # make all will build various things, including the file of interest. Trying, the output messages included: Generating rockchip/rk3399-rock-pi-4.dtb from /usr/13S-src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-rock-pi-4.dts converting /usr/13S-src/sys/contrib/device-tree/src/arm64/rockchip/rk3399-rock-pi-4.dts -> /usr/obj/usr/13S-src/arm64.aarch64/sys/modules/dtb/rockchip/rk3399-rock-pi-4.dtb Checking . . . # file /usr/obj/usr/13S-src/arm64.aarch64/sys/modules/dtb/rockchip/rk3399-rock-pi-4.dtb /usr/obj/usr/13S-src/arm64.aarch64/sys/modules/dtb/rockchip/rk3399-rock-pi-4.dtb: Device Tree Blob version 17, size=73947, boot CPU=0, string block size=6291, DT structure block size=66576 So, at that point you should have a file that you could copy over to the msddosfs. (I did not add the file that you would add. So the name of interest in your context will be different.) The use of stable/13 materials was only because the context had not done a buildworld buildkernel sequence. So it looks like the .dtb production does not require other infrastructure from build activity to do its work. Use a source tree appropriate to your context. The actual stable/13 that was running was an official snapshot build (with extra reference material added), not one of my builds: # uname -apKU # The long output line has been split for readability FreeBSD generic 13.1-STABLE FreeBSD 13.1-STABLE #0 stable/13-n253133-b51ee7ac252c: Wed Nov 23 03:36:16 UTC 2022 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 aarch64 1301509 1301509
(In reply to Mark Millard from comment #10) Thanks again. The output of uname -apKU from my machine (apart from the first part) is: 13.1-RELEASE-p3 FreeBSD 13.1-RELEASE-p3 GENERIC amd64 amd64 1301000 1301000 I have tried 'build all' both in the original /usr/src and the /usr/current-src with the modified Makefile. The command makes the output (in one line): '[Creating objdir /usr/obj/usr/current-src/amd64.amd64/sys/modules/dtb/rockchip...]' Output of tree /usr/obj/usr/current-src/: /usr/obj/usr/current-src/ `-- amd64.amd64 `-- sys `-- modules `-- dtb `-- rockchip 5 directories, 0 files So it seems I am building for the wrong architecture. I tried to build it with env MACHINE_ARCH=aarch64 make all but that didn't work either.
(In reply to Jon Theil Nielsen from comment #11) I was building on an aarch64 system, not amd64, so native. Do you need to do cross building for some reason?
(In reply to Mark Millard from comment #12) One of the .mk files involved does the likes of: .PATH.dts: ${SYSDIR}/contrib/device-tree/src/${MACHINE} ${SYSDIR}/dts/${MACHINE} .PATH.dtso: ${SYSDIR}/dts/${MACHINE}/overlays So you need both MACHINE and MACHINE_ARCH to be defined to the cross build target values: # make MACHINE=arm64 MACHINE_ARCH=aarch64 all
(In reply to Mark Millard from comment #13) Oh! # tree /usr/obj/usr/current-src/arm64.aarch64/sys/modules/dtb/rockchip/ /usr/obj/usr/current-src/arm64.aarch64/sys/modules/dtb/rockchip/ |-- rk3328-analog-sound.dtbo |-- rk3328-i2c0.dtbo |-- rk3328-nanopi-r2s.dtb |-- rk3328-rock-pi-e.dtb |-- rk3328-rock64.dtb |-- rk3328-uart1.dtbo |-- rk3399-firefly.dtb |-- rk3399-khadas-edge-captain.dtb |-- rk3399-khadas-edge-v.dtb |-- rk3399-khadas-edge.dtb |-- rk3399-mmc0-disable.dtbo |-- rk3399-mmc1-disable.dtbo |-- rk3399-nanopc-t4.dtb |-- rk3399-nanopi-r4s.dtb |-- rk3399-rock-pi-4.dtb |-- rk3399-rock-pi-4b.dtb |-- rk3399-rockpro64.dtb `-- rk3399-sdhci-disable.dtbo 0 directories, 18 files Thanks so much. I will test the rest tomorrow. But I think this was the hardest part for me to figure out.
(In reply to Mark Millard from comment #13) I just want to confirm that this approach solved the problem of booting into FreeBSD. I used the image for FreeBSD-14.0-CURRENT-arm64-aarch64-ROCKPRO64 and afterwards installed u-boot according to the /usr/local/share/u-boot/u-boot-rock-pi-4/README. It was far beyond my knowloge as an "ordinary" FreeBSD user even when I consulted both the Handbook and various wiki pages. Normally, I don't think much about the boot process and the hardware layer. Maybe there should be a paragraph in Chapter 14 "The FreeBSD Booting Process" about u-boot, device trees and so on? Now I will try to figure out the rest of the configuration. I guess there will be more challenges but as long as I have a SSH and a working network connection most of it will be easier for me. Thank you very much for the help!
Just to add here, I'm using SleepWalker's privately patched u-boot port, both on a RockPi 4A as well as on a RockPi 4SE. I started using it because I needed SPI flash support (to be able to boot from NVMe SSD). The very same u-boot also booted the 4SE without problems. I'm going to work together with him to see what needs to be done to update the official FreeBSD u-boot port for these devices. Besides SPI flash support (and obviously, solving any issue with the 4SE), it also adds support to boot from an USB stick. Regarding the documentation, I'm not sure whether there is even a single person who fully understands all that. :-) I have been doing u-boot stuff at a previous job (including adding things like failover capabilities and so), so maybe I can dig again a bit into it, and remember enough to describe that. However, so far I have yet to find someone (beyond maybe Linus Torvalds) who fully grasped that device tree stuff. Everyone I met so far operates on a copy&paste level there. :-/
(In reply to Joerg Wunsch from comment #16) Fully understand what ? If you think that only Linus understand device tree stuff you're really out of your mind, a lot of people (including me) in FreeBSD understand it (it's not that complicated tbh).
(In reply to Emmanuel Vadot from comment #17) OK, then you might add documentation for it. ;-) (was requested a couple of comments above)