NixOS support for CM4

so, there is a overlay. can you look at the vclog -m and see, if the overlay is loading? / errors. do you have a HDMI cable/monitor attached to the uconsole?
also check /sys/devices/platform/soc/fe700000.dsi/fe700000.dsi.0/dsi_state

let me think… can you also try to upgrade the boot loader firmware?

# vcgencmd bootloader_version
2025/05/08 16:21:35
version 69471177ba7e4cb7597cb2496f2a0b23f19c1113 (release)

vclog -m output:

002917.097: arasan: arasan_emmc_open
002917.268: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5
003022.043: arasan: arasan_emmc_set_clock C0: 0x00800000 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 400000 max: 400000 delay: 5
003022.129: arasan: arasan_emmc_set_clock C0: 0x00800f00 C1: 0x000e0047 emmc: 200000000 actual: 390625 div: 0x00000100 target: 400000 min: 390000 max: 400000 delay: 5
003041.400: arasan: arasan_emmc_set_clock C0: 0x00800f06 C1: 0x000e0207 emmc: 200000000 actual: 50000000 div: 0x00000002 target: 50000000 min: 0 max: 50000000 delay: 1
003048.457: brfs: File read: /mfs/sd/config.txt
003048.911: brfs: File read: 298 bytes
003069.733: HDMI0:EDID error reading EDID block 0 attempt 0
003070.748: HDMI0:EDID giving up on reading EDID block 0
003082.511: HDMI1:EDID error reading EDID block 0 attempt 0
003083.527: HDMI1:EDID giving up on reading EDID block 0
003084.288: brfs: File read: /mfs/sd/config.txt
003084.695: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
003541.242: gpioman: gpioman_get_pin_num: pin LEDS_PWR_OK not defined
003542.522: *** Restart logging
003542.541: brfs: File read: 298 bytes
003547.766: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
003548.782: hdmi: HDMI0:EDID giving up on reading EDID block 0
003553.827: hdmi: HDMI0:EDID error reading EDID block 0 attempt 0
003554.845: hdmi: HDMI0:EDID giving up on reading EDID block 0
003554.862: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
003559.901: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0
003560.918: hdmi: HDMI1:EDID giving up on reading EDID block 0
003565.958: hdmi: HDMI1:EDID error reading EDID block 0 attempt 0
003566.973: hdmi: HDMI1:EDID giving up on reading EDID block 0
003566.992: hdmi: HDMI:hdmi_get_state is deprecated, use hdmi_get_display_state instead
003567.007: HDMI0: hdmi_pixel_encoding: 300000000
003567.019: HDMI1: hdmi_pixel_encoding: 300000000
003576.945: dtb_file ‘bcm2711-rpi-cm4.dtb’
003582.722: brfs: File read: /mfs/sd/bcm2711-rpi-cm4.dtb
003582.737: Loaded ‘bcm2711-rpi-cm4.dtb’ to 0x100 size 0xdd14
003596.660: brfs: File read: 56596 bytes
003618.343: brfs: File read: /mfs/sd/config.txt
003634.399: brfs: File read: 298 bytes
003634.544: Failed to open command line file ‘cmdline.txt’
003714.240: brfs: File read: /mfs/sd/armstub8-gic.bin
003714.250: Loaded ‘armstub8-gic.bin’ to 0x0 size 0x200
003714.275: brfs: File read: 512 bytes
003905.595: brfs: File read: /mfs/sd/u-boot-rpi4.bin
003905.612: Loaded ‘u-boot-rpi4.bin’ to 0x200000 size 0x9e958
003906.368: Kernel relocated to 0x80000
003906.379: Device tree loaded to 0x2eff1e00 (size 0xe192)
003908.348: gpioman: gpioman_get_pin_num: pin SDCARD_CONTROL_POWER not defined
004012.785: sdram: sdram refresh 1562->6248 (1)

016414.277: vchiq_core: vchiq_init_state: slot_zero = 0xeaf80000, is_master = 1
030139.325: gpioman: gpioman_get_pin_num: pin FLASH_0_ENABLE not defined
030139.339: gpioman: gpioman_get_pin_num: pin FLASH_0_INDICATOR not defined
030139.365: gpioman: gpioman_get_pin_num: pin FLASH_0_ENABLE not defined
030139.376: gpioman: gpioman_get_pin_num: pin FLASH_0_INDICATOR not defined

There’s no *dsi dir in soc:

✗ ls /sys/devices/platform/soc/
driver fe101000.cprman fe300000.mmcnr soc:nvmem
driver_override fe104000.rng ff800000.interrupt-controller soc:power
fd5d2000.avs-monitor fe200000.gpio modalias subsystem
fe00b840.mailbox fe200000.gpiomem of_node uevent
fe00b880.mailbox fe201000.serial power
fe007000.dma-controller fe215000.aux soc:fb
fe100000.watchdog fe215040.serial soc:firmware

And the bootloader version is:

❯ vcgencmd bootloader_version
2023/01/11 17:40:52
version 8ba17717fbcedd4c3b6d4bce7e50c7af4155cba9 (release)
timestamp 1673458852
update-time 0
capabilities 0x0000007f

I’ll try updating the bootloader later. Thanks for having a look!

you are using uboot bootloader.

003582.722: brfs: File read: /mfs/sd/bcm2711-rpi-cm4.dtb
003618.343: brfs: File read: /mfs/sd/config.txt
003714.240: brfs: File read: /mfs/sd/armstub8-gic.bin
003905.595: brfs: File read: /mfs/sd/u-boot-rpi4.bin

unfortunately there is a “small” issue. NixOS using the u-boot type do not copy the overlays to the /boot directory(ok, copy just a base one, this is a NixOS limitation not the u-boot one), and the overlays need to be merged with the base overlay (like I did it in the old repo).

I moved to the nixos-raspberrypi generational bootloader since it helps me with the booting CM4 from the NVMe, and also allows to boot CM5 (uboot and mainline kernel still lack support of CM5). See the example flake for some hints.

The boot.loader.raspberryPi.bootloader = “kernel” option just create a native RPi boot process: Boot ROM –> bootcode.bin –> start.elf –> Linux Kernel

  1. Can you please download the test images (from link I shared) and try if there is a screen?
  2. I can port changes for the u-boot process - but it won’t be future proof ((-; [hint: if U upgrade your uConsole with the HG board you will be forced to use SD Card to place the /boot loader)
  3. U-boot is still not supported on RPi5/CM5, mainline kernel lack support (mostly to not-open-documentation available and binary blobs), UEFI is… let’s say limited.

I need to rethink the uboot support, but not before the next week…

1), yes, the display works with the test image
2) I am not overly attached to u-boot, is it possible switch while keeping the existing system? Changing to the bootloader to kernel, doesn’t seem to make any difference.. And oh my! I wasn’t aware of the HG board! And I really wanted a way to have NVME instead of the fragile SD card, thanks for sharing this!

Edit: actually, I might just restart from scratch using the kernel bootloader, I was going to move to a new card at some point anyway.

  1. it depends. if you updated to NixOS-raspberrypi (as I used in the images/example) - you can just add boot.loader.raspberryPi.bootloader = "kernel" to your config. By default nixes-raspberry uses bootloader = “uboot” for RPi4/CM4. you will only have to cleanup the leftovers.

aah… it’s a great idea to move to the kernel-type. it’s also support multiple generations - but lack the “boot menu” - it’s done by editing the config.txt and change one line… (os_prefix=nixos/…)

one funny advantage of new generational kernel BL is that now the system can boot whatever you use CM4/CM5.

@johndoe another thing: the gamepad keys don’t seem to work (CM4), tried xev, and pressing the keys don’t produce any events.

I guess loosing the boot menu is not a hue issue since, the display is not on at that time, I don’t think the keyboard worked either, so it was impossible to select a different boot option anyway.

Thanks for porting all these things to 25.11! It’s a huge help to have these nixos modules, thanks for your work!

I need to look why the YXBA keys are not registered… maybe we need additional tweaks to enable it.

remove the SDCard, look at the firmware partition, look at the nixos/ directory…

change in config.txt: os_prefix=nixos/default/ 
to os_prefix=nixos/56-default/ [or what's appropriate]

I know, it’s not great solution, but we need to live with it for now. ((-;

-j.

1 Like
  1. there are xev and wev for x11 and wayland
  2. non of them register gamepad buttons, I recommend to use online gamepad test in browser, there are also some utils that could do it without browser, but I didn’t like them.

ok, got it ((-;

the gamepad keys are linked to /dev/input/js0 (joystick not the keyboard). just run jstest.gtk or similar to test the keys… ((-;

-j.

1 Like

Thanks both! Of what I forgot to mention is that first the gamepad buttons didn’t work in RetroArch, and only after that I tried testing it with xev. I’ll try to look around, maybe RetroArch needs some additional config to make the gamepad buttons work.

you kinda have combination of keyboard arrows + gamepad buttons in a single control scheme.

you can flash QMK keyboard firmware and it has “gamepad layer / mode” where keyboard arrows behave as gamepad plus.

Ok, I totally forgot that in the settings I just have to remap the buttons, and it works even in wayland! It’s m fault, sorry for the false alert!

just curiosity - what is the advantage of QMK firmware regarding the uConsole? I’m happy with the factory firmware… (but not happy that it is a binary blob…)

you can have layers (working gamepad), I do not like it, i found it ‘sluggish’, but seems people like it.

it’s not, you can modify and recompile it with arduino studio: uConsole/Code/uconsole_keyboard at master · clockworkpi/uConsole · GitHub

and then upload to keyboard by official instruction

trackball movement is much better than with stock firmware on my uconsole. also select+trackball = scroll evemts.

1 Like

i didn’t notice any difference

i kinda prefer fn + scroll on the last version of stock firmware

i never updated stock firmware. factory version was just bad in many aspects.

1 Like

hey, just an quick update. Happy to announce that CM5-uConsole can boot directly from the nvme and ethernet is also available ((-;

remember to enable pciex1 and ethernet using the declarative config.txt ((-;

  hardware.raspberry-pi.config = {
    cm5.base-dt-params = {
      pciex1 = { enable = true; value = "on"; };
      pciex1_gen = { enable = true; value = "3"; };
    };
    cm5.dt-overlays = {
      clockworkpi-uconsole-cm5.params = {
        no_rp1eth.enable = false;
      };
    };
  };
1 Like