I trying to adapt 4.9 msm8953 kernel [1] for my phone - Xiaomi Redmi Note 4x. It was originally shipped with kernel 3.18.
Kernel almost done, however one of the last problems is changed sysfs structure [2]:
in kernel 3.18 FPC fingerprint device path was /sys/devices/soc/soc:fpc1020, but in 4.9 it is now in /sys/devices/platform/soc/soc:fpc1020. This is a problem for proprietary userland, which is hard to change.
So the goal is to symlink /sys/devices/platform/soc/soc:fpc1020 to /sys/devices/soc/soc:fpc1020.
For what I see there is no public API to directly create nodes inside /sys/devices.
Any advices how to get kobject of /sys/devices and make sysfs symlink here?
[1] https://github.com/nE0sIghT/android_kernel_xiaomi_msm8953
[2] https://github.com/nE0sIghT/android_kernel_xiaomi_msm8953/issues/18
I was able to create symbolic link using kernfs_create_link and getting parent kernfs node through parent property.
Here is solution: https://github.com/nE0sIghT/android_kernel_xiaomi_msm8953/commit/5749d673cce1e2ab2bdeb2f689d1527143889a05
Related
I am using Linux kernel release 5.4. I have one kernel built-in driver, which creates a sysfs class: /sys/night_owl/tick1/* using class_create() and device_create_file() function. I am developing another kernel loadable module, which reuses the /sys/class/night_owl class, this means I will have something like this /sys/class/night_owl/tick2/*. Does Linux kernel support this feature or are there any keywords for me to search on this?
I'm working on a Cyclone V SOC FPGA from Altera with a double Cortex-A9 processor. The embedded system (linux 4.15.7) is created with Buildroot-2018.02. U-boot is used to load the system i-e FPGA.rbf file, device tree blob and zImage and everything works fine.
I want now to integrate the RBF file to my linux and program the FPGA from Linux. I found several methods and the one I understand is the most common is to use CONFIGFS with a device-tree overlay.
So I changed my device tree to integrate the overlay, the u-boot boot script to disable FPGA load and also the following options in the linux ".config" file with make linux-xconfig :
+CONFIG_OF_OVERLAY=y
+CONFIG_ALTERA_STAPL=y
+CONFIG_CONFIGFS_FS=y
+CONFIG_SAMPLES=y
+CONFIG_SAMPLE_CONFIGFS=m
These options are the state were I am now after several try.
After a make and a reboot, once the kernel is loaded, I enter the following command in the console :
mkdir /config
mount -t configfs none /config
At this state, I'm expecting to see some device tree files in the /config folder but there wasn't any, only one rdma_cm folder :
# ls /config
rdma_cm
I continued my reading on this topic and found that I must enable the CONFIG_OF_CONFIGFS option in my linux kernel.
PROBLEM: This option is not available in my linux kernel. Also, file drivers/of/configfs.c is no here too. I've searched in vain to find how to enable device tree overlay for my kernel version.
How can I configure my kernel to make device-tree available in configfs ?
I had the same problem as you. So I had to make a device driver by myself.
This device driver is tentative and I expect Linux mainline to officially support Device Tree Overlay ConfigFS.
The device driver I made is available at the following URL.
https://github.com/ikwzm/dtbocfg
If you are using Debian, you can build the Debian Package of the device driver with the following URL.
https://github.com/ikwzm/dtbocfg-kmod-dpkg
If you want to try Device Tree Overlay using this device driver, please refer to the following URL.
https://github.com/ikwzm/FPGA-SoC-Linux
https://github.com/ikwzm/FPGA-SoC-Linux-Example-1-DE10-Nano
I'm looking for any appropriate solution for Device tree writing in raspberry pi
I went through:
basic device driver module loading and unloading
adding a kernel module in kernel source tree so that it can loaded automatically just like predefined kernel modules.
But now i have doubt about how one can write device tree in raspberry-pi for binding a particular driver or module at the booting time phase?
I researched lots of available resources within the Internet but unfortunately I could not find any precise solution that suits my need.
So you just need to add a node in your device tree and set the "compatible" property point to your driver. Check below link for reference.
https://github.com/saiyamd/skeleton-dt-binding/blob/master/skeleton.c
While we want to create a device file in file system, which one should we choose right now? Make a node in udev, which will show up in /dev or use sysfs which will show up in /sys.
I just think I can accomplish most of functions for a device through these two different ways. So it confused me a lot.
Thanks.
Use udev (and or define and publish some major & minor device numbers, like for mknod). See makedev(3)
Application programs want to access physical devices in /dev/ (not in /sys/). Data to/from a device go usually thru /dev/ char or block devices. Metadata and configuration can go thru sysfs
Read more about udev and about sysfs. See also device file wikipage.
You won't get very useful answers if you don't explain more concretely your issues... What exact kind of device are you thinking about? Very probably there exist already similar devices....
Publish very early (even in alpha stage, when it is not fully working) your device driver and software source code as free software preferably as GPLv2 (the license used by Linux kernel). Ask also on kernelnewbies. Work hard (perhaps more than a year) to get your driver incorporated in the official Linux kernel.
You should be familiar with Advanced Linux Programming (in the application userspace world) before attempting to code a kernel driver. After that, read books and resources on Linux kernel driver programming and study the source code of existing drivers in the recent Linux kernels.
I'm having a bit of a hard time fully understanding how the kernel starts in linux. I'm a wince developer and our company decided to run with linux instead now.
We outsourced all of the board bringup and the package I recieved is quit a bit different for the prototype board we have compared to the nitrogen6x we have been using.
Before i start listing the differences for the distro we created, the kernels are identical. The distro we have been using is a busybox system. The one we recieved from the vendor is sysvinit. I removed mdev from busybox and we are only using udev.
when I use the kernel on our busybox build the touch screen drivers breaks, or doesn' run, or does something totally magical. I'm not quit sure... there is a /dev/input/event0 device which when run on the sysvinit side is a touch device.. Is the kernel not the mechanism that binds the built-in drivers to a device node? I thought udev was for more dynamic events in the system.
On the other hand I can't really tell whats been loaded on my device. Is there a way to list running drivers that were built into the kernel? my touch pad is up? This is a fairly simple process of looking at the registry on wince to see which devices were loaded.
I guess what I'm really trying to discover, isn't so much how to add a driver to the kernel, its how the whole thing gets is plumbed together. I've found plenty of documents on createing kernel modules, but i haven't found a good resource on how to pull everything together from scratch so you can actually use said modules. Going back to the example of the touchscreen driver, its built into the kernel, how does that get plugged into /dev/input/event0??
I'm kind of having a difficult time finding good resources mostly because searching google for varations of linux/drivers/device nodes/ piles in tons of random crap from everywhere.
What you probably want to use now is evtest. It will allow you to know what are the input devices that are present and ready to use on your system.
To get more information on the input subsystem and more generic information on how the kernel is working, I can direct you to our training materials. The materials are free to download, use and redistribute.
The general answer is, there is no single, easy place to look to discover what drivers have been loaded by the kernel if they are compiled in. Of course, lsmod will display any drivers that were dynamically loaded after kernel boot.
The kernel does not create device nodes. That is, to quote your question, the kernel does not "bind" the driver to the device node. The association between kernel driver and device node is contained in the major and minor numbers registered when the driver is initialized. You can have a device node on your file system for which there is no corresponding driver (common especially in older devices where device nodes were statically created on the file system) and you can also have a driver installed for which there is no device node.
Modern Linux distros have dynamically created device nodes created on a mount point called /dev and this is usually a tmpfs file system, meaning it is volatile - it gets destroyed on every boot and recreated dynamically on each new boot.
udev is the magic that creates most device nodes based on events that it receives from the kernel when a new device is discovered (this can be after boot on device plugin, like a USB disk) or on startup when udev reads the queued events and acts on them. As you noted, busybox has a limited udev implementation called mdev.
Study udev and you will get a much better understanding of the process. Hope this helps a little.