These are commands you type (or copy-and-paste) into your terminal. The lines starting with # are comments and are not executed.
So to Download and update the sources:
Type git clone https://git.openwrt.org/openwrt/openwrt.git and press enter.
Wait until the operation completes. It involves downloading the sources so it will take some time.
Type cd openwrt and press enter.
Type git pull and press enter.
And so on for the rest of the commands, except for make menuconfig. This step will present a screen that allows you to pick which target and packages to build. The "Build system usage" page I linked earlier has a more detailed explanation:
When you open menuconfig you will need to set the build settings in this order (also shown in this order in menuconfig's interface):
Target system (general category of similar devices)
Subtarget (subcategory of Target system, grouping similar devices)
Target profile (each specific device)
Package selection
Build system settings
Kernel modules
You really only need to configure settings 1, 2, and 3, in that particular order. For the Raspberry Pi 5 you want to pick bcm27xx as the target system, bcm2712 as the subtarget, then pick the Raspberry Pi 5 target profile. You might also want to configure setting 4 to build and include LuCI into the image.
Looks like snapshot is now working again. I was able to install additional packages and install using ext4 custom image.
Modify cmdline.txt if you are doing usb boot install console=serial0,115200 console=tty1 root=/dev/sda2 rootfstype=squashfs,ext4 rootwait
I also had to remove the partuuid.txt in /boot
Modify config.txt if you want to turn off leds and ignore voltage warning
# OpenWrt config
include distroconfig.txt
[all]
# Place your custom settings here.
# Turn off the LEDs
dtparam=pwr_led_trigger=default-on # The default
dtparam=pwr_led_activelow=off
dtparam=act_led_trigger=default-on # The default
dtparam=act_led_activelow=off
dtparam=eth_led0=4
dtparam=eth_led1=4
#dtparam=act_led_trigger=off
#dtparam=act_led_activelow=off
#enable uart pi5
enable_uart=1
#enable rtc charging
dtparam=rtc_bbat_vchg=3000000
[all]
#disable high current warning
usb_max_current_enable=1
I've been trying to use openvpn on my raspberry pi 5 for a few days and can't get more than 50-ish mbps. I know it can go faster as I have connected to the same server on an x86 machine and got way higher speeds. I followed this page (https://openwrt.org/docs/techref/hardware/cryptographic.hardware.accelerators) to try and get it going faster, but I'm not seeing any change, even after a reboot. I installed libopenssl-devcrypto and kmod-cryptodev.
When I run "openssl engine -t -c" I get (and this isn't redacted)
(dynamic) Dynamic engine loading support
[ unavailable ]
(devcrypto) /dev/crypto engine
[ available ]
I also tried using "openssl speed -elapsed -evp aes-128-cbc" and "env OPENSSL_ia32cap=0 openssl speed -elapsed -evp aes-128-cbc" to test hw vs non-hw crypto speeds and they are nearly identical.
I'm pretty sure the pi has crypto acceleration according to this reddit post , though they probably were using raspberry pi os or something other than openwrt. I'm using the snapshot builds to do this. Do I need to recompile it altogether? The image builder appears to have the kmod-crypto-core and kmod-cryptodev modules selected in the .config file so I'm not sure what else I need to do.
I assume you mean in the openvpn client config. I just tried adding that and I get no change in performance. The logs also start showing "Note: OpenSSL hardware crypto engine functionality is not available", but that goes away when I reverse the change.
3200/0.79 gives around 4000 so pi5 should be able to do a maximum of 4gbps openvpn under ideal circumstances with aes-256-gcm
And ~2.6gbps with aes-256-cbc
On a hunch, I looked into the Raspberry Pi 5's image builder and noticed that CONFIG_CRYPTO_HW is not set in the .config file. I think the default for that value is n, so that gives me to impression that the image simply doesn't have HW crypto enabled at all.
I'm trying to compile it with that enabled, but am running into other unrelated problems in the build process. Am I possibly on the right track with this or is it a red herring?
I think CONFIG_CRYPTO_HW is only for dedicated hw and that's not the case for rpi5 as there are only cpu crypto extensions enabled by default and that's working fine according to the benchmark above.
How did you determine your Pi was faulty? What tests did you run? I am having issues with mine too and just want to make sure it is or isn't the actual board.
Downloaded today's snapshot, booted, and ssh'd in. Works for me. Noticed a welcome change to cmdline.txt. It's now using partition ids so I didn't need to manually edit my usb drive partition location. Nice.
None of the operating systems I tried would boot – Ubuntu, Raspberry Pi OS, OpenWrt, or even for firmware updates, the Raspberry Pi was unresponsive.
It was completely bricked.
I suspected an issue with the main power rail based on my limited electronic knowledge. I checked the integrated circuits and capacitors on the card with my fingertips for short circuits because a short circuit equals heat.
And I noticed that when I plugged in the power, the PMIC was suddenly heating up incredibly for a moment and then cutting off power. This made me realize that the card itself was faulty.
The rest is simple. They sent me a new one as soon as it was restocked.