SAIRPi Project - Slackware AI on Raspberry Pi

SAIRPi Jaffaworks™ R&D

SAIRPi Jaffaworks - R&D Hardware Specifications

Many factors and considerations are discussed and scrutinised when selecting hardware, before a final decision is made. It's crucial for optimal performance, compatibility, stability and reliability, and longevity, to determine the best components for each activity and assignment.

Hardware decisions are deliberate, not accidental.

This is why the SAIRPi Project took time in choosing the right hardware and accessories for running Slackware Linux with the Hailo-10H M.2 AI Accelerator Module on a Raspberry Pi 5.

This is the very start of our journey into Edge AI at the SAIRPi Project. We begin that journey by laying down the foundations and building the system with the various the hardware components. We'll explain precisely what they are, and why we're using them.

Raspberry Pi 5 16GB

We were already using this Raspberry Pi 5 16GB as a server (which was computer hardware overkill on a monumental scale 🤓) so it was de-commissioned, replaced, and repurposed as the device to run Slackware Linux for Edge AI development.

Using a Raspberry Pi 5 with 16GB LPDDR4X memory and a Hailo-10H M.3 AI Accelerator Module enables high-performance and very low-latency, that can run edge AI inferences such as LLMs, e.g. Llama and Qwen model families (albeit smaller models), and also vision models. The 16GB RAM provides maximum headroom for simultaneous AI processing and system operations

The 16GB of system RAM on the Raspberry Pi 5 will be beneficial for running complex, large applications and managing larger datasets alongside the AI processes, while the Hailo-10H itself manages its own 8GB of onboard LPDDR4X memory separately and efficiently.

Raspberry Pi 5 16GB GPIO side view

Raspberry Pi 5 16GB HDMI power socket side view

Raspberry Pi 5 Cooler

Over the years, the SAIRPi Project has used, and come to revere, Ice Tower Coolers for the Raspberry Pi devices. Ice Tower Coolers are manufactured by 52Pi and offer the best active air cooling currently available on Raspberry Pi computers. They come in various guises with each offering subtle benefits due to their design.

For the Raspberry Pi 5 16GB, the Ultra Thin ICE Tower Cooler was chosen. We've been using this particular cooler on other Raspberry Pis for well over a year, and it has been formidable in its performance and reliability. This cooler will keep the Raspberry Pi 5 well below 50° Celsius easily.

NB: The caveat with the 52Pi Ultra Thin ICE Tower Cooler is that it can get quite hot if the Raspberry Pi 5 (SoC, etc.) is under load for prolonged periods of time and the fan is not operational. As long as the fan settings (in /boot/config.txt) are set appropriately for the task at hand, its cooling capacity is substantial, more than adequate, and very impressive. Otherwise this cooler will heat up when the fan is not running. Which is a very good indication of its cooling capability and performance of the 5mm copper heat pipes, but it does need the fan to be constantly circulating an airflow through the heat sink fin array in order to keep the temperatures down.

The benefits of 52Pi's Ultra Thin ICE Tower Cooler are that the fan features a 4-Pin JST connector that plugs into the corresponding socket on the Raspberry Pi 5 board and works with the built-in fan management control firmware, facilitating automated speed regulation. The heat sink directly connects with and cools (via thermal pads), not just the SoC but also, the RP1 I/O controller chip, DA9091 power management IC (PMIC), Gigabit Ethernet IC, and onboard wireless/Bluetooth module, by maximising its surface area for heat transfer, ensuring one of the best cooling solutions possible for low-profile thermal performance. Another plus is that the heat sink is fixed (by underside M3 nylon screws) to the Raspberry Pi 5 PCB, so there's no movement, wobble, or segregation of any kind. It's ultimately solid once it's secured in place.

Here are the Raspberry Pi 5 active cooling fan parameters we use at the SAIRPi Project:

file /boot/config.txt [pi5] ## Pi 5 active cooling fan parameters # Cooling fan on | off dtparam=cooling_fan=on # Tepid: 40% fan @ 40'C dtparam=fan_temp0=40000 dtparam=fan_temp0_hyst=3000 dtparam=fan_temp0_speed=100 # Warm: 60% fan @ 45'C dtparam=fan_temp1=45000 dtparam=fan_temp1_hyst=4000 dtparam=fan_temp1_speed=150 # Hot: 80% fan @ 55'C dtparam=fan_temp2=55000 dtparam=fan_temp2_hyst=5000 dtparam=fan_temp2_speed=200 # Very Hot: 100% fan @ 65'C dtparam=fan_temp3=65000 dtparam=fan_temp3_hyst=5000 dtparam=fan_temp3_speed=250

We have found these to be the most consistent and effective settings for our cooling requirements with 52Pi's Ultra Thin ICE Tower Cooler on the Raspberry Pi 5.

Full details of fan PWM settings, temperature thresholds, and temperature hysteresis on the Raspberry Pi 5 can be found within the overlays README file in the /boot/overlays directory, or on the official Raspberry Pi GitHub repository.

M.2 NVMe board HAT for Raspberry Pi 5

Due to the fact that we run large Ice Tower Coolers on all our Raspberry Pi 5 computers at the SAIRPi Project, the Raspberry Pi AI HAT+ 2 was simply never an option for our use-case. So, we needed a bottom HAT NVMe board, with dual M.2 ports, and is PCIe Gen3 capable. After investigating and considering all that were currently available, almost all those on the market right now state they are "PCIe Gen3 compatible" but not all are capable of operating at Gen3 data throughput speeds. Ultimately; long story short, it was not a difficult choice because only one existed that ticked all our boxes.

The PCIe3.0 Switch to dual M.2 HAT for Raspberry Pi 5 from Seeed Studio is the NVMe bottom HAT that we selected. It features an ASMedia ASM2806 PCIe 3.0 switch - which is a high-speed, low-latency, 6-lane, 4-port PCIe Gen3 packet switch IC designed to expand upstream PCIe bandwidth into multiple downstream ports. Meaning, it's capable of delivering up to 8GT/s shared bandwidth via the Raspberry Pi 5's PCIe interface.

Unfortunately for contemporary boards, almost everything else available at this time uses ASMedia ASM1182e/ASM1184e chipsets which is PCIe Gen2 only. We need the data throughput speed capabilities of PCIe Gen3 which is why the Seeed Studio PCIe3.0 Switch to dual M.2 HAT for Raspberry Pi 5 was chosen. It is the only option that matches our criteria.

Seeed Studio PCIe3.0 Switch to dual M.2 HAT for Raspberry Pi 5

With two M.2 ports, our M.2 NVMe SSD which contains the Slackware Linux operating system will be connected to M.2 M-KEY 1 port, and the Hailo-10H M.2 AI Accelerator Module will be connected to M.2 M-KEY 2 port. This is the logical order of things. With regards to boot order, M.2 M-KEY 1 port takes precedence over M.2 M-KEY 2 port when two bootable NVMe devices are detected. However, we'll only be using one bootable NVMe device. We are aware that during operation, because the Raspberry Pi 5 has a single PCIe 2.0/3.0 x1 lane, the available bandwidth is shared between both M.2 slots via the onboard ASMedia ASM2806 PCIe 3.0 switch. Therefore, simultaneous access to both M.2 devices will result in divided bandwidth speeds.

" But... but... but... PCIe Gen3 on the Raspberry Pi 5 is experimental! " you might be correctly saying, or thinking, right now.

The SAIRPi Project isn't concerned or deterred by PCIe Gen3 being experimental on the Raspberry Pi 5, because the majority of the work we do with Slackware Linux on Raspberry Pi computers is experimental. Plus we've been using PCIe Gen3 on the Raspberry Pi 5 throughout. 😁

NVMe M.2 SSD

When it comes to SSD storage devices, we choose Samsung. For well over a decade we have used Samsung SSD storage with 3D V-NAND technology which has proven to be unmatched in consistency and unparalleled in stability. They might not be the fastest SSD available, or the cheapest, but what you get for your money is peerless, constant reliability and persistent operations.

The Samsung 980 PRO NVMe M.2 SSD 1TB is what we'll be installing. It's a high-performance, PCIe 4.0 NVMe SSD, that remains a top-tier choice for the SAIRPi Project, and many other [power] users around the world. The Samsung 980 Pro 1TB SSD has a PCIe Gen 4.0 x4, NVMe 1.3c interface with an M.2 (2280) form factor, featuring V-NAND 3-bit TLC flash memory, 1GB LPDDR4 DRAM cache, and an Elpis controller that's optimised for PCIe 4.0 - that's backwards compatible with PCIe Gen3 and will quite happily run at these speeds. Boasting TurboWrite 2.0, it uses a 114GB SLC buffer (6GB static + 108GB dynamic) to maintain high speeds for large file transfers. This SSD also features a nickel coating on the controller and a heat spreader label on top of it to prevent thermal throttling.

Samsung 980 Pro 1TB SSD NVMe 1.3c PCIe Gen 4.0 x4

Where Samsung differs from most other SSD manufacturers and suppliers is vertical integration. Samsung’s vertical integration is essentially the farm-to-table approach of the technology world. Unlike many other competitors who assemble parts from various different vendors, Samsung designs and manufactures nearly every critical component of their SSD devices in-house. This ensures unified design and synergy, superior reliability, supply chain stability, and an innovation lead. On these levels no other manufacturer can compete with Samsung.

Additionally, while Samsung’s vertical integration ensures the hardware is elite, Samsung Magician Software is hailed as the gold standard because it provides a level of software control and transparency that few competitors can match - but ONLY on Windows systems, and not Linux. Most SSD brands provide a bare-bones toolbox. Samsung integrates everything into an all-in-one interface. Samsung magician Software isn't just an optional utility - it’s a professional-grade management suite that makes a SSD easier to maintain and update firmware, and faster to use, albeit for Windows OS only at this current time.

This isn't an intentional advertisement for Samsung per se, and we're not being paid or rewarded for promoting their hardware - that's for sure. 😏

What we can state and relay is SAIRPi Project experience with Samsung SSD devices, spanning well over a decade, which is nothing short of exemplary. They are the best. They are unrivalled in terms of reliability. Slackware Linux (or any software) surely benefits from running on hardware that is ultimately dependable. That is why we use Samsung SSD storage devices pretty much exclusively.

Hailo-10H M.2 AI Accelerator Module

The Hailo-10H M.2 AI Accelerator Module "Starter Kit" arrives in a neat little box containing; the module, a 20x20x15mm heat sink, 20x20x3mm thermal shims, 20x20x2mm thermal pads, an M2 standoff and 2.5mm screw to secure the module, and a tiny screwdriver.

The Hailo-10H M.2 AI Accelerator Module will be installed on the M.2 M-KEY 2 port on the PCIe3.0 Switch to dual M.2 HAT for Raspberry Pi 5. This AI Accelerator Module features a 40 TOPS NPU and offers local, offline, private, ultra energy efficient, and powerful edge computing, without any reliance on cloud-based data centers. It all looks and sounds phenomenal, mind-blowing, and positively awesome!

Hailo-10H M.2 AI Accelerator Module

We are very keen to get into working with it and anticipate rolling our sleeves up and preparing for some hard work with this Hailo-10H AI Accelerator on Slackware Linux running on a Raspberry Pi 5 16GB. It's going to be a whole new experience, an adventure into the unknown, and great fun!

Hailo-10H heat sink

As soon as we saw the size and type of heat sink that Hailo bundles with the 10H M.2 module, we knew it was not going to suit our overall thermal requirements. So, we have a few M.2 SSD heat sinks laying around and decided to fit one to the Hailo-10H module.

The heat sink we selected is a Xclio Cold-Fish Pro M.2 22x80 Performance Aluminum Passive SSD Cooler. Although it is a double-sided clip design, with four adjustable-height screws, we won't be able to fit the clip into our setup because the SSD and Hailo-10H module are butted up against each other when installed on the Seeed Studio PCIe3.0 Switch to dual M.2 HAT NVMe board. So we'll use thermal pads to affix the heat sink directly to the Hailo-10H module and see if that's enough to secure it in place for the foreseeable future.

Hailo-10H M.2 AI Accelerator Module

Now we needed to test it. So, we fitted the Ultra Thin ICE Tower Cooler to the Raspberry Pi 5, connected the PCIe3.0 Switch to dual M.2 HAT to the Raspberry Pi 5 and installed the Samsung 980 Pro 1TB SSD and Hailo-10H M.2 module, and attached the XClio heat sink to the Hailo-10H module. We booted the device using a SARPi5_64 Installer. We attempted to log in, verified that SSH was accepting connections, which it most certainly was. Then we let it sit for a while...

While testing the Xclio Cold-Fish Pro heat sink attached to the Hailo-10H module, the thermal pads alone (although double-sided adhesive) were not optimal. After 25-30 minutes the heat sink started to detach at the M.2 port end and droop downwards. Incidentally, just running idle and without the Hailo-10H or Raspberry Pi 5 doing any work whatsoever, the XClio heat sink was getting quite warm, but not too hot to touch. So, we stuck some cooking-grade silicone shims underneath the heat sink to match the precise height of the underside standoffs. Now the Hailo-10H heat sink will be secure and not be pulled away from the module due to its significant weight. On that note: to say it's made from aluminium, and looking at its size, it's incredibly heavy for an M.2 SSD heat sink! (It weighed in at 44 grams.) 😆

We'll definitely need to monitor the thermal characteristics of the hardware when we get around to working with it, and possibly revise and/or adjust some elements along the way. 🤔

Note: it's a very tight fit on the dual M.2 Bottom Mounted HAT

With the Hailo-10H and Samsung SSD installed on the PCIe3.0 Switch to dual M.2 HAT for Raspberry Pi 5 board, it is a very tight fit. There's a hair's width between the Hailo-10H and the Samsung SSD once they're installed and the nylon standoffs are actually touching them. However, we manage to fit everything together neatly, without any external pressure or stresses being applied to any of the components.

PCIe3.0 Switch to dual M.2 HAT for Raspberry Pi 5 with Samsung 980 Pro 1TB NVMe SSD and Hailo-10H M.2 AI Accelerator Module with XClio Passive heat sink

We aren't able to fit the mounting bracket on the XClio heat sink - as thin as it is, there's just no space for it on this board. So, we just affixed it using the double-sided thermal conductive adhesive tape that came supplied with the cooler.

NB: the Hailo-10H M.2 module is underneath the XClio heat sink.

Raspberry Pi 5 Enclosure (Case)

Putting the Raspberry Pi 5 test rig into an enclosure may not be the best decision. Especially if/when work needs doing on the hardware; the enclosure will have to be dismantled, and the Raspberry Pi removed, before any work can be done - in most situations. However, after seeing a really cool, hand-made wooden/acrylic "The Maker Matrix" Raspberry Pi 5 case on eBay (made in the UK by Ideas Universe) one was purchased. They are 100mm x 70mm x 100mm (LxWxH), with a 2 inch 240x320 pixel GMT020-02 TFT display screen (SPI driver: ST7789V) with real carbon fibre faceplate, and in Jaffa orange livery. These cases actually look much better in real life than the images show. One of us (mentioning no names - but it should be obvious) couldn't resist the temptation of engaging in a little retail therapy. 🤑 🙄

The Maker Matrix - Raspberry Pi 5 Enclosure

This Raspberry Pi enclosure is inspired in its design and construction, with plenty of space inside. It's a solid product and not flimsy or fragile, nor are there any inklings of cheapness about it. This is clearly a product that has been intuitiively considered, well planned, and put together with great care and attention. It comes with a magnetically attached faceplate (for easy access) which houses the 2 inch TFT screen, LED lighting module, a rear mounted 40mm fan for increased airflow, and perspex side panels with access slots for the GPIO, HMDI and power sockets. The frame is made from birch wood with a 3mm thickness, and the hood (top panel) and faceplate are acrylic with an inlaid carbon fibre panel surrounding the screen. A really great story about this enclosure is that, before it was purchased, we contacted the seller on eBay and asked if it was possible to modify the design in order to accommodate a bottom HAT NVMe board. The seller was very obliging and more than willing to accommodate our request. Consequently, we received a modified and gorgeous looking enclosure that looks more aesthetically pleasing in real life than it does in the eBay photos.

We've made a couple of modifications to the original features of this Raspberry Pi enclosure.

The first modification was removing the LED lighting module from the underside of the inner hood (roof) of the enclosure - because it's not part of our requirements in the grand scheme of the R&D work we'll be doing. Besides that, there's only a certain number of power connectors on the Raspberry Pi 40-pin GPIO and we have a TFT screen, 40mm fan, and DS3231 Real Time Clock (RTC) to install on it. Incidentally, spring is here, summer is on the way, and we don't want to attract any uninvited rogue insects... because it's a computer - not a bug zapper! Although, it may be considered 'cool' by some users to light up your computer hardware like a nightclub - if your taste is "Las Vegas Boulevard" - where nothing says high performance like synchronised RGB disappointment...
🚦 🚥 🚦 🚥 🚦

NB: RGB lighting remains a triumph of aesthetics over engineering. The SAIRPi Project doesn't do LED/RGB lighting whatsoever. We might get into it at some point, when we need a 'visible from space cooling solution' with more photons than airflow, where illumination is doing infinitely more work than the SoC or RP1 chip. 🤣 😂 😁

The second modification was adding a few layers of aluminium foil to the inner base of the enclosure to act as a heat spreader. Knowing how warm the XClio heat sink gets when the system is only idling, we figured some additional heat dissipation would be beneficial. The rear 40mm fan will also assist in reducing thermal build-up inside the enclosure.

We installed the Raspberry Pi 5 into the enclosure and it certainly looks simply gorgeous when it's all together.

Slackware AI Raspberry Pi 5 test rig computer system front view Slackware AI Raspberry Pi 5 test rig computer system GPIO side view
Slackware AI Raspberry Pi 5 test rig computer system rear view Slackware AI Raspberry Pi 5 test rig computer system HDMI side view

We've also installed a Diymore DS3231 Real Time Clock (RTC) Memory Module (I²C interface) and affixed it to the inside roof of the enclosure (where the LED module used to be). This is because we won't be using the RTC that's built-in to the SoC. The DS3231 module is infinitely more accurate than onboard equivalent. We would have installed a DS3234 RTC (SPI) but that interface is occupied by the TFT screen.

We have some plans on what to display on the TFT screen. For now, we'll keep that under wraps. 😎

Installing Slackware Linux and booting the system

After powering on the system and booting it, with the SARPi5_64 Installer already available (i.e. for Slackware AArch64), we installed the Slackware Linux OS. We gave our system the hostname: 'maia'. Once installation was complete we rebooted the Raspberry Pi 5.

After logging in, the first thing we did was set the date. The second thing we did was...

root@maia:~# date Mon Apr 13 13:23:30 BST 2026 root@maia:~# lspci 0001:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30) 0001:01:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01) 0001:02:00.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01) 0001:02:02.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01) 0001:02:06.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01) 0001:02:0e.0 PCI bridge: ASMedia Technology Inc. ASM2806 4-Port PCIe x2 Gen3 Packet Switch (rev 01) 0001:03:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO 0001:06:00.0 Co-processor: Hailo Technologies Ltd. Hailo-10H AI Processor (rev 01) 0002:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30) 0002:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge root@maia:~# lspci | grep -i hailo 0001:06:00.0 Co-processor: Hailo Technologies Ltd. Hailo-10H AI Processor (rev 01) root@maia:~# lspci -tv -[0001:00]---00.0-[01-06]----00.0-[02-06]--+-00.0-[03]----00.0 Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO +-02.0-[04]-- +-06.0-[05]-- \-0e.0-[06]----00.0 Hailo Technologies Ltd. Hailo-10H AI Processor -[0002:00]---00.0-[01]----00.0 Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge root@maia:~# lspci -nn | grep -i hailo 0001:06:00.0 Co-processor [0b40]: Hailo Technologies Ltd. Hailo-10H AI Processor [1e60:45c4] (rev 01) root@maia:~# lspci -k | grep -A3 -i hailo 0001:06:00.0 Co-processor: Hailo Technologies Ltd. Hailo-10H AI Processor (rev 01) Subsystem: Hailo Technologies Ltd. Hailo-10H AI Processor 0002:00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2712 PCIe Bridge (rev 30) Kernel driver in use: pcieport 0002:01:00.0 Ethernet controller: Raspberry Pi Ltd RP1 PCIe 2.0 South Bridge root@maia:~# lspci -vv -s 0001:06:00.0 | grep -E "LnkCap|LnkSta" LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s <1us, L1 <2us LnkSta: Speed 8GT/s, Width x1 (downgraded) LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink- Retimer- 2Retimers- DRS- LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+ root@maia:~# uname -a Linux maia 6.18.21-v8-sarpi5_64 #1 SMP PREEMPT Sat Apr 11 15:17:13 BST 2026 aarch64 GNU/Linux root@maia:~# cat /proc/device-tree/model | tr '\0' '\n' Raspberry Pi 5 Model B Rev 1.1 root@maia:~# cat /proc/cpuinfo | grep Revision Revision : e04171 root@maia:~# free total used free shared buff/cache available Mem: 16580048 261136 16001120 3040 468384 16318912 Swap: 8388592 0 8388592 root@maia:~# _

From this output, everything appears to be in order and very much expected. The dual M.2 NVMe board is being detected correctly and the link speeds are within defined parameters for PCIe Gen3, and even though the ASMedia ASM2806 packet switch can handle a total of x6 lanes of PCIe data it can only use what the host provides, which is x1 lane of data. The packet switch can only forward what it receives from the host Raspberry Pi 5. Both the Samsung SSD and Hailo-10H M.2 NVMe devices are being detected correctly. The system is super quick, responsive, stable, and very predictable. Precisely what we expect and have come to love and know regarding Slackware Linux.

Slackware remains unabridged and peerless, by doing the opposite of what most other Linux distributions are trying to achieve. It strips away abstraction and unnecessary obfuscating layers/automation, and keeps the user in full control 100% of the time. Slackware exposes the operating system directly, without trying to complicate or reinterpret it. Slackware is simple, stable, and reliable. It's the ultimate Linux OS on any and all platforms.

There really is nothing quite like Slackware Linux, and if you're not using it you are missing out! 😉

Further Modifications & Adjustments - 2026-04-15

Having test-ran 'maia' for a few hours, one thing was obvious: the rear intake fan was just TOO LOUD and a major distraction! As with all conventional axial brushless DC fans, their design dictates airflow potential and, more often than not, aeroacoustic noise is a secondary consideration - if at all.

The Matrix Maker enclosure for the Raspberry Pi 5 came fitted with a Winsinn 40mm hydraulic bearing brushless DC-5v fan which are tuned for airflow, not for acoustics, or longevity, or consistency. The airflow is welcome, but the aeroacoustics are certainly not. So, we turned to the one brand name that is renowned for efficient quiet fans, Noctua.

A Noctua NF-A4x10 5V fan was sourced and purchased. It arrives the next day and we promptly install it, replacing the existing fan. We pull the connectors from the 4-pin PWN fan connector on the Noctua NF-A4x10 and are able to easily insert the yellow wire (PWR) and black wire (GND) pins into a 2-pin Dupont connector. Which simply connects to pins 4 (5v PWR) and 6 (GND) on the Raspberry Pi 5 GPIO header. Obviously, this means without any pulse width modulation (PWM) the fan will be running at full speed 100% of the time, but because it's relatively quiet this is not a concern at all.

The differences between the Noctua and Winsinn fans are significant. Basically:

• With the Winsinn 40mm hydraulic bearing brushless DC-5v fan we can expect a lifespan of 35,000 hours maximum (according to the manufacturer) with an airflow of 5–7 CFM that generates 27-35dB(A) aeroacoustic noise, at 5000-7000 RPM (which always varies between units), and a warranty of ... (is there any warranty at all?). 🤔

• With the Noctua NF-A4x10 5V fan, it features SSO2 (premium) bearings which are oil-pressure stabilised and produce minimal vibration and therefore low noise, and we can expect a lifespan of approx. 150,000 hours (according to the manufacturer) with an airflow of 4.83 CFM that generates 19.6 dB(A) aeroacoustic noise, at 4500 RPM - plus it comes with a SIX YEAR warranty (which we voided by modifying the PWM connectors). 😂

The Noctua fan may be 10x the cost of the Winsinn fan, with slightly less airflow potential but almost half the aeroacoustic noise, but the benefits and assurance that comes with Noctua fans is unbeatable. Noctua are burning beeswax candles slowly that emit adequate light, while other fan manufacturers are burning paraffin wax candles rapidly at both ends. In relative terms, according to official specifications, we can expect to run the Noctua NF-A4x10 constantly for 17 years, 1 month, and 5 days, before it starts to exhibit any operational problems. This is why the SAIRPi Project chooses Noctua when it comes to axial brushless DC fans.

Configuring The DS3231 Real Time Clock (RTC) - 2026-04-17

The Raspberry Pi 5 comes equipped with a Real Time Clock (RTC) built-in to the SoC. The onboard RTC has an external 32khz crystal, and is limited by the accuracy of that - typically ±50ppm - according to official Raspberry Pi specs. So, a drift of approx. 4.32 seconds maximum per day, 2.16 minutes per month, and 26.28 minutes per year - and that's reliant on the accuracy of the external crystal. Specific details on design of the Raspberry Pi 5 built-in RTC don't seem to be currently available, So, at a best guess, this would seem to be based on a similar accuracy to the DS1307 RTC controller.

Comparatively, the DS3231 RTC has an internal Temperature Compensated Crystal Oscillator (TCXO) and an accuracy of ±2ppm. So, a drift of roughly 0.17 seconds per day, 5.18 seconds per month, and 63 seconds per year. This is why we prefer to use the DS3231 or DS3232 (I²C) and/or DS3234 (SPI) RTCs over all other alternatives.

We must disable the Raspberry Pi onboard 5 RTC in order to use the DS3231 RTC module instead, and we can do this by entering a parameter in the /boot/config.txt file.

file /boot/config.txt # Disable Pi 5 onboard Real Time Clock [RTC] dtparam=rtc=off

After disabling the built-in onboard RTC on the Raspberry Pi 5 and rebooting, we setup and configure the DS3231 RTC module using the SARPI mini-projects DS3231 installation guide.

Then we reboot once more check out our newly configured DS3231 RTC module.

root@maia:~# dmesg | grep -i rtc [ 0.891609] ds3234 spi0.0: registered as rtc0 root@maia:~# cat /proc/driver/rtc rtc_time : 10:44:02 rtc_date : 2026-04-17 alrm_time : 05:11:08 alrm_date : 2026-04-14 alarm_IRQ : no alrm_pending : no update IRQ enabled : no periodic IRQ enabled : no periodic IRQ frequency : 1 max user IRQ frequency : 64 24hr : yes root@maia:~# ls /dev/rtc* /dev/rtc@ /dev/rtc0 root@maia:~# hwclock -r 2026-04-17 10:44:18.124314+01:00 root@maia:~# hwclock -v hwclock from util-linux 2.42 System Time: 1776419061.646649 Trying to open: /dev/rtc Using the rtc interface to the clock. Last drift adjustment done at 1776122979 seconds after 1969 Last calibration done at 1776122979 seconds after 1969 Hardware clock is on local time Assuming hardware clock is kept in local time. Waiting for clock tick... ioctl(3, RTC_UIE_ON, 0): Invalid argument Waiting in loop for time from /dev/rtc to change ...got clock tick Time read from Hardware Clock: 2026/04/17 10:44:22 Hw clock time : 2026/04/17 10:44:22 = 1776419062 seconds since 1969 Time since last adjustment is 296083 seconds Calculated Hardware Clock drift is 0.000000 seconds 2026-04-17 10:44:21.651687+01:00 root@maia:~# _

All working as expected. 👍

Configuring The TFT Module 240x320 ST7789V GMT020-02 Display

This was the first time we'd used the ST7789V display on the Raspberry Pi 5 at the SAIRPi Project, so it was somewhat of an education into the differences between OLED screens and this one. However, after much trial and error, and testing, we finally managed to get it working. Fundamentally, there's no standard list of instructions or way to wire it up. We found multiple guides and tips on the Internet, but none that full covered what we wanted to do with this screen. So it was a case of cherry picking details from various sources and bringing them together to get the desired result.

Our TFT module is a GMT020-02-7P ver 1.3 (ST7789V chipset) manufacrutred by GoldenMorning Electronic Company Ltd. based in ShenZehn, China. This is how we wired the ST7789V display module to our Raspberry Pi GPIO header.

CS - pin 24 (GPIO8)
DC - pin 22 (GPIO25)
RST - pin 18 (GPIO24)
SDA - pin 19 (GPIO10)
SCL - pin 23 (GPIO11)
VCC - pin 17 (3v3)
GND - pin 20 (Ground)

The SCL, SDA, and CS pins are fixed and must be connected as we have done. The DC and RST pins are flexible. The VCC must be 3v3 (or else the TFT module may be damaged) and GND can go wherever there's an available ground pin. We like to keep wiring for seperate devices relatively close to each other. So, this is why we chose this way to do it. We also connected the TFT wires to a Dupont 10-pin (double 5x2) holder on the Raspberry Pi 5 GPIO end for ease of disconnecting/connecting in future.

root@maia:~# ls /dev/spidev* /dev/spidev0.0 /dev/spidev0.1 root@maia:~# dmesg | grep -Ei 'spi|st7789|fb|drm' [ 0.000000] node 0: [mem 0x0000000000080000-0x000000003fbfffff] [ 0.000000] software IO TLB: mapped [mem 0x00000000fbffc000-0x00000000ffffc000] (64MB) [ 0.419163] brcm-pcie 1000120000.pcie: MEM 0x1f00000000..0x1ffffffffb -> 0x0000000000 [ 0.420372] pci_bus 0002:00: root bus resource [mem 0x1f00000000-0x1ffffffffb] (bus address [0x00000000-0xfffffffb]) [ 0.420394] pci 0002:00:00.0: bridge window [mem 0x1f80000000-0x1fbfffffff] [ 0.529348] pci_bus 0002:00: resource 4 [mem 0x1f00000000-0x1ffffffffb] [ 0.534035] v3d 1002000000.v3d: [drm] Transparent Hugepage support is recommended for optimal performance on this platform! [ 0.537676] [drm] Initialized v3d 1.0.0 for 1002000000.v3d on minor 0 [ 0.541624] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.565242] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.573844] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.582180] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.590508] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.848441] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.857867] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.870371] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.880200] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.901932] vc4-drm axi:gpu: bound 107c580000.hvs (ops vc4_hvs_ops) [ 0.944514] vc4-drm axi:gpu: bound 107c701400.hdmi (ops vc4_hdmi_ops) [ 0.953700] vc4-drm axi:gpu: bound 107c706400.hdmi (ops vc4_hdmi_ops) [ 0.954525] vc4-drm axi:gpu: bound 107c500000.mop (ops vc4_txp_ops) [ 0.954606] vc4-drm axi:gpu: bound 107c501000.moplet (ops vc4_txp_ops) [ 0.954940] vc4-drm axi:gpu: bound 107c410000.pixelvalve (ops vc4_crtc_ops) [ 0.954994] vc4-drm axi:gpu: bound 107c411000.pixelvalve (ops vc4_crtc_ops) [ 0.955924] [drm] Initialized vc4 0.0.0 for axi:gpu on minor 1 [ 0.957775] vc4-drm axi:gpu: [drm] Cannot find any crtc or sizes [ 0.966038] vc4-drm axi:gpu: [drm] Cannot find any crtc or sizes [ 0.970871] vc4-drm axi:gpu: [drm] Cannot find any crtc or sizes [ 10.973622] platform 107d004000.spi: deferred probe pending: platform: wait for supplier /soc@107c000000/pinctrl@7d504100/spi10_cs_gpio1 root@maia:~# lsmod | grep -Ei 'spi|fb|drm' spi_dw_mmio 49152 0 spi_dw 49152 1 spi_dw_mmio root@maia:~# ls -l /dev/fb* ls: cannot access '/dev/fb*': No such file or directory root@maia:~# _

Everything looks good. Because this screen is driven directly over SPI it's not recognised as a standard Linux framebuffer device, so there's no /dev/fb0 or /dev/fb1, etc.

Now we need a Python script to load and store images in the TFT module's internal display memory. We try and test the Raspberry Pi 5 case supplier's recommended scripts and instructions but find them quite complicated and difficult to work with. So we write one, and after a great deal of testing and working through various issues... it eventually works as intended.

Here's the SAIRPi Project's Python script for TFT module 240x320 ST7789V GMT020-02 display if you'd like to download it and use it for your own purposes. The same script is available to download from the SAIRPi Project GitHub repository.

Here's the image that we created and used for testing with the TFT module 240x320 ST7789V display: "SlackPunk". 😁

TFT module 240x320 ST7789V Display Image

With the TFT module display configured and working perfectly, that signals the completion of building the Slackware AI on Raspberry Pi test rig system.

And here it is... in all its resplendent magnificence. 😍

SlackPunk Image on ST7789V TFT Module

We also wrote another python3 script to display the system status on-the-fly. This image was taken during a prolonged kernel build test-run, and the SoC temperature never rose above 42° Celsius with this current setup.

Slackware System Status on ST7789V TFT Module

These python3 scripts for the ST7789V TFT module, and more, are available to download from the SAIRPi Project GitHub repository.

What's Next?

With the hardware and operating system in place, and working perfectly, we can now focus our attention and efforts towards AI on the Edge using Hailo-10H AI Accelerator hardware.

We've realised a few things while building, assembling, and installing hardware/software on the Slackware AI on Raspberry Pi test rig system...

The SAIRPi Project might benefit from a 'How-To' or 'mini-projects' section. If only to document and detail how we do things, deep-dive fashion, in order to inform and assist others in problem-solving, troubleshooting, and/or achieving their goals. The TFT module was particularly tricky to get configured and running properly, and (mainly due to a lack of available instructions on the Internet) we think a guide on how we achieved it will potentially be helpful to others who might be struggling for the same reason(s).

This is certainly something we will give due consideration and serious thought to whether it should be implemented, moving forward.

Back to Top


Updated: 2026-05-09 06:37:40 UTC
Slackware Linux   LF EDGE: Building an Open Source Framework for the Edge
Hailo high-performance AI on the edge   Raspberry Pi Ltd.

Disclaimer: The SAIRPi Project website is for non-commercial and general information purposes only. The content is provided by Penthux.NET. All rights reserved. While we endeavour to keep information up to date and correct, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability or availability with respect to the website or any information, software, products, services, or related content, which is available on the website, for any purpose. Any reliance you place on such information or content is therefore strictly at your own risk. In no event will Penthux.NET be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this website or any of its contents. Through this website you are able to visit other external websites which are not under our control. Penthux.NET has no influence over the nature, accuracy, suitability, or availability of any external content. The inclusion of any external URLs does not necessarily imply a recommendation or endorsement of any content therein. Every effort is made to ensure the SAIRPi Project website remains accessible. However, Penthux.NET takes no responsibility for, and will not be liable for, the SAIRPi Project website being temporarily unavailable due to technical issues beyond our control. SAIRPi Project is in no way affiliated with Slackware Linux, or Hailo Technologies Ltd., or The Linux Foundation, or Raspberry Pi Ltd., or any of their respective members, trustees, partners, or associates. All trademarks are the property of their respective owners.


Decline! Accept!

SAIRPi Project uses cookies and Google Analytics for web traffic metrics.

No personal data is collected or stored by this website.

Please read the SAIRPi Project [ Cookie Policy ] and [ Privacy Policy ] for more details.