4

My task is to implement a custom layer with fixed names for things like Ethernet and LEDs.

It needs to be the same on x86 and ARM devices. So the Power LED and eth1 is always the same for the applications, but are not connected to the same hardware pins. From my point of view I can do this on ARM with Device Tree assignments. But can I use the device tree on x86 based boards to do this? Is it good practice?

Background Information: Targets: wide range of embedded Linux Boards, Buildsystem: Buildroot, Custom Linux Kernel Versions, no Linux distribution, Busybox running on top

artless noise
  • 21,212
  • 6
  • 68
  • 105
Rotesmofa
  • 67
  • 8
  • One point that speaks against the Device Tree is that I have boards which are running old kernel Versions like 3.2, I know that it might be possible to use it none the less. But with changes in the Bootloader and Kernel. – Rotesmofa Jan 20 '16 at 10:14

2 Answers2

2

Use sysfs.

For example you can access network inteface information via /sys/class/net/eth0/. For specific peripheral you can provide your own kernel objects which provides a stable name.

This already keeps x86 / ARM difference to a minimum for applications. I'm thinking for example wpa_supplicant or most of the init level initialization scripts.

auselen
  • 27,577
  • 7
  • 73
  • 114
  • This answer is kept short, but does have a point. I would have accept it, but artless noise did put a lot of thought into his/her answer. – Rotesmofa Jan 27 '16 at 14:34
2

TL;DR - Device tree is not the answer you are looking for. There are many ways to do this depending on your ultimate needs.

Device Tree is inherited from the PowerPC. It is not an interface to user-space. It is intended to provide a data driven customization of board layouts for a given CPU/SOC family. For instance, there are many TI OMAP devicesSee devices in tables each of which has different chips connected to the CPU (different Ethernet MII/RMII,etc) with various pin, clock, power, etc configurations. Each has the same TI OMAP SOC so the code to configure this is know for all of them. Device Tree is an input for the board to configure the SOC to use the hardware. Device drivers may have hooks to alter behaviour when a particular SOC (or board) is found.

Device tree is a way for a boot loader to tell the kernel what hardware is present and should be configured.

There are various methods you can use to talk to user space. Some are the same underlying thing with different use cases...

  1. Make a system new call.
  2. netlink
  3. File system (device file)
  4. procfs
  5. sysfs
  6. debugfs
  7. Signals
  8. udev/mdev
  9. User-space GPIO
  10. select (file/socket)

Items 3-6 are all basically the same. Generally, files are synchronous. Ie, if you have a PIN output they are fine as you can just write to them from user-space. However, say you have an input pin like a custom card (daughter board) present/insert. Maybe you have some RS-232 cable connected or head-phone insert pin? With a file interface, you must poll them (or you need to have inotify etc support in your kernel code). netlink is a way to provide messages from the kernel to user-space. It makes sense if your pin can be connect to a system interrupt (in any case).

mdev and udev use netlink to tell user-space about PCI, USB, etc hardware being connected/disconnected. You can use a similar scheme for GPIO. You just make a link between /sys/class/output/led1 and /dev/my_company/power_led with a mdev/udev script.

Personally, I would want to put the naming in user space and not the kernel. What is eth1 for instance? Maybe you want a diagnostic and main communication Ethernet port? Hardware might not populate diagnostic port at some point to make the BOM cheaper. Then maybe eth1 is eth0?

artless noise
  • 21,212
  • 6
  • 68
  • 105
  • Thank you versy much for sharing this. – Rotesmofa Jan 27 '16 at 14:36
  • 8) udev/mdev are out of questions since I already had lots of trouble creating consistent rules with different devices involved (might be caused through hardware as well). Your last point is what I am after, the developers need a Debug_Ethernet_Interface which is in Hardware connected to anything from eth0/1/2,usb0 or something virtual and also the abstraction of something like a status LED. I am not sure if I can cover everythig with something like sysfs. – Rotesmofa Jan 27 '16 at 14:42