Consider a live GNU/Linux distro with the following constraints: all the software should be contained in an initrd image (which results in its huge size) and the kernel contains as few statically-compiled modules as possible.
Consider the bootup process of the described distro: the bootloader (e.g. grub or isolinux) loads the kernel, which then loads and extracts the initrd into the memory. During the extraction (which takes 20-30 seconds on old computers) nothing happens on the screen.
I was wondering, is there a ready-made solution of showing a splash screen during the initrd extraction process? If not, can you please comment on the following ideas:
Statically compile an e.g. 600x480x8bit image into the kernel and somehow flush it into the framebuffer while initrd is being extracted.
Do the same, but force a particular video driver to be loaded (e.g. VESA) and hack into its code, rather that kernel's framebuffer.
Thank you.
Perhaps you can make it simpler: Create 2 initrd files. The first one can be small. Then it can call Plymouth to show a splash screen while the real initrd is extracted.
You are wrong if you think, that the kernel loads the initrd image. It is done by the boot loader. If you want to show a splash screen you have to tell your boot loader to display an image. How to do this depends on your boot loader.
You might try creating a plain .ppm file and use LZMA compression for the Kernel Compression Mode. This might be done by using the boot logo option, but not sure if it will work for you.
First you need to enable support in your kernel for Bootup logo and Standard 224-color Linux Logo:
Device Drivers —> Graphics Support –>
Support for frame buffer devices
VESA VGA graphics support
Video mode selection support
Framebuffer Console support
Select compiled-in fonts
VGA 8×16 font
Bootup logo
Standard 224-color Linux log
Second,if supposed that you have a .png image named screen.png, you need to generate the appropiate .ppm file:
pngtopnm screen.png| ppmquant -fs 223 | pnmtoplainpnm > /usr/src/linux/drivers/video/logo/logo_linux_clut224.ppm
Then just compile, install, update your bootloader and check if it works for you.
Related
I've successfully used buildroot (v. 2019.05) to built u-boot and Kernel and was able to boot it together.
The problem is that, even though I selected Kernel compression mode to gzip, all I get is the uncompressed Image file.
In the output directory (and Linux as well) there is only Image file, while there should be Image.gz.
How to generate Image.gz from / instead of Image?
On arm64, Linux does not support self-extracting compression. It relies on the boot loader to do that.
The Linux build system does have an Image.gz (and Image.bz2 etc.) target, but it does nothing more than calling gzip on Image (compare this with zImage, which adds a self-extractor).
Since it is easy to do the compression outside of the kernel build system, and since there are so many different compressors possible, Buildroot doesn't provide options for them. However, it is possible to select a custom image name (BR2_LINUX_KERNEL_IMAGE_TARGET_CUSTOM) and then set BR2_LINUX_KERNEL_IMAGE_TARGET_NAME to Image.gz. Alternatively, you can do the compression in a post-build script.
Remember to make sure that the bootloader is able to decompress with that algorithm.
According to the Linux package configuration tool:
This selection will just ensure that the correct host tools are built.
The actual compression for the kernel should be selected in the kernel
configuration menu.
Make sure you select the compression option using make linux-menuconfig too.
In buildroot, besides selecting the compression mechanism you can also select the output format for the kernel image (uImage, zImage, vmlinux ...).
You should find on of those in your output/images/ or in the build directory of your kernel.
When using U-boot you probably want to use the uImage or the zImage. See this question. Both of them will be compressed if selected in the kernel configuration (CONFIG_KERNEL_GZIP).
During boot the uncompressed size of the kernel is logged in the beginning. You can compare it to the size on your filesystem.
## Booting kernel from Legacy Image at 10000000 ...
Image Name: Linux-4.14.73-ltsi
Created: 2019-05-14 11:55:16 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 4684016 Bytes = 4.5 MiB
Load Address: 00008000
Entry Point: 00008000
...
Kernel 3.19 (re-)introduced Device Tree Overlays. I am on Linux kernel 3.19.4, via Fedora (3.19.4-200.fc21.armv7hl).
I have an overlay file overlay.dts as described in the documentation.
overlay.c contains functions to work with overlays, including to functions to load an overlay.
Does the kernel check any paths for overlays to load? If so, where? If not, how can I load my overlay?
From my experience (3.8-3.14), DTB loading is actually the jurisdiction of the boot-loader, rather than the kernel itself. I've used u-boot for this - u-boot can load the compiled device-tree file (man dtc) from an EXT2-based filesystem to a known location in RAM, which is then specified in the kernel command line.
Which boot-loader are you using?
I am doing project on Pandaboard using Embedded Linux (UBUNTU 12.10 Server Prebuild image) to optimize boot time. I need techniques or tools through which I can find boot time and techniques to optimize the boot time. If anyone can help.
Just remove application which is not required from /etc/init.d/rc file also put echo after every process initialization and check which process is taking much time for starting,
if you find application which is taking more time then debug that application and so on.
There is program that can be helpful to know the approximate boot-up time. Check this link
Time Stamp.
First of all the best you have to do is to compile yourself your own made kernel, get the source on the internet and do a make xconfig and then unselected everythin you don't need.
In a second time create your own root filesystem using Buildroot and make xconfig to select/unselect everything you need or not.
Hope this help.
I had the same problem and do that way, now it's clearly not the same ;)
EDIT: Everything you need will be here
to analyze the boot process, you can use Bootchart2, its available on github: https://github.com/mmeeks/bootchart
or Bootchart, from the Ubuntu packages:
sudo apt-get update
sudo apt-get install bootchart pybootchartgui
There are broadly 3 areas where you can reduce boot time
Bootloader:
Modify the linker script to initialize only the required h/w. Also, if you are using an SD card to boot, merge kernel and bootloader image to save time.
Kernel:
Remove unwanted modules from kernel config. Also try using compressed and uncompressed image. If your CPU is good enough to handle it go compressed image and check uncompression time required for different compression types.
Filesystem:
FS size can be significantly reduced by removing the unwanted bins and libs. Check for dependencies and use only the one's that are required.
For more techniques and information on tools that help in measuring the boot time please refer to the following link.
Refer to Training Material
The basic rule is: the fastest code is code that never gets loaded and
run, so remove everything you don't need:
in U-Boot: don't load and run the full U-Boot at all; use FALCON
mode and have the SPL load the Linux kernel and DTB directly
in Linux: remove all drivers and other stuff you don't really need;
load all drivers that are not essential for your core application as
modules - and load them after your application was started. If you
take this serious, you may even want to start only one CPU core
initially (and start the remaining ones after your application is
running).
in user space: minimize the size of the root file system. throuw
out anything you don't need; configure tools (like busybox) to
contain only the really needed functionality; use efficient code
(for example, link against musl libc instead of glibc) etc.
What can be acchieved by combining all these measures can be seen in
this video - and yes, the complete code for this optimization is
available here.
Optimizing embedded Linux Boot process , needs modifications in three level of embedded Linux design.
Note: you will need the source codes of bootloader and kernel
Boot : the first step in optimizing and reducing boot time of board is optimizing boot loader. first you should know what is your bootloader is. If your bootloader is an opensource bootloader like u-boot than you have the opportunity to modify and optimize it. In u-boot we have a procedure that we can skip unnecessary system check and just upload kernel image to ram and start. the documentation and instruction for this is available in u-boot website. by doing this you will save about 4 ~ 5 second in boot.
Kernel : for having a quicker kernel , you should optimize kernel in many sections. for editing you can use on of Linux config menu. I always use a low graphic menu. it need some dependency you can use it by this command:
$ make menuconfig
our goal for Linux kernel is to have smaller kernel image and less module to load in boot. first change the algorithm of compression from gzip to LZO. the point of this action is gzip algorithm will take much time to extract kernel. by using LZO we have a quicker kernel decompression process. the second , disable any unnecessary driver or module that you don’t have it on your board or you don’t use it any more. by doing this , you will lose some device access and cannot use them in Linux but you will have two positive points: less Ram usage , quicker boot time.
but please remind that some driver are necessary for Linux and by disabling them you will lose some of main features (for example if you disable I2C driver in Linux you will no longer have a HDMI interface) that you need or in worst case you will have a boot problem (such as boot-loop). The third is to disable some of unusable filesystem to reduce kernel size and boot time. The Fourth is to remove some of compression algorithm to have smaller kernel image.
the last thing , If you are using a u-boot bootloader create a uImage instead of zImage. the following steps , are general and main actions , for having quicker boot as 1 second after power attach you should change more option.
after two base layer modifications, now we should optimize boot process in user-space (root file system). depend on witch system are you using , we have different changes to do. in abstract root file system of Linux that have necessary package and system to boot Linux we should use systemd instead of Unix systemv , because systemd have a multi-task init. system and it is faster , after that is udev that you should modify some of loading modules. if you have a graphical user-interface , we can use an easy trick to have a big boot time reduction by initing GUI first and load other module after loading GUI.
if you do all of following tasks , you can have quick boot time and fast system to work with.
According to this picture from The Kernel Boot Process:
The bulk of the kernel image is only ~1.5MB. I thought the kernel image should be a fairy large binary image file in order to support the hardware (or is this kernel module?) and various kernel functions, since the source is pretty large. Also, where's the initrd?
First the kernel is compressed. Then in most desktop environment, the kernel is built with a minimal set of statically linked modules. The initrd image is loaded from the hard drive, from the /boot folder (see your grub configuration) and is used to detect your desktop hardware to load the appropriate modules, to be able to mount a root file system. The initrd image contains this sets of modules. Imagine a RAID, LVM or an exotic file system that cannot be recognized by the bootloader. This is why the boot partition is most of time in ext2/3/(4?). Then when the right modules are loaded, the root file system is swapped from initrd image with the one on the hard drive (pivot_root). Then the rest of the hardware modules are loaded from the "none initrd" filesystem, mostly with the help of udev.
Hope this helps!
P.S. Correct me if I'm wrong!
In my ARM based custom board, I flash u-boot to NAND whenever I do changes on that. (putting some debug statements/modification). Is there any way to directly load the uboot image in RAM memory instead of flashing it every time?
For linux kernel image I do load it in memory and use bootm to boot that image. Similarly for u-boot I am trying out. Kindly provide your suggestions.
Someone at Freescale has done this, for their P1022DS evaluation system (and some others as well). They have provided a somewhat useful document about the process in the file ${UBOOTROOT}/doc/README.ramboot-ppc8500 (in U-Boot V2010.12). This document is pretty terse and leaves many questions unanswered, but I found it a reasonable place to start when I needed to debug U-Boot for a new board, before the flash memory for that board was operating correctly.
In fact, having non-functional flash memory is one reason you might want to debug U-Boot in RAM. (There are a few reasons listed in the README, and they all sound pretty reasonable to me, in contrast to some of the other advice available on this subject)
In our situation, it was found that early prototype target board hardware included an error in the address bus connection to the flash memory that prevented us from using that flash memory. While the hardware was being redesigned and re-fabricated, we wanted to continue testing/debugging those parts of our U-Boot configuration that did not depend on flash memory, for example, I2C, Ethernet, FPGA configuration, PCIe, etc. (there are plenty of things that are independent of where the U-Boot image comes from).
Running U-Boot after loading it into RAM via a JTAG interface (using Codewarrior and the USB TAP) allowed us to continue our U-Boot bring-up tasks, even though we had no functional flash memory. Once we received a newer version of the target board with correctly functioning flash memory, we returned to debugging those parts of U-Boot that we hadn't been able to test earlier. After that, U-Boot was fully functional, and we did not have to wait for a board spin to make any progress.
Debugging a bootloader is a bit difficult, but with the right tools it should be relatively painless.
I deal with the PowerPC achitecture and with a BDI-3000 I can load and debug directly to RAM (of course, after initializing the DDR controller).
One option is if you have on-chip SRAM or L2 Cache that can be configured as on-chip SRAM. The BDI can copy to the SRAM area first, u-boot does it's thing (initialize DDR controller for example), then relocates itself to DDR RAM afterwards. Definitely faster that re-writing to slow Flash all the time.
It wasn't possible in 2004, at least.
It should be possible, if the U-Boot image you want to run has startup code that allows running it from arbitrary addresses. Whether or not that is the case for your board I can't tell.
If the startup code begins by copying the code section from the current (PC-relative) address to the final execution address (usually this is preceded by a check that these areas don't overlap), then you can load the .bin file to any address in RAM, and invoke it using go.
The second obstacle I could see would be unconditional RAM setup code at the beginning, which a number of boards have.
This is what can be read on the u-boot documentation FAQ:
Question:
I don't want to erase my flash memory because I'm not sure if my new U-Boot image will work. Is it possible to configure U-Boot such
that I can load it into RAM instead of flash, and start it from my old
boot loader?
Answer:
No. (Unless you're using a Blackfin processor, or Socfpga board, but you probably aren't.)
Question:
But I've been told it is possible??
Answer:
Well, yes. Of course this is possible. This is software, so everything is possible. But it is difficult, unsupported, and fraught
with peril. You are on your own if you choose to do it. And it will
not help you to solve your problem.
source:http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
The problem here is that what you are trying to do goes against the philosophy of what a bootloader is. Most processors require that code starts from Flash. That code is called a bootloader. That is what U-boot is.
However, if you want to modify U-boot so that it is not a true bootloader, then you can do whatever you want. It's just software. But don't expect any mainline support for the above reasons.
Just take in mind (be care of) the hardware that you are configuring in your modified U-Boot. U
Boot is intended to initialize critical modules, some of them are not able to be re-configured on the fly or they may not performe as if they were initialized/configured at startup.
If your Target board support network booting, you can load uboot image from host machine to RAM through network.
You can use usb boot. TI and Freescale provides their usb boot utilities. I don't know about other vendors.
Yes, It is possible most of the compilation structure at the end U-Boot provides a u-boot.bin file which is a flattened binary, if your target supports USB/TFTP or any other medium which current U-boot can detect on you target environment then we can load the u-boot.bin file to the static memory address area. This address is the entry point of U-Boot Code and U-boot can execute the flattened binaries by go 0x<memory_address>. The static memory address area can be deduced form u-boot.map file, This entry point is basically address to the .text area of compiled program usually can we searched in the .map file with string "Address of section .text set to 0x." Below is the example of doing it from USB.
usb start
load usb 0x<memory_address> u-boot.bin
go 0x<memory_address>
This should run you U-Boot from usb with out disturbing current code.