Linux kernel supported hardware

Linux allocated devices (4.x+ version)В¶

This list is the Linux Device List, the official registry of allocated device numbers and /dev directory nodes for the Linux operating system.

This document is included by reference into the Filesystem Hierarchy Standard (FHS). The FHS is available from https://www.pathname.com/fhs/.

Allocations marked (68k/Amiga) apply to Linux/68k on the Amiga platform only. Allocations marked (68k/Atari) apply to Linux/68k on the Atari platform only.

This document is in the public domain. The authors requests, however, that semantically altered versions are not distributed without permission of the authors, assuming the authors can be contacted without an unreasonable effort.

DEVICE DRIVERS AUTHORS PLEASE READ THIS

Linux now has extensive support for dynamic allocation of device numbering and can use sysfs and udev ( systemd ) to handle the naming needs. There are still some exceptions in the serial and boot device area. Before asking for a device number make sure you actually need one.

To have a major number allocated, or a minor number in situations where that applies (e.g. busmice), please submit a patch and send to the authors as indicated above.

Keep the description of the device in the same format as this list. The reason for this is that it is the only way we have found to ensure we have all the requisite information to publish your device and avoid conflicts.

Finally, sometimes we have to play “namespace police.” Please don’t be offended. We often get submissions for /dev names that would be bound to cause conflicts down the road. We are trying to avoid getting in a situation where we would have to suffer an incompatible forward change. Therefore, please consult with us before you make your device names and numbers in any way public, at least to the point where it would be at all difficult to get them changed.

Your cooperation is appreciated.

Additional /dev/ directory entries¶

This section details additional entries that should or may exist in the /dev directory. It is preferred that symbolic links use the same form (absolute or relative) as is indicated here. Links are classified as “hard” or “symbolic” depending on the preferred type of link; if possible, the indicated type of link should be used.

Compulsory links¶

These links should exist on all systems:

stdin file descriptor

stdout file descriptor

stderr file descriptor

Required by iBCS-2

Required by iBCS-2

Recommended links¶

It is recommended that these links exist on all systems:

Alternate SCSI CD-ROM name

Locally defined links¶

The following links may be established locally to conform to the configuration of the system. This is merely a tabulation of existing practice, and does not constitute a recommendation. However, if they exist, they should have the following uses.

Current mouse device

Current tape device

Current CD-ROM device

Current CD-writer device

Current scanner device

Current dialout device

Current root filesystem

Current swap device

/dev/modem should not be used for a modem which supports dialin as well as dialout, as it tends to cause lock file problems. If it exists, /dev/modem should point to the appropriate primary TTY device (the use of the alternate callout devices is deprecated).

For SCSI devices, /dev/tape and /dev/cdrom should point to the cooked devices ( /dev/st* and /dev/sr* , respectively), whereas /dev/cdwriter and /dev/scanner should point to the appropriate generic SCSI devices (/dev/sg*).

/dev/mouse may point to a primary serial TTY device, a hardware mouse device, or a socket for a mouse driver program (e.g. /dev/gpmdata ).

Sockets and pipes¶

Non-transient sockets and named pipes may exist in /dev. Common entries are:

lpd local socket

syslog local socket

gpm mouse multiplexer

Mount points¶

The following names are reserved for mounting special filesystems under /dev. These special filesystems provide kernel interfaces that cannot be provided with standard device nodes.

PTY slave filesystem

POSIX shared memory maintenance access

Terminal devices¶

Terminal, or TTY devices are a special class of character devices. A terminal device is any device that could act as a controlling terminal for a session; this includes virtual consoles, serial ports, and pseudoterminals (PTYs).

All terminal devices share a common set of capabilities known as line disciplines; these include the common terminal line discipline as well as SLIP and PPP modes.

All terminal devices are named similarly; this section explains the naming and use of the various types of TTYs. Note that the naming conventions include several historical warts; some of these are Linux-specific, some were inherited from other systems, and some reflect Linux outgrowing a borrowed convention.

A hash mark ( # ) in a device name is used here to indicate a decimal number without leading zeroes.

Virtual consoles and the console device¶

Virtual consoles are full-screen terminal displays on the system video monitor. Virtual consoles are named /dev/tty# , with numbering starting at /dev/tty1 ; /dev/tty0 is the current virtual console. /dev/tty0 is the device that should be used to access the system video card on those architectures for which the frame buffer devices ( /dev/fb* ) are not applicable. Do not use /dev/console for this purpose.

The console device, /dev/console , is the device to which system messages should be sent, and on which logins should be permitted in single-user mode. Starting with Linux 2.1.71, /dev/console is managed by the kernel; for previous versions it should be a symbolic link to either /dev/tty0 , a specific virtual console such as /dev/tty1 , or to a serial port primary ( tty* , not cu* ) device, depending on the configuration of the system.

Serial ports¶

Serial ports are RS-232 serial ports and any device which simulates one, either in hardware (such as internal modems) or in software (such as the ISDN driver.) Under Linux, each serial ports has two device names, the primary or callin device and the alternate or callout one. Each kind of device is indicated by a different letter. For any letter X, the names of the devices are /dev/ttyX# and /dev/cux# , respectively; for historical reasons, /dev/ttyS# and /dev/ttyC# correspond to /dev/cua# and /dev/cub# . In the future, it should be expected that multiple letters will be used; all letters will be upper case for the “tty” device (e.g. /dev/ttyDP# ) and lower case for the “cu” device (e.g. /dev/cudp# ).

The names /dev/ttyQ# and /dev/cuq# are reserved for local use.

The alternate devices provide for kernel-based exclusion and somewhat different defaults than the primary devices. Their main purpose is to allow the use of serial ports with programs with no inherent or broken support for serial ports. Their use is deprecated, and they may be removed from a future version of Linux.

Arbitration of serial ports is provided by the use of lock files with the names /var/lock/LCK..ttyX# . The contents of the lock file should be the PID of the locking process as an ASCII number.

It is common practice to install links such as /dev/modem which point to serial ports. In order to ensure proper locking in the presence of these links, it is recommended that software chase symlinks and lock all possible names; additionally, it is recommended that a lock file be installed with the corresponding alternate device. In order to avoid deadlocks, it is recommended that the locks are acquired in the following order, and released in the reverse:

The symbolic link name, if any ( /var/lock/LCK..modem )

The “tty” name ( /var/lock/LCK..ttyS2 )

The alternate device name ( /var/lock/LCK..cua2 )

In the case of nested symbolic links, the lock files should be installed in the order the symlinks are resolved.

Under no circumstances should an application hold a lock while waiting for another to be released. In addition, applications which attempt to create lock files for the corresponding alternate device names should take into account the possibility of being used on a non-serial port TTY, for which no alternate device would exist.

Pseudoterminals (PTYs)В¶

Pseudoterminals, or PTYs, are used to create login sessions or provide other capabilities requiring a TTY line discipline (including SLIP or PPP capability) to arbitrary data-generation processes. Each PTY has a master side, named /dev/pty[p-za-e][0-9a-f] , and a slave side, named /dev/tty[p-za-e][0-9a-f] . The kernel arbitrates the use of PTYs by allowing each master side to be opened only once.

Once the master side has been opened, the corresponding slave device can be used in the same manner as any TTY device. The master and slave devices are connected by the kernel, generating the equivalent of a bidirectional pipe with TTY capabilities.

Recent versions of the Linux kernels and GNU libc contain support for the System V/Unix98 naming scheme for PTYs, which assigns a common device, /dev/ptmx , to all the masters (opening it will automatically give you a previously unassigned PTY) and a subdirectory, /dev/pts , for the slaves; the slaves are named with decimal integers ( /dev/pts/# in our notation). This removes the problem of exhausting the namespace and enables the kernel to automatically create the device nodes for the slaves on demand using the “devpts” filesystem.

© Copyright The kernel development community.

Источник

Linux kernel supported hardware

Ubuntu does not impose hardware requirements beyond the requirements of the Linux kernel and the GNU tool-sets. Therefore, any architecture or platform to which the Linux kernel, libc, gcc , etc. have been ported, and for which an Ubuntu port exists, can run Ubuntu.

Rather than attempting to describe all the different hardware configurations which are supported for PowerPC , this section contains general information and pointers to where additional information can be found.

2.1.1.В Supported Architectures

Ubuntu 20.04 supports six major architectures and several variations of each architecture known as “ flavors ” . One other architecture (IBM/Motorola PowerPC) has an unofficial port.

Architecture	Ubuntu Designation	Subarchitecture	Flavor
Intel x86-based	i386	В	В
AMD64 & Intel 64	amd64	В	В
ARM with hardware FPU	armhf	multiplatform	generic
		multiplatform for LPAE-capable systems	generic-lpae
64bit ARM	arm64	В	В
IBM POWER Systems	ppc64el	IBM POWER8 and newer machines	В
IBMВ z/Architecture	powerpc	IBM Z and IBM LinuxONE, no s390 (31-bit mode) support	zEC12 and newer machines

2.1.2.В CPU, Main Boards, and Video Support

For Ubuntu 20.04 only the PMac (Power-Macintosh or PowerMac) and PreP subarchitectures are supported.

2.1.2.1.В Kernel Flavours

There are two flavours of the powerpc kernel in Ubuntu, based on the CPU type:

This kernel flavour supports the PowerPC 601, 603, 604, 740, 750, and 7400 processors. All Apple PowerMac machines up to and including the one marketed as G4 use one of these processors.

All Apple PowerMac G4 SMP machines.

The powerpc64 kernel flavour supports the following CPUs:

The POWER3 processor is used in older IBM 64-bit server systems: known models include the IntelliStation POWER Model 265, the pSeries 610 and 640, and the RS/6000 7044-170, 7043-260, and 7044-270.

The POWER4 processor is used in more recent IBM 64-bit server systems: known models include the pSeries 615, 630, 650, 655, 670, and 690.

Systems using the PPC970 processor (Apple G5, YDL PowerStation, IBM Intellistation POWER 185) are also based on the POWER4 architecture, and use this kernel flavour.

Newer IBM systems using POWER5, POWER6, and POWER7 processors.

2.1.2.2.В Power Macintosh (pmac) subarchitecture

Apple (and briefly a few other manufacturers — Power Computing, for example) made a series of Macintosh computers based on the PowerPC processor. For purposes of architecture support, they are categorized as NuBus (not supported by Ubuntu), OldWorld, and NewWorld.

OldWorld systems are most Power Macintoshes with a floppy drive and a PCI bus. Most 603, 603e, 604, and 604e based Power Macintoshes are OldWorld machines. Those pre-iMac PowerPC models from Apple use a four digit naming scheme, except for the beige colored G3 systems, which are also OldWorld.

The so called NewWorld PowerMacs are any PowerMacs in translucent colored plastic cases and later models. That includes all iMacs, iBooks, G4 systems, blue colored G3 systems, and most PowerBooks manufactured in and after 1999. The NewWorld PowerMacs are also known for using the “ ROM in RAM ” system for MacOS, and were manufactured from mid-1998 onwards.

Specifications for Apple hardware are available at AppleSpec, and, for older hardware, AppleSpec Legacy.

Источник

Linux kernel supported hardware

Ubuntu does not impose hardware requirements beyond the requirements of the Linux kernel and the GNU tool-sets. Therefore, any architecture or platform to which the Linux kernel, libc, gcc , etc. have been ported, and for which an Ubuntu port exists, can run Ubuntu.

Rather than attempting to describe all the different hardware configurations which are supported for 32-bit hard-float ARMv7 , this section contains general information and pointers to where additional information can be found.

2.1.1.В Supported Architectures

Ubuntu 20.04 supports six major architectures and several variations of each architecture known as “ flavors ” . One other architecture (IBM/Motorola PowerPC) has an unofficial port.

Architecture	Ubuntu Designation	Subarchitecture	Flavor
Intel x86-based	i386	В	В
AMD64 & Intel 64	amd64	В	В
ARM with hardware FPU	armhf	multiplatform	generic
		multiplatform for LPAE-capable systems	generic-lpae
64bit ARM	arm64	В	В
IBM POWER Systems	ppc64el	IBM POWER8 and newer machines	В
IBMВ z/Architecture	armhf	IBM Z and IBM LinuxONE, no s390 (31-bit mode) support	zEC12 and newer machines

2.1.2.В Variations in ARM CPU designs and support complexity

ARM systems are much more heterogeneous than those based on the i386/amd64-based PC architecture, so the support situation can be much more complicated.

The ARM architecture is used mainly in so-called “ system-on-chip ” (SoC) designs. These SoCs are designed by many different companies with vastly varying hardware components even for the very basic functionality required to bring the system up. System firmware interfaces have been increasingly standardised over time, but especially on older hardware firmware/boot interfaces vary a great deal, so on these systems the Linux kernel has to take care of many system-specific low-level issues which would be handled by the mainboard’s BIOS in the PC world.

At the beginning of the ARM support in the Linux kernel, the hardware variety resulted in the requirement of having a separate kernel for each ARM system in contrast to the “ one-fits-all ” kernel for PC systems. As this approach does not scale to a large number of different systems, work was done to allow booting with a single ARM kernel that can run on different ARM systems. Support for newer ARM systems is now implemented in a way that allows the use of such a multiplatform kernel, but for several older systems a separate specific kernel is still required. Because of this, the standard Ubuntu distribution only supports installation on the newer systems which are supported by the ARM multiplatform kernels in Ubuntu/armhf.

2.1.3.В Platforms supported by Debian/armhf

The following systems are known to work with Ubuntu/armhf using the multiplatform (armmp) kernel:

The IMX53QSB is a development board based on the i.MX53 SoC.

The Versatile Express is a development board series from ARM consisting of a baseboard which can be equipped with various CPU daughter boards.

Certain Allwinner sunXi-based development boards and embedded systems

The armmp kernel supports several development boards and embedded systems based on the Allwinner A10 (architecture codename “ sun4i ” ), A10s/A13 (architecture codename “ sun5i ” ) and A20 (architecture codename “ sun7i ” ) SoCs. Full installer support is currently available for the following sunXi-based systems:

Cubietech Cubieboard 1 + 2 / Cubietruck

LeMaker Banana Pi and Banana Pro

LinkSprite pcDuino and pcDuino3

Olimex A10-Olinuxino-LIME / A10s-Olinuxino Micro / A13-Olinuxino / A13-Olinuxino Micro / A20-Olinuxino-LIME / A20-Olinuxino-LIME2 / A20-Olinuxino Micro

PineRiver Mini X-Plus

System support for Allwinner sunXi-based devices is limited to drivers and device-tree information available in the mainline Linux kernel. The android-derived linux-sunxi.org 3.4 kernel series is not supported by Ubuntu.

The mainline Linux kernel generally supports serial console, ethernet, SATA, USB and MMC/SD-cards on Allwinner A10, A10s/A13 and A20 SoCs, but it does not have native drivers for the display (HDMI/VGA/LCD) and audio hardware in these SoCs. The NAND flash memory that is built into some sunXi-based systems is not supported.

Using a local display is technically possible without native display drivers via the “ simplefb ” infrastructure in the mainline kernel, which relies on the “ U-Boot ” bootloader for initialising the display hardware.

SolidRun Cubox-i2eX / Cubox-i4Pro

The Cubox-i series is a set of small, cubical-shaped systems based on the Freescale i.MX6 SoC family. System support for the Cubox-i series is limited to drivers and device-tree information available in the mainline Linux kernel; the Freescale 3.0 kernel series for the Cubox-i is not supported by Ubuntu. Available drivers in the mainline kernel include serial console, ethernet, USB, MMC/SD-card and display support over HDMI (console and X11). In addition to that, the eSATA port on the Cubox-i4Pro is supported.

The Wandboard Quad is a development board based on the Freescale i.MX6 Quad SoC. System support for it is limited to drivers and device-tree information available in the mainline Linux kernel; the wandboard-specific 3.0 and 3.10 kernel series from wandboard.org are not supported by Ubuntu. The mainline kernel includes driver support for serial console, display via HDMI (console and X11), ethernet, USB, MMC/SD and SATA. Support for the onboard audio options (analog, S/PDIF, HDMI-Audio) and for the onboard WLAN/Bluetooth module is not available in Ubuntu 20.04.

Generally, the ARM multiplatform support in the Linux kernel allows running debian-installer on armhf systems not explicitly listed above, as long as the kernel used by debian-installer has support for the target system’s components and a device-tree file for the target is available. In these cases, the installer can usually provide a working installation, but it may not be able to automatically make the system bootable. Doing that in many cases requires device-specific information.

When using debian-installer on such systems, you may have to manually make the system bootable at the end of the installation, e.g. by running the required commands in a shell started from within debian-installer .

2.1.4.В Multiple Processors

Multiprocessor support — also called “ symmetric multiprocessing ” or SMP — is available for this architecture. The standard Ubuntu 20.04 kernel image has been compiled with SMP-alternatives support. This means that the kernel will detect the number of processors (or processor cores) and will automatically deactivate SMP on uniprocessor systems.

Having multiple processors in a computer was originally only an issue for high-end server systems but has become common in recent years nearly everywhere with the introduction of so called “ multi-core ” processors. These contain two or more processor units, called “ cores ” , in one physical chip.

2.1.5.В Graphics Hardware Support

Ubuntu’s support for graphical interfaces is determined by the underlying support found in X.Org’s X11 system, and the kernel. Basic framebuffer graphics is provided by the kernel, whilst desktop environments use X11. Whether advanced graphics card features such as 3D-hardware acceleration or hardware-accelerated video are available, depends on the actual graphics hardware used in the system and in some cases on the installation of additional “ firmware ” images (see SectionВ 2.2, “Devices Requiring Firmware”).

Nearly all ARM machines have the graphics hardware built-in, rather than being on a plug-in card. Some machines do have expansion slots which will take graphics cards, but that is a rarity. Hardware designed to be headless with no graphics at all is quite common. Whilst basic framebuffer video provided by the kernel should work on all devices that have graphics, fast 3D graphics invariably needs binary drivers to work. The situation is changing quickly but at the time of the focal release free drivers for nouveau (Nvidia Tegra K1 SoC) and freedreno (Qualcomm Snapdragon SoCs) are available in the release. Other hardware needs non-free drivers from 3rd parties.

Details on supported graphics hardware and pointing devices can be found at http://xorg.freedesktop.org/. Ubuntu 20.04 ships with X.Org version 7.7.

2.1.6.В Network Connectivity Hardware

Almost any network interface card (NIC) supported by the Linux kernel should also be supported by the installation system; drivers should normally be loaded automatically.

On 32-bit hard-float ARMv7 , most built-in Ethernet devices are supported and modules for additional PCI and USB devices are provided.

2.1.7.В Peripherals and Other Hardware

Linux supports a large variety of hardware devices such as mice, printers, scanners, PCMCIA/CardBus/ExpressCard and USB devices. However, most of these devices are not required while installing the system.

Источник