Raspberry pi 5 status

Fred Finster Raspberry Pi 500 keyboard model running FreeBSD Arm64 15.0 Raspberry Pi . COM forum post with details that worked for me. Suggestions on where to post a 3GB single binary image file to write into a microSD card to boot the RPI 5 or RPI 500 keyboard. Also, how easy it is with Raspberry Pi 5 or Raspberry Pi 500 model to start with a bare blank microSD or bare blank USB flash disk drive stick and download, over the hard wired ethernet connector to access the internet, and retrieve a multigigabyte single file to dram memory and write into a bare blank microSD card or USB flash disk drive stick, that image. Finish the write and then reboot into the new operating system. What resources can the FreeBSD Foundation or the https://freebsd.org/where network infrastructure provide the same feature as RaspberryPi.com. Take a raspberry pi hardware, like the RPI 500 keyboard model, starting with a blank microSD, download the latest version of the Raspberry Pi Linux Debian Operating System and write into that same blank microSD card. Can a single FreeBSD image for the RPI 500, also be loaded from a similar location like the https://freebsd.org/where or https://download.freebsd.org/releases/arm64/aarch64/ISO-IMAGES/15.0/

I have an image to share for the RPI 5 or RPI 500 model hardware. Where shall I place it, for others to access? That is the question I am asking.
How to make it easy for a new Raspberry Pi 5 or 5+, 500 or 500+ USER to download a single file using the RPI hardware and write it to the internal microSD card or USB Flash disk drive stick? I promote seeing more FreeBSD Arm64 and GhostBSD-Arm64 Users. http://GhostBSD-arm64.blogspot.com
I will get NGINX and Poudriere setup again on this RPI 500 model and use the http:ghostbsd-arm64.hopto.org URL link in the future to share large gigabyte files.
 
a short status: I installed FreeBSD 14.3-release on a SD card and booted it. The EFI loader, the FreeBSD loader and the FreeBSD console all works. Nice.
Network is via a usb-to-ethernet dongle, as the internal wired and wireless on the Pi5 doesn't work yet.
Also, I thought the fan would spin all the time, but it doesn't - it just spins a few rotations on boot / powercycle and then stops.
I did a freebsd-update, the machine now runs
Code:
root@devpi5sd:~ # freebsd-version -ku
14.3-RELEASE-p5
14.3-RELEASE-p6
root@devpi5sd:~ # uname -a
FreeBSD devpi5sd 14.3-RELEASE-p5 FreeBSD 14.3-RELEASE-p5 GENERIC arm64
I connected the NVME Base Duo, both it and the two SSDs on it are detected. From dmesg
Code:
root@devpi5sd:~ # dmesg | egrep nvme\|nda
FreeBSD is a registered trademark of The FreeBSD Foundation.
nvme0: <Generic NVMe Device> mem 0xc0100000-0xc0103fff at device 0.0 on pci3
nvme0: unable to allocate MSI-X
nvme0: unable to allocate MSI
nvme1: <Generic NVMe Device> mem 0xc0000000-0xc0003fff at device 0.0 on pci4
nvme1: unable to allocate MSI-X
nvme1: unable to allocate MSI
nvme0: Allocated 64MB host memory buffer
nvme1: Allocated 64MB host memory buffer
nda0 at nvme0 bus 0 scbus0 target 0 lun 1
nda0: <Samsung SSD 990 EVO Plus 4TB 2B2QKXG7 S7U9NU0YA21568Y>
nda0: Serial Number S7U9NU0YA21568Y
nda0: nvme version 2.0
nda0: 3815447MB (7814037168 512 byte sectors)
nda1 at nvme1 bus 0 scbus1 target 0 lun 1
nda1: <Samsung SSD 990 EVO Plus 4TB 2B2QKXG7 S7U9NU0YA21527F>
nda1: Serial Number S7U9NU0YA21527F
nda1: nvme version 2.0
nda1: 3815447MB (7814037168 512 byte sectors)
I haven't tried installing on the SSDs (or booting from) yet.
 
The fan behaviour depends on the EEPROM version I think. Older versions would run the fan at full speed. Newer ones just spin it briefly during boot and then stop it.

I find no fan a bit of a concern, particularly as the SD card (quite heat sensitive) sits right underneath the CPU. I know the CPU will throttle, but I would much prefer to have the fan working correctly.
 
I upgraded to 14.4:
Code:
root@devpi5:~ # freebsd-version -ku
14.4-RELEASE-p1
14.4-RELEASE-p1
root@devpi5:~ # uname -a
FreeBSD devpi5 14.4-RELEASE-p1 FreeBSD 14.4-RELEASE-p1 GENERIC arm64
no big changes.
- still no fan (other than a brief spin at boot)
- still no support for the internal wired network interface
- still no support for the internal wireless network interface
 
Ok, I wrote a FreeBSD 15.0-release image to a usb stick, which I booted on the Raspberry Pi 5. No changes as far as I could see (in other words, no fan control, no on board networking)
So I upgraded to FreeBSD 15.0-release-p5 via freebsd-update.
Code:
root@generic:~ # freebsd-version -ku
15.0-RELEASE-p5
15.0-RELEASE-p5
root@generic:~ # uname -a
FreeBSD generic 15.0-RELEASE-p5 FreeBSD 15.0-RELEASE-p5 GENERIC arm64
so the latest upgrade of FreeBSD 15 on the Raspberry Pi5 is the same as 14:
- still no fan (other than a brief spin at boot)
- still no support for the internal wired network interface
- still no support for the internal wireless network interface

The dmesg can be found here, if anybody is interested.
 
Still no new board after RPI3 with FreeBSD 13.x and scfb graphics. There really should be an ARM board as some sort of community preference. I would buy it and contribute to a FreeBSD environment that covers most of the devices.
 
Ok, I wrote a FreeBSD 15.0-release image to a usb stick, which I booted on the Raspberry Pi 5. No changes as far as I could see (in other words, no fan control, no on board networking)
So I upgraded to FreeBSD 15.0-release-p5 via freebsd-update.
...
The dmesg can be found here, if anybody is interested.
Is there pciconf for this platform? If yes, could you add 'pciconf -lv' output in addition?
And could you add 'devinfo -r' output as well?
This should give us better understanding of the platform...
 
- still no fan (other than a brief spin at boot)
For the fan you might need to issue some commands for it to work.

See this Wiki for details:

Fan Control on RockPro64​


So start with looking at ls /dev/pwm and see if you already have pwm controllers to use.
There may be more than one PWM node so you may need to experiment with this command:
pwm -E -f pwmc1.0 -d 50%

Most ARM64 board have PWM nodes showing. To add additional PWM nodes you might need to use an DTOverlay to change pin muxing.
Depends on platform how many PWM pins are available..
 
Most arm64 boards might, but the Raspberry Pi / Broadcom is different
Code:
root@devpi5:~ # ls -l /dev/pwm*
ls: /dev/pwm*: No such file or directory
and no "temperature" under hw either
Code:
root@devpi5:~ # sysctl hw | grep temp
hw.usb.template: -1
 
Hmm, there exists cases like the Pironman 5, which have a tower cooler and external fans that can be controlled with GPIO pins (see documentation). That would not change the problem with the fan on the cooler (still controlled by the (for FreeBSD unsupported) rp1), but perhaps the external fans would be able to keep the Pi 5 cool enough?
 
I'm prodding claude to write drivers for the thermal sensor and fan. It's almost working.

I'm using USB ethernet. After I get the fan working I will try to get the onboard NIC driver working.

After the claude prototype is good enough, I'll refactor and clean up the code then put together a patch/PR and others can test it.

Currently I'm building a BROADCOM kernel and then loading my KLDs. This weekend I should receive a UART to USB adapter so that I can make claude drive remote instead of on-host with less manual help from me supervising all the kernel panics.
 
I'm prodding claude to write drivers for the thermal sensor and fan. It's almost working.

I'm using USB ethernet. After I get the fan working I will try to get the onboard NIC driver working.

After the claude prototype is good enough, I'll refactor and clean up the code then put together a patch/PR and others can test it.

Currently I'm building a BROADCOM kernel and then loading my KLDs. This weekend I should receive a UART to USB adapter so that I can make claude drive remote instead of on-host with less manual help from me supervising all the kernel panics.


Everything in this repo was written by claude code, with some heavy handed supervision from me, so don't believe any of the documentation (trust but verify), but the makefile should build the KLD targets for the bcm2712 module providing access to the thermal sensor and the rpi5 module which at this point only provides the fan controller modeled after the behavior in the linux driver.

As I write this, the thermals and fan control work on the hardware on my desk. It has only been tested with a BROADCOM kernel config. For anyone who knows what to do with this stuff and doesn't require any handholding, I would appreciate any testing/feedback. When I get some safety/efficacy consensus/review I will release an alpha. Please test it if you can.

I've moved on to prod claude to write the onboard NIC driver.

FWIW: I'm burning session token limits in half time. Claude is amazing at reading code and meh at reading documentation and OK at putting it together, but it would have taken me a week or two to figure out what claude can decipher in 10-30 minutes. The spell is broken occasionally when it misunderstands something, so expertise is critical to keep it from going down a spiral of despair. It helps to have a pedantic attitude and ask it to explain how it got the wrong idea. At the end, I hope to report on the carbon footprint, and I suspect the economics are dubious for software with a small user base. It makes me feel better that I'm donating this to the community, but not 100%. What I do think is helpful, without qualification, 100% agreement with jkh, is asking an LLM to explain to you how something is implemented in a codebase or what certain things in the codebase are supposed to do, and I encourage anyone who is curious to download the source and ask an LLM to walk you through parts of it.
 
Back
Top