SBC on dev@iostream.pl

Cold and Darkness (III)

Sun, 20 Sep 2026 17:15:00 +0200

The third and final episode of the saga about SBC cases and cooling.

ROCK 5T

The latest SBC to find its way into my home is the ROCK 5T — a serious contender in my Kubernetes cluster.

It is based on the Rockchip RK3588, an eight-core SoC combining:

four Cortex-A76 cores,
four Cortex-A55 cores,
a Mali-G610 GPU,
an NPU capable of up to 6 TOPS.

My unit has 16 GB of RAM and a 500 GB NVMe SSD — the latter being entirely my own indulgence.

This configuration should remain useful for years: compiling software, collecting metrics, running heavier cluster workloads, and experimenting with relatively small language models.

The ROCK 5T also provides two HDMI outputs, one HDMI input, DisplayPort over USB-C, dual 2.5 GbE, and two M.2 M-Key slots for NVMe drives.

There is also a standard 40-pin GPIO header, which suggests plenty of other possible uses.

Operating system?

Armbian, obviously.

The ROCK 5T currently has Platinum support there, placing it among the better-supported boards in Armbian’s catalogue.

But first…

…the board needs a case, proper cooling, and a little stress testing.

Power

The power supply must be purchased separately.

And here comes the first surprise: the ROCK 5T does not use ordinary USB-C power.

It accepts 9–20 V DC through a 5.5/2.5 mm barrel connector, with 12 V recommended.

Radxa recommends a supply capable of at least 36 W, which means 12 V / 3 A or more.

The USB-C port handles things such as OTG and DisplayPort, but it does not power the board.

So all those convenient USB-C power supplies already sitting on the shelf?

Not this time.

Apparently the marketing department decided that the purchasing experience would be more complete if several parts of a complete computer had to be bought separately.

CPU Cooling

The CPU fan also has to be purchased separately.

Fortunately, the official active heatsink fits perfectly and requires no improvisation.

Radxa lists active cooling among the official accessories for the board.

So at least this time it is clear what the designer intended.

The Case

The case…

Yes.

You guessed correctly.

That must be purchased separately as well.

I chose the official Radxa metal enclosure.

The product description warned that the case might not provide proper access to the HDMI-IN connector.

Naturally, this sounded disappointing.

When the package arrived, however, the HDMI-IN opening turned out to be perfectly usable.

The GPIO header, on the other hand, was not conveniently accessible.

So the documentation warns about the problem that is not there and forgets to mention the one that is.

One has to admire the consistency.

Assembly

The package contains two thermal pads roughly the size of an M.2 2280 drive.

That makes sense, because the ROCK 5T supports two 2280 NVMe SSDs.

The pad goes onto the SSD before the board is placed inside the case.

Once the case is closed, the pad makes contact with the metal enclosure, effectively turning the case itself into a large heatsink for the drive.

Simple.

Effective.

The case also includes two external Wi-Fi antennas.

The original antennas can therefore be disconnected and replaced with the external ones before the enclosure is closed.

In my case, I removed the Wi-Fi antennas entirely.

This machine has been connected exclusively through Ethernet from the beginning.

When a board provides two 2.5 GbE interfaces, it becomes surprisingly difficult to justify making a cluster node send packets through the air.

Testing

Measurements were taken exactly as in the previous two parts.

Two thermometers.

For the NVMe drive:

sudo nvme smart-log /dev/nvme0 | grep temperature

For the CPU:

armbianmonitor -m

Then the two now-familiar stress tests.

CPU and memory:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

I/O:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

As always, fio writes data to the selected file.

Here, that file is /tmp/fio.test.

Do not casually replace it with a block device unless you intend to begin writing an entirely different article immediately afterward.

Results

Component	`stress-ng`	`fio`
NVMe	39 °C	40 °C
CPU	62.8 °C	55.5 °C

Very good.

The NVMe remains cool, and the CPU stays comfortably below temperatures where thermal throttling would become a concern.

That means this machine can now be used regularly in the cluster in a way that actually reflects its computing power, memory capacity, and storage.

In my case, that means heavier CI/CD workloads, metrics, and everything smaller SBCs would accept only with a very audible sigh.

Series Conclusion

After three episodes, the conclusion is fairly simple:

cooling is not an optional accessory.

On modern high-performance SBCs, it is part of the basic system design.

Without a heatsink, fan, or properly designed enclosure, every board described in this series can reach unpleasant temperatures very quickly under sustained load.

With appropriate cooling, the picture changes completely.

Every machine tested here maintained reasonable temperatures during both CPU stress and intensive NVMe activity.

In several cases, the results were better than I expected.

So the patients survived.

They are doing well.

And they can safely be sent back to work.

If another single-board resident appears in my fortress, this supposedly final trilogy may receive an entirely unplanned fourth episode.

Because everyone always says:

this is definitely my last SBC.

Cold and Darkness (II)

Tue, 15 Sep 2026 15:20:00 +0200

In this episode, two more machines go through the usual treatment:

Raspberry Pi 500+,
Odroid M2.

They are interesting for very different reasons.

One is essentially a complete computer hidden inside a keyboard.

The other is a traditional SBC that still needs a case, cooling, and a little persuasion before it behaves properly under sustained load.

Raspberry Pi 500+

The next machine is the Raspberry Pi 500+.

I bought mine at a very good price, and it turned out to be an excellent purchase.

It comes with:

a mechanical keyboard,
16 GB of RAM,
a factory-installed 256 GB NVMe SSD.

The mechanical keyboard obviously has no effect on CPU performance or temperature.

I simply happen to be a very big fan of mechanical keyboards.

Perhaps there will be an episode about those one day.

That is a threat.

The other two features are considerably more practical.

A proper SSD is a much better place for an operating system than an SD card, and nobody has ever become ill from having too much RAM.

Except perhaps after looking at the invoice.

As mentioned earlier, though, I bought this particular machine at a substantial discount — considerably cheaper than any other bare SBC in my collection with comparable NVMe support.

The Raspberry Pi 500+ is an all-in-one design, with all the electronics enclosed inside the keyboard case.

The result looks a little like a modern, simplified Amiga 500, or one of the classic home computers from the 1980s and 1990s.

That is not accidental.

Raspberry Pi itself described the 500+ as a tribute to the home computers many of us grew up with.

What is less obvious without opening the case is how exactly the cooling has been implemented.

Questions include:

how the CPU is cooled,
where thermal pads are used,
whether additional heatsinks are present,
how the NVMe drive is cooled.

The SSD itself is also something you mostly know about from the specification rather than from direct visual inspection.

Yes, I know.

I could open the case.

Unfortunately, one of the screws appears to have made a personal decision to remain exactly where it is.

And since the machine works perfectly well, for now I am satisfied with knowing that it works perfectly well.

That is, after all, what I bought it for.

Testing

The same tests used earlier for the Orange Pi 5 Plus and the Raspberry Pi 5 in the DeskPi case work perfectly well here.

For the NVMe temperature:

sudo nvme smart-log /dev/nvme0 | grep temperature

For the Raspberry Pi itself:

vcgencmd measure_temp
vcgencmd measure_clock arm
vcgencmd get_throttled

The first command reports CPU temperature.

The second shows the current ARM clock frequency.

The third is especially useful because it reveals whether the system has experienced thermal throttling, undervoltage, or related issues.

The CPU and memory stress test:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

And the I/O test:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

As before, fio writes data to the selected file.

In this example, that file is /tmp/fio.test.

Do not spontaneously replace it with a block device unless ruining the rest of your day is part of the benchmark.

Results

Component	`stress-ng`	`fio`
NVMe	35 °C	31 °C
CPU	47.7 °C	37.8 °C

Compared with the other SBCs tested so far, these results are excellent.

Especially considering that the whole computer is enclosed inside a keyboard.

It looks very much as though the engineers behind the Raspberry Pi 500+ did an exceptionally good job.

One might even say they did their homework.

Although in Poland in 2026, that metaphor now requires a little caution.

Odroid M2

The Odroid M2 arrived with its standard case and cooling fan.

The enclosure is made of plastic, which initially made me wonder whether it would cope well with sustained heat, especially from the NVMe drive.

As it turns out, the design is quite sensible.

The top of the case contains ventilation openings directly around the fan area.

The underside has openings near the NVMe drive.

This strongly suggests that the intended cooling strategy is airflow rather than pressing the SSD against the enclosure through a thermal pad.

So I left it exactly as designed.

Assembly took perhaps three minutes.

Which is always suspicious.

Usually, if assembling an SBC takes only three minutes, it means you forgot something.

Not this time.

Hardkernel itself notes that the Odroid M2 can generate enough heat under sustained CPU and GPU load to require active cooling, which is why a fan is included in the kit. Its speed can be controlled using PWM.

Testing

The tests were identical to the previous ones.

For NVMe temperature:

sudo nvme smart-log /dev/nvme0 | grep temperature

For SoC temperature under Armbian:

armbianmonitor -m

Then:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

and:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

Results

Component	`stress-ng`	`fio`
NVMe	46 °C	50 °C
CPU	61 °C	59.2 °C

Before running the tests, I was slightly concerned that every SBC enclosed in a metal case would outperform the plastic Odroid by a wide margin.

That did not happen.

The CPU remained comfortably below troublesome temperatures, and the NVMe temperature was perfectly reasonable as well.

So plastic does not always mean:

this is going to get hot.

Sometimes it simply means:

someone designed the airflow properly.

To Be Continued

Next time:

Rock 5T.

More metal.

More NVMe.

And more reasons to run stress-ng.

Cold and Darkness

Tue, 08 Sep 2026 11:10:00 +0200

After several weeks of experimenting with various SBCs, the time finally came to provide them with two basic necessities: a proper case and proper cooling.

Neither is always as straightforward as it sounds, so I decided to document the process.

Raspberry Pi 5 and DeskPi

Assembly

For the Raspberry Pi 5, one can buy a DeskPi kit.

Which is exactly what I did.

The word kit is particularly appropriate here, because the box contains:

the case itself,
a fan,
thermal pads,
a multifunction adapter board.

That last item is by far the most interesting part.

It acts as an M.2 NVMe adapter, converts the Raspberry Pi’s micro-HDMI connectors to full-size HDMI, reroutes USB-C power, and adds a proper physical power button.

In other words, it fixes several things one might reasonably wish had been there from the beginning.

DeskPi’s own product description confirms support for M.2 NVMe drives, full-size HDMI through an adapter board, rerouted USB-C, and a power switch.

Assembly is not particularly difficult.

Except for the ribbon cable.

The first step is to throw the manual into the trash.

Unless you own a paper shredder.

In that case, use the shredder.

I envy you.

Trust me: the manual will not help much.

I had already been using an NVMe drive with my Raspberry Pi 5, so I first had to dismantle the existing setup and remove the Pimoroni NVMe Base.

A very good product, incidentally.

Just no longer useful in this particular configuration.

The USB-C and HDMI extension pieces fit without much trouble, and most of the assembly is pleasantly uneventful.

If you do not already have a fan installed, this is a good moment to add one.

Remember the thermal pads.

My Raspberry Pi 5 already had the official active cooler installed, and I decided to keep it because it works perfectly well.

The one thing that deserves disproportionate attention is the PCIe ribbon cable.

Yes, it can physically be inserted in more than one orientation.

No, only one of them is useful.

The final result should look like this:

If it does not, you may spend several enjoyable hours wondering why the Raspberry Pi can no longer see the NVMe drive.

I did.

No, the manual does not clearly explain the ribbon orientation.

Do not retrieve it from the trash.

If the Raspberry Pi already booted from NVMe before moving into the case, there is a good chance it will continue doing so without any additional changes.

That was exactly what happened in my case.

No new config.txt entries.

No bootloader changes.

Nothing.

Null.

Nada.

However, my bootloader had already been configured for NVMe booting beforehand, so a fresh setup may require additional preparation.

Testing

Once everything works and the case is properly assembled, it seems reasonable to perform a few basic stress tests.

I used:

stress-ng,
fio,
nvme-cli.

First:

sudo apt install nvme-cli fio stress-ng

The NVMe drive temperature can be read with:

sudo nvme smart-log /dev/nvme0 | grep temperature

The CPU temperature on Raspberry Pi can be checked with:

vcgencmd measure_temp

The first test applies ten minutes of CPU and memory pressure:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

The second one produces sustained I/O activity:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

A small warning here:

the fio test writes data to the selected file.

In this example that file is /tmp/fio.test, which is intentional.

Do not casually replace it with a block device unless destroying data is part of the experiment.

Results

The NVMe drive peaked at around 50°C.

The CPU reached 73.6°C.

For a Raspberry Pi 5 under sustained load inside a compact case, I consider that perfectly acceptable.

Orange Pi 5 Plus and the GeekPi Case

Assembly

The GeekPi case is a black aluminum enclosure.

It is appropriately ugly.

It is also extremely well suited to the Orange Pi 5 Plus, which is much more important.

The case accommodates an M.2 2280 drive and has a top-mounted fan that moves air across a larger portion of the board rather than cooling only the SoC.

The kit also includes thermal pads and small heatsinks.

Unlike the DeskPi manual, the product page does a reasonably good job of showing where everything belongs.

Progress.

There is, however, one complication:

the fan.

The Orange Pi 5 Plus provides a dedicated two-pin FAN connector using a small JST-style plug, while the fan included with the case terminates in two separate DuPont connectors intended for GPIO pins.

If one simply wants the fan to run continuously, it can be connected to:

+5V,
GND.

This works.

The disadvantages are equally obvious:

the fan runs all the time,
there is no temperature control,
two GPIO header pins are occupied,
even a quiet fan becomes surprisingly noticeable after several hours.

I wanted the board itself to control the fan.

Modifying the Fan Cable

The dedicated Orange Pi fan connector is intended to cooperate with software-controlled fan handling.

On current Linux setups this is typically exposed through the kernel’s pwm-fan mechanism and device-tree configuration. Orange Pi documentation and Armbian discussions show temperature-dependent fan levels rather than a simple permanently powered connection.

That sounded much better.

I bought a handful of inexpensive 1.25 mm JST pigtails and prepared to modify the cable.

Before soldering anything, I checked the connector electrically with a multimeter.

This is highly recommended.

Do not trust wire colors alone.

Do not trust random diagrams found in image search.

Do not trust yourself after midnight.

I connected a JST pigtail to the FAN header, powered on the Orange Pi, and observed the behavior while increasing CPU temperature with stress-ng.

The test confirmed that the dedicated connector was being controlled according to temperature.

With that established, the rest was simple:

cut off the DuPont connectors,
strip roughly one centimeter of insulation from the fan wires,
strip the JST pigtail wires,
slide heat-shrink tubing onto the wires before soldering,
solder the matching wires,
move the heat-shrink tubing over the joints,
gently heat it until it contracts.

The third item deserves special emphasis.

Most people remember heat-shrink tubing immediately after finishing the solder joint.

This is one of the traditional stages of electronics education.

Testing

After carefully assembling the case again, it was time for another round of tests.

First, the tools:

sudo apt install nvme-cli fio stress-ng

The NVMe temperature:

sudo nvme smart-log /dev/nvme0 | grep temperature

For the Orange Pi under Armbian, system temperature can conveniently be monitored with:

armbianmonitor -m

The output refreshes every few seconds and includes the SoC temperature.

The same stress tests can then be repeated:

stress-ng \
 --cpu 0 \
 --vm 4 \
 --vm-bytes 60% \
 --timeout 10m \
 --metrics-brief

and:

fio \
 --name=nvme-test \
 --filename=/tmp/fio.test \
 --size=4G \
 --rw=readwrite \
 --bs=1M \
 --iodepth=32 \
 --direct=1 \
 --runtime=5m \
 --time_based \
 --group_reporting

Results

The NVMe drive peaked at 44°C.

The CPU briefly reached 68.4°C.

At that point, the fan came alive.

Afterward, the temperature rarely exceeded roughly 65°C under the same workload.

That is exactly the kind of behavior I wanted: silent when cooling is unnecessary, audible only when the board actually needs help.

And, most importantly, controlled by the SBC rather than permanently wired to five volts like a tiny desk fan from 1997.

To Be Continued

Two boards down.

Several still waiting.

In the next part:

Odroid M2,
Raspberry Pi 500+.

One of them has a perfectly reasonable case.

The other has opinions.