embedding in common PC hardware
 

Hi,
I am looking for your help to find out this information.
Has anyone embedded linux in a common PC hardware, that is chosen what devices it has on, everything is compiled and tweaked for only these devices and no useless operation is done at boot (init stuff)?
Could I find some documentation about this project or possibility, if any?
Thanks

It sounds like you are just talking about a minimal Linux system with a optimized and hardware-tailored kernel. That is easy to do, and some distributions (LFS comes to mind) make it fairly straightforward. The small, optimized, OS can then be booted from a CF card or similar arrangement.

What would be the main advantage of this kind of hardware-taylored system? OK if it's reduced boot time because I am interested in ultra-fast boot.
I read the LFS book but there's not that kind of information. However I cannot compile everything in a system, I want just to edit kernel and scripts.
So I think I need a project that was already made by someone to study it.

Hello,

I agree with MS3FGX, if you really want to fine tune the whole system, a LFS based system is probably the best alternative. The drawbacks is that you will have to spend a lot of time to configure each packages and it does not have any package manager :(
Another good alternative may be Gentoo. Its portage system is really awesome when you master... but you will have a long learning curve for that. Gentoo advantages is that you can choose everything, for example which package for boot process (upstart, standard sysv, systemd, openrc, or something else...). You can also choose which support to enable for each package, for example, you know that you will never use ipv6 or gnome, well each package having option/dependency related to ipv6 or gnome will be compiled without this kind of support. Also you will be able to fine tune compilation by telling portage system to compile each package with the best gcc options for your architecture.
Anyway considering your requirements, if you really want a real fast boot and fined tuned sytem, you will have to spend a lot of time.

Kind regards,

Oliv'

What type of system do you actually want to build? Ordinary desktop? Fileserver? Any other device?

Please take a look at the following:
it's excerpts from dmesg output (printk.time=1 option)

I read many documents about init process and I think this output is from modules.
I chose the lines where a big delay was encountered to show you. I don't know if it has to be blamed on the first line or the second, and I don't know if that time is printed at the beginning or at the end of the module execution. I don't even know what module it is from (I try with grep but it seems to be difficult).
But I want to reduce that time. I absolutely need to know how.

This modules are actually probing your hardware. You do have a multi-card-reader? That is the one that is actually probed there (amongst others). You can of course compile a kernel that contains only the modules you need, but I don't think that it will really speed up your boot. Loading modules is only a part of it, you also have to start daemons, initialize the network, and, and, and.
May be you are beginning from the wrong point. The fastest booting is that, that actually didn't take place. I almost never really boot, I almost always set my system up to suspend (most of the time) or hibernate (if I am longer away from home). This way, normally I get "boot times" <2s (suspend), and when coming home from longer absence, I don't know for sure, but I think it is less than 15s, including BIOS post.

The point is: the system never changes and never breaks so what do the modules probe?
I want to edit the modules code so they just load some register and the address of the device. I think it can be done and maybe someone did it. if not, I would like to know how to do.

Ok so what you want is probably that: http://elinux.org/Deferred_Initcalls (and probably also some other customizations)
Also have a look to other pages on this site... many of them are really really interesting ;)

Kind regards

Oliv'

Maybe I am wrong here, and please anyone correct me if so. The modules for embedded devices are very special, I would believe, while the modules for ordinary PC-hardware are for a much broader range of devices. That means, that a module can drive more than one piece of hardware, for example like the snd_hda_intel-module. So in any way it has to probe which hardware exactly is in the system, even if the hardware has not changed.
But this are only my :twocents:, maybe I am just plain wrong here.

Well, technically, by the time you see all of those messages, the system is booted. Loading modules is done by userspace applications such as modprobe and once userspace applications have started, the system is booted. You could build modules into the kernel, or delay loading of the modules if you need some other actions to start earlier. The init process is where you need to focus to modify this behavior. On hardware that I work with (ARM), a busybox shell is loaded in userspace in about 2 seconds following reset/power-on. The entire application can be embedded in an initrd, and launched by the kernel before any spinning media (if it even exists) ever sees a probe or a prod.
A lot of the probing and delays that are part of device driver initialization is to accommodate things like Plug & Play compatible devices. Linux desktop and server oriented installations are geared to be generic enough that they can accommodate various hardware configurations and respond to changes in hardware configuration. When I think about embedded systems, I think exactly the opposite: exactly enough hardware and software to accomplish the one job that the system is required to perform. Reduce everything to the minimum footprint.

--- rod.

Well, the kernel in a desktop distribution would include modules for more devices, while an embedded device would have a set hardware configuration, but there is no fundamental difference between the two. You can just as easily compile in all the drivers your desktop needs and not use any modules at all, which in fact is what I do on my machines since I don't change my hardware very often.

You could try to disable floppy support, swap and USB mass storage support if you don't need those.
Alternatively it might be possible to compile those as modules, so that you load them after your system is booted.

P5music, what do you want your embedded system to do, specifically? Do you already have some/most/all of an application or suite of applications that need to run? What hardware driver support does your application(s) require?
To get the fastest boot time, you should launch your application(s) directly from a RAM disk that is built into the kernel image (initrd), and the required driver(s) should be built into the kernel. In a traditional desktop or server oriented system, there is an init process that launches driver loaders, like modprobe, and performs a lengthy configuration process. The init process is identified to the kernel via kernel arguments (supplied by the bootloader), or may be built into the kernel. The init process can be anything you want, and you can simply roll your own. I think it needs to be statically linked, but otherwise it can be any program you want, or write. Given the circumstances around how it is loaded, it may need to do some extra work to initialize the system to a point that it can operate. Those are details that are specific your application and hardware architecture.
If you are using a traditional PC host platform, you will always get delays related to the BIOS initialization procedure. This too, can be minimized. If you have a host architecture that allows for BIOS extension ROMS, these will be identified early on by the BIOS, and invoked at an early stage in the boot process. They can be used to bootstrap your OS without delay, and using whatever means is appropriate to your application. PXE boot ROMs that are installed on ethernet adapters are a good example of this technology. There is nothing to say that such a BIOS extension ROM on an ethernet adapter has to use the ethernet; it can do whatever you want it to (you just have to write the code...).
By nature, embedded systems have very specific purposes, and it is difficult to guide you without some details of what your application needs to do, what your requirements are, and what hardware is involved.

--- rod.

I apologize in advance for having no answers to any follow-up questions.
 

I just don't follow this subject closely. But I did recently note, with passing curiosity
http://bootdebian.blogspot.com/

which looks possibly like it has at least the general type of information you're after.