Low level stuff has always been interesting to me, I just have no clue how one would even get started with it, or who would even pay me to work on it.
Low level stuff has always been interesting to me, I just have no clue how one would even get started with it, or who would even pay me to work on it.
For example, take something like (1) the simplest AVR microcontroller (the type used in Arduinos, hence there is a ton of third-party documentation and code floating around) and (2) your typical Hitachi HD44780 LED display.
To control the display, one needs to pull certain pins high and low, for specific intervals -- this is all in the HD44780's data sheet. Of course, you don't do this every time you send a character; you abstract this away into functions setchar(x, y, c), clearDisplay(), and so on.
Presto, your first driver!
Then you might think: let's print stuff that we receive via a serial connection. So how do you react to that data? Then you learn about interrupts and interrupt handling.
Then you might think: I could be doing stuff while I wait for I/O. Actually, I'd like to do a lot of stuff, in parallel, but the AVRs are single-core (so to speak). So you do what you've heard other OSes do: take available compute time, divide it into slices, and distribute slices to processes. And thus, you have learned about multi-tasking.
This was relatively simple to do on AVRs, and great fun.
It may be easier if you do some electronics as a hobby since you can create the devices yourself with simple enough protocols. It gives you a good understanding of how the hardware works at a basic level.
There are thousands of tutorials out there on how to get started writing simple drivers, as well as the excellent book "Linux device drivers".
I don't do _complex_ drivers, but I've been able to write simple ones for my DIY electronic devices (keyboards, sensors, ...) and even a reverse engineered one for my BOSS RC5 guitar pedal.
Can be for old laptop (T420, etc with Intel GPU/Driver.)
Use FTRACE in kernel.
Setup ebpf trace for GPU acitivies.
Write some doc/blog/medium pages on the process and show off your works.
Understand, document and improve some opensource GPU API related utilities
Understand and document interaction between GPU/GUI App and OpenSource driver.
In term of jobs:
AMD has 289 opening for intern positions: https://jobs.amd.com/go/Internships-&-Co-op-Opportunities/25... A lot of them are graphic related.https://github.com/isometimes/rpi4-osdev
There are other courses/projects for other boards. The keyword is usually “baremetal”.
For Linux drivers specifically there are training material from Bootlin etc. They definitely give you a kickstart—the kernel is so complex that most of the device driver knowledge is organizational and cannot be found on YouTube.
One keyword is embedded programming. You can start out bare metal basically doing everything in a while(1) loop until you get to a point where different tasks (in the literal way) and peripherals get so much that you will end up doing exactly this, but on a much smaller (and comprehensible) scale.
The thing about NetBSD (and I can vouch for OpenBSD being much the same) is that it's so stinking well documented, if you go in knowing C you can learn how to write a simple device driver using just the man pages as your guide. Section 9 of the manual in particular documents every kernel API and most if not all internal types.
It's a great OS to practice developing low-level code with. Linux is a bit harder.
When it comes to writing firmwares or an OS, nothing can substitute for hands-on experience with actual hardware.