Project Description
With Quad SATA HAT[1] you can turn your RPi / RockPi into a nice little NAS. There are some packages[2] for Raspbian/Ubuntu which will allow you to control the disks and the optional fan and OLED display. But what if you want to install Tumbleweed on your box?

Goal for this Hackweek
The goal of this project is to start with a RPi 4 and SATA HAT and end up with a working NAS solution on Tumbleweed. The provided software is only targeting Debian based distros and even in that case the support is not great.
Resources
- https://wiki.radxa.com/DualQuadSATA_HAT
- https://rock.sh/get-rockpi-sata
- https://github.com/baierjan/go-sata-hat
- https://build.opensuse.org/package/show/home:jbaier_cz/golang-github-baierjan-sata-hat
The Hacking
Step 1: OS installation
As I already have some experience with Raspbian, it is trivial to grab a new SD card, extract a fresh new image onto the card, put it in the Pi and just boot the system. After a while I am able to log in to the system via SSH. All good.
Now, it is Tumbleweed time. I headed to our RPi4 documentation, the recommended step is to take the JeOS image and extract it as in previous step. I like it, but I need to tweak it a little bit. Ultimately, I do not want to have SD card present as I want to boot the system from connected SSD disk. So, lets grab the JeOS Tumbleweed image and extract it on a fresh new SSD disk connected via USB-SATA connector.
I removed the SD card, put the SSD disk into the SATA slot and I am trying the boot process. Unfortunately, I am unable to see any new device in the DHCP log. Even more unfortunately, the RPi 4 has microHDMI output and I probably do not have any such cable around (and frankly, I am to lazy to do a thorough search). So it is time for my USB-TTL UART converter, the config.txt should contain enable_uart=1 and it might also help to include console=ttyS0,115200n8 into default grub command line parameters. The pinout for RPi can be easily found, in my case I need to connect pins 6, 8 and 10 (GND, TX, RX). For the actual connection, minicom or screen can be used. I am not happy with the result (I do not see anything).
After some blind laboring, I am able to find out, that the Pi is not able to boot from the SATA HAT because it does not see it. After consulting the documentation (i.e. searching on the official forum), I found out that the HAT needs to be "activated" by setting pins 25 and 26 to HIGH. OK, additional search and I know how to solve the issue. At first, I need to boot from SD card (the previously installed Raspbian will do), and update EEPROM configuration.
```
rpi-eeprom-config --edit
[all] BOOTUART=1 WAKEONGPIO=1 ENABLESELFUPDATE=1 BOOTORDER=0xf14
[config.txt] gpio=25,26=op,dh ```
There are several important settings, BOOT_UART=1 will enable serial console during boot. BOOT_ORDER=0xf14 means try USB (4) first, then SD card (1), then repeat (f) if necessary. In my case the USB boot is the SATA HAT. Another useful mode could be 2 for network boot. The most important part are the last two lines, gpio=25,26=op,dh will set pins 25 and 26 to output mode, driving high. That will enable the HAT after power-on, so it will be able to boot from it.
After this, I can successfully boot into the JeOS first boot configuration. As I have already prepared everything for serial console connection, I can do the setup even without monitor and keyboard attached. I can finish the installation, setup network and ssh server.
Step 2: Fan control
There are two controllable fans, one on the board for CPU and one on top for the hard drives. Both are PWM capable and are controlled through pins 12 and 13. The original code uses Python and RPi.GPIO, however that did not work well for me. I also tried another Python libraries for GPIO pins, but was not able to solve performance issues nicely. For the PWM to work correctly, the controlling frequency needs to be high enough to prevent buzzing noises in an audible spectrum from the fans and neither library was able to provide it. After some extended search, I stumbled upon Go-written library go-rpio which was able to do hardware PWM (instead of slower software emulated) and which was able to achieve the optimal 25kHZ frequency.
I created a simple script which allows to set each fan to any of 5 available levels (0%, 25%, 50%, 75%, 100%) and an auto mode, which will read the current CPU temperature and adapt the fan levels. The thresholds are customizable via environment variables. Provided service file for the fan-control utility can read those overrides and start the auto mode upon boot.
Step 3: OLED display
After some fiddling and reverse engineering, I was able to find out, that I need to reset the display before use; the reset procedure is done by flipping pin 22. The display itself is a standard I2C device and instead of deprecated Adafruit Python library, I used a go-based one. Currently, the display can show current time, CPU temperature and disk use percentage. The path for the disk usage can be customized by environment variable OLED_DU_PATH. The output is rotated by 180° by default, which can be disabled by setting OLED_ROTATE=false.
For the I2C to work correctly the appropriate overlay needs to be activated. Inside config.txt or even better inside extraconfig.txt make sure to include line dtparam=i2c1=on.
Step 4: Push button
Pin 17 is connected to the button on the top panel. I was able to use edge detection on the pin to detect push events and use it to turn on/off the OLED display. Maybe in some later version, this could be customisable and can run an arbitrary command. The important part here is to not only switch the pin into an input mode but also activate the pull-up resistor (the button has inverted control -- i.e. pressing the button will trigger the fall-down edge and transition to low state).
Step 5: Combining all together
I created a common module for shared functions and I have two binaries with a corresponding service file to control the fans and the OLED display. The provided spec file will allow OBS to create an installable package for Tumbleweed. After installation, both services need to be enabled (and started) via systemctl enable --now fan-control sys-oled.
Looking for hackers with the skills:
This project is part of:
Hack Week 23
Activity
Comments
-
about 2 years ago by harrisonbc | Reply
Hi - I have one of these HATs and am happy to help test it out with Tumbleweed
-
about 2 years ago by jbaier_cz | Reply
The first version of the software, which should be able to control fan speed is available in my repository. The documentation is lacking, but the simple
systemctl enable --now fan-controlshould enable the automatic mode.
-
Similar Projects
Build a Single Camera 3D Scanner (Photogrammetry). by lparkin
Description
I want to see how fast I can develop a single-camera (pi camera module v3) rig with a stepper motor controlling a turntable that rotates the model being scanned. The trick here is not to be super fancy with 100's of sensors and data inputs, quite the opposite. I want to see how accurate I can scan objects into 3D-printable models using only a camera and as many fixed and known parameters as possible.
Speed to be augmented with agentic AI coding companion. As it stands, I have a 3D printer, pretty much all the electronics I need.
Goals
- Design and print working/workable camera rig
- Design and print working/workable turntable (considering printing my own cylinder-style bearings as well)
- Assemble rig components into MVP assembly
- Develop application that can hook into existing tools, or leverage a library like openCV, to process 2D images into a 3D model.
- Iterate until models are good enough to 3D print.
Resources
- https://www.instructables.com/3D-scanning-Photogrammetry-with-a-rotating-platfor/
- https://www.instructables.com/3d-Scan-Anything-Using-Just-a-Camera/
- https://www.instructables.com/Build-a-DIY-Desktop-3d-Scanner-With-Infinite-Resol/
- https://www.instructables.com/3D-Laser-Scanning-DIY/
Tumbleweed on Mars-CM (RISC-V board) by ph03nix
RISC-V is awesome, Tumbleweed is awesome, chocolate cake is awesome. I'm planning to combine all of them in one project.
Project Description
I recently purchased a MILK-V Mars CM and managed to setup it up already using Debian Linux. My project for this Hackweek is to see how far I can get to run Tumbleweed on this compute module board.
Goal for this Hackweek
- Run Tumbleweed on the Compute Module
Resources
- http://milkv.io/mars-cm
- https://en.opensuse.org/HCL:VisionFive2
OpenRC in openSUSE by jimedrand
Description
I have been using openSUSE for 3 years and I am just seen the systemd as init system. Actually, I want to make openSUSE with supports to another init such as OpenRC init that I'm always using it in another distros, and I was think, "what about if I'm including OpenRC init in openSUSE and give anyone as second way for them who don't want to use systemd?", and I'm curious about that. That's why I'm opening these.
Goals
Giving OpenRC support for Tumbleweed first, then going in Leap in future if possible.
A CLI for Harvester by mohamed.belgaied
Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.
Project Description
Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as:
harvester vm create my-vm --count 5
to create 5 VMs named my-vm-01 to my-vm-05.
Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.
Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli
Done in previous Hackweeks
- Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
- Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE
Goal for this Hackweek
The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.
Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it
Issue list is here: https://github.com/belgaied2/harvester-cli/issues
Resources
The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact).
Welcome contributions are:
- Testing it and creating issues
- Documentation
- Go code improvement
What you might learn
Harvester CLI might be interesting to you if you want to learn more about:
- GitHub Actions
- Harvester as a SUSE Product
- Go programming language
- Kubernetes API
- Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)
Kudos aka openSUSE Recognition Platform by lkocman
Description
Relevant blog post at news-o-o
I started the Kudos application shortly after Leap 16.0 to create a simple, friendly way to recognize people for their work and contributions to openSUSE. There’s so much more to our community than just submitting requests in OBS or gitea we have translations (not only in Weblate), wiki edits, forum and social media moderation, infrastructure maintenance, booth participation, talks, manual testing, openQA test suites, and more!
Goals
Kudos under github.com/openSUSE/kudos with build previews aka netlify
Have a kudos.opensuse.org instance running in production
Build an easy-to-contribute recognition platform for the openSUSE community a place where everyone can send and receive appreciation for their work, across all areas of contribution.
In the future, we could even explore reward options such as vouchers for t-shirts or other community swag, small tokens of appreciation to make recognition more tangible.
Resources
(Do not create new badge requests during hackweek, unless you'll make the badge during hackweek)
- Source code: openSUSE/kudos
- Badges: openSUSE/kudos-badges
- Issue tracker: kudos/issues
Create a page with all devel:languages:perl packages and their versions by tinita
Description
Perl projects now live in git: https://src.opensuse.org/perl
It would be useful to have an easy way to check which version of which perl module is in devel:languages:perl. Also we have meta overrides and patches for various modules, and it would be good to have them at a central place, so it is easier to lookup, and we can share with other vendors.
I did some initial data dump here a while ago: https://github.com/perlpunk/cpan-meta
But I never had the time to automate this.
I can also use the data to check if there are necessary updates (currently it uses data from download.opensuse.org, so there is some delay and it depends on building).
Goals
- Have a script that updates a central repository (e.g.
https://src.opensuse.org/perl/_metadata) with metadata by looking at https://src.opensuse.org/perl/_ObsPrj (check if there are any changes from the last run) - Create a HTML page with the list of packages (use Javascript and some table library to make it easily searchable)
Resources
Results
Day 1
- First part of the code which retrieves data from https://src.opensuse.org/perl/_ObsPrj with submodules and creates a YAML and a JSON file.
- Repo: https://github.com/perlpunk/opensuse-perl-meta
- Also a first version of the HTML is live: https://perlpunk.github.io/opensuse-perl-meta/
Day 2
- HTML Page has now links to src.opensuse.org and the date of the last update, plus a short info at the top
- Code is now 100% covered by tests: https://app.codecov.io/gh/perlpunk/opensuse-perl-meta
- I used the modern perl
classfeature, which makes perl classes even nicer and shorter. See example - Tests
- I tried out the mocking feature of the modern Test2::V0 library which provides call tracking. See example
- I tried out comparing data structures with the new Test2::V0 library. It let's you compare parts of the structure with the
likefunction, which only compares the date that is mentioned in the expected data. example
Day 3
- Added various things to the table
- Dependencies column
- Show popup with info for cpanspec, patches and dependencies
- Added last date / commit to the data export.
Plan: With the added date / commit we can now daily check _ObsPrj for changes and only fetch the data for changed packages.
Day 4
Switch software-o-o to store repomd in a database by hennevogel
Description
The openSUSE Software portal is a web app to explore binary packages of openSUSE distributions. Kind of like an package manager / app store.
https://software.opensuse.org/
This app has been around forever (August 2007) and it's architecture is a bit brittle. It acts as a frontend to the OBS distributions and published binary search APIs, calculates and caches a lot of stuff in memory and needs code changes nearly every openSUSE release to keep up.
As you can imagine, it's a heavy user of the OBS API, especially when caches are cold.
Goals
I want to change the app to cache repomod data in a (postgres) database structure
- Distributions have many Repositories
- Repositories have many Packages
- Packages have many Patches
The UI workflows will be as following
- As an admin I setup Distribution and it's repositories
- As an admin I sync all repositories repomd files into to the database
- As a user I browse a Distribution by category
- As a user I search for Package of a Distribution in it's Repositories
- As a user I extend the search to Package build on OBS for this Distribution
This has a couple of pro's:
- Less traffic on the OBS API as the usual Packages are inside the database
- Easier base to add features to this page. Like comments, ratings, openSUSE specific screenshots etc.
- Separating the Distribution package search from searching through OBS will hopefully make more clear for newbies that enabling extra repositories is kind of dangerous.
And one con:
- You can't search for packages build for foreign distributions with this app anymore (although we could consume their repomd etc. but I doubt we have the audience on an opensuse.org domain...)
TODO
Introduce a PG database
Add clockworkd as scheduler and delayed_job as ActiveJob backend
Introduce ActiveStorage
Build initial data model
Introduce repomd to database sync
Adapt repomd sync to Leap 16.0 repomod layout changes (single arch, no update repo)
Make repomd sync idempotent
Introduce database search
Setup foreman to run rails sandrake jobs:workoff- Adapt UI
Build Category Browsing
Build Admin Distribution CRUD interface
OSHW USB token for Passkeys (FIDO2, U2F, WebAuthn) and PGP by duwe
Description
The idea to carry your precious key material along in a specially secured hardware item is almost as old as public keys themselves, starting with the OpenPGP card. Nowadays, an USB plug or NFC are the hardware interfaces of choice, and password-less log-ins are fortunately becoming more popular and standardised.
Meanwhile there are a few products available in that field, for example
yubikey - the "market leader", who continues to sell off buggy, allegedly unfixable firmware ROMs from old stock. Needless to say, it's all but open source, so assume backdoors.
nitrokey - the "start" variant is open source, but the hardware was found to leak its flash ROM content via the SWD debugging interface (even when the flash is read protected !) Compute power is barely enough for Curve25519, Flash memory leaves room for only 3 keys.
solokey(2) - quite neat hardware, with a secure enclave called "TrustZone-M". Unfortunately, the OSS firmware development is stuck in a rusty dead end and cannot use it. Besides, NXP's support for open source toolchains for its devboards is extremely limited.
I plan to base this project on the not-so-tiny USB stack, which is extremely easy to retarget, and to rewrite / refactor the crypto protocols to use the keys only via handles, so the actual key material can be stored securely. Best OSS support seems to be for STM32-based products.
Goals
Create a proof-of-concept item that can provide a second factor for logins and/or decrypt a PGP mail with your private key without disclosing the key itself. Implement or at least show a migration path to store the private key in a location with elevated hardware security.
Resources
STM32 Nucleo, blackmagic probe, tropicsquare tropic01, arm-none cross toolchain
Capyboard, ESP32 Development Board for Education by emiler
Capyboard is an ESP32 development board built to accept individual custom-made modules. The board is created primarily for use in education, where you want to focus on embedded programming instead of spending time with connecting cables and parts on a breadboard, as you would with Arduino and other such devices. The board is not limited only to education and it can be used to build, for instance, a very powerful internal meteo-station and so on.
- github.com/realcharmer/capyboard
- github.com/realcharmer/capyboard-starter
- github.com/realcharmer/capyboard-docs
- github.com/realcharmer/capyboard-examples
- docs.capyboard.dev
Hack Week 25
My plan is to create a new revision of the board with updated dimensions and possibly even use a new ESP32 with Zigbee/Thread support. I also want to create an extensive library of example projects and expand the documentation. It would be nice to also design additional modules, such as multiplexer or an environment module.
Goals
- Implement changes to a new board revision
- Design additional modules
- Expand documentation and examples
- Migrate documentation backend from MkDocs to Zensical
Hack Week 24
I created a new motherboard revision after testing my previous prototype, as well as a light module. This project was also a part of my master's thesis, which was defended successfully.
Goals
- Finish testing of a new prototype
- Publish source files
- Documentation completion
- Finish writing thesis
Backfire TV - Take back control of your Firestick by andreabenini
Take Back Control of Your Amazon Firestick.
Tired of Ads, a cluttered launcher, and buttons you can't change? BackFireTV is a project to liberate your Firestick from Amazon's walled garden and make it truly yours. They call it the firestick. To fight fire with fire, you need a backfire.
That's the soul of BackFireTV. To truly liberate it and return back to its core capabilities this project uses a linux script, one Android app and ADB access against Amazon's restrictive policies. We leverage these internal tools to create a "backfire" against the incessant ads and locked ecosystem, transforming your Firestick back into the useful, customizable device it was always meant to be.
The Problem
The Amazon Firestick starts as an excellent, affordable streaming device. However, Amazon's
aggressive Ad policies and restrictive ecosystem have turned it into an increasingly annoying
and a less useful device. It comes with frustrations:
- Messy interface. The less the better was probably the best slogan for the early device,
its interface is now cluttered and chaotic when you probably need just a couple of buttons
for starting your favorite applications.
- Constant Ads. The default launcher is filled with commercials and sponsored content.
- Bloated Interface. A cluttered and slow home screen you can't customize.
- Locked Buttons. Dedicated buttons for services you don't use (like popular streaming
providers) that can't be easily changed.
- Lack of Control. A closed ecosystem that limits what you can do.
I could overlook them all if the device was provided for free. But since you pay and you own it it should be legit to do whatever you please in your personal device and network.
The Solution: BackFireTV
BackFireTV hacks your Firestick to give you back control. It uses a clever system of DHCP hooks
and ADB (Android Debug Bridge) commands to remotely manage your device, block annoyances and
customize your experience from the moment it connects to your network.
The dhcp lease action starts a nohup command on the firestick and forgets about it, the daemon
then manages running programs, hacks remote control features and keys. It can be paused or
resumed, no rooting required.
Features
- Custom Launcher. Automatically replaces the default Amazon launcher with the lean and clean Wolf Launcher.
- Ad-Free Experience:. Blocks annoying ads and sponsored content for a cleaner interface.
- Button Remapping. Reprogram the physical buttons on your remote. For example, make the Disney+ button launch Kodi or your favorite application.
- Works on every firestick 4K. Tested on: Firestick TV 4k (1st/2nd gen), Firestick TV 4k Max.
- No rooting required. It runs on basic user permissions with standard privileges. It also works on standard devices: latest firmware, with or without external hw attached (usb storage, network cards, usb hubs, ...).
- No banned apps. This hack relies on the linux subsystem underneath, no matter what Amazon does on the AppStore, this script can always be sideloaded and cannot be banned (no fingerprints on android app layer).
- Toggle to default anytime. Standard amazon launcher can still be toggled any time for administrative tasks or just as a comparison. Feel free to manage it as usual and switch back to
VimGolf Station by emiler
Description
VimGolf is a challenge game where the goal is to edit a given piece of text into a desired final form using as few keystrokes as possible in Vim.
Some time ago, I built a rough portable station using a Raspberry Pi and a spare monitor. It was initially used to play VimGolf at the office and later repurposed for publicity at several events. This project aims to create a more robust version of that station and provide the necessary scripts and Ansible playbooks to make configuring your own VimGolf station easy.
Goals
- Refactor old existing scripts
- Implement challenge selecion
- Load external configuration files
- Create Ansible playbooks
- Publish on GitHub
Resources
- https://www.vimgolf.com/
- https://github.com/dstein64/vimgolf
- https://github.com/igrigorik/vimgolf
