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
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
(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 mmc@7e300000.blk... Disk mmc@7e300000.blk not ready Scanning disk emmc2@7e340000.blk... 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.
Do you have a mouse connected? I've seen the same thing with my device when a mouse is connected.
(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.
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!
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.
(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.
(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.
(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
Created attachment 224199 [details] rPi OS CPU info
Created attachment 224200 [details] FreeBSD 13-RELEASE "boot -v" dmesg
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.
(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.)
(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.
(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.
(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 .
(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.
(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.)
(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
(In reply to Mark Millard from comment #19) I incorrectly wrote "not" twice. Trying again: (A) would definitely not lead to b03114 changing.
(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.
(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
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).
(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 [14] snapshots: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/14.0/ but for "latest" instead of "quarterly".
(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.
(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.
(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.
(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.
(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.
(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.
(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.
My RPI4b+ with 4G memory still failed boot with the updated u-boot.bin provided by Klaus Küchemann (comment #15) :( wen
(In reply to Wen Heping from comment #32) do you have dmesg/console-output/OS-version/firmware-version(if not current default release- image) ?
(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 ?
(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
(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.
(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.
(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
(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.
(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.
(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.
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.
(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.
(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
(In reply to Mark Millard from comment #43) Thank you ! wen
(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.
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 <nsaenzjulienne@suse.de> 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.)
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.
(In reply to Roger Leigh from comment #48) Nothing in this bugzilla has the error message that contains: Failure to add disk device usb_mass_storage.lun0 which yours does. It is a separate issue.
I tried to install latest FreeBSD 14 snapshot FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20211028-4827bf76bce-250301.img.xz and dd-ed this image to the microSD card for Raspberry Pi 3b+. The result is still the same - no MMC device: U-Boot> mmc info MMC Device 0 not found no mmc device at slot 0 U-Boot> mmc part MMC Device 0 not found no mmc device at slot 0 U-Boot> mmc list mmc@7e300000: 2 U-Boot> version U-Boot 2021.7 (Oct 28 2021 - 05:44:44 +0000) aarch64-none-elf-gcc (FreeBSD Ports Collection for aarch64noneelf) 8.4.0 GNU ld (GNU Binutils) 2.37
A full log from the serial console: U-Boot 2021.07 (Oct 28 2021 - 05:44:44 +0000) DRAM: 948 MiB RPI 3 Model B+ (0xa020d3) MMC: mmc@7e300000: 2 Loading Environment from FAT... In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e980000: usb dr_mode not found USB DWC2 scanning bus usb@7e980000 for devices... 4 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 MMC Device 0 not found no mmc device at slot 0 MMC Device 1 not found no mmc device at slot 1 Device 0: unknown device lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: pxeuuid missing environment variable: bootfile Retrieving file: pxelinux.cfg/01-b8-27-eb-fe-70-8a lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/00000000 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/0000000 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/000000 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/00000 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/0000 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/000 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/00 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/0 lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-bcm283x-rpi lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm-bcm283x lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/default-arm lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed missing environment variable: bootfile Retrieving file: pxelinux.cfg/default lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed Config file not found lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed lan78xx_eth Waiting for PHY auto negotiation to complete......... TIMEOUT ! phy_startup failed U-Boot> mmc info MMC Device 0 not found no mmc device at slot 0 U-Boot> mmc part MMC Device 0 not found no mmc device at slot 0 U-Boot> mmc list mmc@7e300000: 2 U-Boot> version U-Boot 2021.07 (Oct 28 2021 - 05:44:44 +0000) aarch64-none-elf-gcc (FreeBSD Ports Collection for aarch64noneelf) 8.4.0 GNU ld (GNU Binutils) 2.37 U-Boot> bdinfo boot_params = 0x0000000000000100 DRAM bank = 0x0000000000000000 -> start = 0x0000000000000000 -> size = 0x000000003b400000 flashstart = 0x0000000000000000 flashsize = 0x0000000000000000 flashoffset = 0x0000000000000000 baudrate = 115200 bps relocaddr = 0x000000003b35a000 reloc off = 0x000000003b2da000 Build = 64-bit current eth = lan78xx_eth ethaddr = b8:27:eb:fe:70:8a IP addr = <NULL> fdt_blob = 0x000000003af4e750 new_fdt = 0x000000003af4e750 fdt_size = 0x0000000000007640 Video = fb active FB base = 0x000000003eaf0000 FB size = 656x416x32 lmb_dump_all: memory.cnt = 0x1 memory.reg[0x0].base = 0x0 .size = 0x3b400000 reserved.cnt = 0x2 reserved.reg[0x0].base = 0x0 .size = 0x1000 reserved.reg[0x1].base = 0x3af4d370 .size = 0x4b2c90 arch_number = 0x0000000000000000 TLB addr = 0x000000003b3f0000 irq_sp = 0x000000003af4e740 sp start = 0x000000003af4e740 Early malloc usage: 598 / 2000 U-Boot>
(In reply to Anton Kochkov from comment #50) yes, there seems to be a mismatch of file-versions in the release again(I didn't research the issue for now)... for a quick fix you can override this one(u-boot.bin 2020.10) to your msdods-partition: https://sourceforge.net/projects/freebsd-bug-id-255080/files/u-boot.bin/download
(In reply to Klaus Küchemann from comment #15) Are you able to share the configuration you use for building this?