Arduino Uno Q

[geerlingguy]

Basic information

• Board URL (official): https://www.arduino.cc/product-uno-q
• Board purchased from: Arduino store
• Board purchase date: October 7, 2025
• Board specs (as tested): 2GB RAM / 16 GB eMMC
• Board price (as tested): $44

Linux/system information

# output of `screenfetch`
         _,met$$$$$gg.           arduino@uno-q
      ,g$$$$$$$$$$$$$$$P.        OS: Debian 
    ,g$$P""       """Y$$.".      Kernel: aarch64 Linux 6.16.0-geffa8626771a
   ,$$P'              `$$$.      Uptime: 9m
  ',$$P       ,ggs.     `$$b:    Packages: 910
  `d$$'     ,$P"'   .    $$$     Shell: bash 5.2.37
   $$P      d$'     ,    $$P     Resolution: 1920x1080
   $$:      $$.   -    ,d$$'     DE: Xfce
   $$\;      Y$b._   _,d$P'      WM: Xfwm4
   Y$$.    `.`"Y$$$$P"'          WM Theme: Adwaita
   `$$b      "-.__               GTK Theme: Adwaita-dark [GTK2]
    `Y$$                         Icon Theme: Tango
     `Y$$.                       Font: Sans 10
       `$$b.                     Disk: 7.2G / 15G (54%)
         `Y$$b.                  CPU: Qualcomm Kryo-V2 @ 4x 2.016GHz
            `"Y$b._              GPU: 
                `""""            RAM: 639MiB / 1741MiB

# output of `uname -a`
Linux uno-q 6.16.0-geffa8626771a #1 SMP PREEMPT Wed Aug  6 14:24:25 UTC 2025 aarch64 GNU/Linux

Benchmark results

CPU

• Geekbench 6: (187 single / 530 multi - https://browser.geekbench.com/v6/cpu/14705280/)
• 9.597 Gflops at 3.5W, for 2.74 Gflops/W (geerlingguy/top500-benchmark HPL result)

Power

• Idle power draw (at wall): 0.5 W
• Maximum simulated power draw (stress-ng --matrix 0): 1.9 W
• During Geekbench multicore benchmark: 2.5 W
• During top500 HPL benchmark: 3.5 W

Note: Power measurements taking with Uno Q plugged directly into USB-C power adapter, using SSH to access the Uno Q via WiFi. When used as a desktop, with an external USB-C docking station, the full setup used 4-5W more than when plugged in directly.

Disk

Built-in eMMC (Kingston MW2816)

Benchmark	Result
iozone 4K random read	11.42 MB/s
iozone 4K random write	3.43 MB/s
iozone 1M random read	211.33 MB/s
iozone 1M random write	40.12 MB/s
iozone 1M sequential read	208.89 MB/s
iozone 1M sequential write	80.52 MB/s

Network

iperf3 results over WiFi:

• iperf3 -c $SERVER_IP: 277 Mbps
• iperf3 -c $SERVER_IP --reverse: 174 Mbps
• iperf3 -c $SERVER_IP --bidir: 217 Mbps up, 65 Mbps down

GPU

glmark2

glmark2-es2 results:

=======================================================
    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      freedreno
    GL_RENDERER:    FD702
    GL_VERSION:     OpenGL ES 3.1 Mesa 25.1.0-1qcom1
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 379 FrameTime: 2.643 ms
[build] use-vbo=true: FPS: 419 FrameTime: 2.389 ms
[texture] texture-filter=nearest: FPS: 401 FrameTime: 2.496 ms
[texture] texture-filter=linear: FPS: 399 FrameTime: 2.509 ms
[texture] texture-filter=mipmap: FPS: 396 FrameTime: 2.531 ms
[shading] shading=gouraud: FPS: 364 FrameTime: 2.751 ms
[shading] shading=blinn-phong-inf: FPS: 351 FrameTime: 2.850 ms
[shading] shading=phong: FPS: 317 FrameTime: 3.161 ms
[shading] shading=cel: FPS: 305 FrameTime: 3.280 ms
[bump] bump-render=high-poly: FPS: 275 FrameTime: 3.639 ms
[bump] bump-render=normals: FPS: 416 FrameTime: 2.409 ms
[bump] bump-render=height: FPS: 381 FrameTime: 2.625 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 247 FrameTime: 4.049 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 143 FrameTime: 7.013 ms
[pulsar] light=false:quads=5:texture=false: FPS: 402 FrameTime: 2.490 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 152 FrameTime: 6.618 ms
[desktop] effect=shadow:windows=4: FPS: 228 FrameTime: 4.387 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 140 FrameTime: 7.148 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 147 FrameTime: 6.839 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 194 FrameTime: 5.170 ms
[ideas] speed=duration: FPS: 305 FrameTime: 3.287 ms
[jellyfish] <default>: FPS: 229 FrameTime: 4.377 ms
[terrain] <default>: FPS: 32 FrameTime: 31.668 ms
[shadow] <default>: FPS: 217 FrameTime: 4.618 ms
[refract] <default>: FPS: 62 FrameTime: 16.336 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 366 FrameTime: 2.736 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 311 FrameTime: 3.218 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 366 FrameTime: 2.739 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 345 FrameTime: 2.900 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 308 FrameTime: 3.249 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 342 FrameTime: 2.926 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 345 FrameTime: 2.905 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 326 FrameTime: 3.069 ms
=======================================================
                                  glmark2 Score: 290 
=======================================================

vkmark

vkmark results:

MESA: error: DRM_IOCTL_VIRTGPU_GET_CAPS failed with Bad file descriptor
MESA: error: DRM_IOCTL_VIRTGPU_CONTEXT_INIT failed with Bad file descriptor, continuing without context...
MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with Bad file descriptor
MESA: error: Failed to create virtgpu AddressSpaceStream
MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with Bad file descriptor
MESA: error: Failed to create virtgpu AddressSpaceStream
MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with Bad file descriptor
MESA: error: Failed to create virtgpu AddressSpaceStream
MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with Bad file descriptor
MESA: error: Failed to create virtgpu AddressSpaceStream
MESA: error: DRM_VIRTGPU_RESOURCE_CREATE_BLOB failed with Bad file descriptor
MESA: error: Failed to create virtgpu AddressSpaceStream
=======================================================
    vkmark 2025.01
=======================================================
    Vendor ID:      0x5143
    Device ID:      0x7000200
    Device Name:    Turnip Adreno (TM) 702
    Driver Version: 104861696
    Device UUID:    b437e45a5ddf5c12279db589b9834ecd
=======================================================
[vertex] device-local=true: FPS: 491 FrameTime: 2.037 ms
[vertex] device-local=false: FPS: 494 FrameTime: 2.024 ms
[texture] anisotropy=0: FPS: 442 FrameTime: 2.262 ms
[texture] anisotropy=16: FPS: 435 FrameTime: 2.299 ms
[shading] shading=gouraud: FPS: 408 FrameTime: 2.451 ms
[shading] shading=blinn-phong-inf: FPS: 410 FrameTime: 2.439 ms
[shading] shading=phong: FPS: 355 FrameTime: 2.817 ms
[shading] shading=cel: FPS: 336 FrameTime: 2.976 ms
[effect2d] kernel=edge: FPS: 558 FrameTime: 1.792 ms
[effect2d] kernel=blur: FPS: 93 FrameTime: 10.753 ms
[desktop] <default>: FPS: 592 FrameTime: 1.689 ms
[cube] <default>: FPS: 2303 FrameTime: 0.434 ms
[clear] <default>: FPS: 2724 FrameTime: 0.367 ms
=======================================================
                                   vkmark Score: 741
=======================================================

GravityMark

GravityMark results:

1. Download the latest version of GravityMark: https://gravitymark.tellusim.com
2. Run `chmod +x [downloaded_filename].run`
3. Run `sudo ./[downloaded_filename].run` and press `y` to accept the terms.
4. Open the link it prints, and run the Benchmark defaults, changing to 720p resolution and 50,000 asteroids.

Note: These benchmarks require an active display on the device. Not all devices may be able to run glmark2-es2, so in that case, make a note and move on!

AI / LLM Inference

Basic ollama LLM model inference results:

Running benchmark 3 times using model: tinyllama:1.1b

Run	Eval Rate (Tokens/Second)
1	5.34 tokens/s
2	5.50 tokens/s
3	5.50 tokens/s
Average Eval Rate	5.44 tokens/second

System used around 6.1W during inference.

Memory

tinymembench results:

Click to expand memory benchmark result

tinymembench v0.4.10 (simple benchmark for memory throughput and latency)

==========================================================================
== Memory bandwidth tests                                               ==
==                                                                      ==
== Note 1: 1MB = 1000000 bytes                                          ==
== Note 2: Results for 'copy' tests show how many bytes can be          ==
==         copied per second (adding together read and writen           ==
==         bytes would have provided twice higher numbers)              ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
==         to first fetch data into it, and only then write it to the   ==
==         destination (source -> L1 cache, L1 cache -> destination)    ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in    ==
==         brackets                                                     ==
==========================================================================

 C copy backwards                                     :   2159.4 MB/s (4.2%)
 C copy backwards (32 byte blocks)                    :   2147.8 MB/s (4.2%)
 C copy backwards (64 byte blocks)                    :   2203.5 MB/s (1.9%)
 C copy                                               :   2212.0 MB/s (1.8%)
 C copy prefetched (32 bytes step)                    :   1171.3 MB/s (1.9%)
 C copy prefetched (64 bytes step)                    :   1268.1 MB/s (0.7%)
 C 2-pass copy                                        :   1310.6 MB/s (0.5%)
 C 2-pass copy prefetched (32 bytes step)             :    937.4 MB/s (1.8%)
 C 2-pass copy prefetched (64 bytes step)             :    858.8 MB/s (1.0%)
 C fill                                               :  11757.8 MB/s (0.4%)
 C fill (shuffle within 16 byte blocks)               :  11748.6 MB/s (0.3%)
 C fill (shuffle within 32 byte blocks)               :  11764.3 MB/s (0.2%)
 C fill (shuffle within 64 byte blocks)               :  11786.0 MB/s (0.3%)
 NEON 64x2 COPY                                       :   2300.0 MB/s (0.4%)
 NEON 64x2x4 COPY                                     :   2297.3 MB/s (0.4%)
 NEON 64x1x4_x2 COPY                                  :   2292.1 MB/s (0.5%)
 NEON 64x2 COPY prefetch x2                           :    380.8 MB/s (0.8%)
 NEON 64x2x4 COPY prefetch x1                         :   2785.0 MB/s (0.9%)
 NEON 64x2 COPY prefetch x1                           :   2783.8 MB/s (0.5%)
 NEON 64x2x4 COPY prefetch x1                         :   2790.5 MB/s (0.6%)
 ---
 standard memcpy                                      :   2225.5 MB/s (0.8%)
 standard memset                                      :  11793.2 MB/s (0.1%)
 ---
 NEON LDP/STP copy                                    :   2268.5 MB/s (0.9%)
 NEON LDP/STP copy pldl2strm (32 bytes step)          :   1090.2 MB/s (1.0%)
 NEON LDP/STP copy pldl2strm (64 bytes step)          :   1275.3 MB/s (0.3%)
 NEON LDP/STP copy pldl1keep (32 bytes step)          :   2715.2 MB/s (0.8%)
 NEON LDP/STP copy pldl1keep (64 bytes step)          :   2732.3 MB/s (0.4%)
 NEON LD1/ST1 copy                                    :   2305.8 MB/s (0.5%)
 NEON STP fill                                        :  11796.4 MB/s (0.9%)
 NEON STNP fill                                       :  11271.1 MB/s (2.0%)
 ARM LDP/STP copy                                     :   2270.0 MB/s (0.6%)
 ARM STP fill                                         :  11796.2 MB/s (0.2%)
 ARM STNP fill                                        :  11260.5 MB/s (2.6%)

==========================================================================
== Framebuffer read tests.                                              ==
==                                                                      ==
== Many ARM devices use a part of the system memory as the framebuffer, ==
== typically mapped as uncached but with write-combining enabled.       ==
== Writes to such framebuffers are quite fast, but reads are much       ==
== slower and very sensitive to the alignment and the selection of      ==
== CPU instructions which are used for accessing memory.                ==
==                                                                      ==
== Many x86 systems allocate the framebuffer in the GPU memory,         ==
== accessible for the CPU via a relatively slow PCI-E bus. Moreover,    ==
== PCI-E is asymmetric and handles reads a lot worse than writes.       ==
==                                                                      ==
== If uncached framebuffer reads are reasonably fast (at least 100 MB/s ==
== or preferably >300 MB/s), then using the shadow framebuffer layer    ==
== is not necessary in Xorg DDX drivers, resulting in a nice overall    ==
== performance improvement. For example, the xf86-video-fbturbo DDX     ==
== uses this trick.                                                     ==
==========================================================================

 NEON LDP/STP copy (from framebuffer)                 :    220.4 MB/s (2.5%)
 NEON LDP/STP 2-pass copy (from framebuffer)          :    198.0 MB/s
 NEON LD1/ST1 copy (from framebuffer)                 :     54.7 MB/s
 NEON LD1/ST1 2-pass copy (from framebuffer)          :     52.6 MB/s
 ARM LDP/STP copy (from framebuffer)                  :    108.8 MB/s
 ARM LDP/STP 2-pass copy (from framebuffer)           :    103.6 MB/s

==========================================================================
== Memory latency test                                                  ==
==                                                                      ==
== Average time is measured for random memory accesses in the buffers   ==
== of different sizes. The larger is the buffer, the more significant   ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM      ==
== accesses. For extremely large buffer sizes we are expecting to see   ==
== page table walk with several requests to SDRAM for almost every      ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest).                                         ==
==                                                                      ==
== Note 1: All the numbers are representing extra time, which needs to  ==
==         be added to L1 cache latency. The cycle timings for L1 cache ==
==         latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
==         two independent memory accesses at a time. In the case if    ==
==         the memory subsystem can't handle multiple outstanding       ==
==         requests, dual random read has the same timings as two       ==
==         single reads performed one after another.                    ==
==========================================================================

block size : single random read / dual random read, [MADV_NOHUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.0 ns          /     0.0 ns 
     32768 :    0.0 ns          /     0.0 ns 
     65536 :    3.5 ns          /     5.8 ns 
    131072 :    5.3 ns          /     8.1 ns 
    262144 :    6.2 ns          /     9.1 ns 
    524288 :    8.1 ns          /    11.5 ns 
   1048576 :   89.8 ns          /   137.7 ns 
   2097152 :  134.2 ns          /   176.4 ns 
   4194304 :  160.6 ns          /   196.2 ns 
   8388608 :  171.7 ns          /   200.1 ns 
  16777216 :  175.5 ns          /   204.6 ns 
  33554432 :  190.4 ns          /   209.1 ns 
  67108864 :  196.1 ns          /   214.1 ns 

block size : single random read / dual random read, [MADV_HUGEPAGE]
      1024 :    0.0 ns          /     0.0 ns 
      2048 :    0.0 ns          /     0.0 ns 
      4096 :    0.0 ns          /     0.0 ns 
      8192 :    0.0 ns          /     0.0 ns 
     16384 :    0.0 ns          /     0.0 ns 
     32768 :    0.0 ns          /     0.0 ns 
     65536 :    3.5 ns          /     5.7 ns 
    131072 :    5.3 ns          /     8.2 ns 
    262144 :    6.2 ns          /     9.1 ns 
    524288 :    8.2 ns          /    11.9 ns 
   1048576 :   91.7 ns          /   139.5 ns 
   2097152 :  135.9 ns          /   178.3 ns 
   4194304 :  157.7 ns          /   191.9 ns 
   8388608 :  168.3 ns          /   194.3 ns 
  16777216 :  171.2 ns          /   197.7 ns 
  33554432 :  176.5 ns          /   198.3 ns 
  67108864 :  177.8 ns          /   198.7 ns 

Core to Core Memory Latency

sbc-bench results

Run sbc-bench and paste a link to the results here:

wget https://raw.githubusercontent.com/ThomasKaiser/sbc-bench/master/sbc-bench.sh
sudo /bin/bash ./sbc-bench.sh -r

Phoronix Test Suite

Results from pi-general-benchmark.sh:

• pts/encode-mp3: 37.043 sec
• pts/x264 4K: TODO fps
• pts/x264 1080p: TODO fps
• pts/phpbench: 107127
• pts/build-linux-kernel (defconfig): TODO sec

[geerlingguy]

Geekbench fails during multi-core tests. Maybe cooling or power delivery? Need to check thermals.

    [10.0.2.223] nested   Running Horizon Detection
    [10.0.2.223] nested   Running Object Remover
    [10.0.2.223] nested   Running HDR
    [10.0.2.223] nested   Running Photo Filter
    [10.0.2.223] nested Error: executed 0 commands
    Starting nested operation: tasks/geekbench.py | Print Geekbench result 

Top500 HPL compilation failed as well:

    [10.0.2.223] nested         gfortran: fatal error: Killed signal terminated program f951
    [10.0.2.223] nested         compilation terminated.

Then I ran out of disk space testing Kernel compilation and Ollama, heh:

Timed Linux Kernel Compilation 6.15:
    pts/build-linux-kernel-1.17.1 [Build: defconfig]
    Test 1 of 1
    Estimated Trial Run Count:    3                      
    Estimated Time To Completion: 23 Minutes [06:13 UTC] 
        Running Pre-Test Script @ 05:50:58
        Started Run 1 @ 05:52:42
        The test quit with a non-zero exit status.
        Running Interim Test Script @ 06:44:34
        Started Run 2 @ 06:45:07
        The test quit with a non-zero exit status.
        Running Interim Test Script @ 07:36:27
        Started Run 3 @ 07:36:53
        The test quit with a non-zero exit status.
        E: net/sched/sch_api.c:2525:1: fatal error: closing dependency file net/sched/.sch_api.o.d: No space left on device
        Running Post-Test Script @ 08:28:14
...
tar: lib/ollama/cuda_v13: Cannot mkdir: No space left on device

And indeed, the 9.3 GB of available space is full:

/dev/mmcblk0p72  9.3G  9.3G     0 100% /

[geerlingguy]

Ah, deepseek r1:1.5b is too big...

$ ollama run deepseek-r1:1.5b
Error: 500 Internal Server Error: model requires more system memory (1.5 GiB) than is available (1.0 GiB)

Trying with tinyllama instead.

[geerlingguy]

I've tried Geekbench a few more times, with and without supplemental cooling (Noctua fan directly above), and it always locks up after printing Running Photo Filter.

I know on a couple other systems (especially overclocked), the multicore tests would sometimes fail when NEON stuff was hammered by Geekbench. Maybe it'd be more stable at a lower clock? Not sure.

Here is power usage with spikes from the HPL top500 benchmark, and then the last spike from stress-ng on all cores:

Idle power draw around 2.9W (that is with the LED matrix doing the default heartbeat pulse thing).

[geerlingguy]

Phoronix gives:

[Performance Tip] CPUFreq Boost support is disabled on this system.
Enabling boost should allow the CPU to achieve its rated boost
frequencies.

To change behavior, run:

'echo 1 > /sys/devices/system/cpu/cpufreq/boost'

However, the SoC gets up to 63-65°C externally (as read through my thermal camera), without boost, so I'd be cautious doing that without extra cooling.

[geerlingguy]

Still can't get Linux kernel compile to work, either. Not 100% sure if it's disk space or some other error, but I might see about running off an external USB drive at some point:

Timed Linux Kernel Compilation 6.15:
    pts/build-linux-kernel-1.17.1 [Build: defconfig]
    Test 1 of 1
    Estimated Trial Run Count:    3                      
    Estimated Time To Completion: 23 Minutes [20:33 UTC] 
        Running Pre-Test Script @ 20:11:02
        Started Run 1 @ 20:12:42
        The test quit with a non-zero exit status.
        Running Interim Test Script @ 23:10:16
        Started Run 2 @ 23:10:41
        The test quit with a non-zero exit status.
        Running Interim Test Script @ 02:10:46
        Started Run 3 @ 02:11:09
        The test quit with a non-zero exit status.
        E: drivers/phy/rockchip/phy-rockchip-inno-hdmi.mod.c:25:1: fatal error: closing dependency file drivers/phy/rockchip/.phy-rockchip-inno-hdmi.mod.o.d: No space left on device
        Running Post-Test Script @ 05:13:33

[geerlingguy]

Testing the Arduino App Lab out of the box, to see how the MCU and SoC coordinate...

• It boots right into App Lab, but you can quit it if you want.
• App Lab asks you for a WiFi network, then checks for updates.
• The 'Blinking LED' example (that is supposed to toggle an LED every second, through the Python to MCU bridge) didn't work, it compiled, ran the container, but then the LED on the board (Radxa Rock 5 model B #3) just turned on and didn't blink at all.
• The Air quality on LED matrix example seemed to work, though when I opened a file in App Lab to edit it, it popped into a console window in Vim, which IMO is not very user friendly! A noob picking up an Arduino the first time will just get stuck in vim and drive themselves mad...
  • On the other hand, for the 0.1% of the population that will end up loving Vim that doesn't already know about it, this is a great way to force them to learn about it haha
• I tried the 'Weather forecast on LED matrix', and for the default city of Turin, it showed sun. I tried switching to 'St. Louis, MO, USA', and got nothing on the matrix. I tried 'Saint Louis', and got clouds, which is correct.
• The first time I booted and App Lab launched, I didn't see any updates available, but the second launch, it showed there were a number of updates, and the only option at that point was to click 'Start update' (no cancel or anything like that)
• One odd thing: I didn't see any way to observe the Arduino MCU console output, just the App Lab console, which seemed to not have serial output from the MCU...? Maybe I'm missing something, but I right-clicked on console, etc. to no effect.

After the App Lab updates complete, I will re-test...

[geerlingguy]

After updating, the new version (0.1.28) is much improved, though not without quirks:

• The Blinking LED example actually works, which is nice
• The code editor is in line, so you click a file, and the editor is there (no more popping vim in a separate window, thankfully)
• There's a Serial Monitor (defaults to 9600 baud)
• Just to run the Blinking LED example, I had to build a Python Docker container that downloaded a couple hundred MB of resources (phew!). Seems like uv and virtual environments would be more efficient, but who am I to say?
• The latest version can also create custom Apps instead of just running the examples.
• Launching a barebones test app with nothing added besides printing 'Hello world' in the Python output takes about 20-30 seconds.

Also, it seems updating from within App Lab seems to update some other bits too, as the power off / startup animations on the LED matrix have changed as well.

Notes on power behavior:

• When I select 'Shut down' in Debian, it shuts down... then immediately boots back up. Not sure why.
• Pressing the 'Power' button on the board when it is booted up and logged in (in the desktop environment) doesn't seem to do anything
• Holding down the 'Power' button for 5 seconds initiates a hard reset

[geerlingguy]

Can't get geekbench6 to complete, as it runs out of memory:

[ 1405.708857] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=user.slice,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-2.scope,task=geekbench_aarch,pid=1080,uid=1000
[ 1405.726956] Out of memory: Killed process 1080 (geekbench_aarch) total-vm:2079180kB, anon-rss:1423560kB, file-rss:312kB, shmem-rss:0kB, UID:1000 pgtables:3100kB oom_score_adj:0

Trying with swap (I had also tried after killing containerd, docker, and lightdm to free up like 40 MB of RAM—that didn't help):

sudo fallocate -l 2G /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Edit: finally worked, with https://browser.geekbench.com/v6/cpu/14705280/