Pi in the sky V (Raspberry Pi 5 support)

The thing is, there likely will be a PCIe break out board for the normal pi5 (which might or might not allow for a dual port 2.65 Gbps ethernet NIC), no need to wait for the CM5... now price wise you might be correct... about not being able to compete at all, I am not so sure both the pi5 and the R6C seem to use 4 Arm A76 cores clocked at similar frequencies... you would need to load these fully before the rockchips additional Arm A55 "little" cores might come into play... Now, the R6C seems to be a pretty complete package out of the box for a wired router, while the pi5 will certainly need some fiddling...

At least in terms of form factor, the breakout board + 2 NIC (no matter it's 2.5G or not) won't be as small as R6S/R6C, also R6S with the original metal casing the passive cooling is doing great.

FYI the Raspberry Pi 5 is already getting shipped through a ‘Priority Boarding’ code from a MagPi or HackSpace magazine subscription. I already got mine and I'm eager to help getting OpenWrt to run on it.

1 Like

I have the rpi 5 running OpenWrt, the wifi is not working yet

Crypto performance has improved a lot;

root@OpenWrt:/# ubus call system board
{
        "kernel": "6.1.61",
        "hostname": "OpenWrt",
        "system": "ARMv8 Processor rev 1",
        "model": "Raspberry Pi 5 Model B Rev 1.0",
        "board_name": "raspberrypi,5-model-b",
        "rootfs_type": "ext4",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r0-0686b50",
                "target": "bcm27xx/bcm2712",
                "description": "OpenWrt SNAPSHOT r0-0686b50"
        }
}
root@OpenWrt:/# openssl speed aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 149750480 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 69715299 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 20963568 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 5487960 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 8192 size blocks: 699204 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 350398 aes-128-cbc's in 3.00s
version: 3.0.12
built on: Sat Nov  4 19:28:49 2023 UTC
options: bn(64,64)
compiler: aarch64-openwrt-linux-musl-gcc -fPIC -pthread -Wa,--noexecstack -Wall -O3 -Os -pipe -mcpu=cortex-a76 -fno-caller-saves -fno-plt -fhonour-copts -ffunction-sections -fdata-sections -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -DPIC -fPIC -Os -pipe -mcpu=cortex-a76 -fno-caller-saves -fno-plt -fhonour-copts -ffunction-sections -fdata-sections -Wformat -Werror=format-security -fstack-protector -fPIC -fuse-ld=bfd -znow -zrelro -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -D_FORTIFY_SOURCE=1 -DPIC
CPUINFO: OPENSSL_armcap=0x3d
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc     798669.23k  1487259.71k  1788891.14k  1879488.64k  1909293.06k  1913640.28k
7 Likes

Good job, are you planning to prepare a PR for the official project?

1 Like

Hello,

I don't know why, but I couldn't boot the Raspberry Pi 5 4GB rev 1.0 model with either the ext4-factory image or the squashfs-factory image.

If there's something I can test, I'm ready to help. @mj82

Best regards,
ulpian

it's probably going to be crap anyway, so ....

1 Like

I tried your build, my 2.5G USB To Ethernet adapter was recognized, everything work good.

3 Likes

What 2.5 usb adapater did you use? Thanks

isn't Realtek the only one offering them ?

The adapter is RTL8156b, bought from amazon. https://www.amazon.com/dp/B09V2J992N

1 Like

Hello,
I don't know why, but I couldn't boot the Raspberry Pi 5 4GB rev 1.0 model with either the ext4-factory image or the squashfs-factory image.
If there's something I can test, I'm ready to help. @mj82
Best regards,
ulpian

Update: Today, it was determined that my Raspberry Pi 5 is faulty. It has been identified that the power management controller (PMIC) chip is short-circuited. A replacement will be provided free of charge.

So it's purely a hardware problem. Sorry for the confusion.

ulpian

works, thanks you

For anyone looking to purchase a Raspberry Pi 5 in the US, 4gb it is available in low quantities at Microcenter, in-store only, check your local store: https://www.microcenter.com/product/673712/raspberry-pi-5-4gb

1 Like

Thank you so much for this~

openwrt does appear capable on the pi 5~ but

I'm unable to setup my pi 5 as the packages dont properly install (unsure if its only me atm)

I was able to get the wifi to work as of the update from yesterday~managed to connect to my phones internet but. as my.. rare case... the map package is the only way I'm capable of having any proper internet access so I'm unable to fully utilize with the current build~ as its unable to get kmod-nat46 and other related dependencies of the map package

The fan also appears to stop after the initial boot into openwrt Could it be due to this?

However the fan appears to be automatically turned on with any other compatible distro~

Ah, I see PR#13987

So upon trying to update the packages I get the following

root@OpenWrt:~# opkg update
Downloading https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2712/packages/Packages.gz
*** Failed to download the package list from https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2712/packages/Packages.gz

Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/base/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/luci/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/routing/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading https://downloads.openwrt.org/snapshots/packages/aarch64_cortex-a72/telephony/Packages.sig
Signature check passed.
Collected errors:
 * opkg_download: Failed to download https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2712/packages/Packages.gz, wget returned 8.
root@OpenWrt:~# Failed to download the package list from https://downloads.openwrt.org/snapshots/targets/bcm27xx/bcm2712/packages/Packages.gz

Which shouldn't come as a surprise, as long as the PR isn't merged, yet.

1 Like

I was unaware, that makes sense now.

I was a fool.

I'm going to assume that's also the reason it wouldn't be able to install any other utilities.

Is there a way to work around this as I'm still freshly exposed to linux~ and internet related systems

As far as testing~ due to the a76 chip being able to heat up faster than.

It appears that even with the onboard cooling its not able to cool fast enough that it causes latency/speed tests to be very very... dependent on heat~ I can understand why users would want to skip the pi5~

(though this could also be due to the snapshot~)

As implied above, the issues will go away once support is merged - until then, you will have to build the PR code from source, enabling everything you might want at build time, including it into your image.

This isn't so much of a 'linux' issue, but more a side-effect of having to run extremely optimized code for the typical embedded platforms, to keep everything small and at maximum performance. Long term, for the contemporary RPi- and other SBC like (e.g. rockchip and sunxi) ARMv8 platforms, it might make sense to look into armsr and UEFI instead (to make these more generic) - but I guess that'll take time on the tianocore side.

1 Like