Welcome to the very first objective of the LPI LPIC-1 Certification. I wish you luck and a speedy path to certification. Here we look at determining hardware on your system as well as configuring it. Maybe you have just been handed a running system to look after and you need to know all about it. The computer hardware is at the centre of Linux and of course,as a Linux administrator, you will need the basic grasp of how to manage and fault find the hardware. We have a total of three videos embedded in this page for to help you on your way to LPI certification.
BIOS
Starting a computer, you know, is just pushing the big power button. Entering the boot procedure the computer will normally boot to the computer’s BIOS, or Basic Input Out System. This is firmware that loads from components (EEPROMs) on the motherboard. Some newer systems since 2011 now have an EFI or UEFI system that may load from a special disk partition. To enter and configure the BIOS we often will need to press the designated key. This may be with the F2 , ESC, or F10 key but with a little luck, the required key will be displayed during the boot phase. From here we can configure the boot device. The hardware that we want to boot from. Perhaps we want to boot from the network card so we increase the boot priority on the NIC (Network Interface Card).
Running Linux as a server may require us not to have a keyboard plugged in. On some systems, this may cause an error and the system will not boot, there will normally be a BIOS setting where we can enable boot without the keyboard being present. Once Linux has booted then it does not use the BIOS anymore and even though some elements of an EFI system could be accessed, the Linux kernel does not make much use of EFI.
Interrupts
Starting with interrupts which are direct connections to the CPU (Central Processor Unit). Having these communication channels allow devices like the keyboard, timer, parallel port etc to talk to the CPU. It is called an interrupt as the device stops what the CPU is doing for its task to be handled. On Linux the interrupts to the processor are handled in the file: /proc/interrupts and even can show how many times an interrupt has bothered the CPU or CPUs if it is a multi-processor unit.
I/O Addressing
I/O (input / output) addressing or I/O ports are unique addresses within memory reserved for communication between specific devices and the CPU; so that when an interrupt is called the message is sent through the I/O port. In Linux, this is maintained through the /proc/ioports file and will list the memory address used by the associated hardware. From the following screenshot, we can see that the keyboard has the memory address 0060 and 0064 set aside for its sole use
DMA
Many systems now have depreciated i/o ports in favour of DMA or Direct Memory Address. Rather than the CPU having to be used to mediate the transfer of data to memory, this can be addressed directly with DMA channels. This process will free up CPU cycles and the system should run more efficiently. To view DMA channels in use on your Linux system we can view the /proc/dma file.
Connecting with the hardware
Hardware can be grouped into two sets, Cold Plug and Hot Plug. Cold plug devices are your typical expansion cards that are plugged inside of the computer when it is powered off. Hot-pluggable devices as the name suggests can be plugged into the running system Typically we see these as USB or Firewire devices. From out Linux command line we can see what PCI devices we have using the command:
lspci
Similarly, we can list devices on the USB bus with the command:
lsusb
Listing Hardware
There are many commands to list our hardware that all start with ls. We have seen lspci and lsusb, in addition, we have some other commands:
- lscpu: To list the CPUs we have.
- lsblk: Use to list the block devices, the disk and partitions we have.
USB Thumb Drives
We can also take note that as we connect, say a USB thumb drive, a device is created dynamically for it when we are using the Linux kernel 2.6 or later. This is controlled by the UDEV daemon. In earlier versions of the kernel, all device files would have to exist in the /dev directory although most of the time they will not be used. Now when I add a new drive a corresponding device file is created. We see in the video that we had just /dev/sda, then as we add the USB drive we see that /dev/sdb is created and then removed with the drive being ejected.
Loading Drivers
Of course for our software to be able to communicate with the device, we will need to load the drivers. In Linux, these are called modules and have a .ko (Kernel Modules) extension in the file-system. They tend to be loaded automatically as the hardware is detected but we can list and manage the modules ourselves. The associated commands are:
- lsmod
- insmod
- rmmod
- modprobe
We probably do not need to use insmod, to load a driver and rmmod to unload a driver anymore as these have been rolled into modprobe. The command lsmod will list loaded modules and reads this information from /proc/modules . If we are to use insmod to load a module it needs the full path to the module. This can be shown, on some systems, with modprobe -l . However, it is easy to load modules with modprobe without the full path:
modprobe pcspkr
This is certainly a lot easier than insmod:
insmod <fullpath to module file .ko>
The command rmmod can be used easily to unload loaded module from memory:
rmmod pcspkr
But if we stick with using just the one command then we can unload modules with modprobe:
modprobe -r pcspkr
Be aware that even if you do not use them you may be asked in the exam about rmmod and insmod. The video steps you through using the command on SUSE Linux. Finally, we look at how the user space programs access these devices, usually through the virtual sysfs mounted in the directory /sys, again the video will demonstrate this process.