so to that end, What would be a good idea for a linux kernel module I can work on, something that may get me to interact with any topics involving communication standards/protocols ( i2c, SPI, or JTAG, wireless, BLE).
thank you.
Along those lines, look at all the dkms modules in any Linux distro and try to talk to the module authors about mainlining, do the work needed if they agree to it.
Also, I have some ideas for Linux kernel things I noticed are needed in my branches of linux.git. I doubt I'll work on them any time soon, so feel free to use the ideas/code I've left in the branches.
cleanups/bluetooth-magic-numbers
cleanups/debian
features/dmesg-richness
features/hwmon-streaming
features/in-kernel-cross-fs-copy
features/lvm-raid-discard
features/runtime-syscall-lookup
features/sys-class-storage
features/tmpfs-o-discard
features/tmpfs-user-xattr
features/usbip-flexibility
Not directly related to your question, but check out the KernelNewbies community and also some of the FOSS internship programs, especially GSoC and LKMP offer paid internships to work on the Linux kernel.
https://kernelnewbies.org/ https://github.com/fossjobs/fossjobs/wiki/resources#internsh...
There are a lot of patches that are purely Android-specific and won't ever make it to upstream Linux, but others, like the drivers for flash chips and USB? These could definitely be submitted upstream.
Samsung for example uploads their FOSS dumps to [1].
First thing I'd do is to get u-boot working as a fourth-stage bootloader so you don't have to wrestle with ODIN or fastboot every time you rebuild your kernel. That alone should be a decent sized university project.
[1] https://opensource.samsung.com/uploadList?menuItem=mobile&cl...
[2] https://en.wikipedia.org/wiki/Booting_process_of_Android_dev...
Having an existing community may also be useful for figuring this stuff out.
They are great little machines, though a bit underpowered (even when they were new) so running MacOS is not a great experience. Decent Linux support should give these devices a second live.
Most devices should be able to work, as they are all standard components. My suspicion is that we are mostly lacking device trees and maybe some SMC work.
I expect the circuit diagrams for this laptop to be floating around the web somewhere (otherwise shoot Louis Rossman an email), so reverse-engineering the SMC should be doable, and a great low level/embedded challenge.
Surely most of the required support is there already?
Also known as the A1534 Macbook8,1 (yes, Apple's naming is always confusing).
This could be used for things like user space memory mapping of networked memory, where memory is retrieved from a remote computer when accessed. This would make it possible to transparently implement userspace large scale shared memory systems in a very elegant way. Good luck with what ever you decide to do!
You'd have to figure out phandle support for the I2C configuration channel, fire up I2S streaming by enabling it in the kernel and piping audio to the DAC, then playing it into some speakers.
Could expand it by adding some filtering. Many DACs have filter banks that you can populate with coefficients via I2C.
There's some decent kernel module resources and examples in this repo if this is something you're brand new to:
https://github.com/Johannes4Linux/Linux_Driver_Tutorial
If you have any interest or experience in cybersecurity and have considered doing that professionally, my company is hiring and likely will be all year. We probably have a use for a new SWE on the embedded side. Email me at my username at Gmail.
But why not I guess. :)
Camera sensor drivers are a bit less abstracted and many sensors don't have upstream drivers. But there's also a lack of quality documentation for HW in this area, oftentimes... v4l2 API is a bit more approachable than alsa PCM API, IMO. And on advanced SoCs you can pass around video buffers bewteen various v4l2 mem2mem devices to transform/process the data in HW. Drivers for HW acceleration of image or video data processing are seldom exercised in all their features, so there are many bugs there waiting to be squashed, and features to be implemented. It's a deep rabbit hole.
Let the fella learn.
> my company is hiring and likely will be all year. We probably have a use for a new SWE on the embedded side. Email me at my username at Gmail.
I'll keep this mind, thank you.
Our work is much closer to the metal. There's a big hardware component. Based on what you describe, we have work that I strongly suspect you'd find interesting. Your intuition was correct - low level coding and OS stuff is where all the goods are at.
Shoot me an email at cushychicken@gmail.com and I can tell you about what we do in a bit more detail.
[1] 802.1Q-2018 - IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks:
https://ieeexplore.ieee.org/document/8403927
[2] Provider Backbone Bridging for Linux:
https://github.com/openss7/pbbr
[3] Are there inherent problems with 802.1aq preventing wider adoption?
https://www.reddit.com/r/networking/comments/8gez0r/are_ther...
[1]:https://en.wikipedia.org/wiki/Port_knocking [2]:https://rnikhil.com/2016/12/12/port-knocking-python.html
This should be somewhat easy to start and self-contained. If you want, you can easily extend it if you want things to become more fancy. E.g., hiding the secret constant. Implementing a challenge response protocol, limiting access to other global state (hardware dongle? ip address?) and so on.
* You can select a board with not fully supported peripheral Examples RISC-V or Loongson boards with incomplete or missing drivers.
* or create a higher abstractions over the SPI for a A/D or D/A or pwm chip. The module offers a /dev/ file that hides the SPI communication or the motor position and encoding...
Some SPI devices can stream out lots of data on the bus. I’m looking at you ADCs.
It’d be nice to have a stream style API for that. Not sure which Linux framework is best suited for that. Maybe IIO but something on those lines might be fun to explore.
I had to first reverse engineer the windows utility that was written in c# and found out that it used wmi commands. After reading the kernel code for a while I realized there where already some code that implemented HP WMI commands.
Using that as a foundation it was quite easy to write my own kernel module that could change the led colors. Then I tried to integrate it with the linux kernel's led API. Since the LEDs where RGB it was a little different to integrate but I managed to find some examples in some playstation joystick driver code.
This project was a lot of fun, but I would say that you should be careful not to break your hardware. I have broken devices even from the user space by pushing it beyond it's limits.
This my code, large part of it is based on other HP WMI stuff https://github.com/kuterd/hp_omen_led_controler
But really, to answer your question; the best thing is to find something that you actually want your computer to do that's feasible, but not possible because there's no kernel module. Then you'll be incentivized to keep going with the project, not just a resume/interview material project.