Raspberry Pi 4 not booting FreeBSD-12.1 (no HDMI signal or other activity)

oshyshko

oshyshko

UPDATE 2019-12-16: rpi4 is not supported yet, the behavior described below is not a bug or some kind of anomaly.

I am trying to run FreeBSD on Raspberry Pi 4, 4GB version (rpi4).
I get no HDMI output or any other life signs during boot.

What could be wrong?
How to investigate?

Here are my steps:
1. Get the image, unzip, burn to SD card:
Code: 
$ wget "https://download.freebsd.org/ftp/releases/arm64/aarch64/ISO-IMAGES/12.1/FreeBSD-12.1-RELEASE-arm64-aarch64-RPI3.img.xz"
$ unxz FreeBSD-12.1-RELEASE-arm64-aarch64-RPI3.img.xz
$ sudo dd if=./FreeBSD-12.1-RELEASE-arm64-aarch64-RPI3.img of=/dev/rdisk2 bs=100m
2. Unmount, eject the SD card and plug into rpi4
3. Connect rpi4 to HDMI monitor (via HDMI port that next to USB-C power port)
4. Connect rpi4 via USB-C to CanaKit 3.5A power
5. Observe:
- within first 1-2 seconds: red light is on, green light flashes rapidly
- after that, red light is on, green light is off, no other activity
- no HDMI signal
6. Plug ethernet cable, observe:
- yellow light on on rpi4's ethernet port
- no IP taken via DHCP

NOTES:
- Using images from 12.0 and 11.X releases and stables didn't make a change.
- Using dd ... of=/dev/disk2 didn't make a change.
- Using other, completely new SD cards 16GB and 32GB didn't make a change.
- Using an SD card with the latest Raspbian boots on this rpi4 just fine.
- I got this rpi4 and a power adapter from here
 
Last edited:
The problem of supporting ARM hardware is the same of the whole embedded market: no one follow any standards and do whatever the wreck they want; everything is secret and they provide little to no documentation.

The only reason Linux get support for these hardware is because the implementation (aka magic numbers) is given to them. And as you can expect those are usually pretty crap implementation but which somehow work.
 
acheron said:
The pcie documentation is missing for the rpi4, it means no pcie/eth etc.
Click to expand...
I made some progress with pci-e. (Enabled the root complex, got the bridge up, probed the first bus, detected the peripheral, read the config space on the peripheral, but not figured out how to route interrupts or allocate the BARs into the host memory space.)

It’s not impossible, but it requires someone with some time on their hands.
 
RobCrowston said:
I made some progress with pci-e. (Enabled the root complex, got the bridge up, probed the first bus, detected the peripheral, read the config space on the peripheral, but not figured out how to route interrupts or allocate the BARs into the host memory space.)

It’s not impossible, but it requires someone with some time on their hands.
Click to expand...
RobCrowston said:
I made some progress with pci-e. (Enabled the root complex, got the bridge up, probed the first bus, detected the peripheral, read the config space on the peripheral, but not figured out how to route interrupts or allocate the BARs into the host memory space.)

It’s not impossible, but it requires someone with some time on their hands.
Click to expand...

I might have some time on my hands. If you could point me in the right direction, perhaps with some documentation/steps I need to follow, I could take a crack at it.
 
rigoletto@ said:
The problem of supporting ARM hardware is the same of the whole embedded market: no one follow any standards and do whatever the wreck they want; everything is secret and they provide little to no documentation.

The only reason Linux get support for these hardware is because the implementation (aka magic numbers) is given to them. And as you can expect those are usually pretty crap implementation but which somehow work.
Click to expand...

Your words summarizes the situation perfectly.
 
Memory access to the PCI-e peripheral is now working correctly. The xhci driver sometimes attaches successfully, in the sense it enumerates the hub and can detect if a device is plugged in, but not always, probably some race or timing problem. However, nothing works yet because interrupts are not being routed correctly. That's the next bit.

Someone else on the mailing list ported the netbsd driver for ethernet and I can confirm it works for me. I think it is now in CURRENT.
 
The PCI-e driver was accepted. Waiting to be committed to current. Alternatively you can use the UEFI bootloader instead of u-boot, which already works. (See the arm mailing list for details, I haven't looked at this approach myself.)

I also have a fix for loading the USB controller firmware on the newest hardware revisions of the Pi4 out for review. However, the older (pre-May 2020) hardware will work without it.

Also recently fixed is reboot, hardware random number generation, and some tweaks to ethernet to cope with upstream changes to the dtb files.

I will take a look some weekend at why we are waiting for so long for ethernet to come up. I have noticed it myself but seeing it in the Youtube video there reminds me it is a very long time.
 
You must log in or register to reply here.
Back
Top