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.
Cover inittab etc.
Good question this, answers? mini-howtos?
Who knows the state of the art?
Mention IDE types and other solutions with linux support
Intend to talk about mounting RO, the filesystem standard, symlinks, perhaps will do a mini-howto.....other suggestions please!
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?
Will talk about minimalist window managers, and smaller versions of X. Need good reliable URL's
Will also mention SVGA(BGI). Anything else?
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.
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