Mate don’t you worry. It used to boil my blood when someone just pointed me to the “arch wiki”, but honestly, 98% of times you end fixing things that way.
No one is born with all that knowledge. Take it easy and patience!
Trying out this image myself on the CM4, and it’s working well. I’ve set up i3 and I’m wondering how to get the battery status. Looking at /sys/class/power_supply/axp20x-battery/uevent I’m seeing POWER_SUPPLY_ENERGY_NOW and POWER_SUPPLY_ENERGY_FULL are both 0. Every other value looks normal. Is there any additional configuration needed to get the battery charge to show up?
[ucon@archlinux ~]$ sudo cat /sys/class/power_supply/axp20x-battery/uevent
POWER_SUPPLY_NAME=axp20x-battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_ONLINE=1
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_VOLTAGE_NOW=4251000
POWER_SUPPLY_CURRENT_NOW=1736000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT=2100000
POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=2100000
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=4200000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=3300000
POWER_SUPPLY_CAPACITY=86
POWER_SUPPLY_ENERGY_FULL=0
POWER_SUPPLY_ENERGY_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=8000000
POWER_SUPPLY_CALIBRATE=0
[ucon@archlinux ~]$ acpi -V
Battery 0: Charging, 0%, until charged
Battery 0: design capacity 1893 mAh, last full capacity 0 mAh = 0%
Adapter 0: on-line
Cooling 0: cpu-thermal no state information available
From my experience, the energy readings are not reliable so I just ignore them. If you want a seemingly normal value, you might want to trigger a calibration using this command:
echo 1 | sudo tee /sys/class/power_supply/axp20x-battery/calibrate
The mentioned features are not implemented in mainline driver and are from a pmu patch inspired by yatli’s work on devterm.
You might also want to write a correct ENERGY_FULL_DESIGN value using i2c-tools directly. This is not implemented in the pmu driver yet.
Tried to compile with rpi kernel 6.9 got an error with 90-linux-dtbs.hook … FAILED
Don’t know what is the device tree binary thing yet.
Archlinux working fine, 3d acceleration not perceptible.
Wifi works really well, bluetooth not, Though since update from ap6256-firmware.git mouse trackball is not going left or right.
I’m ready to help if needed
It’s just a minor checksum issue. You can either update the checksums locally with updpkgsums(providing you’ve inspected the code) or use my updated code.
1 Like
One more thing, by the way. When I power up the device while connected to an external monitor, it displays the TTY/console in the correct orientation, but the one on the device is rotated -90 degrees. Only when I startup an environment does the quirk disappear. Can anything be done about that? It’s not so much a deal breaker, but it would be great to have a fix.
Try adding this to your cmdline.txt file.
fbcon=rotate:1
That should rotate the console screen.
1 Like
Will this affect the screen when I start without an external monitor next time? I think I’ll try it anyway. Thanks for making me aware of cmdline.txt.
1 Like
It should just rotate the DSI panel, I haven’t used the console on a external monitor though. You can always just remove it if it causes more problems then fixes.
It’s a known problem. The VTs share the same framebuffer console and the rotation has effect on both outputs. I came up with a workaround that using window managers or desktop environments and adjusting the outputs settings there. In my case the cmdline parameter is not necessary.
If you prefer to keep the right orientation on builtin LCD despite the status of HDMI, then you should use fbcon=rotate:1.
1 Like
Update on rotating the orientation:
- Without ‘fbcon’: Device screen without external monitor displays correct orientation. With external monitor, the orientation is correct; the device’s display however is rotated -90 degrees.
- With
fbcon: Device screen without external monitor displays correct orientation. Connected to external monitor, the device screen displays in correct orientation; but the external monitor is rotated 90 degrees.
I think I’m stuck in a catch-22 situation. I guess I’ll prefer without the fbcon.
Can you rotate the monitor within the monitors menu?
Hahahahaha, we’re just talking the TTY/console there. Whether or not fbcon is present, and whether or not a monitor was connected before boot, the orientation of the displays were always correct with GNOME.
But come to think of it, I haven’t tested plugging the monitor with the system booted.
I mean on the actual monitor. like you can have fbcon present and when you need to use the console on the monitor press a few keys on the back of the monitor to rotate it. my 21" monitor can do portrait or landscape.
Oops. I don’t think that’s a thing in my 4K TV. I can fiddle around, but I make no guarantees. By the way, the system curiously takes up the whole screen but uses a 1/12 portrait portion to display the console. 
I tested playing a video with ffmpeg, and it obliged on the external monitor largely without issue… save the possible orientation patch. Sound is still on the device so I wonder how to transfer to HDMI audio in TTY.
Audio won’t work over HDMI unless the CM4 boots with the HDMI already plugged into a tv/monitor.
If I remember it right, you can still manually change the audio output to HDMI after booting.
1 Like
Any clues on microphone jack (TRRS) not recognised on arch ?
the 3.5mm jack on the mainboard is only audio out.
2 Likes
The mic is not connected if you are using a raspi core(those are NC pins). You can still access the mic if you are using R01 or A06. It’s not a problem of Arch.