I have an issue trying to boot FreeBSD 13.1-RELEASE on a Raspberry Pi Model 3B+ and the same issue on a Raspberry pi 4. I'm using the FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img written to an SD card. On boot up, it stops at the U-boot prompt and does not proceed until I enter the command "boot". I wish to auto boot FreeBSD without having to intervene with the "boot" command at the U-boot prompt. I'm told that if I set "bootdelay=0" at the U-boot prompt and then save it, that this will solve the issue and so that FreeBSD boots up when power is supplied. I've tried to set bootdelay=0 at the U-boot prompt using: setenv bootdelay 0 saveenv the "saveenv" fails to write the change to flash though with an error. Other people I've discussed this with on the freebsd forums have said that the "saveenv" command fails for them as well and they are unable to save changes. So there are basically two issues that I have: 1) FreeBSD-13.1-RELEASE does not boot up when power is supplied, the boot sequence stops at the U-boot prompt. 2) The U-boot "saveenv" command fails to write changes to flash
*** Bug 268631 has been marked as a duplicate of this bug. ***
(In reply to John Rushford from comment #0) I've no access to a RPi3B+. So I can only comment based on RPi4B's that I have access to sometimes (and one RPi3B that I sometimes have access to). I've never had any version of FreeBSD, releng/13.* or snapshot of stable/13 or main [so: 14], stop at the U-Boot prompt unless I typed something to top its countdown before the countdown completed. (Same goes for personal builds.) (A noisy serial connection could be the same as typing, but that is not a problem that I've had.) I have on occasion deliberately stopped the countdown to get to the U-Boot prompt. (For example, to print the live fdt.) saveenv is a separate, long-known issue. I do have access to some USB3 NVMe based media that require something like a usb_gpood_delay assignment in order for U-Boot to use the media. I build a patched U-Boot that contains such (Given that saveenv is ineffective in the context.)
(In reply to Mark Millard from comment #2) Mark, I have tried two different raspberry pi's, a 4 and a 3B+. Both stop at the U-boot prompt and I've tried also without a keyboard or mouse plugged into the pi's. It's not halting because I inadvertently stopped by hitting a key on the keyboard. I'm using the image from the download page written to an SD card, FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img.xz dated 2022-May-12 08:46 John
(In reply to John Rushford from comment #3) I only have access to 2 of the 7 RPi4Bs currently. But for those 2 . . . (On another FreeBSD aarch64 machine to set up the microsd card. . .) # dd if=FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img of=/dev/da3 bs=1m conv=fsync,sync status=progress 3200253952 bytes (3200 MB, 3052 MiB) transferred 48.063s, 67 MB/s 3072+0 records in 3072+0 records out 3221225472 bytes transferred in 48.484735 secs (66437931 bytes/sec) Summary of the below: both work fine and do not stop at the U-Boot prompt: they both get all the way to the login prompt. Your problem is somehow more specific to your context rather than a problem everyone gets for RPi4B's. A "C0T" Rev1.5 8 GiByte RPI4B was used for 1st boot from the microsd card: . . . U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03115) MMC: mmc@7e300000: 3, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC 7[r[999;999H[6n8Scanning disk mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 1262604 bytes read in 72 ms (16.7 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi . . . ---<<BOOT>>--- WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64 FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) . . . /dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/rootfs: clean, 22672 free (24 frags, 2831 blocks, 0.0% fragmentation) Growing root partition to fill device random: randomdev_wait_until_seeded unblock wait uhub1: 4 ports with 4 removable, self powered random: randomdev_wait_until_seeded unblock wait random: unblocking device. GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them. mmcsd0s2 resized mmcsd0s2a resized gpart: arg0 'ufs/rootfs': Invalid argument super-block backups (for fsck_ffs -b #) at: 6402432, 7682880, 8963328, 10243776, 11524224, 12804672, 14085120, 15365568, 16646016, 17926464, 19206912, 20487360, 21767808, 23048256, 24328704, 25609152, 26889600, 28170048, 29450496, 30730944, 32011392, 33291840, 34572288, 35852736, 37133184, 38413632, 39694080, 40974528, 42254976, 43535424, 44815872, 46096320, 47376768, 48657216, 49937664, 51218112, 52498560, 53779008, 55059456, 56339904, 57620352, 58900800, 60181248, 61461696 Mounting local filesystems:. . . . Starting background file system checks in 60 seconds. Thu May 12 08:46:43 UTC FreeBSD/arm64 (generic) (ttyu0) login: A "B0T" Rev1.4 8 GiByte Ri4B was used for 2nd boot from the microsd card: . . . U-Boot 2021.07 (May 12 2022 - 07:00:33 +0000) DRAM: 7.9 GiB RPI 4 Model B (0xd03114) MMC: mmc@7e300000: 3, emmc2@7e340000: 0 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 2 1 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... libfdt fdt_check_header(): FDT_ERR_BADMAGIC 7[r[999;999H[6n8Scanning disk mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... ** Unrecognized filesystem type ** Found 3 disks No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi 1262604 bytes read in 73 ms (16.5 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC Booting /efi\boot\bootaa64.efi . . . ---<<BOOT>>--- WARNING: Cannot find freebsd,dts-version property, cannot check DTB compliance Copyright (c) 1992-2021 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC arm64 FreeBSD clang version 13.0.0 (git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303) . . . Starting background file system checks in 60 seconds. Thu May 12 08:47:48 UTC FreeBSD/arm64 (generic) (ttyu0) login:
(In reply to Mark Millard from comment #4) I'm not sure what is causing this issue for me on both a RPI 3B+ and 4. These RPI's are stock and I wrote that image to a micro SD card just as you've done and on both RPI's it stops at the U-boot prompt. I see another bug report where they used a USB SD card adapter and their RPI then booted up without issue. I'll try writing the image to a USB stick and see if that works.
well, while this issue doesn't affect the Pi4b(at least not mine), it's true for the 3b+ .... It's an RPI3b+ firmware issue and the problem with freebsd is that changes in the RPI-firmware- upstream are not controlled(or pre-tested) by any freebsd u-boot maintainer. On the other hand we can say that this is not a freebsd bug. So long speech and short solution : I`ve extensively tested and configured this for you on a 3b+ and here's an upload of a known working u-boot/firmware : https://sourceforge.net/projects/freebsd-rpi3bplus-msdos-part/ direct download : https://sourceforge.net/projects/freebsd-rpi3bplus-msdos-part/files/working_env.zip/download Please overwrite your complete(!) msdos-partition with the content of the downloaded msdos-partition. download is ONLY FOR 3b+ since I assume the4b working. Please close this bug report if you succed in booting your 3b+ , because I can say that these kind of rpi-specific bugs will NOT be controlled by FreeBSD, not currently and not in the future.. (I recommend not thinking about it too much, simply use the downloaded msdods-partition:-) Regards Klaus
(In reply to John Rushford from comment #5) Thanks for all your replies as they have been very helpful. I'm a little embarrassed but, I have found the issue with my PI's. I was attempting to build a stratum 1 NTP server on the pi's using FreeBSD and PPS. I have an Adafruit GPS hat plugged into the GPIO pins and apparently the GPS data that is received is causing the boot processed to halt at the U-boot prompt. When I remove the GPS hat, they boot normally. So this begs the question on how do I prevent this behavior with the GPS hat plugged in? I'm told that if I were able to set the U-boot bootdelay to 0, that the pi's would just boot. However I am unable to set the bootdelay because "saceenv" doesn't work. Is there some way to have the GPIO serial lines ignored so that GPS data/noise doesn't interrupt the boot sequence? Should I close this bug report and open another? thanks for your help
(In reply to John Rushford from comment #7) Using the same pins as the FreeBSD serial console for device data may well have other problems until some reconfiguration of the default FreeBSD install. For example, the default install will produce a login prompt and the device data would be feeding that login prompt. Of course, you have already seen the problems with using the same pins as U-Boot uses (not distinct pins from the FreeBSD serial console here). The RPi* firmware also outputs via those same pins during its stages of activity. As does U-Boot, the FreeBSD loader, the FreeBSD kernel, and FreeBSD world/user-space. If you are to control the boot sequence, say to get evidence via a "boot -v" command at the FreeBSD loader prompt, you would need these serial console pins to be available for your typing without other sources of data being fed to them. It would seem to be better to set up to use one of the other TXD/RXD/GND pins that can be configured. (Not that I've ever done such.) If the HAT does not allow using such other pins, that would seem problematical overall. There are probably folks on the freebsd-arm list that would have more detailed suggestions if you posted questions there, folks that have done analogous things themselves.
(In reply to Mark Millard from comment #8) I probably should have noted that the RPi* EEPROM and firmware likely output to the serial console ports pins before any Device Tree Overlays (.dtbo files) are loaded that could (re-)configure which UART(s) are routed to which supported pins. This likely tends to mean that those pins are less likely to be reused for purposes where such output could be a problem. Also, as I remember, the RPi4B's have more UARTs available to configure than the historical RPi2B v1.1, RPi2B v1.2, RPi3B, RPI3B+, and the like.
(In reply to John Rushford from comment #7) <<So this begs the question on how do I prevent this behavior with the GPS hat plugged in?I'm told that if I were able to set the U-boot bootdelay to 0, that the pi's would just boot. However I am unable to set the bootdelay because "saveenv" doesn't work.>> I also have hardware plugged into GPIO(while the serial line pin chip on my 3b+ is physically broken), the exact same boot issue you described was fixed by the msdos - partition-download I offered,`would be interesting to know, if it also fixes your (GPIO-) issue, did you try??? I would not expect that bootdelay=0 will fix the issue(because I tried with a compiled in bootdelay=0 u-boot-version), but for the /saveenv/, if I find the time, I'll try to offer a solution(If possible).. but please keep in mind that it all depends on a correct combination of firmware/u-boot!! otherwise it will fail and it doesn't make sense to struggle with it: nearly no one knows what exactly happens on the rpi fw-side... K.
(In reply to John Rushford from comment #7) Hmm. I looked at: https://www.adafruit.com/product/2324 and it reports: QUOTE Please note, this HAT takes over the Raspberry Pi's hardware UART to send/receive data to and from the GPS module. So, if you need to use the RX/TX pins with a console cable, you cannot also use this HAT. Instead, you'll have to use a composite or HDMI monitor and keyboard to log in or use ssh to connect over the network to your Pi. END QUOTE Also, looking around, it may only be the RPi4Bs (an related) that can have multiple TXD/RXD/GND configured, not the RPi3B+ .
(In reply to Klaus Küchemann from comment #10) Klaus, I replaced my /boot/msdos partition with the software you provided and the RPI 3b+ now boots with the GPS hat installed. I'm curious as to what you changed to overcome my issue. My next step is to complete the configuration and get GPSD, PPS and NTP working. If you're curious, I'm going through this: https://framkant.org/2017/03/stratum-1-ntp-server-with-freebsd-on-raspberry-pi/ thanks for your help
(In reply to Mark Millard from comment #11) Yes, I only plan to use ssh to login to the PI. I had this all working using Raspian OS without any issues, GPS hat, PPS and NTP but, I prefer using FreeBSD so I'm trying to get it working now.
(In reply to John Rushford from comment #12) John, thanks for testing. I'm glad to hear that https://sourceforge.net/projects/freebsd-rpi3bplus-msdos-part/ can now be seen as a validated fix for this bug. Well, for your curiosity as to what I've changed : ... the story of FreeBSD "struggling" with RPI-firmware and u-boot is very long and hard to explain(and FreeBSD is not alone with it). The solution in this case was to replace the non-working current port of firmware/u-boot combination with a working one,based on longer experience and "pre-sourcecode-hacking by trial&error", In this case no source code change did it but replacing the fw/u-boot versions. All this is not always scientific but widely known as the safest way for Non-Raspbian systems. So my recommendation for FreeBSSD maintainers of these ports is to use fixed, validated fw-u-boot environments for the specific devices , based on reports like this(instead of merging untested upstream versions). This was compiled u-boot for the 3b+, please let me know if you need similar for the 4b... Interesting GPS/NTP project you do, I also began gpio-projects like e.g. LoraWAN etc., but how it is with all this plans: hardware bought but sometimes more plans than time :-) Regards K.
(In reply to Klaus Küchemann from comment #14) Klaus, thanks for the 3B+ u-boot software and if you have the time, I sure could use it for the 4B as well. best regards John Rushford
(In reply to John Rushford from comment #15) Hi & happy new year , as suspected, I could not reproduce this issue on my rpi4b (4GB&8GB-early models) with the same GPIO hardware as on the 3b. Both boot the 13.1 release msdos-partition. A first try for your 4b could be to overwrite u-boot.bin on the downloaded 3b msdos partition with the u-boot.bin version from the 13.1release and then try to boot that sd-card on your 4b. In general context for the GPIO settings via config.txt this document is very useful : https://www.raspberrypi.com/documentation/computers/config_txt.html#gpio If then your 4b still hangs on u-boot`s boot-prompt, we talk again... if you succeed please let us know, Regards K.