early stage kdump support by mbrugger

Project Description

When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.

Goal for the Hackweeks

1. Investigate if this is possible and the implications it would have (done in HW21)
2. Hack up a PoC (done in HW22 and HW23)
3. Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).

update HW23

• I was able to include the crash kernel into the kernel Image.
• I'll need to find a way to load that from init/main.c:start_kernel() probably after kcsan_init()
• I workaround for a smoke test was to hack kexec_file_load() systemcall which has two problems:
  1. My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
  2. As the crash kernel is part of init.data it will be already stale once I can call kexec_file_load() from user-space.

The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.

update HW24

• Day1
  • rebased on v6.12 with no problems others then me breaking the config
  • setting up a new compilation and qemu/virtme env
  • getting desperate as nothing works that used to work
• Day 2
  • getting to call the invocation of loading the early kernel from __init after kcsan_init()

• Day 3

  • fix problem of memdup not being able to alloc so much memory... use 64K page sizes for now
  • code refactoring
  • I'm now able to load the crash kernel
  • When using virtme I can boot into the crash kernel, also it doesn't boot completely (major milestone!), crash in elfcorehdr_read_notes()

• Day 4

  • crash systems crashes (no pun intended) in copy_old_mempage() link; will need to understand elfcorehdr...
  • call path vmcore_init() -> parse_crash_elf_headers() -> elfcorehdr_read() -> read_from_oldmem() -> copy_oldmem_page() -> copy_to_iter()

• Day 5

  • hacking arch/arm64/kernel/crash_dump.c:copy_old_mempage() to see if crash system really starts. It does.
  • fun fact: retested with more reserved memory and with UEFI FW, host kernel crashes in init but directly starts the crash kernel, so it works (somehow) \o/

• TODOs

  • fix elfcorehdr so that we actually can make use of all this...
  • test where in the boot __init() chain we can/should call kexec_early_dump()

---

Create a DRM driver for VGA video cards by tdz

Yes, those VGA video cards. The goal of this project is to implement a DRM graphics driver for such devices. While actual hardware is hard to obtain or even run today, qemu emulates VGA output.

VGA has a number of limitations, which make this project interesting.

• There are only 640x480 pixels (or less) on the screen. That resolution is also a soft lower limit imposed by DRM. It's mostly a problem for desktop environments though.
• Desktop environments assume 16 million colors, but there are only 16 colors with VGA. VGA's 256 color palette is not available at 640x480. We can choose those 16 colors freely. The interesting part is how to choose them. We have to build a palette for the displayed frame and map each color to one of the palette's 16 entries. This is called dithering, and VGA's limitations are a good opportunity to learn about dithering algorithms.
• VGA has an interesting memory layout. Most graphics devices use linear framebuffers, which store the pixels byte by byte. VGA uses 4 bitplanes instead. Plane 0 holds all bits 0 of all pixels. Plane 1 holds all bits 1 of all pixels, and so on.

The driver will probably not be useful to many people. But, if finished, it can serve as test environment for low-level hardware. There's some interest in supporting old Amiga and Atari framebuffers in DRM. Those systems have similar limitations as VGA, but are harder to obtain and test with. With qemu, the VGA driver could fill this gap.

Apart from the Wikipedia entry, good resources on VGA are at osdev.net and FreeVGA

---

Hacking on sched_ext by flonnegren

Description

Sched_ext upstream has some interesting issues open for grabs:

• core event counters
• topology: Use cpumasks

Goals

Send patches to sched_ext upstream

Also set up perfetto to trace some of the example schedulers.

Resources

https://github.com/sched-ext/scx

---

Officially Become a Kernel Hacker! by m.crivellari

Description

My studies as well my spare time are dedicated to the Linux Kernel. Currently I'm focusing on interrupts on x86_64, but my interests are not restricted to one specific topic, for now.

I also "played" a little bit with kernel modules (ie lantern, a toy packet analyzer) and I've added a new syscall in order read from a task A, the memory of a task B.

Maybe this will be a good chance to...

Goals

• create my first kernel patch

Resources

• https://www.kernel.org/doc/html/latest/process/submitting-patches.html
• https://git-send-email.io/ (mentioned also in the kernel doc)
• https://javiercarrascocruz.github.io/kernel-contributor-1

Achivements

• found while working on a bug, this is the 1st patch: cifs: avoid deadlocks while updating iface [✅ has been merged]

---

RISC-V emulator in GLSL capable of running Linux by favogt

Description

There are already numerous ways to run Linux and some programs through emulation in a web browser (e.g. x86 and riscv64 on https://bellard.org/jslinux/), but none use WebGL/WebGPU to run the emulation on the GPU.

I already made a PoC of an AArch64 (64-bit Arm) emulator in OpenCL which is unfortunately hindered by a multitude of OpenCL compiler bugs on all platforms (Intel with beignet or the new compute runtime and AMD with Mesa Clover and rusticl). With more widespread and thus less broken GLSL vs. OpenCL and the less complex implementation requirements for RV32 (especially 32bit integers instead of 64bit), that should not be a major problem anymore.

Goals

Write an RISC-V system emulator in GLSL that is capable of booting Linux and run some userspace programs interactively. Ideally it is small enough to work on online test platforms like Shaderoo with a custom texture that contains bootstrap code, kernel and initrd.

Minimum:

riscv32 without FPU (RV32 IMA) and MMU (µClinux), running Linux in M-mode and userspace in U-mode.

Stretch goals:

FPU support, S-Mode support with MMU, SMP. Custom web frontend with more possibilities for I/O (disk image, network?).

Resources

RISC-V ISA Specifications
Shaderoo
OpenGL 4.5 Quick Reference Card

Result as of Hackweek 2024

WebGL turned out to be insufficient, it only supports OpenGL ES 3.0 but imageLoad/imageStore needs ES 3.1. So we switched directions and had to write a native C++ host for the shaders.

As of Hackweek Friday, the kernel attempts to boot and outputs messages, but panics due to missing memory regions.

Since then, some bugs were fixed and enough hardware emulation implemented, so that now Linux boots with framebuffer support and it's possible to log in and run programs!

The repo with a demo video is available at https://github.com/Vogtinator/risky-v

---

SUSE Prague claw machine by anstalker

Project Description

The idea is to build a claw machine similar to e.g. this one:

Why? Well, it could be a lot of fun!

But also it's a great way to dispense SUSE and openSUSE merch like little Geekos at events like conferences, career fairs and open house events.

Goal for this Hackweek

Build an arcade claw machine.

Resources

In French, an article about why you always lose in claw machine games:

We're looking for handy/crafty people in the Prague office:

• woodworking XP or equipment
• arduino/raspi embedded programming knowledge
• Anthony can find a budget for going to GM and buying servos and such ;)

---

Framework laptop integration by nkrapp

Project Description

Although openSUSE does run on the Framework laptops out-of-the-box, there is still room to improve the experience. The ultimate goal is to get openSUSE on the list of community supported distros

Goal for this Hackweek

The goal this year is to at least package all of the soft- and firmware for accessories like the embedded controller, Framework 16 inputmodule and other tools. I already made some progress by packaging the inputmodule control software, but the firmware is still missing

Resources

As I only have a Framework laptop 16 and not a 13 I'm looking for people with hardware that can help me test

Progress:

Update 1:

The project lives under my home for now until I can get an independent project on OBS: Framework Laptop project

Also, the first package is already done, it's the cli for the led-matrix spacer module on the Framework Laptop 16. I am also testing this myself, but any feedback or questions are welcome.

You can test the package on the Framework 16 by adding this repo and installing the package inputmodule-control

Update 2:

I finished packaging the python cli/gui for the inputmodule. It is using a bit of a hack because one of the dependencies (PySimpleGUI) recently switched to a noncommercial license so I cannot ship it. But now you can actually play the games on the led-matrix (the rust package doesn't include controls for the games). I'm also working on the Framework system tools now, which should be more interesting for Framework 13 users.

You can test the package on the Framework 16 by installing python311-framework16_inputmodule and then running "ledmatrixctl" from the command line.

Update 3:

I packaged the framework_tool, a general application for interacting with the system. You can find it some detailed information what it can do here. On my system everything related to the embedded controller functionality doesn't work though, so some help testing and debugging would be appreciated.

Update 4:

Today I finished the qmk interface, which gives you a cli (and gui) to configure your Framework 16 keyboard. Sadly the Python gui is broken upstream, but I added the qmk_hid package with the cli and from my testing it works well.

Final Update:

All the interesting programs are now done, I decided to exclude the firmware for now since upstream also recommends using fwupd to update it. I will hack on more things related to the Framework Laptops in the future so if there are any ideas to improve the experience (or any bugs to report) feel free to message me about it.

As a final summary/help for everyone using a Framework Laptop who wants to use this software:

The source code for all packages can be found in repositories in the Framework organization on Github

All software can be installed from this repo (Tumbleweed)

The available packages are:

• framework-inputmodule-control (FW16) - play with the inputmodules on your Framework 16 (b1-display, led-matrix, c1-minimal)

• python-framework16_inputmodule (FW16) - same as inputmodule-control but is needed if you want to play and crontrol the built-in games in the led-matrix (call with ledmatrixctl or ledmatrixgui)

• framework_tool (FW13 and FW 16) - use to see and configure general things on your framework system. Commands using the embedded controller might not work, it looks like there are some problems with the kernel module used by the EC. Fixing this is out of scope for this hackweek but I am working on it

• qmk_hid (FW16) - a cli to configure the FW16 qmk keyboard. Sadly the gui for this is broken upstream so only the cli is usable for now

---

Capyboard, ESP32 Development Board for Education by emiler

Description

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.

I already have one initial prototype ready and tested. The next iteration addresses several issues the first prototype had. I am planning on finishing up the mainboard and one of the modules this week.

This project is also a part of my master's thesis.

Goals

• Finish testing of a new prototype
• Publish source files
• Documentation completion
• Finish writing thesis

Resources

• github.com/realcharmer/capyboard
• github.com/realcharmer/capyboard-starter
• github.com/realcharmer/capyboard-docs
• docs.capyboard.dev

---

Build a split keyboard from scratch by mpagot

Description

I'm getting older... this summer I experienced an annoying and persistent tingling in one hand and arm. That was the initial motivation to get more interested in ergonomic work gadgets, and from that to split keyboards. And that was the entrance in a rabbit hole.

Which keyboard I like to create:

• Split keyboard for ergonomic (I'm not primary interested in having it portable)
• I have big hands: I like it to fit as much as possible my hands measures
• Columnar stagger keys position
• Not too few keys (at the moment I'm at 24 + 24)
• One row thumb cluster
• No wireless, not to have batteries and for security reason
• CherryMX, or generally speaking no low profile/corne choc
• Hot swap Socket switches

Goals

• Create PCB design for a split keyboard
• Get it produced
• Mount it
• Evaluate FWs

Resources

• Main project repo: Zenga
• ZKM config for a hand wired 4 keys something: nne
• Blog posts opensuse.hackweek.2024

Progress

Day1

Get the existing Ergogen project working on my TW machine Get Kicad as flatpack Go back to the https://flatfootfox.com/ergogen-part3-pcbs/ Join the #ergogen Discord channel and ask for help about the nets

Day2

Redesign the keyboard matrix on Inkscape Implement it in the Ergogen YAML format Create a Kicad PCB file Start routing it Iterate over the matrix arrangement to try to implement it like 2 layer board and ideally with not vias Get some Kicad tutorials

Day3

Get my hand dirty building a 2x2 key matrix --> welcome to nne Look at ZKM and how to configure it --> https://github.com/michelepagot/zmk-config-nne Get the FW built by github, try to flash it: get matrix scan pulse but no keys to the PC Get in contact with ceoloide, an Ergogen maintainer, about net issue.

---