This reverts commit f98f95359b.
It seems that this commit is causing issues with the PWM fan on the RPi 5 as
reported here: https://github.com/openwrt/openwrt/issues/16191
So let's revert this for now.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
- Enable CONFIG_HWMON and CONFIG_THERMAL_HWMON on all subtargets.
- Drop kmod-thermal from bcm2712.
- Add CONFIG_SENSORS_RASPBERRYPI_HWMON generic symbol.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
These devices were already supported. I merely added missing entries to:
1. make them easier to locate in firmware selector
2. allow firmware upgrades to proceed without dire warnings
Sample dire warning contains:
upgrade: Device raspberrypi,model-zero-2-w not supported by this image
upgrade: Supported devices: rpi-3-b rpi-3-b-plus rpi-zero-2 \
raspberrypi,2-model-b-rev2 raspberrypi,3-model-b \
raspberrypi,3-model-b-plus raspberrypi,3-compute-module \
raspberrypi,compute-module-3 raspberrypi,model-zero-2
With this patch, the firmware upgrade proceeds normally.
Signed-off-by: Dave Brand <dbrand666@users.noreply.github.com>
This patch adds support for Raspberry Pi 5.
Instead of using 16K pages like Raspberry Pi OS, OpenWrt uses 4K pages due to
incompatibilities with F2FS and other applications.
There are multiple RPi forum posts with different cases and users are forcing
kernel8.img to workaround them, which is the 64 bit kernel of the RPi 4.
However, this isn't possible in OpenWrt because we only ship one kernel and we
would have to add RPi 5 support to bcm2711 subtarget (RPi 4) for that
workaround to work in OpenWrt.
Specification:
- Processor Broadcom BCM2712 2.4GHz quad-core 64-bit Arm Cortex-A76 CPU,
with cryptographic extension, 512KB L2 caches per core, 2048KB L3 cache
Features:
- VideoCore VII GPU, supports OpenGL ES 3.1, Vulkan 1.2
- Dual 4Kp60 HDMI display output with HDR support 4Kp60 HEVC decoder
- LPDDR4X-4267 SDRAM 4GB and 8GB
- Dual-band 802.11ac Wi-Fi
- Bluetooth 5.0 / Bluetooth Low Energy
- microSD card slot, with support for SDR104 high-speed mode
- 2 x USB 3.0 ports
- 2 x USB 2.0 ports
- Gigabit Ethernet
- 2 x 4 lane MIPI camera/display
- PCIe 2.0 x1
- 5V/5A power via USB-C
- Raspberry Pi standard 40-pin header
- Real-time clock RTC
- Power button
Build system: x86_64
Build-tested: bcm2712
Run-tested: bcm2712/RPi5
Signed-off-by: Marty Jones <mj8263788@gmail.com>
[Remove device variant, improve description]
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Some carrier boards [1][2] for the Raspberry Pi CM4 that are specifically
designed to be used as routers come with secondary NICs using a Realtek
RTL8111 Gigabit Ethernet chip.
When using such a board as a router with OpenWrt, it is very helpful
when both NICs are working by default. Since the Raspberry Pi 4 and the
CM4 have plenty of disk space, it should cause no harm to include the
kmod-r8169.
[1] https://wiki.dfrobot.com/Compute_Module_4_IoT_Router_Board_Mini_SKU_DFR0767
[2] https://www.waveshare.com/wiki/CM4-DUAL-ETH-MINI
Signed-off-by: Johannes Heimansberg <git@jhe.dedyn.io>
(r8169 should pull in the necessary dependencies.)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
NVRAM packages for the same wireless chip are consolidated into one as
they contain only small text files and symlinks.
Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
Package `cypress-nvram` was added because back then the files for newer
RPi models on `linux-firmware` didn't have the proper values.
It is the other way around nowadays, so switch back to `linux-firmware`.
Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
This is to align the implementation with upstream `linux-firmware`.
Some Raspberry Pi boards do not have dedicated NVRAM in `linux-firmware`
source repository, their NVRAM is provided through a symbolic link to
NVRAM of another board with an identical wireless design.
Signed-off-by: Kuan-Yi Li <kyli@abysm.org>
Due to licensing uncertainty, we do not include the firmwares for the
wireless chips used in the Raspberry Pi Zero 2 W. To have working
wireless, follow the instructions below.
For people building their own images:
mkdir -p files/lib/firmware/brcm
wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436-sdio.bin
wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436-sdio.txt
wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436s-sdio.bin
wget -P files/lib/firmware/brcm/ https://github.com/RPi-Distro/firmware-nonfree/raw/bullseye/debian/config/brcm80211/brcm/brcmfmac43436s-sdio.txt
Now build the OpenWrt image as usual, and it will include the firmware
files in the correct location.
For people using ext4 images:
Write the ext4 image to the sdcard, then mount the 2nd partition and put
the firmware files from the links above in /lib/firmware/brcm relative
from the mount point where the partition is mounted.
For people using squashfs images:
Write the squashfs image to the sdcard, place it in the Raspberry Pi
Zero 2 W, boot it and wait for the overlay filesystem to be created.
Find the offset of the overlay filesystem in sysfs:
# cat /sys/devices/virtual/block/loop0/loop/offset
25755648
Shut down the device, unplug the power and move the SD card to a Linux
computer. Mount the 2nd partition of the sdcard as a loop device with
the offset found earlier.
sudo mount /dev/sdh2 -o loop,offset=25755648 /mnt/temp
Put the firmware files from the links above in /upper/lib/firmware/brcm
relative to the mount point where the loop device is mounted.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Tested-by: Peter van Dijk <peter@7bits.nl>
Some vendors like Seeedstudio in their product [1] with Raspberry Pi
Compute Module 4 uses Microchip LAN7800 (USB 3.0 to Gigabit
Ethernet Bridge) - USB 3.0 extended from PCIe of CM4.
lsusb output:
```
Bus 002 Device 002: ID 0424:7800 Microchip LAN7800
```
Raspberry Pi 4 and even Compute Module 4 has many resources available
and for just one kernel module it is not necessary to add additional specific CM4 profiles.
Let's include it by default, so the both Ethernet ports will be usable
to have better user-experience. Because previous generation of Raspberry
Pi included LAN7800 Gigabit Ethernet by default and it is enabled there
[2] in kernel without additional kernel module, which was added recently [3].
After this commit in dmesg can be found this:
```
root@OpenWrt:~# dmesg | grep lan
[ 7.038889] lan78xx 2-3:1.0 (unnamed net_device) (uninitialized): int urb period 64
[ 7.090484] usbcore: registered new interface driver lan78xx
```
Tested and works with sysupgrade image.
[1] https://www.seeedstudio.com/Dual-GbE-Carrier-Board-with-4GB-RAM-32GB-eMMC-RPi-CM4-Case-p-5029.html
[2] 32c74552b2/target/linux/bcm27xx/bcm2709/config-5.4 (L437)
[3] 31647d8be8
Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Both bcm2709 and bcm2710 firmware can run on the same RaspberryPi
models, varying however in 32 and 64 Bit architectures. The model name
alone does not include the architecture information, which becomes
problematic if looking at a overview that only contains the names. By
adding a variant it is possible to tell the architecture.
Signed-off-by: Paul Spooren <mail@aparcar.org>
In order to support SAE/WPA3-Personal in default images. Replace almost
all occurencies of wpad-basic and wpad-mini with wpad-basic-wolfssl for
consistency. Keep out ar71xx from the list as it won't be in the next
release and would only make backports harder.
Build-tested (build-bot settings):
ath79: generic, ramips: mt7620/mt76x8/rt305x, lantiq: xrx200/xway,
sunxi: a53
Signed-off-by: Petr Štetiar <ynezz@true.cz>
[rebase, extend commit message]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This change makes the names of Broadcom targets consistent by using
the common notation based on SoC/CPU ID (which is used internally
anyway), bcmXXXX instead of brcmXXXX.
This is even used for target TITLE in make menuconfig already,
only the short target name used brcm so far.
Despite, since subtargets range from bcm2708 to bcm2711, it seems
appropriate to use bcm27xx instead of bcm2708 (again, as already done
for BOARDNAME).
This also renames the packages brcm2708-userland and brcm2708-gpu-fw.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Acked-by: Álvaro Fernández Rojas <noltari@gmail.com>
