[CLOSED] Hardware discovery and driver selection

Talk about Documentation
1

I occasionally answer (here and elsewhere) questions from users (mostly those on x86) who have hardware that requires drivers not present in the default OpenWrt distribution. I think this is a topic that deserves a Wiki page, and I would like to contribute that page (I have a wiki account and have contribute to the wiki before). Topics covered would include:

  • Installation of pciutils and usbutils
  • Using pciutils (usbutils) to obtain PCI (USB) identifiers
  • Using linux-hardware.org to narrow down the likely name of the relevant kernel module based on PCI / USB identifier
  • Using search engines and pkgdata to identify relevant kernel module(s)
  • Driver installation using opkg and apk

I would like to solicit community input on a few questions:

  • Does this topic belong on the wiki? Or is it too niche?
  • If it does, what is the appropriate location? I am leaning toward a page under User guide >> Base system.
  • What is the appropriate title? My working title is Hardware discovery and driver selection. If anyone has a better idea, I am all ears...

Thank you in advance for your thoughts!

2 Likes
2

Boot ubuntu, check driver, profit.

1 Like
3

In other words, do you think I am proposing something unnecessary?

4

I would also support including these in default OpenWrt x86-64 images, so that when the default image is booted from USB, the output of these utilities can be inspected to lessen dependency of other distros.

1 Like
5

Yeah, but then, we'd also want fdisk, lsblk, and who knows what else... :crazy_face:

1 Like
6

You kind of presume ubuntu and flatpak pre-installed

7

Not at all. The whole point is to use only already running OpenWrt and a limited amount of search engine fu to avoid having to mess around with another Linux distro.

Here's an excerpt from one of my earlier posts here that shows the action sequence in a particular case.

[Quote]

Now run:

lspci -nn

If there's too much stuff onscreen, limit the output to lines containing the word "Ethernet":

lspci -nn | grep Ethernet

One way or another, you will see something like this:

01:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
02:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
03:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
04:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
05:08.0 Ethernet controller [0200]: Intel Corporation 82562ET/EZ/GT/GZ - PRO/100 VE Ethernet Controller [8086:1065] (rev 04)

Note the first four lines are nearly identical and refer to a device whose PCI identifier is [8086:10d3]. The fifth line is singular, so we can conclude that the four lines refer to the four-port Ethernet card that we need to get working, while the fifth line describes the single-port card that is working already.

Let's take a quick trip to Hardware for Linux:

https://linux-hardware.org/index.php?id=pci:8086-10d3

Note the ending of the URL; it's our PCI identifier with colon replaced by a dash. We are in luck: this is a piece of hardware known in the Linux world. The kernel module for it has been seen in Llinux sources at

drivers/net/ethernet/intel/e1000e/netdev.c

So we should be looking for something named kmod-netdev or perhaps kmod-e1000e. Googling OpenWrt kmod-netdev produces some links, but it doesn't look like they have anything to do with networking. Googling OpenWrt kmod-e1000e, on the other hand, leads to a direct hit; the package kmod-e1000e does exist and is described as Kernel modules for Intel(R) PRO/1000 PCIe Ethernet adapters.

Now that we know which kernel module we are missing, we can install it:

opkg install kmod-e1000e

Once the package installs, you will see a series of messages related to the previously unknown, but now available, ports eth1, eth2, eth3, and eth4.

[End quote]

8

I regret that I have only one thumb to up for my country this post.

Absolutely, I use all sorts of different x86 hardware, and the increasing number of new combined-image generic devices (armsr, loongarch and riscv) will only add to the need for this sort of information.

9

Another potential use case is component upgrades on any target with removable components. For example, there are plenty of older devices with detachable ath9k cards that can be upgraded to ath10k cards...

1 Like
10

Help me, i have lost driver for this device.

I dont have internet connection to install more tools obviously, like lsscsi

i an not sabotaging your idea but how it saves time for generic user or in forum questions.

1 Like
11

There's a whole class of situations (especially in the x86 universe) when a device is partially operational. Two or more NICs, at least one has a driver onboard, at least one doesn't. I just went through this exact situation with someone on Reddit. Make the operational card WAN, go online, get pciutils, identify non-operational card(s), find out what driver(s) is (are) needed, install the driver(s)... Turns out my correspondent had a working igb card, but their other card needed kmod-sky2...

12

I would say yes

Possibly you can add your info to https://openwrt.org/docs/guide-user/installation/openwrt_x86 ?

ps: see also RFC: Wiki documentation for purpose-built x86-based firewall devices for thoughts about a similar subject

13

this would definitely help.
i was in this situation some days ago and e.g. after i installed the graphics driver for my intel n100 the temperature was way lower because only with the proper loaded driver all the power saving functions are working.

14

On first exposure, this makes sense, but upon consideration, I don't see it as an x86-only issue... This is something you could use on any target when, for example, upgrading Wi-Fi cards or adding USB devices. Also, as @efahl advised, there are multiple non-x86 targets where hardware discovery is relevant.

15

A draft of the proposed wiki page has been posted to a new thread:

[DRAFT] Hardware discovery and driver selection

This thread will be closed.

16

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.