Date: Sat, 23 Apr 2022 02:42:27 -0700 From: Mark Millard <marklmi@yahoo.com> To: "freebsd-arm@freebsd.org" <arm@freebsd.org> Subject: Looks like U-Boot 2022.04 may be fairly useful Message-ID: <D41D6A62-EF7E-4FB8-847B-663DBBC2E2DB@yahoo.com> References: <D41D6A62-EF7E-4FB8-847B-663DBBC2E2DB.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I did the following primarily as a learning exploration but I figured I'd report some on it. I have the following devices booting based on U-Boot 2022.04 built via poudriere-devel. I used testport and bulk and used portlint. I did not update RPi* firmware: this was just substituting the new U-Boot version into a working environment to see if it still works. Xunlong Orange Pi Plus 2E: U-Boot SPL 2022.04 (Apr 23 2022 - 03:19:10 +0000) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2022.04 (Apr 23 2022 - 03:19:10 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus 2E Pine64 Rock64: U-Boot TPL 2022.04 (Apr 23 2022 - 03:14:35) LPDDR3, 800MHz BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2022.04 (Apr 23 2022 - 03:14:35 +0000) Trying to boot from MMC1 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 Trying to boot from MMC2 NOTICE: BL31: v2.5(release): NOTICE: BL31: Built : 05:34:22, Dec 8 2021 NOTICE: BL31:Rockchip release version: v1.2 U-Boot 2022.04 (Apr 23 2022 - 03:15:10 +0000) Model: Pine64 Rock64 RPI 4 Model B (0xd03114): U-Boot 2022.04 (Apr 23 2022 - 03:14:35 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) Most of that is based on various FreeBSD main [so: 14] vintages, some from late March and others going back into even late last year. (I've not synchronized the systems in a long time.) But RPi4B was also booted via 13.1-RC4 with the u-boot updated as well. A simplified sequencing of the exploration is . . . I started by updating: modified: devel/aarch64-none-elf-gcc/Makefile modified: devel/aarch64-none-elf-gcc/distinfo deleted: devel/aarch64-none-elf-gcc/files/patch-libcpp_lex.c modified: devel/aarch64-none-elf-gcc/pkg-plist modified: devel/arm-none-eabi-gcc/Makefile modified: devel/arm-none-eabi-gcc/distinfo modified: devel/arm-none-eabi-gcc/pkg-plist to be based on gcc 11.3.0 (the first non -devel gcc port to have a bug fix for how it interacts with modern binutils). Without the fix U-Boot 2022.04 would not build. I then updated: modified: sysutils/u-boot-tools/Makefile modified: sysutils/u-boot-tools/distinfo to be based on 2022.04 . (Turns out that this does not run into the toolchain bug that u-boot builds run into. So gcc 11.3.0 is more optional here. Originally I used 11.2.0 --which still has the toolchain bug, as I discovered later.) I then updated: modified: sysutils/u-boot-master/Makefile modified: sysutils/u-boot-master/distinfo deleted: sysutils/u-boot-master/files/patch-common__bootm.c as well. ( Actually, that last is now in a sysutils/u-boot-master/files/patch-boot_bootm.c .) This did run into the toolchain bug and, for now, 11.3.0 is the fix, at least until gcc9 or gcc10 gets an update that has the fix. The fix was produced after gcc8 went out of support so gcc8 will not be updated by the gcc folks to work correctly with modern binutils for the issue in the bug. For: modified: sysutils/u-boot-rpi-0-w/Makefile modified: sysutils/u-boot-rpi-arm64/Makefile modified: sysutils/u-boot-rpi/Makefile modified: sysutils/u-boot-rpi2/Makefile modified: sysutils/u-boot-rpi3/Makefile modified: sysutils/u-boot-rpi4/Makefile I removed U_BOOT_SLAVE_PORTREVISION_2021.07 and the 1547145/raw patchfile item that does not apply. (I have other RPi* patches that I've had for a long time.) I do not actually have access to a rpi-0-w but it fit the editing pattern. For rpi-0-w, the build is untested. The other u-boot slave ports ( u-boot-orangepi-plus-2e , u-boot-rock64 , u-boot-pine64 , u-boot-sinovoip-bpi-m3 ) did not need changes to build. I've not had access to a working pine64 or u-boot-sinovoip-bpi-m3 in years at this point. So: those builds are untested. Exploring adjusting things for portlint and how it handled various things means that I moved around more text than strictly necessary. I noticed an oddity here or there that I took a guess about the appropriate fix, not that I actually know. As for pkg-plist files, I mostly assumed that what was put in the staging area was correct and listed it. I do not have independent knowledge of what should be there. There are both files that no longer exist and files that are added. testport reported a type of example of something that I removed from what I originally generated. If I end up with access to a 8 GiByte RPi4B Rev 1.5 with the C0T stepping (no 3 Gibyte limitation, for example), I'll probably use these builds to explore booting it. That might have to involve RPi* firmware updates. My understanding is that there were dtb changes at some point that FreeBSD is not set up to handle --even for RPi4B's that now work with the firmware from the port. But I could be wrong about such. === Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D41D6A62-EF7E-4FB8-847B-663DBBC2E2DB>