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?

Quad SATA HAT top board

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

  1. https://wiki.radxa.com/DualQuadSATA_HAT
  2. https://rock.sh/get-rockpi-sata
  3. https://github.com/baierjan/go-sata-hat
  4. 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:

raspberrypi tumbleweed rpm hardware

This project is part of:

Hack Week 23

Activity

  • about 2 years ago: binary_sequence liked this project.
  • about 2 years ago: jgoldschmidt liked this project.
  • about 2 years ago: jbaier_cz added keyword "raspberrypi" to this project.
  • about 2 years ago: jbaier_cz added keyword "tumbleweed" to this project.
  • about 2 years ago: jbaier_cz added keyword "rpm" to this project.
  • about 2 years ago: jbaier_cz added keyword "hardware" to this project.
  • about 2 years ago: ggardet_arm liked this project.
  • about 2 years ago: mbrugger liked this project.
  • about 2 years ago: harrisonbc joined this project.
  • about 2 years ago: jbaier_cz started this project.
  • about 2 years ago: jbaier_cz originated this project.

  • Comments

    • harrisonbc
      about 2 years ago by harrisonbc | Reply

      Hi - I have one of these HATs and am happy to help test it out with Tumbleweed

      • jbaier_cz
        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-control should 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.

    asciicast

    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)


    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

    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 class feature, 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 like function, 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

    • add-emoji Introduce a PG database
    • add-emoji Add clockworkd as scheduler and delayed_job as ActiveJob backend
    • add-emoji Introduce ActiveStorage
    • add-emoji Build initial data model
    • add-emoji Introduce repomd to database sync
      • add-emoji Adapt repomd sync to Leap 16.0 repomod layout changes (single arch, no update repo)
      • add-emoji Make repomd sync idempotent
    • add-emoji Introduce database search
    • add-emoji Setup foreman to run rails s and rake jobs:workoff
    • Adapt UI
      • add-emoji Build Category Browsing
      • add-emoji 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.

    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.
    BackFireTV

    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