artificial intelligence; automatic HW identification and driver download

[Sashank999]

I started to think that this isn't possible.
We could use lspci and lsusb with updated pci.ids and usb ids so that we could get the name of the wireless device.
Then we should manually :
Find the chipset of the driver using Google.
Go here : https://en.wikipedia.org/wiki/Comparison_of_open-source_wireless_drivers and find the correct driver fro the chipset.
Get the driver from the tczs in the repo.

[ladnar]

I was starting to think it WAS/IS possible. At the very least, a simple bash script could combine all these functions, weed out the unnecessary info, and put all your hardware IDs in one file, for easy reference.

I woke up this morning with half a bash script in my head ...

And stumbled on this page too ...

https://linux.die.net/sag/hwutils.html

So, here's a start. You'll notice that my code is both lazy and stupid (not to mention, non-functional; just an outline of an idea.). I will work on it in my "down time", but I have a cluster computer to build and have to learn USB gadget, RNDIS, cdc ethernet, MACaddress, Static IP,  LKM/.ko module updates, etc. , etc.

Also note, this is just to list things in one easy place. I wouldn't know how to set it up to crawl the internet to grab the needed drivers.

SHEBANG!

Code: [Select]


#! /bin/bash

cd /

lshw

#grepping

lspci

#catting

lsusb

#listing and saving in a .txt file

lsblk

#more grepping

lscpu

#more listing

lsmem

# etc, etc , etc

cat /proc/cpuinfo

blkid

fdisk -l


I feel like shell scripts should end with a special statement, too? Like, maybe #K@Z@m! But like I said, I am just a biologist; an outsider. You are under no obligation to listen to my suggestions. Maybe I will just put it in behind a "#", thus commented out! I could start a trend, or fad, in shell scripting!

Downside to a shell script? Wikipedia says :

"Another significant disadvantage is the slow execution speed and the need to launch a new process for almost every shell command executed. When a script's job can be accomplished by setting up a pipeline in which efficient filter commands perform most of the work, the slowdown is mitigated, but a complex script is typically several orders of magnitude slower than a conventional compiled program that performs an equivalent task.

There are also compatibility problems between different platforms. Larry Wall, creator of Perl, famously wrote that "It is easier to port a shell than a shell script."   "

[ladnar]

Last month I was studying Linux  ports. Not receptacles, of a physical nature, but "conceptual ports". Conceptual sockets. Networking ports and sockets. I forgot everything I learned, but will tackle it again, soon.

The stupid-lazy script I offered above, would ideally access such ports; listening and/or "polling" such ports. The "extended hardware" ... ?

But I suppose, maybe not? Once the kernel and brains have found a port, it is safe to say the kernel has found all the hardware it needs in order to talk through that port. And the kernel is not querying other machines about their hardware and drivers? And if it does, it relies on the other computer to know its own devices and hardware and drivers. So, probably not.

Also, on another note; like picore11 doesn't have blkid. Maybe some kind of loop to skip it? Or a simple, non-verbose line printed to CLI explaining which commands, of the long list of hardware listing commands, were not performed?

Also, I know nothing of dstat, but maybe? My kali linux laptop doesn't have it. But a quick check online says it replaces iostat, vmstat, netstat, etc. Kali DOES have those. But they seem more like "function-assessment" utilities, not "absence or presence" , enumeration utilities.

[ladnar]

Some careful grepping and catting of dmesg could glean part #s and manufacturer #s.

[Rich]

Hi ladnar

... Also, on another note; like picore11 doesn't have blkid. ...

Are you sure? Do you get the same response for this command:

Code: [Select]

tc@box:~$ which blkid
/sbin/blkid
tc@box:~$
The  shebang  should not be written like this:

Code: [Select]

#! /bin/bash
It should always be the first line in the script and written like this:

Code: [Select]

#!/bin/bashYes, it will still run if it is not the first line.
Yes, it will still run with the extra space.
Yes, it will cause failures if a program needs to determine whether your file is a script.
No, you should no longer visit the website that taught you that bad habit.

... I see the thread has moved for being OT. I blame myself. ...

You only served as a reminder. I should have moved it in July when it was started.

[ladnar]

Thanks Rich. I have had too much coffee and not enough sleep. I think I will stop posting and have a mid-morning nap.

Good advice on the shebang. I probably just mis-learned it, not taught wrong.

I will try "which blkid" after a nap.

In the interest of staying on topic, I re-read all the messages. I was missing some subtle points from sashank999, and some subtleties of the whole topic in general. If the CPU doesn't have a driver, and thus a way to communicate with the hardware, how does it know what hardware is there and which driver it needs?

Good question.

I think xor is making the point that there is some low-level communication that allows for this. I don't know if lshw and lspci and etc. respond to this "low level" signaling? Is it a smart enough signaling to tell, to the cpu, the peripheral/hardware device manufacturer number and product id? I have to assume xor knows what he is talking about.

With my cluster computer problem, I am using ethernet gadget USB. Last night I was studying OTG wires (something I embarrassingly neglected before this moment), and crucial to this implementation is a pin that is left floating if the wire is inserted one way, but grounded when inserted another way. This signals the USB controller(s) (chips), determining which chip will be the master (host) and which the slave (device). Once this low-level signaling occurs, this physical configuration established, the chips can begin to initiate the bus. This is just an example; admittedly an indistinct example. Just an example of low-level, hardware signaling that occurs before "speaking" to the cpu through a driver (I am pretty certain the USB chips set this up as soon as they are plugged in, with no input from the cpu or drivers. I could be wrong? But I figure once the chips get the simple stuff out of the way, the CPU and driver can start telling the USB controller what to do, what to send and what to receive.)

Ethernet gadget mode requires extra software; LKM, .ko modules, loaded? / interfaced? with the kernel. But now I am very OT; obsessed with my bramble-pi cluster!

So to summarize, hardware, when it is plugged in, can signal simple things like "ground on this wire", or "power on this wire". Beginning with simple things like this, one or two transistors might flip, and begin some low-level "Hello, I am here. My name is XYZ. the company that made me is ABC."-type communication. "Handshaking" type stuff. Does lspci and lshw and etc have THIS information? Or must one "dig deeper" to access this info?

I DEFINITELY don't know. Do you? (OK, its 7:30 Pacific time; up since 3 AM; must nap now.).

[mocore]

...

So to summarize, hardware, when it is plugged in, can signal simple things like "ground on this wire", or "power on this wire". Beginning with simple things like this, one or two transistors might flip, and begin some low-level "Hello, I am here. My name is XYZ. the company that made me is ABC."-type communication. "Handshaking" type stuff. Does lspci and lshw and etc have THIS information? Or must one "dig deeper" to access this info?

I DEFINITELY don't know. Do you? (OK, its 7:30 Pacific time; up since 3 AM; must nap now.).

all i know is that i know nothing ! .. but after reading the hw/usb speculation in this topic , and searching i found a diagram* in a 'book'

https://sysplay.github.io/books/LinuxDrivers/book/Content/Part11.html ( copy @ https://i.imgur.com/rcCRJYF.png )



+ wrt   kernal/usb  https://www.kernel.org/doc/html/latest/usb/index.html
.. and a few other random linux usb documentation links ,
 - https://www.kernel.org/doc/html/v4.13/driver-api/usb/writing_usb_driver.html
 - ( Docs » The Linux driver implementer's API guide » Linux USB API » The Linux-USB Host Side API )

this https://wiki.linuxaudio.org/wiki/raspberrypi#usb_audio
also springs to mind , as an example of one microcosm of (raspberry/hw) implementation specific ambiguity and fun

eg > The RPi has a USB2.0 controller that apparently can cause issues with USB1.1 audio interfaces.

( see pi forums kernel / firmware "issues" for more `depth` ;- )

[ladnar]

Its lsblk that picore does not have. blkid is there. There is a list of utilities that come with Busybox on the internet somewhere. I might be curious enough to check and see if lsblk is on there somewhere? Maybe I'll check the list of available tcz's (extensions?) too?

[ladnar]

Thanks mocore.

I should have warned you. I hate every diagram about USB that I have ever encountered. Every last one of them is as clear as mud. As the son of a "copper-wire-twisted-pair-dinosaur-from-the-telephony-days" (telegraph, single wire, earth-return? Say it ain't so!), I have to say that these companies who write up the textbooks took a nice simple elegant topic and futz-ed it all up!

Differential signaling on twisted pair doesn't have to be rocket science. I bought 4 books on the subject, looking for a straight answer about "what does the signal look like", and I got a whole lot of "J and K" nonsense. That's not to say that the books were wrong; It just took four books, and 60 chapters to say what could have been summed up in three introductory chapters.

But, of course, it is an evolving standard, and it is complex, so I can cut them some slack. The best one I found was McDowell and Seyer (about 75% good information), but some of the things (the other 25%) they should have included I had to find in Jan Axelson's books (I owned 3 of hers!).

[Rich]

Hi ladnar

Its lsblk that picore does not have. ...

According to this list, installing  util-linux.tcz  will provide that function:
http://tinycorelinux.net/11.x/armv6/tcz/util-linux.tcz.list

... There is a list of utilities that come with Busybox on the internet somewhere. I might be curious enough to check and see if lsblk is on there somewhere? ...

To see which  busybox  commands have been enabled, run these 2 commands:

Code: [Select]

busybox
busybox.suid

[Greg Erskine]

hi ladnar,

A couple of points:

Bash may not be loaded by default. If not use #!/bin/sh

"exit" is the end command in a script. exit 0 is implied. Stick it in if you like.

Script speed is relative. piCorePlayer uses 30,000 lines of shell as a http CGI, performance is more than adequate.

Seeing "chmod 777" raises alarm bells to me!!

[ladnar]

Seeing "chmod 777" raises alarm bells to me!!

I knew I was being bad. But with an OS that lives on RAM (and a coupla blank uSD cards in my pocket) I am living dangerously.

And, technically, Asimov's three rules of robotics aren't broken. Firstly, I do not need a "worker" or "slave", as the Czech word "robota" would imply (Rossum's Universal Robots, circa 1925, Karel Capek). I am more in the vein of Homer's Illiad and/or Odyssey; Hephasteus, Tripods, and Golden Girls for a blacksmith's apprentice. Its an older dream, than our recent nightmares. Vacaunson's digestive duck, perhaps?

What, for curiosities sake, is the worst that chmod 777 can do, on a RAM resident OS, air gap, SBC?

(My robotics obsession began around 2003, after reading Noam Chomsky's "Syntactic structures" and Daniel  Dennett's "Darwin's Dangerous Idea". I decided "Syntax is for the birds" and "Semantics is where it's at". I was also reading Hume's discussion of "impressions" and "ideas", and Paul Thompson's book "The Structure of Biological Theories", wherein he discusses the Syntactic conception of theory structure, vs. his preferred embodiment, the Semantic formalization. I won't pretend to have understood it all (I think I am a Syntactic person, when it comes to formal theories, but I appreciate a little "Semantic looseness" everywhere else!), but I somehow got it in my head that VN^2=S ; That is, for an Aritficial or Natural Intelligence possessing N number of Nouns and V number of Verbs, VN^2 number of simple semantic sentences, S, was the maximum that could be intelligently composed. A lovely little permutation derivation, if ever there was one.

Of course the INTELLIGENT intelligent sentences are a much smaller subset than S would imply. intelligence is, after all, situational. So, I guess its simple then, huh? All we have to do is make a device that CAN speak all of the sentences, S, but, for various reasons, chooses not to. Easey Peasey, right?)

Is it either or /bash or /sh ? Or, preferably /sh, unless you know its going to be /bash, then there's some benefit to having /bash? Which is more popular; or should I just check every script I run and remember what machine I am on, i.e. what shell I'm using? Cuz I switch machines sometimes; it gets confusing for newbies?

Thanks Greg,

#Sh@z@m!
exit

[Sashank999]

If you are writing scripts only for TCL, use sh. "sh" means the default shell in the Linux System. For TCL, it is "ash" https://linux.die.net/man/1/ash
For may GNU/Linux distros, it is "bash" https://linux.die.net/man/1/bash
Bash has more features like arrays than ash. Moreover, bash can be easily found in any distro. So, cross-distro scripts are to be created in bash (my opinion).
If you are switching distros, use bash. But I personally recommend sh or ash on TCL and my infocreator script work is based on ash of TCL.
If anyone is interested in this thread, see this : https://wiki.manjaro.org/index.php/Manjaro_Hardware_Detection_Overview .
It is an implementation of this thread in Manjaro Linux. I know nothing about C or C++ so if anyone knows them, you can see here.

[xor]

philosophical approach
There are 2 types of linux distributions.
first one; turnkey all-in-one (including redundant drives)
the second; do it yourself linux
common feature of both
their inability to respond to realistic needs on time and instantly.
not everyone can create linux themselves.
usually turns to turnkey model.
therefore, loss of time and efficiency is inevitable.
The whole linux configuration I have created in my mind is actually about my process of finding and discovering the right file in the repository archive.
Installing the drivers before the software the user will deal with is one of the top priorities and one of the most blindly tedious operations.
the hardware id is already communicating with the motherboard bios all the time.
communicates over this identification number. this is already the most basic drive format. and naturally this hardware is its own DNA structure.
hardware already provides the most basic communication at the bios level.
the opening purpose of this topic; with minimalist approaches
The thought of creating a minimalist linux experience where less trouble to the end user or even a hassle-free!

minimalist linux distributions are often an experience-based usage. Of course, getting to this point is for me;
After at least 10 different Linux distributions,
and if you pay attention to my forum membership date,
After 10 years, I could tell the big difference TCL between other linux.

The essence of the event is briefly;
bios data is literally a fixed id that is accessible
it needs a hard drive.
For this, the correct file needs to be downloaded from the repository.
doing this manually takes experience. even if it's simple
how can this be automated.

define the variable constant and download the required software.

[xor]

the upper text; It was translated to English with google translation.