The SMBus standard specifies an address resolution protocol (SMBus ARP.) It has two key features :
- Handle I2C slave address collisions. If two SMBus slaves would use the same I2C address, ARP lets one of them pick a different address to avoid the address collision.
- Automatically and reliably identify SMBus slaves. Each SMBus slave supporting ARP has a unique device ID, which can be used to automatically instantiate the right I2C device and subsequently let the needed driver be loaded.
Plan
If implemented properly, sensors-detect would no longer be needed on a number of systems, as all required drivers would get loaded automatically.
There has been some work done on SMBus ARP in the past, but nothing good enough to be integrated in the upstream kernel. Mark D. Studebaker wrote proof-of-concept code in 2002, for kernel 2.2. The code was updated for kernel 2.4 but development stopped in 2005.
More recently, Corentin Labbe has been working on proof-of-concept code for kernel 2.6/3. As I recall the code did not actually work, but maybe it can be used as a base.
Results
Miserable failure. Proper hardware support is rare, and prerequisites aren't met.
This project is part of:
Hack Week 10
Activity
Comments
-
about 11 years ago by jdelvare | Reply
Things didn't go as good as I hoped. Firstly my own machine no longer replies to the SMBus ARP address, while I'm almost certain it used to. I can't explain it.
Then I tried to find a machine on the Suse network that would be suitable, but that kind of information doesn't show in orthos, so finding the right machine was difficult. I finally found "knorr", which does reply to the SMBus ARP address, but uses an HT-1000 south bridge for which we don't support SMBus PEC, which is a prerequisite for SMBus ARP. I don't even know if the chipset supports it, and the datasheet is not publicly available.
So I gave up on "knorr" and now found "fux" which does reply to the SMBus ARP address and uses the i2c-i801 SMBus driver which implements SMBus PEC support. I can start my tests now.
-
about 11 years ago by jdelvare | Reply
The curse goes on. "fux" has an ICH10 south bridge, and testing revealed that PEC (CRC) errors during SMBus block transactions (at least) lock up the SMBus controller. I suspect an undocumented erratum. I managed to find a software workaround, I must discuss it with upstream.
When testing that software workaround on another chip (ICH5) supported by the i2c-i801 driver, I hit another bug related to PEC error handling. I'm still puzzled by that one, I don't understand what is going on and have no idea how to work around it.
It should be clear by now that I'm not going to complete my hack week project. It turns out that the world is not yet ready for SMBus ARP. First of all we need proper SMBus PEC support on a wide range of machines. Only when this is available, it will make sense to look into SMBus ARP support again.
Similar Projects
Hacking on sched_ext by flonnegren
Description
Sched_ext upstream has some interesting issues open for grabs:
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
Improve various phones kernel mainline support (Qualcomm, Exynos, MediaTek) by pvorel
Similar to previous hackweeks ( https://hackweek.opensuse.org/projects/improve-qualcomm-soc-msm8994-slash-msm8992-kernel-mainline-support, https://hackweek.opensuse.org/projects/test-mainline-kernel-on-an-older-qualcomm-soc-msm89xx-explore-mainline-kernel-qualcomm-mainlining) try to improve kernel mainline support of various phones.
Result
In the end I concentrated again to msm8994:
- 507aae9a3549c ("arm64: dts: qcom: msm8994-angler: Enable power key, volume up/down") (will be in kernel 6.14)
- Testing of c910544d22347 ("arm64: dts: qcom: msm8994: Describe USB interrupts") (will be in kernel 6.14)
- WIP USB support for msm8994
Kill DMA and DMA32 memory zones by ptesarik
Description
Provide a better allocator for DMA-capable buffers, making the DMA and DMA32 zones obsolete.
Goals
Make a PoC kernel which can boot a x86 VM and a Raspberry Pi (because early RPi4 boards have some of the weirdest DMA constraints).
Resources
- LPC2024 talk:
- video:
Model checking the BPF verifier by shunghsiyu
Project Description
BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).
One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.
For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.
Goal for this Hackweek
Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.
Resources
- Formal Methods for the Informal Engineer: Tutorial #1 - The Z3 Theorem Prover and its accompanying notebook is a great introduction into Z3
- Has a section specifically on model checking
- Software Verification and Analysis Using Z3 a great example of using Z3 for model checking
- Sound, Precise, and Fast Abstract Interpretation with Tristate Numbers - existing work that use formal verification to prove that the multiplication helper used for value tracking work as intended
- [PATCH v5 net-next 00/12] bpf: rewrite value tracking in verifier - initial patch set that adds tristate number to the verifier
Create DRM drivers for VESA and EFI framebuffers by tdz
Description
We already have simpledrm for firmware framebuffers. But the driver is originally for ARM boards, not PCs. It is already overloaded with code to support both use cases. At the same time it is missing possible features for VESA and EFI, such as palette modes or EDID support. We should have DRM drivers for VESA and EFI interfaces. The infrastructure exists already and initial drivers can be forked from simpledrm.
Goals
- Initially, a bare driver for VESA or EFI should be created. It can take functionality from simpledrm.
- Then we can begin to add additional features. The boot loader can provide EDID data. With VGA hardware, VESA can support paletted modes or color management. Example code exists in vesafb.
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
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
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 ;)
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.