|Summary:||U-Boot build for Raspberry Pi 4 (arm64) does not boot from MicroSD card slot|
|Product:||Base System||Reporter:||Leo Schneider <ttkdroid>|
|Component:||arm||Assignee:||freebsd-arm (Nobody) <freebsd-arm>|
|Severity:||Affects Only Me||CC:||canardo909, christer.solskogen, hokan, karels, maciphone2, marklmi26-fbsd, nicolai-freebsd, rleigh, ttkdroid, wen|
Description Leo Schneider 2021-04-15 07:45:26 UTC
TEST SCENARIO 1. Flashed the image FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz in MicroSD using dd on MacOS 2. Inserted flashed MicroSD on RaspberryPi 4 slot 3. U-Boot fails to find the MicroSD 4. U-Boot then looks for USB storage but can't find it 5. U-Boot then try to boot from network 6. Same MicroSD card is inserted in a MicroSD-USB adapter and inserted on Raspberry Pi USB Port 7. FreedBSD boots OK OBSERVATIONS 1: The U-Boot build doesn't include the command 'sdboot' thus it was not possible to manually force the boot from the MicroSD card slot 2: The U-Boot "boot_targets" has "mmc" defined 3. It switches to "mmc0" which I assume is the MicroSD card but complains "** No partition table - mmc 0 **" and then switch to network boot
Comment 1 Mark Millard 2021-04-15 09:23:21 UTC
I did the following: 1. Flashed the image FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz onto a MicroSD, using dd on a Rock64 running FreeBSD. 2. Inserted flashed MicroSD in various RaspberryPi 4 slots (RPi4B 8 GiByte v1.4, RPI4B 4 GiByte v1.1, RPi3B 1 GiByte v1.2, RPi2B 1GiByte v1.2 [so: cortex-a53 version]). 3. They all booted just fine from the MicroSD. (The growfs happened on the 8 GiByte RPi4B.) There must be something more involved in your context's details that contributes to your results. The problem will be to identify what all contributes to the distinctions. If you can capture and attach the serial console output, it might be useful for someone trying to help. I will note that it is normal for there to be messages about both mmc0 and mmc1. For example for a USB3-SSD-only boot, no microsd card in place, there is in the recent log file that I recorded (for other reasons at the time): mmc0: No compatible cards found on bus mmc1: No compatible cards found on bus
Comment 2 Mark Millard 2021-04-15 18:13:05 UTC
(In reply to Mark Millard from comment #1) I recorded the RPi4B 8 GiByte booting from the media: mmcsd0: 31GB <SDHC SDCIT 3.0 SN 002BC426 MFG 10/2016 by 65 42> at mmc1 50.0MHz/4bit/65535-block So mmc1 was used for the card, not mmc0. Notably the mmc0 and mmc1 messages are from the FreeBSD kernel, just before the cpu information (in case yours was from a different time frame): mmc0: No compatible cards found on bus mmcsd0: 31GB <SDHC SDCIT 3.0 SN 002BC426 MFG 10/2016 by 65 42> at mmc1 50.0MHz/4bit/65535-block bcm2835_cpufreq0: ARM 600MHz, Core 200MHz, SDRAM 400MHz, Turbo OFF Release APs...Trying to mount root from ufs:/dev/ufs/rootfs [rw]... done CPU 0: ARM Cortex-A72 r0p3 affinity: 0 Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG> Instruction Set Attributes 0 = <CRC32> Instruction Set Attributes 1 = <> Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32> Processor Features 1 = <> Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,16TB PA> Memory Model Features 1 = <8bit VMID> Memory Model Features 2 = <32bit CCIDX,48bit VA> Debug Features 0 = <2 CTX BKPTs,4 Watchpoints,6 Breakpoints,PMUv3,Debugv8> Debug Features 1 = <> Auxiliary Features 0 = <> Auxiliary Features 1 = <> CPU 1: ARM Cortex-A72 r0p3 affinity: 1 CPU 2: ARM Cortex-A72 r0p3 affinity: 2 CPU 3: ARM Cortex-A72 r0p3 affinity: 3 The earlier mmc0 or mmc1 kernel messages were in the sequence: mmc0: <MMC/SD bus> on sdhci_bcm0 fb0: <BCM2835 VT framebuffer driver> on simplebus0 fb0: keeping existing fb bpp of 32 fbd0 on fb0 WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0. VT: Replacing driver "efifb" with new "fb". fb0: 592x448(592x448@0,0) 32bpp fb0: fbswap: 1, pitch 2368, base rx3eaf5000, screen_size 1060864 sdhci_bcm1: <Broadcom 2708 SDHCI controller> mem 0x7e340000-0x7e3400ff irq 79 on simplebus1 mmc1: <MMC/SD bus> on sdhci_bcm1 The only u-boot tiem frame references to "mmc" or "MMC" were in the sequence: MMC: mmc@7e300000: 1, 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... 4 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... Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC 7[r[999;999H[6n8Scanning disk firstname.lastname@example.org... Disk email@example.com not ready Scanning disk firstname.lastname@example.org... So I did not get the partition table message, but your was for mmc0 and in my context the microsd card showed up on mmc1 instead, at least as the FreeBSD kernel names things. You may need to quote more context of the text around the mmc messages as part of helping people help you.
Comment 3 christer.solskogen 2021-04-15 18:38:40 UTC
Do you have a mouse connected? I've seen the same thing with my device when a mouse is connected.
Comment 4 Mark Millard 2021-04-16 04:39:00 UTC
(In reply to christer.solskogen from comment #3) FYI: In my context having a mouse also connected to the RPi4B 8 GiByte did not create a problem. Booting still just worked.
Comment 5 Nicolai Plum 2021-04-17 17:49:35 UTC
I am seeing this problem too. A new rPi will not boot from a FreeBSD image in the internal SD card slot. I have two rPis under test, I will call them Old Pi and New Pi. Both are Raspberry Pi Model 4 B 2GB. One is about a year old, the other is new (purchased a few days ago from one of the larger dedicated rPi supply houses). The FreeBSD image used is FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img downloaded a few days ago, file datestamped 09 April 2021, I will call it FreeBSD henceforth. The Raspberry Pi OS image used is 2021-03-04-raspios-buster-armhf-full.img. I will call it Raspberry Pi OS henceforth. I used the same SD card throughout, rewriting OS images as needed. New Pi will boot Raspberry Pi OS from an SD card in the built-in SD card slot. Old Pi will boot FreeBSD from an SD card in the built-in SD card slot. New Pi will not boot FreeBSD from an SD card in the built-in SD card slot (the exact same image, without rewriting, that Old Pi booted successfully) New Pi will boot FreeBSD from an SD card in an USB to SD card adapter (the same adapter I used to write the image in the first place). New Pi appears to have the same overall components as Old Pi but the RAM chip has an entirely different identifier and the SOC package has slightly different set of numbers/letters on it. Things I am confident of: * New Pi does not have a broken SD card slot, nor does it have other hardware problems preventing booting. * Old Pi has similarly fully functional hardware. Old Pi has the following identifying marks on the SOC package: BROADCOM 2711ZPKFSB06BOT TE1919 045-23 B3 W New Pi has the following identifying marks on the SOC package: BROADCOM 2711ZPKFSB06C0T TA2105 054-05 B3 W The boot messages on New Pi when failing to boot from SD card in SD slot (transcribed from a literal screenshot using my phone camera): ------< cut here 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: 0 switch to partitions #0, OK mmc0 is current device ** No partition table - mmc 0** Device 0: unknown device ethernet@7d580000 Waiting for PHY auto negotiation to complete.. ------< cut here The system then tries to network boot. Partial boot messages from New Pi when succeeding in booting from SD card in USB to SD adapter (transcribed from photographs, and some messages missed as the screen clears after the first set of messages): Part 1: ------< cut here Net: eth0: ethernet07d580000 PCIe BRCH: 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... Device NOT ready Request Sense returned 02 3A 00 3 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 1 ------< cut here Part 2: ------< cut here Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi Image base: 0x39cfc000 EFI version: 2.80 EFI Firmware: Das U-Boot (rev 8224.4096) Console: conconsole (0) Load Path: /efi\boot\bootaa64.efi Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0, 0x0,0x9,0x0,0x3)/UsbClass(Oxbda,0x306,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18f a8) Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0, 0x9,0x0,0x3)/UsbClass(Oxbda,0x306,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8) Setting currdev to disk0p1: Trying /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9, 0x0,0x3)/UsbClass(0xbda,0x306,0x0,0x0,6x0)/HD(2,0x01,0,0x197c7,0x5e6821) Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading boot/loader.conf Loading /boot/loader.conf.local / -----< cut here It may be that newer rPi hardware MMC slots are not recognised. Any suggestions welcome!
Comment 6 Nicolai Plum 2021-04-17 17:50:55 UTC
Additonal notes: The only things connected to the rPi were: HDMI cable to hdmi0 connector Power (3A USB-C PSU) SD card (in SD slot) or USB to SD adapter containing SD card.
Comment 7 Mark Millard 2021-04-17 18:00:32 UTC
(In reply to Nicolai Plum from comment #5) 2711ZPKFSB06BOT vs. 2711ZPKFSB06C0T is a major change in that there is a bunch of logic special to the B0T variant to deal with a DMA limitation of not being able to span the full address space. The C0T variant has the hardware fixed and is not limited to the lower 3 GiBytes. The RPi firmware likely configures the C)T parts differently in various ways. Likely someone with appropriate knowledge and interest is going to need to get their hands on examples of 2711ZPKFSB06C0T like parts with 4 GiByte and 8 GiByte RAM sizes.
Comment 8 Mark Millard 2021-04-17 18:15:24 UTC
(In reply to Nicolai Plum from comment #5) You may want to add an attachment with boot -v output up to the failure, possibly including early (pre-FreeBSD) serial console information if it can be recorded. The information likely would be of interest to anyone that wanted to work on supporting C0T parts. It may be that more modern RPi firmware is needed for C0T parts. (I'm not claiming sufficiency, just necessity may be involved.) A similar point might go for the u-boot involved. More than FreeBSD code may be involved in getting the C0T parts to be supported.
Comment 9 Mark Millard 2021-04-17 19:54:04 UTC
(In reply to Nicolai Plum from comment #5) Any chance that you could do the following via a RaspiOS or RaspiOS64 boot of the 2711ZPKFSB06C0T based RPi4B? # cat /proc/cpuinfo # cat /sys/firmware/devicetree/base/model See: https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
Comment 11 Nicolai Plum 2021-04-17 21:29:53 UTC
Created attachment 224200 [details] FreeBSD 13-RELEASE "boot -v" dmesg
Comment 12 Nicolai Plum 2021-04-17 21:33:03 UTC
The Linux (Raspberry Pi OS) CPU/model info and FreeBSD verbose boot messages are attached to this bug report. Having a USB keyboard attached also seemed to mess up the early boot phases (as mentioned in previous comments), causing what looked like USB initialisation timeouts at the boot stage with the Raspberry logo. There's a narrow time window to plug in the keyboard after this USB init is done but before U-Boot looks for devices so that the keyboard is visible to the FreeBSD boot loader and "boot -v" can be typed in.
Comment 13 Mark Millard 2021-04-17 22:44:19 UTC
(In reply to Nicolai Plum from comment #10) Interesting, that "Revision : b03114" shows up in: https://github.com/raspberrypi/documentation/commit/ff3b562d6044cb50545104a04567614feb09dd91#diff-8e1dd306076bc874881b22ac322895672ea78ebaa50a53283660f588fb8b6218 which shows that hardware/raspberrypi/revision-codes/README.md had a 2020-Nov-25 update that added both: + | b03114 | 4B | 1.4 | 2GB | Sony UK | and: + | c03130 | Pi 400 | 1.0 | 4GB | Sony UK | in the same commit. There is no other "b03114" in the table. (There are other *03114 codes already in the table at that point.) It looks like b03114 may identify a part code ending in C0T. But also of note is that even the modern version of that table only has that code for 2GB. (Other codes could also identify C0T but it may be that the codes are generally not that specific.)
Comment 14 Mark Millard 2021-04-17 23:41:11 UTC
(In reply to Nicolai Plum from comment #5) The text: QUOTE 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: 0 switch to partitions #0, OK mmc0 is current device ** No partition table - mmc 0** END QUOTE is from U-Boot, not from RPi firmware, nor from FreeBSD's loader or FreeBSD's kernel. In other words: U-Boot is having this initial problem. It looks necessary (but possibly not sufficient overall) to have a U-Boot that knows how to deal with the model of RPi4B. There is some possibility that the .dtb files from the RPi firmware contribute to what U-Boot is doing and might also need updating. (I would not expect this.) This suggests that testing using 2021.04 U-Boot instead of the 2020.10 U-Boot would be an appropriate substitution. Unfortunately, "pkg upgrade" on 13.0-RELEASE will not get the updated sysutils/u-boot-rpi-arm64 materials in /usr/local/share/u-boot/u-boot-rpi-arm64/ to copy to the msdos file system. The updated U-Boot must be created/copied another way.
Comment 15 Klaus Küchemann 2021-04-18 02:25:02 UTC
(In reply to Mark Millard from comment #14) <<...This suggests that testing using 2021.04 U-Boot instead of the 2020.10 U-Boot would be an appropriate substitution....>> --- if you need the latest (master): U-Boot 2021.04 (Apr 18 2021 - 01:33:43 +0000) : for download here : https://sourceforge.net/projects/fbsd-u-boot-2021-04-apr18-2021/files/u-boot.bin/download K.
Comment 16 Mark Millard 2021-04-18 03:30:28 UTC
(In reply to Klaus Küchemann from comment #15) So, which does that u-boot.bin correspond to?: /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin /usr/local/share/u-boot/u-boot-rpi3/u-boot.bin /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin None of the above 13.0-RELEASE is based on /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin --but back before the 2021.04 update: 2020.10 .
Comment 17 Klaus Küchemann 2021-04-18 03:38:04 UTC
(In reply to Mark Millard from comment #16) <<So, which does that u-boot.bin correspond to?...>> ... /u-boot-rpi4/u-boot.bin, since this report is an rpi4-issue. if you need another/further u-boot.bin-compilation, just let me know. K.
Comment 18 Mark Millard 2021-04-18 04:16:15 UTC
(In reply to Klaus Küchemann from comment #17) I do not have a failing context to test so I'd not be a user. I'd leave it to such a user if they want a closer match to the options used to make the 13.0-RELEASE image's U-Boot . Now, at least, they can look into the distinctions if they care to. (My normal use is probably more limited than most. I doubt that my normal use would demonstrate the build option differences as they would be seen on a RPi4B. But, as I remember, there are some distinctions for u-boot-rpi4/u-boot.bin vs. u-boot-rpi-arm64/u-boot.bin for an RPi4B.)
Comment 19 Mark Millard 2021-04-18 23:10:31 UTC
(In reply to Nicolai Plum from comment #5) https://lists.freebsd.org/pipermail/freebsd-arm/2021-April/023667.html is a report of a b03114 RPi4B (2GB) that boots fine with 13.0-RELEASE. The B0T vs. C0T part suffix is not known: already covered by heat sink. However, it does suggest 3 possibiliites: A) Differing EEPROM content versions B) Differing board/CPU revisions C) A combination of both (A) would definitely not lead to b03114 not changing. So I propose another test under RaspiOS or RaspiOS64: # vcgencmd bootloader_config and/or: # rpi-eeprom-config
Comment 20 Mark Millard 2021-04-18 23:15:17 UTC
(In reply to Mark Millard from comment #19) I incorrectly wrote "not" twice. Trying again: (A) would definitely not lead to b03114 changing.
Comment 21 Mark Millard 2021-04-19 13:42:41 UTC
(In reply to Mark Millard from comment #20) Looks like I asked for the wrong thing for what I was thinking. The b03114 that boots fine via 13.0-RELEASE's RPI build is reported on the lists as having the below (reported by Denis Ovsienko). I was actually thinking of the CURRENT: line, just below the BOOTLOADER: line, and the RELEASE: line, just after the LATEST: line. I'll note that I use the same BOOTLOADER version on the RPi4B's that I have access to, including the 8 GiByte ones (d03114): root@raspberrypi:~# rpi-eeprom-update BOOTLOADER: up-to-date CURRENT: Thu 3 Sep 12:11:43 UTC 2020 (1599135103) LATEST: Thu 3 Sep 12:11:43 UTC 2020 (1599135103) RELEASE: default (/lib/firmware/raspberrypi/bootloader/default) Use raspi-config to change the release. VL805_FW: Using bootloader EEPROM VL805: up-to-date CURRENT: 000138a1 LATEST: 000138a1 root@raspberrypi:~# lspci 00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10) 01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01) root@raspberrypi:~# lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@raspberrypi:~# grep -E '^[^#]' /boot/config.txt dtparam=i2c_arm=on dtparam=audio=on [pi4] dtoverlay=vc4-fkms-v3d max_framebuffers=2 [all] gpu_mem=16 root@raspberrypi:~# vcgencmd bootloader_config [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 DHCP_TIMEOUT=45000 DHCP_REQ_TIMEOUT=4000 TFTP_FILE_TIMEOUT=30000 ENABLE_SELF_UPDATE=1 DISABLE_HDMI=0 BOOT_ORDER=0xf41 root@raspberrypi:~# rpi-eeprom-config [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 DHCP_TIMEOUT=45000 DHCP_REQ_TIMEOUT=4000 TFTP_FILE_TIMEOUT=30000 ENABLE_SELF_UPDATE=1 DISABLE_HDMI=0 BOOT_ORDER=0xf41 I will note that I've had problems with "gpu_mem=16" attempts in the past and so use "gpu_mem=32" instead. I normally only use HDMI output for a console when it is in use at all. I use a serial console and ssh normally, X11 use is very rare for me.
Comment 22 Mark Millard 2021-04-19 17:48:00 UTC
(In reply to Mark Millard from comment #21) I'll note that there is a newly-promted EEPROM default/critical available as of today, but it is untested with the RPi-firmware/U-Boot/FreeBSD-loader/FreeBSD-kernel combination as far as I know: pieeprom-2021-03-18.bin Previously the most recent default/critical EEPROM promotion was of: pieeprom-2020-09-03.bin That one has been in fairly general use for some time. It is possible that the C0T parts may do better with one vs. the other, not necessarily matching what works well with B0T parts. For reference: https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md
Comment 23 Nicolai Plum 2021-04-19 19:14:33 UTC
Success! The updated u-boot.bin provided by Klaus Küchemann (comment #15) boots the C0T hardware without problems. This includes with a keyboard attached. Test conditions: Hardware: Raspberry Pi 4B, 2GB RAM, 128GB SD card in the internal SD card slot. Software: FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img with updated u-boot.bin as above. Method: I burned a fresh copy of FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img to the SD card (visible as da1 on my amd64 machine); mounted the MSDOS-format partition (/dev/da1s1); copied the updated u-boot.bin to that MSDOS filesystem; unmounted it; and moved the SD card to the rPi. So it would appear the fix for this is u-boot.bin, at least to get the system to boot. Thank you to both Mark Millard and Klaus Küchemann for your help. Would you like any more information from this system to help with further development, or would you like me to try any other changes? What's the process for getting u-boot.bin updated in the release images? (I'm new to this - this is the first deficiency I have found in FreeBSD that affected me in ~15 years of using it).
Comment 24 Mark Millard 2021-04-19 20:19:29 UTC
(In reply to Nicolai Plum from comment #23) I'm not sure that there is an update processes that would provide a already-fixed image for 13.0-RELEASE for the RPI image (until 13.1-RELEASE). This is especially true because the part of it being updated is not build from materials in FreeBSD's src.git . It is likely that once the quarterly ports builds start to have the 2021.04 vintage of sysutils/u-boot-rpi-amd64 content that the future stable/13 snapshots at: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ (once created) will pick up the u-boot update and will work. Similar points go for main  snapshots: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/ but for "latest" instead of "quarterly".
Comment 25 Mark Millard 2021-04-19 20:22:09 UTC
(In reply to Mark Millard from comment #22) I've updated the RPi4B 8 GiByte EEPROM to the new default (a.k.a. critical) and had no problems booting via a microsd card or a USB3 SSD. But that tests B0T instead of C0T parts.
Comment 26 Mark Millard 2021-04-19 20:29:46 UTC
(In reply to Mark Millard from comment #24) I probably should have warned that the "latest" for 13.0 has not been updated since back in Jan. As stands, for 13.0 quarterly is the most recent available. It is likely possible to request that quarterly update to the more recent 2021.04 based u-boot vintages. That would not fix 13.0-RELEASE images but it would make getting the needed u-boot.bin easy in a standard way for then copying in place.
Comment 27 Klaus Küchemann 2021-04-19 20:48:07 UTC
(In reply to Nicolai Plum from comment #23) I'm glad that it works. If you want, you can close this pr with: fixed by comment 15 . Regards K.
Comment 28 Mark Millard 2021-04-19 21:05:53 UTC
(In reply to Klaus Küchemann from comment #27) I do not think that closing the defect as fixed is appropriate until FreeBSD does not require the workaround. Otherwise the required change can get lost/forgotten easier. Comment #15 does provide a workaround. Another, for those using the Lastest repo via pkg on some machine, is to install the sysutils/u-boot-rpi-arm64 package (or sysutils/u-boot-rpi4 package) and copy the /usr/local/share/u-boot/u-boot-rpi-arm64/u-boot.bin ( or /usr/local/share/u-boot/u-boot-rpi4/u-boot.bin ) to replace the older u-boot.bin on the msdos file system on the rpi4 boot media. Similarly one could build and install the sysutils/u-boot-rpi-arm64 or sysutils/u-boot-rpi4 port and then copy the file over.
Comment 29 Klaus Küchemann 2021-04-19 21:29:22 UTC
(In reply to Mark Millard from comment #28) <<.. workaround...>> it's not a workaround, upgrading u-boot.bin seems instead a strictly requirement to boot the machine from uSD, as far as I understand comment 23 . upgrading( or even downgrading) parts of the msdos-partiton by hand is a standard requirement since months ( or perhaps years:-) for the RPI4 here. but who knows that better than e.g you ?! ... Regards K.
Comment 30 Mark Millard 2021-04-19 22:11:54 UTC
(In reply to Klaus Küchemann from comment #29) Declaring this fixed means that FreeBSD should not be considered for change for the issue. For example, no reason to have quarterly update the u-boot vintage that it is based on (until next quarter). That is all that I'm referring to. What you have done is handy but does not update the quarterly package builds to have the new vintage of the u-boot ports. Those that decide if such updates are made may well give this a "no plan to fix" status, just waiting for the next quarter. At that point closing the defect would be appropriate in my view, not before.
Comment 31 Klaus Küchemann 2021-04-20 00:39:33 UTC
(In reply to Mark Millard from comment #30) <<..Those that decide..>> You and me decide what has to be done on the msdos-partition, no one else. ;-) Ha Ha... `ve added Mike to cc so he can close this pr or leave it open. Regards K.
Comment 32 Wen Heping 2021-04-23 14:30:27 UTC
My RPI4b+ with 4G memory still failed boot with the updated u-boot.bin provided by Klaus Küchemann (comment #15) :( wen
Comment 33 Klaus Küchemann 2021-04-23 15:56:29 UTC
(In reply to Wen Heping from comment #32) do you have dmesg/console-output/OS-version/firmware-version(if not current default release- image) ?
Comment 34 Mark Millard 2021-04-23 16:35:03 UTC
(In reply to Wen Heping from comment #32) What does it say on top of the processor? Other example contexts reported have reported: BROADCOM 2711ZPKFSB06BOT TE1919 045-23 B3 W vs. BROADCOM 2711ZPKFSB06C0T TA2105 054-05 B3 W Is your microsd based on FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz but with just u-boot-bin updated on the msdos file system? Some other combination of materials? If some other: what other combination? Do you have a serial console set up? Can you report captured output from it? Does it show the: QUOTE 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: 0 switch to partitions #0, OK mmc0 is current device ** No partition table - mmc 0** END QUOTE that was reported in comment #5 ?
Comment 35 Wen Heping 2021-04-23 22:46:42 UTC
(In reply to Mark Millard from comment #34) My microsd is based on FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz, and I updated u-boot-bin with the file suggested in Comment15. I did not set up serial console now, sorry have no more message. Thank your reply. wen
Comment 36 Mark Millard 2021-04-23 23:09:51 UTC
(In reply to Wen Heping from comment #35) What of the text printed on the top of the processor? Just in case: in your note you wrote "u-boot-bin" but the file name should be "u-boot.bin". If in copying things around you made a similar typo, it is possible that the old u-boot.bin was not updated/replaced for your test. Without a serial console and copies of output recorded from it, it is going to be difficult for anyone to help you. On screen the "first error notice" may well have scrolled off screen by the time things stop. Still, you could try transcribing material from when things stop --or adding an attachment that is a picture of that screen. It might provide something of some use. At this point it is not even clear if your problem is significantly related to what has been learned for this bugzilla so far --vs. if it would be better submitted as a separate problem.
Comment 37 Klaus Küchemann 2021-04-23 23:47:53 UTC
(In reply to Wen Heping from comment #35) as Mark indicated in comment #36, we are quite sure that your problem is probably not related to u-boot-issues. I have booted your setup on the same machine as yours(older model) 2 minutes ago....Is yours a newer model? the u-boot.bin from comment #15 is even working on the new RPI 400, as I`ve read somewhere . a quick sroll through u-boot`s git also has no news the last days related to the RPI4 so the (comment #15 ) u-boot.bin really should work. K.
Comment 38 Wen Heping 2021-04-24 07:35:07 UTC
(In reply to Mark Millard from comment #36) On top of processor say: 2711ZPKFSB06BOT TE1917 183-04 B3 W I write FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz to my microSD card, and I replace u-boot.bin. The same card boot my RPI3b+ well. wen
Comment 39 Mark Millard 2021-04-24 08:40:07 UTC
(In reply to Wen Heping from comment #38) Thanks for the information. We now know that the newer processor variant is not involved in your issue --which is important to know. Thanks also for reporting that it works in your RPi3B+ . That gives some useful context. One question would be: did the microsd card boot the RPi3+ before the u-boot was replaced as well? Right now we have no information indicating a u-boot specific problem. If the old u-boot also worked in the RPi3B+ then it would seem likely that involving the new u-boot just complicates things and the pure FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img transfer would likely be a better basis for investigation. Unfortunately, between the two items that you report, it means that information from the display or from serial console output appears to be essential to anyone getting a clue about what it going on. It is the first unexpected messages reported that are likely the important ones. So far it looks like your problem is likely not the one associated with comment #5 (which the original description seems to match for the lesser information it provides): the "** No partition table - mmc 0 **" related messages from u-boot.
Comment 40 Mark Millard 2021-04-24 09:07:16 UTC
(In reply to Wen Heping from comment #38) If you could boot RasPiOS or RasPiOS64 on the RPi4B you could try the following sorts of commands and report the outputs (I show example outputs from earlier comments): # rpi-eeprom-update BOOTLOADER: up-to-date CURRENT: Thu 3 Sep 12:11:43 UTC 2020 (1599135103) LATEST: Thu 3 Sep 12:11:43 UTC 2020 (1599135103) RELEASE: default (/lib/firmware/raspberrypi/bootloader/default) Use raspi-config to change the release. VL805_FW: Using bootloader EEPROM VL805: up-to-date CURRENT: 000138a1 LATEST: 000138a1 I will note that in recent days another version of the EEPROM has been promoted to the default/critical status so "LATEST" may be more recent than shown above, even if you are using "RELEASE: default". It woudl depend on the detailed vintage of your RasPiOS* install. # vcgencmd bootloader_config [all] BOOT_UART=0 WAKE_ON_GPIO=1 POWER_OFF_ON_HALT=0 DHCP_TIMEOUT=45000 DHCP_REQ_TIMEOUT=4000 TFTP_FILE_TIMEOUT=30000 ENABLE_SELF_UPDATE=1 DISABLE_HDMI=0 BOOT_ORDER=0xf41 # lspci 00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10) 01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01) # lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Mostly this allows for some cross-checking if some of that might be unexpectedly different in your context.
Comment 41 Klaus Küchemann 2021-04-24 16:39:33 UTC
(In reply to Wen Heping from comment #38) you see the rainbow on your hdmi-display, right ? if so, please plug the hdmi-cable in the first slot, next to the PSU-plug. by the way , that's not a bug and if your model is not a newer one: it will boot FreeBSD-13.0-RELEASE-arm64-aarch64-RPI.img.xz from https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/13.0/ out of the box. Mark will tell you how you can get a better resolution on hdmi while booting ;-) K.
Comment 42 Hōkan 2021-04-24 17:04:39 UTC
I'll note that I couldn't boot when I had more than 1 device (keyboard and/or disk) plugged in to a USB3 port. Once the boot started I could plug in more devices. I have a powered USB3 hub but I've tested without it and didn't see any difference. Updating u-boot from comment #15 resolved the issue for me. I'm booting from a pair of ZFS-mirrored usb drives.
Comment 43 Mark Millard 2021-04-24 18:13:07 UTC
(In reply to Klaus Küchemann from comment #41) (Klaus: Good suggestion to check on the HDMI cable connection.) The config.txt has a line: hdmi_safe=1 that restricts the resolution but allows more contexts to display something (instead of ending up with a blind context). hdmi_safe can be disabled one of 3 ways by changing the line: A) Use: hdmi_safe=0 B) Use: #hdmi_safe=1 C) Delete the line. Booting afterward to make it use the adjusted line is then required.
Comment 44 Wen Heping 2021-04-25 23:21:42 UTC
(In reply to Klaus Küchemann from comment #41) You are right, now I boot my RPI4 after I put hdmi-cable in the first slot. Raspian boot both: hdmi-cable in the first slot and second slot. Thank you ! wen
Comment 45 Wen Heping 2021-04-25 23:22:25 UTC
(In reply to Mark Millard from comment #43) Thank you ! wen
Comment 46 Mark Millard 2021-04-25 23:52:59 UTC
(In reply to Leo Schneider from comment #0) Leo S.: Can you report on if the manual u-boot update to a 2021.04 based version fixes the problem for you as well? Other supporting details, like what the top of your processor indicates for: 2711ZPKFSB06BOT vs. 2711ZPKFSB06C0T and what RAM size the RPi4 has could be of use for confirming or denying the context is as expected from what comment #5 has lead to.
Comment 47 Mark Millard 2021-04-30 07:26:27 UTC
In looking around I ran into some notes for a U-Boot patch for the RPi4's with newer parts. It may hint at why a 021-04 U-Boot is needed and may also hint at variations that the FreeBSD kernel possibly could deal with. QUOTE . . . From: Nicolas Saenz Julienne <email@example.com> Date: Thu, 19 Nov 2020 18:48:17 +0100 Subject: [PATCH 11/16] pci: pcie-brcmstb: Fix inbound window configurations So far we've assumed a fixed configuration for inbound windows as we had a single user for this controller. But the controller's DMA constraints were improved starting with BCM2711's B1 revision of the SoC, notably available in CM4 and Pi400. They allow for wider inbound windows. We can now cover the whole address space, whereas before we where limited to the lower 3GB. This information is passed to us through DT's 'dma-ranges' property and it's specially important for us to honor it them since some interactions with the board's co-processor assume we're doing so (specifically the XHCI firmware load operation, which is handled by the co-processor after u-boot has correctly configured the PCIe controller). . . . END QUOTE I'll note an implication of the dma-ranges for RPi4's being possibly dynamically adjusted before being handed to the kernel --instead of just hardcoded in the bcm2711-rpi-4-b.dtb file provided by the RPi firmware. (There are bcm2711-rpi-400.dtb and bcm2711-rpi-cm4.dtb files as well.)
Comment 48 Roger Leigh 2021-06-06 14:52:20 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256441 may also be related to this U-boot issue. I created a separate ticket since I thought it was a bit different to this one, but maybe it has the same underlying cause.