The official repositry for Linux documentation is the Linux Documentation Project which we will refer to simply as LDP. Note that most standard linux installations include a lot of this documentation under the path /usr/doc, whilst man pages can be seen by using the command 'man whatever' (many distros also include facilities for browsing documentation in HTML). In any case, if you cannot find the HOWTO or manpage on your own system, then you will always find the most up to date version at LDP. This site also has links that will help you find non-english versions of the documents.
At the end of this document you will find a list of links to other embedded resources.
Embedded systems tend to be highly efficient and customised. In order to achieve such goals a good general knowledge of the operating system is essential. Most of what is required for an embedded Linux system will be found in a normal general purpose Linux distribution, so the best way to build up your Linux knowledge is to start using it for your everyday tasks, such as reading this FAQ;-)
Most Linux distributions designed for general purpose use are designed to be as plug-and-play as possible, and hide a lot of administration and configuration from the user. Allthougth this is generaly a good thing, if your eventual aim is to use embedded systems, you may like to consider Slackware which is very much a DIY distribution. For more general information on Linux as opposed to embedding:
These sites may also help you find Local user groups (LUG's), non english sites, and newsgroups/mailing lists for more genral questions such as "Why will X windows not start"
Linux distributions generaly fall into one of three broad categories. Standard general purpose distibutions (Red Hat, Suse, Turbo, Cladera etc). Distributions designed for specific purposes such as a secure web server or a Linux based router, and minimalist distributions (several of these fit on a single floppy).
If there is a distribution specificaly designed for what you are trying to do, then that is obviously a good starting point, otherwise you have the choice of trimming down a big general purpose distribution or building up a minimalistic one. The latter approach is probably the most desirable approach, as you know exactly what is going in. Cutting down a big distro runs the risk of breaking things you did not even know were present.
Need good sites with catalouges of distros
Need references to distros of particular interest to embedders
linux-embedded.com - Distributions for embedders
linux-embedded.com - Tiny distributions
Make the kernel as small as possible by putting as much as possible into modules which can be inserted later. Supply specific hardware parameters to the kernel so that it does not need to probe values. You may also reduce tasks that init launches at boot, see How do I control what gets started at boot?
Everybodies favourite tips please!
I think we could do with a mini howto here, which we put in LDP and reference
To boot from CDROM you need to use the El Torito standard. This is covered in normal CD-R documentation, see the LDP CD-Writing-HOWTO and the mkisofs manpage.
Booting over a network will require that your network adapter has a 'bios' for using the bootp protocol. Full details will be found in the Diskless mini-HOWTO. The NFS-root and NFS-root-client mini-HOWTOS explain how you may use a network for the main (root) filesystem and eliminate local drives alltogether.
When the Linux kernel boots, it invokes a program called init which in turn launches everything else, primarily based on the information in /etc/innitab. A short explanantion of init will be found in the LDP System administration guide, whilst a detailed description will be found using man init and man inittab.
In embedded systems where various application process are required to be continuously running, the parent process may be invoked by inserting it in the inittab file such that it will be relaunched if it dies. This parent process may then be used for monitoring other application processes.
Init is normally set up to invoke specific scripts as it passes from one runlevel to another (normally on start up and shutdown). These scripts are described in inittab, allthougth by convention they are placed under /etc/rc.d, and user scripts may be linked in to these to carry out specific tasks at boot or shutdown.
Note that in many distros these scripts are implemented automaticly by the system administration tools, you should read the distro specific documentation to find out the correct way to link in user scripts.
Cover inittab etc.
Good question this, answers? mini-howtos?
Who knows the state of the art?
Some solid state disks are designed to mimic IDE interfaces, and may be used with normal IDE drivers. Other 'memory disk cards' or SSD's incorporated on processor boards etc. have direct memory and/or portmapped interfaces, or use other proprietry techniques. These require special drivers, but with the ever growing interest in the use of Linux in embedded systems most manufacturers now supply Linux drivers or at least make the interface details available such that others may develop drivers. One way of using SSD's is by providing a PCMCIA interface. Such devices are supported by Linux as standard, see LDP PCMCIA-HOWTO. The most common type of SSD is based on flash memory. Allthougth this provides the cheapest per byte solution it is essentially a read most technology, writing is subject to severe limitations. For files that must be regularly modified SRAM based cards are often deployed. As SRAM solutions are expensive and have limited capacity a harddisk free system is likely to require both. This may be implemented by basing the filesystem on the flash device and simply including symbolic links to specific directories or files that reside on the SRAM device. See also the ramdisk section of this document.
By running applications with user priviledges, much protection against corrupting critical system files is inherent, and by running your apps at normal user level much protection against system corruption is possible. The Linux filesystem is laid out along standard lines that are broadly similar to all UNIX systems and are defined in the Linux file system standard (see LDP). In this layout, data files, configuration files, and program binaries and libraries are kept in seperate areas, and as a result most of a Linux file system may be mounted RO during a normal session. User data files, browser cache, mailboxes, whatever, reside within the users home directory. Tempory files are placed in /tmp, whilst other system files that may vary during normal sessions (such as print spools, system logs etc), will be placed under the /var tree. Thus only the /home, /tmp and /var directiories need be ordinarily mounted RW. It is possible to place these directories on seperate partitions, or alternativly symbolic links may be used. See also ramdisks. In many applications it may be possible to use read-only media, as opposed to a hard disk mounted read only, in particular by booting from a write protected floppy (yes, some useful embbeded systems can be entirely contained on a floppy), or by booting from a CDROM. Such a technique makes system corruption, even by hackers, impossible, except for temporary corruption. When the system re-boots, it always parts from a known state. .....other suggestions please!
Ramdisks are extensively used in Linux systems not only for specialist applications but also for the basic install. Ramdisks must be enabled in the kernel, and details of how to set up a system with a Ramdiskwill be found in the kernel documentation file ramdisk.txt.
Ramdisks are able to resolve a lot of problems in minimal systems, especially were hard disks are not present. DRAM memory is much cheaper than Static RAM and flash memory, and althougth it is volatile, the hard disk is commonly used also for data storage which need not necessarily be maintained. Also, flash memory is not suitable for data that is frequemtly written such as a printer queue.
The /tmp directory is an obvious canditate for placing on ramdisk, less obvious candidates are printer ques and message logs. Allthougth a traditional system will maintain the contents of these (so e.g. an unprinted document may be sent after the machine is re-booted), in most embedded systems it would be acceptable, even desirable, to loose this information.
As noted elsewhere in this FAQ, we may boot a system from CDROM or over a network, and allthougth this is functional and often used, sometimes speed may be a problem, or it may desirable that the CDROM device 'powers-down' after a boot. In such situations, it is possible to create the filesystem at boot by copying it over from the CD or network, and in such a scenario, much time may be saved by using a compressed image of the filesystem.
Organising a 'hybrid' filesystem composed of a mixture of ramdisk and flash/network drives may be done with two different strategies, both relying on symbolic links. In the first method (which minimises the size of the ramdisk), our main root filesystem remains that of the flash/network drive, and we simply include symbolic links to the ramdisks for directories such as /tmp and the printer spool.
An alternative method (generally better if there is no great problem having a large DRAM module), is to make the ramdisk the root partition and include in this filesystem symbolic links to flash/net based directories/files were important variable data is to be held. The ramdisk.txt file also explains how the kernel can automaticly set up such a filsystem at boot from a compressed image file.
How can you load the ramdisk image over a network?
Some BIOS's will not allow this. If they do then in kernels 2.2.x upwards there is support for using the serial port as the primary 'console'. In the development series 2.3.x (and hence in the upcoming 2.2.4 stable release), there is support for using the printer port as cosole output. This is particularly useful for remote unantended machines, as a printed log allows maintence personal to quickly evaluate the situ\uation.
Well, whats your favourite input gadget? I would like links to devices that people have deployed.
First of all there is the normal console, which is not limited to text (at least on x86 versions of Linuxi), but can do vga graphics as well. See man svgalib for details of a programming library which will give you (as the name suggests;-) access to super vga like graphics on a raw PC console. This library is very similar to the Borland BGI library, which was widely used for graphical DOS based programs. Many people have extended this super vga base with GUI libraries and tools for graphical dialogs, pop up windows, jpeg images etc. If you are doing a very simple interface with just a few options per screen in big letters etc., it is possible to set custom screen fonts and screen sizes to get good quality large text without resorting to svgalib. Color, cursor position, and other controls are availble via the ncurses library, see the LDP man page for ncurses. There are also many X windows like alternatives to X. A well established one is MGR which is effectively a usable subset of the X windows system. Microwindows on the other hand is a more recent ongoing project that aims to provide a windowing GUI specificaly for lightweight embedded systems. Using X windows itself, it should be noted that some modern window managers a great consumers of resources. There are a number of lightweight and minimalistic window managers available, but in many embedded applications a window manager may not be required or desired at all. In this case you may launch X with no window manager. Typicaly you would also start your own application software (perhaps at full screen), but you would be at liberty to launch existing X apps such as e.g. an mpeg movie player, giving co-ordinates for the placement of the window which will appear with no 'frame' (task bar, iconise buttons etc.), and would also retain full use of the networking facilities.
Here I need good homepage URL's with short comment on the project status and useability
I would like to do this by example. If people can tell me that their FOO project which does this, that and everything else requires x/y/z, then I will put up a representative cross section (projects will be presented in an anonymous fashion)
Generally speaking, in the world of information technology real time means that the system performs it's task without siginificant delay. In most applications it is enougth that the system is simply fast enougth to be able to handle the tasks expected of it. However, some applications require precise timing requirements. Typicaly, it is required that a tasks is invoked at fixed perodic intervals, or that a task can be scheduled to start (or stop, or whatever) after a specific time period. Real time does not necessarily mean fast, it means tasks can be scheduled to occur after a pre-determined time (neither sooner or later) within known tolerances. In OS kernel terminology, the latter case is what is meant by the phrase real-time, simply being quick to respond is often termed 'real-fast'.
A common mis-conception among newcommers to embedded systems is that real-time is somehow better than real-fast (presumably on the basis that it is more sophisticated), and therefore being unsure they aim for real-time to be on the safe side. In reality real-time should only be used where necessary. It requires that the scheduling of processes is planned, and this must be reviewed whenever the system is modified. Badly planned real-time scheduling can easily result in a worse performance and cause more problems than if the default scheduler had been used. On the other hand, a good real-time system requires not only carefull initial design, but on-going fine tuning if it is to remain effective.
Any system (real-time or real-fast) must be able to handle the foreground tasks within acceptable limits, using real-time techniques will rarely let you utilise siginificantly less powerfull hardware for the same application. A common problem is that whilst the hardware is able to keep pace with the worst case of forground tasks, every so often background or periodic maintenance tasks will combine to slow down the system to the point where the primary tasks no longer complete in time. This could be resolved with real-time methods, but generally is far better resolved using 'priorities'. It is possible to set priorities for tasks, and althougth it may be tempting to try and have higher priorities on the most important tasks, it is normally better to set lowwer priorities on the background or houskeeping tasks, such that they tend to execute when the processor has spare cycles. See the nice manpage for a simple way to launch apps with a low priority).
If the application is really coarsly grained, it may be preffereable to launch heavy background tasks via a routine which first checks the CPU load avg or network traffic (via /proc or systems calls) and deffer the launching of the task if the system appears heavily loaded.
Another situation in which designers think they may need a real-time system is when they must respond quickly to an I/O event. If that event is capable of generating an interupt then the best approach would be an interupt handler, which may be implemented in an installable kernel module. This is a lot easier to do than it may sound, a basic kernel module requires only 4 lines of code. See here for more information on doing this.
But suppose you have read the above and are STILL convinced you need real-time, then of course linux has that as well. There are several different solutions depending on the type of scheduling and the form of the implementation you require or desire. The general linux embedded sites (lings at end of this faq), will give pointers to the home pages for the various options.
I would like links to real-time options "guide" or overview
Apart from ash, what other suggestions do you have?
[This is NOT legal advice]
The short answer is no.
The GPL requires that any additions or extensions to the GPL'd software (which conversly means any software that incorporates GPL software) must in itself go under the GPL. This does not apply at a system level, so the fact that you have a system that is wall to wall GPL does not exclude the inclusion of a propritry closed source program, a fact that is obvious when one thinks of how many closed source apps are now available for Linux.
However, as the kernel is GPL'd, then anything included in the kernel (such as a device driver) must itself be under the GPL and hence with open source code. If proprietry algorithms are required for which the source must be undisclosed, then this may still be done using kernel modules.
Note that if you are using GPL'd development tools (such as gcc) you may inherit limitations by linking in GPL'd libraries. The GPL has a special case for libraries, and general purpose ones (specificaly the 'C' library ) do not require you to release source if you do not modify the library. However some libraries that implement complete building blocks do require source code release. If you do not intend to release source to a specific program, check the license of the libraries you link to, or use non GPL/commercial libraries or development tools.
BSDish type licences (which includes Xfree and it's libraries) do not require source code release.
As for supplying the source code for the GPL software you have included, you do not need to actually supply a copy with each product, you only need make it available on request, and you may make a reasonable charge for this. BTW, it is unlikely that you will be asked for all the source to your base distributions, because it is so widely available from up to date sources.
Two easy valid solutions for doing this are to dump the GPL source on your ftp site, or to give a copy to your customer support team who will supply it on request, charging their normal hourly rate plus materials and shipping.
You will of course require a copyright notice that states that you have used GPL'd software in the product, and were they can go to get a copy.
The primary site for more information (and a full copy and legal explanation) of the GPL is the Free Software Foundation.
Nowdays PC's come in a whole smorgasboard of form factors. Compact PCI, credit card sized modules, PC 104, PC on a DIMM......
Linux will run on just about all these products, with many manufacturers actively supporting Linux. Make a shortlist of the products that most interest you (or the type of product), and then post to the list in case somebody has tales of woe, or particular recomendations.
For simple requirements see the LDP mini-HOWTO "IO-Port-Programming", which explains how you may access IO ports and use other ports (such as printer and joystick ports) from user space programs.
For more complex requirements (Interupt handlers, DMA etc.) you will require a kernel module (device driver). These are simple and straightforward to develop under Linux, and the process is well documented. The 'guides' section of the LDP has a specific kernel modules guide, as well as the general kernel hackers guide and a guide that explains the architecture of the Linux kernel itself.
ORA have published a good book called "Linux Device Drivers" by Alessandro Rubini which is a concise and straightforward guide to developing your own Kernel modules.
Start by refrencing the IO-ports HOWTO, and then go on to explain about the joys and simplicities of kernel modules. Will cite Alessandro Rubini's book, what about URL's?
I know about the stuff for CAN and 488 on the Linux LAB project, anybody have any other pointers/info?
Need official home URL's for stuff such as PicoBSD and eCos....whatever
Will also cite ELKS