Code and docs of uConsole with CM3 core.
Here I use mainline linux RPi's downstream fork.
I started from archlinuxarm's linux-aarch64. It looks like RPi3's mainline support is enough mature. I can reuse the infrastructure built by forks at archlinuxarm, focus on tweaking/optimizing linux.
- port drivers
- write device tree
- build test
- test on real hardware
- kernel boots on a RPi 3B
- kernel boots on uConsole with CM3
- HDMI(video) works
- WiFi works
- Bluetooth works
- PMU works
- the charging indicator/LED uses the same hack from CPi's patch, now LED will stay on when charging
- CM3's I2C0 is buggy and cannot be used for PMU, use i2c-gpio instead
- DSI panel works
- There will be some error messages from kernel when screen is turned off, and it seems safe to ignore them.
- Audio works
- with 3.5mm jack detection
- A better virtual sound card mode should be implemented to maintain different volume values for different outputs. But I don't know how. Help wanted.
- with 3.5mm jack detection
- CM4 support
- it's done
- have no CM4 so cannot test
- a forum user reports that everything works with latest code
- CM4S support
- tested on a CM4S (CM4S01016B) board, everything works
- It's fully compatible with CM3 from a hardware perspective. The software needs a few tweaks.
[ ] trim build config- setup CI/CD?
I've successfully adapted the uConsole patches to CM3. I've even written a new kernel driver to support automatic amplifier switch, so the speaker will automatically shutdown when 3.5mm jack is used. No software polling, efficient.
Raise issue if you have any problems.
It's reported that CM4's WiFi won't work if using the kernel package in this repo. It should be fixed in latest code though.
Please read the guide in doc(still draft and possibly will never be updated).
Or read the scripts to figure out the procedure.
There exists working bootloader and kernel for RPi. The missing part is the drivers for uConsole. I fixed it through porting CPi's code to latest kernel, and then packaged it for ease of use. That's all, despite that there was some frustrating things during the process.
For arch, a standard way to build a kernel package is calling makepkg
directly in the folder where PKGBUILD
sits. If you want to cross compile it, just pass more environment variables, using this command:
makepkg CARCH=aarch64 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
CARCH=aarch64
is required to override the host arch detection mechanism in makepkg
.
When cross compiling, the kernel headers cannot be packaged properly, and just ignore any error about that. Kernel headers must be built on the target machine to have the tools compiled for the target.
They are essentially the same. Only the packaging methods differ. You can build your own kernel with patches and config in PKGBUILDs/linux-uconsole-cm3-rpi64
.
kinda lazy ;)
Use the scripts to create customized system image, a rebuild of the kernel package might be necessary though.
And I need time/investment for other personal projects.
Because of the operation voltage(3.3V by default) and RPi's limit, the WiFi part of the wireless module cannot run at its highest speed. But it should be enough.
BT serial speed will affect module's wireless performance. Just a note.
For Arch users: there's a firmware package to enable WiFi and BT hardware, packaged by Manjaro devs. It replaces the firmware packages derived from Armbian's and RPi's repositories, brcmfmac43456-firmware
in aur and firmware-raspberrypi
in alarm, respectively.
BT & WiFi coexistence may need further tweaking. When there's traffic over 2.4G WiFi, BT audio will stutter. Read this post for available parameters. I failed to make BT audio stable with 2.4G WiFi. One workaround is soft-blocking WiFi using rfkill, or use 5G WiFi only. Contributions welcomed.
On uConsole with CM3, the official LTE modem will ALWAYS be powered up on boot because the initial pulls of the pins.
When plugged in, the system might not able to fully shutdown itself. This is no longer a problem. This originates from I2C0's issue on RPi3 series. Somehow the communication will fail if hardware I2C0 is used.
The power button is the system power button, that means you can shutdown your uConsole just by clicking the power button.
Since Sun Nov 5 UTC 2023, this repo contains patches to enable gauge calibration on AXP228. To use it:
# initialize calibration
echo 1 | sudo tee /sys/class/power_supply/axp20x-battery/calibrate
# check status
cat /sys/class/power_supply/axp20x-battery/calibrate
# BIT(5): feature status, 1 for enabled
# BIT(4): active state, 1 for active, should be 0 after calibration done
# read current capacity(uWh)
# This is calculated from original uAh value from PMU reads.
# It assumes the typical voltage is 3.6V.
cat /sys/class/power_supply/axp20x-battery/energy_full
It's possible to manipulate the PMU directly with i2c-tools
. In this case, the driver i2c_dev
should be loaded with modprobe/insmod.
Sometimes the screen will stay black. This is because a data transfer timeout and the LCD is not initialized. It occurs with about 10% chance when screen(and DSI bus) is fully reseted and can be fixed by doing another reset. There seems a bug for the driver vc4_dsi
, see issue 4323 in raspberrypi/linux. Currently a few workarounds are required to fully eliminate this issue.
For ArchLinux users, you can try rpi-dsi-workaround
in PKGBUILDs. Install the package and enable the service rpi-dsi-workaround.service
to start it at boot. The workaround checks the DSI bus's state every 60 seconds, and reset the screen if an error is found. This feature requires latest patch set from the package linux-uconsole-rpi64
.