Raspberry Pis' config.txt

Here is a URL for the official Raspberry Pi documentation on the config.txt, and here is a URL for clockworkpi’s provided config.txt for the CM4.

Raspberry Pis use the file config.txt, located in the boot partition (mounted by Raspberry Pi OS at /boot/firmware/, and prior to RPiOS Bookworm, /boot/) to change firmware options on boot.

For additional information, this is a quote from Perplexity.ai, so take it as it is:

…While there is no explicit quote [in official documentation] saying “later entries take precedence,” it is an understood and documented behavior consistent with how the config file and includes work on Raspberry Pi.

Given that there are only a handful of Compute Modules useable on the uConsole, and that the uConsole on its own is 1 hardware configuration, is it possible for there to be a “best” config.txt? I think it’s possible. If we all get together and share our hardware configurations and config texts, perhaps we can at least make a well-documented config.txt that would act as a better start point for new uConsole owners.

Here is my full /boot/config.txt, which I have commented thoroughly and honestly. I can’t pretend to be an expert in the matter.

# Raspberry Pi config.txt
# Use under the license of your choice, of: Public Domain, MIT, UNLICENSE.

# Compatibility
#
# Name | Should work | Tested?
# CM3  | Yes         | Not yet
# CM3+ | Yes         | Not yet
# CM4S | No          | Not yet
# CM4  | Yes         | Yes
# CM5  | Yes         | Not yet
# Tested on a CM4 Lite 4GB, with the HackerGadgets SDR board.

# Raspberry Pi OS default. Using a kernel named "kernel8.img" sets this
# implicitly. There are no (known) 32 bit kernels useable on the uConsole.
arm_64bit=1

# Raspberry Pi OS default. Increases the default turbo-mode frequency from
# 1.5GHz to 1.8GHz on certain 4Bs and all 400s. Does this apply to the CM4?
arm_boost=1

# Prevents the firmware from picking a video mode, leaving it to Linux.
# TODO: is this useful?
disable_fw_kms_setup=1

# clockworkpi default.
# TODO: is this necessary?
disable_overscan=1

# clockworkpi default. Remaps the audio output to GPIO pins 12 and 13, used by
# the mainboard (visible on the schematic).
dtoverlay=audremap,pins_12_13

# clockworkpi default. Enables the USB controller on the mainboard (presumably)
# and sets it to USB host mode.
dtoverlay=dwc2,dr_mode=host

# This enables use of the PCF85063A RTC over I2C, for the HackerGadgets SDR
# board. If not using that expansion, leaves a complaint in your logs.
#dtoverlay=i2c-rtc,pcf85063a

# On the DevTerm, this enables the built-in printer. If using the HackerGadgets
# SDR board, enables the expansion's LoRa transceiver. See:
# <https://hackergadgets.com/pages/hackergadgets-uconsole-rtl-sdr-lora-gps-rtc-
# usb-hub-all-in-one-extension-board-setup-guide>.
#dtoverlay=spi1-1cs

# This is used to use the mainboard's WLAN antenna connector rather than the
# one on the Compute Module.
#dtparam=ant2

# clockworkpi default. Enables on-board audio.
dtparam=audio=on

# This is a clockworkpi default that enables SPI. On the CM3 or CM4 it doesn't
# do any harm to leave it on even when not using it.
dtparam=spi=on

# Enables the serial console on GPIOs 14 and 15, used by the HackerGadgets SDR
# expansion for communication with the GPS. Does nothing otherwise.
enable_uart=1

# clockworkpi default. Configures GPIO 10 as an input; it is used by the
# mainboard for audio jack detection (visible on the schematic as HP_DET).
gpio=10=ip,np

# clockworkpi default. Prevents autodetection of the Raspberry Pi Touch Display
# (which is certainly not present) on the I2C bus - not strictly necessary, but
# saves time.
ignore_lcd=1

# Compute Module 3, Compute Module 3+
[pi3]

dtoverlay=clockworkpi-uconsole-cm3

# Loads the full KMS driver for the Pi 3's VC4 graphics system.
dtoverlay=vc4-kms-v3d

# Uses the mainboard WLAN.
dtoverlay=spi-gpio35-39

# Configures GPIO 11 as an output, driven high; this is to enable the speakers
# on the mainboard (visible on the schematic as PA_EN). On the CM4 and CM5,
# this causes the speaker be enabled even when headphones are connected.
# TODO: is this necessary on the CM4S?
gpio=11=op,dh


# Compute Module 4S
[cm4s]

# I have not tried this configuration.


# Compute Module 4
[cm4]

dtoverlay=clockworkpi-uconsole

# Loads the full KMS driver for the Pi 4's VC4 graphics system.
dtoverlay=vc4-kms-v3d-pi4

# This is part of the configuration for the HackerGadgets SDR expansion.
#dtparam=i2c_arm=on


# Compute Module 5
[cm5]

dtoverlay=clockworkpi-uconsole-cm5

# This enables use of the PCF85063A RTC over I2C, for the HackerGadgets SDR
# board, in situations where the prior i2c-rtc,pcf85063a line doesn't work.
# This line has a different meaning on prior Compute Modules. See
# <https://forum.clockworkpi.com/t/hackergadgets-aio-board-package/17875/286>.
# TODO: is this a problem specific to the CM5, or to certain SDR boards?
#dtoverlay=i2c-rtc,pcf85063a,i2c_csi_dsi0

# Loads the full KMS driver for the Pi 5's VC4 graphics system.
dtoverlay=vc4-kms-v3d-pi5

# On the CM5, using SPI causes the backlight to be disabled (TODO: why?),
# requiring the operating system to re-enable it. This is necessary if using
# other things on the SPI bus, such as the HackerGadgets SDR board. Comment
# this line out to re-enable it.
dtparam=spi=off

# Disables the unused PCIe lane.
dtparam=pciex1=off

# This is part of the configuration for the HackerGadgets SDR expansion.
#dtparam=rtc=off

# Enables the serial console on GPIOs 14 and 15, used by the HackerGadgets SDR
# expansion for communication with the GPS. Does nothing otherwise.
dtparam=uart0

# On the CM5 this is unnecessary.
enable_uart=0


[all]

# The kernel and initramfs lines are dictated by what operating system is in
# use. For examples:

#kernel=vmlinuz-linux-uconsole-rpi64
#initramfs initramfs-linux-uconsole-rpi64.img followkernel

#kernel=vmlinuz-linux-clockworkpi-git
#initramfs initramfs-linux-rpi-clockwork.img followkernel

I’ll be editing this top message as the thread goes on, with my current tested configuration, to ensure it stays up to date and in the same place.

1 Like

Have you taken a look at the config.txt in any of my images?

I have it’s set up to work with both the uConsole and DevTerm cm3/4/5 with the only changes needed is if you’re using a DevTerm you need a comment out the uConsole stuff and uart is already set up for the devices.

The first entry is not needed as all images for the uConsole and DevTerm have 64bit only kernels.

disable_audio_dither someone said fixed the low battery issues with the CM5 but it didn’t work.

disable_fw_kms_setup=1 is already defaulted to 1 so is not necessary.

The spi stuff is only applicable to the DevTerm or if you have the hackergadgets AIO board.

The RTC stuff is not needed unless you have the hackergadgets AIO board. The RTC built into the cm5 does not have power to it in the stock configuration so will not work.

Here’s the config.txt I ship with all my images.


[pi3]
#dtoverlay=clockworkpi-devterm-cm3
dtoverlay=clockworkpi-uconsole-cm3
dtoverlay=vc4-kms-v3d
dtparam=spi=on
dtoverlay=spi-gpio35-39
gpio=11=op,dh
enable_uart=1


[pi4]
#dtoverlay=clockworkpi-devterm
dtoverlay=clockworkpi-uconsole
dtoverlay=vc4-kms-v3d-pi4,cma-384
dtparam=spi=on
enable_uart=1


[pi5]
#dtoverlay=clockworkpi-devterm-cm5
dtoverlay=clockworkpi-uconsole-cm5
dtoverlay=vc4-kms-v3d-pi5,cma-384
dtparam=pciex1=off
dtparam=uart0


[all]
ignore_lcd=1
max_framebuffers=2
disable_overscan=1
dtparam=audio=on
dtoverlay=audremap,pins_12_13
dtoverlay=dwc2,dr_mode=host
dtparam=ant2


##only edit the section of the pi you have, other section will be ignored.
##if you have a devterm uncomment devterm and comment out entries with uconsole.
3 Likes

On what hardware configurations is your config.txt tested working?

The first entry is not needed as all images for the uConsole and DevTerm have 64bit only kernels.

I’ll move this to the CM3 section, as the CM3 still boots in 32-bit mode.

disable_audio_dither someone said fixed the low battery issues with the CM5 but it didn’t work.

Thank you, I must have added it in error. I’ll go ahead and remove this.

The spi stuff is only applicable to the DevTerm or if you have the hackergadgets AIO board.

Could you explain the SPI settings you do have in the file you provided?

The RTC stuff is not needed unless you have the hackergadgets AIO board. The RTC built into the cm5 does not have power to it in the stock configuration so will not work.

Do you think dtparam=rtc=off would cause any issues on any uConsole configurations, then? It seems to me that you are implying it’s a no-op except when needed (for the HackerGadgets board). I will comment dtoverlay=i2c-rtc,pcf85063a as it could cause issues with a different expansion present.

Your provided config.txt is interesting but lacks necessary documentation. A solution is infinitely more useful when it is accompanied by an explanation; the same goes for code and configuration.

The CM3 in any image for the uConsole will only boot in 64bit as nobody has compiled a 32bit kernel for it that i’ve seen.

the spi-gpio35-39 stuff in the cm3 section is for it to use the wifi on the main board and spi=on is just so the OS can use the thermal printer on the DevTerm

the gpio=11=op,dh is to activate the speakers on the CM3 because for some reason it won’t do it on it’s own but the cm4/5 will.

I’m not sure if leaving the rtc=off will have any adverse effect but having dtoverlay=i2c-rtc,pcf85063a will just throw a “device not found error” without the AIO card.

I’m not the best with documenting but your device will only use the [pi] section it belongs to and [all]

enabling the i2c bus disables the camera, because the i2c bus on the expansion connector is actually the secondary one meant to be for the camera
I don’t think anyone is currently using the camera but it is exposed on the expansion connector

1 Like

this will not do anything or break any image besides the official one. my images ship with 2 kernels the 64bit 4k for the cm3/4/5 and the 64bit 16k for only the cm5. a pi 4 will boot kernel8.img (4k kernel) only and the pi5 will boot kernel_2712.img (16k kernel) unless told to boot kernel8.img

The CM3 in any image for the uConsole will only boot in 64bit as nobody has compiled a 32bit kernel for it that i’ve seen.

I am reiterating my query as to what hardware configurations you have used to test your config.txt. The documentation says arm_64bit=1 is necessary to boot a 64-bit OS from a CM3, on a firmware level, as it will otherwise start in 32-bit mode.

the spi-gpio35-39 stuff in the cm3 section is for it to use the wifi on the main board

the gpio=11=op,dh is to activate the speakers on the CM3

Is there any harm in enabling either of these on later Compute Modules?

spi=on is just so the OS can use the thermal printer on the DevTerm

Is there any use in enabling this on a uConsole?

Yes I have tested with a CM3 in the uConsole arm_64bit=1 is not necessary all uConsole images only have the 64bit kernel to boot off of. There is no 32bit kernel present to boot.

spi-gpio35-39 will only work with the CM3 CM4s, the CM4/5 are not physically hooked up to the main boards wifi chip

gpio=11=op,dh shouldn’t mess with anything if you did have it under the CM4/5

enabling spi is not necessary on the uConsole unless you have the hackergadgets AIO board and can cause issues with the CM5 unless you add a systemd service to re-enable the backlight. i do have a package in my repo for it and it installs with my hackergadgets package.

1 Like

Thank you. I’ve updated my first post and I welcome your input on the changes.

1 Like

On my CM4 uConsole running Arch Linux ARM with kernel 6.16.y the following line:

gpio=11=op,dh

causes the speaker to be enabled unconditionally rather than switched based on the presence of headphones. Could anyone test this on their CM4 or CM5 and see if they see the same bug? I think it’s more likely due to the Compute Module present than the OS but I’m not sure.

that’s not a bug, that line sets GPIO 11 high permanently, and GPIO 11 is connected to the enable input of the audio amplifiers that drive the speakers.

1 Like

That line should only be set for the CM3, the headphone switching is done elsewhere for the CM4/5 depending on what kernel you’re running.

I see, I didn’t realize this line bugged the CM4 or CM5.

Life gets a lot easier when you realize, regardless of even authorial intent, that the only sensible definition for “software bug” is “part of the software that bugs me”. “Software fault” is the literal form of the term.

@rex. I need some help… you did an amazing job with the images and packages. Thanks.
today, i found my clock not synced. so when I did a dmesg | grep rtc, nothing shows. modprobe shows no kernel module loaded for RTC. i have no idea what happend, as everything was working fine until yesterday. is it possible that an apt update, updated my kernel, and the new one hasn’t got the modules?
uname -r returns: 6.12.37-v8-16k+
but ls -l vmlinuz* /boot/ returns:
vmlinuz-6.12.45-v8-16k+
vmlinuz-6.12.45-v8+
however ls -l init /boot/ returns:

initrd.img-6.12.30-v8+
initrd.img-6.12.30-v8-16k+
initrd.img-6.12.32-v8+
initrd.img-6.12.32-v8-16k+
initrd.img-6.12.34-v8+
initrd.img-6.12.34-v8-16k+ i
initrd.img-6.12.37-v8+
initrd.img-6.12.37-v8-16k+
initrd.img-6.12.45-v8+
initrd.img-6.12.45-v8-16k+
Any ideeas what happened? and what kernel to run / what modules?

Do you have the hackergadgets AIO board? Only the cm5 has an RTC but it doesn’t have a power source to run.

You can probably delete all those old initramfs files from older kernels before 6.12.45

yes. I’m running the CM5 + AIO board. and it has been running great.
it seems, that “somehow” i managed to partialy upgrade the kernel to .45, but it still hanged to .37 (uname -r).
i managed to restore the kernel image to the /boot partition from the .deb cache, and also the modules.

1 Like

So it’s all working as intended now?

yes. I have it working good on the .37 kernel. what is the “current” kernel?
what are you (@rex) running?

1 Like

Current is 6.12.45 I’m running Debian bookworm still just because I haven’t gotten around to setting up a new SD with Trixie on it configured how I like.

I have found a case where arm_64bit=1 is indeed necessary and have updated my first post accordingly. I’m not yet sure why OuinOuin74’s kernels are an exception to your rule.