Also get a random raspberry pi and a simple peripheral for it: some 1 wire temperature sensor or something on i2c.
Then ignore the existing drivers and do your own. Do a character device and have a read from it trigger a read in kernel and copying of the data to user space, maybe in human readable form.
Should be good practice.
And for general embedded Linux development you also want to take a look at Yocto.
Yocto is fine and very powerful. I work with it daily, producing a "just enough os". It's amazing to produce a full OS with fully traceable sources, versions and licensing of everything, even CVE patch tracking.
If you work long enough in embedded Linux you will encounter it for sure.
I would advise against starting with yocto for a beginner. It is very complex, most tasks look more like weird magical incantations than actual code. It will discourage many, as things will feel completely incomprehensible for months.
You kind of have to know the problems it solves to appreciate it.
In another comment I pointed to OpenWRT and Raspbian. They have real world devices they target, you can git clone, build and flash real devices to get you started and see real results faster. Their build systems do not have all the complexity of layers and are easier to follow.
You don't really even need a device to get started. The first driver I ever wrote consisted of 128 bytes of memory that you could write to and read back from. After I got that working, I realized I could change the 128 to 1.44M, implement a couple ioctls and have a reasonable RAM disk substitute for a floppy drive (this was SCO OpenServer back in the 1990s, and it didn't have a loop back device.)
You are totally right... Nix is cool for advanced CPUs (i.e. x86, armv7, aarch64, etc) and much less so for microcontrollers.
But if your platform can run NixOS ... then ... let's see...
With nix I have a file that exactly describes the git sources (pinnable on precise changesets if required) for all my components (including custom kernel patches, device drivers, etc).
I use a nix config to create a fully GPLV3 compliant rootfs and another set of nix config files in a separate repo to create our device specific intellectual property, in a separate encrypted image different from the rootfs.
The nix config files easily describes everything i need to fully support Secure boot, as well as code to unseal a TPM luks password used to decrypt the image that contains our intellectual property for that device (basically the application).
All this is fully reproducible, so I can provide our clients with the nix config files for our rootfs, tell them to use nix and they can reproduce our exact rootfs image to run in the device , for GPLv3 compliance. Of course , then the device is "broken" , because our IP will not be decryptBle anymore. But the GpLv3 does not mandate full functionality when running foreign images...
Now I am absolutely certain all this can be also done with Yocto... but with less simplicity ... less joy ... :)
I used pSOS in the past, got burned when Integrated Systems was sold... then stayed away from proprietary OSes as much as I could. Used Debian with XEN later on... then Yocto in many products, then back to a Debian-like OS and now , finally, using Nix. It just works.
> Of course , then the device is "broken" , because our IP will not be decryptBle anymore. But the GpLv3 does not mandate full functionality when running foreign images...
I thought v3 was specifically made to prevent tivoization? And that sounds like you even used the same implementation as TiVo.
Well... you get to reproduce yourself and run everything covered by the gplv3 (same exact versions, same binaries even with Nix) on the device. You get everything you need to reproduce the device's rootfs. It will boot your image, if you disable Secure Boot. You can install your own UEFI certificates if you want to enable Secure Boot with your image. You even get the complete development environment for free (Nix).
Also get a random raspberry pi and a simple peripheral for it: some 1 wire temperature sensor or something on i2c.
Then ignore the existing drivers and do your own. Do a character device and have a read from it trigger a read in kernel and copying of the data to user space, maybe in human readable form.
Should be good practice.
And for general embedded Linux development you also want to take a look at Yocto.